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 ueberfuehrt 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 veraendert sich der Alltag kaum. Der Grund: Die Experimente sind nicht mit Prozessen, Daten, Verantwortung und Metriken verbunden.
Eine Roadmap muss deshalb Arbeit veraendern, nicht nur Software einfuehren.
Stand Mai 2026: Transformation braucht Governance und Evals NIST AI RMF strukturiert AI-Risikomanagement ueber Govern, Map, Measure und Manage. ISO/IEC 42001 beschreibt ein AI-Management-System fuer Organisationen, also Policies, Ziele und Prozesse fuer verantwortliche Entwicklung, Bereitstellung oder Nutzung von AI-Systemen. Microsofts Cloud Adoption Framework fuer 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 grundsaetzlich ab 2. August 2026.
Das veraendert 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. Fuer 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 frueh.
AI-Inventar: vorhandene Tools, Schattennutzung, Datenquellen und Risiken. Prozesskarte: wiederkehrende Wissensarbeit mit Volumen, Kosten und Risiko. Use-Case-Score: Wert, Machbarkeit, Datenqualitaet, 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-Faelle, 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 muessen mitgeprueft 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 fuer einen klaren Prozess. Golden Set mit echten Normal-, Grenz- und Fehlerfaellen. Trace- und Kostenlogging. Human-in-the-loop fuer riskante Aktionen. Retrieval-/Datenqualitaets-Checks. Go-/No-Go-Kriterien fuer 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 geklaert, Reports eingerichtet und Rechte vorsichtig erweitert.
Am Ende gibt es nicht nur einen Agenten, sondern ein Muster fuer weitere Agenten.
Output nach 90 Tagen:
Die entscheidende Metrik ist nicht Anzahl der AI-Tools. Die entscheidende Metrik ist uebernommene, messbare Arbeit bei kontrolliertem Risiko.
Agent in echtem Workflow, nicht nur Demo. Dashboard fuer Nutzung, Kosten, Fehler, Freigaben und Business-Ergebnis. Release-Prozess fuer Prompt-, Tool-, Modell- und Datenquellenaenderungen. Incident-Prozess fuer falsche Antworten, Datenlecks, Tool-Fehler und Policy-Verletzungen. Backlog fuer naechste 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 fuer Agentenbetrieb.
Hat der Prozess genug Volumen? Sind Input und Output klar genug? Gibt es zulaessige 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 fuer mehr Autonomie.
Agentenregister. Tool-Rechte. Datenklassen. Approval-Regeln. Eval-Schwellen. Tracing und Audit. Kostenlimits. Incident- und Rollback-Prozesse. AI-Act- und AI-Literacy-Gate Fuer EU-nahe Unternehmen gehoert AI Literacy seit dem 2. Februar 2025 in die Roadmap. Teams muessen verstehen, wo AI eingesetzt wird, welche Grenzen gelten und wann menschliche Pruefung noetig 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 auffaelligsten Tool starten statt mit Prozesswert. keine Baseline fuer Zeit, Kosten und Qualitaet messen. keine Evals vor dem Pilot. Datenrechte im Prompt statt in Architektur regeln. keine Owner fuer 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 fuer das Unternehmen.
