In den ersten beiden Teilen dieser Serie ging es um das einzelne AI-Feature: warum es Architektur braucht und welche Qualitätsfragen zu beantworten sind. Jetzt geht es um die Ebene darüber.
Mitarbeiter ohne Organigramm
In vielen Unternehmen arbeiten inzwischen Mitarbeiter, die auf keinem Gehaltszettel stehen. Sie tauchen in keinem Organigramm auf. Sie haben keinen Vorgesetzten, keine Stellenbeschreibung, kein Onboarding. Aber sie handeln im Namen des Unternehmens - lesen Kundendaten, klassifizieren Anfragen, bereiten Entscheidungen vor. Manche dürfen E-Mails versenden oder Zahlungen anstoßen.
Diese Mitarbeiter sind AI-Features. Chatbots, Klassifikatoren, Agenten. In den meisten Organisationen weiß niemand genau, wie viele es davon gibt. Und genau hier beginnt das Governance-Problem: Nicht bei der Technik, sondern bei der Frage, wie eine Organisation ihre AI-Systeme kennt, steuert und verantwortet.
Governance ist das Operating Model, das dezentrale AI-Entwicklung überhaupt erst skalierbar macht.
Shadow AI
Was gerade passiert, erinnert an Shadow IT: Fachabteilungen, die eigene Cloud-Accounts aufsetzen, ohne dass die IT davon weiß. Wie das in der Praxis aussieht, wenn Organisationen auf Einschränkung statt Enablement setzen, habe ich hier schon beschrieben. Heute bauen Teams AI-Features, nutzen Provider-APIs über private Accounts, speichern API-Tokens in .env-Dateien auf Entwickler-Laptops. Kein Datenschutzclearing, keine zentrale Sichtbarkeit, keine Kostenübersicht.
Das ist nachvollziehbar. Die Einstiegshürde ist niedrig, die Ergebnisse sind beeindruckend, und wer will schon auf eine Freigabe warten, wenn der Prototyp in zwei Stunden steht? Aber so entstehen AI-Systeme, die niemand inventarisiert, niemand regelmäßig testet und niemand verantwortet. Acht Leute bauen, niemand steuert.
Ein konkretes Szenario: Team A baut einen internen Summarizer über den privaten OpenAI-Account eines Entwicklers. Team B nutzt Claude für Support-Klassifikation, deployed über einen persönlichen Anthropic-Zugang. Team C testet einen Agenten mit Schreibzugriff auf das CRM. Dann schickt der Agent eine falsche Kundenbenachrichtigung. Wer ist Owner? Wer hat den Datenfluss freigegeben? Über welchen Account lief die Inferenz? Niemand kann es beantworten, weil es keinen Ort gibt, an dem diese Informationen zusammenlaufen.
Das Problem ist nicht, dass Teams AI-Features bauen. Das Problem ist, dass es kein Operating Model dafür gibt.
Das hatten wir schon
Wer die Microservices-Welle in Unternehmen miterlebt hat, kennt das Muster. Teams bauten Services, weil sie es konnten. Jedes Team seinen eigenen Tech-Stack, seine eigene Datenbank, sein eigenes Deployment. Irgendwann wusste niemand mehr, welche Services es gab, wer sie betrieb und was sie kosteten.
Die Antwort war nicht, Microservices zu verbieten. Die Antwort war Governance: Service-Kataloge, gemeinsame Plattformen, Observability-Standards, Team-Topologien. Die Teams behielten ihre Autonomie, aber die Organisation gewann Sichtbarkeit und Steuerungsfähigkeit zurück.
Bei AI-Systemen stehen wir an genau diesem Punkt. Nur dass die Konsequenzen schneller eintreten und weiter reichen. Ein schlecht geschnittener Service produziert technische Schulden. Ein unkontrollierter Agent kann Kundendaten an den falschen Provider schicken, fünfstellige Tagesrechnungen erzeugen oder Entscheidungen treffen, die niemand autorisiert hat.
Und man kann Governance nicht prompten. Einem Modell zu sagen, es soll verantwortungsvoll handeln, ist keine Sicherheitsarchitektur. Safety ist eine strukturelle Eigenschaft des Systems, keine Instruktion an das Modell.
Governance als Enablement
Governance hat einen schlechten Ruf. Es klingt nach Genehmigungsformularen und Innovation, die im Approval-Prozess stirbt. Aber das Gegenteil von unkontrollierter Proliferation ist nicht Verbot. Es ist Enablement.
In der Softwarearchitektur kenne ich das Prinzip aus Self-Contained Systems und Data Mesh: Dezentrale Verantwortung, zentrale Sichtbarkeit. Die Domain-Teams besitzen ihre Systeme, weil nur sie die Fachlichkeit verstehen. Aber es gibt gemeinsame Prinzipien, gemeinsame Infrastruktur und einen Ort, der den Überblick behält.
Wer dieses Prinzip auf AI-Features überträgt, kommt zu einem klaren Modell: Die Teams bauen und betreiben ihre AI-Features selbst, weil sie die Domäne kennen. Aber die Organisation stellt die Infrastruktur, die Standards und die Transparenz bereit, damit das nicht im Blindflug passiert.
Was die Organisation bereitstellen muss
Die Grundregel zuerst: Jedes produktive AI-Feature braucht einen fachlichen Owner, einen technischen Owner und eine definierte Eskalation. Ohne klare Ownership ist alles andere wirkungslos. Ownership ist kein Feld im Register, sondern die Voraussetzung dafür, dass jemand Verantwortung übernimmt, wenn etwas schiefgeht. Darauf aufbauend gibt es drei Bausteine.
Zugang und Kosten
Keine privaten Provider-Accounts, keine unkontrollierten API-Tokens. Ein zentraler Zugang zu Inference-Providern, mit Datenschutzverträgen und Kostentransparenz. Wer mit welchem Modell arbeitet, muss sichtbar sein.
Dazu ein Kosten-Dashboard mit Budget-Alerts: Jeder Token-Aufruf kostet, und die Kosten skalieren mit Input-Länge, Modellgröße und Aufrufhäufigkeit. Bei klassischer Software rechnet sich kaum jemand die Request-Kosten aus. Bei LLM-Inferenz kann ein Agent ohne Budget-Grenzen fünfstellige Tagesrechnungen erzeugen.
Standards und Qualitätssicherung
Ein SDK oder Pipeline-Vorlagen, die Observability, Monitoring und Eval-Frameworks mitbringen. Damit Teams nicht bei null anfangen, sondern von Tag eins an messen können, ob ihr Feature in Produktion funktioniert. Die zentrale Plattform liefert das Werkzeug, die Teams wenden es auf ihre Fachlichkeit an.
Transparenz und Steuerung
Ein AI-Feature-Register: Welche Features sind aktiv, wer ist Owner, welcher Provider, wann war der letzte Eval-Lauf, welche Daten fließen wohin. Self-Service für die Teams, aber zentral einsehbar.
Risikoklassen mit Freigaberegeln: Nicht jedes AI-Feature braucht dasselbe Governance-Level. Ein internes Zusammenfassungs-Tool ist etwas anderes als ein Agent mit Schreibzugriff auf Zahlungssysteme. Klare Klassen, welches Feature das Team selbst verantworten kann und welches ein Review braucht.
Und ein Incident-Prozess: Was passiert, wenn ein Agent Mist baut? Wer wird benachrichtigt, wer entscheidet über Rollback, wer kommuniziert? Das muss vor dem ersten Vorfall geklärt sein, nicht danach.
Der EU AI Act wird genau diese Transparenz in Europa einfordern. Wer jetzt die Strukturen aufbaut, macht das nicht nur für Compliance, sondern für die eigene Handlungsfähigkeit.
Struktur, nicht Handschellen
Zurück zu den unsichtbaren Mitarbeitern vom Anfang. Sie sind da, sie leisten Wertvolles, und das Potenzial ist real. Aber ohne Struktur - ohne Ownership, ohne Sichtbarkeit, ohne Leitplanken - wird aus Potenzial irgendwann Risiko. Nicht weil die Technik versagt, sondern weil niemand hinschaut.
Governance ist nicht der Preis, den Unternehmen für AI zahlen. Sie ist die Bedingung dafür, dass AI-Features außerhalb des Prototyps verantwortbar skalieren können.
Weiterlesen:
AI Systems Architecture - Warum AI-Features mehr brauchen als gute Prompts (Teil 1)
AI Systems Architecture: Die Qualitätsfragen - Qualitätsattribute auf Feature-Ebene (Teil 2)