Hat Odoos native KI Berechtigungen und einen Audit-Trail?

Wir entwickeln Pinchy, eine self-hosted Governance-Schicht für KI-Agenten. Odoo ist die Integration, nach der wir am häufigsten gefragt werden. Wir sind hier also nicht neutral. Trotzdem haben wir jede Aussage belegt und fair gehalten. Hat Odoo eine dokumentierte Lücke, sagen wir es. Hat die Community schon eine Antwort, etwa die Module der OCA, verweisen wir darauf.

Ist Odoos native KI in der Community Edition verfügbar?

Nein. Wer in Odoo 19 KI-Agenten anlegen und anpassen will, braucht die AI-App. Und die gehört zur Enterprise-Edition. Die Community hat das selbst dokumentiert: Beim Forum-Thread „Community Edition v19 - AI Module missing“ sagt der Titel schon alles. KI-Agenten, KI-Felder in Studio und KI-Server-Aktionen stecken alle in der lizenzierten Edition.

Das ist wichtig, denn viele self-hosted Odoo-Installationen laufen auf der Community Edition. Diese Teams hinken bei KI nicht hinterher. Die native Funktion ist nur nichts für sie. Realistisch ist für sie eine offene KI-Schicht. Sie bindet Odoo über dessen Standard-API an und läuft in Ihrer eigenen Infrastruktur.

Lässt sich steuern, was ein Odoo-KI-Agent tun darf?

Diesen Punkt setzen die meisten als gelöst voraus. Deshalb lohnt sich Präzision. Odoos KI-Doku beschreibt, wie ein Agent Topics und Tools bekommt. Ein Beispiel ist „Create Leads“, ein anderes eine Suche, die per natürlicher Sprache die passende Ansicht öffnet. Ein Agent ohne Topics kann laut Doku „nur Informationen liefern, aber keine Aufgaben erledigen oder Änderungen an der Datenbank vornehmen“. Das ist eine echte, sinnvolle An-/Aus-Grenze.

Ein fein abgestuftes Berechtigungsmodell pro Agent beschreibt die Doku aber nicht. Es gibt keine Allow-List, die festlegt, welche Operationen ein Agent ausführen darf. Es gibt keine Trennung von Lesen und Schreiben pro Agent. Und es gibt keine eigene, eingeschränkte Identität für den Agenten. In der Praxis erbt der Agent die Rechte des Odoo-Benutzers, unter dem er läuft. Die Grenze ist also der Benutzer, nicht der Agent. Was der Benutzer in der Datenbank darf, kann auch der Agent.

Solange der Agent nur liest, reicht das. Sobald er Datensätze anlegt, ändert oder bestätigt, sieht es anders aus. Ein Agent ist kein Mensch, der eine Dienstanweisung befolgt. Er arbeitet mit Wahrscheinlichkeiten, und er liest dabei Inhalte, denen Sie nicht vertrauen: Dokumente, E-Mails, Chat-Nachrichten. Eine geschickt formulierte Eingabe kann ihn dazu bringen, seine Anweisungen zu ignorieren. Ein Prompt ist eine Leitlinie, keine Grenze. Die Odoo-Community weist selbst darauf hin: Die OCA-Diskussion „HELP WANTED: Odoo LLM agents are here!“ nennt Sicherheit, Zugriffskontrolle und Audit als das ungelöste Problem.

Protokolliert Odoo, was sein KI-Agent getan hat?

Nicht von Haus aus und nicht eigens für KI. Odoo zeigt Änderungen nur teilweise: Bestimmte nachverfolgte Felder schreiben ihre Änderung in den Chatter des Datensatzes. Ein durchgängiges, systemweites Protokoll aller Lese- und Schreibvorgänge gibt es aber nicht. Die Lücke ist im Ökosystem bekannt, denn die OCA pflegt dafür ein eigenes Audit-Log-Modul. Sie aktivieren eine Regel pro Modell, dann protokolliert es die Operationen. Eine geplante Aktion kann Logs löschen, die älter als sechs Monate sind, ist aber standardmäßig deaktiviert. Bis Sie sie einschalten, bleiben die Logs unbegrenzt erhalten. Das ist ein fairer, quelloffener Weg, in Odoo heute zu protokollieren.

Zwei Dinge folgen daraus. Erstens läuft das Logging nur dort, wo Sie es pro Modell einschalten. Vergessen Sie ein Modell, fehlt es im Log. Zweitens, und für KI entscheidend: Das OCA-Modul protokolliert die geänderte Datenbankzeile, nicht den Tool-Aufruf des Agenten und den Grund dahinter. „Auftrag 4123 wurde bestätigt“ steht im Zeilen-Log. Drei Wochen später, bei einem auffälligen Eintrag, brauchen Sie aber mehr. Nämlich: Der KI-Agent hat den Auftrag bestätigt, im Auftrag von Benutzer X, weil eine Kunden-Nachricht darum bat. Mit Zeitstempel. Agenten-Governance braucht den Audit-Trail auf Ebene der Agenten-Aktionen, nicht nur der Tabelle.

Ein fairer Direktvergleich

Diese Schichten ergänzen sich, sie konkurrieren nicht. Das OCA-Modul deckt die Protokollierung gut ab. Viele Odoo-Teams sollten es kennen.

Was „kontrollierte KI für Odoo“ tatsächlich braucht

Welches Werkzeug Sie auch wählen: Ein Setup, das an echte Geschäftsdaten darf, braucht denselben Aufbau. Nichts davon ist Odoo-spezifisch.

• Eng begrenzte Tools statt vollem API-Schlüssel. Der Agent bekommt nie den breiten Zugang. Er ruft eng umrissene, benannte Operationen auf, etwa „diesen Auftrag lesen“ oder „diese Ausgabe anlegen“. Jede ist ein definiertes Tool. Was nicht freigegeben ist, kann er nicht aufrufen, weil es als Tool nicht existiert.
• Standardmäßig verboten, pro Agent. Ein neuer Agent darf nichts, bis Sie ihm einzelne Tools freischalten. Ein Support-Agent, der Aufträge liest, bekommt nicht nebenbei auch das Tool, das Rechnungen bucht.
• Lesen und Schreiben sind getrennte Rechte. Viele nützliche Odoo-Agenten müssen nur lesen. Machen Sie „darf nachsehen“ und „darf ändern“ zu getrennten Entscheidungen, denn das Risiko ist nicht dasselbe.
• Menschliche Freigabe für das Unumkehrbare. Bei kritischen Schreibvorgängen bereitet der Agent die Aktion vor, und ein Mensch gibt sie frei, bevor sie greift. Das klassische Beispiel ist der abfotografierte Beleg. Der Agent liest die Daten aus und legt den Datensatz an. Doch bevor er in die Bücher geht, zeichnet ein Mensch ab.
• Ein Audit-Trail der Agenten-Aufrufe. Welche Operation, in wessen Auftrag, mit welchen Eingaben, mit welcher Antwort. Pro Tool-Aufruf erfasst und idealerweise manipulationssichtbar, damit Sie einen falschen Eintrag rekonstruieren können statt zu raten.

So setzt Pinchy das um

Dieser Abschnitt beschreibt unser eigenes Produkt. Pinchy erreicht Odoo über dessen Standard-Schnittstelle, die externe API per JSON-RPC. Selbst gehostetes Odoo stellt sie auf jeder Edition bereit, Community wie Enterprise. Auf Odoos eigenem SaaS (Odoo Online) gehört sie zum Custom-Plan, nicht zum Standard- oder One-App-Free-Plan. Jede Odoo-Funktion ist ein eng begrenztes Tool. Ein Admin gibt es pro Agent auf einer Allow-List frei, standardmäßig ist alles verboten. Lesen und Schreiben sind getrennte Rechte. Kritische Aktionen wie das Bestätigen eines Auftrags oder das Validieren einer Lieferung sind eigene, freigabe-pflichtige Tools, kein pauschaler Schreibzugriff. Und jeder Tool-Aufruf landet in einem manipulationssichtbaren, HMAC-signierten Audit-Trail. Pinchy ist AGPL-3.0-lizenziert und läuft in Ihrer eigenen Infrastruktur. Odoo-Admins nutzen dafür das kostenlose Pinchy-Connector-Modul. Es liegt im Odoo App Store für die Versionen 17, 18 und 19. Die Verbindung stellen Sie damit direkt aus Odoos Einstellungen her.

Das ist nicht der einzige Weg. Das OCA-Modul oben ist eine faire Option für die Protokollierung, und Governance lässt sich auch selbst zusammenbauen. Wir nennen Pinchy, weil es genau für diese Lücke gebaut wurde. Und weil es Open Source ist, können Sie nachlesen, wie: github.com/heypinchy/pinchy.

Die ehrliche Grenze

Governance begrenzt den Schaden und macht ihn überprüfbar. Sie macht das Modell nicht fehlerfrei. Ein Agent kann auch im Entwurf die falsche Ausgabenkategorie vorschlagen. Berechtigungen sorgen nur dafür, dass ein Mensch ihn zuerst sieht und dass er die Lohnbuchhaltung nie hätte anfassen können. Das sind zwei verschiedene Probleme. Wer sie verwechselt, verbrennt sich die Finger. Was Sie heute festlegen können, ist die Grenze: Geben Sie einem Odoo-Agenten nie einen vollen, ungefilterten Zugang. Geben Sie ihm eng umrissene, freigegebene Tools. Verlangen Sie eine Freigabe für die Schreibvorgänge, auf die es ankommt. Und protokollieren Sie alles, was er tut.