Freigegebene AI betreiben

Begriffe vor dem Lesen

• Shadow KI — Nutzung außerhalb governter Pfade: öffentlicher Chat, persönlicher Key, unsanktionierter Plugin, Dienstleister-POC mit Live-CSV.
• freigegebenen KI-Nutzungspfad — freigegebener Weg mit Modell/Provider, Zweck, Datenklassen, Owner, Steward, Logging, Ausstieg-Kriterien.
• Shadow-Register — Inventar vor dem Verbot: Tools, Uploads, Keys, Plugins, verantwortliche Person, Status shadow | candidate | sanctioned.
• Datenschutzvertrag — AV-Vertrag, bevor personenbezogene Daten in Dienstleister-KI gehen. Ein Trust-Center-Link ist keine Datenschutzvertrag.
• Tenant Kontrollregeln — Admin-Einstellungen, die Prompts, Daten und Trainingsflags im Enterprise-Tenant halten.
• Nutzungsrichtlinie — Acceptable Use für Mitarbeitende — folgt dem Path-Katalog, erfindet ihn nicht neu.

Produkte und Entscheidungen

Sanctioned AI braucht nicht „eine Tool-Liste“, sondern geschnittene Produkte.

Shadow-AI-Register

Dieses Produkt beschreibt:

• Tool-/Endpoint-ID; Dienstleister; Deployment (public / private / on-prem); berührte Datenklassen; Upload verlässt Tenant ja/nein; verantwortliche Person; Status shadow | candidate | sanctioned; Reviewdatum.

Entscheidungen:

• Was wird zuerst inventarisiert — Chat, Keys, Plugins, POCs?; Wer darf Status heben — Path-verantwortliche Person plus Privacy/Security?; Welche „wir verbieten KI“-Richtlinie ohne Register gilt als Lücke?

freigegebenen KI-Nutzungspfad Catalog (sanctioned-paths-v1)

Produktionsfähig nur mit Zweck.

Es benötigt:

• Modell/Provider; erlaubte Zwecke und Nicht-Ziele; Datenklassen und Residency; verantwortliche Person; Steward; Logging; Aufbewahrungsfrist; Auskunfts- und Löschrechte-Kontakt; Ausstieg-Kriterien.

Entscheidungen:

• Welche fünf Pfade sind kritisch genug für v1?; Wer ist Path-verantwortliche Person, nicht nur Tenant-Admin?; Welche leere Zeile blockt Produktion, statt „Strategie“ zu heißen?

Zweck- und Datenklassen-Bindung

Nicht nach Vendor-Marke.

Entscheidungen:

• Welche Klasse darf welchen Path berühren?; Welche Exports sind standardmäßig verboten im öffentlichen Chat?; Wer friert neue Shadow-Pfade im Pilot ein?

DPA- und Tenant-Hinweis

Dieser Teil besitzt Inventar und Katalog; Vertragstiefe folgt in Workplace- und Act-Teilen.

Entscheidungen:

• Welcher Path darf ohne Datenschutzvertrag keine personenbezogenen Daten sehen?; Welche Funde gehen an Workplace-Nutzungsrichtlinie, statt hier ein zweites Inventar zu öffnen?

Wo Governance hängt

Zwischen Strategiefolie und unbekanntem Pfad

„Wir haben AI“ ohne Register beantwortet nicht, welche Pfade Kundendaten berühren.

Zwischen PDF-Verbot und öffentlichem Chat

Die Policy kommt nach dem Paste. Inventar schlägt Slogan.

Zwischen persönlichem API-Key und Tenant-Log

Notebook-Keys umgehen CASB-Erwartungen. Sie brauchen eine Register-Zeile.

Zwischen Zwei-Wochen-POC und Fine-Tune-Endpoint

Customer-CSV im POC ist Produktion ohne Katalog. Zeitdruck ist kein Waiver.

Zwischen BI-Plugin und fehlendem Data-Scope

Embedded Assistenten sind Pfade. Ohne Scope sind sie Shadow in der App.

Zwischen Tool-Admin und verantwortliche Person des Nutzungspfads

Wer SSO setzt, entscheidet nicht Zweck, Datenklasse oder Exit.

Rollen-Mapping

verantwortliche Person des Nutzungspfads (Business / Process)

Fach-Lead ist accountable für Zweck und die Entscheidung, den Path produktiv zu nutzen. Der Owner entscheidet nicht die DPA-Klausel allein.

Privacy / DPO

Bewertet Datenklassen und DSDR-Kontakt. Privacy ersetzt nicht den verantwortliche Person des Nutzungspfads für die Nutzung.

Security / Steward

Führt Register, Katalog, Freeze im Pilot und Wiedervorlage. Stewardship braucht Kapazität, nicht die Restzeit zwischen Leak und Audit.

Platform / Tenant Custodian

Setzt Tenant-Controls und Logging um. Konfigurationsmacht ist keine Path-Verantwortung.

AI Product Owner

Priorisiert welche Pfade candidate werden. Nutzen und Lieferbarkeit — nicht die Risikoklasse (Teil 2).

Audit / Assurance Nutzende

Empfängt Katalog und Top-Shadow-Findings. Sie erfinden keine parallele Tool-Tabelle.

Mini-Fall

Alltagssituation: Eine Quartalsprognose wird in einen öffentlichen Chat kopiert. Die Richtlinie sagt nur „keine personenbezogenen Daten“, aber es gibt kein Inventar der genutzten Inhalte. Niemand kann sicher beantworten, ob Auskunfts- oder Löschrechte betroffener Personen erfüllt werden können. Trotzdem spricht der Vorstand von „KI-Strategie“.

Was schiefläuft: Das Unternehmen verwechselt Tool-Freigabe mit Nutzungsweg. Ein Tool kann technisch erlaubt sein und trotzdem für diese Datenklasse, diesen Zweck oder diesen Verantwortungsbereich falsch sein.

Vereinbarung: Bekannte Tools kommen ins Shadow-Register. Erlaubte Nutzungspfade werden mit Zweck, Datenklasse, verantwortlicher Person und Status benannt. Neue Schattenpfade werden im Pilot eingefroren, das wichtigste Finding wird geschlossen oder bewusst freigegeben, und die Nutzungsrichtlinie verweist auf den Pfadkatalog.

Kritische Übergaben

Anti-Patterns

• KI verbieten, ohne zu inventarisieren
• Dienstleister-Marke mit freigegebenen KI-Nutzungspfad gleichsetzen
• Persönliche Keys als Developer-Präferenz führen
• POCs mit Live-CSV still laufen lassen
• Path-Katalog leer lassen und Nutzungsrichtlinie trotzdem publishen
• Tenant-Admin als Path-verantwortliche Person führen
• Foundations oder Junk-Serie hier umschreiben

Umsetzung im Alltag

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Freigegebene KI betreiben
• Lernpfad — Freigegebene KI betreiben

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Schritt 1: Rahmen und Entscheidung klären

Bekannte AI-Tools einer Domain listen (öffentlich, SaaS, embedded, Notebook, POC). Datenklassen grob markieren. verantwortliche Person des Nutzungspfads und Privacy/Security benennen.

Schritt 2: Control und Nachweis umsetzen

sanctioned-paths-v1 für fünf kritische Pfade veröffentlichen. Top-Shadow-Finding schließen oder waiven. Neue Shadow-Pfade im Pilot frieren.

Schritt 3: Testen und Ausnahmen sichtbar machen

Leadership-Test: welche Pfade dürfen heute Kundendaten berühren? Negativtest: öffentlicher Chat mit Export bleibt shadow. Act-Ops (Teil 2) und Workplace-AUP anschließen.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster auf eine zweite BU übertragen.

Exit-Kriterien

• Shadow-Register und Path-Katalog existieren für den Pilot — nicht nur eine Verbots-PDF.
• Jeder freigegebenen KI-Nutzungspfad hat Zweck, Datenklassen, Owner und Logging-Hinweis.
• Öffentlicher Chat mit Exports ist shadow oder befristet gewaived.
• Leadership kann benennen, welche Pfade Kundendaten berühren dürfen.
• technischer Betreiber liefert Endpoint-Nachweis; Path-verantwortliche Person bleibt für die Nutzung accountable.

Weiterlesen

• KI Governance
• GDPR für Analytics- und KI-Teams
• EU-Regulierung: KI Act…
• Datenmüll vor KI
• Mails & Dokumente vor KI
• Workplace KI Governance

Ausgangslage

Programme stecken zwischen Extremen fest:

• Legal liest den Act; Delivery shippt Chatbots ohne Klasse auf der Path Card;
• „high-risk“ wird monatelang debattiert, während Shadow-Tools weiterlaufen;
• Dokumentation existiert als One-off-PDFs, nicht als lebende Artefakte am Pfad;
• Rollen verschwimmen: wer besitzt Risikoklasse vs. Model Change vs. Data Purpose?;
• Auditoren fragen Nachweispakets; Teams liefern Screenshots.

Regulatorischer Überblick bleibt in EU-Regulierung: AI Act, Data Act, NIS2 und DORA und AI Governance. Hier geht es um wie die Organisation läuft, nachdem Teil 1 den Katalog hat.

So sieht der Bruch aus (Ist-Zustand):

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Pfad:      „Customer Support Assistant“ — sanctioned
Klasse:    leer
Owner:     „AI-Team“
Nachweise:  Kickoff-Deck aus Q1
Incident:  falscher Rat an Kunden — kein Post-Market-Log
Legal:     „wir beobachten den Act“

Beobachten ohne Klasse und Cadence ist keine Compliance.

Begriffe vor dem Lesen

• Data Owner — Fachlich verantwortliche Rolle für Zweck, Bedeutung, Risikoakzeptanz und Freigabe.

• Data Steward — Rolle, die Definitionen, Prüfungen, Konflikte und Nachweise im Alltag pflegt.

• Data Custodian — Technische Rolle, die Zugriffe, Laufzeit, Sperren und Protokollierung umsetzt.

• Freigegebener KI-Nutzungspfad — Eine konkrete Kombination aus Zweck, Werkzeug, Datenklassen, verantwortlichen Rollen und technischen Kontrollen.

• RAG (Retrieval-Augmented Generation) — Das System sucht vor einer Antwort freigegebene Quellen und stellt sie dem Sprachmodell als Kontext bereit.

• HITL (Human in the Loop) — Eine benannte Person prüft oder genehmigt eine Aktion, bevor sie wirksam wird.

• Waiver / befristete Ausnahme — Zeitlich begrenzte Abweichung mit Grund, Risiko, kompensierender Maßnahme und Ablaufdatum.

• Model Card / Dataset Card — Versionierte Beschreibung von Modell beziehungsweise Datensatz, zulässiger Nutzung, Herkunft, Tests und Grenzen.

• Corpus — Die kontrollierte Sammlung von Dokumenten oder Daten, aus der ein KI-System sucht oder lernt.

Entscheidung

Binden Sie jeden freigegebenen KI-Nutzungspfad an eine AI-Risikoklasse, benannte Rollen und eine Prüfrhythmus für Nachweise.

Risikoklasse am Pfad (Minimum)

Arbeitsklasse je Pfad vergeben (Mapping auf Act-Anhänge später mit Legal):

Regeln:

1. Keine Klasse, kein Go-Live für neue freigegebene KI-Nutzungspfade (Sandbox darf candidate mit Ablauf).
2. Klasse hat Owner — Product Owner schlägt vor; Risk/Compliance bestätigt; Steward hält Register aktuell.
3. Wechsel von Modell, Datenzweck oder Tools löst Re-Class-Review aus.
4. Ehrliche Sprache: dieses Operating Model unterstützt Act-Readiness; es ist keine Rechtsberatung — Legal besitzt die Auslegung.

Rollen (RACI lite)

Prüfrhythmus für Nachweise

Mindestens lebende Artefakte (Link Teile 3–8):

• Path Card + Risikoklasse (dieser Teil);
• Model- und Dataset-Cards (Teil 3);
• Eval-Release-Prüfpunkt-Results (Teil 6);
• menschliche Freigabe / Tool-Freigabeliste wo Agenten handeln (Teil 7);
• Cost/Capacity und Shadow-Findings auf der Betriebsübersicht (Teil 8);
• Post-Market: Incident-Log, Beschwerdekanal, Neubewertung nach materialem Change.

Cadence-Beispiel: monatliches Register-Review für limited/high; quartalsweise für minimal; sofort bei materialem Change.

Checkliste

Operationalisieren Sie Act-Readiness für die Pilot-Pfade:

• Risikoklasse-Feld in sanctioned-paths-v1 ergänzen;
• Klasse + Begründung für jeden Pfad mit Kunden- oder Entscheidungswirkung füllen;
• Accountable-Rollen laut Tabelle benennen;
• Nachweis-Cadence und Ablageort setzen (ticket-zentriert, zugriffsbeschränkt);
• Legal-Fragen zur EU-Regulations-Story routen — keine Annex-Auslegung hier erfinden;
• Produktivstart blocken, wenn Klasse oder verantwortlichen Person leer;
• stoppen, wenn ein limited- oder high-Pfad Klasse, Rollen und datierte Nachweis-Checkliste hat.

Artefakt

AI Risk Class Register + Prüfrhythmus für Nachweise Sheet:

• Pfad-ID, Arbeitsklasse, Act-Mapping-Note (Legal-owned);
• Zweck, Grundgesamtheit, Entscheidungswirkung;
• accountable / responsible / consulted;
• Pflichtartefakt-Liste und last/next Due Dates;
• Material-Change-Trigger;
• Link zu Cards, Eval Packs, Incident-Log.

Tools

Risk- und Compliance-Register für Klasse. Katalog für Path-Felder. Model-Registry-Hooks (Teil 3). Lernpfad Compliance Essentials falls vorhanden.

Ressourcen

EU-Regulierung: AI Act…, AI Governance, GDPR für Analytics- und AI-Teams, Teil 1 dieser Serie, AI Eval.

Tools und Quellen

Modell- und Datensatzbeschreibungen helfen nur, wenn sie zur tatsächlich eingesetzten Version gehören und vor der Produktivsetzung geprüft werden. Diese Story zeigt, wie zulässige Nutzung, Herkunft, Testergebnisse und bekannte Grenzen direkt mit dem technischen Register verbunden werden.

Begriffe vor dem Lesen

• Data Owner — Fachlich verantwortliche Rolle für Zweck, Bedeutung, Risikoakzeptanz und Freigabe.

• Data Steward — Rolle, die Definitionen, Prüfungen, Konflikte und Nachweise im Alltag pflegt.

• Data Custodian — Technische Rolle, die Zugriffe, Laufzeit, Sperren und Protokollierung umsetzt.

• Freigegebener KI-Nutzungspfad — Eine konkrete Kombination aus Zweck, Werkzeug, Datenklassen, verantwortlichen Rollen und technischen Kontrollen.

• RAG (Retrieval-Augmented Generation) — Das System sucht vor einer Antwort freigegebene Quellen und stellt sie dem Sprachmodell als Kontext bereit.

• HITL (Human in the Loop) — Eine benannte Person prüft oder genehmigt eine Aktion, bevor sie wirksam wird.

• Waiver / befristete Ausnahme — Zeitlich begrenzte Abweichung mit Grund, Risiko, kompensierender Maßnahme und Ablaufdatum.

• Model Card / Dataset Card — Versionierte Beschreibung von Modell beziehungsweise Datensatz, zulässiger Nutzung, Herkunft, Tests und Grenzen.

• Corpus — Die kontrollierte Sammlung von Dokumenten oder Daten, aus der ein KI-System sucht oder lernt.

Entscheidung

Bevor eine Version einen freigegebenen KI-Nutzungspfad bedienen darf:

1. eine Minimum Model Card (Model-/Versions-ID, Intended Use und Nicht-Ziele, Training/Base-Lineage, Eval-Summary-Link aus Teil 6, Risikoklasse, Owner, Known Limitations, Rollback-Version);
2. eine Minimum Dataset Card (Corpus-/Snapshot-ID, Zweck retrieval / training / eval, Quellen, Sensitivität, Hygiene-/AI-Gate-Status, License/Rechte, Steward, Refresh/Rebuild-Trigger);
3. ein Registry-Gate: Promote nur bei vollständigen Cards (limited/high Hard Fail; minimal Warn mit Ablauf);
4. einen Owner für Semantik und Risiko, einen Steward für Vollständigkeit, einen Custodian für Registry-Durchsetzung;
5. einen Ausnahmeweg mit Freigeber und Ablauf — nie stilles Promote ohne Card.

Metadata-Prep allein blockt nicht — Metadaten für AI…. Das Gate sitzt an der Registry.

Card-Workflow

1. Cards an Versions-IDs binden

Der Owner legt fest, welche Model-Version und welcher Corpus-Snapshot den Path bedienen. Der Steward schreibt beide IDs in die Cards; der Custodian verankert sie in Registry und Vector-Admin. Eine immergrüne Folie ohne Versions-ID ist kein Nachweis — der nächste Fine-Tune überschreibt sie still.

2. Mindestfelder füllen

Model Card nennt Use, Nicht-Ziele, Lineage, Eval-Link, Risiko, Limits und Rollback. Dataset Card nennt Zweck, Quellen, Sensitivität, Hygiene-Status und Rebuild-Trigger. Fehlt ein Feld, darf limited/high nicht promoten. Ohne Nicht-Ziele wird derselbe Corpus später für Training missbraucht.

3. Registry-Gate verdrahten

Der Custodian hängt die Templates an Promote-Jobs. limited/high hard-failen bei Lücken; minimal warnt mit Ablaufdatum. Ein Gate, das nur warnt und nie blockt, ist Dekoration — stoppen, wenn ein Promote wegen fehlender Cards fällt und einer mit IDs durchgeht.

4. Live-Pfade nachziehen

Der Steward ergänzt nachträglich Cards für bereits live freigegebene KI-Nutzungspfade und hängt sie an die Prüfrhythmus für Nachweise aus Teil 2. Ohne Nachzug bleibt Produktion das Schlupfloch: neue Versionen haben Cards, der laufende Bot nicht.

5. Review bei Wechsel

Owner bestätigt Risiko erneut bei Use-Erweiterung oder Corpus-Delta. Steward triggert Review bei Embedding-Wechsel, Re-Index oder Incident. Custodian prüft, dass Pack-ID und Versions-Pin noch zusammenpassen. Eine Card nach Go-Live optional machen heißt, den nächsten Rollback ohne Nachweise zu fahren.

Handoffs

Anti-Patterns

• Cards als optionales PDF nach Produktivstart ablegen
• Produktion-Endpoint auf unbenannten Fine-Tune zeigen
• Retrieval-Dokumentbestand ohne Dataset Card indexieren
• Eine immergrüne Card für alle Versionen führen
• Metadata-Prep haben, aber Promote nie blocken

Erster Praxistest

Nehmt einen realen, begrenzten Nutzungspfad. Führt die folgenden Schritte mit den tatsächlich verantwortlichen Rollen und Systemen aus. Der Test ist erst abgeschlossen, wenn Entscheidung, technische Wirkung und Nachweis zusammenpassen.

1. Feld-Templates für Model- und Dataset-Card festlegen und an einen Registry-Promote hängen.
2. Cards für einen live freigegebenen KI-Nutzungspfad nachziehen (IDs, Zweck, Rollback).
3. Ein Promote mit fehlender Card blocken und den Fail als Nachweise speichern.
4. Review-Trigger an Prüfrhythmus für Nachweise aus Teil 2 koppeln.

Synthetische Daten sind kein Freifahrtschein für KI-Tests und Testumgebungen. Sie können sensible Muster übernehmen, Bewertungen verfälschen oder später unbemerkt in produktive Trainingsdaten gelangen. Deshalb braucht jeder Datensatz einen klaren Zweck, überprüfte Risiken und eine technische Sperre gegen nicht freigegebene Nutzung.

Begriffe vor dem Lesen

• Data Owner — Fachlich verantwortliche Rolle für Zweck, Bedeutung, Risikoakzeptanz und Freigabe.

• Data Steward — Rolle, die Definitionen, Prüfungen, Konflikte und Nachweise im Alltag pflegt.

• Data Custodian — Technische Rolle, die Zugriffe, Laufzeit, Sperren und Protokollierung umsetzt.

• Freigegebener KI-Nutzungspfad — Eine konkrete Kombination aus Zweck, Werkzeug, Datenklassen, verantwortlichen Rollen und technischen Kontrollen.

• RAG (Retrieval-Augmented Generation) — Das System sucht vor einer Antwort freigegebene Quellen und stellt sie dem Sprachmodell als Kontext bereit.

• HITL (Human in the Loop) — Eine benannte Person prüft oder genehmigt eine Aktion, bevor sie wirksam wird.

• Waiver / befristete Ausnahme — Zeitlich begrenzte Abweichung mit Grund, Risiko, kompensierender Maßnahme und Ablaufdatum.

• Model Card / Dataset Card — Versionierte Beschreibung von Modell beziehungsweise Datensatz, zulässiger Nutzung, Herkunft, Tests und Grenzen.

• Corpus — Die kontrollierte Sammlung von Dokumenten oder Daten, aus der ein KI-System sucht oder lernt.

Entscheidung

Bevor ein synthetisches Set Training, Eval oder Nichtproduktionsumgebung-AI-Pfade speist:

1. eine Synthetic Data Zweckkarte je Set (train / eval / nonprod-ui) mit Generator-Methode, Seed-Policy und Nicht-Zielen;
2. ein Promote-Verbot synthetic→Prod-Corpus — kein stilles Mischen in den Policy-Index;
3. Leakage- und Utility-Checks plus Re-Identifikationsnote mit Privacy;
4. Masking plus Subset statt Synthetic, wenn Prod-Bugs reproduziert werden müssen;
5. Owner für Zweck, Steward für Card und Checks, Custodian für Ingest-Block; Junk→AI-Scrub wenn Synthetic auf reale Quellen trifft.

Nebenkopien bleiben im Deletion-Scope — Nichtproduktionsumgebung, Exports….

Synthetic-Workflow

1. Sets inventarisieren

Der Steward listet jedes synthetische Set, das einen AI-Pfad berührt — inkl. Generator-Exports und „temporärer“ Nichtproduktionsumgebung-Refreshes. Der Owner bestätigt den Zweck. Ohne Inventar landet ein uncarded Set im Trainingslauf, und niemand kann DSDR beantworten.

2. Zweckkarte ausstellen

Eine Card pro Zweck: train, eval oder nonprod-ui. Generator, Seed-Policy und Nicht-Ziele gehören auf die Card, nicht ins Ticket. Custodian blockt Ingest ohne Card-ID. Eine Card für alle drei Zwecke ist dasselbe Schlupfloch wie „AI ok“ auf dem Mail-Export.

3. Leakage und Re-ID prüfen

Privacy und Steward fahren Membership-/Overlap-Checks gegen Prod-Stichproben und bewerten Utility ehrlich. Overfittete Generatoren leaken Patterns, auch wenn keine Klarnamen stehen. Ohne Check ist „synthetic = anonym“ eine Behauptung — PII vor AI-Ingestion stoppen.

4. Promote und Mischung sperren

Custodian verbietet stilles Promote in den Prod-Corpus. Eval-Golden-Sets labeln synthetisch vs. Prod; ungelabelte Mischung macht Retrieval-Metriken aus Teil 6 wertlos. Wer Prod-Bugs braucht, nimmt Masking plus Subset, nicht einen Generator, der die Verteilung glättet.

5. Nebenkopien und Refresh binden

Owner hängt Refresh und Restore an Re-Scan. Steward legt die Card neben Dataset Cards aus Teil 3. Custodian nimmt Synthetic-Kopien in den Deletion-Scope. Wer Synthetic aus dem Scope lässt, erzählt DSDR eine Lüge.

Handoffs

Anti-Patterns

• Nicht-Produktion mit Raw-Produktion „vorübergehend“ befüllen
• Synthetic als automatisch anonym und frei nutzbar behandeln
• Eval-Golden-Sets aus synthetisch und Produktion ohne Labels mischen
• Generator-Output still in den Produktion-Dokumentbestand promoten
• Masking überspringen, obwohl ein Produktion-Bug reproduziert werden muss

Erster Praxistest

Nehmt einen realen, begrenzten Nutzungspfad. Führt die folgenden Schritte mit den tatsächlich verantwortlichen Rollen und Systemen aus. Der Test ist erst abgeschlossen, wenn Entscheidung, technische Wirkung und Nachweis zusammenpassen.

1. Alle synthetischen Sets an AI-Pfaden inventarisieren und je eine Zweckkarte schreiben.
2. Leakage- und Re-ID-Check mit Privacy für ein Train- oder Eval-Set fahren.
3. Einen uncarded Set vom Train-Ingest blocken und den Fail protokollieren.
4. Promote-Verbot synthetic→Prod im Custodian-Job verdrahten.

Tools und Quellen

Junk im Policy-Bot-Corpus (SharePoint Policies) ist versehentlicher Ballast. Poisoning ist feindliche oder fahrlässige Kontamination — prompt-injizierte Docs, getarnte Anhänge, fahrlässige Uploads — bevor der Policy-Bot abruft oder trainiert.

Begriffe vor dem Lesen

• Data Owner — Fachlich verantwortliche Rolle für Zweck, Bedeutung, Risikoakzeptanz und Freigabe.

• Data Steward — Rolle, die Definitionen, Prüfungen, Konflikte und Nachweise im Alltag pflegt.

• Data Custodian — Technische Rolle, die Zugriffe, Laufzeit, Sperren und Protokollierung umsetzt.

• Freigegebener KI-Nutzungspfad — Eine konkrete Kombination aus Zweck, Werkzeug, Datenklassen, verantwortlichen Rollen und technischen Kontrollen.

• RAG (Retrieval-Augmented Generation) — Das System sucht vor einer Antwort freigegebene Quellen und stellt sie dem Sprachmodell als Kontext bereit.

• HITL (Human in the Loop) — Eine benannte Person prüft oder genehmigt eine Aktion, bevor sie wirksam wird.

• Waiver / befristete Ausnahme — Zeitlich begrenzte Abweichung mit Grund, Risiko, kompensierender Maßnahme und Ablaufdatum.

• Model Card / Dataset Card — Versionierte Beschreibung von Modell beziehungsweise Datensatz, zulässiger Nutzung, Herkunft, Tests und Grenzen.

• Corpus — Die kontrollierte Sammlung von Dokumenten oder Daten, aus der ein KI-System sucht oder lernt.

Entscheidung

Bevor eine Quelle den sanctioned Corpus speist:

1. eine Corpus Provenance / Supplier Trust Matrix mit Tier owned (intern führend), contracted (Vendor mit Delete/Attest), open-crawl (hohe Prüfung / nur Sandbox), unknown (blocked);
2. Integrity-Gates: Content-Hashes, signierte Manifeste wo möglich, Change-Alerts auf Source-URLs;
3. Trennung untrusted Retrieval von System-Prompts — AI Failures;
4. Owner für Corpus-Freigabe, Steward für Tier-Triage, Custodian für Ingest-Block und Hash-Store;
5. einen Response-Pfad bei Taint (Quarantäne, Rebuild, Unlearning-Link) — Remediation für PII existiert bereits in Machine Unlearning….

Junk-Disposition bleibt Nachbar: Aufräumen vor Retrieve oder Train.

Provenance-Workflow

1. Quellen tiern

Der Owner beschließt, welche Quelle den Prod-Corpus speisen darf. Der Steward ordnet jede Zeile einem Trust-Tier zu — SharePoint Policies, Vendor-Knowledge-Pack, Web-Crawl, unbekannter Upload. unknown ist blocked, nicht „später klassifizieren“. Ohne Tier ist jede Quelle gleich vertrauenswürdig.

2. Integrity prüfen

Custodian verlangt Content-Hash und, bei contracted, Vendor-Attest oder signiertes Manifest. Change-Alerts auf Source-URLs lösen Steward-Triage aus. Ein Pack ohne Hash ist ein blinder Import — Poisoning wird erst in der Antwort sichtbar.

3. Untrusted isolieren

open-crawl bleibt sandboxed und getrennt vom System-Prompt. Owner verbietet, untrusted Chunks als Policy-Grounding zu zitieren. Wer Crawl und interne Records mischt, macht Prompt-Injection zum Retrieval-Default.

4. Ingest durch eine verbindliche Prüfung absichern

Custodian blockt unknown und lässt owned/contracted nur mit gültigem Hash durch. Steward verknüpft tote oder tainted Quellen mit Junk→AI-Disposition. Ein Gate, das nur das Wiki aktualisiert, stoppt keinen Crawl-Job.

5. Taint-Response üben

Owner und Steward tabletoppen eine tainted Source: Quarantäne, Index-Purge, Card-Update, ggf. Unlearning. Custodian dokumentiert den Response-Pfad. Ohne Tabletop bleibt der Incident ein Slack-Thread — Müll-Assets vergiften den AI-Kontext.

Handoffs

Anti-Patterns

• Web-Crawl ungeprüft in Produktion-KI-Suche kippen
• Dienstleister-Knowledge-Pack ohne Hash oder Delete-Attest akzeptieren
• Insider-Uploads in indexierten Partnerfreigaben ignorieren
• unknown als „candidate“ behandeln statt blocken
• personenbezogene Daten-Remediation haben, aber keinen Supply-Chain-Response-Pfad

Erster Praxistest

Nehmt einen realen, begrenzten Nutzungspfad. Führt die folgenden Schritte mit den tatsächlich verantwortlichen Rollen und Systemen aus. Der Test ist erst abgeschlossen, wenn Entscheidung, technische Wirkung und Nachweis zusammenpassen.

1. Alle Quellen eines RAG-Corpus einem Trust-Tier zuordnen; unknown blocken.
2. Vendor-Attest oder Hash für ein contracted Pack verlangen.
3. open-crawl in die Sandbox legen und vom System-Prompt trennen.
4. Ein Tainted-Source-Tabletop mit dokumentiertem Response-Pfad fahren.

Eine flüssige falsche Antwort des Policy-Bots aus dem falschen Chunk wirkt wie Sprachmodell-Versagen. Oft ist es Retrieval-Versagen: der Index liefert den stillgelegte Policy-Chunk. Ohne getrennte Metriken tunen Teams Prompts ewig und fixen nie den Index.

Begriffe vor dem Lesen

• Data Owner — Fachlich verantwortliche Rolle für Zweck, Bedeutung, Risikoakzeptanz und Freigabe.

• Data Steward — Rolle, die Definitionen, Prüfungen, Konflikte und Nachweise im Alltag pflegt.

• Data Custodian — Technische Rolle, die Zugriffe, Laufzeit, Sperren und Protokollierung umsetzt.

• Freigegebener KI-Nutzungspfad — Eine konkrete Kombination aus Zweck, Werkzeug, Datenklassen, verantwortlichen Rollen und technischen Kontrollen.

• RAG (Retrieval-Augmented Generation) — Das System sucht vor einer Antwort freigegebene Quellen und stellt sie dem Sprachmodell als Kontext bereit.

• HITL (Human in the Loop) — Eine benannte Person prüft oder genehmigt eine Aktion, bevor sie wirksam wird.

• Waiver / befristete Ausnahme — Zeitlich begrenzte Abweichung mit Grund, Risiko, kompensierender Maßnahme und Ablaufdatum.

• Model Card / Dataset Card — Versionierte Beschreibung von Modell beziehungsweise Datensatz, zulässiger Nutzung, Herkunft, Tests und Grenzen.

• Corpus — Die kontrollierte Sammlung von Dokumenten oder Daten, aus der ein KI-System sucht oder lernt.

Entscheidung

Bevor ein Index- oder Prompt-Change einen sanctioned RAG-Pfad erreicht:

1. ein RAG Eval Pack (rag-eval-pack-v1) als Hard Gate für limited/high (Warn für minimal);
2. getrennte Schichten — Retrieval (Recall@k, Filter, Empty-Hit) und Answer (Groundedness, Task Success, Refusal);
3. ein versioniertes Golden Set (Query→Doc-IDs, Sensitivität, Owner = Path-Steward);
4. Cards-Link zu Model/Dataset aus Teil 3 plus Restrisiko-Note;
5. Owner für Schwellen, Steward für Golden Set und Review, Custodian für Pipeline-Block; Waiver nur über Teil 7.

Nie nur auf Answer-Scores promoten, wenn Retrieval-Regression failed.

Eval-Workflow

1. Schichten trennen

Der Eval-Owner setzt Schwellen je Pfad. Der Steward veröffentlicht sie im Pack. Wer nur Answer-BLEU misst, tuned Prompts und lässt den stillgelegte Chunk stehen.

2. Golden Set versionieren

Steward besitzt das Set: 50–200 kritische Intents, Query→erwartete Doc-IDs, Sensitivität gelabelt. Synthetic oder redaktiert bevorzugen — Teil 4. Refresh bei Policy- oder Produktwechsel. Ein Set mit PII oder veralteten Policies ist selbst ein Incident.

3. Release an Builds hängen

Custodian triggert Eval bei neuem Index-Build, Embedding- oder Chunker-Wechsel, großem Corpus-Delta und Prompt-Change. Require: Retrieval-Pass + Answer-Pass + Cards-Link. Ohne Hook shippt der Hygiene-Re-Index auf Slack-Daumen — und Woche+1 zitiert der Bot die stillgelegte Policy.

4. Fails zurück verdrahten

Retrieval-Misses durch tote oder tainted Docs gehen an Junk→AI oder Teil 5, nicht an Prompt-Tuning. Steward dokumentiert den Fix im Pack. Ein Fail ohne Owner wird zum Dauer-Waiver.

5. Pack speichern

Custodian legt Pack-ID, Index/Build-ID, Golden-Set-Hash, Metriken, Pass/Fail/Waive und Reviewer ab. Owner bestätigt Restrisiko. Ohne gespeicherte ID ist der letzte Produktion-Change nicht auditierbar.

Handoffs

Anti-Patterns

• Online-Demo oder Slack-Daumen als Regression behandeln
• Nur Answer-Scores messen, Hit-Rate@k ignorieren
• Re-Index nach Hygiene ohne Eval-Prüfpunkt produktiv ausliefern
• Golden Sets mit personenbezogene Daten oder veralteten Richtlinien fahren
• Eval-Fails still über Slack waiven

Erster Praxistest

Nehmt einen realen, begrenzten Nutzungspfad. Führt die folgenden Schritte mit den tatsächlich verantwortlichen Rollen und Systemen aus. Der Test ist erst abgeschlossen, wenn Entscheidung, technische Wirkung und Nachweis zusammenpassen.

1. Retrieval- und Answer-Schwellen für einen sanctioned RAG-Pfad festlegen.
2. Golden Set v1 mit Owner und Sensitivitäts-Tags publizieren.
3. Index/Promote an Eval-Jobs hängen und ein Release bei failed Retrieval blocken.
4. Eval-Pack-ID des letzten Produktion-Change speichern.

Ein KI-Assistent kann nicht nur Texte erzeugen, sondern auch Tickets anlegen, Nachrichten versenden oder Stammdaten ändern. Damit aus einem freigegebenen Assistenten kein unkontrollierter Schreibzugriff wird, braucht jedes Werkzeug einen klaren Zweck, eine begrenzte Wirkung und bei riskanten Aktionen eine menschliche Freigabe. Befristete Ausnahmen bleiben sichtbar und laufen automatisch aus.

Begriffe vor dem Lesen

• Data Owner — Fachlich verantwortliche Rolle für Zweck, Bedeutung, Risikoakzeptanz und Freigabe.

• Data Steward — Rolle, die Definitionen, Prüfungen, Konflikte und Nachweise im Alltag pflegt.

• Data Custodian — Technische Rolle, die Zugriffe, Laufzeit, Sperren und Protokollierung umsetzt.

• Freigegebener KI-Nutzungspfad — Eine konkrete Kombination aus Zweck, Werkzeug, Datenklassen, verantwortlichen Rollen und technischen Kontrollen.

• RAG (Retrieval-Augmented Generation) — Das System sucht vor einer Antwort freigegebene Quellen und stellt sie dem Sprachmodell als Kontext bereit.

• HITL (Human in the Loop) — Eine benannte Person prüft oder genehmigt eine Aktion, bevor sie wirksam wird.

• Waiver / befristete Ausnahme — Zeitlich begrenzte Abweichung mit Grund, Risiko, kompensierender Maßnahme und Ablaufdatum.

• Model Card / Dataset Card — Versionierte Beschreibung von Modell beziehungsweise Datensatz, zulässiger Nutzung, Herkunft, Tests und Grenzen.

• Corpus — Die kontrollierte Sammlung von Dokumenten oder Daten, aus der ein KI-System sucht oder lernt.

Entscheidung

Für jeden agentischen freigegebenen KI-Nutzungspfad publizieren:

1. eine Liste erlaubter Werkzeuge — je Tool: Zweck, Datenklassen, Wirkungsklasse (read / write / money / identity), Owner;
2. eine HITL Matrix — welche Aktionen menschliche Freigabe brauchen je Risikoklasse aus Teil 2;
3. ein AI Waiver Template am Exception-Register: Owner, Rationale, Ablauf, Restrisiko, Compensating Controls; nie permanent für high ohne Risk-Sign-off;
4. standardmäßige Sperre für Tools außerhalb der Freigabeliste; Writes und Identity-Changes brauchen HITL für limited/high;
5. Owner für mögliche Reichweite einer Fehlaktion, Steward für Matrix und Waiver-Triage, Custodian für Gateway-Durchsetzung.

Agent-Design-Tiefe bleibt in AI Agents; Ops hängt hier.

Agent-Workflow

1. Tools inventarisieren

Der Owner listet jedes Tool am Path — Ticket-Create, Mail-Send, CRM-Write, Payment. Steward hängt Zweck, Datenklasse und Wirkungsklasse an. Custodian entfernt alles, was nicht auf der Freigabeliste steht. Ein Demo-„Admin“-Tool, das bleibt, vergrößert die mögliche Reichweite einer Fehlaktion.

2. HITL an Klasse binden

Steward mappt Aktionen auf die Risikoklasse aus Teil 2. Writes, money und identity brauchen menschliche Freigabe für limited/high. Owner bestätigt, wer genehmigt — nicht „das Team“. HITL nur auf der Folie stoppt keinen Ticket-Create.

3. Waivers durchs Register routen

Eval-Fails und fehlende Tools laufen über dasselbe Exception-Register wie Governance-Waivers — Governance Exception und Waiver. Jeder Waiver trägt Ablauf und Compensating Control. Ein stilles Slack-Okay auf Teil-6-Fails ist ein permanenter Schatten-Waiver.

4. Gateway durchsetzen

Custodian verdrahtet Freigabeliste und HITL in Agent-Gateway oder Policy Engine. Nicht freigegebene Werkzeuge bleiben standardmäßig gesperrt. Ein Gateway, das nur loggt, lässt den unsanktionierten Write durch. Stoppen, wenn ein zu breites Tool entfernt und ein befristeter Waiver protokolliert ist.

5. Aging prüfen

Steward prüft Waiver-Ablauf in der Betriebsübersicht aus Teil 8. Owner verlängert nur mit neuem Restrisiko. high ohne Risk-Sign-off wird nie permanent. Aging ignorieren heißt, Teil-6-Gates für immer auszuschalten.

Handoffs

Anti-Patterns

• Breite Admin-Tools für die Demo belassen
• menschliche Freigabe nur als Folie für High-Risk führen
• Eval-Fails unter Slack-Okay produktiv ausliefern
• Teil-6-Gates dauerhaft waiven
• Exception-Register umgehen und KI-Waivers separat pflegen

Erster Praxistest

Nehmt einen realen, begrenzten Nutzungspfad. Führt die folgenden Schritte mit den tatsächlich verantwortlichen Rollen und Systemen aus. Der Test ist erst abgeschlossen, wenn Entscheidung, technische Wirkung und Nachweis zusammenpassen.

1. Tools eines Agent-Pfads inventarisieren und Wirkungsklasse setzen.
2. HITL-Regeln an die Risikoklasse hängen; Writes/money/identity approven lassen.
3. Ein zu breites Tool entfernen und den Deny im Gateway belegen.
4. Einen zeitlich begrenzten Waiver über das Exception-Register protokollieren.

Ein freigegebener KI-Assistent kann fachlich funktionieren und trotzdem unbeherrschbar werden: Kosten steigen, der Suchindex wächst über seinen Zweck hinaus oder niemand kann erklären, welche Quelle eine Antwort beeinflusst hat. Diese Story verbindet Kosten, Kapazität und die Herkunft des verwendeten Kontexts in einer gemeinsamen Betriebsübersicht.

Begriffe vor dem Lesen

• Data Owner — Fachlich verantwortliche Rolle für Zweck, Bedeutung, Risikoakzeptanz und Freigabe.

• Data Steward — Rolle, die Definitionen, Prüfungen, Konflikte und Nachweise im Alltag pflegt.

• Data Custodian — Technische Rolle, die Zugriffe, Laufzeit, Sperren und Protokollierung umsetzt.

• Freigegebener KI-Nutzungspfad — Eine konkrete Kombination aus Zweck, Werkzeug, Datenklassen, verantwortlichen Rollen und technischen Kontrollen.

• RAG (Retrieval-Augmented Generation) — Das System sucht vor einer Antwort freigegebene Quellen und stellt sie dem Sprachmodell als Kontext bereit.

• HITL (Human in the Loop) — Eine benannte Person prüft oder genehmigt eine Aktion, bevor sie wirksam wird.

• Waiver / befristete Ausnahme — Zeitlich begrenzte Abweichung mit Grund, Risiko, kompensierender Maßnahme und Ablaufdatum.

• Model Card / Dataset Card — Versionierte Beschreibung von Modell beziehungsweise Datensatz, zulässiger Nutzung, Herkunft, Tests und Grenzen.

• Corpus — Die kontrollierte Sammlung von Dokumenten oder Daten, aus der ein KI-System sucht oder lernt.

Entscheidung

Bevor der Betrieb als geschlossen gilt:

1. eine AI Operating Betriebsübersicht (ai-ops-scorecard-v1) monatlich — oder wöchentlich in Wellen — je Domain/Pfad-Cluster;
2. Mindest-Indikatoren: Cost je Pfad (Tokens, Embed, Vendor); Index-Größe und Freshness; Eval-Pass-Rate (Teil 6); offene Shadow-Findings (Teil 1); Waiver-Aging (Teil 7); Gate-Fail-Rate (Junk→AI / Teil 5);
3. Context Lineage: Chunk-ID → Snapshot-ID → Source-Asset-ID → Purpose-ID → Path-ID;
4. Kostenverantwortliche Person je freigegebenen KI-Nutzungspfad, Steward für Betriebsübersicht-Triage, Custodian für Lineage-View und Caps;
5. Actions an Schwellen — Cap, Rebuild-Stop, Waiver-Expiry — nicht nur Ampeln.

Warehouse-Lineage-Tiefe bleibt in Lineage, die Veränderungen erklärt.

Betriebsübersicht-Workflow

1. Kostenverantwortliche Person setzen

Der verantwortliche Person des Nutzungspfads ist Kostenverantwortliche Person — nicht FinOps allein. Steward legt Caps für Tokens, Embed und Vendor fest. Custodian verdrahtet das Cap im Gateway. Unbegrenzte Tokens ohne Owner sind ein stiller Budget-Incident.

2. Betriebsübersicht publizieren

Steward veröffentlicht die erste Betriebsübersicht mit Schwellen und Actions. Owner prüft neben Hygiene- und Deletion-Nachbarn, wenn Indikatoren überlappen — Hygiene Operating Betriebsübersicht. Eine Betriebsübersicht ohne Action ist ein weiteres Dashboard.

3. Herkunftskette des verwendeten Kontexts verdrahten

Custodian hängt Chunk-Metadata an Snapshot- und Source-IDs für ein Corpus. Zweck und Path-ID kommen aus Cards und sanctioned-paths-v1.

Zweck → freigegebenen KI-Nutzungspfad → Snapshot/Corpus → Chunk/Embedding → Index-Build → Answer/Tool Call

Ohne diese Kette dauert „woher kam diese Antwort?“ Tage — DSDR und Incident brauchen Minuten.

4. Wellen planen

Owner stoppt Re-Embed-Wellen, wenn Index-Größe oder Cost die Schwelle reißt. Steward koppelt Freshness an Rebuild-Trigger aus der Dataset Card. Capacity nach der Hygiene-Welle zu planen heißt, den Index den Zweck überwachsen zu lassen.

5. Incident über Lineage schließen

Custodian beweist den Stop, wenn ein Incident Chunk→Source über die Ansicht der Herkunftskette traced. Owner aktualisiert Cards und Betriebsübersicht. Eine Lineage, die nur das Warehouse kennt, erklärt keinen zitierten Chunk.

Handoffs

Anti-Patterns

• Token-Spend ohne verantwortliche Person je Pfad laufen lassen
• Re-Embed nach Hygiene ohne Capacity-Plan
• Lineage am Warehouse stoppen, während Antworten Chunks zitieren
• Shadow-Findings und Eval-Rates in getrennten Rhythmen führen
• Betriebsübersicht ohne Action-Schwellen als Ampel-Theater betreiben

Erster Praxistest

Nehmt einen realen, begrenzten Nutzungspfad. Führt die folgenden Schritte mit den tatsächlich verantwortlichen Rollen und Systemen aus. Der Test ist erst abgeschlossen, wenn Entscheidung, technische Wirkung und Nachweis zusammenpassen.

1. Kostenverantwortliche Person und Caps für einen freigegebenen KI-Nutzungspfad setzen.
2. Erste Betriebsübersicht mit Schwellen und einer Action publizieren.
3. Chunk-Metadata eines Corpus an Snapshot- und Source-IDs hängen.
4. Einen Lehr-Incident Chunk→Source über die Ansicht der Herkunftskette nachvollziehen.