Ersetzt ein Harness die Modellbewertung?
Die Modellbewertung bleibt Teil der Systemvalidierung. Ein Harness benötigt außerdem Tests für Befugnisse, Zugriff, Aktionsausführung, menschliche Entscheidungen und Betriebsfehler.
Leitfaden
Architektur für regulierte Agent-Harnesses
Praktische Architektur für Agentenbefugnisse, Tool- und Datenumfang, Pre-Action-Policy, Validierung, menschliche Eskalation, Monitoring und Nachweise.
Für Plattformarchitekten, KI-Risikoverantwortliche und Sicherheitsteams in Finanzdienstleistungen.
Zuletzt aktualisiert: 7. Sept. 2026 · Version v1.0 · Keine Rechtsberatung.
Kurzantwort
Ein Harness für regulierte Agenten verbindet die vorgeschlagene Aktion eines Agenten mit ausdrücklicher Befugnis, begrenztem Zugriff, Policy-Bewertung, Validierung und menschlicher Eskalation und erfasst anschließend das Ausführungsergebnis. Die Referenzarchitektur von KLA gliedert diese Arbeit in sieben Kontrollen.
Architektur
Der Aktionspfad
Geschäftsverantwortliche Stelle erteilt Befugnis → Agent schlägt Aktion vor → Identitäts- und Umfangsprüfungen → Pre-Action-Policy → Validierung oder menschliche Entscheidung, wo erforderlich → kontrollierte Ausführung → Ergebnis und Nachweise.
Wenden Sie diese Abfolge auf jede folgenreiche Aktion an. Richten Sie darum Netzwerk- und Zugangsdaten-Grenzen ein und leiten Sie Betriebsfehler an den Monitoring- und Remediierungsprozess weiter.
Kontrollzuordnung
Sieben Kontrollen und ihre Verantwortlichen
Die nachstehende Produktzuordnung von KLA beschreibt relevante Oberflächen. Die Spalte zum Abnahmetest enthält einen auszuführenden Bereitstellungstest; sie behauptet weder eine Durchsetzung über die gesamte Systemlandschaft noch eine abgeschlossene Kundenverifizierung.
| Kontrolle | KLA-Zuordnung | Verantwortliche Stelle | Abnahmetest |
|---|---|---|---|
| Befugnis | Agent Registry; Identität der gesteuerten Anfrage | Plattform- und Geschäftsverantwortliche | Ein nicht erkannter Agent oder ein Agent außerhalb des zulässigen Umfangs kann die Aktion nicht ausführen |
| Tool- und Datenumfang | Tool Catalog; Data Boundaries | Plattform- und Datenverantwortliche | Anfragen zu eingeschränkten Tools, Aufzeichnungen und Tenants werden abgelehnt |
| Pre-Action-Policy | Policy Builder; KLA Policy Engine | Policy-Verantwortliche | Führen Sie allow, warn, require_approval und block auf dem integrierten Pfad aus |
| Validierung | Simulation; workflowspezifische Prüfungen | Unabhängige prüfende Person | Ungültige Ausgabe und unsichere Zustandsübergänge scheitern vor der Veröffentlichung |
| Menschliche Eskalation | Decision Desk | Autorisierte entscheidungsverantwortliche Person | Ablehnung und Ablauf verhindern die Ausführung des Pfads für genehmigte Aktionen |
| Monitoring | Assurance Center; Lineage Explorer | Betrieb und Sicherheit | Ein Kontrollfehler wird zu einem Finding mit verantwortlicher Stelle und Reaktion |
| Nachweise | Audit Trail; Evidence Room | Verantwortliche Stelle für Nachweise und Aufzeichnungen | Anfrage, Entscheidung, menschliche Prüfung und tatsächliches Ausführungsergebnis rekonstruieren |
Integration
Die Durchsetzungsgrenze definieren
Listen Sie jeden Tool-Endpunkt, jedes Credential, jede Datenquelle und jeden delegierten Agenten auf, der die ausgewählte Aktion auslösen kann. Führen Sie die gesteuerte Aktion durch den Kontrollpunkt und testen Sie alternative Pfade. Erfassen Sie jeden Pfad, der außerhalb der Durchsetzung verbleibt.
Die Host-Umgebung verantwortet Sandboxing, Netzwerkisolierung und Produktionszugriff. Eine Genehmigung muss für die konkrete Aktion gelten und bei der Ausführung gültig bleiben; legen Sie das Verhalten bei Änderungen von Parametern, Policy oder Befugnis fest.
Abnahme
Einen Fall durchgängig prüfen
Verwenden Sie einen synthetischen Fall mit einem zulässigen Lesevorgang, einer genehmigungspflichtigen Aktion und einer blockierten Operation. Prüfen Sie den nachgelagerten Zustand nach Genehmigung, Ablehnung, Ablauf und Wiederholung. Erfassen Sie Identifikatoren, Policy-Version, Identität der prüfenden Person und Ergebnis.
Führen Sie bei versiegelten Exporten auch den unabhängigen Verifier aus und bewahren Sie dessen Ergebnis auf. Ein sichtbarer Nachweis und ein erfolgreich verifiziertes Bundle liefern unterschiedliche Belege; kennzeichnen Sie jeden davon korrekt.
Kontext
Quelle und Interpretation
Dies ist der Architekturvorschlag von KLA, der durch die Harness-Notiz der Bank of England geprägt ist. Seine sieben Kontrollen sind die Gruppierung von KLA. Der begleitende Artikel erläutert die sechs Themen der Bank und den Umfang der Notiz.
FAQ
Fragen vor der Kaufentscheidung
Was kontrolliert KLA in dieser Architektur?
KLA trägt Policy, menschliche Entscheidungen und Nachweise für konfigurierte, gesteuerte Pfade bei. Prüfen Sie die Integrationsabdeckung und weisen Sie Verantwortlichkeiten für Hosting, Netzwerk, Zugangsdaten und Bewertung auf Systemebene separat zu.
Weiterführende Links
Verwandte Links
EU AI Act: Zuordnung von Agenten-Kontrollen
/guides/ai-act-standards-agent-control-mapping
Analyse zum Harness-Engineering der Bank of England
/blog/bank-of-england-ai-harness-engineering
Agenten-Kontrollen für EU-AI-Act-Standards vorbereiten
/blog/eu-ai-act-standards-agent-controls
SAFR-Laufzeit-Framework
/blog/safr-mas-framework-explained
Besprechen Sie Ihre Architektur für Agenten-Kontrollen
/book-demo
Referenzen