Wie man das Risiko von KI-Agenten vor der Produktion bewertet

Wie man das Risiko von KI-Agenten vor der Produktion bewertet

10. Mai 2026 · 10 Min. Lesezeit

Die Risikobewertung eines KI-Agenten sollte stattfinden, bevor er in Produktion geht, nicht erst nach dem ersten Vorfall, der ersten Prüfungsanfrage oder einer unklaren Eskalation.

Die Bewertung muss nicht schwergewichtig sein. Wenn der Prozess zu schwer wird, umgehen Teams ihn. Die nützliche Version ist eine strukturierte Aufnahme, mit der Produkt, Compliance, Security, Architektur und Fachbereich eine Frage beantworten:

Was könnte dieser Agent tun, wer wäre betroffen, und welche Kontrollen müssen vorhanden sein, bevor er arbeiten darf?

Dieser Artikel beschreibt ein praktisches Bewertungsmodell für KI-Agenten im Unternehmen. Es passt zu dem Zeitpunkt, an dem ein Team einen echten Use Case, eine grobe Architektur und einen geplanten Produktionspfad hat, aber noch keine Freigabe für den Betrieb.

Kurzfassung

Vor der Produktion sollten sieben Dimensionen bewertet werden:

Dimension Was zu bestimmen ist
Use-Case-Aufnahme Zweck, Nutzer, Owner, Prozess und Einsatzkontext
Autonomie Ob der Agent nur antwortet, empfiehlt, handelt oder durch Trigger läuft
Tool-Zugriff Welche Systeme er aufrufen kann und ob diese Aufrufe lesend oder schreibend sind
Datensensitivität Auf welche personenbezogenen, vertraulichen, regulierten oder privilegierten Daten er zugreifen kann
Menschliche Aufsicht Wo ein Mensch prüft, freigibt, unterbricht oder rückgängig macht
Geschäftsauswirkung Welcher Schaden entstehen kann, wenn der Agent falsch, manipuliert, nicht verfügbar oder zu selbstsicher ist
Finale Risikostufe Ob der Agent niedriges, mittleres, hohes oder ohne Redesign inakzeptables Risiko hat

Das Ergebnis sollte eine kurze Risikostufe, eine Kontroll-Checkliste, benannte Verantwortliche und Nachweise sein, die in Security-, Datenschutz-, Compliance- und Architekturprüfungen wiederverwendet werden können.

Warum die Risikobewertung von Agenten anders ist

Klassische KI-Prüfungen konzentrieren sich oft auf Modell, Datensatz, vorgesehenen Zweck, Ausgabequalität, Bias, Erklärbarkeit und Datenschutz. Das bleibt wichtig.

Agenten fügen operatives Risiko hinzu.

Ein Agent kann:

  • Tools oder APIs aufrufen.
  • Dokumente oder Datenbankeinträge abrufen.
  • Delegierte Berechtigungen verwenden.
  • Gedächtnis speichern.
  • Mehrstufige Pläne ausführen.
  • Durch Hintergrund-Trigger laufen.
  • Nachrichten senden, Datensätze ändern, Tickets öffnen, Workflow-Schritte freigeben oder Kunden-, Mitarbeiter-, Finanz-, Rechts- oder Infrastrukturprozesse anstoßen.

Deshalb darf die Bewertung nicht bei "ist die Antwort korrekt?" enden. Sie muss auch fragen: "Was kann das System mit dieser Antwort tun?"

Das Risikomodell sollte Verhalten bewerten, nicht Labels. Ein Chatbot, der Agent heißt, kann niedriges Risiko haben. Ein Workflow-Assistent mit Tool-Zugriff kann hohes Risiko haben, selbst wenn er ein bekanntes Foundation Model nutzt.

Schritt 1: Mit der Use-Case-Aufnahme beginnen

Die Use-Case-Aufnahme definiert die Grenzen. Ohne sie wird der Rest der Bewertung abstrakt.

Erfassen:

  • Name des Agenten und fachlicher Owner.
  • Vorgesehener Zweck.
  • Primäre Nutzer.
  • Betroffene Kunden, Mitarbeitende, Lieferanten oder Dritte.
  • Unterstützter Geschäftsprozess.
  • Bereitstellungskanal, etwa Website, Teams, Slack, internes Portal, API oder Hintergrundworkflow.
  • Produktionstrigger, etwa Nutzerprompt, Ticket-Erstellung, E-Mail-Eingang, geplanter Job, Webhook oder Queue-Event.
  • Geplanter Launch-Umfang, etwa Pilot, interne Produktion, kundenorientiert oder unternehmensweit.
  • Support- und Incident-Owner.

Entscheidend ist Ownership. Wenn der Agent keinen verantwortlichen Business Owner, keinen Supportpfad und keinen Incident Owner hat, ist er nicht produktionsreif.

Schritt 2: Autonomie bewerten

Autonomie beschreibt, in welchem Maß der Agent entscheiden und handeln kann, ohne dass ein Mensch jeden Schritt steuert.

Eine einfache vierstufige Skala reicht meist aus.

Score Autonomiestufe Beschreibung
0 Nur Antwort Der Agent beantwortet Fragen und handelt nicht
1 Empfehlung Der Agent schlägt Aktionen vor, aber ein Mensch führt sie aus
2 Handeln mit Freigabe Der Agent kann Aktionen vorbereiten oder nach expliziter Freigabe ausführen
3 Autonom handeln Der Agent kann durch Trigger handeln oder Schritte ohne Einzelfreigabe abschließen

Fragen:

  • Kann der Agent ohne Nutzernachricht laufen?
  • Kann er mehr als einen Schritt abschließen, bevor er zu einem Menschen zurückkehrt?
  • Kann er entscheiden, welches Tool aufgerufen wird?
  • Kann er entscheiden, wann eine Aufgabe fertig ist?
  • Kann er erneut versuchen, eskalieren, delegieren oder Pläne ändern?
  • Kann er einen echten Geschäftseintrag, eine Kundenkommunikation, Zahlung, Mitarbeiterentscheidung, einen Vertrag, eine Sicherheitskontrolle oder eine Infrastruktureinstellung beeinflussen?

Hohe Autonomie ist nicht automatisch inakzeptabel. Sie bedeutet aber, dass die Kontrollumgebung stärker sein muss: klarere Grenzen, bessere Protokollierung, Freigaben für wirksame Aktionen, Monitoring und eine Möglichkeit, den Agenten schnell zu stoppen.

Schritt 3: Tool-Zugriff bewerten

Tool-Zugriff macht Agentenrisiko oft konkret. Tools sind APIs, Datenbanken, Browser, E-Mail, Ticketsysteme, CRM, ERP, HR-Systeme, Workflow-Automatisierung, Codeausführung, Dateispeicher, Zahlungssysteme und Security-Tools.

Nutze eine einfache Skala.

Score Tool-Zugriff Beschreibung
0 Keine Tools Der Agent erzeugt nur Antworten
1 Nur lesende Tools Der Agent kann Daten abrufen, aber Systeme nicht ändern
2 Begrenzte Schreibtools Der Agent kann Entwürfe, Tickets, Notizen oder wenig kritische Einträge erstellen
3 Hochwirksame Tools Der Agent kann Kunden-, Finanz-, HR-, Rechts-, Security- oder Infrastrukturzustand ändern

Für jedes Tool erfassen:

  • Tool-Name.
  • Geschäftlicher Zweck.
  • Lese- oder Schreibfähigkeit.
  • Authentifizierungsmethode.
  • Ob der Agent eine eigene Identität, ein Servicekonto oder delegierte Nutzerrechte verwendet.
  • Scopes und Berechtigungen.
  • Rate Limits und Nutzungslimits.
  • Ob das Modell Tool-Argumente auswählt.
  • Ob Tool-Ausgaben spätere Tool-Aufrufe beeinflussen können.
  • Ob eine Freigabe erforderlich ist.

Hier greift Least Privilege. Wenn der Agent nur Bestellstatus braucht, erhält er keine Rückerstattungsrechte. Wenn er nur einen Entwurf erstellen muss, darf er die Nachricht nicht senden. Wenn er nur Testdaten braucht, wird er nicht an Produktionsdaten angeschlossen.

Schritt 4: Datensensitivität bewerten

Agenten können Daten direkt offenlegen. Sie können Daten aber auch indirekt offenlegen, indem sie sie zusammenfassen, transformieren, kombinieren oder über einen anderen Kanal senden.

Score Datenstufe Beschreibung
0 Öffentlich Nur öffentliche Informationen
1 Intern Nichtöffentliche Geschäftsinformationen mit niedriger Sensitivität
2 Vertraulich oder personenbezogen Kunden-, Mitarbeiter-, Geschäfts-, Vertrags- oder Betriebsdaten
3 Eingeschränkt oder reguliert Besondere Kategorien personenbezogener Daten, Zugangsdaten, Secrets, Zahlungsdaten, Anwaltsprivileg, regulierte Akten oder sicherheitssensitive Informationen

Fragen:

  • Auf welche Datenquellen kann der Agent zugreifen?
  • Kann er Daten aus mehreren Systemen kombinieren?
  • Kann er personenbezogene Daten abrufen?
  • Kann er vertrauliche Verträge, Mitarbeiterakten, Finanzunterlagen, Quellcode, Zugangsdaten, Security-Logs oder juristisches Material abrufen?
  • Kann er Daten aus dem Ursprungssystem heraus übertragen?
  • Kann er Daten im Gedächtnis speichern?
  • Sind Aufbewahrung und Löschung definiert?
  • Sind Datenminimierung und Zweckbindung adressiert?

Wenn personenbezogene Daten betroffen sind, sollte die Bewertung mit dem Datenschutzprozess verbunden werden. Für EU-Kontexte ist die DSGVO besonders relevant für Rechtsgrundlage, Datenminimierung, Sicherheit, Meldung von Verletzungen und Datenschutz-Folgenabschätzung, wo erforderlich.

Schritt 5: Menschliche Aufsicht definieren

Menschliche Aufsicht ist nicht dasselbe wie eine Person irgendwo in der Nähe des Prozesses. Sie muss konkret genug sein, um Ergebnisse zu ändern.

Für jede wesentliche Aktion definieren:

  • Wer prüft?
  • Was sieht diese Person?
  • Welche Entscheidung kann sie treffen?
  • Kann sie ablehnen, ändern, eskalieren oder pausieren?
  • Wird die Freigabe im Audit-Log erfasst?
  • Sind Prüfer in den Grenzen des Agenten geschult?
  • Was passiert, wenn der Prüfer nicht verfügbar ist?
  • Kann ein Mensch den Agenten bei ungewöhnlichem Verhalten stoppen?

Eine Freigabe sollte erforderlich sein, wenn eine Aktion schwer rückgängig zu machen ist, Rechte oder Zugriff betrifft, Geld verändert, Beschäftigungs- oder HR-Status verändert, externe Kommunikation sendet, rechtliche oder vertragliche Einträge ändert, Security-Posture verändert oder Produktionsinfrastruktur betrifft.

Schwache Aufsicht lautet:

Ein Mensch ist im Loop.

Nützliche Aufsicht lautet:

Eine Support-Leitung muss Rückerstattungen über CHF 100 freigeben. Der Freigabebildschirm zeigt Kundenanfrage, abgerufene Richtlinie, vorgeschlagenen Betrag, Begründung, Quellbestellung, Risikoflags und Trace-ID. Freigabe oder Ablehnung wird protokolliert, bevor die Refund-API aufgerufen werden kann.

Diese Spezifität überlebt Produktion.

Schritt 6: Geschäftsauswirkung bewerten

Geschäftsauswirkung beschreibt, was passiert, wenn der Agent versagt.

Score Auswirkungsstufe Beschreibung
0 Minimal Kleine Unannehmlichkeit oder leicht korrigierbare Ausgabe
1 Niedrig Interne Nacharbeit, begrenzte Nutzerverwirrung oder geringe Betriebskosten
2 Mittel Kundenwirkung, Compliance-Nachweislücke, finanzieller Verlust, Datenoffenlegung oder Prozessstörung
3 Schwer Wesentlicher rechtlicher, finanzieller, sicherheitsbezogener, regulatorischer oder reputativer Schaden

Betrachte diese Fehlermodi:

  • Der Agent liegt falsch.
  • Der Agent ist zu selbstsicher.
  • Der Agent folgt Prompt Injection.
  • Der Agent ruft das richtige Tool mit falschen Argumenten auf.
  • Der Agent legt sensible Daten offen.
  • Der Agent überspringt erforderliche Freigaben.
  • Der Agent handelt im großen Maßstab.
  • Der Agent scheitert still.
  • Der Agent kann nicht erklären, was passiert ist.
  • Der Agent erzeugt einen Datensatz, dem nachgelagerte Systeme vertrauen.

Die schwierigste Frage ist Skalierung. Ein einzelner schlechter Entwurf ist anders als 10.000 falsche Kunden-E-Mails. Eine einzelne schlechte Empfehlung ist anders als ein autonomer Trigger, der alle paar Minuten läuft.

Schritt 7: Finale Risikostufe zuweisen

Die finale Stufe sollte einfach genug sein, damit Teams sie nutzen.

Ein praktischer Ansatz ist, Autonomie, Tool-Zugriff, Datensensitivität und Geschäftsauswirkung von 0 bis 3 zu bewerten und dann über den höchsten Score plus Red Flags die Stufe zu bestimmen.

Stufe Typisches Profil Produktionshaltung
Niedrig Nur Antworten oder Empfehlungen, geringe Sensitivität, geringe Auswirkung Standardprüfung, Owner benannt, Basis-Logging
Mittel Lesende Tools, interne oder vertrauliche Daten, begrenzte Geschäftsauswirkung Security-/Datenschutzprüfung, Zugriffskontrollen, Monitoring, Nutzerhinweise
Hoch Schreibtools, hohe Autonomie, eingeschränkte Daten, Kunden- oder regulatorische Wirkung Architekturprüfung, Freigabe-Workflow, Audit-Logging, Tests, Incident Plan, Risikoakzeptanz
Ohne Redesign inakzeptabel Irreversible hochwirksame Aktionen, übermäßige Berechtigungen, kein Owner, kein Logging, keine wirksame Aufsicht oder unklare Rechtsgrundlage Nicht launchen, bis redesignte Kontrollen vorhanden sind

Eine Formel hilft, ersetzt aber kein Urteil. Ein Agent mit geringer Autonomie und Zugriff auf Payroll-Daten braucht trotzdem starke Prüfung. Ein Agent ohne sensible Daten, aber mit Rechten zum Ändern von Firewall-Regeln, ist nicht niedriges Risiko.

Produktions-Gate-Checkliste

Vor dem Launch sollten Nachweise für die passenden Kontrollen vorliegen.

Mindestnachweise:

  • Benannter Business Owner und technischer Owner.
  • Genehmigte Use-Case-Aufnahme.
  • Inventory-Eintrag.
  • Tool-Permission-Matrix.
  • Datenklassifizierung und Datenschutzprüfung, wo nötig.
  • Design der menschlichen Aufsicht.
  • Logging- und Traceability-Plan.
  • Prompt-Injection- und Missbrauchstests für toolnutzende Agenten.
  • Monitoring- und Alerting-Plan.
  • Incident-Owner und Eskalationspfad.
  • Review-Datum und Trigger für Neubewertung.

Hochriskante Agenten sollten zusätzlich haben:

  • Architekturprüfung.
  • Explizite Risikoakzeptanz.
  • Tests der Freigabe-Workflows.
  • Red-Team-Szenarien.
  • Rollback- oder Kill-Switch-Verfahren.
  • Change Control für Prompts, Tools, Retrieval-Quellen und Policies.
  • Regeln zur Aufbewahrung von Nachweisen.

Beispiel: Customer-Support-Refund-Agent

Ein Support-Agent kann Bestellhistorie lesen, Kundenanfragen zusammenfassen, Rückerstattungsrichtlinien prüfen und Rückerstattungen vorbereiten.

Dimension Score Begründung
Autonomie 2 Er schlägt Aktionen vor und bereitet sie vor, aber Rückerstattungen benötigen Freigabe
Tool-Zugriff 3 Die Refund-API ändert Finanzdatensätze
Datensensitivität 2 Kundendaten und Bestellhistorie sind im Scope
Geschäftsauswirkung 2 Falsche Rückerstattungen oder Ablehnungen erzeugen Kunden-, Finanz- und Compliance-Wirkung

Finale Stufe: Hoch.

Erforderliche Kontrollen:

  • Refund-Tool auf minimal nötigen Scope begrenzt.
  • Schwelle für Rückerstattungsbeträge.
  • Menschliche Freigabe für Rückerstattungen über einem definierten Betrag.
  • Automatisches Blockieren ungewöhnlicher Rückerstattungsmuster.
  • Prompt-Injection-Tests mit Kundenmitteilungen und Anhängen.
  • Audit-Log für Anfrage, abgerufene Richtlinie, vorgeschlagene Entscheidung, Freigabe, Tool-Aufruf und Endergebnis.
  • Klarer Support Owner und Incident-Pfad.

Dieser Agent kann trotzdem ein guter Produktionskandidat sein. Die Bewertung soll nützliche Systeme nicht blockieren. Sie macht sichtbar, welche Kontrollen erforderlich sind, bevor das System echte Kunden und echtes Geld berührt.

Beispiel: HR-Policy-Assistent

Ein HR-Assistent beantwortet Mitarbeiterfragen aus freigegebenen Richtliniendokumenten. Er hat keine Schreibtools und keinen Zugriff auf Mitarbeiterfallakten.

Dimension Score Begründung
Autonomie 0 Er beantwortet nur Fragen
Tool-Zugriff 1 Er ruft freigegebene Policy-Inhalte ab
Datensensitivität 1 Er nutzt interne Richtlinien, keine Mitarbeiterakten
Geschäftsauswirkung 1 Falsche Antworten können Verwirrung auslösen, sollten aber an HR eskalieren

Finale Stufe: Niedrig bis Mittel, je nach Zielgruppe und Themen.

Erforderliche Kontrollen:

  • Freigegebene Wissensquellen.
  • Klarer Owner für Aktualität der Richtlinien.
  • Quellenlinks in Antworten.
  • Eskalationspfad für arbeitsrechtliche, rechtliche, Benefits- oder sensible persönliche Fragen.
  • Nutzungsprotokollierung.

Dies sollte nicht denselben Prozess durchlaufen wie ein autonomer Finanzagent mit hoher Wirkung. Gute Governance unterscheidet zwischen beiden.

Referenzbasis

Dieses Bewertungsmuster passt zu mehreren etablierten Quellen:

Die praktische Lehre ist einfach: Agentenbewertung sollte keine Modellunterlage mit neuem Titel sein. Sie sollte die tatsächlichen Fähigkeiten des Agenten mit Geschäftsauswirkung und Produktionskontrollen verbinden.

Praktische Regel

Wenn ein Agent nur antworten kann, bewerte Qualität und Datenzugriff.

Wenn ein Agent handeln kann, bewerte den Handlungspfad.

Wenn ein Agent handeln kann, ohne auf einen Menschen zu warten, bewerte das Betriebsmodell.

Und wenn niemand erklären kann, wer den Agenten verantwortet, was er tun kann, was er getan hat und wie man ihn stoppt, ist er nicht produktionsreif.