EU-souveränes AI-Routing im Automotive-Engineering: Datenresidenz und Isolation by Construction

EU-souveränes AI-Routing: Datenresidenz und Mandantentrennung by Construction

Sobald AI auf Engineering-Daten trifft, wird Datenresidenz zur harten Anforderung. Wo läuft die Inferenz? Wer sieht welche Inhalte? Und wie wird das belegt? Im Automotive ist das kein Nice-to-have. Es ist die Voraussetzung für OEM-Fähigkeit und TISAX.

Souveränität entsteht nicht durch ein Label auf einer Folie. Sie entsteht durch eine Architektur, die den Datenfluss erzwingt. Der Kern ist ein selbst betriebener EU-Gateway. Er authentifiziert jeden Aufruf, routet ihn, isoliert pro Kunde und protokolliert metadaten-basiert.

Isolation wird nicht zugesichert. Sie wird im Code erzwungen.

Damit stehen für Sie als Verantwortliche im Engineering konkrete Fragen im Raum:

• Wie bleibt sensible Inferenz sicher in einer EU-Region?
• Wie trennen wir Kunden und Mandanten sauber voneinander?
• Wie belegen wir den Datenfluss auditierbar, ohne Inhalte zu protokollieren?
• Wie senken wir zugleich die Token-Kosten, ohne Kontrolle abzugeben?

Dieser Beitrag zeigt, wie ein EU-gebundenes Routing aufgebaut ist. Und warum ein metadaten-basiertes Audit Nachvollziehbarkeit schafft, ohne Inhalte mitzuschreiben.

Datenresidenz ist im Automotive kein Sonderfall

In vielen Branchen ist die Frage nach dem Ort der Inferenz ein Detail. Im Automotive-Engineering ist sie eine Eingangsbedingung. Entwicklungsdaten unterliegen Geheimhaltung gegenüber OEMs. Dazu kommt die Nachweispflicht aus TISAX. Das gilt für Anforderungen, Schaltpläne, Testdaten und Diagnose-Traces.

Ein Aufruf, der solche Daten unkontrolliert in eine fremde Jurisdiktion trägt, ist mehr als ein Risiko. Er ist ein möglicher Vertragsbruch. Deshalb genügt es nicht, Souveränität zu behaupten. Sie muss sich beschreiben und belegen lassen. Welcher Pfad, welche Region, welcher Anbieter, welche Trennung.

Der EU-Gateway als zentraler Kontrollpunkt

Ein Weg, viele Modelle, ein Audit

Der EU-Gateway ist der einzige Weg, über den Modell-Aufrufe laufen. Er ist OpenAI-kompatibel und selbst betrieben. Der Ablauf ist eindeutig. Der Client sendet einen Aufruf mit einem Virtual Key. Der Gateway prüft Key und Anbieter-Whitelist. Dann geht der Aufruf an einen Provider in einer EU-Region. Am Ende steht das Audit-Logging.

Ein einziger Kontrollpunkt bedeutet Klarheit. Es gibt einen Ort für Rechte. Einen Ort für Kosten. Und einen Ort für den Nachweis. So lässt sich der Datenfluss gegenüber einem Assessor beschreiben und belegen.

Isolation by Construction

Mandantentrennung wird nicht organisatorisch zugesichert. Sie wird technisch erzwungen. Ein Kunden-Key, der ein nicht-konformes Ziel ansteuert, wird im Code abgelehnt. Nicht per Konfiguration, die jemand versehentlich ändert.

• 401 bei fehlendem oder ungültigem Key.
• 403 bei Kunden-Key und nicht-konformem Ziel. Hart im Code verankert.
• 200 nur bei EU-konformem Pfad.

Auf App-Ebene setzt sich das fort. PostgreSQL mit Row-Level-Security trennt Mandanten und Rollen. Isolation ist damit eine Eigenschaft des Systems, keine Betriebsversprechung.

Audit ohne Inhalts-Logging

Das Audit ist bewusst metadaten-basiert. Nachvollziehbar bleibt, wer wann welchen Pfad genutzt hat. Die Inhalte selbst werden nicht protokolliert. Für Engineering-Daten mit Schutzbedarf ist das entscheidend. Sonst entsteht aus der Kontrolle ein neues Datenrisiko.

Transparenz kommt trotzdem nicht zu kurz. Ein wöchentlicher Audit- und Spend-Report je Mandant zeigt Nutzung und Kosten. Ein eigenes Caching-Layer senkt die Token-Kosten. Die Kontrolle über den Datenfluss bleibt dabei erhalten. So bleibt Souveränität wirtschaftlich.

Wie das Routing in die Compliance-Kette passt

EU-Datenresidenz ist einer von mehreren Bausteinen. Sie sind ab Tag eins Default. Das Routing greift in eine breitere Architektur.

• EU-Region-Pinning sensibler Inferenz und eine harte Anbieter-Whitelist.
• ISO 21434. Pipeline-Sicherheit als Default über den Lifecycle.
• EU AI Act. Transparenz für AI-augmentierte Schritte als Grundhaltung.
• TISAX. Begleitung entlang der Validierungskette bis zur OEM-Fähigkeit.

Häufige Fehler beim souveränen Routing

• Souveränität per Label. Eine EU-Region auf der Folie, aber kein erzwungener Pfad im Code.
• Inhalts-Logging aus Bequemlichkeit. Volle Prompt-Protokolle werden zum neuen Datenrisiko.
• Konfigurierbare Isolation. Eine Trennung, die per Flag aufweichbar ist, statt hart im Code.

Der gemeinsame Nenner ist immer derselbe. Souveränität muss belegbar sein, nicht behauptet.

So gehen wir vor: Build, Operate, Transfer

Ein EU-souveränes AI-Routing bauen wir nicht als Folienkonzept. Wir bauen es als produktive Fähigkeit. Das folgt dem Prinzip Build, Operate, Transfer. Unsere Beteiligung nimmt über die Phasen ab. Ihre Capability wächst ins eigene Haus. Der Wissenstransfer ist vertragliches Erfolgskriterium, kein Zusatz. Sonst entsteht genau der Lock-in, den wir vermeiden wollen.

1. Build. Setup, Guardrails und erste Workflows entlang Ihres realen Prozesses.
2. Operate. Betrieb mit KPI-Verantwortung auf Wertstrom-Ebene. Nie auf Personen-Telemetrie.
3. Transfer. Dokumentierte Übergabe. Ihr Team übernimmt Tooling, Wissen und Betrieb.

Getragen wird das von drei Modulen. Erstens ein Strategic Engineering Lead. Das ist ein Senior-Embedded-Architekt zusammen mit einem Strategic AI Lead. Zweitens die auditierbare Tooling-Plane sensified AI-OS. Drittens die Automotive-Playbooks. Sie beschreiben die Methodik für AI in Embedded-, ASIL-, ASPICE- und AUTOSAR-Kontexten. Die Leitplanke, was AI nicht entscheidet, ist darin fest verankert.

Die vier Mandat-Typen sind kombinierbar. Sie passen sich Ihrem Reifegrad an. Es gibt den Strategic Engineering Lead für den breiten Aufbau. Es gibt die BOT Engineering-Capability als Programm-Paket je Domäne. Es gibt den ASPICE- oder ASIL-Workflow-Pilot zur Validierung vor dem Mandat. Und es gibt das Modul Tooling, MCP und AI-Governance mit Schlüssel-Isolation und Kosten-Transparenz. Der Einstieg ist bewusst risikoarm. Zuerst ein Qualifying-Call zum Fit-Check. Dann NDA und Discovery-Workshop. Danach der Workflow-Pilot. Erst dann das BOT-Mandat mit Governance-Plane. Kommerzielle Details klären wir im Discovery-Workshop, nicht über öffentliche Preislisten.

Gemessen wird auf Wertstrom-Ebene, nie an Personen. Wir messen Kosten je Wertstrom, den Produktivitäts-Zuwachs und die reale Nutzung. So bleibt jederzeit belegbar, ob sich die Fähigkeit rechnet. Das entscheidet über den nächsten Ausbauschritt. Der Betrieb erzeugt keine Chat-Historie als Ergebnis. Er erzeugt prüfbare Artefakte, die in Ihren Prozess passen. Dazu gehören Reports, Traceability-Matrizen und ausführbare Testsuiten.

Der Pilot ist bewusst klein gehalten. Er dauert wenige Wochen. Er nimmt sich einen realen Ausschnitt Ihres Prozesses vor, nicht ein Laborbeispiel. Am Ende steht ein belastbarer Beleg. Sie sehen, ob die Kette hält und ob sich der Aufwand lohnt. Erst auf dieser Basis entscheiden wir gemeinsam über das volle Mandat. So bleibt jedes Investment an ein sichtbares Ergebnis gebunden.

Das Routing ist ein Baustein der Plattform-Ebene. Warum die Architektur davor eine modell-agnostische Abstraktionsschicht ohne Vendor-Lock-in braucht, steht im Plattform-Beitrag. Wie Datenresidenz in ein prüffähiges Gesamtbild passt, zeigt der Beitrag zum TISAX-fähigen AI-Rollout.

Fazit

Es gibt einen Unterschied zwischen zwei Sätzen. Der erste lautet: Wir nutzen AI-Tools. Der zweite lautet: Wir besitzen eine beherrschte, auditierbare AI-Engineering-Capability. Dieser Unterschied entscheidet, ob AI im Serienprogramm trägt oder im Pilot versandet. Genau diese Entscheidungen hat sensified für den eigenen Betrieb getroffen. Sie sind in einem realen ASPICE-Serienprogramm gebaut. Deshalb kommt sensified mit einer Position, nicht mit Fragen.

Drei Dinge unterscheiden diesen Ansatz. Es gibt einen klaren Plan, belegt durch eigenes, produktives IP. Wir bauen es mit, bis es ASPICE-konform in Produktion läuft. Und es gibt keinen Vendor-Lock-in, abgesichert durch modell-agnostische Architektur und Transfer als Erfolgskriterium. Zwei Tiefen treffen dabei in einem Partner zusammen. Das ist etabliertes Automotive- und SDV-Wissen. Und es ist AI-Engineering-Tiefe aus eigener Plattform.

Wie dieser Baustein in eine beherrschte Gesamt-Capability passt, zeigt unsere Seite zur AI-Transformation im Automotive-Engineering. Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema. Der nächste Schritt ist ein Discovery-Workshop. Dort ordnen wir Ihren Prozess, Ihre Compliance-Lage und den ersten sinnvollen Use-Case gemeinsam ein.

Das Wichtigste in Kürze

• Der EU-Gateway ist der einzige, kontrollierte Weg. Ein Ort für Rechte, Kosten und Nachweis.
• Isolation wird im Code erzwungen, nicht per Konfiguration zugesichert.
• Das Audit ist metadaten-basiert. Inhalts-Logging bleibt aus.
• Caching und Spend-Reports halten Souveränität wirtschaftlich.