Auftragsklärung

Auftragsklärung stellt sicher, dass alle Beteiligten dasselbe Vorhaben im Kopf haben, bevor Ressourcen fließen. Ergebnis ist ein knapper, von allen autorisierten Stellen unterzeichneter Projektauftrag.

Ausgangslage: Die Organisation betreibt im Verborgenen bereits KI-Werkzeuge — punktuell, unkontrolliert, ohne Governance. Die Konsequenz ist Wissens-Asymmetrie, Compliance-Risiko und verpuffter Nutzen. Ziel ist ein koordinierter, nachvollziehbarer Einstieg in KI-getriebenes Projektmanagement.

Auftrag: Den ersten reproduzierbaren KI-Unterbau in I1–I3 errichten, den ersten Use Case in I3–I4 live bringen und die Organisation bis I7 befähigen, Use Cases eigenständig aufzuziehen. Voraussetzung: Rechtskontext bis Ende I2 geklärt.

Abgrenzung: Keine Personalentscheidungen, keine neue IT-Abteilung, kein proprietärer Plattform-Lock-in. Das Vorhaben endet, sobald der Betrieb verstetigt und die Organisation handlungsfähig ist.

Metazeile

Auftraggeber

Bereichsvorstand Digitalisierung & IT

Projektleitung

offen — Nominierung bis I1 Woche 2

Freistellung

vollständig für PL, anteilig für TP-Leitungen

Budget-Typ

Festpreis-Puffer + iterativer F&E-Anteil

Nicht-Ziele

Kein Tool-Lock-in · kein Vollautomatismus ohne HITL · kein Ausrollen ohne Governance

Top-Fragen

1. Wer hat den Auftrag formal erteilt, und ist das ein Einzelentscheid der Bereichsführung oder ein Gremiumsbeschluss mit bindender Wirkung für alle betroffenen Bereiche?
2. Was gilt als Erfolg nach Abschluss von I7 — ein arbeitsfähiger Unterbau mit einem Use Case, oder eine Organisation, die neue Use Cases eigenständig aufzieht?
3. Welche Signale aus dem laufenden Betrieb haben den Anlass ausgelöst — konkrete Schatten-KI-Vorfälle, Audit-Befunde, Wettbewerbsdruck, oder ein regulatorisches Datum?
4. Welche Entscheidungen kann die Projektleitung autonom treffen, und ab welcher Tragweite muss der Lenkungsausschuss zustimmen?
5. Gibt es eine explizite Definition von „vertraulich", die alle Beteiligten heute schon teilen, oder muss die Datenklassen-Matrix erst im Projekt erarbeitet werden?
6. Ist das Nicht-Ziel „kein Tool-Lock-in" vertraglich schon geschützt (Exit-Klauseln in bestehenden Cloud-Verträgen), oder bleibt das eine Gestaltungsabsicht?
7. Welche bestehenden Projekte, Richtlinien oder Entscheidungen begrenzen den Gestaltungsraum sofort — z. B. ein bereits gewählter Cloud-Anbieter oder ein laufendes SAP-Rollout?
8. Ist der Projektrahmen auf diesen Konzern beschränkt, oder soll das Ergebnis auf andere Gesellschaften oder Töchter übertragbar sein?
9. Wie lange ist der Auftrag politisch stabil — gibt es ein Ablaufdatum (Vorstandsmandat, Budget-Zyklen), das die Zielarchitektur beeinflusst?
10. Wer zeichnet das Projekt-Abnahmedokument am Ende, und welche Kriterien muss dieses Dokument erfüllen, damit die Abnahme nicht auf Gutdünken beruht?

Projekt-Design

Projekt-Design definiert das Grundprinzip: Wie wird gearbeitet, woran misst man Fortschritt, und welche Annahmen stecken im Vorgehen?

Methodik: Hybrides Vorgehen — klassische Planungstiefe für Governance, Recht und Infrastruktur; agile Iterationen für Use Cases und Kontextarbeit. Stacey-Klassifikation: überwiegend komplex. Das bedeutet, Anforderungen schärfen sich iterativ; der Plan ist ein lebendes Artefakt, kein Gesamtwerk von Iteration I1.

Qualitätssicherung: Jede Iteration endet mit einem Quality Gate (Artefakt-Checkliste, definierte Abnahmekriterien, HITL-Protokoll). Kein Start der Folge-Iteration ohne Gate-Freigabe. Fortschrittsmessung: Earned Value für klar messbare Pakete; 0:100-Methode für agentische oder nicht-inkrementelle Pakete.

Grundprinzipien: Befähigung vor Zukauf — wo intern realisierbar, kein Einkauf externer Dienste ohne Exit-Plan. Vertraulichkeit vor Komfort — lokale Modelle vor Cloud, wo Datenklasse es erfordert. Beweis vor Übergabe — kein Artefakt gilt als fertig ohne automatisierten Nachweis.

Metazeile

Projekttyp

Vorhaben mit hohem F&E-Anteil

Stacey-Zone

überwiegend komplex

Iterationsanzahl

I1–I7 (7 Iterationen, Dauer je nach Kalender)

Qualitätsprinzip

Quality Gate je Iteration · HITL · automatisierter Beweis

Beschaffung

Open Source zuerst · Exit-Plan bei jeder Integration

Top-Fragen

1. Wie weit ist der hybride Ansatz (klassische Struktur + agile Iteration) in der Organisation verankert — gibt es ein gemeinsames Verständnis von „Iteration" oder muss das erst eingeführt werden?
2. Welche der drei Dreieck-Ecken darf in einem kritischen Fall nachgeben — wenn Umfang variabel und Zeit in Iterationen ist, was passiert, wenn eine Iteration die Qualitätsanforderungen nicht erfüllt?
3. Wie wird der F&E-Anteil (agentische Verfahren) budgetär behandelt — als eigene Kostenstelle mit höherem Risikopuffer, oder integriert in die Vorhaben-Baseline?
4. Welche Kompetenz ist heute im Haus vorhanden (lokale Modelle, Orchestrierung, Prompt-Engineering), und was muss als Personalaufbau oder Einkauf ergänzt werden?
5. Ist „Befähigung vor Zukauf" eine strategische Vorgabe des Auftraggebers oder ein Gestaltungsvorschlag der Projektleitung — und wer entscheidet, wenn Eigenaufbau zu langsam wird?
6. Wie wird die Stacey-Klassifikation (überwiegend komplex) in den Steuerungsgremien kommuniziert — versteht der Lenkungsausschuss, dass Anforderungen sich iterativ schärfen?
7. Welche organisatorische Verankerung hat das Vorhaben nach Projektende — gibt es eine Stelle, Abteilung oder Rolle, die den Betrieb des KI-Unterbaus übernimmt?
8. Woran erkennt man, dass ein Use Case tatsächlich Nutzen stiftet — welche Kennzahl ist vor dem ersten Use-Case-Start als Messbasis vereinbart?
9. Gibt es bereits ein Unternehmens-KI-Gremium oder Architektur-Board, das Exit-Plan-Entscheidungen (z. B. Ablösung eines Cloud-Anbieters) formal freigeben muss?
10. Wie restriktiv ist der bestehende IT-Beschaffungsprozess — kann die Projektleitung neue Open-Source-Werkzeuge taktisch einsetzen, oder ist jeder Einsatz extern genehmigungspflichtig?

Ziele

Ziele beschreiben, was nach Projektende anders ist als vorher — messbar, priorisiert, mit klarer Grenze zwischen Pflicht und Option.

Muss-Ziele (verpflichtend): Reproduzierbarer KI-Unterbau mit klarer Datenklassen-Governance; mindestens ein Use Case live und belegbar nützlich; Rechtskontext formal geklärt (DSGVO, EU AI Act); Organisation eigenständig handlungsfähig nach Projektende.

Soll-Ziele (angestrebt): Geringere manuelle HITL-Last durch agentische Routinen; mindestens drei Use Cases live bis I6; Observability-System mit automatischer Kostenübersicht; RAG-Basis und Graphstrukturen für Kontextabfragen.

Kann-Ziele (opportunistisch): Automatisierte Änderungsvorschläge für Richtlinien, die den KI-Einsatz hemmen; tiefere Anbindung von Fachsystemen (ERP, DMS) in I6–I7; vollständig lokale Erzeugung vertraulicher Artefakte ohne Cloud-Egress.

Metazeile

Muss (M)

Unterbau · 1 Use Case · Rechtskontext · Eigenständigkeit

Soll (S)

Geringere HITL-Last · 3 UC bis I6 · RAG-Basis · Observability

Kann (K)

Änderungsvorschläge · Fachsystem-Anbindung · Cloud-Egress-Reduzierung

Zielkonflikt

Compliance fix — UC-Timeline variabel; Gate-Protokoll regelt Priorität

Nicht-Ziel

Vollautomatismus ohne HITL · proprietärer Stack

Top-Fragen

1. Was ist das messbare Kriterium für „erster Use Case live" — ab welchem Nutzungsmuster oder welcher Nutzerzahl gilt das als erbracht?
2. Woran wird „geringere manuelle HITL-Last" gemessen — gibt es eine Ausgangsmessung der heutigen manuellen Aufwände, gegen die der Effekt berechnet werden kann?
3. Was bedeutet „Rechtskontext geklärt" präzise — ein Rechtsgutachten, ein abgestimmtes Prozessprotokoll mit dem DSB, eine Betriebsvereinbarung, oder eine Kombination?
4. Wie wird „reproduzierbare Arbeit" nachgewiesen — gibt es ein Abnahme-Szenario, in dem der Plan ohne den ursprünglichen Autor wiederhergestellt werden muss?
5. Welche Soll-Ziele (RAG, Graph-/Vektor-DB, BM25) haben ein frühestes Startdatum, und welche Voraussetzungen müssen vorher erfüllt sein?
6. Wie wird Scope Creep beim Use-Case-Portfolio operativ verhindert — gibt es ein Eingabetor (Änderungsantrag, Lenkungsausschuss), das neue Use Cases formal prüft?
7. Ist das Kann-Ziel „Änderungsvorschläge an das Management" durch den Auftraggeber schon prinzipiell gebilligt, oder ist das ein Ergebnis, das erst am Ende zur Entscheidung vorgelegt wird?
8. Welche INVEST-Eigenschaften (Independent, Negotiable, Valuable, Estimable, Small, Testable) sind in der Organisation bekannt, und wer ist Ansprechpartner für die Priorisierung der Backlog-Stories?
9. Steht die Ziel-Priorisierung (Muss/Soll/Kann) schriftlich im Projektauftrag, oder ist sie nur im Team abgesprochen — und wer kann sie nachträglich kippen?
10. Wie werden Zielkonflikte zwischen Compliance-Konformität (fix) und frühem operativem Nutzen (Use Case live in I3–I4) aufgelöst, wenn der Rechtskontext länger als I2 braucht?

Umfeld

Umfeld beschreibt den Kontext, in dem das Vorhaben operiert — rechtlich, organisatorisch, technisch. Nicht steuerbar, aber relevant für Entscheidungen.

Rechtlicher Rahmen: EU AI Act (Risikoklassen und Literacy-Pflicht Art. 4 ab 2025), DSGVO (AVV/DSFA), Betriebsverfassungsgesetz (§87 Mitbestimmung bei technischen Einrichtungen). Compliance-Strom CMP bearbeitet alle drei parallel.

Organisatorischer Kontext: Konzern mit 5.000–15.000 Mitarbeitenden. IT-Beschaffungsprozess formal geregelt. Betriebsrat hat Mitbestimmungsrechte bei technischen Systemen. Noch kein zentrales KI-Gremium. Provider-Governance-Lücken in bestehenden Cloud-Verträgen.

Technischer Kontext: Heterogene Systeme (ERP, DMS, Mail, Kollaborationsplattform). Eigene Rechen-Hardware der Klasse M5 Max für lokale Modelle. Bestehende Cloud-Verträge ohne explizite KI-Zusätze. Fehlende einheitliche Authentifizierungsschicht für neue Dienste.

Metazeile

Rechtlicher Rahmen

EU AI Act · DSGVO · BetrVG §87

Organisationstyp

Konzern 5.000–15.000 MA, zentrale IT

Betriebsrat

Mitbestimmungsrecht §87 — frühzeitig einbinden

Provider-Lücken

AVV / Datenresidenz / ZDR je Anbieter prüfen

Technik-Stand

Heterogene Systeme · lokale Modell-Hardware vorhanden · Auth-Lücke

Top-Fragen

1. Hat der Betriebsrat bereits eine schriftliche Position zu KI-gestützten Arbeitsmitteln — gibt es eine Rahmenbetriebsvereinbarung, einen laufenden Verhandlungsprozess, oder offene Ablehnung?
2. Welche Cloud-Verträge (AVV, Datenresidenz-Zusagen, Retention-Policies) sind heute schon abgeschlossen, und welche Provider-Governance-Lücken sind bekannt?
3. Unter welche EU-AI-Act-Risikokategorie fällt das Vorhaben nach vorläufiger Einschätzung von Recht/Legal — und gibt es eine Folgenabschätzungspflicht (DSFA) für den geplanten Verarbeitungskontext?
4. Gibt es im Konzern ein bestehendes KI-/Daten-Gremium oder Architektur-Board, das Leitplanken für Modell- und Plattformentscheidungen vorgibt — oder muss das im Vorhaben erst etabliert werden?
5. Welche internen Dienstanweisungen (z. B. zu Datenweitergabe, Cloud-Nutzung, Quellcode-Verwaltung) schränken den Handlungsspielraum heute ein und müssen vor Plattformbau geprüft werden?

Stakeholder

Stakeholder-Analyse identifiziert, wer Einfluss auf das Vorhaben hat, was die Person erwartet, und wie der Informationsfluss gestaltet wird.

Promotoren: Bereichsvorstand (Auftraggeber, Entscheidungsträger), IT-Leitung (Betriebshoheit, Ressourcen), Innovationsverantwortliche in Fachbereichen (erster Use Case), einzelne operativ-affine Mitarbeiter (Early Adopter).

Kritische Stakeholder: Betriebsrat (§87 BetrVG — Mitbestimmung technische Einrichtungen; Befürchtung Leistungskontrolle), Datenschutzbeauftragter (DSFA-Pflicht offen, Verarbeitungsverzeichnis), Legal/Recht (EU AI Act Risikoklasse, vertragliche Absicherung).

Kommunikation: Iterations-Statusbericht (je Iteration, alle Beteiligten), Lenkungsausschuss (je Quality Gate), Betriebsrats-Informationssitzung (je I2 und I3 minimal), Mitarbeiter-Information (bei Use-Case-Start je Bereich, schriftlich).

Metazeile

Promotoren

Bereichsvorstand · IT-Leitung · Early Adopter Fachbereiche

Kritisch

Betriebsrat · DSB · Legal

Berichtspflicht

Iterations-Statusbericht · Gate-Protokoll · BR-Info je I2/I3

Eskalationsweg

PL → LA → Auftraggeber

RASCI

folgt in Element 07

Top-Fragen

1. Sind die Befürchtungen des Betriebsrats (Leistungs-/Verhaltenskontrolle) bereits dokumentiert und in einer gemeinsamen Sitzung besprochen worden — oder ist das noch offen?
2. Hat der DSB eine vorläufige Stellungnahme zur DSFA-Pflicht abgegeben, und ist er bereit, den Rechtsklärungsprozess aktiv mitzugestalten (statt nachgelagert zu prüfen)?
3. Welche Fachbereiche haben Interesse an den ersten Use Cases signalisiert — und sind das Promotoren mit Entscheidungsbefugnis oder nur operative Anwender?
4. Wie oft und in welchem Format soll der Lenkungsausschuss informiert werden — reicht ein Iterations-Statusbericht, oder gibt es ein gesondertes Steuerungsgremium für KI-spezifische Fragen?
5. Gibt es im Konzern Einzelpersonen, die das Vorhaben aktiv blockieren könnten — identifizierte Opponenten mit Einfluss auf Budgets, Gremien oder öffentliche Meinung?

Risiken

Risiken sind identifiziert, bewertet und mit Maßnahmen hinterlegt. Das Register wird je Iteration aktualisiert.

Technische Risiken: Modell-Drift (Qualität sinkt ohne Beobachtbarkeit) — Gegenmaßnahme: Observability von Tag 1 (INT-4); Provider-Governance-Änderung — Gegenmaßnahme: Exit-Plan je Integration (INF-2); Latenz lokal vs. Cloud — Gegenmaßnahme: Latenz-Monitoring als KPI.

Organisatorische Risiken: Betriebsrats-Eskalation blockiert Use-Case-Start — Maßnahme: GOV-2 in I2 abschließen; Politischer Wechsel (Auftraggeber) — Maßnahme: Auftrag gremiumsbeschlossen (AK-Element 01); Ressourcenabzug aus der Linie — Maßnahme: formale Freistellung in Projektauftrag.

Compliance-Risiken: EU AI Act Risikoklasse noch nicht bewertet — Maßnahme: CMP-1 bis Ende I2; DSFA-Pflicht ungeklärt — Maßnahme: CMP-2 in I2; Lizenzen KI-generierter Output noch nicht geprüft — Maßnahme: CMP-7 in I7 (Platzhalter).

Metazeile

Methodik

Probability × Impact · Residualrisiko nach Maßnahme

Kritischstes Risiko

Betriebsrats-Eskalation → GOV-2 als Frühmaßnahme

Monitoring-Rhythmus

wöchentlich PL-intern · je Quality Gate für LA

Risikoregister

lebendes Artefakt — kein Einmalprodukt

Risikobudget

offen — eingestellt nach Risikoanalyse I1

Top-Fragen

1. Welche regulatorischen Termine (EU AI Act Anwendungsdaten, DSGVO-Guidance-Updates) fallen voraussichtlich in die Iterationsfenster I1–I7 — und ist der Compliance-Strom (CMP) so getaktet, dass er diese Daten als Trigger aufnimmt?
2. Ist der Exit-Plan für den Fall eines Anbieter-Governance-Wechsels heute schon auf Machbarkeit geprüft — gibt es eine Alternative für die kritischste Cloud-Abhängigkeit, die in weniger als einer Iteration eingesetzt werden kann?
3. Wie wird das Mitbestimmungs-Risiko (Betriebsrats-Eskalation) während der Iterationen beobachtet — gibt es ein Frühwarnsignal (z. B. formale Anfrage, Sitzungsprotokoll), das einen Eskalations-Trigger auslöst?

Projektorganisation

Projektorganisation regelt, wer was entscheidet, wer informiert wird und wer haftet. Grundprinzip: Verantwortung an Wirkung knüpfen, nicht an Hierarchie.

Lenkungsausschuss: Auftraggeber, IT-Leitung, Legal, Datenschutzbeauftragter (beratend). Entscheidet über Budget-Abweichungen, Scope-Änderungen, Gate-Freigaben. Trifft sich je Quality Gate (mind. je Iteration).

Projektleitung: Autonom bei Tages-/Wochenentscheidungen innerhalb Budget und Scope. Eskalationspflicht bei: Budget-Abweichung >10 %, Scope-Erweiterung, Compliance-Risiko-Eskalation, Ressourcenabzug.

Teilprojektleitungen: Je Strom (CTX, INF, INT, CMP, UC, GOV) eine TP-Leitung. Fachlich zuständig für Artefakte, Quality Gates und HITL-Protokolle des Stroms. Freistellung anteilig 40–60 % — abhängig von Strom-Aktivität je Iteration.

Metazeile

Lenkungsausschuss

Auftraggeber · IT-Leitung · Legal · DSB (beratendes Stimmrecht)

Projektleitung

Vollfreistellung · Eskalationsrecht gegenüber Linie

TP-Leitungen

6 Strom-Leitungen · Freistellung 40–60 %

RASCI

wird in I1 Woche 2 fertiggestellt

PMO

offen — internes Mini-PMO oder externer Support

Top-Fragen

1. Sind die Teilprojektleitungen der fünf Ströme bereits benannt, und haben sie formale Freistellung aus der Linie — oder laufen sie parallel zum Tagesgeschäft?
2. Wie ist das Eskalationsrecht der Projektleitung gegenüber Linienvorgesetzten geregelt — gibt es ein schriftliches Mandat, oder hängt die Durchsetzungsfähigkeit an informellen Beziehungen?
3. Wer definiert und pflegt die RASCI-Matrix, und ab welcher Änderung muss sie erneut durch den Lenkungsausschuss bestätigt werden?
4. Welche Human-in-the-Loop-Punkte sind bereits als Pflicht-Rollen benannt — und sind die verantwortlichen Personen schon bekannt und haben zugestimmt?
5. Gibt es ein Project Office (PMO) oder eine vergleichbare Struktur, die Berichtswesen, Vorlagen und Werkzeuge einheitlich bereitstellt — oder baut die Projektleitung das selbst auf?

Phasenplan / Arbeitspakete

Phasenplan zeigt die logische Abfolge der sechs Ströme über sieben Iterationen. Abhängigkeiten sind eingetragen; kritischer Pfad berechnet sich automatisch im Gantt.

I1 (Initialisierung): Kontextmodell (CTX-1), Datenklassen-Routing (INF-1), Provider-Governance-Stub (INF-2), Leitplanken (GOV-1), BR-Information (GOV-2 Start), Use-Case-Auswahl (UC-1), Umgebungs-Klärung (INT-0), Workshop-Vorbereitung (INT-5). Quality Gate: Rechtskontext-Scope klar + Datenklassen-Matrix v1.

I2 (Fundament): Rechtskontext abschließen (INF-1 Ende, CMP-1, CMP-2 Start), Kontextquellen anbinden (INT-2), PM-Tool anbinden (INT-1), Use Case Auftragsklärung start (UC-2). Quality Gate: Rechtskontext formal geklärt + Plattform-Basis bereit.

I3–I7 (Betrieb & Ausweitung): Schrittweise Systemintegrationen (INT-3), Observability (INT-4), agentische Compliance-Prüfung (CMP-3), Use Cases live (UC-3, UC-4, UC-5), Change-Begleitung (GOV-3), Governance-Betrieb (GOV-4, GOV-5), Kontextoptimierung (CTX-3, CTX-4), Plattformreife (INF-3, INF-4, INF-5).

Metazeile

Iterationen

I1–I7 · Dauer je nach Kalender

Kritischer Pfad

INF-1 → INF-2 → CMP-2 → CMP-3 → INF-3

Quality Gates

je Iteration · Gate-Protokoll schriftlich · LA-Freigabe

Änderungsprotokoll

Änderungsantrag → PL-Bewertung → LA-Beschluss bei Scope-Änderung

Platzhalter

INF-6 (I5), INF-7 (I6–I7), CMP-6 (I6), CMP-7 (I7), GOV-6 (I5), GOV-7 (I7), UC-7 (I5)

Top-Fragen

1. Was definiert das Quality Gate „Rechtskontext geklärt" operativ — welche Artefakte müssen vorliegen, und wer hat die Freigabekompetenz, bevor INF-2 (Plattformbau) startet?
2. Wie wird entschieden, ob eine Phase verlängert oder der Folge-Iterationsslot verschoben wird — gibt es ein Entscheidungsprotokoll für Gate-Verzögerungen, das Scope Creep vermeidet?
3. Sind die Meilensteine „Erster Use Case live" und „Agentische Compliance-Prüfung greift" zeitlich entkoppelt — oder blockiert ein Verzug bei CMP-2 automatisch den UC-Strang?

Projektstrukturplan

Vier PSP-Varianten derselben Projektarbeit, unterschiedlich gegliedert. Blätter referenzieren AP-IDs aus den sechs Strömen. Collapsible — auf/zu per Klick oder Taste.

Variante & Baum

Top-Fragen

1. Sind die Arbeitspaket-Grenzen zwischen CTX-3 (Kontextpflege automatisieren) und INF-2 (Plattform-Unterbau) trennscharf definiert — wer ist Eigentümer des Routing-Artefakts?
2. Wie werden Use-Case-Erweiterungen (UC-3) im PSP behandelt, wenn das Portfolio wächst — gibt es eine generische Arbeitspaket-Schablone, oder erfordert jeder neue Use Case einen eigenen PSP-Ast?
3. Ist „0 Projektmanagement" als eigenes PSP-Element mit eigenem Budget und Fortschrittsmessung versehen, oder wird es als Overhead ohne separate Erfassung geführt?

Ablaufplan

Ablaufplan macht die logischen Abhängigkeiten zwischen Arbeitspaketen rechenbar. Der kritische Pfad bestimmt die frühestmögliche Fertigstellung.

Kritischer Pfad (CPM): INF-1 (I1–I2) → INF-2 (I2–I3) → CMP-2 (I2–I3) → CMP-3 (I3–I4) → INF-3 (I3). Pufferlose Vorgänge auf dem Pfad — Verzug hier verschiebt den gesamten Plan. Parallele Ströme (CTX, UC, GOV) haben Puffer, solange sie nicht auf INF-2/CMP-3 warten.

Kritische Abhängigkeiten: CTX-3 (Kontextpflege) startet erst, wenn INF-2 (Datenklassen-Routing) abgenommen ist. CMP-2 (AVV/DSFA) folgt auf CMP-1 (Korpus erschlossen). GOV-2 (Betriebsrat) blockiert keinen technischen Strang, aber UC-2 darf ohne BR-Zustimmung nicht in Produktion gehen.

Puffer-Monitoring: Kritische Vorgänge wöchentlich; nicht-kritische je Iteration. Protokoll: Ist-Dauer vs. Geplant → Puffer-Update → LA-Information wenn Puffer <0.

Metazeile

Methodik

CPM (Critical Path Method) · Iteration als Zeiteinheit

Kritischer Pfad

INF-1 → INF-2 → CMP-2 → CMP-3 → INF-3

Harte FS-Abhängigkeiten

CTX-3 nach INF-2 · CMP-2 nach CMP-1 · UC-2 nach GOV-2 (Prod.)

Puffer-Monitoring

wöchentlich für krit. Vorgänge · je Gate für unkrit.

Visualisierung

Gantt im Plan-Element mit CPM-Overlay · interaktiv

Top-Fragen

1. Sind die Abhängigkeiten zwischen CTX-3 und INF-2 sowie CMP-2 und CTX-2 als harte Finish-to-Start-Beziehungen vereinbart, oder gibt es Spielraum für parallelen Start mit definierten Zwischenergebnissen?
2. Wie wird der kritische Pfad (INF-1 → INF-2 → CMP-2 → CMP-3 → INF-3) beobachtet — gibt es ein wöchentliches Puffer-Monitoring, oder nur ein Iterations-Statusbericht?
3. Welche Vorgänge auf dem kritischen Pfad haben den größten Schätzunsicherheits-Anteil — und ist dafür bereits eine Dreipunkt-Schätzung mit Worst-Case-Szenario dokumentiert?

Termin-/Ressourcenplan

Termin-/Ressourcenplan weist nach, dass die geplante Arbeit mit den vorhandenen Kapazitäten in den Iterations-Fenstern leistbar ist.

Rollen und Kapazitäten (Schätzwerte): Projektleitung 1,0 VZÄ I1–I7; Recht/Datenschutz 0,5 VZÄ I1–I3 (extern); Plattform-Engineering 2,0 VZÄ I2–I4; KI-/Kontext-Engineering 1,5 VZÄ I2–I5; Compliance/Change 1,0 VZÄ I2–I5; Use-Case-Verantwortliche 0,5 VZÄ I3–I6.

Iterationskalender (Schätzung, ohne Kalendertermine): I1 = 4 Wochen (Initialisierung); I2 = 6 Wochen (Fundament, Rechtskontext); I3 = 6 Wochen (erste Systeme live); I4 = 5 Wochen (Use Cases produktiv); I5–I7 = je 4–5 Wochen (Stabilisierung/Ausweitung).

Kapazitätskonflikte: Recht/Datenschutz ist Engpass in I1–I2 — externe Ressource muss früh reserviert werden. Plattform-Engineering wird gleichzeitig für INF-2, INT-3, CTX-3 benötigt — Priorisierung im Strang CTX/INF klar halten.

Metazeile

Ressourcen (grob)

1,0 PL · 0,5 Recht (ext.) · 2,0 Plattform · 1,5 KI/Kontext · 1,0 CMP/Change · 0,5 UC

Engpass

Recht/Datenschutz I1–I2 · Plattform I2–I4

Iterationslängen

I1=4W · I2=6W · I3=6W · I4=5W · I5–I7≈4–5W

Kalender-Status

Iterationen noch nicht kalenderscharf

Abgleich-Rhythmus

wöchentlich PL-intern · je Gate für LA

Top-Fragen

1. Wie lang ist ein Iterationsfenster in Kalenderwochen festgelegt — und wer hat die Befugnis, die Kadenz für einen Strom auszusetzen oder zu verdichten?
2. Welche externen Fixtermine (Gremiumssitzungen, Betriebsratssitzungen, Geschäftsjahreswechsel) müssen in das Iterationsraster eingetaktet werden, bevor der Plan kalenderscharf wird?
3. Wenn INF-1 (Rechtskontext) am Ende von I2 nicht abgeschlossen ist — nach welchem Protokoll wird entschieden, ob INF-2 trotzdem in I3 beginnt oder das gesamte Raster verschoben wird?

Kostenplan

Kostenplan schätzt den finanziellen Rahmen auf Arbeitspaket-Ebene, aggregiert je Iteration und benennt das Risikobudget explizit.

Personalkosten (Schätzung): Projektleitung und sechs TP-Leitungen über I1–I7: ~350–400 Personentage intern. Externe Recht/Datenschutz I1–I3: ~30–50 PT extern. Gesamtpersonalkosten: abhängig von internen Verrechnungssätzen und externem Tagessatz — Aufstellung erfolgt nach Bestätigung der Sätze.

Sachkosten: Token-/Cloud-Kosten je Modell und Use Case (ab I3 wachsend); Lizenzkosten Open-Source minimal (0 €); Werkzeug-Abo-Kosten (PM-Tool, Monitoring): pauschal ~200–500 €/Monat. Hardware (eigener Modell-Server): bereits vorhanden — kein Neuinvestment.

Risikobudget und Contingency: F&E-Anteil (agentische Experimente) mit eigenem Puffer 10–15 % des Gesamtbudgets. Risikobudget 10 % der Baseline. Gesamtrahmen: zur Freigabe durch den Lenkungsausschuss nach Abschluss der RASCI-Matrix und Verrechnungssatz-Klärung.

Metazeile

Personal intern

~350–400 PT Schätzung I1–I7

Extern (Recht)

~30–50 PT · Tagessatz offen

Sachkosten

Token-Kosten wachsend ab I3 · Abo-Kosten minimal · Hardware vorhanden

F&E-Puffer

10–15 % Baseline

Risikobudget

10 % Baseline · wird nach Risikoanalyse eingestellt

Top-Fragen

1. Sind die qualifizierten Recht-/Datenschutz-Ressourcen für I1–I2 bereits reserviert — handelt es sich um interne Stellen oder externe Beratung, und ist deren Verfügbarkeit bestätigt?
2. Welche lokale Modell-Hardware ist heute betriebsbereit und inventarisiert — und wer hat die Betriebsverantwortung für den eigenen Modell-Server während des Vorhabens?
3. Wie wird der Kapazitätsabgleich iterativ aktualisiert — gibt es ein Werkzeug oder einen Prozess, der Unter-/Überdeckungen je Iteration frühzeitig sichtbar macht?

Steuerung & Berichtswesen

Steuerung & Berichtswesen sorgt dafür, dass Abweichungen früh erkannt und entschieden werden, statt sich stillschweigend aufzuschichten.

Kennzahlen (KPIs): Earned Value Index (SPI/CPI) je Strom; kritischer-Pfad-Puffer in Iterationsprozent; offene Gate-Blocker; HITL-Last (manuelle Stunden je Woche); Token-Kosten je Iteration; Anzahl Use Cases live und in Test; Compliance-Risiken offen/geschlossen.

Berichtsformat: Iterations-Statusbericht (kompakt, 1 Seite, je Iteration, alle Beteiligten); Gate-Protokoll (detailliert, je Quality Gate, LA); Eskalations-Memo (bei Puffer <0 auf kritischem Pfad, sofort). Kein ausgedünnter Folien-Bericht — Fakten statt Signalfarben ohne Datenbasis.

Korrekturmaßnahmen: Bei SPI <0,85: Scope-Prüfung + LA-Eskalation. Bei Compliance-Blocker: CMP-Strom erhält sofort Vorrang, andere Ströme werden eingefroren bis Entscheid. Bei Betriebsrats-Eskalation: GOV-2-Protokoll greift (Sondersitzung innerhalb 72h).

Metazeile

KPIs

EVI (SPI/CPI) · CP-Puffer · HITL-Last · Token-Kosten · UC-Live-Anzahl · CMP-Risiken

Berichtsformat

Statusbericht (je It.) · Gate-Protokoll (je Gate) · Eskalation (ad hoc)

Eskalationsschwellen

SPI <0,85 · CP-Puffer <0 · Compliance-Blocker · BR-Eskalation

Werkzeuge

Gantt (Iteration) · Kostenübersicht (iterativ) · Observability-Dashboard ab I3

Rhythmus

wöchentlich PL-intern · je Gate für LA

Top-Fragen

1. Welche internen Verrechnungssätze gelten für die beteiligten Rollen (Projektleitung, Recht, Plattform-Engineering) — sind diese im Projektauftrag genehmigt, oder müssen sie erst mit dem Controlling abgestimmt werden?
2. Wie wird der Token-/Verbrauchskosten-Posten monatlich erfasst und der Baseline gegenübergestellt — gibt es ein Monitoring-Werkzeug, oder erfolgt die Erfassung manuell aus Cloud-Abrechnungen?
3. Ist das Risikobudget bereits beziffert und in der Kostensumme enthalten — oder wird es erst nach Abschluss der formalen Risikoanalyse nachträglich eingestellt?

Abschluss & offene Punkte

Abschluss schließt das Vorhaben geordnet ab, sichert das erarbeitete Wissen und stellt die Organisation auf eigenständigen Betrieb um.

Abnahmeprotokoll: Je Artefakt ein Abnahmekriterium (definiert in Elemente 01–03). Gesamt-Abnahme durch Lenkungsausschuss nach Vorlage aller Einzelabnahmen. Abnahme-Voraussetzung: mindestens ein Use Case produktiv, Rechtskontext formal geschlossen, Betriebsdoku übergeben, HITL-Rollen besetzt.

Übergabe und Verstetigung: Betriebsdokumentation je Strom; Schulungsnachweis für alle HITL-Rollen; Übergabeprotokoll an Betriebsverantwortliche; Leitplanken-Dokument (GOV-4) und Governance-Betriebsmodell (GOV-5) als laufende Artefakte übergeben.

Lessons Learned: Retrospektive je Iteration, aggregiert im Abschluss. Erkenntnisse werden als Modul-Verbesserungen in den Harness rückgeführt. Offene Punkte aus dem Vorhaben fließen in einen priorisierten Backlog für den Folgebetrieb.

Metazeile

Abnahme

LA-Beschluss nach Einzel-Abnahmen je Artefakt

Übergabe-Pakete

Betriebsdoku · Schulungsnachweis · Leitplanken-Dok · GOV-Betriebsmodell

Lessons Learned

Retrospektive je Iteration · aggregiert im Abschluss · Harness-Rückfluss

Offene Punkte

Priorisierter Folge-Backlog · Ownership nach Übergabe

Nicht-Ziele

Kein Re-Scope nach Abnahme ohne neuen Projektauftrag

Top-Fragen

1. Welche Fortschrittsmessmethode gilt für agentische Arbeitspakete (z. B. CMP-2), bei denen kein physisches Ergebnis schrittweise entsteht — ist 0:100 oder Mengenproportionalität vereinbart, und wer prüft die Abnahme?
2. Wer ist befugt, einen Änderungsantrag für eine Use-Case-Erweiterung (Scope Creep) abzulehnen — Projektleitung allein, oder erst nach Lenkungsausschuss-Entscheid?
3. Was ist das verbindliche Abschlusskriterium für „Selbstständigkeit der Organisation" — welche Nachweise (Schulungsnachweis, eigenständig aufgezogener Use Case, Betriebsdoku) müssen bei der Übergabe vorliegen?

Umgebung & Startpunkt schnell klären

Bestandsaufnahme: welche Werkzeuge, Auth-Pfade und Infrastruktur sind tatsächlich vorhanden — bevor Integrationsplanung gegen Annahmen entsteht.

Bevor Integration geplant wird, muss feststehen, was tatsächlich vorhanden ist. Dieses Paket erfasst in I1 den Ist-Stand in drei Zügen: welche Werkzeuge (PM-Tools, Dokumentenablagen, Mail-Systeme, Fachsysteme) produktiv genutzt werden, welche Auth-Pfade bereits existieren (SSO, OAuth, Service Accounts) und welche Infrastruktur lokal und serverseitig bereitsteht. Ohne diese Bestandsaufnahme entsteht Integrationsplanung gegen Annahmen statt gegen Tatsachen.

Der zweite Zug ist die Klärung der Verbindlichkeit: Welche Werkzeuge sind strategisch gesetzt — durch IT-Governance, Lizenzverträge oder Betriebsvereinbarungen — und welche sind faktisch im Einsatz, ohne dass eine strategische Entscheidung dahintersteht? Das trennt die Integrationslast, die es gibt, von der, die zuerst organisatorisch zu klären ist. Datenklassen-Relevanz je Werkzeug (INF-1) wird hier erstmals zugeordnet.

Das Ergebnis ist eine kompakte Übersicht: Werkzeug, Nutzungsgrad, strategischer Status, Datenklasse, existierender Auth-Pfad, vorläufige Integrationsrichtung (direkt / Proxy / bewusst außen vor). Sie steuert alle weiteren Pakete in diesem Stream und verhindert, dass mehrere APs dieselbe Umgebungslücke unabhängig voneinander entdecken.

Top-3 Fragestellungen

1. Welche Werkzeuge (PM-Tool, Ablagen, Mail, Fachsysteme) sind strategisch gesetzt, und welche sind nur faktisch im Einsatz ohne explizite Governance-Entscheidung?
2. Welche Auth-Pfade (SSO, OAuth, API-Keys, Service Accounts) stehen bereits bereit, und welche müssten erst beantragt oder eingerichtet werden?
3. Welche Werkzeuge fallen nach INF-1 in welche Datenklasse, und was bedeutet das vorab für die mögliche Integrationstiefe?

Anbindung PM-Tool (Jira / MS Project o. Ä.)

Das bestehende PM-Werkzeug bleibt Darstellungs- und Übergabeschicht, nicht Quelle der Wahrheit. Sync-Perimeter eng halten; Auth nach INT-0; Routing nach INF-1.

Das bestehende PM-Werkzeug — ob Jira, MS Project oder ein anderes — bleibt Darstellungs- und Übergabeschicht, nicht Quelle der Wahrheit. Die agentische Landschaft hält den Plan in offenen Formaten (CTX-1); das Werkzeug empfängt den jeweils aktuellen Stand zur Anzeige und zur Rückmeldung durch die Beteiligten. Welche Richtung Daten fließen, ist die erste Designentscheidung: ein Einwegexport genügt oft, solange Rückmeldungen über einen definierten Freigabepfad in die SSoT einfließen, statt direkt im Werkzeug zu landen.

Für einen bidirektionalen Sync sind Prozess- und Datenflussfragen vorab zu klären: Welches Element ist in welchem System bearbeitbar, wer setzt die Wahrheit bei einem Konflikt, und wie verhindern wir Rück-Drift — also, dass Änderungen im Werkzeug die SSoT stilllegen? Der Sync-Perimeter ist bewusst eng zu halten: je mehr Felder synchronisiert werden, desto größer die Drift-Oberfläche. Kandidaten für den Perimeter sind Status, Zieldaten und zugewiesene Personen; Detailkontext bleibt in der agentischen Landschaft.

Die Auth läuft über den in INT-0 geklärten Pfad; Datenklassen-Routing nach INF-1 bestimmt, welche Felder in den Sync dürfen und welche lokal bleiben. Das PM-Werkzeug ist typischerweise intern, also ohne Cloud-Egress für vertraulichen Inhalt — aber das ist zu belegen, nicht anzunehmen. Eine dünne eigene Schicht kapselt die Werkzeug-API, damit ein Werkzeugwechsel die Kernlogik nicht bricht.

Top-3 Fragestellungen

1. Welches PM-Werkzeug ist gesetzt, und ist ein Einweg-Export zur Darstellung ausreichend oder ist ein bidirektionaler Sync fachlich nötig?
2. Welcher Sync-Perimeter (welche Felder, welche Richtung) ist sinnvoll, und wie verhindert das Design Rück-Drift in die SSoT?
3. Welche Datenklassen fließen durch den Sync, und ist das PM-Werkzeug für alle davon als Ziel zulässig (INF-1)?

Anbindung Kontextquellen (Ablagen, Mail, Meetings, Fachsysteme)

Für jede Quelle: Darf der Inhalt angebunden werden? Wie? Wie oft? Anbindung ist read-only; Mail und Fachsysteme erst nach AVV und Routing.

Projektkontext entsteht nicht nur in der agentischen Landschaft — er liegt in Dokumentenablagen (SharePoint, Confluence, Laufwerke), in Mailthreads, in Meeting-Transkripten (UC-3) und in Fachsystemen (ERP, CRM, HR). Dieses Paket klärt, welche dieser Quellen anbindungswürdig sind, wie die Beschaffung zur Laufzeit erfolgt (CTX-3) und unter welchen Bedingungen Inhalte aus diesen Quellen als Kontext in die agentische Landschaft fließen dürfen. Nicht jede Quelle, die existiert, muss angebunden werden; der Aufwand der Anbindung und die Datenklasse der Inhalte sind die Filterkriterien.

Für jede Quelle gelten drei Leitfragen: Darf der Inhalt nach INF-1 angebunden werden (Datenklasse, Routing)? Wie wird die Anbindung technisch realisiert (API, Connector, Read-only-Zugriff)? Und wie oft muss der Kontext frisch beschafft werden (einmalig, periodisch, auf Anfrage)? Mail und Fachsysteme enthalten typischerweise personenbezogene oder vertrauliche Daten — ihre Anbindung ist erst zulässig, wenn Datenklasse, AVV (CMP-2) und Routing geklärt sind. Die Anbindung ist read-only; in die Quellsysteme wird nicht zurückgeschrieben.

Das Ergebnis ist ein Anbindungsplan: je Quelle Entscheidung (anbinden / bewusst außen vor), Kanal, Datenklasse, Routing-Gate und Refresh-Zyklus. Quellen, die noch keine geklärte Datenklasse haben, bleiben außen vor, bis INF-1 die Zuordnung liefert. So entsteht kein unkontrollierter Sog von Kontext in die Landschaft, sondern ein auditierter Zufluss.

Top-3 Fragestellungen

1. Welche Kontextquellen (Ablagen, Mail, Meetings, Fachsysteme) sind für das Projektmanagement tatsächlich relevant, und welche erzeugen mehr Rauschen als Nutzen?
2. Welche dieser Quellen enthalten vertrauliche oder personenbezogene Daten, und was ist je Quelle Voraussetzung für eine zulässige Anbindung (AVV, Datenklasse, Routing)?
3. Wie wird die Beschaffung zur Laufzeit gesteuert — wann holt sich das System aktiv nach, wann wartet es auf einen Push — damit das Kontextfenster nicht unkontrolliert wächst?

Systemintegrationen: Auth, Schnittstellen, Datenklassen-Routing

Einheitliche Integrationsschicht für alle Anbindungen: Auth-Muster, Kapselung je Drittsystem, Datenklassen-Gate an jeder Systemgrenze, Exit-Plan je Integration.

Über die einzelnen Anbindungen hinaus braucht die Plattform eine einheitliche Integrationsschicht: ein Muster für Auth (SSO / OAuth / API-Key-Rotation), eine dünne Kapselungsschicht je Drittsystem und ein Routing, das für jede ausgehende Anfrage die Datenklasse prüft, bevor sie ein Drittsystem erreicht. Diese Schicht ist generisch — sie dient nicht einem einzelnen Werkzeug, sondern dem Gesamtmuster der Anbindungen aus INT-1 und INT-2.

Auth ist die Schwachstelle jeder Integrationslandschaft. Credentials werden nicht hartkodiert, sondern über einen Secrets-Manager verwaltet; Rotation ist von Anfang an eingeplant. Service Accounts erhalten nur die Rechte, die sie für ihren spezifischen Auftrag brauchen — least-privilege durchgängig. Für jede Schnittstelle wird ein Exit-Plan dokumentiert: wie kommt man aus der Anbindung heraus, was bleibt portabel, was hängt am Werkzeug. Drittsysteme werden hinter dünnen eigenen Schnittstellen gekapselt; der Austausch eines Systems betrifft dann nur die Kapsel, nicht die Kernlogik.

Das Datenklassen-Routing aus INF-1 und INF-4 wird hier auf Systemgrenzen ausgedehnt: jeder ausgehende Datenstrom trägt die Klasse, die das Gate prüft. Vertraulicher Inhalt verlässt die lokale oder server-seitige Umgebung nicht, unabhängig davon, welches Drittsystem am anderen Ende steht. Die Schicht ist auditierbar (INF-5): jede Integration wird im Log-Trail sichtbar.

Top-3 Fragestellungen

1. Welches Auth-Muster gilt einheitlich für alle Schnittstellen, und wie ist Credential-Rotation von Anfang an in das Design eingebaut?
2. Wie wird das Datenklassen-Routing aus INF-4 auf ausgehende Datenströme ausgedehnt, sodass ein Gate jede Schnittstelle strukturell prüft?
3. Welche konkreten Drittsysteme haben bekannte API-Restriktionen (Rate Limits, Authentifizierungsmodell, Datenschutzklauseln), die die Anbindungsarchitektur frühzeitig einschränken? [Platzhalter — offen]

Observability: Beobachtbarkeit, Kosten, Latenz, Alerts

Drei Ebenen: laufender Betrieb der Agenten, Ressourcen (Token, Kosten in Euro, Latenz), Integrationsstatus. Konservative Alerts — wenige, hochpräzise Signale.

Die Plattform ist nur so belastbar wie die Sicht, die auf sie möglich ist. Observability deckt drei Ebenen ab: den laufenden Betrieb der Agenten (welcher Agent läuft in welchem Kontext, mit welcher Instruktion, seit wann), die Ressourcen (Token-Verbrauch, Kosten in Euro je Lauf, Latenz je Schritt) und den Integrationsstatus (welche Schnittstelle zuletzt erfolgreich, welche gedriftet oder ausgefallen). Ohne diese drei Ebenen erzeugt die Plattform einen Blindflug — Fehler und Kosten fallen erst auf, wenn der Schaden sichtbar ist.

Kosten sind eine Kernkennzahl, keine Nachbetrachtung. Je Agentenlauf werden Token und Kosten in Euro erfasst und auf Anwendungsfall und Aufrufenden zurückführbar gehalten. Zombie-Prozesse — Agenten, die laufen, obwohl ihr Auftrag beendet ist oder fehlgeschlagen hat — sind erkennbar und beendbar; ein Alert greift, sobald ein Prozess über einer definierten Schwelle weiterläuft. Laufende Agenten, ihre Instruktionen und ihre Startpunkte sind jederzeit als Liste abfragbar — keine anonyme Verarbeitungswolke.

Alerts sind zunächst konservativ: zu viele Alerts erodieren das Vertrauen schneller als zu wenige. Das Monitoring startet mit wenigen, hochpräzisen Signalen — Routing-Gate-Verletzung, Laufzeitüberschreitung, Kostenschwelle — und wird schrittweise ausgebaut. Die Betriebsdaten liegen in offenen Formaten und sind nicht exklusiv in einem externen Monitoring-Werkzeug eingesperrt; die Darstellung ist eine Schicht über der Datengrundlage.

Top-3 Fragestellungen

1. Welche drei bis fünf Signale sind im Betrieb wirklich alert-würdig (hohe Präzision, kein Rauschen), und welche Schwellen gelten je Signal?
2. Wie werden Kosten (Token, Geldbetrag in Euro) je Lauf und je Anwendungsfall erfasst und auf Aufrufer und Use Case zurückgeführt?
3. Welches Monitoring-Werkzeug ist in der Organisation bereits strategisch gesetzt, und schränkt das die Wahl des Datenformats oder des Exportpfads ein? [Platzhalter — offen]

Workshop durchführen & transkribieren

Reproduzierbarer Workshop-Prozess: Vorbereitung, Dialog, Transkription (lokal, Parakeet TDT 0.6B v3), Nachbereitung — vom Gespräch in die Quelle der Wahrheit.

Workshops sind der primäre Kanal, über den Kontext entsteht, den kein System vorher hat: das implizite Wissen der Beteiligten, die tatsächlichen Grenzen und Vorbehalte, die Priorisierungen der Stakeholder. Das Paket beschreibt den Prozess für einen Workshop-Typ — exemplarisch den „Startpunkt schärfen" — und macht ihn reproduzierbar: Vorbereitung (Agenda aus Kontextmodell, Teilnehmende nach Stakeholder-Profil), Durchführung (Dialog, keine Vorab-Festlegung), Transkription (lokal per STT, Parakeet TDT 0.6B v3 via parakeet-mlx für vertrauliche Inhalte) und Nachbereitung (Transkript → strukturierter Kontext → SSoT).

Das Transkript ist kein Protokoll, das jemand freigibt und abheftet — es fließt als Kontext zurück. Agenten schärfen daraus Agenda-Folgedokumente, offene Punkte werden als verfolgbare Einträge geführt (CTX-2), und die Auftragsklärung (UC-2) wird mit dem erarbeiteten Material direkt weitergeführt. Der Weg vom Gespräch in die Quelle der Wahrheit ist kurz und auditierbar: Audiorohdatei aufbewahren, Transkriptionsquelle im Frontmatter, Ablage nach Datenklasse (INF-1).

Dieser Workshop-Typ ist das erste Mal, dass alle treibenden Rollen (Sponsor, IT-Sicherheit, Datenschutz, Legal, Betriebsrat, Fachbereich, Projektleitung) gemeinsam am Tisch sind. Was hier nicht geklärt wird, wird in späteren Iterationen als Annahme weitergetragen und kostet dort mehr. Das Paket liefert deshalb auch eine knappe Checkliste für den Moderator: Welche Punkte müssen in dieser Runde zwingend entschieden werden, welche dürfen offen bleiben und wer trägt sie?

Top-3 Fragestellungen

1. Welche Punkte aus den Workshop-Blöcken (Datenklassen, Recht, Infrastruktur, Use Cases, Rollen, Leitplanken) müssen in dieser Runde entschieden werden — und welche können offen bleiben, solange ein Verantwortlicher namentlich bekannt ist?
2. Wie wird sichergestellt, dass das Transkript vertraulich bleibt (lokal STT, Datenklassen-Routing), und wer hat Zugriff auf Rohdatei, Transkript und Zusammenfassung?
3. Welches Format und welche Ablage erwartet die Organisation für Workshop-Ergebnisse — gibt es eine bestehende Konvention, in die das Transkript-Ergebnis einfließen muss? [Platzhalter — offen]

Kontextmodell & SSoT aufsetzen

Die Quelle der Wahrheit für den gesamten Projektkontext definieren: welche Dokumente, Register und Artefakte gelten als maßgeblich, und wie werden Änderungen nachvollziehbar?

Das Kontextmodell legt fest, was für die agentische Landschaft als Wahrheit gilt. Die SSoT ist kein zentraler Dokumentenserver, sondern ein Verzeichnis klar definierter Quellen mit Eigentumsregeln: wer darf ändern, wer liest, wer wird benachrichtigt. Artefakte werden referenziert, nicht kopiert; eine Kopie ist immer ein potenzieller Widerspruch zur Quelle.

Offene Formate sind Grundbedingung: Markdown, YAML, JSONL — maschinenlesbar, versionierbar, nicht exklusiv im Werkzeug. Jede Entscheidung über die Struktur des Kontextmodells ist selbst dokumentiert (Provenance), damit eine neue Session ohne Chathistorie den Stand rekonstruieren kann.

In I1 wird die Grundstruktur angelegt und die ersten Kernelemente befüllt. Das Modell wächst mit dem Plan; es wird nie als vollständig betrachtet, bevor alle Elemente mindestens einmal befüllt und durch ein Quality Gate gelaufen sind.

Top-3 Fragestellungen

1. Welche Artefakte (Projektauftrag, AP-Listen, Risikoregister, Stakeholder-Tabelle) sind heute schon vorhanden, und in welchem Format liegen sie vor?
2. Wer hat Schreibzugriff auf welches Kontextelement — und wer muss bei Änderungen informiert werden, damit Downstream-Systeme nicht auf veralteter Basis arbeiten?
3. Wie wird verhindert, dass Agenten veralteten Kontext stillschweigend weiterverarbeiten — gibt es ein Versionierungs- oder Invalidierungsmechanismus für Kontextelemente?

Kontext-Provenance & Audit-Trail

Je Planelement nachvollziehbar machen: wer hat wann welche Annahme eingebracht, aus welchem Kontext stammt sie, und was wurde daraus abgeleitet.

Provenance ist kein Selbstzweck — sie macht Entscheidungen revidierbar. Wenn ein Stakeholder-Profil auf einer Annahme beruht, die sich als falsch herausstellt, muss sichtbar sein, welche Folge-Artefakte auf dieser Annahme aufbauen. Ohne diesen Trail entsteht stille Fehlerfortpflanzung.

Der Audit-Trail ist leichtgewichtig: kein vollständiges Protokoll jedes Token, aber ein belastbarer Nachweis für jede strategische Annahme. Format: JSONL oder Frontmatter-Felder in Markdown-Dokumenten, maschinenlesbar, nicht im Werkzeug eingesperrt.

Das Ziel in I2 ist ein laufender Provenance-Layer für die bis dahin erzeugten Kontextelemente — nicht Vollständigkeit, sondern Konsistenz für alle Elemente, die im Quality Gate I2 bewertet werden.

Top-3 Fragestellungen

1. Welche Kontextelemente gelten als strategische Annahmen, für die ein Provenance-Nachweis zwingend ist — und welche sind Detailfelder, für die ein einfacher Zeitstempel reicht?
2. Wie wird der Audit-Trail bei Änderungen aktualisiert, ohne dass der Pflegeaufwand die Nutzbarkeit übersteigt?
3. Was passiert, wenn ein Provenance-Eintrag fehlt — gibt es ein Gate, das unvollständig dokumentierte Annahmen blockiert, oder eine Warnung, die HITL auslöst?

Laufzeit-Kontextbeschaffung & Kontextfenster-Optimierung

Kontextfenster je Schritt gezielt befüllen: zur Laufzeit nachladen statt alles vorab zu laden. Größe des Fensters ist eine Ressourcenentscheidung, keine Designfrage.

Nicht jeder Schritt braucht den vollständigen Kontext. Der Retrieval-Layer beschafft je Anfrage das relevante Minimum: Auftragsklärung für die aktuelle Frage, Risikoeintrag für das aktuelle Element, Stakeholder-Profil für den aktuellen Adressaten. Vorab-Befüllung des Fensters erzeugt Token-Kosten ohne Nutzenzuwachs.

Die Optimierung hat zwei Richtungen: Relevanz (welche Kontextelemente sind für diesen Schritt nötig) und Länge (wie kurz kann ein Kontextelement sein, ohne Präzision zu verlieren). Komprimierte Kontextelemente — Zusammenfassungen, extrahierte Metazeilen — sparen Fenster, ohne Information zu verlieren, wenn die Rohdatei nachgeladen werden kann.

In I3 wird die Grundmechanik für den retrieval-gesteuerten Zugriff auf CTX-1 implementiert, zunächst für die Use Cases UC-2 und UC-4. Erweiterung auf weitere Ströme in I4.

Top-3 Fragestellungen

1. Welche Kontextelemente werden in mehr als 80 % der Agenten-Schritte benötigt — und welche sind seltene Nachschlagefelder, die lazily geladen werden können?
2. Wie wird gemessen, dass die Kontextfenster-Optimierung die Ausgabequalität nicht verschlechtert — gibt es einen Qualitäts-Benchmark vor und nach der Komprimierung?
3. Wie verhält sich das System, wenn ein benötigtes Kontextelement veraltet oder nicht verfügbar ist — gibt es einen Fallback oder wird der Lauf mit Fehler abgebrochen?

Geheimer Kontext & Abstraktions-LLM

Vertraulichen Kontext lokal halten; lokal abstrahieren, bevor ein Cloud-Schritt nötig ist. Keine Klartext-Geheimnisse in Cloud-Anfragen.

Manche Kontextelemente dürfen die lokale oder server-seitige Umgebung nicht verlassen — personenbezogene Daten, vertrauliche Geschäftszahlen, Inhalte mit hoher Datenklasse nach INF-1. Für Cloud-Schritte, die Teile dieses Kontexts brauchen, wird ein Abstraktions-LLM lokal eingesetzt: es erzeugt eine entpersonalisierte oder abstrahierte Fassung, die Cloud-sicher ist. Die Rohdatei bleibt lokal.

Das Abstraktions-Muster muss selbst auditierbar sein: welche Fassung wurde für welche Cloud-Anfrage verwendet, und wann wurde die Abstraktion erzeugt? Damit ist nachweisbar, dass keine vertraulichen Rohdaten die Grenze überschritten haben. Das Muster wird in GOV-1 als Leitplanke formalisiert und in INF-1 als Routing-Regel verankert.

In I3 wird das Muster für mindestens einen Use Case prototypisch umgesetzt: ein Schritt, der vertraulichen Kontext braucht und trotzdem eine Cloud-Anfrage stellt, muss den Abstraktions-Layer durchlaufen.

Top-3 Fragestellungen

1. Welche Kontextelemente sind vertraulich genug, dass selbst eine abstrahierte Fassung nicht in die Cloud darf — und wie wird diese Grenze operativ gezogen?
2. Wie wird die Qualität der Abstraktion bewertet — bleibt genug Kontext für eine brauchbare Cloud-Antwort, ohne vertraulichen Inhalt preiszugeben?
3. Wer darf das Abstraktions-LLM konfigurieren und seinen Output prüfen — gibt es eine HITL-Freigabe für den ersten produktiven Einsatz?

Rollen- & Rechte-Konzept ohne starre Linien

Zugriff an Datenklasse, Provenance und Aufgabe knüpfen statt an starre Hierarchie. Wer welchen Kontext sehen darf, folgt aus dem Need-to-Know, nicht aus der Orgchart-Position.

Klassische Rollensysteme bilden Hierarchien ab, nicht Wissensbedarfe. Ein Datenschutzbeauftragter braucht Zugriff auf Verarbeitungsverzeichnisse, nicht auf das gesamte Projektplan-Repository. Ein externer Berater braucht Use-Case-Specs, keine Kostendaten. Das Rechtekonzept orientiert sich an der Datenklasse des Kontextelements und dem Aufgabenkontext des Zugreifenden — dynamisch, nicht statisch.

Die Umsetzung ist modular: Datenklassen-Matrix (INF-1) definiert, welche Klasse welche Zugriffsanforderung hat. Provenance (CTX-2) dokumentiert, wer welchen Kontext eingebracht hat und wer informiert werden muss bei Änderungen. Das Rechtekonzept bindet beide Schichten zusammen, ohne eine eigene Rechteverwaltungsinfrastruktur aufzubauen.

In I4 wird das Konzept für die ersten produktiven Use Cases angewendet: wer hat Lesezugriff auf welche Kontextelemente in UC-2 und UC-4, und wie wird das zur Laufzeit geprüft?

Top-3 Fragestellungen

1. Welche Rollen haben heute implizit Zugriff auf Kontextelemente, der explizit gemacht und entweder bestätigt oder eingeschränkt werden muss?
2. Wie wird das Rechtkonzept bei neuen Projektteilnehmenden oder externen Beratern angewendet — gibt es einen definierten Onboarding-Schritt?
3. Was passiert, wenn ein Zugriff in der Laufzeit geblockt wird — gibt es einen HITL-Eskalationspfad oder bricht der Agenten-Schritt ab?

Retrieval-Fundament: RAG & BM25 (Ausblick)

Platzhalter — Volltextsuche und semantisches Retrieval über den gesamten Kontext-Pool für I6.

Dieses Paket ist ein Platzhalter. Der Umfang wird in I4 geschärft, wenn CTX-3 (Laufzeit-Kontextbeschaffung) abgenommen ist und der Kontext-Pool groß genug ist, um Retrieval-Methoden sinnvoll zu benchmarken.

Geplanter Scope: BM25-Index über Markdown-Artefakte (schnell, deterministisch, kein Embedding nötig); semantisches Retrieval (Vektor-Ähnlichkeit) als Ergänzung für unscharfe Anfragen; Evaluations-Framework (Recall@K, MRR) als Gate vor produktivem Einsatz.

Platzhalter bis I4 — Scope wird dann aus CTX-3-Erfahrungen abgeleitet.

Top-3 Fragestellungen

1. Welche Kontextelemente profitieren von BM25 (exakte Termsuche), welche von semantischem Retrieval (unscharfe Ähnlichkeit)?
2. Wie wird die Retrieval-Qualität gemessen, ohne manuelle Ground-Truth-Labeling zu erfordern?
3. Wie verhält sich das Retrieval bei vertraulichen Kontextelementen — gibt es eine Trennung des Index nach Datenklasse?

Wissensgraph & Vektor-Index für Kontext (Ausblick)

Platzhalter — Strukturierter Wissensgraph und Vektor-Datenbank für relationale Kontextabfragen in I7.

Dieses Paket ist ein Platzhalter. Es baut auf CTX-6 auf und setzt voraus, dass der Kontext-Pool groß genug ist, um Graphstruktur sinnvoll zu nutzen.

Geplanter Scope: Wissensgraph (Entitäten: AP, Stakeholder, Risiko, Entscheidung; Relationen: hängt-ab-von, betrifft, widerspricht); Vektor-Index für semantische Ähnlichkeitssuche; Abfrage-Interface für Agenten (kein direktes SQL, sondern Abfragemuster nach Kontext).

Platzhalter bis I6 — Scope wird dann aus CTX-6-Erfahrungen abgeleitet.

Top-3 Fragestellungen

1. Welche Entitätstypen und Relationen sind für das Projektmanagement am wertvollsten, um Abhängigkeiten und Konflikte automatisch zu erkennen?
2. Wie wird der Graph bei Plan-Änderungen konsistent gehalten — wer löst Konflikte bei widersprüchlichen Relationen auf?
3. Welche Abfragen soll der Graph ermöglichen, die heute manuell durchgeführt werden und messbar Zeit kosten?

Datenklassen & Lokal/Server/Cloud-Routing-Regel

Welche Daten wohin dürfen: Datenklassen-Matrix als verbindliche Grundlage für jede Routing-Entscheidung in der agentischen Landschaft.

Ohne Datenklassen-Matrix ist jede Routing-Entscheidung eine Ermessensentscheidung — damit nicht reproduzierbar und nicht auditierbar. Die Matrix kategorisiert alle Projektdaten in mindestens drei Klassen: öffentlich (Cloud zulässig), intern (Server zulässig, kein Cloud-Egress), vertraulich (nur lokal). Je Klasse gibt es eine Default-Route, die ohne weitere Prüfung gilt, und eine Ausnahme-Route, die HITL-Freigabe erfordert.

Die Matrix ist kein einmaliges Artefakt — sie wächst mit dem Plan. In I1 werden die Kernklassen definiert und auf die ersten Kontextelemente angewendet (CTX-1). In I2 werden alle Arbeitspakete nach Klasse eingestuft und die Routing-Regel in die Plattform eingebaut (INF-2 folgt). Die Matrix ist das Gate vor jeder Cloud-Anfrage.

In I1 liefert dieses Paket Version 1 der Datenklassen-Matrix: Klassendefinitionen, Default-Routing, erste Einstufungen für CTX-1-Elemente. Änderungen an der Matrix sind versioniert und erfordern ab I2 LA-Freigabe.

Top-3 Fragestellungen

1. Welche Datenklassen existieren bereits implizit in der Organisation (z. B. durch Vertraulichkeits-Stempel in Dokumenten), und wie werden diese in die neue Matrix überführt?
2. Was passiert, wenn ein Kontextelement nicht eindeutig klassifizierbar ist — gibt es eine Default-Klasse (konservativ = höchste Restriktion) oder ein Klärungsprozess?
3. Wie wird die Routing-Regel zur Laufzeit erzwungen — ist sie in der Plattform als Hard Gate implementiert oder nur als Richtlinie, die Agenten befolgen sollen?

Provider-Governance: Retention, Zero-Retention, AVV

Je Anbieter: realer Retention-Tier, Zero-Data-Retention-Nachweis, AVV — als belegte Governance-Tabelle, nicht als Vertrauen in Marketing-Versprechen.

Cloud-Anbieter haben unterschiedliche Retention-Regime: was länger als behauptet gespeichert wird, ist nicht kontrollierbar. Die Governance-Tabelle belegt je Anbieter den realen Retention-Tier (aus Vertrag oder technischer Dokumentation), ob Zero-Data-Retention buchbar ist und ob ein gültiger AVV vorliegt. Ist einer dieser drei Punkte nicht belegt, gilt der Anbieter als nicht freigegeben für vertrauliche Klassen.

Die Tabelle ist lebendes Artefakt: Anbieter ändern ihre Bedingungen, neue Anbieter kommen hinzu. Sie wird je Iteration geprüft und bei Änderungen versioniert. Ein Änderungs-Alert greift, wenn ein Anbieter seinen Tier senkt oder einen bestehenden AVV nicht verlängert.

In I1 wird die Tabelle für die in INT-0 geklärten Anbieter erstellt. In I2 folgt die Verknüpfung mit INF-1: welche Klasse darf auf welchem Anbieter verarbeitet werden, und welche Anbieter sind für bestimmte Klassen strukturell gesperrt. EU-souveräne Hoster (etwa IONOS) werden als eigener Datenpfad neben Hyperscaler-Cloud und rein lokal in INF-8 bewertet.

Top-3 Fragestellungen

1. Für welche Anbieter liegt heute schon ein unterschriebener AVV vor, und für welche ist das noch offen?
2. Welcher Anbieter hat einen nachweisbaren Zero-Data-Retention-Modus, und unter welchen Bedingungen (Tarif, Anforderung, Vereinbarung) ist dieser aktiv?
3. Was ist der Eskalationsprozess, wenn ein Anbieter seinen Retention-Tier ändert und vertrauliche Daten bereits verarbeitet wurden?

Inferenz-Topologie & Datenpfade: wo Agent und Modell laufen

Wo der Agent läuft und wo das Modell rechnet, sind zwei getrennte Entscheidungen. Aus ihrer Kombination ergeben sich die Datenpfade, die je Datenklasse zulässig sind.

Wo der Agent-Prozess läuft und wo das Modell rechnet, sind zwei getrennte Entscheidungen. Aus ihrer Kombination ergeben sich die tatsächlichen Datenpfade — und damit, was eine Datenklasse überhaupt verlassen darf. Drei Grundformen: (a) lokaler Agent mit lokalem Modell — der vertrauliche Kontext bleibt vollständig auf der eigenen Hardware; (b) lokaler Agent mit Cloud-Modell — die Orchestrierung läuft lokal, in die Cloud geht nur der einzelne Prompt, also genau das, was der Arbeitsschritt braucht; (c) Agent in der Cloud — der gesamte Arbeitskontext der Aufgabe liegt beim Anbieter. Die drei Formen unterscheiden sich vor allem darin, welcher Anteil des Kontexts wohin fließt — bei identischem Modell.

Quer zu dieser Topologie liegt das Retention-Spektrum des Anbieters: von Zero-Data-Retention (null Tage Vorhaltung) über kurze Abuse-Monitoring-Fenster bis zu 30 Tagen oder mehr. Für die Datenklasse zählt der real konfigurierte Tier, nicht der Default (Belege in INF-2). Topologie und Retention zusammen ergeben den zulässigen Datenpfad: ein lokaler Agent mit Cloud-Modell unter Zero-Retention ist ein anderer Pfad als ein Cloud-Agent ohne ZDR, auch wenn beide dasselbe Modell nutzen.

Als dritter Pfad neben rein lokal und Hyperscaler-Cloud werden EU-souveräne Hoster evaluiert: deutsche und europäische Anbieter (etwa IONOS mit seinem AI Model Hub sowie weitere DSGVO-konforme, behörden-taugliche Provider), die Inferenz innerhalb der EU mit klarer Auftragsverarbeitung anbieten. Sie tragen für Klassen, die nicht lokal bleiben müssen, aber den Hyperscaler-Pfad meiden sollen. Das Paket bewertet je Pfad Datenfluss, Retention, Vertragslage und Eignung je Datenklasse und liefert eine Pfad-Matrix, die in das Routing (INF-4) eingeht. In I2 werden Topologien und Kandidaten erfasst, in I3 gegen die Datenklassen-Matrix (INF-1) und die Provider-Governance (INF-2) bewertet. Die rechtliche Letztbeurteilung bleibt bei qualifizierten Anwälten.

Top-3 Fragestellungen

1. Welche Datenklassen dürfen den lokalen Rahmen verlassen, und welche Topologie (lokaler Agent + Cloud-Modell, Cloud-Agent, souveräner Hoster) ist je Klasse überhaupt zulässig?
2. Welche EU-souveränen Hoster (IONOS u. a.) erfüllen nachweisbar DSGVO- und Behörden-Anforderungen mit gültiger Auftragsverarbeitung und belegbarem Retention-Tier — und für welche Klassen tragen sie?
3. Wie wird strukturell verhindert, dass ein Cloud-Agent mehr Kontext mitnimmt als der Arbeitsschritt braucht, und wie wird der real genutzte Datenpfad je Anfrage protokolliert (Anknüpfung INF-5)?

Modell-Auswahl: lokal (M5-Klasse) vs. Cloud je Use Case

Je Use Case lokal oder Cloud, gemessen an Vertraulichkeit, Qualität und Kosten. Kein Modell hartkodiert — Wechsel über Konfiguration.

Die Modell-Wahl ist eine Routing-Entscheidung, keine Designentscheidung. Je Use Case gelten drei Kriterien: Datenklasse des Kontexts (INF-1 bestimmt, ob Cloud zulässig ist), Qualitätsbedarf (reicht ein kleineres lokales Modell, oder ist Cloud-Modell für diese Aufgabe nötig) und Kosten (Token-Kosten je Cloud-Lauf vs. Latenz-Kosten lokal). Diese drei Kriterien werden je Use Case dokumentiert und ins Modell-Routing eingebaut.

Lokal bedeutet: Modelle der M5-Klasse (128 GB RAM, quantisierte Modelle bis ~70B Parameter). Cloud bedeutet: Anthropic, OpenAI oder vergleichbare Anbieter, nach INF-2 freigegeben. Das Routing ist konfigurierbar — ein Use Case kann in der Entwicklung lokal laufen und in I4 auf Cloud wechseln, ohne Code-Änderung.

In I2–I3 wird das Routing für UC-2 (Auftragsklärung) und UC-3 (Voice → Transkript) implementiert. Beide haben unterschiedliche Datenklassen und Qualitätsanforderungen — sie sind geeignete Benchmark-Kandidaten für das Routing-Muster.

Top-3 Fragestellungen

1. Welche lokalen Modelle sind heute auf der M5-Hardware tatsächlich lauffähig und ausreichend getestet — und welche sind Kandidaten, aber noch nicht evaluiert?
2. Wie wird bei einem lokalen Modell gemessen, ob die Qualität für den Use Case ausreichend ist — gibt es ein Evaluations-Framework oder reicht manuelle Sichtprüfung?
3. Was passiert bei Ausfall des lokalen Modell-Servers — gibt es einen automatischen Fallback auf Cloud (mit Datenklassen-Gate) oder stoppt der Use Case?

Plattform-Unterbau: datenklassen-basiertes Routing & Orchestrierung

Routing je Datenklasse + Orchestrierungsschicht mit belastbarer Observability. Kein Blindflug: jeder Agent mit Session, Kontext, Instruktion nachvollziehbar.

Die Plattform ist mehr als die Summe ihrer Werkzeuge — sie braucht eine Orchestrierungsschicht, die Agenten koordiniert, Kontexte zuteilt und Routing-Entscheidungen automatisiert. Diese Schicht ist von Anfang an observabel: welcher Agent läuft in welchem Kontext, mit welcher Instruktion, seit wann, mit welchen Kosten. Zombie-Agenten — laufend ohne Auftrag — sind erkennbar und beendbar.

Das Datenklassen-Routing aus INF-1 wird in der Orchestrierungsschicht als Hard Gate umgesetzt: jede Kontextanfrage prüft die Klasse, bevor sie an ein Modell weitergegeben wird. Das ist nicht die Plattform, die hofft, dass Agenten die Regeln einhalten — es ist eine technische Erzwingung. Die Schicht ist selbst auditierbar (INF-5).

In I3–I4 wird die Grundstruktur der Orchestrierungsschicht für die ersten produktiven Use Cases implementiert. Vollständige Robustheit (Failover, Multi-Agent, parallele Läufe) folgt in I5–I6.

Top-3 Fragestellungen

1. Welches Orchestrierungs-Framework oder -Muster ist für die Organisation und den Tech-Stack am geeignetsten — und gibt es einen klaren Exit-Plan, wenn das gewählte Framework nicht skaliert?
2. Wie wird die Orchestrierungsschicht selbst überwacht — wer beobachtet den Beobachter, und wie werden Fehler in der Schicht selbst erkannt?
3. Wie viele gleichzeitige Agenten-Läufe muss die Plattform in I4 und I5 tragen — und ist die lokale Hardware der Engpass oder die Orchestrierungs-Logik?

Audit & Logging des Modell- und Datenflusses

Jeder Modell- und Datenfluss auditierbar protokolliert — Nachweis statt Behauptung. Offene Formate, kein Lock-in im Logging-Werkzeug.

Audit-Logging ist kein optionales Feature — es ist die technische Grundlage dafür, dass Compliance-Anforderungen (DSGVO, EU AI Act) belegt werden können, ohne auf Vertrauen in Prozesse angewiesen zu sein. Je Modell-Aufruf werden mindestens erfasst: Zeitstempel, Modell-ID, Eingabekontext (pseudonymisiert nach Datenklasse), Ausgabe-Hash, Kosten in Token und Euro, aufrufender Use Case.

Der Log ist unveränderbar — einmal geschrieben, nicht editierbar. Kompromittierung eines Eintrags ist erkennbar (Hash-Prüfung). Ablageformat: JSONL in offenen Formaten, lokal oder server-seitig nach Datenklasse der protokollierten Daten. Kein exklusiver Lock-in in einem Monitoring-Werkzeug.

In I3 wird das Logging für alle produktiven Use Cases implementiert, zusammen mit INF-4 (Orchestrierung). Ein erster Report-Lauf zeigt, ob Kosten- und Routing-Kennzahlen korrekt erfasst werden.

Top-3 Fragestellungen

1. Welche Informationen aus dem Modell-Aufruf sind so vertraulich, dass sie selbst im Audit-Log nicht im Klartext stehen dürfen — und wie wird das technisch umgesetzt (Pseudonymisierung, Hashing)?
2. Wie lange werden Audit-Logs aufbewahrt, und wer hat Lesezugriff darauf — gibt es eine Aufbewahrungspflicht nach DSGVO oder AVV?
3. Wie wird das Logging bei Ausfall des Log-Backends behandelt — bricht der Use Case ab, oder läuft er weiter mit einem Warnhinweis im nächsten Report?

Betriebsmodell on-prem vs. Cloud festlegen

Platzhalter — Entscheidung über langfristiges Betriebsmodell nach Erfahrungen aus I1–I4.

Dieses Paket ist ein Platzhalter. Die Scope-Definition erfolgt in I4, wenn erste Betriebserfahrungen aus INF-4 und INF-5 vorliegen.

Geplanter Scope: Vergleich on-prem (eigene Hardware) vs. Cloud-native vs. Hybrid nach Kosten, Kontrolle, Wartungsaufwand und Skalierbarkeit; Entscheidung dokumentiert als ADR; Migrations-/Stabilitätspfad für den gewählten Weg.

Platzhalter bis I4.

Top-3 Fragestellungen

1. Welche Betriebsaspekte (Backup, Hochverfügbarkeit, Patching) werden heute von der IT-Abteilung zentral übernommen, und welche muss das Projekt selbst verantworten?
2. Wie hoch ist die Toleranz der Organisation für lokale Hardware-Abhängigkeit (single point of failure) im Vergleich zu Cloud-Abhängigkeit?
3. Gibt es eine bestehende IT-Strategie (Cloud-first, on-prem bevorzugt), die den Entscheidungsraum für das Betriebsmodell bereits einengt?

Off-Laptop-Sicherung & deterministische Skalierungs-Tools

Platzhalter — Robustheitsstufe: Off-Laptop-Backup, deterministische Werkzeuge für skalierenden Betrieb in I6–I7.

Dieses Paket ist ein Platzhalter. Scope wird in I5 nach Betriebsmodell-Entscheidung (INF-6) definiert.

Geplanter Scope: Off-Laptop-Git-Server für alle vertraulichen Artefakte; deterministische Build- und Deployment-Werkzeuge; Backup-Rhythmus und -Prüfung; Kapazitäts-Monitoring bei wachsendem Kontext-Pool.

Platzhalter bis I5.

Top-3 Fragestellungen

1. Welche Artefakte (Kontext-Pool, Audit-Logs, PSP-Daten) sind bisher nur lokal gesichert und müssten bei Hardware-Ausfall neu erzeugt werden?
2. Wie wird ein Off-Laptop-Backup bei vertraulichen Inhalten implementiert, ohne Cloud-Egress zu erlauben?
3. Welche Skalierungsgrenze ist heute schon absehbar (Kontext-Pool-Größe, Anzahl gleichzeitiger Agenten), und welches Werkzeug adressiert diese Grenze deterministisch?

Gesetzes- & Anweisungs-Korpus erschließen

Gesetze, Richtlinien und interne Dienstanweisungen erfassen, normalisieren und versionieren — als maschinenlesbare Grundlage für die agentische Compliance-Prüfung.

Compliance-Prüfung durch Agenten setzt voraus, dass der Prüf-Korpus selbst strukturiert, versioniert und referenzierbar vorliegt. Rohe PDF-Dokumente oder Intranet-Seiten ohne Struktur sind kein tauglicher Ausgangspunkt. Dieses Paket erschließt den Korpus: EU AI Act (Risikoklassen, Art. 4 Literacy), DSGVO (Verarbeitungsverzeichnis, DSFA-Pflicht), BetrVG §87, interne IT-Dienstanweisungen.

Erschließen bedeutet: Dokumente in maschinenlesbare Abschnitte zerlegen (Paragraphen, Erwägungsgründe, Dienstanweisungs-Artikel), mit IDs versehen, versionieren und in CTX-1 als Kontextelemente registrieren. Ändert sich ein Dokument, zeigt die Provenance-Kette (CTX-2), welche abgeleiteten Artefakte (DSFA, AVV, Stellungnahme) davon betroffen sind.

In I1–I2 werden die Kerndokumente erschlossen: EU AI Act Kernartikel, DSGVO Art. 6/9/13/28/35, BetrVG §87, IT-Dienstanweisung Cloud-Nutzung. Vollständigkeit des gesamten Regelwerks folgt in I3.

Top-3 Fragestellungen

1. Welche internen Dienstanweisungen existieren heute für Cloud-Nutzung, Datenweitergabe und KI-Einsatz — und sind diese in einem zentralen Verzeichnis findbar, oder sind sie verteilt über verschiedene Systeme?
2. Wer ist zuständig für die Pflege des Regelwerks in der Organisation — gibt es eine Stelle, die neue Gesetze und Richtlinien übersetzt und verteilt, oder passiert das ad hoc?
3. Wie wird mit Widersprüchen zwischen internen Dienstanweisungen und externen Rechtsnormen umgegangen — gibt es eine Eskalations-Regel (extern geht vor), oder wird das im Einzelfall entschieden?

AVV & DSFA strukturieren

Auftragsverarbeitungsverträge je Provider und Datenschutz-Folgenabschätzung für den KI-Einsatz in bearbeitbare, agentisch prüfbare Form bringen.

Ein AVV, der als PDF in einem Intranet-Ordner liegt, ist für agentische Prüfung wertlos. Dieses Paket überführt AVVs je Provider (nach INF-2 identifiziert) und die DSFA in strukturierte, versionierte Artefakte: Je AVV eine Metazeile (Provider, Datum, Gültigkeitsdauer, Klassen-Freigabe, offene Klärungspunkte), je DSFA eine Bewertungsstruktur (Verarbeitung, Risiko, Maßnahme, Verantwortlicher).

Die DSFA ist kein einmaliges Dokument — sie wird angepasst, wenn sich der Verarbeitungskontext ändert (neuer Use Case, neue Datenklasse, neuer Anbieter). Strukturiert bedeutet: Frontmatter in Markdown oder YAML, maschinenlesbar, referenzierbar aus CMP-3 (agentische Prüfung). Änderungen an AVV oder DSFA lösen automatisch eine HITL-Benachrichtigung aus.

In I2 wird die DSFA-Erstfassung für den Verarbeitungskontext der ersten Use Cases erstellt (UC-2, UC-3). In I3 werden alle AVVs der bis dahin aktiven Anbieter strukturiert. Freigabe durch DSB und Legal ist Gate für UC-2-Produktivstart.

Top-3 Fragestellungen

1. Welche Provider haben bereits einen gültigen AVV, und für welche ist das noch offen — gibt es eine Frist im bestehenden Betrieb, die eine Beschleunigung erfordert?
2. Liegt für den aktuellen KI-Einsatz (auch bestehenden Schatten-KI-Einsatz) bereits eine DSFA vor, oder muss das Vorhaben diese erstmals erstellen?
3. Wer in Legal oder Datenschutz hat die Kompetenz, AVVs und DSFA inhaltlich zu prüfen — und ist diese Person ab I2 verfügbar?

Agentische Compliance-Prüfung (inhärent je Arbeitsschritt)

Prüfung in jeden Arbeitsschritt eingebaut — nicht als nachgelagerter Audit, sondern als inhärentes Gate. HITL ab definierter Schwere.

Compliance-Prüfung als nachgelagerter Schritt kommt zu spät: bis dahin sind Entscheidungen bereits getroffen, Kontext bereits verarbeitet. Inhärente Prüfung bedeutet, dass jeder relevante Arbeitsschritt die Prüfung als Teil seines Ablaufs enthält — nicht als Anhang. Welche Prüfungen für welchen Schritt nötig sind, leitet sich aus dem Prüf-Korpus (CMP-1) und der AVV/DSFA (CMP-2) ab.

Die Prüftiefe skaliert mit der Schwere: einfache Schritte bekommen eine schnelle Regel-Prüfung (ist der Kontext klassifiziert, ist der Provider freigegeben), komplexe Schritte bekommen eine tiefere Prüfung (DSFA-Konsistenz, HITL-Gate). HITL-Eskalation greift, wenn eine Prüfung nicht eindeutig entschieden werden kann oder wenn die Schwere-Schwelle überschritten ist.

In I3 wird die agentische Compliance-Prüfung für UC-2 (Auftragsklärung) implementiert. In I4 wird sie auf UC-4 (Statusberichte) ausgedehnt. Vollständige Abdeckung aller Use Cases in I5.

Top-3 Fragestellungen

1. Wie wird „Schwere" einer Compliance-Entscheidung operativ definiert — gibt es eine Taxonomie (gering/mittel/hoch/kritisch) mit klaren Grenzwerten?
2. Was passiert, wenn die agentische Prüfung einen Compliance-Verstoß feststellt — gibt es einen automatischen Stop, einen HITL-Alert, oder nur eine Protokollierung?
3. Wie wird die Qualität der agentischen Prüfung selbst überwacht — gibt es periodische manuelle Stichproben, die die Prüfergebnisse gegen den Regelkatalog vergleichen?

AI-Literacy nach Art. 4 EU AI Act

KI-Kompetenz-Anforderungen je Rolle ableiten und belegbar nachweisen — Art. 4 EU AI Act als Pflicht, nicht als Kulisse.

Art. 4 EU AI Act verpflichtet Betreiber von KI-Systemen, sicherzustellen, dass Personal im Umgang mit KI ausreichend kompetent ist. Was das je Rolle bedeutet, ist nicht im Gesetz definiert — es muss für jeden Kontext abgeleitet werden. Dieses Paket übersetzt Art. 4 in konkrete Kompetenz-Profile je Rolle im Vorhaben: Projektleitung, HITL-Verantwortliche, Use-Case-Betreibende, Governance-Rollen.

Belegbarkeit ist Pflicht: kein Schulungsnachweis-Theater, sondern nachweisliche Kompetenz-Verifikation. Das kann eine dokumentierte Einweisung sein, eine Prüfungsaufgabe, oder ein Nachweis aus einem bestehenden Schulungsprogramm. Der Nachweis ist je Person in CTX-2 protokolliert. Bei Rollenwechsel greift eine erneute Prüfung.

In I3 werden die Kompetenz-Profile erstellt und die erste Runde Nachweise für alle aktiven Rollen eingeholt. Die Compliance-Prüfung (CMP-3) prüft je Use-Case-Start, ob alle beteiligten Rollen nachgewiesen qualifiziert sind.

Top-3 Fragestellungen

1. Welche Rollen im Vorhaben sind direkt „betreibend" im Sinne des EU AI Acts — und welche sind nur beratend oder unterstützend, ohne eigene Betreiber-Pflicht?
2. Gibt es im Konzern bereits ein KI-Schulungsprogramm oder eine Zertifizierung, die als Nachweis für Art. 4 anerkannt werden kann?
3. Wie wird mit Zulieferern oder externen Beratern umgegangen, die KI-Systeme des Vorhabens nutzen — greift die Literacy-Pflicht auch für sie?

Änderungsvorschläge ans Management

Wo Vorgaben hemmen und Nachteile gering sind: belegte Änderungsvorschläge erzeugen — nicht als Kritik, sondern als fundierte Entscheidungsvorlage.

Nicht alle hemmenden Vorgaben sind schlechte Vorgaben — manche sind Schutzmaßnahmen mit gutem Grund. Dieses Paket erzeugt Änderungsvorschläge nur, wenn drei Bedingungen erfüllt sind: die Vorgabe hemmt einen Use Case messbar, die Nachteile einer Änderung sind gering, und es gibt eine belegte Alternative (aus dem Compliance-Korpus oder externen Quellen).

Änderungsvorschläge werden als Entscheidungsvorlage aufbereitet: aktuelle Regelung, Hemmungs-Nachweis, Änderungsvorschlag, Risiko der Änderung, Empfehlung. Nicht als Beschwerde, sondern als Analyse mit Handlungsoption. Der Lenkungsausschuss entscheidet; das Vorhaben implementiert.

In I5 wird ein erster Durchlauf aller bis dahin identifizierten Hemmungen gemacht. Vorschläge mit besonders klarem Nutzenpotenzial werden priorisiert und zur LA-Sitzung I5 vorgelegt.

Top-3 Fragestellungen

1. Welche internen Vorgaben werden heute schon im Betrieb umgangen oder ignoriert, weil sie als nicht praktikabel gelten — und wäre dort ein Änderungsvorschlag ein geringer Aufwand mit großer Wirkung?
2. Wie reagiert die Organisation typischerweise auf Vorschläge zur Änderung interner Richtlinien — gibt es einen definierten Änderungsprozess oder ist das Terrain politisch heiß?
3. Welche externe Guidance (EU AI Act Leitfäden, DSGVO Working Party Stellungnahmen) könnte als Stützung für Änderungsvorschläge dienen?

Anwalts-Freigabe-Gate & Rechtsregister

Platzhalter — Formales Freigabe-Gate für rechtlich kritische Entscheidungen und ein Rechtsregister als Nachschlagewerk in I6.

Dieses Paket ist ein Platzhalter. Scope wird in I4 nach CMP-3 definiert.

Geplanter Scope: Formaler Gate-Prozess für Use Cases und Integrationen mit rechtlichem Risiko; Rechtsregister als maschinenlesbares Verzeichnis aller abgeklärten Rechtsfragen mit Ergebnis und Datum.

Platzhalter bis I4.

Top-3 Fragestellungen

1. Für welche Entscheidungen ist eine formale Rechtsberatung zwingend, und für welche reicht die interne Prüfung durch den DSB?
2. Gibt es eine bestehende Kanzlei-Beziehung, die für KI-Rechtsfragen aktiviert werden kann?
3. Wie wird das Rechtsregister aktuell gehalten, wenn sich Gesetze oder Guidance-Dokumente ändern?

Lizenz- & Urheberrechts-Prüfung KI-Output

Platzhalter — Prüfung, wem KI-generierte Outputs gehören und welche Lizenzbedingungen der eingesetzten Modelle gelten in I7.

Dieses Paket ist ein Platzhalter. Scope wird in I5 nach den ersten produktiven Use Cases definiert.

Geplanter Scope: Überblick Lizenzregime der eingesetzten Modelle (Training-Daten-Herkunft, Output-Lizenz, kommerzielle Nutzungsbedingungen); Richtlinie für KI-generierte Outputs im Projektkontext (Urheberschaft, Verwendungspflicht der Angabe).

Platzhalter bis I5.

Top-3 Fragestellungen

1. Welche Modelle werden im Vorhaben produktiv eingesetzt, und welche Lizenzmodelle gelten für ihre Outputs?
2. Müssen KI-generierte Projektergebnisse als solche gekennzeichnet werden — gibt es eine interne oder externe Anforderung dafür?
3. Wie gehen bestehende Kundenverträge oder Kooperationsvereinbarungen mit KI-generierten Inhalten um?

Use-Case-Auswahl und Nutzen-Kriterien

Erste Use Cases nach drei Kriterien auswählen: niedrig-riskant (Datenklasse handhabbar), schnell wertschöpfend (Ergebnis in I2–I3 sichtbar), lehrreich (Plattform-Erkenntnisse für weitere Use Cases).

Nicht jeder mögliche Use Case ist der richtige erste Use Case. In einem Vorhaben, das gleichzeitig Unterbau baut und Use Cases liefern soll, braucht die Auswahl drei Kriterien: Das Risiko-Profil muss handhabbar sein (Datenklasse, HITL-Bedarf, Compliance-Betroffenheit), der Nutzen muss in I2–I3 sichtbar sein (kein Ergebnis in I7 für den ersten Use Case), und der Use Case muss Erkenntnisse liefern, die die Plattform für nachfolgende Use Cases verbessern.

Die Auswahl ist keine einmalige Entscheidung — das Use-Case-Portfolio wird je Iteration überprüft. Neue Kandidaten durchlaufen dasselbe Kriterien-Raster; Kandidaten, die nicht mehr passen, werden zurückgestellt oder gestrichen. Scope Creep beim Portfolio ist das häufigste Risiko in Phase I3–I5.

In I1 wird das Use-Case-Portfolio (UC-2 bis UC-7) anhand der Kriterien priorisiert. Das Ergebnis ist eine Priorisierungstabelle: Use Case, Kriterium-Scores, Startiteration, Verantwortlicher. UC-2 und UC-3 starten in I2.

Top-3 Fragestellungen

1. Welche PM-Routinen kosten heute am meisten manuelle Zeit — und bei welchen ist die Qualität oft schwankend, weil sie von der Erfahrung einzelner Personen abhängt?
2. Gibt es Use Cases, die intern bereits informal erprobt werden (Schatten-KI), und wären diese gute Kandidaten für eine geordnete Erstintegration?
3. Wer entscheidet, welche Use Cases in das Portfolio aufgenommen werden — ist das die Projektleitung allein, oder gibt es einen fachlichen Sponsor je Use Case?

Use Case live: KI-gestützte Auftragsklärung und Klärungsfragen

Klärungsdialog zwischen Auftraggeber und Projektleitung → strukturierter Kontext → abgeleitete Klärungsfragen je Element. Ergebnis: Kontextmodell stärker als vorher.

Die Auftragsklärung ist der schwerste Schritt im Projektplanungszyklus — und am häufigsten der unschärfste. Klärungsfragen helfen, Annahmen explizit zu machen, bevor der Plan darauf aufbaut. Dieser Use Case nimmt einen bestehenden Klärungsdialog (Meeting, Interview, Workshop-Transkript aus INT-5) und erzeugt daraus: einen strukturierten Kontext (was ist bekannt, was ist Annahme, was ist offen), und für jedes Element des PM-Zyklus abgeleitete Klärungsfragen — priorisiert nach Dringlichkeit.

Der Use Case ist read-only in Bezug auf das Produktivsystem der Organisation: es werden keine Entscheidungen in Fremdsysteme zurückgeschrieben. Die Ausgabe geht in den Kontext-Pool (CTX-1), wo sie vom nächsten Agenten-Schritt aufgenommen wird. HITL-Gate: eine Person prüft die generierten Fragen, bevor sie zum Auftraggeber gehen.

Voraussetzung für den Produktivstart: GOV-2 (Betriebsrat-Zustimmung) und CMP-2 (AVV/DSFA für den Verarbeitungskontext) sind abgenommen. In I2 wird der Use Case in einer Test-Runde mit internem Material geprüft; in I3 geht er in den produktiven Einsatz.

Top-3 Fragestellungen

1. Wie gut ist der Klärungsdialog heute dokumentiert — gibt es Gesprächsnotizen, Meeting-Protokolle, oder liegt das nur in den Köpfen der Beteiligten?
2. Welche Klärungsfragen kommen heute am häufigsten zu spät auf (erst in I3 oder I4), weil sie in der Auftragsklärung nicht gestellt wurden?
3. Wie wird die Ausgabe des Use Cases in die bestehenden Projektdokumente übernommen — gibt es einen festen Schritt, oder ist das Ad-hoc-Entscheidung der Projektleitung?

Voice → Transkript → Kontext (Parakeet STT)

Meeting-Audio lokal in strukturierten, vertraulichkeitskonformen Kontext überführen. Parakeet TDT 0.6B v3 (nvidia/parakeet-tdt-0.6b-v3) via parakeet-mlx — keine Cloud für vertrauliche Inhalte.

Meetings, Workshops und Klärungsgespräche sind die reichsten Kontextquellen im Projekt — und die flüchtigsten. Ohne Transkription gehen Entscheidungen, Bedenken und implizites Wissen verloren oder werden falsch erinnert. Dieser Use Case macht die Meeting-Transkription zum Standardprozess: Audio lokal aufnehmen, lokal transkribieren, Transkript strukturieren und in CTX-1 registrieren.

Das STT-Modell ist Parakeet TDT 0.6B v3 (nvidia/parakeet-tdt-0.6b-v3) via parakeet-mlx auf Apple Silicon. Es läuft vollständig lokal — kein Audio verlässt das Gerät. Für nicht-vertrauliche Meetings kann Cloud-STT als Alternative konfiguriert werden, wenn INF-1 das erlaubt. Bestehende Captions/Untertitel werden bevorzugt vor eigenem Transkript.

Das strukturierte Transkript enthält: Zeitmarken, Sprecherkennung (wo möglich), identifizierte Entscheidungen und offene Punkte als maschinenlesbare Felder. Es fließt in CTX-1 als Kontextelement und steht UC-2 und UC-4 als Eingabe zur Verfügung. Rohdatei wird aufbewahrt, Transkriptionsquelle im Frontmatter.

Top-3 Fragestellungen

1. Welche Meetings werden heute schon aufgezeichnet, und welche sind bisher undokumentiert — gibt es eine Betriebsvereinbarung oder Richtlinie für Aufzeichnung?
2. Wie wird mit Meetings umgegangen, an denen externe Teilnehmende beteiligt sind — reicht die Datenklassen-Prüfung aus, oder braucht es eine Einwilligung der Externen?
3. Was ist der Prozess, wenn Parakeet TDT auf lokaler Hardware zu langsam ist — gibt es eine akzeptable Latenz, und ab welcher Länge muss asynchron transkribiert werden?

Use Case: KI-gestützte Statusberichte

Berichte aus dem Kontext verdichten — jede Aussage über Provenance belegbar. Kein Bericht ohne Quellenangabe, kein Bericht ohne HITL-Freigabe.

Statusberichte sind der häufigste Kommunikationskanal im Projekt — und oft der aufwändigste manuell zu erstellende. Dieser Use Case erzeugt einen Statusbericht-Entwurf aus dem Kontext-Pool: Stand je Strom, offene Gate-Blocker, Abweichungen gegen Baseline, nächste Meilensteine. Jede Aussage hat eine Provenance-Referenz (CTX-2): woher kommt die Information, wann war sie aktuell.

Der Entwurf ist ein Entwurf — er geht in HITL-Freigabe bevor er versendet wird. HITL-Verantwortlicher prüft: Sind alle kritischen Informationen vollständig? Gibt es Widersprüche zwischen Strom-Status und Gesamt-Status? Wird etwas beschönigt, was rot sein sollte? Die Freigabe wird in CTX-2 protokolliert.

In I3 wird der Use Case für den Lenkungsausschuss-Bericht implementiert. Das Gate-Protokoll zum Quality Gate I3 ist der erste produktive Lauf. In I4 wird der Use Case auf wöchentliche Statusberichte ausgedehnt.

Top-3 Fragestellungen

1. Welche Information aus dem aktuellen Statusbericht-Prozess ist heute am aufwändigsten zu sammeln — und ist diese Information in strukturierter Form im Kontext-Pool verfügbar?
2. Wie detailliert muss ein KI-generierter Statusbericht sein — gibt es ein Standardformat für den Lenkungsausschuss, und wird der Use Case dieses Format sofort treffen oder erst iterativ?
3. Was passiert, wenn der Kontext-Pool unvollständig ist und der Bericht deshalb Lücken hat — wird das im Entwurf transparent gemacht, oder ignoriert der Use Case fehlende Daten?

Use Case: KI-gestützte Risiken- und Stakeholder-Pflege

Register KI-getrieben mitlaufen lassen — Änderungen nach GOV-1-Leitplanken, HITL bei strategischen Einträgen.

Risiken- und Stakeholder-Register sind klassische Artefakte, die am ersten Tag sehr gepflegt sind und dann in der Hektik des Projektalltags veralten. Dieser Use Case macht sie zu lebenden Dokumenten: bei jedem relevanten Kontext-Update (neues Meeting-Transkript, neue Stakeholder-Rückmeldung, neuer Compliance-Befund) prüft ein Agent, ob ein Eintrag anzupassen ist, und schlägt eine Änderung vor.

GOV-1 definiert die Leitplanken: Agenten schlagen vor, HITL entscheidet bei strategischen Einträgen (Stakeholder-Eskalation, neues kritisches Risiko). Nicht-strategische Updates (Aktualisierung eines Kontakts, Status-Change bei bestehendem Risiko) können mit niedrigerer HITL-Schranke behandelt werden.

In I3 wird der Use Case für das Risiken-Register implementiert. Stakeholder-Register folgt in I4, wenn der Use Case für Risiken stabil läuft und die HITL-Protokolle etabliert sind.

Top-3 Fragestellungen

1. Wie oft wird das Risiken-Register heute tatsächlich aktualisiert — ist es ein wöchentlicher Prozess oder eher ein Quartalsprojekt?
2. Welche Risiko-Typen (technische, organisatorische, Compliance-Risiken) soll der Use Case abdecken, und gibt es Risiken, die manuell gepflegt bleiben müssen?
3. Wie wird sichergestellt, dass ein Agent kein Risiko aus dem Register entfernt, das noch aktiv ist — gibt es einen Hard Stop für Löschoperationen?

Dokument-Synchronisation der Projektartefakte

Abhängige Projektdokumente bei Quell-Änderung erkennen und angleichen — kein stilles Veralten von Folge-Dokumenten.

Wenn sich die Auftragsklärung in I3 ändert, betrifft das potenziell Ziele, Risiken, Stakeholder-Profil und Kostenplan. Manuell ist dieser Propagations-Schritt aufwändig und fehleranfällig — er wird oft ausgelassen. Dieser Use Case erkennt bei einer Quell-Änderung automatisch, welche Folgedokumente betroffen sind (via Provenance-Kette CTX-2) und erzeugt Aktualisierungs-Vorschläge.

Die Propagation ist konservativ: kein Dokument wird automatisch geändert. Der Vorschlag enthält: betroffenes Dokument, betroffene Stelle, vorgeschlagene Änderung, Begründung (welche Quell-Änderung hat das ausgelöst). HITL entscheidet je Vorschlag. Vorschläge ohne HITL-Entscheid nach 7 Tagen werden eskaliert.

In I4 wird der Use Case für die Propagation aus der Auftragsklärung implementiert. Es ist einer der komplexeren Use Cases — er setzt CTX-2 (Provenance) stabil voraus. Vollständige Propagation für alle 14 PM-Elemente folgt in I5–I6.

Top-3 Fragestellungen

1. Welche Dokument-Abhängigkeiten sind heute bekannt und würden von automatischer Propagation am meisten profitieren?
2. Wie wird verhindert, dass ein Propagations-Vorschlag einen Dokument-Stand überschreibt, der bereits bewusst von der Quelle abweicht (intentionaler Scope-Unterschied)?
3. Was ist die erwartete Anzahl täglicher Propagations-Vorschläge bei aktivem Projektbetrieb — und ist das HITL-Volumen für die verantwortliche Person tragbar?

Iterations- und Provenance-Pflege des Plans

Platzhalter — Automatisierte Pflege der Iterations-Historie und Provenance-Kette für den gesamten Plan in I5.

Dieses Paket ist ein Platzhalter. Scope wird in I4 nach den Erfahrungen aus UC-2 bis UC-6 definiert.

Geplanter Scope: Automatisiertes Diff je Iteration (was hat sich im Plan geändert, warum); Iterations-Eintrag in die Historie (CTX-2); Provenance-Lücken im Plan erkennen und HITL auslösen.

Platzhalter bis I4.

Top-3 Fragestellungen

1. Wie viele Planänderungen je Iteration sind realistisch zu erwarten, und ist eine automatisierte Diff-Erkennung für dieses Volumen verhältnismäßig?
2. Welche Provenance-Lücken im aktuellen Plan sind bekannt, und wäre eine automatisierte Erkennung ein geringerer Aufwand als manuelle Durchsicht?
3. Wie wird die Iterations-Historie langfristig aufbewahrt, und wer hat in I7 noch Zugriff auf die Entscheidungshistorie aus I1?

Leitplanken definieren: det. vs. prob., Gates, HITL, Reversibilität

Was darf die KI autonom: deterministisch vs. probabilistisch, Gates nach Reversibilität, HITL nach Schwere. Leitplanken sind schriftlich — nicht implizit.

Ohne explizite Leitplanken entscheiden Agenten nach Kontext, nicht nach Organisation. Leitplanken definieren, was automatisiert und was mit HITL läuft, welche Ausgaben vor Verwendung durch eine Person geprüft werden und welche Entscheidungen reversibel vs. irreversibel sind. Irreversible Entscheidungen (Daten gelöscht, Dokument versendet, Entscheidung protokolliert) bekommen immer ein HITL-Gate — keine Ausnahme.

Das deterministische vs. probabilistische Spektrum wird je Werkzeug explizit gemacht: ein Routing-Gate ist deterministisch (Hard Rule, keine LLM-Entscheidung), ein Entwurf-Generator ist probabilistisch (Ergebnis variiert, braucht HITL). Diese Unterscheidung verhindert, dass probabilistische Werkzeuge an Stellen eingesetzt werden, die Zuverlässigkeit erfordern.

In I1 werden die Leitplanken für die Use Cases UC-2 und UC-3 formuliert. In I2 folgt das vollständige Leitplanken-Dokument für alle Ströme. Das Dokument ist SSoT für GOV-4 (Management-Transparenz) und CMP-3 (Compliance-Prüfung).

Top-3 Fragestellungen

1. Gibt es heute schon informelle Leitplanken (Regeln, die das Team stillschweigend befolgt), die formalisiert werden sollten?
2. Wie wird ein Verstoß gegen eine Leitplanke erkannt und behandelt — gibt es einen technischen Hard Stop oder nur ein Protokolleintrag?
3. Wer hat das Mandat, Leitplanken zu ändern — Projektleitung allein, oder braucht es LA-Beschluss für jede Änderung?

Betriebsrat & Mitbestimmung einbinden

Betriebsrat früh als Partner, nicht als Hürde am Ende. Material für eine Betriebsvereinbarung bereitstellen — transparent, überprüfbar, mit nachweisbaren Ausschlüssen.

Der Betriebsrat hat nach §87 BetrVG Mitbestimmungsrecht bei technischen Einrichtungen, die Verhalten oder Leistung überwachen können. KI-Systeme berühren dieses Recht nahezu immer. Eine frühe, transparente Einbindung ist kein Risiko, sondern die Grundlage dafür, dass das Vorhaben überhaupt starten kann, ohne später blockiert zu werden.

Das Material für die Betriebsvereinbarung enthält: Liste der eingesetzten Systeme, je System was es erfasst und was es nicht erfasst, welche Personendaten es verarbeitet, welche HITL-Rollen Zugriff haben und welche Ausschlüsse technisch implementiert sind (nicht nur zugesagt). Ausschlüsse sind belegt, nicht behauptet — der Betriebsrat erhält Zugang zum Audit-Log-Format als Verifikation.

In I1 findet die erste Informationssitzung mit dem Betriebsrat statt (orientierend, ohne formalen Beschluss). In I2 wird das Material für eine Betriebsvereinbarung vorgelegt. Produktivstart von UC-2 ist erst nach BR-Zustimmung oder nach Ablauf der Mitbestimmungsfrist.

Top-3 Fragestellungen

1. Welche konkreten Befürchtungen hat der Betriebsrat bereits geäußert — und welche davon können technisch ausgeschlossen werden?
2. Gibt es im Konzern eine Rahmenbetriebsvereinbarung zu IT-Systemen, die als Vorlage oder Analogie für die KI-Betriebsvereinbarung dienen kann?
3. Wie schnell läuft der Mitbestimmungsprozess typischerweise in diesem Konzern — gibt es eine Erfahrung aus vergangenen IT-Einführungen?

Change & Coaching der Menschen

Verschiebung vom Ausführen zum Entscheiden begleiten: KI übernimmt Routinen, Menschen übernehmen Urteilsvermögen. Kein Widerstand durch Überraschung.

Die größte Hürde bei KI-Einführung ist nicht die Technologie, sondern die Veränderung des Selbstverständnisses: wer heute Berichte zusammenstellt, prüft morgen KI-generierte Entwürfe. Das ist eine andere Tätigkeit, die andere Kompetenz verlangt. Change-Begleitung bedeutet: Rollen explizit machen (was tut die KI, was tut der Mensch), neue Kompetenz aufbauen (wie erkenne ich guten KI-Output, wie korrigiere ich ihn) und Vertrauen herstellen (durch nachvollziehbare Ausgaben mit Provenance).

Coaching ist keine einmalige Schulung — es ist ein laufender Prozess je Use Case. Vor dem ersten produktiven Lauf eines Use Cases erhält die HITL-Person eine geführte Einführung: was kann dieser Use Case, was sind seine bekannten Grenzen, wie ist das HITL-Gate gestaltet. Feedback aus dem Coaching fließt in GOV-4 (Leitplanken-Aktualisierung) zurück.

In I2 startet das Change-Programm mit den HITL-Rollen für UC-2 und UC-3. In I3 wird es auf alle produktiven Use Cases ausgedehnt. Das Programm ist dokumentiert und wiederholbar — nicht von einer einzelnen Person abhängig.

Top-3 Fragestellungen

1. Welche Rollen im Projekt haben die größte Veränderungslast durch KI-Einführung — und bei welchen ist der Veränderungswiderstand am wahrscheinlichsten?
2. Gibt es bestehende Change-Management-Ressourcen im Konzern (HR, L&D), die das Coaching-Programm unterstützen können?
3. Wie wird der Erfolg des Change-Programms gemessen — gibt es eine Kennzahl (HITL-Annahme-Rate, Use-Case-Nutzungsfrequenz), die Akzeptanz abbildet?

Management-Transparenz: was darf / was nicht

Permanente, automatisierte Sicht auf aktive Leitplanken und Erlaubnisse — für das Management, nicht nur für das Projektteam.

Management-Transparenz bedeutet, dass die Führungsebene jederzeit wissen kann, was die KI-Systeme dürfen und was nicht — ohne das Projektteam fragen zu müssen. Das ist kein Vertrauens-Proxy, sondern ein technischer Nachweis: aktive Leitplanken als maschinenlesbares Dokument, zuletzt geändert wann und von wem, mit welcher Begründung.

Das Leitplanken-Dokument aus GOV-1 wird zur Grundlage einer automatisierten Management-Ansicht: ein kompaktes Übersichtsdokument (HTML oder PDF), das bei jeder Leitplanken-Änderung neu generiert wird. Inhalt: welche Systeme aktiv sind, was sie dürfen und was nicht, welche HITL-Rollen existieren, wer Zugriff auf den Audit-Log hat.

In I3 wird die erste Version der Management-Ansicht generiert und dem Lenkungsausschuss vorgelegt. Sie ist ab dann ein fester Bestandteil des Iterations-Statusberichts.

Top-3 Fragestellungen

1. Welche Informationen will das Management sehen — und welche sind zu detailliert für die Führungsebene und gehören in den Detailbericht?
2. Wie oft soll die Management-Ansicht aktualisiert werden — bei jeder Leitplanken-Änderung (event-getrieben) oder im Iterations-Rhythmus?
3. Gibt es einen Prozess, mit dem das Management Leitplanken kommentieren oder nachschärfen kann, ohne tief in den Projektalltag einzugreifen?

Treibende Kräfte & Rollen — Governance-Betriebsmodell

Wer treibt, betreibt und verantwortet die KI-Governance nach Projektende. Verantwortung an Wirkungsfäden, nicht an Orgchart-Position.

Governance endet nicht mit dem Projekt. Nach I7 muss eine Struktur existieren, die Leitplanken aktuell hält, neue Use Cases bewertet, Compliance-Änderungen aufnimmt und das HITL-Qualitätsniveau sichert. Dieses Paket definiert das Betriebsmodell: welche Rollen welche Governance-Aufgaben übernehmen, in welchem Rhythmus, mit welchen Werkzeugen.

Das Modell unterscheidet: treibende Rollen (prüfen Leitplanken auf Aktualität, schlagen Anpassungen vor), betreibende Rollen (stellen den technischen Betrieb der Leitplanken-Erzwingung sicher) und verantwortende Rollen (entscheiden über Leitplanken-Änderungen, sind benachrichtigt bei Verstößen). Eine Rolle kann mehrere Funktion haben — aber jede Funktion braucht genau eine verantwortliche Person.

In I3 wird das Betriebsmodell dokumentiert und den identifizierten Personen zur Bestätigung vorgelegt. Es ist Gate für die Projektübergabe in I7: kein Abschluss ohne bestätigtes Betriebsmodell.

Top-3 Fragestellungen

1. Welche bestehenden Gremien im Konzern (IT-Sicherheitsausschuss, Datenschutz-Steuerkreis) könnten Governance-Funktionen für KI integrieren, statt neue Strukturen aufzubauen?
2. Wer übernimmt die Rolle der „treibenden Kraft" nach I7 — und hat diese Person heute schon das Mandat und die Kompetenz dafür?
3. Wie oft muss das Governance-Betriebsmodell selbst überprüft werden — gibt es einen Rhythmus, oder nur bei Anlass (neuer Use Case, Gesetzes-Update)?

Reifegrad- & KPI-System für Governance

Platzhalter — Systematisches Messen des Governance-Reifegrads und der KPI-Erfüllung über die Iterationen.

Dieses Paket ist ein Platzhalter. Scope wird in I4 nach GOV-4 und GOV-5 definiert.

Geplanter Scope: Reifegrad-Skala für Governance (1–5) je Dimension (Leitplanken-Qualität, HITL-Abdeckung, Transparenz, Compliance-Erfüllungsgrad); KPI-Tracking über Iterationen; automatisch generierter Reifegrad-Report je Iteration.

Platzhalter bis I4.

Top-3 Fragestellungen

1. Welche Governance-Dimensionen sind für diese Organisation am wichtigsten zu messen, und gibt es bereits einen Reifegrad-Standard (z. B. AI Governance Maturity Model), an dem gemessen wird?
2. Wer schaut auf den Reifegrad-Report und entscheidet auf dessen Basis, welche Governance-Lücken priorisiert geschlossen werden?
3. Wie werden KPI-Abweichungen eskaliert — gibt es eine automatische Eskalation bei bestimmten Schwellen, oder ist das nur Information?

Cockpit / Agenten-OS & Agentenorchestrierung (Ausblick)

Platzhalter — Einheitliches Cockpit für Agenten-Betrieb, Orchestrierung und Leitplanken-Monitoring in I7.

Dieses Paket ist ein Platzhalter. Scope wird in I5–I6 nach Erfahrungen aus INT-4, GOV-4, GOV-5 definiert.

Geplanter Scope: Ein zentrales Cockpit, das Agenten-Betrieb (läuft, gestoppt, Fehler), Ressourcen (Token, Kosten), Leitplanken-Status (aktiv, verletzt, aktuell) und Management-Sicht (GOV-4) in einer Ansicht vereint. Nicht gebaut auf einem einzigen Dashboard-Werkzeug, sondern als Schicht über offenen Daten.

Platzhalter bis I5.

Top-3 Fragestellungen

1. Welche Informationen aus dem laufenden Betrieb werden heute von wem händisch zusammengestellt, die ein Cockpit automatisieren könnte?
2. Gibt es ein bestehendes Monitoring-Werkzeug im Konzern, das als Ausgangspunkt für das Cockpit dienen kann?
3. Wie wird das Cockpit gepflegt, wenn das Vorhaben endet — ist die Pflege in das Governance-Betriebsmodell (GOV-5) eingebettet?

Workshop: Startpunkt schärfen

Den Startpunkt gemeinsam modellieren. Offene Klärungen schließen, um die nächsten Iterationen zu schärfen. Querfeldein, ein Durchgang.

Blöcke (Reihenfolge fix, Zeiten offen)

Ergebnis

Ein geschärfter Startpunkt, ein paar entschiedene Use Cases, klare offene Punkte mit Verantwortlichen — als Kontext für die nächste Iteration des Projektplans.

Arbeitspakete & Plan

Iterations-Gantt über sechs Ströme: CTX · INF · INT · CMP · UC · GOV. Kritischer Pfad (CPM) automatisch berechnet. Hover/Touch für Details. Zoom nur Cmd/Ctrl+Scroll.

Arbeitspaket-Übersicht

Projektstrukturplan — 4 Varianten

Vier PSP-Varianten derselben Projektarbeit, unterschiedlich gegliedert. Blätter referenzieren AP-IDs aus den sechs Strömen.

Variante & Baum

Iterations-Historie

Wie sich der Plan über die Dokument-Versionen verändert hat — welche Elemente präziser wurden, welche neu hinzukamen, was sich strukturell geändert hat.