Als wir begannen, unseren KI-Bot Unternehmenskunden vorzustellen, war die erste Frage immer dieselbe: Was passiert, wenn er unsere Daten veraendert? Das ist eine berechtigte Sorge. Sie haben eine produktive Odoo-Instanz, die Ihr gesamtes Geschaeft abwickelt - Vertrieb, Lagerverwaltung, Buchhaltung, Personalwesen. Einem KI-Tool Zugriff auf dieses System zu geben, klingt riskant. Deshalb haben wir die Architektur so konzipiert, dass es dem Bot physisch unmoeglich ist, etwas zu schreiben, zu aendern oder zu loeschen.
Die Grundlage ist einfach: Der Bot verbindet sich mit Odoo ueber XML-RPC unter Verwendung eines dedizierten Dienstkontos, das ausschliesslich Nur-Lese-Berechtigungen hat. Dies ist kein Software-Schalter, den wir versehentlich umschalten koennten. Der dem Bot zugewiesene Odoo-Benutzer hat benutzerdefinierte Zugriffsrechte auf Modellebene - Lesezugriff auf die vom Kunden genehmigten Modelle, keinerlei Schreib-/Erstell-/Loeschberechtigungen. Selbst wenn unser Code einen Fehler haette, der einen Schreibvorgang versucht, wuerde Odoos eigene Zugriffssteuerungsebene ihn mit einem AccessError ablehnen.
Wir sind ueber die reinen Odoo-Berechtigungen hinausgegangen. Die Integrationsschicht des Bots hat ueberhaupt keine Schreibmethoden implementiert. Der von uns erstellte XML-RPC-Client stellt nur search_read, fields_get und read-Operationen bereit. Es gibt keinen execute_kw-Aufruf fuer create, write oder unlink in der gesamten Codebasis. Das ist Verteidigung in der Tiefe - selbst wenn jemand unsere Anwendungsschicht kompromittieren wuerde, existieren die Werkzeuge zur Datenaenderung schlichtweg nicht im bereitgestellten Code.
Die Speicherung von Anmeldedaten war eine weitere kritische Entscheidung. Alle Odoo-Verbindungsdetails jedes Kunden - URL, Datenbankname, API-Schluessel - werden im Ruhezustand mit AES-256-GCM verschluesselt. Die Verschluesselungsschluessel werden getrennt von den verschluesselten Daten gespeichert, gemaess dem Envelope-Encryption-Muster. Wir verwenden einen einzigartigen Initialisierungsvektor fuer jeden Verschluesselungsvorgang, was bedeutet, dass selbst identische Anmeldedaten fuer zwei Kunden voellig unterschiedliche Chiffretexte erzeugen.
Die API-Schluessel selbst verdienen Aufmerksamkeit. Wir verwenden Odoos integriertes API-Schluessel-System anstatt Passwoerter zu speichern. API-Schluessel koennen vom Kunden sofort ueber sein Odoo-Adminpanel widerrufen werden, ohne uns einbeziehen zu muessen. Wenn ein Kunde den Bot-Zugriff sperren moechte, loescht er den API-Schluessel und er funktioniert sofort nicht mehr. Kein Ticket, kein Warten, keine Abhaengigkeit von uns.
Daten waehrend der Uebertragung werden durch TLS 1.3 fuer alle Verbindungen zwischen unserem Bot-Server und den Odoo-Instanzen der Kunden geschuetzt. Wir erzwingen Zertifikatsvalidierung - kein Ueberspringen von SSL-Pruefungen, auch nicht fuer die Entwicklung. Der Bot-Server selbst laeuft auf einem isolierten Hetzner VPS mit minimaler Angriffsflaeche: keine unnoetig offenen Ports, ausschliesslich SSH-Schluessel-Authentifizierung, automatische Sicherheitsupdates.
Eine Frage, die wir von IT-Teams erhalten, ist, ob Kundendaten zum Training von KI-Modellen verwendet werden. Die Antwort ist nein, und die Architektur erzwingt dies. Wenn ein Benutzer dem Bot eine Frage stellt, fragen wir das Odoo des Kunden nach den relevanten Daten ab, formatieren sie in einen Prompt, senden ihn an Claudes API und geben die Antwort zurueck. Wir speichern keine Abfrageergebnisse ueber die Konversationssitzung hinaus. Wir sammeln keine Daten fuer Training. Die API-Bedingungen von Claude besagen ausdruecklich, dass API-Eingaben und -Ausgaben nicht fuer das Modelltraining verwendet werden.
Der Konversationsverlauf selbst wird in unserer Datenbank mit derselben AES-256-GCM-Verschluesselung gespeichert, die fuer Anmeldedaten verwendet wird. Konversationen sind an einzelne Telegram-Benutzer gebunden und werden nach 30 Tagen automatisch geloescht. Ein Kunde kann die sofortige Loeschung aller seiner Konversationsdaten anfordern, und wir koennen dies innerhalb von Minuten ausfuehren.
Odoos Datensatzregeln fuegen eine weitere Schutzebene hinzu, die die meisten Leute uebersehen. Selbst mit Lesezugriff koennen Datensatzregeln einschraenken, welche Datensaetze der Bot-Benutzer sehen kann. Ein Kunde kann sein Odoo so konfigurieren, dass der Bot nur Datensaetze bestimmter Unternehmen in einem Multi-Company-Setup sieht, oder nur genehmigte/veroeffentlichte Produkte, oder nur bestimmte Mitarbeiterkategorien. Der Bot erbt alle diese Einschraenkungen automatisch, weil er als regulaerer Odoo-Benutzer agiert.
Wir haben auch Ratenbegrenzung auf mehreren Ebenen implementiert. Der Bot begrenzt Abfragen pro Benutzer pro Minute, um Missbrauch zu verhindern. Er begrenzt die Gesamtabfragen pro Kundenorganisation pro Stunde, um unkontrollierte Kosten zu vermeiden. Und er hat ein globales Ratenlimit zum Schutz unserer Infrastruktur. Wenn ein Limit erreicht wird, antwortet der Bot mit einer hoeflichen Nachricht und der Benutzer kann es kurz darauf erneut versuchen.
Fuer Kunden in regulierten Branchen stellen wir eine detaillierte Antwort auf Sicherheitsfrageboegen bereit und koennen eine Pruefung unserer Codebasis durch ihr Sicherheitsteam arrangieren. Wir haben dies bisher dreimal gemacht, und jede Pruefung bestaetigte, dass die Nur-Lese-Architektur echt ist, nicht nur Marketing. Ein Pruefer bemerkte ausdruecklich, dass das Fehlen von Schreibmethoden in der Codebasis ungewoehnlich sei - die meisten Systeme implementieren Schreibmethoden und versuchen dann, sie auf Berechtigungsebene zu blockieren, was von Natur aus weniger sicher ist.
Das praktische Ergebnis von all dem ist, dass unser Bot ueber 10.000 Abfragen ueber Odoo-Instanzen von Kunden verarbeitet hat, ohne einen einzigen Datenvorfall. Keine versehentlichen Schreibvorgaenge, keine Datenlecks, kein unautorisierter Zugriff. Die Nur-Lese-Architektur ist nicht nur ein Sicherheitsmerkmal - sie ist das zentrale Designprinzip des Produkts, das die Einfuehrung im Unternehmensbereich ermoeglicht.