Die fünf Governance-Gates (G1 bis G5) zum OEM-fähigen AI-Rollout

Fünf Governance-Gates: kontrolliert von der Pilotgruppe zur OEM-Fähigkeit

Der Weg vom Pilot zum unternehmensweiten Rollout scheitert selten an der Technik. Er scheitert an Governance. An fehlender Identität. An unklaren Rechten. An ungeschützten Daten. An Abläufen, die niemand belegen kann.

Deshalb gilt im Engineering ein einfacher Satz. Governance und TISAX sind der kritische Pfad, nicht die Modellwahl. Wer AI-Zugang in der falschen Reihenfolge öffnet, erkauft Tempo mit Risiko. Spätestens im ASPICE-Assessment fällt das auf.

AI-Zugang wächst erst, wenn die nächste Voraussetzung erfüllt ist.

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

• In welcher Reihenfolge öffnen wir AI-Zugang, ohne Compliance zu verlieren?
• Woran machen wir fest, dass die nächste Stufe erlaubt ist?
• Wie sammeln wir Evidenz, bevor wir breit ausrollen?
• Wie skalieren wir von einer Pilotgruppe auf hunderte Engineers?

Dieser Beitrag beschreibt die fünf Freigabe-Gates. Er zeigt, warum ihre Reihenfolge nicht verhandelbar ist. Und wie eine Validierungsstufe die Evidenz vor dem breiten Ausbau liefert.

Vom Pilot in die Breite: hier scheitern die meisten

Ein Pilot mit einer Handvoll motivierter Engineers beeindruckt fast immer. Der Bruch kommt beim Übergang in die Breite. Was in einer kleinen Gruppe funktioniert, kollabiert bei hunderten Engineers. Sie haben unterschiedliche Rollen, Daten und Schutzbedarfe. Nicht das Modell wird zum Problem. Es ist die fehlende Ordnung darum herum.

Der Rollout braucht deshalb eine Zwischenstufe. Ein Richtwert sind rund 100 Engineers. Diese Stufe ist mehr als ein größerer Pilot. Sie ist der Ort, an dem die Gates unter realer Last gepruft werden. Erst wenn sie hier tragen und die Evidenz stimmt, ist der breite Rollout mehr als eine Hoffnung.

Die fünf Gates in der richtigen Reihenfolge

Jedes Gate ist Voraussetzung für das nächste. AI-Zugang wächst erst, wenn das jeweilige Gate steht. Nicht parallel. Nicht später.

1. G1, Identity und SSO. Eine eindeutige Identität ist die Basis jeder Freigabe. Ohne sie gibt es keine Zurechnung.
2. G2, RBAC. Rollenbasierte Rechte statt pauschalem Zugriff. Wer was darf, folgt der Rolle.
3. G3, DLP und Klassifizierung. Datenabfluss kontrollieren. Inhalte einstufen, bevor sie in Workflows fließen.
4. G4, manipulationssicheres Audit-Logging. Nachweisbar, wer was wann ausgelöst hat. Unveränderbar.
5. G5, TISAX-Kette. Begleitung entlang der Validierungskette bis zur OEM-Fähigkeit.

Warum die Reihenfolge nicht verhandelbar ist

Jedes Gate trägt das nächste

Rechte ohne Identität sind wertlos. Sie lassen sich niemandem zuordnen. Datenklassifizierung ohne Rechte läuft ins Leere. Dann sieht jeder alles. Und ein Audit-Log trägt nur, wenn Identität, Rechte und Klassifizierung davor stehen. Die Gates sind keine beliebige Checkliste. Sie sind eine tragende Kette.

Der Preis des Überspringens

Wer Gates überspringt, baut auf Sand. AI-Zugang ohne saubere Identität und ohne Audit ist im ASPICE-Assessment nicht belegbar. Das gefährdet die OEM-Abnahme. Die vermeintliche Abkürzung führt zu teurer Nacharbeit. Oder zum Verlust des Marktzugangs.

Evidenz vor dem breiten Rollout

Vor der Skalierung steht der Beleg. In der Validierungsstufe messen wir drei Größen, bevor wir ausbauen.

• Kosten je Wertstrom, transparent und nachvollziehbar.
• Produktivitäts-Zuwachs auf Wertstrom-Ebene, nie als Personen-Telemetrie.
• Nutzung. Wird die Fähigkeit real genutzt oder nur bereitgestellt?

Erst diese Evidenz rechtfertigt den breiten Ausbau. Sie macht den Rollout zur belegten Entscheidung. Er ist dann keine Wette mehr.

Häufige Fehler bei der Skalierung

• Technik zuerst. Das beste Modell wählen, bevor Identität und Rechte stehen.
• Gates parallel. Alle fünf gleichzeitig angehen und keines sauber schließen.
• Rollout ohne Evidenz. Von der Pilotgruppe direkt in die Breite, ohne Kosten und Nutzung zu messen.

Diese Fehler sind vermeidbar, weil sie strukturell sind. Wer die Gates als Kette begreift und die Validierungsstufe als Pflicht akzeptiert, umgeht sie fast von allein. Die Reihenfolge kostet zu Beginn Disziplin. Sie zahlt sich in jeder späteren Abnahme aus. Ein sauberes Fundament trägt hunderte Engineers. Ein schnelles Provisorium trägt keine.

So gehen wir vor: Build, Operate, Transfer

Einen governance-festen AI-Rollout 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.

Die Gates sind das Gerüst, zwei Nachbarbeiträge füllen es: der TISAX-fähige AI-Rollout beschreibt die Informationssicherheits-Seite, und ISO 26262 und AI zieht die Grenze zwischen Assistenz und Safety-Entscheidung.

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

• Governance ist der kritische Pfad, nicht die Modellwahl.
• Reihenfolge: Identity, RBAC, DLP und Klassifizierung, Audit, TISAX.
• Jedes Gate trägt das nächste. Überspringen kostet die OEM-Abnahme.
• Evidenz zu Kosten und Nutzung kommt vor dem breiten Rollout.