AI Architecture · 13 Min.
AI Transformation Roadmap: 90 Tage, um aus KI-Experimenten ein echtes Betriebssystem zu bauen
KI-Transformation scheitert selten an Ideen. Sie scheitert daran, dass Experimente nicht in ein messbares Betriebssystem überführt werden.
SYSTEMS Grafik zu AI Transformation Roadmap: Data -> Agent -> Outcome. Fokus: Wie Unternehmen in 90 Tagen von KI-Experimenten zu produktiven Agenten und Betrieb kommen.
Kurzfassung
KI-Transformation braucht weniger Ideen und mehr Umsetzungssystem. In 90 Tagen kann ein Unternehmen Use Cases priorisieren, erste Agenten bauen und Governance etablieren. Der Fokus muss auf messbarer Arbeit liegen, nicht auf Tool-Sammlungen.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum viele KI-Initiativen stecken bleiben Es gibt Workshops, Tool-Tests, Prompt-Sammlungen und einzelne Automationen. Trotzdem verändert sich der Alltag kaum. Der Grund: Die Experimente sind nicht mit Prozessen, Daten, Verantwortung und Metriken verbunden.
Eine Roadmap muss deshalb Arbeit verändern, nicht nur Software einführen.
Stand Mai 2026: Transformation braucht Governance und Evals NIST AI RMF strukturiert AI-Risikomanagement über Govern, Map, Measure und Manage. ISO/IEC 42001 beschreibt ein AI-Management-System für Organisationen, also Policies, Ziele und Prozesse für verantwortliche Entwicklung, Bereitstellung oder Nutzung von AI-Systemen. Microsofts Cloud Adoption Framework für AI fordert Strategie, Use-Case-Priorisierung, Data Governance, Accountability und Governance-Policies. Der EU AI Act ist bereits in Teilen anwendbar: AI-Literacy-Pflichten und Verbote gelten seit 2. Februar 2025; GPAI-/Governance-Regeln seit 2. August 2025; volle Anwendbarkeit grundsätzlich ab 2. August 2026.
Das verändert die Roadmap. AI-Transformation ist nicht mehr "wir probieren Tools". Sie braucht Inventar, Risikoklassen, Use-Case-Priorisierung, Evaluation, Governance und Betrieb.
Tage 1 bis 30: Use Cases und Architektur Zuerst werden Prozesse gescannt: Wo entsteht wiederkehrende Wissensarbeit? Wo gibt es klare Inputs und Outputs? Wo ist Risiko kontrollierbar?
Aus zehn Ideen werden drei priorisierte Use Cases. Für jeden Use Case entstehen Ziel, Datenquellen, Rechte, Erfolgsmessung und Risiko. Danach ist klar, welcher erste Agent wirklich gebaut werden sollte.
Diese 30/60/90-Struktur ist keine Norm. Sie ist eine Umsetzungsschablone aus NIST, ISO, Microsoft CAF, OpenAI-Evals und EU-AI-Act-Zeitplan. Genau deshalb funktioniert sie besser als ein Tool-Rollout: Sie zwingt Strategie, Governance und Engineering in dieselbe Reihenfolge.
Output nach 30 Tagen:
Die wichtigste Entscheidung in Monat 1 ist oft, was nicht gebaut wird. Ein guter 90-Tage-Plan killt schlechte Use Cases früh.
AI-Inventar: vorhandene Tools, Schattennutzung, Datenquellen und Risiken. Prozesskarte: wiederkehrende Wissensarbeit mit Volumen, Kosten und Risiko. Use-Case-Score: Wert, Machbarkeit, Datenqualität, Risiko, Time-to-Proof. Zielarchitektur: Modelle, Tools, Daten, Gateway, Logs und Rechte. Governance-Entwurf: Owner, Freigaben, verbotene Aktionen und Review-Rhythmus. Tage 31 bis 60: Prototyp mit Evals Der erste Agent startet eng: lesen, strukturieren, vorschlagen. Parallel entstehen Eval-Fälle, Logging, Kostenlimits und Freigaberegeln.
Das Ziel ist kein perfektes Interface. Das Ziel ist Beweis: Spart der Agent echte Arbeit und bleibt er innerhalb der Grenzen?
Output nach 60 Tagen:
OpenAI Agent Evals und Trace-Grading sind hier wichtig, weil nicht nur Antworten bewertet werden. Tool Calls, Handoffs, Guardrails und Entscheidungspfade müssen mitgeprüft werden.
OpenAI weist in Evaluation-Guidance darauf hin, dass generative Systeme variabel sind und klassische deterministische Tests nicht reichen. NISTs GenAI-Profil fordert Go-/No-Go-Schwellen und interne sowie externe Evaluierungen vor Deployment. Ein Pilot ohne Eval-Schwellen ist deshalb kein Pilot. Er ist eine Demo.
Ein produktnaher Agent für einen klaren Prozess. Golden Set mit echten Normal-, Grenz- und Fehlerfällen. Trace- und Kostenlogging. Human-in-the-loop für riskante Aktionen. Retrieval-/Datenqualitäts-Checks. Go-/No-Go-Kriterien für mehr Rechte. Tage 61 bis 90: Rollout und Betrieb Wenn der Agent stabil ist, wird er in den Arbeitsfluss eingebettet: CRM, Portal, Tickets, Dokumente oder interne Review-Queue. Rollen werden geklärt, Reports eingerichtet und Rechte vorsichtig erweitert.
Am Ende gibt es nicht nur einen Agenten, sondern ein Muster für weitere Agenten.
Output nach 90 Tagen:
Die entscheidende Metrik ist nicht Anzahl der AI-Tools. Die entscheidende Metrik ist übernommene, messbare Arbeit bei kontrolliertem Risiko.
Agent in echtem Workflow, nicht nur Demo. Dashboard für Nutzung, Kosten, Fehler, Freigaben und Business-Ergebnis. Release-Prozess für Prompt-, Tool-, Modell- und Datenquellenänderungen. Incident-Prozess für falsche Antworten, Datenlecks, Tool-Fehler und Policy-Verletzungen. Backlog für nächste Agenten nach bewiesenem Muster. Der 90-Tage-Entscheidungsfilter Jeder Use Case muss sechs Fragen bestehen:
Wenn eine Antwort fehlt, ist der Use Case vielleicht interessant, aber nicht reif für Agentenbetrieb.
Hat der Prozess genug Volumen? Sind Input und Output klar genug? Gibt es zulässige Datenquellen? Kann Erfolg objektiv gemessen werden? Kann Risiko durch Rechte, Review und Rollback begrenzt werden? Gibt es einen Owner, der Betrieb und Fehler verantwortet? Governance ohne Blockade Governance darf kein PDF-Friedhof werden. Sie muss in die Runtime:
So wird Governance nicht zum Bremser. Sie wird zur Bedingung für mehr Autonomie.
Agentenregister. Tool-Rechte. Datenklassen. Approval-Regeln. Eval-Schwellen. Tracing und Audit. Kostenlimits. Incident- und Rollback-Prozesse. AI-Act- und AI-Literacy-Gate Für EU-nahe Unternehmen gehört AI Literacy seit dem 2. Februar 2025 in die Roadmap. Teams müssen verstehen, wo AI eingesetzt wird, welche Grenzen gelten und wann menschliche Prüfung nötig ist.
Nicht jeder Agent ist Hochrisiko. Aber jede Roadmap braucht eine Klassifikation: betroffene Personen, Zweck, Daten, Entscheidungsauswirkung, Rechtsgebiet und eingesetzte Modelle.
Typische Fehler mit dem auffälligsten Tool starten statt mit Prozesswert. keine Baseline für Zeit, Kosten und Qualität messen. keine Evals vor dem Pilot. Datenrechte im Prompt statt in Architektur regeln. keine Owner für Agent, Daten, Risiko und Betrieb. nach der Demo keinen Rollout-Prozess bauen. Der SYSTEMS-Blick Wir bauen AI Transformation als Architekturprogramm. Kleine Agenten, klare Metriken, Governance von Anfang an und ein Rollout, der aus jedem Use Case ein wiederholbares System macht.
So entsteht aus Experimenten ein AI Operating System für das Unternehmen.
