In diesem Beitrag
Odoo-KI und Datenresidenz: Deckt EU-Hosting auch die Inferenz ab?
Das Beschaffungsformular fragt, wo Kundendaten verarbeitet werden. Deine Odoo-Datenbank liegt in der gewünschten Region, also scheint der Hosting-Punkt erledigt. Dann wird eine KI-Funktion aktiviert, die Informationen aus Datensätzen verwendet. Dafür brauchst du eigene Belege, bevor jemand das Formular unterschreibt.
Eine Datenbankregion innerhalb der EU belegt allein nicht, wo ein Odoo-KI-Ablauf seine Daten verarbeitet. Gib die konkrete Funktion erst frei, wenn ihr ihren konfigurierten Weg, Inhalte, Inferenz, Protokolle, Aufbewahrung und Supportzugriffe mit der tatsächlichen Standortanforderung abgeglichen habt. Jeder offene Schritt braucht einen Belegverweis und eine verantwortliche Person.
Quellenstand: 5. November 2026. Wir haben die aktuelle IAP-Richtlinie und die offizielle Hosting-Dokumentation geprüft. Die vorgeschlagene Checkliste und der synthetische Datensatz unterstützen die folgenden Beispielszenarien. Wir haben weder eine Kundeninstanz untersucht noch Odoo-Datenverkehr aufgezeichnet oder Rechtskonformität festgestellt.
Was belegen die aktuellen Odoo-Quellen?
Die Quellen beantworten zwei getrennte Fragen: Wo liegt die Datenbank, und wo kann ein konfigurierter KI-Vorgang ausgeführt werden? Bewahre Quelle und Geltungsbereich jeder Antwort auf. Eine bestätigte Hosting-Region darf nicht stillschweigend zur Zusage für einen anderen Dienst, ein abgerufenes Dokument, ein externes Werkzeug oder ein Diagnoseprotokoll werden.
Die IAP-Richtlinie von Odoo nennt für Ask AI/AI Agents globale Inferenz und ab v20 eine automatische Anbieterauswahl. Prompts, Kontext und abgerufene Inhalte können an Anbieter übermittelt werden.
Die Hosting-Anleitung fragt separat nach der gewünschten Datenbankregion. Daraus leiten wir für die Architektur ab: Die Grenzen sind verschieden. Für eine verbindliche Verarbeitung ausschließlich in der EU reicht der Nachweis der Datenbankregion nicht aus.
Beschaffe die aktuellen Hosting- und Backup-Zusagen, die für deine Datenbank gelten. Halte fest, welche Speicher und Kopien erfasst sind. Prüfe Zugriffsregelungen getrennt von der KI-Verarbeitung. Eine öffentliche Richtlinie beschreibt einen Dienst, aber nicht jede Konfiguration deiner Instanz.
Welche Standortanforderung musst du erfüllen?
Formuliere die Anforderung so, dass jemand sie prüfen und freigeben kann. Bestimme, welche Vorgänge welche Datenklasse verwenden und wo sie erlaubt sind. Eine Vorgabe nur für den primären Datenbankspeicher unterscheidet sich von einer Vorgabe für KI-Anfragen, Anhänge, Protokolle, Backups und Support. Die freigebende Person muss den Geltungsbereich festlegen.
| Aussage | Offene Frage | Benötigter Beleg |
|---|---|---|
| „Unsere Datenbank muss in der EU liegen.“ | Gilt das auch für Sicherungskopien und KI-Verarbeitung? | Hosting-Umfang und ausdrückliche Entscheidungen für andere Wege |
| „Diese Kundendaten dürfen nur in der EU verarbeitet werden.“ | Welche Felder und abgeleiteten Inhalte fallen darunter? | Verarbeitungszusage für den konkreten Weg und Kontextinventar |
| „Kein Anbieter darf diese Inhalte zum Training verwenden.“ | Welche eigenständigen Vorgaben gelten für Ort und Aufbewahrung? | Jede Zusage separat dokumentieren |
| „Der Pilot darf nur öffentliche Inhalte nutzen.“ | Kann die Funktion private Kontextdaten oder Werkzeuge hinzufügen? | Konfigurationsprüfung und synthetische Kontextprüfung |
Das sind erfundene Beispiele, keine Rechtsregeln. Stammt die Vorgabe aus einem Kundenvertrag, dokumentiere die Klausel und die zuständige Person für ihre Auslegung. Bei einer internen Risikoentscheidung benennst du die datenverantwortliche Person. Das Umsetzungsteam braucht eine Anforderung, deren Bedeutung nicht erst bei der Freigabe wechselt.
Allgemeine Unterschiede zwischen Anbietern und Endpunkten behandelt unser Leitfaden zur EU-Datenresidenz bei KI-APIs. Hier geht es um die Nachweise für eine bestimmte Odoo-Funktion, nicht um ein weiteres Anbieterverzeichnis.
Was gehört in die Belegübersicht des Datenwegs?
Beginne bei der konkreten Funktion und liste jeden Schritt auf, der eingeschränkte Daten verarbeitet. Mögliche Schritte bleiben ungeprüft, bis ihre Existenz geklärt ist. Trenne bei bestätigten Schritten die Belege für Speicherung, Verarbeitung, Aufbewahrung und Zugriff. Datum und Konfiguration gehören dazu, damit spätere Änderungen bewertet werden können.
| Schritt, falls vorhanden | Zu klären | Nützliche Belege |
|---|---|---|
| Odoo-Quelldatensatz | Ausgewählte Felder und Anhänge im freigegebenen Nutzerumfang | Funktionskonfiguration und synthetischer Eingabedatensatz |
| Prompt-Zusammenstellung | Anweisung, Verlauf und hinzugefügte Datensatzfelder | Autorisierte Nutzlastprüfung oder dokumentiertes Verhalten |
| Orchestrierungsdienst | Betreiber des Anfragewegs und gespeicherte Zwischenzustände | Geltende Dienstbedingungen und Konfigurationsverweis |
| Modellinferenz | Dienst und Standortzusage für diesen Weg | Aktuelle Anbieter- oder Vertragsbelege |
| Abruf oder externes Werkzeug | Gesendete Daten, Ziel und Rückgabe | Werkzeugfreigaben und beobachteter Testaufruf |
| Protokolle, Exporte und Backups | Über den unmittelbaren Vorgang hinaus kopierte Inhalte | Protokollierungs- und Aufbewahrungseinstellungen sowie Hosting-Belege |
| Supportzugriff | Wer Inhalte über welchen Weg einsehen kann | Zugriffsverfahren und geltende Zusagen |
Lade die Checkliste für Standortbelege herunter. Sie beginnt absichtlich mit ungeprüften Zeilen und offenen Zuständigkeiten. Markiere nachweislich nicht vorhandene Schritte als nicht anwendbar und bewahre die Begründung auf. Ergänze fehlende Schritte und Belege. Eine ausgefüllte Zeile soll eine Entscheidung erklären, nicht nur einen beruhigenden Ländernamen nennen.
Unterscheide Beobachtung und Anbieterzusage. Ein Anfrageziel oder eine IP-Adresse hilft bei der Identifikation eines Dienstes, belegt aber nicht allein den physischen Ort jeder Inferenz. Umgekehrt muss eine vertragliche Standortzusage auf genau die aktivierte Konfiguration anwendbar sein.
Wie prüfst du Kontext ohne echte Kundendaten?
Verwende einen synthetischen Datensatz mit unterscheidbaren Werten sowohl in vorgesehenen als auch in ausgeschlossenen Feldern. Führe die autorisierte Prüfung in einer geeigneten Testumgebung durch. Vergleiche sichtbare Belege mit dem erwarteten Kontext und dokumentiere Beobachtungsgrenzen. Fehlende Protokolle beweisen nicht, dass ein Datenweg nicht existiert.
Der herunterladbare synthetische Kontext-Testdatensatz beschreibt ein erfundenes Angebot. Er enthält Produkt, Menge, eine Adresse unter example.invalid sowie eindeutige Markierungen in einer internen Notiz und einem Anhangsfeld. Für die gewünschte Ausgabe werden nur Produkt und Menge benötigt. Die Datei ist eine vorgeschlagene Testeingabe, kein Odoo-Importmodul.
- Halte Funktion, Version, konfigurierte Quellen, Werkzeuge und Nutzerrechte fest.
- Definiere vor dem Aufruf, welche synthetischen Felder die Aufgabe benötigt.
- Prüfe Kontext und Werkzeuganfragen mit den autorisierten Beobachtungsmöglichkeiten des Wegs.
- Dokumentiere unerwartete Felder, fehlende Einsicht und Belegverweise.
- Prüfe die Standortzusage unabhängig vom Ergebnis der Kontextprüfung.
Eine ausgegebene Testmarkierung kann einen unerwarteten Weg aufdecken. Fehlt sie in der Ausgabe, beweist das nicht, dass das Feld nie gesendet wurde. Deshalb kombiniert die vorgeschlagene Prüfung Konfiguration, verfügbare Aufzeichnungen und geltende Zusagen. Ein einzelner Screenshot zertifiziert keinen vollständigen Datenweg.
Wann kann die Funktion starten, eingeschränkt werden oder muss warten?
Entscheide pro Funktion und Datenklasse. Eine verbindliche Standortvorgabe braucht passende Belege, bevor eingeschränkte Inhalte in den Weg gelangen. Kann der Geschäftsprozess mit weniger Daten arbeiten, bewerte diesen reduzierten Umfang ausdrücklich. Ist eine entscheidende Tatsache offen, weise ihre Klärung zu, statt die gesamte Anwendung pauschal freizugeben.
| Szenario | Beleglage | Vorgeschlagene Entscheidung |
|---|---|---|
| Pilot für öffentliche Produkttexte | Öffentliche Eingaben erlaubt; ergänzter Kontext und Werkzeuge noch zu prüfen | Nach bestätigtem Umfang einen begrenzten Piloten erwägen |
| Zusammenfassung eingeschränkter Kundendokumente | EU-Verarbeitung vorgeschrieben, Wegzusage fehlt oder widerspricht ihr | Datenklasse ausschließen, bis ein unterstützter Weg belegt ist |
| Freigegebener Weg erhält ein Abrufwerkzeug | Neue Quelle und neues Ziel waren nicht Teil der Prüfung | Geänderten Weg prüfen, bevor die Freigabe erweitert wird |
Eine enge Entscheidung lässt sich besser pflegen. „Produktbeschreibungen mit diesen Feldern und Werkzeugen“ benennt einen überprüfbaren Umfang. Bei „Odoo ist konform“ bleibt offen, welche Version, Funktion, Daten und Anforderung jemand beurteilt hat.
Löst ein anderer technischer Weg die Standortfrage?
Eine Alternative hilft nur, wenn der gesamte konfigurierte Weg die Vorgabe erfüllt. Bewerte Modell, Orchestrierung, Werkzeuge, Protokolle, Backups und Zugriffe gemeinsam. Ein anderer Datenbankhost, ein als europäisch bezeichneter Endpunkt oder ein entfernter Anbietername belegt nicht automatisch das Verhalten aller übrigen Schritte.
Das ist eine Architekturprüfung, keine Aussage, dass eine bestimmte Odoo-Edition beliebige Ersatzlösungen unterstützt. Kläre zuerst die unterstützte Verbindung und Betriebsverantwortung. Die Plattformgrenze behandelt der Leitfaden zu Odoo-API-Integrationsgrenzen. Die Beschaffungsfolgen behandelt das KI-Budget für geprüfte Angebote.
Stelle dieselben Belegfragen bei einem selbst betriebenen Vorschlag. Eine interne Datenbank ist nur eine Komponente; externe Inferenz, Abrufe oder Supportwege brauchen weiterhin eigene Entscheidungen. Lässt sich die Vorgabe innerhalb des unterstützten Entwurfs und Budgets nicht erfüllen, bleibt der betroffene Schritt während der Alternativenprüfung manuell.
Was würden wir zuerst nachweisen?
Wähle eine Funktion und Datenklasse, schreibe die tatsächliche Standortanforderung auf und ergänze die Belegübersicht mit Zuständigen. Kläre zuerst die Tatsache, die die Freigabe verändern könnte. Andere Datenklassen bleiben außerhalb des Piloten, bis ihre Wege abgedeckt sind. Wesentliche Konfigurationsänderungen öffnen die Prüfung erneut.
Übernimm die Dokumentation in die Vorbereitung des Odoo-KI-Upgrades. Braucht die Vorgabe einen anderen Weg, hilft der Vergleich von Standardfunktion und Individualsoftware. Die Twinsoft-AI-Fallstudie liefert Projektkontext, keine Zertifizierung der Datenresidenz.
Wavects KI-Sicherheitsberatung unterstützt die Prüfung. Besprich deinen Odoo-KI-Datenfluss anhand der Anforderung und der Funktion, die die betroffenen Daten verarbeiten soll.