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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.