AI Operating Model Design: Struktur für skalierte KI
Wie Unternehmen Rollen, Governance-Kadenz und Tool-Standards so gestalten, dass KI-Initiativen über einzelne Pilotprojekte hinaus skalieren.
Wie Unternehmen Rollen, Governance-Kadenz und Tool-Standards so gestalten, dass KI-Initiativen über einzelne Pilotprojekte hinaus skalieren.
Wer priorisiert, welcher KI-Use-Case als Nächstes gebaut wird? Wer haftet, wenn ein KI-gestützter Entscheid falsch war? Wer stellt sicher, dass die Rechtsabteilung nicht drei verschiedene, sich widersprechende KI-Tools gleichzeitig einsetzt? Wenn Ihnen auf keine dieser Fragen sofort eine klare Antwort einfällt, ist das kein Zufall, sondern der Normalzustand in Unternehmen, die für ihre KI-Initiativen noch keine Struktur definiert haben.
Ein einzelner erfolgreicher Piloten-Use-Case – ein Chatbot im Kundenservice, ein automatisiertes Angebotstool im Vertrieb – lässt sich auch ohne diese Antworten mit einem engagierten Team und etwas Genehmigungsspielraum realisieren. Sobald aber fünf, zehn oder zwanzig Fachbereiche gleichzeitig KI-Use-Cases entwickeln wollen, reicht Enthusiasmus allein nicht mehr aus – und genau die fehlenden Antworten werden zum eigentlichen Engpass, nicht die Technologie.
Das AI Operating Model ist die Antwort auf diese Fragen in strukturierter Form. Es legt fest, wer welche Entscheidungen trifft, welche Rollen dafür nötig sind, in welchem Rhythmus Governance stattfindet und wie Tools und Budgets über Abteilungsgrenzen hinweg koordiniert werden. Unternehmen, die diese Struktur überspringen und direkt von Pilotprojekt zu Pilotprojekt springen, stoßen fast immer auf dieselbe Wand: Der zehnte Use-Case dauert nicht kürzer als der erste, sondern länger, weil niemand mehr den Überblick hat, welche Tools, Daten und Risikoentscheidungen bereits existieren. Das Operating Model ist damit kein bürokratischer Zusatzaufwand, sondern die Voraussetzung dafür, dass sich der Aufwand pro Use-Case mit der Zeit reduziert statt erhöht.
Wichtig ist dabei die Perspektive: Das Operating Model ist kein einmaliges Organigramm, das am Kick-off-Tag verabschiedet und dann eingefroren wird. Es ist ein Betriebssystem, das mit der Reife der KI-Nutzung mitwächst – und genau diese Entwicklung sollte bereits im Design mitgedacht werden, statt bei jeder neuen Wachstumsstufe eine Reorganisation zu erzwingen.
In der Praxis kristallisieren sich drei Grundarchetypen heraus, und die Wahl zwischen ihnen ist die wichtigste strukturelle Entscheidung im gesamten Design-Prozess.
Das zentrale Center of Excellence (CoE) bündelt sämtliche KI-Initiativen in einem Team, das Priorisierung, Entwicklung und Risikoprüfung zentral verantwortet. Der Vorteil liegt auf der Hand: Konsistenz bei Qualität, Risikohandhabung und Tooling, klare Verantwortlichkeiten, ein einziger Ort für Wissen und Best Practices. Der Nachteil zeigt sich fast zwangsläufig ab einer gewissen Nachfrage: Das CoE wird zum Intake-Flaschenhals. Fachbereiche warten wochenlang auf einen Termin, ihre Anliegen werden gegen unternehmensweite Prioritäten abgewogen, die mit ihrem eigenen Tagesgeschäft wenig zu tun haben. Die Folge ist vorhersehbar – Fachbereiche beginnen, das CoE zu umgehen, und genau das befeuert Schatten-KI.
Das föderierte bzw. eingebettete Modell dreht das Prinzip um: Jeder Fachbereich baut und betreibt seine eigene KI-Fähigkeit. Das bringt Geschwindigkeit und hohe fachliche Passgenauigkeit, weil die Entwicklung nah an der tatsächlichen Problemstellung stattfindet. Der Preis dafür ist strukturelle Ineffizienz: Marketing, Vertrieb und Kundenservice kaufen unabhängig voneinander überlappende KI-Abonnements, entwickeln eigene Prompt-Bibliotheken für ähnliche Probleme, und die Risikobewertung fällt in jeder Abteilung unterschiedlich streng aus – von "wird schon passen" bis "wir brauchen erst ein Rechtsgutachten".
Das hybride Hub-and-Spoke-Modell verbindet beide Logiken: Ein zentraler Hub verantwortet Plattform, Standards, Risikorahmen und das Tool-Portfolio, während die Fachbereiche über eingebettete Rollen ihre eigenen Use-Cases im Rahmen dieser Standards entwickeln und betreiben. Der Hub liefert die Leitplanken – genehmigte Modelle, Evaluationsverfahren, Risikoklassifizierung –, die Spokes liefern die fachliche Tiefe und Geschwindigkeit. Dieses Muster ist kein Kompromiss aus Verlegenheit, sondern der Zielzustand, auf den die meisten mittelständischen und großen Organisationen zusteuern, sobald sie über die erste Pilotphase hinauswachsen. Wer direkt mit diesem Modell startet statt sich über reine CoE- oder reine Föderations-Phasen dorthin vorzuarbeiten, spart sich mindestens eine schmerzhafte Reorganisation.
Generische Rollenlisten helfen wenig, wenn sie nicht auf reale Verantwortlichkeiten heruntergebrochen werden. Folgende Rollen haben sich in der Praxis als tragfähiges Grundgerüst etabliert:
Der AI Product Owner verantwortet den Use-Case-Backlog eines Fachbereichs und stellt sicher, dass jede Initiative einen messbaren Geschäftswert liefert, statt Technologie um ihrer selbst willen einzusetzen. Diese Rolle sitzt fachlich in der Abteilung, nicht in der IT.
Der Prompt Engineer bzw. AI Solutions Engineer baut und pflegt Prompts, Evaluationssets und Guardrails für produktive Anwendungen. Diese Rolle ist technischer als der Product Owner, aber weniger tief in der Modellinfrastruktur verankert als ein ML-Engineer.
Der AI Governance/Risk Lead verantwortet Risikoklassifizierung, Compliance-Freigaben und Modell-Dokumentation. Diese Rolle sitzt typischerweise im Hub und ist der zentrale Ansprechpartner für alles, was über die reine Nutzung hinaus rechtliche oder regulatorische Fragen aufwirft.
Der ML/Data Engineer verantwortet Integration, Datenpipelines und gegebenenfalls Fine-Tuning – die technische Infrastruktur, auf der die Use-Cases laufen.
Der eingebettete Business Translator bzw. AI Champion pro Fachbereich übersetzt zwischen fachlichem Bedarf und technischer Machbarkeit. Diese Rolle ist oft die unterschätzteste im gesamten Modell, weil sie die tägliche Reibung zwischen Fachseite und technischem Team abfängt.
Der Executive Sponsor sitzt im AI-Steuerungsgremium und stellt sicher, dass Budget- und Priorisierungsentscheidungen auf Geschäftsführungsebene getroffen werden, statt in der Organisation zu versickern.
Der Change/Enablement Lead verantwortet Schulung und Adoption – eine Rolle, die in vielen Operating-Model-Entwürfen schlicht vergessen wird, obwohl mangelnde Adoption einer der häufigsten Gründe für gescheiterte KI-Initiativen ist.
Entscheidend für mittelständische Unternehmen: In den meisten Fällen sind diese Rollen im ersten Jahr keine dedizierten Vollzeitstellen, sondern Teilzeit- oder Rotationsfunktionen, die bestehende Mitarbeitende zusätzlich zu ihrer eigentlichen Aufgabe übernehmen. Ein AI Product Owner in einem 200-Personen-Unternehmen ist häufig eine Abteilungsleiterin, die 20 Prozent ihrer Zeit für diese Funktion reserviert. Erst wenn die Nutzung eine kritische Schwelle überschreitet – als Faustregel etwa zehn oder mehr aktive Produktiv-Use-Cases – rechtfertigt sich der Schritt zu dedizierten Vollzeitrollen. Wer von Anfang an eine Vollzeit-Governance-Organisation aufbaut, baut damit häufig an der tatsächlichen Nutzung vorbei.
Der Mechanismus, der ein Center of Excellence davor bewahrt, zum Flaschenhals zu werden, ist konsequente Risikostufung. Nicht jeder Use-Case verdient dieselbe Prüftiefe. Ein internes Tool, das E-Mail-Entwürfe für die interne Kommunikation vorschlägt, braucht eine andere Prüfung als ein Modell, das Kreditentscheidungen oder Bewerberauswahl automatisiert unterstützt.
Die Klassifizierung sollte bereits bei der Einreichung eines Use-Case erfolgen, nicht erst nachträglich. Ein einfaches Raster mit typischerweise drei bis vier Stufen reicht in der Praxis: Low-Risk (interne Produktivitätswerkzeuge ohne Kundenkontakt und ohne automatisierte Entscheidungswirkung), Medium-Risk (kundennahe oder prozessrelevante Anwendungen ohne rechtlich bindende Entscheidungen), und High-Risk (kundenwirksame oder regulatorisch relevante Entscheidungen, etwa in Personal, Finanzierung oder Sicherheit). Jede Stufe erhält einen eigenen Genehmigungspfad: Low-Risk kann durch den Fachbereich selbst mit einer einfachen Selbstauskunft freigegeben werden, High-Risk durchläuft eine vollständige Prüfung durch den Governance/Risk Lead inklusive Dokumentationspflicht und gegebenenfalls Freigabe durch das Steuerungsgremium.
Damit dieses System funktioniert, müssen Entscheidungsrechte explizit benannt sein – wer darf den Produktivbetrieb eines KI-gestützten Entscheidungsprozesses final freigeben? In vielen Organisationen ist genau das nicht geklärt, was in der Praxis dazu führt, dass entweder niemand die Verantwortung übernimmt oder jeder sie für sich beansprucht, sobald etwas schiefgeht.
Governance scheitert selten an fehlendem Willen, sondern an fehlender Regelmäßigkeit. Ein tragfähiger Rhythmus sieht in der Praxis so aus:
Ein monatliches AI-Steuerungsgremium auf Führungsebene entscheidet über Portfolio-Priorisierung und Budgetfreigaben über Abteilungsgrenzen hinweg. Hier sitzen der Executive Sponsor sowie Vertreter der wichtigsten Fachbereiche.
Eine zweiwöchentliche funktionsübergreifende Arbeitsgruppe übernimmt die operative Arbeit: Use-Case-Intake, Risikobewertung neuer Anträge, Klärung von Blockern. Diese Gruppe ist der eigentliche Motor der Governance – hier werden die meisten Entscheidungen tatsächlich getroffen.
Ein leichtgewichtiger Intake-Prozess mit Risikoklassifizierung direkt bei Einreichung sorgt dafür, dass jeder neue Use-Case von Anfang an in die richtige Prüftiefe einsortiert wird, statt erst nachträglich klassifiziert zu werden.
Ein quartalsweiser Portfolio-Review verknüpft die laufenden Use-Cases mit tatsächlichen Geschäfts-KPIs und entscheidet, welche Initiativen skaliert, pausiert oder eingestellt werden.
Ein Modell- und Vendor-Review-Board, das quartalsweise oder anlassbezogen bei Vertragsänderungen tagt, pflegt die Liste genehmigter Tools und Modelle und bewertet neue Anbieter, bevor sie in den produktiven Einsatz gelangen.
Diese Kadenz muss zur Unternehmensgröße passen. Ein mittelständisches Unternehmen mit fünf aktiven Use-Cases braucht keine wöchentliche Gremiensitzung – wohl aber die Grundstruktur, damit sie mitwächst, sobald die Zahl der Use-Cases steigt.
Tooling-Standardisierung beginnt mit einer verbindlichen Liste genehmigter Tools und Modelle, die für alle Fachbereiche gilt. Darauf aufbauend empfiehlt sich ein zentrales LLM-Gateway bzw. eine Abstraktionsschicht über die verschiedenen Modellanbieter, damit einzelne Anwendungen nicht fest an einen bestimmten Provider gebunden sind – ein Wechsel des Modells oder Anbieters wird so zur Konfigurationsänderung statt zum Neubau.
Eine geteilte Prompt- und Evaluationsbibliothek über Abteilungsgrenzen hinweg verhindert, dass jeder Fachbereich dieselben Probleme unabhängig voneinander löst. Häufig entwickeln Marketing und Kundenservice fast identische Prompts für Textzusammenfassung oder Tonalitätsanpassung, ohne voneinander zu wissen.
Besonders wirkungsvoll ist ein Schatten-KI-Registrierungsprozess mit Amnestie: Mitarbeitende und Teams, die bereits ungenehmigte KI-Tools im Einsatz haben, melden diese ohne Sanktionsrisiko, damit sie in den offiziellen Rahmen überführt oder bewusst durch genehmigte Alternativen ersetzt werden können. In nahezu jedem Unternehmen, das seine KI-Landschaft zum ersten Mal systematisch erfasst, zeigt sich, dass deutlich mehr KI-Tools im Einsatz sind, als der offiziellen IT bekannt war. Das ist keine Ausnahme, sondern der Regelfall – und genau deshalb sollte der Registrierungsprozess von Anfang an mitgeplant werden, statt als nachträgliche Reaktion auf einen Vorfall.
Die Finanzierungslogik ist eng mit der Wahl des Operating Models verknüpft und wird in Design-Prozessen oft übersehen. Bei vollständig zentraler Budgetierung trägt eine zentrale Stelle sämtliche Kosten für Plattform und Use-Case-Entwicklung. Das stärkt die Governance-Durchsetzung, weil das Budget an zentrale Standards gekoppelt ist, verlangsamt aber häufig das Commitment der Fachbereiche, weil diese die Kosten nicht selbst tragen und entsprechend geringeres Interesse an Kosteneffizienz zeigen.
Beim Chargeback- bzw. Kostenumlage-Modell zahlen Fachbereiche für die von ihnen genutzten Ressourcen. Das schafft stärkere Verbindlichkeit und Kostenbewusstsein, setzt aber eine gewisse organisatorische Reife voraus – ohne verlässliche Nutzungsmessung und Kostenverrechnung wird Chargeback schnell zur Quelle interner Konflikte statt zum Steuerungsinstrument.
In der Praxis bewährt sich meist ein hybrides Modell: Die zentrale Plattform- und Infrastrukturebene – Gateway, Basismodelle, Sicherheitswerkzeuge – wird zentral finanziert, während die fachspezifische Use-Case-Entwicklung vom jeweiligen Fachbereich getragen wird. Damit trägt die zentrale Ebene die Kosten für Konsistenz und Risikokontrolle, während die Fachbereiche die Verantwortung für den Geschäftswert ihrer eigenen Initiativen behalten.
Der Erfolg des Operating Models selbst muss unabhängig von der Rendite einzelner Use-Cases gemessen werden. Relevante Kennzahlen sind: die Durchlaufzeit von der Use-Case-Einreichung bis zum Produktivbetrieb, der Anteil des KI-bezogenen Budgets, der über genehmigte und governte Kanäle läuft, im Vergleich zu Schatten-Tools, die Anzahl aktiver eingebetteter AI Champions pro Fachbereich, die Adoptionsrate von KI-Anwendungen nach Funktion sowie das Konzentrationsrisiko bei Modellen und Anbietern.
Diese Metriken beantworten eine andere Frage als der ROI eines einzelnen Use-Case: Sie zeigen, ob die Organisation als Ganzes lernfähig und skalierbar mit KI umgeht, oder ob jeder neue Use-Case wieder bei null anfängt.
Für Unternehmen in Deutschland, Österreich und der Schweiz lohnt es sich, die interne Risikostufung direkt an den Risikokategorien des EU AI Act zu spiegeln – unzulässig, hochriskant, begrenztes Risiko, minimales Risiko. Wird diese Zuordnung von Anfang an in das interne Klassifizierungsraster eingebaut, greifen Pflichten wie Konformitätsbewertung, menschliche Aufsicht und Dokumentationspflicht automatisch für die richtige Governance-Stufe, statt nachträglich mühsam zugeordnet werden zu müssen.
Ein zweiter, in der Praxis häufig übersehener Punkt betrifft die Mitbestimmung: KI-Systeme, die Mitarbeiterüberwachung oder Leistungsbewertung berühren, lösen in Deutschland und Österreich in aller Regel Mitbestimmungsrechte des Betriebsrats aus. Diese Prüfung darf nicht als nachgelagerter Schritt behandelt werden, sondern braucht eine feste Rolle in der Governance-Kadenz – etwa als verbindlicher Prüfpunkt im Intake-Prozess für jeden Use-Case, der Personaldaten oder Leistungsmetriken berührt.
Statt eines einheitlichen Schulungsprogramms empfiehlt sich ein gestuftes Modell: ein Executive-Awareness-Track für die Führungsebene, der Chancen, Risiken und Entscheidungslogik vermittelt; ein Vertiefungs-Track für die eingebetteten AI Champions in den Fachbereichen mit praktischer Prompt- und Evaluationskompetenz; und ein allgemeiner KI-Literacy-Track für alle Mitarbeitenden, der Grundverständnis und sicheren Umgang mit genehmigten Tools vermittelt. Jeder Track ist direkt an die zuvor definierten Rollen gekoppelt, statt als isoliertes Trainingsprogramm nebenherzulaufen.
Einige Muster wiederholen sich über Branchen und Unternehmensgrößen hinweg. Ein reines zentrales CoE wird zum Intake-Flaschenhals, sodass Fachbereiche es umgehen – das befeuert genau die Schatten-KI, die Governance eigentlich verhindern soll. Ein rein föderiertes Modell erzeugt doppelte Tool-Ausgaben und uneinheitliche Risikobehandlung zwischen Abteilungen. Governance wird am Reißbrett entworfen, bevor überhaupt ein realer Use-Case existiert – das Ergebnis ist überkonstruiert und wird in der Praxis schlicht ignoriert. Es fehlen klare Entscheidungsrechte, wer den Produktivbetrieb einer KI-gestützten Entscheidung final freigeben darf. Und KI-Governance wird als reine IT-Sicherheitsprüfung behandelt statt in bestehende Datenschutz- und Modellrisikostrukturen integriert zu werden, wodurch doppelte, sich widersprechende Prüfprozesse entstehen.
Der wirksamste erste Schritt ist eine zügige Bestandsaufnahme des aktuellen Zustands – welche Schatten-KI-Nutzung existiert bereits, welche Piloten laufen, welche Entscheidungsrechte sind faktisch schon etabliert, auch wenn sie nirgends dokumentiert sind. Diese Bestandsaufnahme dauert typischerweise wenige Wochen und liefert die Grundlage, auf der das Zielmodell aufgebaut wird, statt Governance im luftleeren Raum zu entwerfen.
Dabei zeigt sich regelmäßig ein konkreter Kostenhebel: In mittelständischen Unternehmen mit dezentraler Beschaffung haben mehrere Fachbereiche unabhängig voneinander überlappende KI-SaaS-Abonnements eingekauft, oft für nahezu identische Anwendungsfälle. Eine standardisierte Tooling-Schicht macht diese Doppelkosten sichtbar und eliminiert sie – ein Effekt, der sich in vielen Organisationen unabhängig von Branche und Größe reproduziert und der sich bereits in den ersten Monaten nach Einführung des Operating Models amortisiert.
Aus dieser Bestandsaufnahme heraus lässt sich das Zielmodell ableiten: Wo heute organisch föderiert gearbeitet wird, wird ein CoE-lite als Übergangsstruktur etabliert, sobald mehrere Use-Cases gleichzeitig skalieren sollen. Von dort aus entwickelt sich die Organisation in Richtung des hybriden Hub-and-Spoke-Modells mit eingebetteten Rollen – nicht als einmaliger Kraftakt, sondern als geplanter, mehrstufiger Weg, der von Anfang an mitgedacht wird.