grok-bot
ea82f772ad
Tippfehler-Cluster (02–05, 09, 12, 23, 27–28) und Terminologie (Outcomes 16↔18, Budget 16↔23, prompt_version, Coding-Agent, fester Workflow). Handoff: Git-Remote, P0/P1A/P1B erledigt, nächster Slice Faktencheck.
15 KiB
Einführung im Unternehmen
Q3-Review: zwölf „AI-Pilots“ auf der Slide. Drei Teams bauen denselben Support-Bot mit drei Providern. Legal fragt nach Datenresidenz — niemand hat eine Antwort mit Owner. Finance sieht drei Rechnungen und eine Forecast-Lücke. Security hört von dem Projekt erst, weil ein Praktikant Keys in einem Repo gefunden hat. Ownership? „Das treibt die AI-Initiative.“ Kosten? „Noch Pilot.“ Produktisierung? „Nächstes Quartal.“
Das ist kein Technologieproblem. Es ist ein Einführungsproblem: Demo-Theater ohne Phasen, Exit-Kriterien und gemeinsame Betriebsdisziplin.
Kern in einem Satz: Unternehmensweite AI-Einführung gelingt als Pilot → Platform → Productization — mit messbaren Exit-Kriterien, klarem Ownership und einer gemeinsamen Harness-Schicht; Disziplin schlägt Demo-Theater.
Anschluss: Ampel und Schnitt → Kapitel 05; Spec → Kapitel 06; Architektur und Adaptation → Kapitel 07, Kapitel 08; Eval → Kapitel 17; Team-Ownership → Kapitel 26. Vorlagen: templates/ai-feature-spec.md, templates/adr-adaptation.md, templates/production-ready-checklist.md, checklists/team-onboarding-30-tage.md.
Bridge: Klassisches SE → AI Engineering
Unternehmen führen nicht „AI“ ein, sondern Capabilities mit probabilistischer Runtime — vergleichbar mit einer neuen Klasse kritischer Integrationen, nicht mit einem einmaligen Tool-Rollout.
| Klassisches SE / Org | AI-Einführung … |
|---|---|
| Proof of Concept mit Scope und Kill-Kriterien | Pilot mit Spec, Eval-Baseline, Feature-Flag, Ampel |
| Shared Platform (Auth, Logging, Deploy) | gemeinsame Harness-Schicht (Trace, Route, Cap, Guardrail, Pin, Eval) |
| Productization: SLO, On-Call, Runbook | plus Quality-SLO, Cost Envelope, Model-Change |
| Architecture Decision Records | ADRs für Adaptation, Hosting, Data Classes |
| Buy vs. Build | Buy (API-Modelle) / Build (Orchestrierung) / Embed (Vendor-UI) ehrlich trennen |
| CoE vs. embedded Platform | Enablement und Standards — nicht Ticket-Bottleneck |
| Security Review vor Prod | auch im Pilot, sobald Daten/Tools/Keys im Spiel sind |
| Portfolio-Steuerung | weniger parallele Pilots, mehr Productization |
Die Brücke: ihr skaliert Engineering-Disziplin (Spec, Test, Ops, Ownership), nicht die Anzahl der Chat-Demos.
Phasenmodell: Pilot → Platform → Productization
Drei Phasen, klar getrennt. Wer alles parallel „skaliert“, skaliert Chaos.
Phase 1 — Pilot
Ziel: Ein Job-to-be-done, realer Nutzer-Schnitt, Lerngewinn mit begrenztem Risiko — kein „AI-Programm“.
| Element | Minimum |
|---|---|
| Scope | ein JTBD; Out-of-Scope geschrieben |
| Ampel | aus Kapitel 05; Rot = stoppen oder hybrid ohne LLM-Kern |
| Spec | ai-feature-spec.md: Success, Failures, Cost/Latency, Privacy |
| Eval | Golden-Baseline vor Feature-Creep (Kapitel 17) |
| Risk | Feature-Flag, kleine Population, begrenzte Wirkungsebene |
| Ownership | named: Feature, Eval, On-Call-Kontakt (Kapitel 26) |
| Stakeholder light | Eng + Product; Legal/Security/Finance früh informiert, nicht erst bei Go-Live |
Exit-Kriterien (Pilot bestanden):
- Spec und Ampel dokumentiert und reviewt.
- Offline-Eval reproduzierbar; Baseline nicht schlechter als vereinbartes Minimum.
- Cost und Latency unter Envelope bei realistischer Stichprobe.
- Kill-Switch und Rollback des Pins funktionieren.
- Entscheidung: stoppen, iterieren im Pilot, oder Productization vorbereiten — schriftlich.
Exit „gescheitert“ ist Erfolg, wenn ihr teuren Weiterbau verhindert. Ein Pilot ohne Stopp-Option ist Marketing.
Phase 2 — Platform (Harness, nicht „ein Bot“)
Ziel: Wiederkehrende Ops-Schmerzen zentral lösen, ohne Produkt-Logik und Domain-Ownership zu zentralisieren.
Platform ist nicht „ein Chatbot für alle Abteilungen“. Platform ist die gemeinsame Harness-Schicht um Foundation Models:
| Baustein | Warum zentral / geteilt |
|---|---|
| Tracing + Token-Accounting | ohne Versionen und €/Request kein Betrieb (Kapitel 22) |
| Model-Routing + Caps | Tiers, Budget, Fallback (Kapitel 09, 23) |
| Guardrails Input/Output | Injection, Leakage, Policy-Hooks (Kapitel 19) |
| Pin-Registry | kein latest quer durch Repos (Kapitel 24) |
| Eval-Runner / Golden-Gate in CI | gleiche Qualitätsdisziplin pro Capability |
| Secrets, Residenz, Vendor-Contracts | einmal sauber, oft falsch im Team-Silo |
Exit-Kriterien (Platform nützlich):
- Mindestens zwei Produkt-Teams nutzen dieselbe Harness-Schicht.
- Neues Feature: Trace, Cap, Pin und Mini-Eval ohne Copy-Paste-Boilerplate.
- Platform-Team misst Adoption und Time-to-safe-slice — nicht nur Ticket-Backlog.
- Domain-Prompts und Specs bleiben bei den Capability-Teams.
Phase 3 — Productization
Ziel: Aus „läuft im Flag“ wird betriebenes Produkt.
| Element | Inhalt |
|---|---|
| SLOs | Latency/Availability plus Quality (Task Success, Safety, Repair-Rate) |
| On-Call | Runbook, SEV-Klassen, Kill-Switches (Kapitel 25) |
| Cost Envelope | Alerts, Caps, Unit Economics im Review |
| Security & Privacy | Review bestanden; Data Classes; Logging redacted (Kapitel 20) |
| Lifecycle | Model-Change-Checklist, Canary, Rollback-Pfad |
| Checklist | production-ready-checklist.md grün |
Exit-Kriterien (productized):
- Production-Ready-Check abgehakt mit Owner-Datum.
- Quality- und Cost-Signale im Dashboard; Alerts mit Runbook-Link.
- On-Call weiß, wie man degradiert (Flag / Cap / Pin / Tools off).
- Model- oder Prompt-Change geht nicht live ohne Gate.
Ohne Productization bleiben Pilots Schatten-Prod — mit Prod-Risiko und Pilot-Ausrede.
Stakeholder ohne Org-Chart-Theater
Rollen nach Entscheidung, nicht nach Jobtitel-Inflation:
| Rolle | Entscheidet / liefert |
|---|---|
| Engineering | Orchestrierung, Harness-Nutzung, Eval-Automation, Observability |
| Product | JTBD, Scope, UX der Degrade-Pfade, Priorisierung der Pilots |
| Legal / Privacy | erlaubte Datenflüsse, Residenz, Retention, Vendor-Verträge (Rahmen) |
| Security | Threat Model, Keys, Tool-Permissions, Safety-Eskalation |
| Finance | Budget Caps, Forecast, Unit Economics — nicht nur Jahres-PO |
Ein wöchentliches 30-Minuten-Capability Board (Top-Pilots, Ampel, Cost, Blocker) schlägt ein 40-Seiten-„AI Strategy Deck“ ohne Specs.
Buy vs. Build vs. Embed
| Option | Was ihr kauft / baut | Wann ehrlich |
|---|---|---|
| Buy | API-Modelle, ggf. Managed Eval/Obs | Standard-Capabilities; ihr wollt keine GPU-Ops |
| Build | Orchestrierung, Spec, Eval, Guardrails, Domain-Tools | Differenzierung und Kontrolle liegen in eurem Control Flow |
| Embed | Vendor-UI / „Workspace-Bot“ | interne Produktivität, geringer Integrationsbedarf |
Typisches Muster: Modelle buy, Harness und Produktlogik build, reines Embed nur wo ihr keine SLOs fürs Kernprodukt braucht. „Alles selbst hosten“ und „alles dem Vendor überlassen“ sind Extreme — beides hat Ops- und Lock-in-Kosten. ADR für Hosting und Adaptation: adr-adaptation.md, adr-model-hosting.md.
Center of Excellence vs. Embedded
| CoE / Platform enablement | Embedded in Produktteams | |
|---|---|---|
| Stärke | Standards, Reviews, shared Harness, Lernen teilen | Speed am JTBD, Domain-Kontext |
| Risiko | Ticket-Hölle, Gatekeeping, Innovation-Theater | N-fache Silo-Bots, Pin-Drift, Shadow AI |
| Passt wenn | viele Teams, Compliance, gemeinsame Pain | frühe Phase, 1–2 Capabilities |
Hybrid, der funktioniert: kleines Platform/Enablement-Team baut und pflegt die Harness und Patterns; Product-Teams ownen Spec, Prompt, Eval und On-Call ihrer Capability. CoE ohne Produkt-Skin-in-the-game wird Folien; pure Embeds ohne Standards werden 50 Pilots zero product.
Decision Frame: Wann in Platform investieren?
| Signal | Investition |
|---|---|
| Ein Team, ein Pilot, unklare Learnings | noch nicht — erst Spec + Eval + Flag |
| Zwei+ Teams, copy-paste Tracing/Routing/Keys | jetzt dünne Harness |
| Cost/Quality-Incidents wiederholen sich | Caps, Pin-Registry, Eval-Runner priorisieren |
| Compliance verlangt Residenz/Audit zentral | Platform-Bausteine für Data + Logging |
| „Eine Plattform für alle Use Cases“ vor erstem grünen Pilot | zu früh — Scope schrumpfen |
Faustregel: Platform, wenn gemeinsame Ops-Schmerzen messbar sind — nicht wenn die Strategy-Slide „AI Platform 202x“ verlangt.
Governance light
Governance, die Teams nutzen, ist kurz und an Artefakten gekoppelt:
- ADR bei Adaptation-Stufe, Hosting, Tool-Wirkung (Side Effects).
- Model-Change-Prozess (Pin, Eval-Gate, Canary) — Vorlage im Lifecycle-Kapitel.
- Data Classes (was darf in Prompt, Log, Vendor?) — eine Seite, nicht ein Handbuch.
- Pilot-Portfolio: max. parallele Pilots; jedes Item mit Owner und Exit-Datum.
40-Seiten-Policy vor dem ersten Golden Set erzeugt Compliance-Theater und Shadow AI. Policy wächst aus wiederkehrenden Incidents und Reviews — nicht aus Angst-Slides.
Onboarding-Tempo: checklists/team-onboarding-30-tage.md.
Patterns und Trade-offs
Pattern: Ein Pilot, harte Exit-Kriterien
Zeitbox und Stopp-Kriterien in der Spec; Demo ist Zwischenprodukt, kein Go-Live.
Trade-off: weniger „Momentum“-PR; mehr Kapital für das, was productized werden darf.
Pattern: Harness thin, Domain thick
Zentral: Telemetrie, Caps, Pins, Guardrail-Hooks. Dezentral: Prompts, Retrieval-Korpus, Fach-Tools.
Trade-off: Platform muss Stabilität liefern, nicht Feature-Roadmap der Fachbereiche.
Pattern: Capability Board statt Strategy Deck
Ampel, Cost, Eval-Stand, Blocker — wöchentlich.
Trade-off: unspektakulär; steuert Portfolio.
Trade-off: Speed now vs. shared layer
| Nur Team-Silo | Frühe dicke Platform |
|---|---|
| schneller erster Slice | langsamer erster Slice |
| teure Konsolidierung später | Gefahr Geister-Framework |
Gesunder Mittelweg: Pilot diszipliniert, Platform beim zweiten Team und bei Ops-Schmerz.
Anti-Patterns
| Anti-Pattern | Symptom | Besser |
|---|---|---|
| Shadow AI unchecked | Keys, Tools, Daten ohne Review | erlaubte Pfade + light Governance; nicht Verbote ohne Alternative |
| 50 Pilots, zero product | Slide voll, Prod leer | Portfolio-Cap; Exit oder Productization |
| „AI strategy“ ohne Spec | Vision, keine Metriken | Spec + Ampel pro Capability |
| Vendor lock-in by slide | ein Anbieter = „unsere Plattform“ | Buy Modelle, Build Control Flow; Exit-Option im ADR |
| Platform too early | Framework vor JTBD | erst ein grüner Pilot |
| Platform too late | N-fache Bots, Incidents | Harness bei 2+ Teams / wiederholtem Pain |
| CoE als Ticket-Hölle | alles wartet auf das Zentrum | Enablement + Self-Serve Harness; Domain-Ownership bleibt |
| Innovation-Theater | Hackathons ohne Eval/Owner | jedes Demo mit Spec-Stub und Kill-Kriterium |
| Skip security „weil Pilot“ | Prod-Daten im Prompt | Security light ab Tag 1 bei Daten/Tools |
| Ein Chatbot für alle | unendliche Failure Surface | JTBD-Capabilities, nicht Universalschalter |
Production Notes
Cost. Ohne Caps und Feature-Keys pro Capability ist „Pilot“ ein offenes Budget. Finance braucht feature_key und Forecast aus Traces — nicht Excel-Schätzung am Quartalsende (T7).
Latency / SLO. Productization heißt Quality- und Latency-Ziele geschrieben und alarmiert — nicht nur „wirkt schnell in der Demo“ (Kapitel 23).
Observability. Platform-Invest lohnt zuerst an Tracing, Token-Accounting und Versionen im Span. Ohne das skaliert ihr Blindflug (Kapitel 22).
Security. Pilot ist kein Freifahrtschein: Keys, Egress, Tool-Permissions und Data Classes gelten, sobald reale Systeme angebunden sind (T8). Security-Review skaliert mit Wirkungsebene, nicht mit dem Wort „Pilot“ auf der Slide.
Lifecycle. Einführung im Unternehmen scheitert oft an ungepinnten Model-Updates über zehn Teams hinweg. Pin-Registry und Change-Checklist sind Organisationswerkzeuge, keine Spielerei (T9). Mensch bleibt Owner von Stopp, Promote und Degrade (T10).
Key Takeaways
- Skaliert Pilot → Platform → Productization mit Exit-Kriterien — nicht die Anzahl der Demos.
- Pilot = ein JTBD, Spec, Eval-Baseline, Ampel, Flag, named Ownership.
- Platform = gemeinsame Harness (Trace, Route, Cap, Guardrail, Pin, Eval) — nicht ein Mega-Chatbot.
- Productization = Quality-SLOs, On-Call, Runbooks, Cost Envelope, Security Review.
- Stakeholder nach Entscheidung (Eng, Product, Legal, Security, Finance); Governance light über ADRs und Data Classes.
- Buy Modelle, build Orchestrierung; CoE befähigt, Produktteams ownen Capabilities.
- Anti-Patterns: Shadow AI, Pilot-Friedhof, Strategy ohne Spec, Platform zu früh/spät, Security-Skip.
Praktische nächste Schritte
- Listet alle laufenden AI-Initiativen: Owner, Spec-Link (ja/nein), Ampel, Exit-Datum — Portfolio auf max. tragbare parallele Pilots schrumpfen.
- Für den wichtigsten Kandidaten: ai-feature-spec.md + Ampel aus Kapitel 05 in einer Woche fertig.
- Eval-Baseline anlegen und Feature-Flag + Kill-Switch verifizieren.
- Decision Frame anwenden: gibt es schon 2+ Teams mit Copy-Paste-Ops? Dann dünne Harness (Trace, Cap, Pin) statt drittem Silo-Bot.
- Production-Ready einmal gegen den reifsten Pilot laufen lassen: production-ready-checklist.md.
- 30-Tage-Onboarding für das nächste Team: checklists/team-onboarding-30-tage.md.
- Reife und Assessment: Reifegradmodell.