Ein AI Operating Model aufbauen

Es gibt eine Frage, mit der sich der Reifegrad einer Organisation beim Thema AI zuverlässiger messen lässt als mit jeder Technologie-Inventur: „Wer ist bei Ihnen für AI verantwortlich?" Stellt man sie zehn Personen im selben Unternehmen, bekommt man oft zehn verschiedene Antworten. Die IT verweist auf die Fachbereiche, die Fachbereiche auf ein Innovationsteam, das Innovationsteam auf einen Steuerungskreis, von dem niemand genau weiß, wann er zuletzt getagt hat. Manchmal bekommt man auch einfach eine lange Pause.

Diese Uneindeutigkeit wird gern als Kommunikationsproblem behandelt. Sie ist keines. Sie ist das Symptom eines fehlenden Operating Models — und damit die eigentliche Ursache dafür, dass AI in vielen Organisationen nicht über Einzelinitiativen hinauskommt.

Warum die Frage auf den Managementtisch gehört

Noch vor wenigen Jahren konnte man AI als Technologiethema delegieren. Diese Phase ist vorbei. Heute experimentiert praktisch jeder Fachbereich auf eigene Faust: Der Vertrieb testet Assistenten, das Marketing generiert Inhalte, die Sachbearbeitung baut sich kleine Automatisierungen. Nichts davon wartet auf eine Strategie. Die Frage ist längst nicht mehr, ob die Organisation AI einsetzt — sie tut es. Die Frage ist, ob sie es unter erkennbarer Verantwortung tut oder als Summe unkoordinierter Einzelentscheidungen.

Genau hier entsteht das Risiko, das Geschäftsführungen tatsächlich tragen: nicht die spektakuläre Fehlentscheidung, sondern die vielen kleinen, die niemand getroffen hat. Wer haftet für das Ergebnis eines Werkzeugs, das nie jemand freigegeben hat? Welche Daten verlassen das Haus, ohne dass es eine bewusste Entscheidung dazu gab? Das sind keine IT-Fragen. Das sind Organisationsfragen.

Was ein Operating Model tatsächlich ist

Der Begriff klingt nach schwerem Beratungsframework. Gemeint ist etwas Nüchterneres: die Antwort auf eine Handvoll unspektakulärer Fragen. Wer entscheidet? Wer baut? Wer betreibt? Und wer steht gerade, wenn etwas schiefgeht?

Konkret braucht es dafür vier Dinge.

Rollen mit Namen. Jemand verantwortet AI als Ganzes, jemand verantwortet den einzelnen Anwendungsfall, jemand stellt Plattform und Sicherheit, jemand befähigt die Nutzer. Entscheidend ist nicht der Zuschnitt, sondern dass hinter jeder Rolle eine Person steht — nicht ein Gremium, nicht eine Abteilung, nicht ein geteiltes Postfach.

Echte Entscheidungsrechte. Es muss einen Ort geben, an dem ein Ja oder Nein fällt und danach gilt: eine Eingangstür für neue Vorhaben, ein Forum mit Mandat, ein Eskalationspfad. Viele Organisationen haben Gremien; deutlich weniger haben Gremien, die entscheiden dürfen. Der Unterschied ist der zwischen Steuerung und ihrer Simulation.

Ein Lebenszyklus statt eines Projektendes. Eine AI-Idee tritt ein, wird nach Risiko eingeordnet, freigegeben, gebaut, betrieben — und irgendwann bewusst beendet. Vor allem der letzte Schritt fehlt fast immer. Was kein definiertes Ende hat, sammelt sich an.

Gemeinsame Standards. Guardrails für Datenumgang, Prüfung und Freigabe, die für alle gelten. Nicht damit alles gleich aussieht, sondern damit nicht jede Initiative Sicherheit und Compliance neu erfinden muss — und damit die zwanzigste Freigabe so schnell gehen kann wie die zweite.

Der Denkfehler: Struktur als Bremse

Der häufigste Einwand gegen all das lautet: zu viel Bürokratie, wir wollen erst einmal Geschwindigkeit. Ich halte diesen Einwand für den teuersten Denkfehler in der ganzen Debatte, denn er verwechselt die Kosten der Struktur mit den Kosten ihrer Abwesenheit.

Ohne Operating Model wird jede Freigabe zum Einzelfall, den sich niemand zu entscheiden traut. Vorhaben warten nicht, weil jemand Nein gesagt hätte, sondern weil niemand das Mandat hat, Ja zu sagen. Fachbereiche bauen parallel dreimal dasselbe. Und die riskantesten Anwendungen entstehen dort, wo gerade niemand hinschaut — nicht aus Böswilligkeit, sondern weil der offizielle Weg keiner ist. Das Ergebnis ist das Schlechteste aus beiden Welten: langsam und unkontrolliert.

Die Organisationen, die AI wirklich skalieren, haben das Verhältnis umgedreht: Struktur ist bei ihnen nicht der Preis der Skalierung, sondern ihre Voraussetzung. Erst wenn Verantwortung, Entscheidungswege und Standards klar sind, kann eine Organisation zu vielen Dingen gleichzeitig Ja sagen, ohne die Kontrolle zu verlieren.

Leicht anfangen, gezielt härten

So grundsätzlich das klingt — der Einstieg darf klein sein. Der häufigste Fehler ist, das perfekte Operating Model entwerfen zu wollen, bevor irgendetwas in Betrieb ist. Der zweithäufigste ist, gar keines zu haben.

Der Weg dazwischen: mit dem Minimum starten. Eine Eingangstür für Vorhaben. Ein benannter Verantwortlicher pro Anwendungsfall. Eine einfache Risikoeinordnung mit kurzem Review. Mehr nicht. Struktur wird dann dort ergänzt, wo die Realität zeigt, dass sie fehlt — und nur dort. Jede Kontrolle muss sich ihren Platz verdienen, indem sie ein echtes Risiko oder eine echte Verzögerung beseitigt. Governance, die nicht auf das Problem zeigen kann, das sie löst, ist Reibung mit gutem Gewissen.

Dieses Vorgehen hat einen Nebeneffekt, der oft unterschätzt wird: Es macht Governance verhandelbar. Wer Fachbereichen erklären kann, warum eine Regel existiert und was sie verhindert, bekommt Akzeptanz. Wer nur auf ein Rahmenwerk verweist, bekommt Umgehung.

Woran man merkt, dass es trägt

Ein funktionierendes Operating Model erkennt man nicht an seiner Dokumentation, sondern an drei Alltagsbeobachtungen. Eine neue AI-Idee hat eine offensichtliche Eingangstür, einen offensichtlichen Owner und einen offensichtlichen Pfad — niemand muss erst herumfragen. Entscheidungen fallen dort, wo sie vorgesehen sind, und zwar zügig, weil die Kriterien vorher geklärt wurden. Und die Führung kann die Frage, die ihr am häufigsten gestellt wird — „Haben wir das im Griff?" — mit einem Ja beantworten, das einer Nachfrage standhält.

Dieses belastbare Ja ist mehr wert als jeder einzelne Use Case. Denn es ist die Bedingung dafür, dass aus verstreuten Experimenten eine betriebliche Fähigkeit wird: AI, die nicht von individuellem Heldentum abhängt, sondern einem bekannten Pfad folgt — vom ersten Piloten bis in den Regelbetrieb.

Kein Tool liefert das. Kein Modell-Update liefert das. Es ist die stille Infrastruktur aus Verantwortung, Entscheidungsrechten und Prozessen, auf der alles andere aufsetzt. Wer bei AI skalieren will, baut zuerst sie.