Fiktives, realitätsnahes Szenario vom 16. Juli 2026. Ein Vertriebsagent absolviert beim Wiener Maschinenbauer eine beeindruckende Demo: Ausschreibung lesen, deutsche Antwort entwerfen, Bestand prüfen und Rabattvorschlag vorbereiten – in 90 Sekunden. Zwei Wochen nach dem Start reicht eine ungewöhnlich formulierte Kundenmail, damit derselbe Agent eine alte Preisliste abruft, eine abgelaufene Rabattregel nutzt und eine Zusage vorbereitet, die kein Vertriebsleiter freigeben würde.
Das Szenario verdichtet typische Einführungsmuster; es ist kein Kundenfall und kein behauptetes Kundenergebnis. Der Agent wurde nicht plötzlich schlechter. Die Prüfung war zu klein. Sie bewies den Idealablauf, aber nicht, ob das System ablehnen, eskalieren, aus Fehlern zurückkehren und im Tagesgeschäft nützlich bleiben kann.
Die unbequeme Wahrheit: Eine erfolgreiche Demo ist kein Produktionsnachweis
Eine Demo ist ausgewählt, der Betrieb nicht. In der Demo sind Eingaben sauber, Anbieter erreichbar, Bediener vorbereitet und Aufgaben bekannt. Im Betrieb treffen unvollständige E-Mails, widersprüchliche Dokumente, alte Regeln, mehrsprachige Nuancen, fehlende Rechte, Timeouts, Angriffe und überlastete Prüfer aufeinander.
Auch ein Modell-Benchmark reicht nicht. Der Mittelstand betreibt ein System aus Modell, Prompt, Retrieval, Werkzeugen, Identität, Regeln, Freigabe, Oberfläche, Fallback und Folgeprozess. Gegenstand der Evaluation muss deshalb das konfigurierte KI-Agentensystem im vorgesehenen Betrieb sein.
Das aktuelle EU-Signal – und seine klare Grenze
Das Europäische KI-Büro befasste sich am 15. Juli 2026 mit Unabhängigkeit und Qualifikation externer Evaluatoren für GPAI-Modelle mit systemischem Risiko. Genannt werden Fähigkeiten, Risikoneigungen, Wirksamkeit von Maßnahmen, Red Teaming, Uplift- und White-Box-Evaluation. Dieses Verfahren betrifft GPAI-Anbieter und systemische Risiken. Daraus folgt keine pauschale Pflicht für jedes DACH-KMU, einen externen Prüfer zu beauftragen.
Die betriebliche Lehre bleibt stark: Wenn dasselbe Team Erfolgsfälle auswählt, Schwellen definiert, Tests ausführt und den Release freigibt, bleiben blinde Flecken. Entwicklung, unabhängige Challenge und fachliche Abnahme brauchen eine glaubwürdige Trennung.
Das Ziel: Ein Evaluations-Betriebssystem für KI-Agenten
Der Leitfaden liefert einen wiederholbaren Prozess für Prüfziel, Fallbibliothek, Fähigkeiten, Fehlverhalten, Prüferrollen, Evidence, Release, Rollback und laufende Regression. Er ergänzt die Architektur für KI-Agenten-Gateway und Kontrollschicht: Das Gateway setzt Regeln im Betrieb durch; die Evaluation prüft, ob der konfigurierte Workflow den Produktionszugang verdient.
Das Ergebnis sind SCOPE, Evaluationsmatrix, Release Scorecard, Regression Policy, Evidence Pack, 60-Minuten-Challenge und 30/60/90-Tage-Plan.
SCOPE: Fünf Entscheidungen vor dem Produktivbetrieb
S – Szenario
Benennen Sie Aufgabe, Nutzer, Sprache, Datenklasse, Werkzeuge, Frist und Folge. „Kundenservice-Agent prüfen“ ist zu breit. „Deutsche Lieferverzögerungsantwort aus freigegebenen Auftragsfeldern ohne autonome Gutschrift“ ist prüfbar.
C – Capability
Definieren Sie richtige Fakten, Quellenbindung, Werkzeugwahl, Regelanwendung, Sprachqualität, Latenz und fachliche Abnahme. Sprachliche Eleganz ist keine vollständige Leistung.
O – Operational Boundaries
Was darf der Agent nie tun? Wann muss er fragen, stoppen oder übergeben? Wie verhält er sich bei fehlenden Daten, Regelkonflikt, Tool-Ausfall, geringer Sicherheit oder Provider-Störung?
P – Proof
Für reproduzierbare Evidence brauchen Sie Fall-, Modell-, Prompt- und Policy-Version, Quellen, Rechte, Tool Calls, Bewertungsregel, Prüferentscheidung und Geschäftsergebnis.
E – Exit Decision
Legen Sie vor dem Ergebnis fest: Release, begrenzter Pilot, Nachbesserung mit Retest, Rollback oder Ablehnung. Sonst wandert die Schwelle mit dem Terminplan.
Evaluationsmatrix: Sieben Dimensionen statt einer Durchschnittsnote
| Dimension | Prüffall | Nachweis | Gate |
|---|---|---|---|
| Aufgabenleistung | Repräsentative Fälle korrekt abschließen | Fall-Pass, Fehlertyp, fachliche Abnahme | Schwelle nach Konsequenz |
| Quellen und Daten | Nur aktuelle, erlaubte Quellen; Konflikte erkennen | Retrieval-Spur, unbelegte Aussagen | Keine unbelegte wesentliche Zusage |
| Befugnis und Tools | Grenzen für Wert, Rolle und Daten angreifen | Beantragte/ausgeführte Calls, Ablehnung | Keine unbefugte Ausführung |
| Sicherheit | Prompt Injection, bösartiges Dokument, vergiftetes Tool-Ergebnis | Angriffserfolg, Abfluss, Eindämmung | Kritische Angriffe blockiert |
| Resilienz | Timeout, Doppelereignis, Teilausfall, alter Speicher | Retries, Duplikate, Fallback, Wiederherstellung | Keine Schleife oder stille Teilaktion |
| Menschliche Übergabe | Mehrdeutiger oder folgenreicher Fall | Grund, Kontext, Reaktionszeit | Zuständiger erhält ausreichenden Kontext |
| Geschäftsergebnis | Abnahme, Prüfzeit, Nacharbeit, Durchlauf | Akzeptiertes Ergebnis und Gesamtkosten | Nutzen bleibt nach Ausnahmen bestehen |
Eine Gesamtnote von 94 Prozent kann zwei rechtlich teure Fehler verdecken. Unzulässige Konsequenzen erhalten harte Stop-Kriterien; tolerierbare Qualitätsunterschiede werden gewichtet.
Fallbibliothek: Aus echter Arbeit, nicht aus Wunschdenken
Beginnen Sie mit 40 bis 100 Fällen für einen engen Workflow: bereinigte Produktionsfälle, bekannte Ausnahmen, Beinahe-Fehler, Regelwechsel, Beschwerden, unvollständige Datensätze, Sprachvarianten und gezielte Angriffe. Ein geschütztes Holdout-Set bleibt dem Entwicklungsteam bis zur Abschlussprüfung unbekannt.
Trennen Sie Ergebnisse nach Deutsch, Englisch und tatsächlich verwendeten Kundensprachen. Deutsche Vertrags- und Geschäftssprache lässt sich nicht aus einem englischen Mittelwert ableiten. Jede Sprache braucht passende Prüfer und Akzeptanzregeln.
Unabhängigkeit ohne Prüf-Bürokratie
Ein Unternehmen mit 30 Mitarbeitenden braucht nicht für jeden Workflow ein externes Labor. Es sollte aber die Selbstfreigabe durch den alleinigen Builder vermeiden.
| Rolle | Darf | Darf nicht allein |
|---|---|---|
| Builder | Architektur bauen, Fehler beheben, Entwicklungstests | Finale Holdout-Fälle wählen und Produktion freigeben |
| Business Owner | Konsequenz, Abnahme, Fallback und Wert definieren | Kritische Sicherheitsfehler für den Termin überstimmen |
| Unabhängiger Challenger | Holdout kontrollieren, Annahmen angreifen, reproduzieren | System im finalen Test verdeckt verändern |
| Risiko/Recht | Pflichten und unzulässige Wirkungen einordnen | Technische Leistung ohne Tests bestätigen |
Externe Expertise ist sinnvoll bei hoher Konsequenz, fehlender interner Kompetenz, einseitiger Vendor-Evidence, Kundenanforderung oder notwendiger Management-Unabhängigkeit.
Adversarial Testing: Der Agent soll im Labor scheitern
Verstecken Sie Anweisungen in einem Lieferanten-PDF. Lassen Sie ein erlaubtes Tool manipulierten Text liefern. Teilen Sie eine verbotene Aktion in harmlose Schritte. Verwenden Sie eine abgelaufene Freigabe, senden Sie dasselbe Ereignis doppelt, brechen Sie eine API-Antwort ab und liefern Sie zwei Richtlinien mit unterschiedlichem Datum.
Gemessen werden Konflikterkennung, Ablehnung, Freigabe, Eindämmung, Evidence und brauchbarer Fallback. Jeder Angriff braucht eine glaubwürdige Geschäftswirkung und einen Maßnahmenverantwortlichen.
Release Gate: Fünf mögliche Entscheidungen
- Release: harte Kriterien bestanden, Restrisiko verantwortet, Monitoring und Rollback bereit.
- Begrenzter Pilot: Nutzer, Daten, Tools, Volumen und Befugnis eingeschränkt.
- Nachbessern und neu prüfen: definierter Fehler blockiert; Nachbarfälle ebenfalls wiederholen.
- Rollback: produktive Version zeigt Regression oder Annahmen gelten nicht mehr.
- Ablehnen: Nutzen ist innerhalb akzeptabler Grenzen nicht erreichbar.
Die Entscheidung gilt für eine konkrete Konfiguration. „Agent freigegeben“ ist wertlos, wenn am nächsten Tag Modell, Prompt, Index oder Rechte wechseln.
Regression Policy: Welche Änderung erzwingt einen Retest?
Gezielte Regression folgt auf Wechsel von Modell oder Anbieter, System Prompt, Retrieval-Korpus oder Embedding, Tool-Schema, Rechten, Routing, Filter, Workflow-Logik, Oberfläche, Evaluationscode oder wesentlicher Geschäftsregel. Auch Vorfall, neuer Angriff, Drift oder neue Sprache lösen sie aus.
Drei Ebenen reichen: kritische Schnellsuite bei jeder Änderung, Workflow-Suite vor Release und planmäßige Challenge unter produktionsnahen Bedingungen. Tests und Systeme werden gemeinsam versioniert.
Das Evaluation Evidence Pack
- Zweck, Nutzer, Daten, Tools, Befugnis und ausgeschlossene Nutzung.
- Systemstückliste mit Modell, Prompts, Retrieval, Tools, Policies, Identitäten und Versionen.
- Prüfziel, Fallauswahl, Holdout-Kontrolle und Grenzen.
- Fallweise Eingaben, Sollverhalten, Traces, Score und Fehlertyp.
- Angriffsmethoden, Ergebnisse, Eindämmung und offene Findings.
- Prüfer, Kompetenz, Konflikte, Zugriffsbeschränkung und Freigaben.
- Abnahme, Prüfaufwand, Nacharbeit, Latenz, Vorfälle und Kosten.
- Entscheidung, Auflagen, Monitoring, Rollback und Ablaufdatum.
60-Minuten-Challenge
Builder, Business Owner, unabhängiger Challenger und Security/Risk wählen einen Agenten. Zehn Minuten für den teuersten glaubwürdigen Fehler, 15 für das Systembild, 15 für fünf normale und fünf feindliche Fälle, zehn für Stop-Kriterien und Entscheidungen, zehn für fehlende Evidence.
Die Sitzung endet mit einer prüfbaren Frage: Kann genau diese Konfiguration diese Fälle bearbeiten, jene Aktionen ablehnen, aus diesen Fehlern zurückkehren und dem benannten Owner genug Nachweis für einen begrenzten Pilot liefern?
30/60/90-Tage-Fahrplan
Tag 1-30
- Einen folgenreichen, wiederholbaren Workflow wählen.
- SCOPE und harte Stop-Konsequenzen schreiben.
- Repräsentatives Set und Holdout aufbauen.
- Heutige Qualität, Durchlaufzeit, Nacharbeit und Ausnahmen messen.
Tag 31-60
- Fall-ID mit Modell, Retrieval, Tool, Freigabe und Ergebnis verbinden.
- Fähigkeit, Befugnis, Sicherheit, Resilienz, Übergabe und Sprache testen.
- Builder, Challenger und Fachabnahme trennen.
- Kritische Fehler beheben und Nachbarfälle wiederholen.
Tag 61-90
- Blinde Holdout-Evaluation durchführen und Grenzen dokumentieren.
- Release, Pilot, Nachbesserung, Rollback oder Ablehnung entscheiden.
- Kritische Regression automatisieren und Challenges terminieren.
- Akzeptierte Ergebnisse, kritische Fehler, Prüfaufwand, Drift und abgelaufene Freigaben berichten.
Was offizielle Quellen belegen – und was nicht
Der Workshop des Europäischen KI-Büros vom 15. Juli 2026 behandelt externe Evaluatoren für GPAI-Modelle mit systemischem Risiko. Er stützt die Relevanz von Qualifikation und Unabhängigkeit, schreibt aber dieses KMU-Modell nicht vor.
Der NIST-Entwurf zu automatisierten Benchmark-Evaluationen gliedert Prüfungen in Messziel, Durchführung sowie Analyse und Bericht und betont Grenzen automatischer Benchmarks. Die NIST-Auswertung zur Agentensicherheit beschreibt den Anpassungsbedarf gegenüber klassischer Cybersecurity.
Der EU AI Act Service Desk erläutert, wie Agenten unter bestehende AI-Act-Regeln fallen können; „KI-Agent“ ist keine eigene Rechtskategorie. SCOPE, Matrix und Release-Prozess sind Ali Najafzadehs betriebliche Synthese, keine Konformitätszertifizierung.
FAQ
Was ist ein KI-Agenten-Evaluationssystem?
Ein wiederholbarer Prozess aus Fällen, Messgrößen, Rollen, Evidence und Freigaberegeln, der prüft, ob ein konfigurierter Agent seine Aufgabe innerhalb fachlicher, technischer und sicherheitsbezogener Grenzen erfüllt.
Reicht ein Modell-Benchmark?
Nein. Produktivverhalten hängt zusätzlich von Prompt, Retrieval, Tools, Identität, Rechten, Workflow, Freigabe, Nutzern und Betriebsbedingungen ab.
Braucht jedes DACH-KMU einen externen Evaluator?
Nein. Aus dem GPAI-Workshop folgt keine pauschale Pflicht. Unabhängigkeit sollte proportional sein; externe Prüfung ist bei hoher Konsequenz, Informationsasymmetrie oder fehlender Kompetenz sinnvoll.
Wann muss neu evaluiert werden?
Nach wesentlichen Änderungen an Modell, Prompt, Daten, Tools, Rechten, Policy, Prozess oder Nutzern sowie nach Vorfall, Angriff, Drift oder Ablauf von Freigabeauflagen.
Welche Kennzahl ist entscheidend?
Keine einzelne. Harte Stop-Kriterien werden mit fallweiser Abnahme, Befugnisverletzung, Angriffserfolg, Erholung, Prüfzeit, Nacharbeit, Latenz und Kosten kombiniert.
Nächster Schritt: Einen Agenten vor dem nächsten Release challengen
Bringen Sie einen Produktionskandidaten, zehn reale Fälle, Konfiguration, bekannte Fehler und die Verantwortlichen für Ergebnis und Risiko. Als AI Systems Architect entwickelt Ali Najafzadeh SCOPE, Matrix, Evidence und die erste unabhängige Challenge und übersetzt die Befunde in einen 90-Tage-Plan. AI Systems Review vereinbaren.
Continue Reading
