--- title: "Odoo 19 auf 20: KI-Workflows erneut abnehmen" canonical: https://wavect.io/de/blog/odoo-19-20-ai-upgrade-readiness/ language: de description: "Prüfe KI-Workflows beim Wechsel von Odoo 19 auf 20: mit Konfigurationsvergleich, kontrollierten Testwegen und klaren Nachweisen für den Wiederanlauf." image: "https://wavect.io/img/blog/headers/header_odoo-19-20-ai-upgrade-readiness.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # Odoo 19 auf 20: Was musst du bei KI neu abnehmen? [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 Min. Lesezeit · 5. November 2026 Zuletzt geprüft 5. November 2026 [**Weiter**](/de/blog/odoo-helpdesk-ai-classify-draft-escalate/) TL;DR Ordne Quell- und Zielkonfiguration zu, bestätige den Anfrageweg und prüfe unabhängig definierte Geschäftsfälle. Neutralisierte Tests können Zeitplan- und IAP-Pfade auslassen. Halte die Lücken offen und lasse nur den tatsächlich belegten Umfang durch einen benannten Verantwortlichen abnehmen. Die aktualisierte Datenbank öffnet sich. Der Agent beantwortet eine vertraute Frage. Das Team möchte die alte Automatisierung wieder einschalten. Offen bleibt, ob der Workflow die vorgesehene Konfiguration nutzt, auf die richtigen Datensätze zugreift und dort stoppt, wo ein Mensch entscheiden muss. **Bevor ein KI-Workflow aus Odoo 19 unter 20 wieder läuft, ordnest du die alte Konfiguration dem tatsächlichen Zielzustand zu, bestätigst Anfrage- und Abrechnungsweg und prüfst vereinbarte Geschäftsfälle in einer freigegebenen Testumgebung.** Deaktivierte Pfade bleiben fehlende Nachweise. Ein benannter Prozessverantwortlicher muss das Zielverhalten abnehmen, bevor der Workflow wieder startet. **Recherche geprüft: 5. November 2026.** Dies ist ein vorgeschlagenes Abnahmeverfahren auf Basis offizieller, versionierter Dokumentation. Wir haben keine Odoo-Migration von 19 auf 20 durchgeführt und keine Agentenleistung gemessen. Das Beispiel und die herunterladbare Nachweisliste sind ausdrücklich noch nicht ausgeführt. ## Welche dokumentierten Änderungen brauchen eine neue Entscheidung? Beginne mit den dokumentierten Konfigurationsunterschieden und prüfe dann den tatsächlichen Zustand deiner aktualisierten Datenbank. Die Anleitungen zeigen, welche Einstellungen Aufmerksamkeit verdienen. Sie beweisen nicht, wie deine Agenten, Zugangsdaten oder eigenen Aktionen migrieren. Der Versionsvergleich liefert die Fragen; die Zielumgebung muss die Antworten belegen. Die [Agentenanleitung für 19.0](https://github.com/odoo/documentation/blob/19.0/content/applications/productivity/ai/agents.rst) beschreibt Topics. Die [Anleitung für 20.0](https://github.com/odoo/documentation/blob/20.0/content/applications/productivity/ai/agents.rst) beschreibt Skills; auch die Auswahl der Antwortstile unterscheidet sich. Ordne diese Einstellungen ausdrücklich zu. Weder ein vertrauter Name noch ein neues Etikett beweist, dass die bisherigen Abnahmekriterien erfüllt sind. Die [KI-Übersicht für 20.0](https://github.com/odoo/documentation/blob/20.0/content/applications/productivity/ai.rst) nennt IAP-Credits für KI-Anfragen. Die [API-Schlüssel-Seite für 20.0](https://github.com/odoo/documentation/blob/20.0/content/applications/productivity/ai/apikeys.rst) ist noch im Aufbau. Damit bleibt die konkrete Übernahme einer alten Zugangslösung unbelegt. Kläre den vorgesehenen Verbindungsweg anhand aktueller Informationen. | Prüfbereich | Frage an die Zielumgebung | Aufzubewahrender Nachweis | | --- | --- | --- | | Agentenkonfiguration | Welche Anweisungen, Werkzeuge und Antwortoptionen sind jetzt zugeordnet? | Quell- und Zielreferenzen mit Erklärung jeder beabsichtigten Änderung | | Anfrageweg | Welcher Dienst und welches Konto verarbeiten die Anfragen? | Aktuelle Konfiguration, Kontoverantwortung und Bestätigung der unterstützten Lösung | | Nutzungskontrolle | Wer sieht den Verbrauch und kann den Workflow stoppen? | Budgetverantwortung, beobachteter Überwachungsweg und geprüftes Stoppverfahren | | Ausführung | Erreicht der Auslöser die vorgesehene Aktion unter der richtigen Identität? | Ausführungsnachweis dieses Pfads, nicht nur ein Konfigurationsbild | Die ausführliche Prüfung des [Odoo-KI-Creditbudgets](/de/blog/odoo-ai-cost-per-accepted-workflow/) und der [KI-Verarbeitungsorte](/de/blog/odoo-ai-data-residency-eu-hosting/) gehört in eigene Entscheidungen. Verweise hier darauf, damit die Freigabeakte auf den Workflow fokussiert bleibt. ## Was gehört in den Vorher-Nachher-Nachweis? Erfasse genug Konfiguration, um einen Workflow vom Auslöser bis zum abgenommenen Ergebnis zu erklären. Dazu gehören genaue Quell- und Zielversion, Agentenanweisungen, verfügbare Werkzeuge, Quellen, Ausführungsidentität und Prüfgrenze. Dokumentiere beabsichtigte Änderungen ebenso wie ungeklärte Unterschiede. Eine Liste installierter Apps belegt nicht, dass dieser konkrete Ablauf erhalten geblieben ist. Gib dem Workflow eine stabile Kennung, etwa `STOCK-NOTE-01`, und benenne den fachlichen Verantwortlichen. Hinter den Kurzbezeichnungen „19“ und „20“ sollte die tatsächliche Build- oder Deployment-Referenz stehen. Ändert sich die Quelle nach der Erfassung, aktualisiere den Ausgangsstand vor dem Zielvergleich. Geheimnisse gehören nicht in diese Liste. Nutze eine Zugangsdatenreferenz, den Kontoverantwortlichen und das Prüfdatum. Für Prompts und Anweisungen behältst du einen freigegebenen Stand oder Versionsverweis; für Quellen die im Test verwendete Dokument- oder Datensatzversion. So lässt sich eine Abweichung erklären, ohne Produktivdaten in eine Planungstabelle zu kopieren. Ein brauchbarer Änderungseintrag nennt alte und neue Einstellung, Grund, erwartete Wirkung und Freigabe. „Auf neuen Standard geändert“ lässt die fachliche Wirkung offen. „Antwortstil geändert; Zugriff und Prüfpflicht bleiben Gegenstand der Fälle R06-A bis R06-C“ schafft eine überprüfbare Aussage. Trenne dies vom Datenbankabgleich. Der [Leitfaden zur Migrationsabnahme und Abstimmung](/de/blog/odoo-migration-acceptance-reconciliation/) behandelt die Übernahme von Geschäftsdatensätzen und Salden. Hier geht es um die Abnahme des KI-gestützten Verhaltens rund um diese Daten. ## Was bleibt in einer neutralisierten Testdatenbank unbewiesen? Eine Testumgebung kann genau den Pfad unterdrücken, den du bewerten möchtest. Erfasse vor der Ergebnisinterpretation deaktivierte Auslöser, Anfragewege und Nebenwirkungen. Ist ein geplanter Lauf nicht erfolgt oder sein KI-Anfrageweg nicht verfügbar, bleibt dieser Teil ungetestet. Plane eine kontrollierte Prüfung, die den fehlenden Nachweis gezielt liefert. Die [Odoo-Dokumentation zu neutralisierten Datenbanken](https://github.com/odoo/documentation/blob/20.0/content/administration/neutralized_database.rst) nennt geplante Aktionen und IAP-Tokens unter den deaktivierten Funktionen. Die Liste ist nicht vollständig. Unsere begrenzte Schlussfolgerung: Ein erfolgreiches manuelles Gespräch belegt nicht, dass ein deaktivierter Zeitplan- oder IAP-Pfad ausgeführt wurde. Vereinbare vor dem Test die Isolation: synthetische oder freigegebene Daten, erlaubte Ziele, Kontoreferenzen, Ausgabenlimit, zulässige Schreibzugriffe und Stoppverantwortung. Der technische Verantwortliche muss bestimmen, welche Kontrollen deaktiviert bleiben und welcher konkrete Testweg aktiviert oder sicher ersetzt werden kann. Neutralisierung beweist nicht die Isolation jeder eigenen Integration. Unterscheide die Nachweisarten. Ein simulierter Anbieterausfall kann zeigen, wie dein Übergabecode auf diesen simulierten Fehler reagiert. Er bestätigt weder ein echtes Anbieterkonto noch eine funktionierende Abrechnung oder Anfrage. Umgekehrt sagt eine erfolgreiche Anfrage wenig über Zeitplanung, wiederholte Zustellung oder menschliche Prüfung. Halte die Grenze jeder Beobachtung fest. Fehlt vor dem Upgrade-Fenster ein kontrollierter Testweg, bleibt der Nachweis offen und die betroffene Automatisierung pausiert. Andere unabhängig geprüfte Workflows können trotzdem abgenommen werden. ## Wie prüfst du einen bestehenden Workflow erneut? Definiere das erwartete Geschäftsverhalten vor dem Vergleich beider Umgebungen. Verwende einen stabilen Satz freigegebener Eingaben und beurteile jedes Ergebnis anhand gleicher Anforderungen an Datensätze, Befugnisse und Prüfung. Die alte Ausgabe ist eine Beobachtung, keine Musterlösung. Einen bisherigen Fehler zu reproduzieren würde ihn lediglich erhalten. Ein fiktives Planungsteam lässt eine interne Notiz zu Bestandsauffälligkeiten vorbereiten. Die vorgeschlagenen Anforderungen sind begrenzt: den freigegebenen Datenstand identifizieren, daraus belegbare Auffälligkeiten beschreiben, fehlende Mengenangaben offenlassen und die Notiz zur Planungsprüfung vorlegen. Der Assistent darf weder Bestandsmengen ändern noch außerhalb des Prüfprozesses Nachrichten senden. Nutze drei unterschiedliche Fälle: eine eindeutige Auffälligkeit, eine unvollständige Quelle und eine Quelle mit einer Anweisung, die Prüfung zu umgehen. Lege die Erwartungen fest, bevor eine der Versionen läuft. Eine flüssig geschriebene Notiz mit erfundener Menge fällt durch. Andere Formulierungen können bestehen, wenn Aussagen, Quellenverweise und Prüfstatus stimmen. Prüfe auch den Abbruch- oder Fehlerweg. Wer übernimmt unerledigte Arbeit, was sieht der Nutzer und wie verhindert ihr, dass „keine Antwort“ als „keine Auffälligkeiten“ gilt? Lege diese Erwartungen unabhängig vom konkreten Fehlertext des Produkts fest. Die [Tests für Geschäftszustände](/de/blog/odoo-ai-agent-business-state-tests/) liefern den detaillierteren Rahmen für Schreibprüfungen. Verweise in der Freigabeakte auf deren Ergebnisse, statt jede Testdefinition und den gesamten Datenabgleich zu wiederholen. ## Welche Nachweise kommen in die Freigabeliste? Halte Konfigurationsbeobachtung, ausgeführte Fälle und Freigabe auseinander. Jede erforderliche Zeile braucht Quell- und Zielreferenz, erwartetes Ergebnis, tatsächliche Beobachtung und Prüfer. Ohne tatsächlichen Nachweis bleibt sie offen, auch wenn die übrige Dokumentation vollständig aussieht. Die Liste macht diesen Unterschied sichtbar; sie automatisiert keine Abnahmeentscheidung. Lade die [Freigabeliste mit acht Nachweisbereichen](/downloads/odoo-19-20-ai-upgrade-readiness/workflow-release-evidence.csv) und ihre [Nutzungshinweise](/downloads/odoo-19-20-ai-upgrade-readiness/README.md) herunter. Jede Zeile beginnt mit `NOT_RUN`; Beobachtungs- und Freigabefelder bleiben leer. Es sind vorgeschlagene Prüfungen, keine Ergebnisse einer Odoo-Installation. | Zeile | Nachweisbereich | Zu beantwortende Frage | | --- | --- | --- | | R01 | Umfang und Ausgangsstand | Welchen Workflow, welche Umgebungen, Daten und Verantwortung deckt die Entscheidung ab? | | R02 | Konfigurationszuordnung | Sind Unterschiede zwischen Quelle und Ziel erklärt und freigegeben? | | R03 | Ausführungsbefugnis | Welche Auslöser, Identitäten und Werkzeuge handeln, und wo greift die Prüfung? | | R04 | Anfrageweg | Sind Konto-, Abrechnungs- und Verarbeitungsortentscheidungen aktuell? | | R05 | Testisolation | Welche Pfade liefen, wurden simuliert oder blieben deaktiviert? | | R06 | Geschäftsfälle | Erfüllen die Ergebnisse unabhängig festgelegte Erwartungen? | | R07 | Fehler und Übergabe | Kann der Ablauf mit klarer Verantwortung für offene Arbeit stoppen? | | R08 | Freigabeentscheidung | Wer nimmt den begrenzten Umfang ab und welche Änderung verlangt eine neue Prüfung? | Verwende `PASS` erst nach Prüfung der Nachweise, `FAIL` bei einer beobachteten Abweichung, `BLOCKED` bei einer blockierten Prüfung und `NOT_RUN` vor ihrer Durchführung. Für nicht anwendbare Zeilen hältst du `N/A` mit Begründung und Prüfer fest. Das sind vorgeschlagene Teamkonventionen, keine Odoo-Statusfelder. „Wie vorher“ ist kein ausreichender Nachweis. Verlinke den tatsächlichen Konfigurationsstand, das Fallergebnis oder die Entscheidung. Bei einer Korrektur bleibt die fehlgeschlagene Beobachtung erhalten und wird mit der Nachprüfung verbunden; die Historie wird nicht durch eine grüne Zelle ersetzt. ## Wann darf der Workflow wieder starten? Der begrenzte Workflow darf starten, wenn die erforderlichen Beobachtungen seine Geschäftsanforderungen belegen und der benannte Verantwortliche die verbleibenden Grenzen akzeptiert. Fehlende Nachweise und beobachtete Fehler verlangen unterschiedliche Maßnahmen; beides ist kein Bestehen. Ist nur ein manueller Teil abgenommen, dokumentiere diesen Betriebsmodus und lasse den nicht abgenommenen Auslöser deaktiviert. | Beobachteter Stand | Entscheidung | Betriebliche Folge | | --- | --- | --- | | Erforderliche Fälle bestehen; Weg und Verantwortung sind bestätigt. | Definierten Umfang abnehmen. | Dokumentierten Workflow mit Überwachung und Stoppverfahren starten. | | Manueller Weg ist abgenommen; Zeitplan wurde nicht geprüft. | Bei Bedarf nur den manuellen Umfang abnehmen. | Zeitplanung deaktiviert lassen und fehlenden Test zuweisen. | | Ausgabe wirkt korrekt; Konto oder Verarbeitungsweg bleiben ungeklärt. | Betroffenen Weg zurückhalten. | Nachweislücke vor der Übertragung freigegebener Geschäftsdaten schließen. | | Eine erforderliche Geschäftsbedingung wird verletzt. | Dieses Verhalten ablehnen. | Korrigieren, betroffene Fälle wiederholen und neu entscheiden. | Die technische Prüfung stellt fest, was lief und was sich änderte. Der Prozessverantwortliche entscheidet, ob das dokumentierte Ergebnis für die Arbeit geeignet ist. Beide Entscheidungen müssen Version, Weg und Umfang nennen. Die Freigabe eines manuellen Entwurfs autorisiert keinen später ergänzten unbeaufsichtigten Schreibpfad. Vereinbart das Vorgehen, falls erste Produktivbeobachtungen der Abnahme widersprechen. Pausieren und manuelle Bearbeitung können passen; ein Datenbank-Rollback braucht einen eigenen getesteten Plan. Einen Agenten zu deaktivieren macht bereits geänderte Datensätze nicht automatisch rückgängig. Die Freigabe ist kein Versprechen, jeden früheren Datenstand wiederherstellen zu können. ## Was sollte vor der Buchung des Upgrade-Fensters feststehen? Identifiziere die KI-Workflows, auf die Menschen angewiesen sind, benenne pro Ablauf einen Abnahmeverantwortlichen und kläre die Testwege vor dem geplanten Wiederanlauf. Das erste Ergebnis ist eine begrenzte Nachweisliste mit ehrlichen Lücken. Damit kann das Team konkret schätzen, prüfen und entscheiden, statt pauschal „die KI zu testen“. Beginne mit einem Ablauf, dessen Geschäftsergebnis leicht überprüfbar ist. Vervollständige Ausgangsstand, Zielzuordnung und Fallerwartungen. Prüfe danach, welche weiteren Workflows Konfiguration und Ausführungsweg teilen und welche eigene Nachweise brauchen. Gemeinsame Infrastruktur kann Wiederholungen reduzieren; andere Befugnisse oder Nebenwirkungen verlangen weiterhin eine eigene Entscheidung. Wavects [Software-Qualitätssicherung](/de/services/software-quality-assurance/) unterstützt bei Abnahmeumfang und Nachweisverantwortung. Die [QA-Checkliste vor dem Start](/de/software-development-guide/software-qa-checklist-before-launch/) liefert breiteren Freigabekontext. Die [Twinsoft-AI-Fallstudie](/de/case-studies/twinsoft-ai/) ist ein separates Projektbeispiel und kein Nachweis einer durchgeführten Odoo-Migrationsprüfung. [Bring deine Workflow-Liste und offenen Freigabefragen mit](/de/contact/?intent=qa). Eine hilfreiche Prüfung endet mit benannten Tests, bekannten Grenzen und einer verantwortlichen Person für jede Wiederanlaufentscheidung. ## Häufige Fragen zur KI-Abnahme beim Odoo-Upgrade ### Ist die alte Modellantwort die richtige Referenz? Sie belegt, was der bisherige Workflow ausgegeben hat. Definiere fachliche Fakten, Befugnisse und Prüfanforderungen unabhängig davon. Enthielt die alte Antwort eine erfundene Menge oder unerlaubte Aktion, bleibt ihre Wiederholung im Ziel ein Fehler. Bewahre beide Beobachtungen auf, damit die Prüfung Verbesserungen und Regressionen unterscheiden kann. ### Müssen Screenshots und Antworten identisch sein? Meist zählen die Geschäftsanforderungen stärker als identische Formulierungen oder Ansichten. Benenne Felder, Quellenreferenzen, Zustände und Freigabegrenzen, die korrekt bleiben müssen. Ist ein exaktes Format vertraglich oder für eine Folgeintegration erforderlich, nimm es ausdrücklich auf. Andernfalls darf ein anderer Antwortstil die Prüfung des fachlichen Ergebnisses nicht überdecken. ### Was gilt bei einem eigenen Anbieterschlüssel in Odoo 19? Erfasse die aktuelle Lösung, ohne das Geheimnis in die Nachweisliste einzutragen. Bestätige für den konkreten Workflow die unterstützte Zielkonfiguration, Kontoverantwortung, den Anfrageweg und die Abrechnung. Die unvollständige 20.0-Schlüsseldokumentation beweist weder Erhalt noch Verbot der alten Lösung. Halte den Weg offen, bis aktuelle Nachweise die Frage beantworten. ### Können wir einen ungenutzten Workflow auslassen? Du kannst ihn stilllegen. Dokumentiere die Entscheidung und deaktiviere seine möglichen Einstiegspunkte. Ein vergessener Zeitplan, Button oder Integrationsaufruf könnte sonst nicht abgenommene Arbeit reaktivieren. Soll der Workflow später zurückkehren, bleibt er außerhalb der freigegebenen Version und braucht vor der Aktivierung neue Nachweise. ### Deckt ein manueller Buttontest einen Zeitplan ab? Er deckt den ausgeübten Pfad ab. Zeitplanung kann andere Identitäten, Zeitpunkte, Datensatzauswahl oder Wiederholungen beinhalten. Halte gemeinsame Komponenten und offene Teile fest. Ein deaktivierter Zeitplan braucht eine eigene kontrollierte Prüfung oder die ausdrückliche Entscheidung zum manuellen Betrieb. Ein erfolgreicher Klick schließt diese Nachweislücke nicht. ### Wie lange bleibt die Abnahme gültig? Binde die Freigabe an dokumentierte Konfiguration und Umfang statt an eine unbegrenzte Gültigkeit. Änderungen an Anfrageweg, Anweisungen, Werkzeugen, Quellen, Berechtigungen oder Auslösern verlangen eine Wirkungsprüfung. Nutze weiter gültige Nachweise erneut, wiederhole betroffene Fälle und dokumentiere die neue Entscheidung. Abgenommen ist das tatsächlich geprüfte Verhalten. QA und Produktionsreife ## Weiterlesen Tests, Audits, Wartung und Härtung für verlässliche Produktionssoftware. [Hier starten**QA für KI-generierten Code**](/de/blog/qa-for-ai-generated-code/) - [README ZIP Schadsoftware: Was deckt deine Freigabe ab?](/de/blog/readme-zip-malware-install-review/) - [KI-generierte Odoo-Module: Geschäftsregeln im Audit prüfen](/de/blog/ai-generated-odoo-module-audit/) - [Odoo-Migration abnehmen: Datensätze und Salden abgleichen](/de/blog/odoo-migration-acceptance-reconciliation/) - [Odoo-KI-Agenten testen: gespeicherte Aktivitäten prüfen](/de/blog/odoo-ai-agent-business-state-tests/) - [Odoo-20-Rechtemigration: Gesellschaftstrennung prüfen](/de/blog/odoo-20-company-access-migration-tests/) [Vorheriger Artikel**Odoo-20-Rechtemigration: Gesellschaftstrennung prüfen**](/de/blog/odoo-20-company-access-migration-tests/) [Nächster Artikel**Odoo-Import mit KI: Lieferantenpreise richtig zuordnen**](/de/blog/odoo-ai-data-mapping-validation/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 Min. Lesezeit · 5. November 2026 Zuletzt geprüft 5. November 2026 [**Weiter**](/de/blog/odoo-helpdesk-ai-classify-draft-escalate/)