Viele Unternehmen haben generative KI eingeführt und ihre Beschäftigten in ersten Kursen geschult. Weitere Kompetenzlücken zeigen sich später, wenn Assistenten auf Unternehmensdaten zugreifen und Agenten Aufgaben in produktiven Systemen übernehmen.
Mehr als Prompt Engineering
Die KI-Kompetenzlücke liegt im Betrieb, nicht im Prompt
Quelle: Cybersteps
Die Ausgangslage ist gut dokumentiert. Laut einer Forsa-Umfrage im Auftrag des TÜV-Verbands setzen 56 Prozent der Unternehmen ab 20 Beschäftigten generative KI-Werkzeuge im Arbeitsalltag ein. Erst 27 Prozent der befragten Unternehmen haben ihre Mitarbeitenden zum Einsatz generativer KI geschult. Bei mittleren Unternehmen mit 50 bis 249 Beschäftigten liegt dieser Anteil bei 32 Prozent, bei kleinen mit 20 bis 49 Beschäftigten bei 21 Prozent. In der weltweiten Global Workforce Hopes and Fears Survey 2026 von PwC stieg der Anteil der Beschäftigten, die generative KI täglich nutzen, gegenüber dem Vorjahr von 14 auf 22 Prozent. Zugleich sank der Anteil derjenigen, die Zugang zu den benötigten Weiterbildungsangeboten haben, von 59 auf 51 Prozent.
Die naheliegende Antwort lautet mehr Schulungen. Kurse zum Formulieren von Prompts und zum Prüfen von Antworten vermitteln wichtige Grundlagen. Für den Betrieb integrierter KI-Anwendungen reichen sie allein jedoch nicht aus. Sobald ein Assistent Zugriff auf SharePoint, Ticketsystem oder CRM erhält, wird aus einer Anwenderfrage eine Betriebsfrage. Im Workforce Readiness Report von Skillsoft nennen 23 Prozent der befragten Führungskräfte Verzögerungen bei der KI-Einführung als Folge fehlender Kompetenzen. Ein genauerer Blick zeigt, welche Fähigkeiten für den Betrieb fehlen.
Wenn der Assistent mehr findet als gedacht
Ein typisches Muster zeigt sich bei der Einführung von Microsoft 365 Copilot oder eigenen RAG-Anwendungen, die Antworten aus internen Dokumenten zusammenstellen. Copilot berücksichtigt die bestehenden Zugriffsrechte des jeweiligen Nutzers. Bei selbst entwickelten RAG-Anwendungen muss die Berechtigungsprüfung ebenso zuverlässig umgesetzt werden. In beiden Fällen gilt, dass über Jahre Freigaben entstanden sind, die niemand mehr überblickt. Ordner wurden für das gesamte Unternehmen geteilt, Projektseiten behielten ihre Gastzugänge, Freigabelinks laufen nie ab. Was früher unbeachtet in der Ablage lag, liefert die KI nun in Sekunden als Antwort, etwa eine alte Gehaltsliste oder einen Vertragsentwurf mit Konditionen.
Das ist kein Fehler des Modells. Es ist ein Berechtigungsproblem, das durch KI plötzlich sichtbar wird. Wer eine solche Einführung verantwortet, muss Identitäten, Gruppen, Freigabelinks und Vertraulichkeitsstufen lesen und bereinigen können, bevor das erste Pilotteam startet. Häufig liegt dieses Wissen bei einer Person im Microsoft-365-Betrieb, die mit dem KI-Projekt organisatorisch nichts zu tun hat. Die Projektgruppe wiederum kennt die Modelle, aber nicht die gewachsene Ablagestruktur. Fehlt die Abstimmung zwischen KI-Projekt und IT-Betrieb, bleiben zu weit gefasste Freigaben unentdeckt.
Agenten brauchen eigene Identitäten und enge Rechte
Noch deutlicher wird die Lücke bei KI-Agenten. Ein Agent, der Tickets anlegt, Termine bucht oder Daten aus dem ERP abruft, benötigt Zugangsdaten. Bequem ist ein API-Schlüssel mit weitreichenden Rechten. Sicher ist er nicht. Über Standards wie das Model Context Protocol (MCP) lassen sich Werkzeuge inzwischen mit wenig Aufwand an ein Sprachmodell anbinden. Jede zusätzliche Anbindung kann weitere Lese- oder Schreibzugriffe ermöglichen, die das Modell im Namen eines Benutzers oder eines Dienstkontos nutzt. Welche davon der Agent tatsächlich ausführen darf, muss außerhalb des Modells verbindlich geprüft werden.
Daraus entstehen Fragen, die eigentlich ins Identity- und Access-Management gehören. Läuft der Agent unter einem eigenen Dienstkonto oder mit den Rechten des Anwenders, der ihn gerade nutzt? Welche Aktionen darf er ohne Bestätigung durch einen Menschen ausführen? Wo werden seine Aufrufe protokolliert, und wer liest diese Protokolle tatsächlich? Wie gefragt das passende Wissen ist, zeigt eine Cisco-Befragung unter deutschen Sicherheitsverantwortlichen. 44 Prozent vermissen beim Cybersecurity-Nachwuchs praktische Erfahrung mit KI-Agenten, die Hälfte bemängelt fehlende technische Tiefe.
Prompt Injection erfordert Schutz an den Systemgrenzen
Assistenten und Agenten verarbeiten laufend Inhalte, die nicht aus dem eigenen Haus stammen, etwa E-Mails, hochgeladene PDFs oder Webseiten. Enthält ein solches Dokument versteckte Anweisungen, kann das Modell sie als Teil seiner Aufgabe behandeln. Schon ohne angebundene Werkzeuge können manipulierte Inhalte Antworten verfälschen oder vertrauliche Informationen aus dem verfügbaren Kontext offenlegen. Hat das System Schreibrechte oder darf es Nachrichten versenden, kann es zusätzlich Daten weiterleiten oder Einträge verändern, ohne dass ein Mensch eingreift.
Eine vollständige technische Lösung für dieses Problem gibt es derzeit nicht. Wirksam sind Maßnahmen, die Sicherheitsteams aus anderen Bereichen kennen. Externe Inhalte werden grundsätzlich als nicht vertrauenswürdig behandelt. Berechtigungen und Parameter von Werkzeugaufrufen prüft eine Instanz außerhalb des Modells, und sensible Schreibaktionen erfordern eine menschliche Freigabe. Begrenzte ausgehende Verbindungen und geprüfte Ausgaben ergänzen diese Kontrollen. Sie zu entwerfen, setzt ein Verständnis dafür voraus, wie Sprachmodelle Kontext verarbeiten, und zugleich Erfahrung mit Sicherheitsarchitektur. Diese Kombination ist in den meisten IT-Abteilungen selten.
Ohne Testfälle kein verlässlicher Betrieb
Eine weitere Lücke betrifft die Qualitätssicherung. In klassischer Software zeigen automatisierte Tests, ob eine Änderung etwas kaputt macht. Bei KI-Anwendungen ändert sich das Verhalten bereits, wenn der Anbieter eine neue Modellversion ausrollt oder jemand den Systemprompt anpasst. Viele Teams bemerken das erst, wenn sich Anwender über falsche oder ausweichende Antworten beschweren.
Ein gepflegter Satz realistischer Testfälle hilft, solche Veränderungen früh zu erkennen. Für jeden Fall werden Bewertungskriterien festgelegt, etwa sachliche Richtigkeit, zulässige Quellen und das Einhalten von Zugriffsrechten. Für eine interne Wissensanwendung reichen anfangs einige Dutzend Fälle. Dazu gehören Fragen, die korrekt beantwortet werden müssen, Fragen zu Dokumenten, die der Testnutzer gar nicht sehen darf, und Fragen, auf die die richtige Antwort lautet, dass dazu keine Informationen vorliegen. Solche Bewertungen, im Fachjargon Evals genannt, sind längst kein Forschungsthema mehr. Sie gehören zur Betriebsroutine. Jemand muss sie pflegen, die Ergebnisse auswerten und bei Abweichungen entscheiden, ob eine Änderung live gehen darf.
Kosten pro Anwendungsfall kennen
Mit wachsender Nutzung rückt auch die Abrechnung in den Vordergrund. Tokenbasierte Preise, verschiedene Modelle für verschiedene Aufgaben und Agenten, die bei einem Fehler in Schleifen laufen, machen Budgets schwer planbar. Wer KI im Unternehmen betreibt, sollte für jeden Anwendungsfall wissen, was eine Anfrage im Schnitt kostet und welchen Aufwand sie einspart. Erst dann lässt sich begründet entscheiden, welcher Pilot ausgebaut und welcher beendet wird. Diese Aufgabe liegt zwischen IT-Betrieb, Controlling und Fachbereich und taucht deshalb in kaum einer Stellenbeschreibung auf.
Ein Verzeichnis statt verstreuter Piloten
In vielen Unternehmen entstehen KI-Anwendungen dezentral. Der Vertrieb testet einen Assistenten für Angebote, die Personalabteilung einen für Stellenanzeigen, die IT einen für die Ticketbearbeitung. Nach einem Jahr weiß niemand mehr genau, welche Werkzeuge mit welchen Daten arbeiten und wer sie freigegeben hat. Ein schlichtes Verzeichnis schafft hier Ordnung. Es hält für jeden Anwendungsfall fest, welches Modell genutzt wird, auf welche Datenquellen es zugreift, wer fachlich verantwortlich ist und wann die letzte Prüfung stattfand. Das erleichtert die Abstimmung mit den Datenschutzverantwortlichen und die Planung gezielter Qualifizierung, die die europäische KI-Verordnung von Unternehmen beim Einsatz von KI-Systemen ohnehin erwartet. Vor allem aber zeigt ein solches Verzeichnis, an welchen Stellen das Betriebswissen fehlt.
Wer diese Rolle im Unternehmen übernimmt
Zusammengenommen ergibt sich ein Profil, das weder einem Data Scientist noch einem klassischen Administrator entspricht. Gefragt ist eine Person, die Berechtigungskonzepte versteht, Agenten sauber anbindet, Testfälle pflegt, Kosten im Blick behält und mit Fachbereichen und Datenschutz eine gemeinsame Sprache findet. Je nach Unternehmen verteilen sich diese Aufgaben auf KI-Management, IT-Betrieb und Informationssicherheit, und für die neuen Rollen kursieren Bezeichnungen wie KI-Manager oder KI-Beauftragter. Auch die IHKs bieten dazu inzwischen Zertifikatslehrgänge an. Verantwortliche sollten dabei prüfen, welche der beschriebenen Aufgaben tatsächlich praktisch vermittelt werden.
Unternehmen haben im Wesentlichen zwei Wege, diese Rolle zu besetzen. Der erste ist der Aufbau aus den eigenen Reihen. Ein Administrator, der die Microsoft-365-Umgebung seit Jahren betreut, kennt die gewachsenen Freigaben und die Ausnahmen, die nirgends dokumentiert sind. Ihm fehlen meist Modellverständnis, Evaluationsmethoden und Erfahrung mit Agenten. Diese Lücke lässt sich gezielt schließen, wenn die Qualifizierung mit echten Unternehmensumgebungen arbeitet und nicht bei Folien stehen bleibt.
Der zweite Weg ist die Einstellung von Quereinsteigerinnen und Quereinsteigern, die eine praxisorientierte Qualifizierung durchlaufen haben. Hier lohnt ein Blick ins Curriculum. In der mehrmonatigen KI-Weiterbildung von Cybersteps arbeiten Teilnehmende laut Lehrplan beispielsweise in einer Unternehmensumgebung mit Benutzern, Identitäten, Berechtigungen und realistischen Daten, unter anderem mit Microsoft 365, Azure, RAG-Anwendungen und der Bewertung von KI-Ergebnissen. Wer Kandidatinnen und Kandidaten mit einem solchen Hintergrund einlädt, sollte im Gespräch nach genau diesen Übungen fragen. Wie wurde ein Agent angebunden, welche Rechte hatte er, und wie wurde geprüft, ob seine Antworten stimmen? Die Bewerberinnen und Bewerber sollten erläutern können, welche Aufgaben sie dabei selbst umgesetzt haben.
Beide Wege schließen sich nicht aus. Sinnvoll kann auch ein Tandem sein, in dem eine erfahrene interne Fachkraft die Umgebung einbringt und eine neu qualifizierte Person sich vollständig auf den KI-Betrieb konzentriert. Wichtig ist nur, dass die Verantwortung bei konkreten Menschen liegt und nicht beim Projektteam als Ganzem.
Vier Fragen vor dem nächsten Rollout
Ob ein Unternehmen an dieser Stelle eine Lücke hat, lässt sich mit wenigen Fragen klären. Wer entscheidet, auf welche Datenquellen ein Assistent zugreifen darf, und wer hat die bestehenden Freigaben vorher geprüft? Welche Testfälle laufen, bevor ein neues Modell oder ein geänderter Prompt in Betrieb geht? Wer liest die Protokolle der Agenten, und wer darf einen Agenten im Zweifel stoppen? Und wer kann beziffern, was ein Anwendungsfall pro Monat kostet?
Stehen hinter diesen Fragen keine Namen, liegt der eigentliche Weiterbildungsbedarf nicht beim Prompten. Er liegt dort, wo KI auf Identitäten, Daten und Prozesse trifft. Diese Schicht entscheidet darüber, ob aus einem gelungenen Pilotprojekt ein Dienst wird, auf den sich Fachbereiche im Alltag verlassen können.
