# KI im IT-Betrieb — Einführung & Governance > Use-Case-Inventar, Nettozeit, begrenzte Piloten, Schattenbetrieb, Risikostufen und Verantwortlichkeiten zu einem wartbaren Einführungsprozess verbinden. Track: [AI-Grundlagen für den IT-Betrieb](https://physar.tech/learn/ai-foundations) Kanonische Fassung: https://physar.tech/learn/ai-foundations/ai-in-ops-workflows Stand: 2026-09-04 Interaktiver Teil: 8 Checks (nur im Browser) ## KI im IT-Betrieb — Einführung & Governance ### Die typischen Einsatzstellen Im IT-Betrieb gibt es eine Handvoll Muster, die sich immer wieder als tragfähig erweisen — und sie haben alle dieselbe Form: viel gleichartiger Text, hohe Varianz in der Formulierung, ein Ergebnis, das sich schnell prüfen lässt. | | | | --- | --- | | Ticket-Triage | Kategorie, Priorität, Zuständigkeit vorschlagen — Korrektur ist billig | | Wissenssuche | Frage auf Dokumentation beziehen — Beleg macht die Prüfung schnell | | Log- und Alarmzusammenfassung | Vorverdichtung für den Menschen — Rohdaten bleiben verfügbar | | Dokumentationsentwürfe | Erstfassung aus Notizen — Redaktion prüft ohnehin | | Änderungsbeschreibungen | Formulieren, nicht bewerten — die Freigabe bleibt beim Menschen | _[Abbildung: Einführung ist selbst eine Regelschleife: klein anfangen, messen, entscheiden — mit einem Abbruchkriterium, das vorher feststeht.]_ **Use Case:** Ein abgegrenzter Einsatz eines AI-Systems mit benanntem Zweck, Nutzern, Eingaben, Wirkung, Eigentümer und Betriebsgrenze — nicht bloß ein gekauftes Tool. Typische Ops-Einsätze reichen von Suche und Zusammenfassung über Klassifikation bis zu Vorschlägen für Änderungen. Beginne mit dem Engpass im Prozess, nicht mit der Fähigkeitsliste eines Modells. Ein Use Case kann mehrere Modell- und Nichtmodellschritte enthalten. Das Inventar bleibt deshalb auf Systemebene: Wer nutzt es, welche Daten fließen, welche Wirkung ist möglich und welcher manuelle Prozess greift bei Ausfall? ### Die Rechnung, die zählt: Nettozeit Der häufigste Fehler in Wirtschaftlichkeitsrechnungen ist, nur die eingesparte Ausführungszeit zu zählen. Realistisch ist: **eingesparte Zeit minus Prüfzeit minus Korrekturzeit minus anteiliger Betriebsaufwand.** Rechne konservativ mit der Prüfzeit. Wenn das Prüfen eines Entwurfs zwei Drittel der Zeit kostet, die das Schreiben gekostet hätte, bleibt ein Drittel Gewinn — nicht der volle Betrag. Und wenn ein Fehler erst später auffällt, kommt die Korrektur oben drauf, oft mit Zinsen. > **Merksatz:** Automatisierung, die Arbeit verschiebt statt sie zu beseitigen, sieht in der Präsentation gut aus und im Betrieb nicht. Nettozeit ist eingesparte Bearbeitung minus Prüfung, Korrektur, Eskalation und zusätzliche Bedienung. Rechne außerdem Plattform- und Pflegezeit ein. Ein Vorschlag, der zwei Minuten Schreiben spart und drei Minuten Quellenprüfung erzeugt, ist kein Produktivitätsgewinn. Segmentiere nach Fallklasse: Automatisierung kann bei Standardtickets positiv und bei seltenen Störungen negativ sein. Zeit ist nicht der einzige Nutzen. Schnellere Reaktion, konsistentere Dokumentation oder bessere Auffindbarkeit können relevant sein, brauchen aber eigene Messgrößen. **Preis:** Ein ehrliches Nutzenmodell macht manche attraktive Demo untragbar. Es verhindert, dass Nutzung oder erzeugte Tokens mit fachlichem Wert verwechselt werden. Beziehe Fehlerfolgen als erwarteten Aufwand ein: Häufigkeit einer Fehlerklasse mal mittlere Korrektur- und Schadenszeit. Seltene schwere Fälle werden zusätzlich als harte Gates behandelt und nicht durch durchschnittliche Zeitersparnis verrechnet. Das verhindert eine Rechnung, in der tausend gesparte Minuten einen einzigen unzulässigen Zugriff scheinbar kompensieren. **Nachteil:** Manche Nutzenarten bleiben schwer monetarisierbar; sie werden separat dokumentiert statt mit erfundenen Eurobeträgen präzisiert. ### Der Pilot: klein, gemessen, mit Ausstieg Ein guter Pilot beantwortet **eine** Frage in wenigen Wochen und hat vorher festgelegt, woran man Erfolg erkennt — und woran Scheitern. Das Abbruchkriterium ist der wichtigste Teil, weil es der einzige ist, den niemand freiwillig aufschreibt. - Einen abgegrenzten Bereich wählen, in dem Fehler tragbar und Rückmeldungen schnell sind. - Basiswert vorher erheben: Wie lange dauert es heute, wie gut ist es heute? - Zielgröße und Abbruchkriterium schriftlich festhalten, bevor gebaut wird. - Laufzeit begrenzen — ein Pilot ohne Enddatum wird zum unbeaufsichtigten Dauerbetrieb. Ein Pilot testet die kleinste unsichere Annahme. Er benennt Population, Baseline, Dauer, Verantwortliche, Datenfreigabe, Erfolgsschwelle, Abbruchkriterium und Rückfallweg. Starte mit reversibler Wirkung und begrenzter Nutzergruppe. Ein offener „Probiert es mal“-Test sammelt Anekdoten, verändert Arbeitsweisen und erzeugt möglicherweise bereits personenbezogene Schattenprozesse, ohne eine belastbare Entscheidung vorzubereiten. > **Abbruch vor Start:** Lege fest, bei welchem Sicherheits-, Qualitäts- oder Nettozeitbefund der Pilot stoppt. Ein Kriterium, das erst nach schlechten Ergebnissen erfunden wird, ist kein Gate. ### Schattenbetrieb — die unterschätzte Stufe Zwischen Pilot und Produktion liegt eine Stufe, die selten genutzt wird und viel liefert: Das System läuft mit, entscheidet aber nichts. Seine Vorschläge werden aufgezeichnet und mit dem verglichen, was die Menschen tatsächlich getan haben. echter Vorgang → Mensch entscheidet → System schlägt parallel vor → **Vergleich aufzeichnen** → Auswertung Der Gewinn ist doppelt: Ihr bekommt eine Qualitätsaussage unter echter Last **ohne** Risiko — und nebenbei entsteht ein Testset aus realen Fällen mit menschlicher Referenzentscheidung. Der Preis ist Wartezeit und doppelte Rechenkosten während der Phase. > **Vorsicht:** Die menschliche Entscheidung ist Referenz, nicht Wahrheit. Wo Menschen systematisch danebenliegen, misst der Vergleich Übereinstimmung mit einem Fehler. Im Schattenbetrieb erzeugt das System Ergebnisse, aber der bestehende Prozess bleibt wirksam. Das erlaubt Paarvergleiche auf realen Fällen, ohne Modellfehler direkt auszulösen. Schattenbetrieb ist nicht risikofrei: Daten werden verarbeitet, Ergebnisse gespeichert, Kosten erzeugt und Mitarbeitende können Vorschläge informell nutzen. Zugriff, Aufbewahrung und klare Kennzeichnung bleiben erforderlich. Achte auf Leckage zwischen Kandidat und Baseline. Wenn Reviewer die Modellantwort sehen, misst du bereits einen assistierten Prozess und möglichen Automatisierungs-Bias. **Preis eines blinden Vergleichs:** mehr Bearbeitungszeit und weniger unmittelbarer Nutzen. Der Gewinn ist eine unabhängigere Aussage über Qualität. ### Der eigentliche Engpass: Akzeptanz Die meisten intern gescheiterten Einführungen scheitern nicht an der Qualität, sondern daran, dass niemand das Werkzeug benutzt. Die Gründe sind selten technisch: Misstrauen nach einer schlechten ersten Erfahrung, unklare Zuständigkeit im Fehlerfall, ein Medienbruch im Arbeitsablauf, oder die Sorge, sich mit einer falschen Übernahme angreifbar zu machen. - Ins vorhandene Werkzeug integrieren statt eine zweite Oberfläche zu eröffnen — jeder Wechsel kostet Nutzung. - Klar sagen, wer im Fehlerfall verantwortlich ist; ohne diese Antwort übernimmt niemand einen Vorschlag. - Belege mitliefern, damit Übernehmen nicht Vertrauen erfordert, sondern Prüfen ermöglicht. - Frühe Nutzer beteiligen und Rückmeldung sichtbar umsetzen — die erste schlechte Erfahrung prägt monatelang. **Kurzcheck:** Ein Triage-Assistent erreicht im Test gute Qualität, wird aber nach zwei Monaten kaum genutzt. Wo suchst du zuerst? - [x] Im Arbeitsablauf — ob der Vorschlag dort erscheint, wo gearbeitet wird, und wer bei einem Fehler geradesteht - [ ] Im Modell — die Qualität ist vermutlich in Produktion schlechter als im Test - [ ] In der Schulung — die Leute wissen wahrscheinlich nicht, wie man es bedient > Richtig. Bei guter gemessener Qualität liegt die Ursache fast immer in Einbindung, Zuständigkeit oder Vertrauen. Akzeptanz ist eine Systemeigenschaft aus Nutzen, Vertrauen, Bedienung und Verantwortungsverteilung. Ein technisch gutes Modell scheitert, wenn es keine Evidenz zeigt, bestehende Tools umgeht oder Fehlerarbeit auf Nutzer verschiebt. Beobachte Abbruch, Korrektur, Umgehung und Eskalation statt nur aktive Nutzer. Ein verpflichtender Rollout kann Nutzung erzwingen, aber keinen Nettoeffekt beweisen. Beteilige die Personen, die Fehler auffangen, bereits am Zuschnitt. **Nachteil:** Mehr Stakeholder verlangsamen den Start und bringen widersprüchliche Anforderungen ans Licht. Diese Konflikte existieren im Betrieb ohnehin; frühe Sichtbarkeit ist billiger als ein später Schattenprozess. ### Warum das dich betrifft Governance klingt nach Stabsabteilung und ist in der Praxis eine Betriebsaufgabe: Wer die Systeme baut und betreibt, entscheidet faktisch, was protokolliert wird, wer worauf zugreift und ob ein Einsatz überhaupt auffindbar ist. Ohne diese Grundlagen kann keine Richtlinie wirken. Dieses Modul liefert keine Rechtsberatung. Es liefert die organisatorischen Entscheidungen, die im Betrieb anfallen — und die Sprache, mit der du sie gegenüber Datenschutz, Revision und Leitung vertrittst. Governance bedeutet nicht, dass jedes Experiment denselben Freigabeapparat durchläuft. Sie sorgt dafür, dass Zweck, Risiko, Daten, Verantwortung und Änderungen nachvollziehbar sind. NIST organisiert Risikomanagement in `GOVERN`, `MAP`, `MEASURE` und `MANAGE`; der EU AI Act legt je nach Rolle und Anwendungsfall konkrete Pflichten fest. Dieses Modul ersetzt keine Rechtsberatung. Es zeigt die technischen Artefakte, ohne die eine Organisation ihre Pflichten nicht operationalisieren kann. ### Schatten-KI: das Verbot, das nicht wirkt Die verbreitetste Reaktion auf KI im Unternehmen ist ein pauschales Verbot. Es wirkt selten: Die Werkzeuge sind über jeden Browser und jedes private Gerät erreichbar, der Nutzen ist unmittelbar spürbar, und die Nutzung hinterlässt keine Spur in eurer Infrastruktur. Das Ergebnis ist **Schatten-KI**: Firmendaten wandern in private Zugänge ohne Vertrag, ohne Protokoll, ohne Zweckbindung. Ein Verbot ohne freigegebenen Weg erzeugt genau die Risiken, die es verhindern sollte — nur unsichtbar. | | | | --- | --- | | Pauschales Verbot ohne Alternative | Nutzung wandert in private Zugänge — maximales Risiko, null Sichtbarkeit | | Freigegebener Weg plus klare Leitplanken | Nutzung ist sichtbar, vertraglich abgesichert und steuerbar | | Keine Regelung | Wildwuchs, aber wenigstens sichtbar — schlechter als Weg mit Leitplanken | > **Merksatz:** Governance konkurriert mit dem privaten Browserfenster. Was zu umständlich ist, wird umgangen — und dann ist die Regelung schlechter als keine. Ein Totalverbot ohne sichere Alternative fördert Schatten-KI: Mitarbeitende nutzen private Konten, kopieren Daten in unbekannte Dienste oder umgehen Logging. Die Antwort ist weder Freigabe von allem noch Duldung, sondern ein benutzbarer erlaubter Pfad mit klaren Datenklassen und schneller Entscheidung für risikoarme Fälle. Verstöße werden als Signal für fehlende Arbeitswege untersucht, nicht nur als Disziplinproblem. > **Trade-off:** Ein erlaubter Standardpfad reduziert Schattennutzung, schafft aber Betrieb, Support und Verantwortung für diese Plattform. Ein Verbot ist nur dann billig, wenn es tatsächlich eingehalten und eine notwendige Arbeit anders erledigt wird. ### Das Register: Voraussetzung für alles Weitere Man kann nicht steuern, was man nicht kennt. Der unspektakulärste und wirksamste Baustein ist deshalb ein **Verzeichnis der Anwendungsfälle**: Wer setzt wo welches System für welchen Zweck ein, mit welchen Daten, mit welcher Kontrolle, wer ist fachlich verantwortlich? - Ohne Register ist keine Risikoeinstufung möglich — es gibt nichts zu bewerten. - Ohne Register trifft eine Modellabkündigung oder eine Sicherheitsmeldung euch unvorbereitet, weil niemand die betroffenen Stellen kennt. - Ohne Register beginnt jede Prüfung durch Revision oder Aufsicht mit einer wochenlangen Bestandsaufnahme. - Der Eintrag muss billig sein — ein aufwendiges Formular erzeugt Einträge, die nie gemacht werden. Das Register verbindet mindestens Zweck, Owner, Nutzergruppe, Datenklassen, Anbieter und Modell, Integrationen, mögliche Wirkung, Risikostufe, Eval-Gate, Freigabe, Aufbewahrung und nächstes Reviewdatum. Es erfasst auch eingebettete AI-Funktionen in bestehenden SaaS-Produkten. Ein Einkaufsregister allein reicht nicht, weil dasselbe Produkt in einem harmlosen Schreibassistenten und einer Personalentscheidung verschiedene Risiken hat. Automatisiere Erinnerungen und Pflichtfelder, aber halte Verantwortlichkeit menschlich benannt. **Preis:** Das Register braucht Pflege. Wenn niemand auf veraltete Einträge reagiert, wird es Dokumentationstheater. Verknüpfe es daher mit Deployment, Zugang, Anbieterwechsel und Incident-Prozess. Ein Registereintrag wird bei relevanten Änderungen aktualisiert: neuer Zweck, neue Datenklasse, anderes Modell, zusätzliches Tool, höhere Autonomie oder veränderter Nutzerkreis. Nicht jede Promptkorrektur braucht ein Governance-Board, aber jede Änderung läuft durch das passende technische Eval-Gate. **Preis:** Änderungsklassen und Verantwortungen müssen vorab definiert werden. Sie erlauben schnelle risikoarme Updates, ohne risikoreiche Scope-Erweiterung zu tarnen. ### Aufwand nach Risiko staffeln Ein einheitliches Prüfverfahren für alle Anwendungsfälle ist entweder für die kleinen zu schwer oder für die großen zu leicht. Regulatorische Rahmenwerke arbeiten deshalb **risikobasiert**: Je größer die möglichen Auswirkungen auf Menschen, desto strenger die Anforderungen an Prüfung, Dokumentation und Aufsicht. Für den Betrieb übersetzt sich das in eine einfache Staffelung: Ein Formulierungshelfer ohne Personenbezug braucht einen Registereintrag und die allgemeinen Leitplanken. Ein System, das über Zugang, Ansprüche oder Beschäftigung von Menschen mitentscheidet, braucht Folgenabschätzung, dokumentierte Kontrollen und benannte Verantwortung. > **Evergreen-Hinweis:** Konkrete Pflichten, Schwellen und Fristen unterscheiden sich je nach Rechtsraum und ändern sich. Stabil ist das **Prinzip**: Aufwand proportional zur möglichen Auswirkung auf Menschen. Risikostufung beginnt bei Wirkung, betroffenen Personen, Reversibilität, Daten und Autonomie. Ein interner Textentwurf braucht weniger Kontrolle als eine Priorisierung von Bewerbern oder eine automatische Infrastrukturänderung. Gesetzliche Kategorien können zusätzliche harte Anforderungen setzen; die interne Stufung darf sie nicht ersetzen. Sie steuert den betrieblichen Aufwand innerhalb des zulässigen Rahmens. | | | | --- | --- | | Niedrig | Assistiver Entwurf, keine sensible Wirkung: schlankes Register und Stichprobe | | Mittel | Fachliche Entscheidungsvorlage: Eval-Gate, Evidenz und Pflichtfreigabe | | Hoch | Rechte, Personal, Sicherheit oder irreversible Wirkung: formale Prüfung und harte Systemgrenzen | ### Transparenz und Verantwortung Zwei Fragen tauchen in jeder ernsthaften Prüfung auf. **Wissen die Betroffenen, dass ein KI-System beteiligt ist?** Und: **Wer trägt die Verantwortung für das Ergebnis?** Die zweite Frage ist die betrieblich wichtigere. Solange sie unbeantwortet ist, wird niemand einen Vorschlag übernehmen, der später jemandem zugerechnet werden könnte — und die Kontrolle im Prozess verkommt zur Formsache. Verantwortung bleibt immer bei Menschen; sie muss nur benannt sein. - Kennzeichnen, wo Betroffene sonst annehmen würden, ein Mensch habe entschieden oder geschrieben. - Fachliche Verantwortung je Anwendungsfall benennen — eine Rolle, keine Abteilung. - Dokumentieren, welches System mit welcher Version und welchen Daten im Einsatz ist. - Einen Meldeweg für auffällige Ergebnisse schaffen, der nicht über drei Ecken führt. **Kurzcheck:** Die Leitung will KI-Werkzeuge komplett untersagen, bis eine Richtlinie steht. Was gibst du zu bedenken? - [x] Ohne freigegebenen Weg wandert die Nutzung in private Zugänge — das Risiko steigt und wird unsichtbar - [ ] Ein Verbot ist die sicherste Option, bis Klarheit besteht - [ ] Ohne Richtlinie ist ohnehin keine Nutzung zulässig, die Frage stellt sich nicht > Richtig. Ein Verbot ohne Alternative erzeugt Schatten-KI. Besser ist ein enger, freigegebener Weg mit klaren Grenzen, bis die Richtlinie steht. Transparenz beantwortet für Betroffene und Nutzer: Wo interagieren sie mit AI, wofür wird sie eingesetzt, welche Grenzen sind bekannt, wer trägt Verantwortung und wie kann eine Entscheidung angefochten werden? Art und Umfang hängen vom Fall und geltendem Recht ab. Eine pauschale Fußnote „kann KI enthalten“ ist betrieblich kaum hilfreich. Der EU AI Act enthält unter anderem Transparenzregeln für bestimmte Interaktions- und Inhaltsfälle. ### Vom Copilot zum kontrollierten Betrieb Ein Service-Desk will automatisch Antwortentwürfe erzeugen und später Standardtickets selbst schließen. **Anforderungen** - Nettozeit und Fehlerwirkung werden getrennt gemessen. - Daten und Verantwortliche sind registriert. - Autonomie wird nicht im selben Schritt wie Textqualität freigegeben. **Schritte** - Assistiven Entwurf gegen den heutigen Prozess im Schattenmodus messen. - Korrekturzeit, Evidenznutzung und Fehlerklassen erfassen. - Nur risikoarme, reversible Fälle für einen engeren Automatikpilot auswählen. - Toolrechte, Freigabegate, Transparenz und Rückfallweg vor Aktivierung dokumentieren. **Merksatz:** Ein Modellpilot beweist Textnutzen; er beweist nicht automatisch sichere Autonomie. Gleich im Check führst du acht Entscheidungen dieses Einführungspfads aus: Nettozeit rechnen, Pilot begrenzen, Schattenbetrieb auswerten, Akzeptanzproblem erkennen, Schatten-KI beantworten, Register anlegen, Aufwand nach Risiko staffeln und Transparenz herstellen. Die richtige Antwort ist nie „mehr Governance“ oder „mehr AI“ an sich, sondern die kleinste Kontrolle, die den benannten Fehler wirksam adressiert. Jede Freigabe besitzt ein nächstes Reviewdatum und einen Owner; andernfalls altert der Pilot unbemerkt zum Dauerbetrieb. So bleibt jede spätere Scope-Erweiterung eine neue, sichtbare Entscheidung statt stiller Funktionsdrift. Das Register dokumentiert auch diese Entscheidung und ihren Gültigkeitsbereich. Nur so bleibt die organisatorische Freigabe mit dem tatsächlich betriebenen Systemzustand verbunden. ## Quellen - Beyer et al. (Hrsg.) — Site Reliability Engineering, O'Reilly 2016, Kapitel Automation und Postmortem Culture - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Map- und Manage-Funktionen - Amershi et al. — Software Engineering for Machine Learning: A Case Study, ICSE-SEIP 2019 - Parasuraman & Manzey — Complacency and Bias in Human Use of Automation, Human Factors 2010 - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Govern-Funktion - ISO/IEC 42001:2023 — AI management systems - Verordnung (EU) 2024/1689 über künstliche Intelligenz — risikobasierter Ansatz - Mitchell et al. — Model Cards for Model Reporting, ACM FAT* 2019 - NIST — Artificial Intelligence Risk Management Framework 1.0 — https://doi.org/10.6028/NIST.AI.100-1 - NIST — AI RMF Core — https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ - NIST — Generative AI Profile, NIST AI 600-1 — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf - Verordnung (EU) 2024/1689 — Artificial Intelligence Act — https://eur-lex.europa.eu/eli/reg/2024/1689/oj - Breck et al. — The ML Test Score, IEEE Big Data 2017 — https://research.google/pubs/the-ml-test-score-a-rubric-for-ml-production-readiness-and-technical-debt-reduction/ - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Map- und Measure-Funktionen - Beyer et al. (Hrsg.) — Site Reliability Engineering, O'Reilly 2016, Kapitel Automation - ISO/IEC 42001:2023 — AI management systems (Inventar und Zuständigkeiten) - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Govern- und Map-Funktionen - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Measure-Funktion - ISO/IEC 42001:2023 — AI management systems (Richtlinien und Zuständigkeiten) - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Map- und Govern-Funktionen - ISO/IEC 23894:2023 — AI risk management - Breck et al. — The ML Test Score: A Rubric for ML Production Readiness, IEEE Big Data 2017 - Beyer et al. (Hrsg.) — Site Reliability Engineering, O'Reilly 2016, Kapitel Testing for Reliability - Verordnung (EU) 2024/1689 über künstliche Intelligenz — Transparenzpflichten bei Interaktion mit KI-Systemen - NIST AI Risk Management Framework (AI RMF 1.0), 2023 — Govern-Funktion (Transparenz und Rechenschaft)