In diesem Kurs geht es darum, festzulegen, welche Aktionen ein KI-Agent im Arbeitsalltag ausführen darf – basierend auf den Empfehlungen des „IMDA Model AI Governance Framework for Agentic AI“. Wer sich neu mit dem Thema befasst, soll am Ende in der Lage sein, eine konkrete Entscheidung zu treffen: Darf ein Agent in einem System Daten lesen, schreiben oder Befehle ausführen, ohne zuvor einen Menschen zu fragen? Viele Teams behandeln Agenten-Berechtigungen wie ein Einstellungsmenü, das man auch später noch anpassen kann. Die Herausforderung besteht darin, dass die Wahl der Berechtigungen bereits festlegt, wozu der Agent fähig ist, noch bevor das erste Ergebnis vorliegt. Der Fehler liegt oft darin, Gewohnheiten aus Chat-Tools zu übernehmen, bei denen das System zwar Texte vorschlägt, aber nicht selbst aktiv handelt.
Ein Agent tritt nicht nur im täglichen Betrieb in Erscheinung, sondern auch bei der Einrichtung und Freigabe. Jemand verbindet ihn mit Tools wie E-Mail-Programmen, Ticketing-Systemen oder Lieferantenportalen. Eine andere Person genehmigt diese Verbindungen und die damit verbundenen Rahmenbedingungen. Diese Schritte mögen wie gewöhnliche Integrationsarbeit wirken, doch die Entscheidung dahinter ist eine andere: Ein Agent kann eigenständig handeln – und diese Aktionen lassen sich oft nur schwer rückgängig machen, sobald sie einmal ausgeführt wurden. Deshalb kehrt dieser Kurs immer wieder zu einer einfachen Unterscheidung zurück: Ein Chatbot macht Vorschläge, ein Agent führt Aktionen aus. Hier ist ein Überblick über die Inhalte des Kurses:
Ein KI-Agent ist eine Software, die Schritte planen und angebundene Tools nutzen kann, um eine Aufgabe mit minimalem Hin-und-Her zu erledigen. Während ein Assistent meist Text generiert, den eine Person kopieren kann, ist ein Agent in der Lage, Änderungen selbstständig in einem anderen System vorzunehmen. Dieser Unterschied ist entscheidend, da eine ausgeführte Aktion über die Dauer des auslösenden Chats hinaus Bestand haben kann. Eine Nachricht lässt sich löschen, doch eine versendete E-Mail oder ein geschlossenes Ticket lassen sich nicht immer rückgängig machen.
Selbst wenn eine Aktion umkehrbar ist, kosten Korrekturen oft Zeit und Vertrauen. Ein Ticket, das nach einer Kundenantwort wieder geöffnet wird, erweckt dennoch den Eindruck, als sei der Vorgang vernachlässigt worden. Ein nach einer Aktualisierung korrigierter Lieferantendatensatz hinterlässt dennoch einen fehlerhaften Wert in einem Export. Ein solides Fundament zu schaffen bedeutet, Berechtigungen als grundlegende Designentscheidung zu betrachten und nicht bloß als letztes Sicherheitsnetz.
Entscheidungen über Berechtigungen liegen bei den Personen, die den Agenten konfigurieren und freigeben – nicht bei der Person, die ihn an einem geschäftigen Tag gerade nutzt. Ein Nutzer kann zwar entscheiden, wann eine Aufgabe gestartet wird, hat aber keinen Einblick in alle Tools, auf die der Agent zugreifen kann. Ein Anbieter liefert zwar Standardeinstellungen, weiß aber nicht, welche Aktionen in Ihrer Organisation akzeptiert werden. Die IT-Abteilung kann zwar Zugriffe einrichten, sollte aber nicht die einzige Stelle sein, an der die geschäftliche Entscheidung getroffen wird.
In diesem Kurs wird Verantwortung zudem als etwas Persönliches und Namentlich Zugewiesenes behandelt. Ein namentlich benannter menschlicher Verantwortlicher ist eine konkrete Person, die dafür geradesteht, was der Agent tun darf und wie er überwacht wird. Diese Verantwortung entfällt nicht, nur weil der Agent „intern“ ist oder über ein Dienstkonto läuft. Wenn ein Agent agiert, muss nachvollziehbar sein, wer den Handlungsspielraum dafür freigegeben hat und unter welchen Bedingungen dies geschah.
Wir führen einen kurzen Check durch, um zwischen Konfigurationen, die nur sicher wirken, und tatsächlich sicheren Konfigurationen zu unterscheiden.