AI-Engineering ohne Vendor-Lock-in: warum die Abstraktionsschicht zuerst kommt

AI-Engineering ohne Vendor-Lock-in: die Abstraktionsschicht ist die erste Entscheidung

Die erste AI-Welle ist durch. Lizenzen sind gekauft. Einzelne Teams experimentieren. Trotzdem beginnen viele Organisationen den nächsten Schritt mit einer Frage: Welche Plattform, welches Modell? Das ist die falsche erste Frage.

Wer sich zuerst auf ein Modell festlegt, baut Workflows, die daran hängen. Jeder Wechsel wird dann zum Neubau. Die richtige erste Entscheidung ist eine andere. Sie betrifft die modell-agnostische Abstraktionsschicht, die den Modellzugriff kapselt.

Zuerst die Abstraktionsschicht. Dann die Plattform.

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

• Wie wechseln wir Modelle und Anbieter, ohne unsere Workflows neu zu bauen?
• Wie vermeiden wir zugleich Modell-Lock-in und geopolitisches Risiko?
• Wann ist ein EU-nativer Dienst sinnvoll, und wann self-hosted?
• Wie sichern wir eine belastbare Exit-Strategie ab?

Dieser Beitrag zeigt, warum die Abstraktionsschicht der eigentliche Hebel gegen Lock-in ist. Und wie daraus eine portable Fähigkeit wird, die später in Ihr Haus wandert.

Die erste AI-Welle ist vorbei. Jetzt zählt die Capability.

Die meisten Teams haben die erste Welle hinter sich. Assistenten sind im Einsatz, erste Workflows laufen. Der entscheidende Schritt fehlt aber. Es ist der Sprung von der Tool-Nutzung zur eigenen, auditierbaren Capability.

In dieser zweiten Phase ist Unabhängigkeit keine Randbedingung mehr. Sie ist eine Eigenschaft der Capability. Genau deshalb ist die Wahl der Abstraktionsschicht keine Fußnote. Sie ist die erste Capability-Entscheidung. Sie bestimmt, ob Ihre Fähigkeit portabel bleibt. Und ob der spätere Transfer ins eigene Haus überhaupt gelingt.

Warum Lock-in im Engineering besonders teuer ist

Der Workflow bindet sich an das SDK

AI-Workflows verknüpfen Prompts, Tool-Aufrufe, Datenzugriffe und Freigaben. Ist diese Kette gegen das SDK eines Anbieters gebaut, wird jeder Modellwechsel zum Projekt. Schnittstellen ändern sich. Antwortformate weichen ab. Die Rechte- und Audit-Logik muss angefasst werden.

Im Automotive-Umfeld verschärft sich das. Requirements-, Test- und Review-Agenten greifen auf dieselbe Modell-Ebene zu. Ein gebundener Kern zieht die Bindung durch den ganzen Prozess. Sie reicht bis in die Evidenzketten, die später im Audit belegt werden.

Zwei Arten von Lock-in

Lock-in hat zwei Gesichter. Beide müssen zugleich adressiert werden.

• Modell-Lock-in. Workflows laufen nur mit einem Modell. Preis- oder Qualitätsänderungen des Anbieters schlagen ungefiltert durch.
• Geopolitisches Lock-in. Datenfluss und Betrieb hängen an einer Jurisdiktion, ohne Ausweg. Das kollidiert mit den Datenresidenz-Anforderungen im Automotive.

Die Abstraktionsschicht als erster Baustein

Eine Schnittstelle, viele Modelle

Eine modell-agnostische Abstraktionsschicht kapselt den Modellzugriff. Sie bietet eine einheitliche, OpenAI-kompatible Schnittstelle. Ihre Workflows sprechen gegen diese Schicht, nicht gegen den Anbieter. Ein Modellwechsel wird damit zur Routing-Entscheidung. Er ist kein Umbau mehr. Die Logik der Engineering-Agenten bleibt unberührt.

Bei sensified ist das produktiv umgesetzt. Ein selbst betriebener, EU-gebundener Gateway authentifiziert jeden Aufruf. Er routet ihn und protokolliert ihn metadaten-basiert. Die Workflows kennen nur die Schnittstelle. Welcher Anbieter dahinter arbeitet, ist konfigurierbar.

EU-nativ für die Breite, souverän für die Insel

Modell-Agnostik heißt nicht, alles selbst zu hosten. Für die Breite der Fälle sind EU-native Dienste oft schneller nutzbar und betriebsärmer. Souveräne, self-hosted Modelle bleiben die bewusst gewählte Insel. Sie ist für Restricted-Workloads gedacht, bei denen Daten das eigene Netz nicht verlassen dürfen.

Die Abstraktionsschicht macht diese Zweiteilung handhabbar. Sie erlaubt, je Workload das passende Ziel zu wählen. Der Workflow muss dafür nicht gespalten werden. So entsteht Souveränität, ohne dass die Produktivität leidet.

Exit und Portabilität gehören in die Architektur

Kein Vendor-Lock-in ist bei sensified eine Zusage, keine Formel. Deshalb ist die Exit- und Portabilitäts-Strategie von Anfang an Teil der Architektur. Der Capability-Transfer ist vertragliches Erfolgskriterium. Am Ende besitzen Sie Tooling, Wissen und Betrieb selbst.

• Der Builder-Stack ist host-portabel. Heute eine marktübliche AI-IDE, morgen eine eigene Desktop-IDE. Das Loadout bleibt gleich.
• Anbieter-Schlüssel liegen nicht am Arbeitsplatz. Sie liegen hinter dem Gateway. Sie sind austauschbar, nicht eingebrannt.
• Ein Modellwechsel hinterlässt keine Narben in den Workflows.

Häufige Fehler auf dem Weg dorthin

• Plattform vor Abstraktion. Erst den Anbieter wählen, dann Workflows bauen. Beim ersten Wechsel steht alles neu an.
• Souveränität als Alles-oder-Nichts. Entweder alles self-hosted oder alles Cloud, statt je Workload zu entscheiden.
• Exit als Nachgedanke. Portabilität erst am Vertragsende ansprechen, wenn die Bindung längst gebaut ist.

Diese Fehler sind vermeidbar. Sie sind strukturell. Wer die Abstraktionsschicht zuerst setzt, umgeht sie fast von allein.

So gehen wir vor: Build, Operate, Transfer

Eine modell-agnostische Abstraktionsschicht 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.

Zwei Nachbarthemen vertiefen diesen Baustein: EU-souveränes AI-Routing zeigt, wie die Abstraktionsschicht mit Datenresidenz zusammenspielt. Und das Read-only Overlay für Polarion und Jira zeigt, wie die Plattform an die bestehende Toolchain andockt.

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

• Die erste Entscheidung ist die Abstraktionsschicht, nicht die Plattform.
• Modell-Lock-in und geopolitisches Lock-in gehören zusammen adressiert.
• EU-nativ für die Breite, souverän für die Insel. Die Schicht macht beides möglich.
• Exit-Strategie und Transfer gehören in die Architektur, nicht ans Vertragsende.