KI-Agenten für Odoo: wie sie sich anbinden und unter Kontrolle bleiben.

Ein KI-Agent für Odoo ist ein Assistent, der Odoo-Datensätze in Ihrem Auftrag liest und schreibt. Er übersetzt Ihre Anfrage in normaler Sprache in die passenden API-Aufrufe. Der Reiz liegt auf der Hand: ERP-Arbeit ohne ERP-Masken. Ob daraus Komfort wird oder Risiko, entscheidet der Umfang der Rechte. Und der ist eher eine Frage der Governance als der Anbindung.

Wir entwickeln Pinchy, eine selbst-gehostete Plattform für KI-Agenten mit einer kontrollierten Odoo-Anbindung, und führen unsere eigene Buchhaltung darüber. Wir sind hier also nicht neutral. Die Mechanik unten gilt für jede Verbindung zwischen Agent und Odoo. Den Governance-Teil überspringen die meisten Leitfäden.

Wie sich ein KI-Agent mit Odoo verbindet

Odoo stellt seine Daten über eine External API bereit. Historisch sind das XML-RPC und JSON-RPC. Odoo 19 ergänzt eine REST-artige JSON-2-API als langfristigen Nachfolger. Die älteren Endpunkte XML-RPC und JSON-RPC sollen in späteren Releases entfallen, die Richtung heißt also JSON-2. Alle rufen dieselben ORM-Methoden auf. Damit sind die Fähigkeiten identisch, nur der Transport unterscheidet sich. Ein Agent kann über jeden dieser Wege Datensätze anlegen, lesen, ändern und löschen.

Wichtig: Das ist die dokumentierte, öffentliche Schnittstelle. Der Agent ist nur ein weiterer API-Client. Er verändert Odoo nicht, installiert nichts hinein und braucht kein Enterprise. Die External API ist in Community und Enterprise dieselbe, deshalb verhält sich ein angebundener Agent in beiden gleich. Seine Aufgabe: aus einer Frage wie dem letzten Quartalsumsatz von Acme die richtige Abfrage formulieren. Und aus der Anweisung, einen Beleg auf Büromaterial zu buchen, den richtigen Schreibvorgang.

Was ein Agent tatsächlich kann

Weil die External API bis zum ORM reicht, arbeitet ein Agent im ganzen System: CRM, Buchhaltung, Lager, Personal und der Rest. In der Praxis sieht das so aus:

• Lesen: einen Kunden finden, den Bestand eines Produkts prüfen, die offenen Rechnungen eines Kunden abrufen, den Umsatz des Vormonats zusammenfassen.
• Anlegen: einen Auftrag entwerfen, eine Ausgabe erfassen, einen Kontakt hinzufügen, ein Helpdesk-Ticket öffnen.
• Ändern: Felder eines Datensatzes anpassen, eine Verkaufschance verschieben, eine Buchungszeile abstimmen.

Für die meisten Teams gibt ein Muster den Ausschlag: Es macht aus einem Beleg eine Buchung. Sie fotografieren einen Lieferantenbeleg und legen ihn in den Chat, dann liest der Agent Betrag und Lieferant aus. Ist das Konto unklar, fragt er nach und bucht den Vorgang danach in Odoo mit den richtigen Feldern. Die ERP-Arbeit erledigt sich, ohne dass Sie eine Odoo-Maske öffnen. Genau dieses Beispiel führt auch unsere eigene Buchhaltung.

Das Risiko, das im Komfort steckt

Diesen Haken lassen die Demos aus. Die External API kennt keinen Modus, der nur die sicheren Teile freigibt. Sie legt das ORM offen, und das ORM liest und schreibt über die gesamte Datenbank. Ein Agent mit vollem API-Zugriff kann im Prinzip jeden Kundendatensatz lesen, jede Rechnung ändern oder Daten löschen. Nicht aus Bosheit, sondern weil die Schnittstelle die eine nötige Operation nicht von den tausend unnötigen trennt.

Dazu kommt: Ein Agent lässt sich durch die Inhalte steuern, die er verarbeitet, etwa durch eine Prompt Injection, versteckt in einem Dokument oder einer E-Mail. Die ungebremste Variante dieser Anbindung wird damit zur echten Gefahr. Der Beleg, den Sie hochladen, könnte im schlimmsten Fall eine versteckte Anweisung enthalten. Diese führt der Agent dann gegen Ihre übrigen Daten aus. Die Lösung ist nicht, dem Feature zu misstrauen, sondern dem Agenten diesen Zugriff nie zu geben.

Einen Odoo-Agenten unter Kontrolle halten

Alles, was Agent-Governance allgemein ausmacht, gilt hier verschärft, weil ein ERP so viel enthält. Konkret:

• Operationen freigeben, nicht die ganze API. Geben Sie dem Agenten eng umrissene, zweckgebundene Fähigkeiten. Eine Operation zum Lesen von Aufträgen oder zum Anlegen einer Ausgabe etwa, statt eines generischen Werkzeugs für beliebige ORM-Methoden. Der Agent soll keine Operation erfinden können, die Sie nicht definiert haben.
• Standard-Verbot. Der Agent startet ohne jeden Odoo-Zugriff, und Sie geben jede Operation einzeln frei, begrenzt auf ihre Aufgabe. Ein Agent fürs Belegbuchen braucht Schreibrechte für Ausgaben, nicht den Lesezugriff auf die Lohnabrechnung.
• Jeden Schreibvorgang protokollieren. Jedes Anlegen und Ändern in Odoo landet in einem manipulationssichtbaren Audit-Trail. So lässt sich jede Änderung darauf zurückführen, wer sie angefragt hat und was geschah.
• Beide Seiten selbst betreiben. Laufen Odoo und Agent in Ihrer eigenen Infrastruktur, bleiben alle Daten, die der Agent verarbeitet, dort. Für ein ERP, das Kunden, Finanzen und Personen enthält, ist dieser Datenstandort kein nettes Extra, sondern Pflicht.

Das ist dasselbe Vier-Schichten-Modell aus dem allgemeinen Leitfaden zur Agent-Governance, angewandt auf das System, das in Ihrem Unternehmen am meisten zu verlieren hat.

Wie Pinchy es macht

Dieser Teil betrifft unser eigenes Produkt. Pinchy verbindet sich mit Odoo über dessen JSON-RPC-External-API und stellt Odoo-Arbeit als eng begrenzte Operationen bereit. Jede Operation läuft durch die Allow-List des Agenten, die standardmäßig alles verbietet. So besitzt ein Agent nur die Odoo-Fähigkeiten, die Sie ihm gegeben haben, und keine weiteren. Jede Aktion in Odoo schreibt Pinchy in einen pro Zeile signierten Audit-Trail. Sie installieren die Anbindung als kleines, kostenloses Modul aus dem Odoo App Store, und die Plattform ist selbst-gehostet. Ein selbst-gehostetes Odoo und ein selbst-gehostetes Pinchy halten Ihre ERP-Daten durchgehend auf Ihren eigenen Servern. Die Abläufe oben, normale Sprache und Beleg-zu-Buchung, setzen wir selbst ein. Das ist keine Theorie, sondern unser Alltag. Die ausführliche Produkt-Tour finden Sie auf der Seite Odoo-KI-Agenten.