Automotive-KI-Plattform: Plattform, Einzeltools oder Architektur?

Die Bestandsaufnahme ist gemacht: ein Textassistent im Vertrieb, ein Prüfsystem an einer Linie, zwei Abteilungen mit eigenen Lizenzen, dazu ein Pilot aus dem letzten Jahr, den niemand abgeschaltet hat. In der nächsten Beiratssitzung steht die Frage im Raum, die der IT-Leiter seit Monaten kommen sah: Bauen wir jetzt eine eigene Plattform, oder lassen wir die Abteilungen weiter einzeln entscheiden? Beide Antworten fühlen sich falsch an. Dieses Gefühl ist berechtigt, solange die Kriterien fehlen, an denen die Entscheidung hängt.

Dieser Beitrag liefert diese Kriterien. Er richtet sich an Geschäftsführung und IT-Leitung von Zulieferern und Automotive-Mittelständlern, die KI längst im Haus haben und nun die Architektur-Entscheidung treffen müssen. Die Ausgangslage beschreibt der Beitrag Sie haben KI im Haus: was im Automotive-Mittelstand fehlt, ist das System dahinter. sensified AI begleitet diese Entscheidung als strategische KI-Leitung, von der Standortbestimmung bis zum System im laufenden Betrieb.

• Was ist das? Ein Entscheidungsstück zur Automotive-KI-Plattform: drei Wege (eigene Plattform bauen, Einzeltools je Abteilung, geführte Architektur mit externem Lead) und ein Prüfraster mit sechs Kriterien für die Wahl je Haus.
• Warum jetzt relevant? 88 Prozent der Unternehmen nutzen laut McKinsey (The State of AI, 2026) KI in mindestens einer Funktion, aber nur rund ein Drittel skaliert über Einzelanwendungen hinaus. Die Architektur-Entscheidung ist die Stelle, an der sich beides trennt.
• Welches konkrete Ergebnis? Eine begründbare Plattform-Entscheidung entlang von Datenhoheit, OEM-Auditierbarkeit, TISAX®-Rahmen, Betriebskosten über drei Jahre, Exit-Fähigkeit und Time-to-Value.

Eine Automotive-KI-Plattform ist die gemeinsame technische und organisatorische Grundlage, auf der ein Zulieferer seine KI-Anwendungen betreibt: Datenzugänge, Modellzugang, Rechteverwaltung, Protokollierung und Betrieb. Ein Zulieferer braucht nicht zwingend eine selbst gebaute Plattform, wohl aber eine tragende Architektur-Entscheidung zwischen drei Wegen: eigene Plattform, Einzeltools je Abteilung oder geführte Architektur mit externer KI-Leitung. Keiner der drei Wege ist pauschal falsch. Die Wahl fällt an sechs prüfbaren Kriterien: Datenhoheit, Auditierbarkeit gegenüber OEM-Kunden, Passung zum TISAX®-Rahmen, Betriebskosten über drei Jahre, Exit-Fähigkeit und Time-to-Value. Für die meisten Häuser mit 250 bis 2.000 Mitarbeitenden bietet die geführte Architektur das beste Verhältnis aus Kontrolle, Tempo und Aufwand, sofern der Wissenstransfer ins eigene Haus vertraglich verankert ist.

• Was: eine begründete Architektur-Entscheidung zwischen eigener Plattform, Einzeltools und geführter Architektur, entlang eines Prüfrasters mit sechs Kriterien.
• Wer profitiert: Geschäftsführung und IT-Leitung von Automobilzulieferern und Mittelständlern mit 250 bis 2.000 Mitarbeitenden im DACH-Raum, die bereits KI-Werkzeuge im Einsatz haben.
• Welches Ergebnis: eine Plattform-Entscheidung, die OEM-Audits übersteht, Betriebskosten kalkulierbar macht und das Haus in keine ungewollte Abhängigkeit führt.

Quelle: sensified AI, strategische KI-Leitung für den Mittelstand, 2026.

Die Zahlen dienen der Orientierung; maßgeblich für Ihre Entscheidung ist die konkrete Daten-, System- und Auditlage in Ihrem Haus.

• Die Plattform-Frage ist eine Architektur-Frage, keine Toolauswahl: Sie entscheidet, wo Daten liegen, wer Zugriffe steuert und wie Nachweise entstehen.
• Betriebskosten über drei Jahre und Exit-Fähigkeit trennen die drei Wege deutlicher als die Anschaffung im ersten Jahr.
• Kein Weg ist pauschal richtig. Das Prüfraster ergibt je Haus eine andere, aber begründbare Antwort.

Quelle: sensified AI, 2026.

Warum die Plattform-Frage jetzt auf dem Tisch liegt

Die Plattform-Frage stellt sich selten am Anfang. Sie stellt sich, wenn die ersten Werkzeuge laufen und die Nebenwirkungen sichtbar werden: Jede Abteilung hat eigene Zugänge, niemand kennt den vollständigen Bestand, und die Frage eines OEM-Auditors nach dem Umgang mit Kundendaten in KI-Systemen lässt sich nicht mehr in einem Satz beantworten. An genau diesem Punkt stehen viele Häuser im Zuliefermarkt.

Vom Tool-Bestand zur Architektur-Entscheidung

Die Zahlen beschreiben die Lage präzise. 93 Prozent der Automobilunternehmen haben laut KPMG (2026) eine eigene KI-Strategie, und in jedem zweiten Haus steuert die oberste Führungsebene das Thema. Zugleich haben nach derselben Studienreihe weniger als 1 Prozent der Unternehmen KI vollständig über alle Bereiche integriert. Zwischen Strategie und Integration liegt die Architektur, und die entsteht in vielen Häusern bislang ungeplant: Werkzeug für Werkzeug, Vertrag für Vertrag, Abteilung für Abteilung. Wie ein Haus aus diesem Zustand herausfindet, beschreibt der Beitrag Verstreute KI-Tools im Zulieferbetrieb: der Weg zur geführten Architektur.

Was eine Plattform von einer Sammlung unterscheidet

Eine Plattform ist mehr als die Summe der Werkzeuge. Sie legt fest, über welche Zugänge Daten in KI-Systeme gelangen, wer Rechte vergibt und entzieht, wo Modelle betrieben werden, wie jede Verarbeitung protokolliert wird und wer den Betrieb verantwortet. Eine Sammlung von Einzeltools beantwortet keine dieser Fragen zentral. Sie beantwortet sie je Werkzeug, je Vertrag und je Abteilung, und genau das macht jedes Kundenaudit und jede interne Kontrolle aufwendig.

Die Entscheidung fällt, auch wenn niemand sie trifft

„Wer die Plattform-Frage vertagt, entscheidet sich für den Wildwuchs.“ Jedes neue Abteilungstool legt Datenflüsse, Verträge und Gewohnheiten an, die später teuer zurückzubauen sind. Die Architektur entsteht so oder so; die Frage ist nur, ob sie geführt entsteht.

Weg 1: die eigene KI-Plattform bauen

Der erste Weg ist der Eigenbau: Das Haus errichtet eine eigene Plattform, betreibt sie selbst und integriert darauf Schritt für Schritt seine Anwendungsfälle. Im Zuliefermarkt hat dieser Weg eine natürliche Anziehungskraft, denn er verspricht das, was die Branche aus dem Produktgeschäft kennt: volle Kontrolle über das eigene System.

Was für den Eigenbau spricht

Die Datenhoheit ist beim Eigenbau maximal, solange Betrieb und Sicherheit dauerhaft getragen werden. Kein fremder Anbieter sitzt zwischen den eigenen Daten und den Modellen, jede Komponente lässt sich an die eigene System- und Auditlandschaft anpassen, und ein Anbieter-Lock-in im engeren Sinn entsteht kaum. Für Häuser mit einer gewachsenen eigenen Softwareorganisation, ausreichender Entwicklungskapazität und einem langen Planungshorizont kann dieser Weg tragen. Es gibt Zulieferer, für die er die richtige Antwort ist.

Was der Eigenbau verlangt

Die Rechnung beginnt allerdings erst nach dem Aufbau. Eine Plattform will betrieben werden: Sicherheitsupdates, Modell-Lebenszyklen, Rechteverwaltung, Protokollierung, Bereitschaft. Das bindet ein Team über Jahre, und dieses Team konkurriert intern mit dem Produktgeschäft um dieselben knappen Entwickler. Dazu kommt das Schlüsselpersonen-Risiko: Verlässt der Architekt der Plattform das Haus, verlässt ein Teil der Betriebsfähigkeit das Haus gleich mit. Der Time-to-Value ist der späteste der drei Wege, denn produktive Anwendungsfälle entstehen erst, wenn die Grundlage steht. Wer den Eigenbau wählt, sollte diese Posten über drei Jahre gerechnet haben, bevor der erste Baustein beauftragt wird.

Weg 2: Einzeltools je Abteilung

Der zweite Weg ist der verbreitetste, weil er sich selten wie eine Entscheidung anfühlt: Jede Abteilung beschafft das Werkzeug, das ihr Problem löst. Der Vertrieb sein Textwerkzeug, die Qualitätssicherung ihr Prüfsystem, die Verwaltung ihren Dokumentenassistenten. Jede einzelne Beschaffung ist für sich genommen vernünftig.

Was für Einzeltools spricht

Kein Weg liefert schneller erste Ergebnisse im einzelnen Anwendungsfall. Die Einstiegshürde ist niedrig, die Fachbereiche wählen passgenau für ihr Problem, und das Haus sammelt reale Erfahrung statt Konzeptpapiere. Als Erkundungsphase ist dieser Weg legitim und oft sogar sinnvoll: Er zeigt, welche Anwendungsfälle im eigenen Haus tatsächlich Wert erzeugen, bevor größere Architektur-Entscheidungen fallen.

Wo die Rechnung kippt

Die Frage, ob KI-Plattform oder Einzeltools, entscheidet sich selten im ersten Jahr, sie entscheidet sich im dritten. Dann stehen ein Dutzend Verträge mit unterschiedlichen Laufzeiten, Datenverarbeitungsregeln und Kündigungsfristen nebeneinander. Unternehmensdaten fließen in mehrere Clouds mit jeweils eigenem Rechtemodell, ein gemeinsames Protokoll über alle Verarbeitungen existiert nicht, und die Auditfrage eines OEM-Kunden muss je Werkzeug neu beantwortet werden. Die Betriebskosten wachsen mit jedem Vertrag und jeder Schnittstelle, ohne dass eine gemeinsame Grundlage entsteht, auf der das nächste Vorhaben günstiger würde. McKinsey (2026) misst das Muster im Großen: 88 Prozent der Unternehmen nutzen KI, aber nur rund ein Drittel kommt über Einzelanwendungen hinaus.

Weg 3: geführte Architektur mit externem Lead

Der dritte Weg trennt zwei Dinge, die in der Debatte oft vermischt werden: die Frage, wer die Architektur führt, und die Frage, wem sie gehört. Eine geführte Architektur wird von einer externen strategischen KI-Leitung entworfen und betrieben, aus bewährten Bausteinen statt aus Neuentwicklung, auf europäischer Infrastruktur, mit einem zentralen Rechte- und Protokollmodell. Sie gehört dem Haus: Datenzugänge, Exit-Rechte und der Transfer des Wissens sind Bestandteil des Modells.

Wie der Weg funktioniert

Am Anfang steht eine Standortbestimmung: Welche Werkzeuge laufen bereits, welche Datenflüsse existieren, welche Auditanforderungen stellen die OEM-Kunden. Darauf entsteht eine gemeinsame Grundlage, in die bestehende, bewährte Werkzeuge integriert werden können, statt alles abzulösen. Neue Anwendungsfälle setzen auf dieser Grundlage auf und teilen sich Rechteverwaltung, Protokollierung und Betrieb. Wie eine solche Plattform im Detail aufgebaut, ausgewählt und betrieben wird, vertieft der Beitrag Managed KI-Plattform für den Mittelstand: Architektur, Auswahl, Betrieb.

Wo der Weg Grenzen hat

Auch dieser Weg ist kein Selbstläufer. Seine Qualität hängt an der Qualität des Partners, und ein Betriebsmodell ohne vertraglich verankerten Wissenstransfer erzeugt nur eine neue, besser organisierte Abhängigkeit. Die Führung der Architektur kann außer Haus liegen, die Entscheidung über Daten, Anwendungsfälle und Prioritäten gehört auf die eigene Führungsebene. Häuser, die diese Rollenverteilung nicht einfordern, tauschen viele kleine Abhängigkeiten gegen eine große.

Kontrolle ist kein Synonym für Eigenbau

„Datenhoheit entsteht durch Architektur und Verträge, unabhängig davon, wer den Code geschrieben hat.“ Ein Haus, das Zugriffe, Datenflüsse und Exit-Rechte technisch und vertraglich kontrolliert, hat mehr Hoheit als eines, das eine selbst gebaute Plattform mit drei überlasteten Administratoren betreibt.

Das Prüfraster: sechs Kriterien entscheiden je Haus

Für die Wahl einer KI-Plattform in der Automobilindustrie gibt es keine pauschal richtige Antwort, wohl aber ein prüfbares Raster. Sechs Kriterien trennen die drei Wege dort, wo es für Zulieferer zählt: bei Daten, Audits, Kosten und der Freiheit, den Kurs später zu ändern.

Wie Sie das Raster anwenden

Die sechs Kriterien wiegen je Haus unterschiedlich, und genau diese Gewichtung ist die eigentliche Führungsarbeit. Ein Direktlieferant mehrerer OEM-Kunden gewichtet Auditierbarkeit und TISAX®-Passung hoch, weil jedes Kundenaudit auf die Architektur schaut. Ein Haus mit angespannter Ergebnislage gewichtet die Betriebskosten über drei Jahre und den Time-to-Value. Ein Haus mit schlechten Erfahrungen aus Softwareverträgen gewichtet die Exit-Fähigkeit. Wichtig ist, dass Geschäftsführung und IT-Leitung die Gewichtung gemeinsam festlegen, bevor über Wege gesprochen wird, denn sonst gewinnt in der Diskussion der Weg mit dem lautesten Fürsprecher.

Typische Konstellationen im Zuliefermarkt

In der Praxis wiederholen sich drei Muster. Häuser mit eigener Softwareorganisation und langem Horizont prüfen den Eigenbau ernsthaft, häufig für einen abgegrenzten Kern und mit zugekauften Bausteinen für den Rest. Häuser am Anfang der Erkundung fahren bewusst eine begrenzte Einzeltool-Phase mit klarem Enddatum und einer Inventur als Pflichtergebnis. Häuser mit laufenden Werkzeugen, wachsendem Auditdruck und knapper interner Kapazität wählen die geführte Architektur, weil sie Ordnung, Tempo und Nachweisfähigkeit verbindet, ohne ein eigenes Plattformteam aufbauen zu müssen. Alle drei Entscheidungen sind seriös, wenn sie am Raster begründet sind.

OEM-Anforderungen und TISAX® in der Plattform-Entscheidung

Für Zulieferer hat die Plattform-Frage eine Dimension, die in generischen Vergleichen fehlt: Die eigene Architektur wird von Kunden geprüft. Wer OEM-Programme beliefert, beantwortet Fragen zu Informationssicherheit und Datenverarbeitung regelmäßig gegenüber Auditoren, und KI-Systeme rücken dabei zunehmend ins Blickfeld.

Was Kundenaudits an der Architektur prüfen

TISAX®, das Assessment-Verfahren der ENX Association auf Basis des VDA ISA (aktuell Version 6), ist für viele Direktlieferanten faktische Marktzugangsvoraussetzung. KI-Systeme, die mit Entwicklungs-, Konstruktions- oder Kundendaten arbeiten, müssen in diesen Rahmen passen: Wo liegen die Daten, wer greift zu, welche Unterauftragsverhältnisse bestehen, wie werden Verarbeitungen protokolliert. Eine Architektur, die diese Antworten zentral vorhält, verkürzt jedes Audit. Eine Landschaft aus unverbundenen Einzeltools verlängert es, weil dieselben Fragen je Werkzeug neu belegt werden müssen.

Was die KI-Verordnung von der Architektur verlangt

Die KI-Verordnung (EU) 2024/1689 kommt hinzu. Die Pflicht zur KI-Kompetenz der Beschäftigten (Art. 4) gilt seit dem 2. Februar 2025, die Pflichten für Anbieter großer Basismodelle seit August 2025, und die Stufen für Hochrisiko-Anwendungen greifen bis 2028. Für die Plattform-Entscheidung heißt das: Die Architektur muss je Anwendungsfall auskunftsfähig sein, welche Risikoklasse berührt ist, welche Transparenzpflichten gelten und wer verantwortlich zeichnet. Diese Auskunftsfähigkeit lässt sich auf jedem der drei Wege herstellen. Auf einer gemeinsamen Grundlage entsteht sie einmal, in einer Einzeltool-Landschaft je Werkzeug.

Das Audit fragt nach dem System

„Ein OEM-Auditor will keine Lizenzliste sehen. Er will sehen, wer Zugriffe steuert, wo Daten fließen und wie Nachweise entstehen.“ Diese Fragen beantwortet eine Architektur, gleich welcher der drei Wege gewählt wurde. Häuser ohne Architektur beantworten sie je Werkzeug neu, bei jedem Audit.

Selbst-Check: fünf Fragen vor der Plattform-Entscheidung

Fünf Fragen zeigen in wenigen Minuten, ob Ihr Haus die Architektur-Entscheidung schon tragen kann oder ob Grundlagen fehlen.

• Kennen Sie den vollständigen Bestand an KI-Werkzeugen in Ihrem Haus, einschließlich der Zugänge einzelner Abteilungen?
• Können Sie für jedes dieser Werkzeuge sagen, welche Daten es verarbeitet und wo diese Daten liegen?
• Würde Ihre heutige Landschaft die Fragen eines OEM-Auditors nach Zugriffen und Protokollen in einem Termin beantworten?
• Haben Sie die Betriebskosten Ihrer KI-Landschaft über drei Jahre gerechnet, einschließlich Verträgen, Schnittstellen und interner Stunden?
• Gibt es für jedes Werkzeug einen geprüften Weg hinaus, falls Anbieter, Konditionen oder Anforderungen sich ändern?

Bleiben zwei oder mehr Fragen offen, ist ein Discovery-Call der passende nächste Schritt.

Nächste Schritte

Wenn Ihr Haus KI-Werkzeuge im Einsatz hat und die Plattform-Frage im Führungskreis liegt, ist der erste Schritt keine Ausschreibung und kein Entwicklungsauftrag. Der erste Schritt ist die Bewertung der drei Wege entlang des Prüfrasters, mit den Zahlen und Auditanforderungen Ihres Hauses. So gehen Sie vor:

1. Discovery-Call über 30 Minuten, kostenlos und mit ehrlichem Fit-Check: Wir ordnen ein, welcher der drei Wege zur Lage Ihres Hauses passt und wo das Prüfraster die schärfsten Ausschläge zeigt.
2. Standortbestimmung: Wir erheben Tool-Bestand, Datenflüsse, Auditanforderungen und Betriebskosten und bewerten die sechs Kriterien für Ihr Haus.
3. Architektur und Betrieb: Wir überführen die Entscheidung in eine tragende Architektur, die in Produktion läuft, mit geordnetem Wissenstransfer in Ihr Haus.

Wie das aufgebaute Können dauerhaft ins eigene Haus kommt, vertieft der Beitrag Build-Operate-Transfer für Zulieferer: KI-Kompetenz ins eigene Haus holen.