grok-bot
63589e684a
AI Act/OWASP und Residenz/Log-TTL in Kap. 19–20, Framing- und Taxonomie-Fixes quer durch Manuskript und Templates, Kap.-10-Anker im Assembler; Handoff fortgeschrieben.
15 KiB
Reifegradmodell
Zwei Teams im gleichen Unternehmen. Team A hat ein „AI-Center-of-Excellence“, Folien mit fünf Stufen und einem farbigen Heatmap-Dashboard. Team B hat einen Ticket-Summarizer mit Feature-Spec, 40 Golden-Set-Fällen, Model-Pin und einem On-Call-Namen im README. Die Heatmap sagt „Level 3“. Der Summarizer überlebt ein Provider-Update ohne Ticketsturm. Die Frage ist nicht, welche Folie hübscher ist — sondern welche Capability belastbar ist.
Reife ist kein Firmen-Label und kein CMMI-Theater. Sie ist der minimal ehrliche Zustand, den eine einzelne AI-Capability (ein Job-to-be-done mit Modell im Pfad) erreicht hat: spezifiziert, messbar, betreibbar, verantwortet.
Kern in einem Satz: Miss Reife pro Capability entlang Spec, Eval, Betrieb, Security, Cost und Ownership — steige Level für Level, statt die Organisation global auf „Production AI“ zu stempeln (T3, T7, T9, T10).
Dieses Kapitel verdichtet Teil IV–VI zu einem Assessment und Level-up-Plan. Dimensionen im Detail: 17–25; Org und Ownership: 26–27. Checkliste Einstieg: team-onboarding-30-tage.md. Production-Gate: production-ready-checklist.md.
Bridge: Klassisches SE → AI Engineering
| Klassisches SE | AI-Capability-Reife … |
|---|---|
| Capability Maturity (Prozess) | Capability-Zustand am Feature, nicht an der Firma |
| Definition of Done | Spec + Eval-Gate + Owner + Rollback-Pfad |
| Test pyramid / CI | Golden Set, Offline-Gates, Online-Signale |
| SLO + Error Budget | Quality-, Cost- und Latency-Ziele in der Spec |
| Dependency management | Model-Pin, Canary, Change als Breaking Change (T9) |
| On-Call + Runbooks | inkl. Quality-Drop, Cost-Spike, Safety |
| Portfolio / Platform | geteilte Harness, Eval-Infra, Standards — erst wenn Slices laufen |
Die Brücke: Reifegrade helfen, Investition und Risiko zu steuern. Sie ersetzen weder Architekturentscheidungen noch Produktverantwortung.
Levels 0–4
Pragmatisch, nicht zertifizierbar. Level pro Capability — ein Chat-Pilot kann Level 0 sein, während der interne Classifier Level 3 fährt.
| Level | Kurzname | Kennzeichen |
|---|---|---|
| 0 | Demo / Chaos | Prompt im Code, kein Eval, latest, keine Ownership |
| 1 | Spec & Baseline | Feature-Spec, kleines Golden Set, Model-Pin, Feature-Flag |
| 2 | Engineered Slice | Structured Output / Tools / RAG nach Bedarf, Offline-Gates, Basis-Obs, Security einmal reviewed |
| 3 | Production Discipline | Online-Quality-Signale, SLOs, Canary/Model-Change, Runbooks, Cost Attribution |
| 4 | Portfolio & Learning | Multi-Capability-Plattform, systematisches Drift-Handling, Org-Lernen, Reife-Reviews |
Level 0 — Demo / Chaos
Was du hast: etwas, das in der Demo beeindruckt. Oft ein Prompt, ein SDK-Call, vielleicht ein Chat-UI.
Was fehlt: messbare Erfolgskriterien (T3), Versionierung, Budget, Security-Threat-Model, Owner. latest-Aliases und Hotfixes im Prompt ohne Review.
Nächster Schritt: stoppt den Prod-Claim. Schreibt eine Spec (templates/ai-feature-spec.md), pinnt das Modell, legt 20–50 Golden-Fälle an, benennt einen Owner. Ziel: Level 1 in Tagen bis wenigen Wochen — nicht „Plattform bauen“.
Level 1 — Spec & Baseline
Was du hast: Job-to-be-done, Success/Failure, grobes Cost Envelope; kleines Golden Set; Feature-Flag; Model- und Prompt-Version im Repo.
Was fehlt: CI-Gate, harte Validierung, Tracing, Security-Review, Online-Signale. Qualität lebt noch im Bauchgefühl der Demo-Personen.
Nächster Schritt: Offline-Eval in den Merge-Pfad; Structured Output oder klare Tool-Contracts wo nötig; Observability-Minimum (checklists/observability-minimum.md); Security-Review einmal ehrlich (checklists/security-review-ai.md).
Level 2 — Engineered Slice
Was du hast: Adaptation passend zur Ladder (08); Offline-Gates blocken Regressionen; Traces mit Versionen und Tokens; Security/Privacy einmal freigegeben; Fallbacks skizziert.
Was fehlt: Online-Quality als Steuergröße, formelle SLOs, Canary-Stop-Regeln, Cost pro Task, Incident-Runbook, regelmäßiger Model-Change-Prozess.
Nächster Schritt: Online-Proxies und Alerts (18); Unit Economics und Caps (23); Model-Change-Checklist (templates/model-change-checklist.md); Incident-Runbook (templates/incident-runbook-ai.md). Production-Ready abhaken, nicht „fast live“.
Level 3 — Production Discipline
Was du hast: Spec-gekoppelte Online-Signale; SLOs inkl. Qualität und Cost; Shadow/Canary vor riskanten Changes; Runbooks und On-Call; Cost Attribution pro Capability; Rollback geübt (T7, T9).
Was fehlt (typisch): Wiederverwendung über Capabilities, systematisches Feedback→Golden-Set, Org-weite Standards, periodische Reife-Reviews, Cross-Team-Lernen aus Incidents.
Nächster Schritt: nur wenn mehrere Capabilities Level 2–3 tragen und Shared Pain real ist: gemeinsame Eval-Infra, Policy-Bibliothek, Platform-SLAs — nicht vorher „AI Platform“ ausrufen (27).
Level 4 — Portfolio & Learning
Was du hast: mehrere produktive Capabilities auf gemeinsamen Harness- und Eval-Standards; Drift und Model-Updates als wiederkehrender Prozess; Postmortems füttern Specs und Golden Sets; periodische Maturity-Reviews mit Owners (T10).
Was fehlt (ehrlich): Level 4 ist kein Endzustand. Neue Capabilities starten oft wieder bei 0–1. Portfolio-Reife heißt: der Einstiegspfad ist kurz und standardisiert, nicht dass jedes Experiment sofort Level 3 ist.
Nächster Schritt: Level-up der schwächsten geschäftskritischen Capability; Shadow-AI (Level-0 in der Fläche) finden und entweder killen oder auf Level 1 heben.
Self-Assessment (pro Capability)
Score pro Frage: 0 = nein / unbekannt, 1 = teilweise / informell, 2 = ja und nachweisbar (Link, Dashboard, PR, Runbook). Max. 30 Punkte. Nutzt die Summe nur als Priorisierungshilfe, nicht als Zertifikat.
| # | Frage | Dimension |
|---|---|---|
| 1 | Gibt es eine Feature-Spec mit messbaren Success- und Failure-Kriterien? | Spec |
| 2 | Existiert ein Golden Set mit Baseline und bekannter Pflege-Regel? | Eval |
| 3 | Blockt CI (oder Release-Gate) bei Eval-Regression? | Eval |
| 4 | Sind Model- und Prompt-Versionen gepinnt und im Trace sichtbar? | Lifecycle |
| 5 | Gibt es Online-Quality-Signale (nicht nur HTTP/Latency)? | Obs |
| 6 | Sind Cost und Latency pro Task (oder klarer Proxy) sichtbar und budgetiert? | Cost |
| 7 | Wurde Security (Injection, Leakage, Tool Abuse) reviewed und mitigiert? | Security |
| 8 | Sind Privacy/Retention/Residenz für Logs und Context geklärt? | Security |
| 9 | Gibt es Canary/Shadow- oder gleichwertigen Change-Prozess für Model/Prompt? | Lifecycle |
| 10 | Existiert ein Incident-Runbook für Quality/Cost/Safety und ein On-Call? | Incidents |
| 11 | Ist ein namentlicher Owner für Prompt, Eval, Model und On-Call benannt? | Ownership |
| 12 | Gibt es Feature-Flag / Kill-Switch und geübten Rollback? | Lifecycle |
| 13 | Werden Production-Feedback und Failures ins Golden Set zurückgeführt? | Eval |
| 14 | Sind SLOs (Qualität und/oder Cost) spezifiziert und alarmiert? | Cost / Obs |
| 15 | Wurde der letzte Model- oder Prompt-Change ohne Bauchgefühl freigegeben? | Lifecycle |
Grobe Einordnung (Richtwert, nicht Gesetz):
| Score | Typisch nahe |
|---|---|
| 0–6 | Level 0 |
| 7–12 | Level 1 |
| 13–18 | Level 2 |
| 19–24 | Level 3 |
| 25–30 | Richtung Level 4 (wenn mehrere Capabilities so stehen) |
Ehrlichkeitsregeln:
- Score pro Capability, nie „die Firma ist Level 3“.
- 2 nur mit Nachweis. Folie ohne Golden Set = Theater.
- Fehlende Owner (Frage 11) deckeln praktisch alles andere: ohne T10 bleibt Level-Jump Papier.
- Kritische Klassen (Gelb/Rot an der Ampel, 05) brauchen höhere Latte bei Security und Human-in-the-loop — auch wenn der Score „mittel“ wirkt.
Patterns und Trade-offs
Pattern: Eine Capability, ein Level, ein Owner
Portfolio-Heatmaps ohne Owner erzeugen Verantwortungsdiffusion. Besser: Top-3-Capabilities mit Score, Level, nächstem Schritt und Namen.
Pattern: Level-up über Gates, nicht über Headcount
Mehr Prompt-Engineers heben Level 0 nicht. Ein Golden Set und ein CI-Gate schon. People skalieren, was messbar ist.
Trade-off: Speed vs. Level-Jump
| Strategie | Wann sinnvoll | Risiko |
|---|---|---|
| Slice halten (0→1→2 in einem Feature) | Default; Lernkurve; Vertrauensaufbau | langsamer sichtbarer „AI-Footprint“ |
| Parallele Demos (viele Level 0) | Exploration, intern, klar als Demo gelabelt | Shadow AI, Incidents, Compliance-Überraschung |
| Big-bang Platform (sofort Level 4-Infra) | selten; nur bei nachgewiesenem Shared Pain | leere Plattform, keine produktive Capability |
| Selective Level-3 (eine kritische Capability) | Revenue/Safety-kritisch | andere Capabilities bleiben Chaos — explizit listen |
Regel: Springt nicht zwei Level in einem Quartal und drei Features gleichzeitig. Wählt eine Top-Capability für den Level-up; der Rest bekommt höchstens Hygiene (Pin, Flag, Owner).
Decision Frame: Was als Nächstes?
- Business-kritisch und Level ≤ 1 → sofort Spec + Eval + Pin.
- Level 2 und Live-Traffic → Online-Signale und Cost vor „Agent-Umbau“.
- Mehrere Level-2/3 mit doppelter Eval-Arbeit → Platform-Invest prüfen.
- Level 0 im Schatten (Slack-Bots, private Keys) → Visibility und Kill-or-Level-1.
90-Tage-Plan (eine Top-Capability)
Ziel: von ehrlichem Assessment zu einem Level-up (Heuristik: oft 0→2 oder 1→3 in ~90 Tagen — Bandbreite je nach Scope und Teamgröße), nicht zur Transformation der gesamten Org. Onboarding-Takt fürs Team: checklists/team-onboarding-30-tage.md.
Tage 1–30 — Sichtbarkeit und Baseline
- Capability wählen (Impact × Risiko × Traffic).
- Self-Assessment (Tabelle oben) mit Nachweisen, nicht mit Hoffnung.
- Spec vervollständigen; Golden Set anlegen oder bereinigen; Model pin; Feature-Flag.
- Owner-Matrix: Prompt / Eval / Model / On-Call (26).
- Security-Light-Pass: Threat-Model-Skizze, Logging-Redaction.
- Exit: Score und Level notiert; Demo-Status ehrlich kommuniziert.
Tage 31–60 — Engineered Slice
- Offline-Eval im CI; Structured Output / Validation wo der Contract es verlangt.
- Observability-Minimum: Trace-IDs, Versionen, Tokens, Outcomes.
- Adaptation-ADR falls noch Luftnummern (templates/adr-adaptation.md).
- Production-Ready-Checklist einmal hart durchgehen.
- Exit: Merge ohne grünes Eval ist blockiert; Staging trägt den Slice.
Tage 61–90 — Production Discipline (soweit nötig)
- Online-Proxies + Alarme an Spec-Schwellen.
- Cost-Dashboard und Budget-Cap.
- Model-Change- und Incident-Runbook; ein Canary- oder Shadow-Pfad geübt (auch wenn „nur“ Prompt-Change).
- Retro: welche Anti-Patterns greifen noch? Shadow AI im Umkreis?
- Exit: Capability ist Level 2 oder 3 mit Nachweis; nächste Capability priorisiert — nicht fünf parallel.
Anti-Patterns
| Anti-Pattern | Symptom | Besser |
|---|---|---|
| Maturity theater | Folien, Heatmaps, kein Golden Set | Score nur mit Nachweis |
| Level-shopping | „Wir sind Level 3, weil Canary-Tool lizenziert“ | Capability-Assessment, nicht Tool-Liste |
| One-size-fits-all | gleiches Level-Ziel für Demo und Payments | Ampel + Risiko steuern Latte |
| Ignore Level-0 shadow AI | private Keys, Schatten-Bots | Inventory, Flag, Kill-or-Level-1 |
| Score without owners | hohe Punktzahl, niemand On-Call | T10 vor T3-Feinschliff |
| Platform before slice | leere Eval-Infra, null Prod-Features | eine Capability auf Level 2 |
| Eternal pilot | seit Monaten „PoC“, schon Kunden-Traffic | Level 1-Mindeststandard oder abschalten |
| Global company level | „Org ist Level 2“ | Matrix: Capability × Level × Owner |
Production Notes
Cost. Jeder Level-up kostet Engineering-Zeit und häufig spürbar mehr Eval-/Shadow-Aufwand (Bandbreite: von „etwas mehr CI“ bis grob doppelter Lauf — je nach Suite und Canary). Das ist Feature-Invest (T7), kein Overhead-Schönwetter. Cost Attribution ab Level 2–3 verhindert, dass „AI“ ein ungedecktes Kostenkonto bleibt.
Latency / SLO. Reife ohne Latency- und Quality-SLO ist Betriebsfolklore. Schwellwerte aus der Spec, nicht aus Branchenmythen.
Observability. Ohne Versionsfelder in Traces sind Level-3-Claims unhaltbar: ihr könnt Changes nicht den Outcomes zuordnen (22).
Security. Level-Sprünge ohne Security-Review sind Scheinreife. Kritische Tools und PII-Context erzwingen Guardrails unabhängig vom Marketing-Level (19, 20).
Lifecycle. Model-Updates sind Breaking Changes (T9). Ab Level 2 muss der Change-Pfad existieren; ab Level 3 muss er geübt sein.
Ownership. Reife ohne Owner ist ein Dashboard für Zuschauer (T10). Incidents und Model-Changes brauchen Namen, nicht Gremien allein.
Key Takeaways
- Reife misst ihr pro Capability, nicht als Firmenstempel.
- Levels 0–4: Demo → Spec/Baseline → Engineered Slice → Production Discipline → Portfolio & Learning.
- Self-Assessment nur mit Nachweis; Owner-Fragen deckeln den Rest.
- Ein 90-Tage-Plan levelt eine Top-Capability — Speed schlägt Level-Jump auf breiter Front.
- Anti-Patterns: Theater, Level-Shopping, Shadow AI ignorieren, Plattform vor Slice.
- T3, T7, T9, T10 sind die Härtetests: messbar, budgetiert, change-sicher, verantwortet.
Praktische nächste Schritte
- Listet eure AI-Capabilities (inkl. Schatten) und wählt eine Top-Capability für die nächsten 90 Tage.
- Führt das 15-Fragen-Assessment mit Nachweisen durch; notiert Level und Top-3-Lücken.
- Schließt Level-1-Hygiene: Spec, Pin, Flag, Owner, kleines Golden Set.
- Plant 30/60/90 gegen die Lücken; Team-Takt: team-onboarding-30-tage.md.
- Hakt vor Go-Live production-ready-checklist.md ab — nicht die Heatmap.
- Weiter: Reprise und Ausblick in Schluss und Ausblick.