Die technische Notiz zum Harness-Engineering der Bank of England vom 2. September 2026 rückt das umgebende Engineering für Frontier-KI in den Mittelpunkt der praktischen Einführung. Ihr Schwerpunkt ist die Cyberabwehr. Sie berichtet über Forumsdiskussionen mit systemisch wichtigen britischen Finanzinstituten, der FCA, HM Treasury und dem NCSC und begründet keine neuen aufsichtlichen Erwartungen.
Für Teams, die Agenten für Finanzdienstleistungen entwickeln, ist unsere architektonische Lesart klar: Prüfen Sie den vollständigen Weg von der delegierten Befugnis bis zur externen Aktion. An diesem Punkt wird Modellfähigkeit zu operativer Verantwortung.
Was ist ein AI-Harness?
Ein AI-Harness ist die Software und Betriebsumgebung, die ein Modell zum Arbeiten befähigt: Kontext, Tools, Ausführungsablauf und Kontrollen. Für einen regulierten Agenten ergänzt das Design von KLA einen ausdrücklichen Nachweis darüber, wer eine Aktion autorisieren darf, welche Grenze diese Befugnis durchsetzt und welche Nachweise den Lauf überdauern.
Sechs Themen, in Architekturentscheidungen übersetzt
Die folgenden Kurzbezeichnungen fassen die sechs Themen der Bank zusammen. Die Architekturfragen in der zweiten Spalte sind die Interpretation von KLA für die Architektur regulierter Agenten.
| Zusammenfassung des Bankthemas | KLA-Architekturfrage | KLA-Zuordnung |
|---|---|---|
| Harness-Design | Wo wird jede folgenreiche Aktion geprüft? | KLA Policy Engine; Decision Desk |
| Komponentenauswahl | Wer ist für jede Kontrolle über interne Komponenten und Lieferkomponenten hinweg verantwortlich? | Tool Catalog; Provider Hub |
| Orchestrierung | Bleibt die Befugnis begrenzt, wenn Arbeit zwischen Agenten wechselt? | Processes; Agent Registry |
| Sensibler Kontext | Auf welche Tools, Aufzeichnungen und Umgebungen darf jeder Agent zugreifen? | Data Boundaries; Tool Catalog |
| Integrierte Kontrollen | Welche Entscheidungen blockieren die Ausführung oder erfordern einen Menschen? | Policy Builder; Decision Desk |
| Validierung und Skalierung | Können Prüfende Findings validieren und bei dem erwarteten Volumen Remediierungen abschließen? | Simulation; Assurance Center; Evidence Room |
Beginnen Sie mit der Aktion, die etwas verändert
Betrachten Sie einen beispielhaften Sicherheitsagenten, der eine Abhängigkeitsschwachstelle im Anwendungs-Repository einer Bank findet. Das Lesen eines genehmigten Quell-Snapshots, das Vorschlagen eines Patches und die Bereitstellung des Patches erfordern unterschiedliche Befugnisse. Definieren Sie für jede Aktion eigene Berechtigungen und weisen Sie die Produktionsänderung der für Änderungen verantwortlichen Person der Bank zu.
Eine aussagekräftige Abnahmedemonstration lässt den Agenten einen gültigen Patch vorschlagen, eine Bereitstellung außerhalb seines Mandats anfordern und auf eine abgelehnte Genehmigung stoßen. Prüfen Sie das Zielsystem nach jedem Versuch. Ein alleiniger Policy-Entscheidungsnachweis kann nicht belegen, dass ein nachgelagerter Schreibvorgang verhindert wurde.
Wo KLA einzuordnen ist
KLA Control Plane stellt Policy- und Entscheidungsnachweise für konfigurierte, gesteuerte Aktionspfade bereit. Policy Builder, die KLA Policy Engine und Decision Desk verbinden Policy-Erstellung, Aktionsbewertung und menschliche Prüfung. Tool Catalog und Data Boundaries beschreiben den gesteuerten Zugriff; Lineage Explorer und Evidence Room unterstützen Untersuchung und Nachweisprüfung.
Die Abdeckung hängt von der Integration ab. Erfassen Sie direkte SDK-Aufrufe, sekundäre Zugangsdaten, delegierte Agenten und Netzwerkpfade. Ein externer Agent, der einen uneingeschränkten alternativen Ausführungspfad behält, kann einen Kontrollpunkt umgehen. Auch Netzwerkisolierung und die Verwahrung von Zugangsdaten benötigen Kontrollen in der Host-Umgebung. Die Darstellung von KLA in einem Diagramm begründet diese Grenzen nicht.
Für eine konkrete Zuordnung verwenden Sie die Architektur für regulierte Agent-Harnesses. Sie weist jeder Kontrolle eine verantwortliche Stelle und einen Abnahmetest zu.
Eine Modelländerung sollte eine Harness-Prüfung auslösen
Wenn ein Team ein Modell ersetzt, prüfen Sie dessen verfügbare Tools, Wiederholungsverhalten, Eingabeverarbeitung, Delegation und Fehlerbehebung. Führen Sie die Tests für blockierte Aktionen und Genehmigungen mit der neuen Konfiguration erneut aus. Erfassen Sie Modell-, Tool- und Policy-Versionen, damit eine spätere Untersuchung die Konfiguration identifizieren kann, die die Aktion hervorgebracht hat.
Verfolgen Sie neben der Modellqualität auch die Prüfbelastung: offene Findings, das Alter ausstehender Genehmigungen, wiederholte Anfragen und abgeschlossene Remediierungen. Ein System, das mehr Findings erzeugt, als das Team bearbeiten kann, benötigt eine Anpassung von Umfang, Priorisierung oder Betriebskapazität.
Architektur mit der Vorbereitung auf Standards verknüpfen
Unsere EU-AI-Act-Kontrollzuordnung verknüpft dieselbe Designarbeit mit den Themen Risikomanagement, Cybersicherheit und Protokollierung. Sie dient der technischen Vorbereitung. Anwendbarkeit und Konformität erfordern eine Bewertung des konkreten KI-Systems, seiner rechtlichen Rolle, der einschlägigen Anforderungen und der tatsächlich angewandten Standards.
Die Notiz der Bank bietet einen hilfreichen Bezugspunkt für Architekturdiskussionen. Sie spricht keine Empfehlung für KLA aus und begründet keine Pflicht zum Erwerb einer Control Plane.
Häufig gestellte Fragen
Ist die Harness-Notiz der Bank of England eine neue Regulierung?
Die Notiz berichtet über technische Diskussionen und begründet keine neuen aufsichtlichen Erwartungen. Institute müssen weiterhin ihre bestehenden Pflichten und ihre eigene Bereitstellung bewerten.
Wie sollte eine Bank einen Agent-Harness bewerten?
Wählen Sie eine folgenreiche Aktion, definieren Sie deren Befugnisse und Zugriffgrenzen, testen Sie Ablehnung und menschliche Eskalation, prüfen Sie die nachgelagerte Wirkung und bewahren Sie Entscheidungs- und Ausführungsnachweise auf.