Verantwortungsvolle KI, Sicherheit & Risiko für Architekten — Claude Certified Architect Professional Prep Course

Screen 1: Der Sicherheits-Stack: Wer besitzt welche Schicht und was passiert, wenn eine ausfällt

ORIENTIERUNG MODUL 2 MIN Der Sicherheits-Stack: Wer besitzt welche Schicht und was passiert, wenn eine ausfällt

Die früheren Module endeten mit einem operativen Produktionssystem: Jeder Schritt eines Partner-Problems wurde dem richtigen Eigentümer zugewiesen, eine Referenzarchitektur und ein Modell wurden ausgewählt, der Use Case wurde dimensioniert, Evals wurden als Akzeptanzkriterien erstellt, und die Integrations-Layer wurden eingerichtet, um Claude in einen Enterprise-Stack einzubetten.

Dieses Modul behandelt die wichtigste Sicherheitsfrage: Welche Kontrollen sind vorhanden, um zu verhindern, dass ein System eine gültige Anfrage ablehnt, ein unfaires Ergebnis liefert oder eine Aktion durchführt, die niemand genehmigt hat? Sicherheit ist ein vollständiger Satz von Kontrollen, die jeweils einen anderen Teil des Anfragepfads abdecken, jede mit einem blinden Fleck, den die nächste abfangen muss. Der Architect ist verantwortlich für die Platzierung jeder Kontrolle und die Entscheidung, was zu tun ist, wenn sie ausfällt.

Am Ende dieses Moduls können Sie: 1 Unterscheiden zwischen dem, was das Training des Modells reduziert, und dem, was Ihre Anwendungsschicht noch durchsetzen muss. 2 Input-Screening, Output-Screening und Tool-Call-Autorisierung an den richtigen Stellen im Anfragepfad platzieren und bestimmen, wann modellbasierte versus deterministische Checks verwendet werden, damit das System geschlossen statt offen ausfällt. 3 Identifizieren, wo ungleiche Ergebnisse innerhalb eines Systems entstehen können, und definieren Sie die erforderlichen Erklärungen für Benutzer, Regulatoren und Ihr eigenes Debugging-Team, damit Fairness und Transparenz in das Design eingebaut sind. 4 Entscheidungen basierend auf Konfidenz, Reversibilität und den Kosten einer falschen Antwort an den entsprechenden Reviewer/Entscheidungsträger weiterleiten, damit der Review-Aufwand auf die Entscheidungen konzentriert wird, die ihn verdienen. 5 Jede Compliance-Verpflichtung einer benannten Kontrolle, einem Eigentümer und einem Beweis-Artefakt zuordnen, damit die Architektur genau überprüft werden kann.

Dieses Modul ist für den Architect, der bereits ein funktionierendes System gebaut hat: Eigentümerschaft zugewiesen, Architektur gewählt, Evals erstellt und Claude in einen Enterprise-Stack verdrahtet. Claude kommt mit breitem Sicherheitsverhalten, aber es kennt nicht die Datenbehandlungsregeln des Partners, sein Autorisierungsmodell oder seine Domain-Policy. Anzunehmen, dass Claude eine Regel durchsetzt, die ihm nie gegeben wurde, ist die häufigste Art, wie ein Sicherheitsdesign fehlschlagen kann.

Alles in diesem Modul ist um einen Kontext herum aufgebaut: ein System, das jede Architektur-Review besteht und trotzdem in der Produktion fehlschlägt. Die Verantwortungsschicht war unvollständig, angenommen oder zum Designzeitpunkt korrekt, aber zum Zeitpunkt der Überprüfung falsch. Die Partner sind Enterprise-Käufer in regulierten Umgebungen, wo eine Kontrolle, die in einer Demo solide aussieht, zu einem Audit-Finding wird, wenn Konfigurationen abweichen oder ein Reviewer nach Beweisen fragt, dass die Kontrolle läuft.

DIE ENTSCHEIDUNGEN ORDNEN SICH DEN FOLGENDEN ABSCHNITTEN ZU

Die Alignment-Grenze ist der Ort, an dem Sie die Linie zwischen dem ziehen, was das Training des Modells bereits reduziert, und dem, was Ihre Anwendungsschicht noch durchsetzen muss. Anzunehmen, dass trainierte Alignment eine Domain-Policy abdeckt, lässt die Regel in jeder Schicht unenforced. Das Modul beginnt hier, weil dies jede nachgelagerte Entscheidung beeinflusst.

Guardrail-Platzierung ist der Ort, an dem Sie Input-Screening, Output-Screening und Tool-Call-Autorisierung im Anfragepfad positionieren, wählen, ob jeder Check modellbasiert oder deterministisch ist, und entscheiden, was die Kontrolle tut, wenn sie ausfällt. Ein einzelner Filter am Ende des Pfads deckt die anderen zwei Punkte nicht ab, und eine Kontrolle, die offen ausfällt, ist schlimmer als keine Kontrolle, weil sie den Anschein von Schutz bietet, ohne eine der Funktionen zu haben.

Fairness und Transparenz ist der Ort, an dem Sie identifizieren, wo ungleiche Ergebnisse in das System eindringen können, und wo Sie das Logging erstellen, das es Ihnen ermöglicht, jede Entscheidung später zu erklären. Die vier Injektionspunkte sind Ihre, um sie zu instrumentieren.

Human-Review-Routing ist der Ort, an dem Sie entscheiden, welche Entscheidungen eine Person wiegen sollte, und was dieser Reviewer tun muss, um seinen Job zu machen. Einfaches Routing nach Volumen überschwemmt die Warteschlange und zwingt oft Reviews, in Genehmigungen zusammenzubrechen. Die Entscheidungen, die Aufmerksamkeit verdienen, sind diejenigen mit hohem Einsatz und niedriger Konfidenz, und diese Einsätze müssen vorher identifiziert werden.

Das Compliance-Control-Register ist der Ort, an dem jede Verpflichtung zu einer identifizierten Kontrolle, einem verantwortlichen Eigentümer und einem Beweis-Artefakt wird, das ein Reviewer inspizieren kann. Die Wahl eines konformen Einstiegspunkts ist eine Voraussetzung. Eine Kontrolle ohne Eigentümer und ohne lebendes Artefakt kann nicht operativ werden, ohne dass es jemand bemerkt, und erscheint dann als Lücke während einer Überprüfung.

Diese Themen bauen aufeinander auf. Die Grenze, die Sie im ersten Abschnitt ziehen, wird durch die Kontrollen im zweiten durchgesetzt, das Logging, das Sie für Fairness erstellen, ist das gleiche Logging, das der Reviewer im vierten Abschnitt verwendet, und das Control-Register im fünften Abschnitt zieht aus jeder instrumentierten Schicht oben. Die kumulative Aufgabe am Ende fordert Sie auf, alle fünf aus einem einzelnen Brief in eine verteidigbare Bereitstellung zusammenzusetzen, was genau das ist, wofür dieses Modul Sie vor einem Sicherheits-Reviewer oder Compliance-Auditor ausrüstet.

HAFTUNGSAUSSCHLUSS / HINWEIS FÜR BILDUNGSINHALTE

Wir haben diesen Architect-Kurs Modul 3: Verantwortungsvolle KI, Sicherheit und Risiko für Architekten erstellt, um Ihnen bei echter Arbeit mit Claude zu helfen. Behandeln Sie ihn als Bildungsinhalte. Er stellt keine rechtliche, finanzielle oder andere professionelle Beratung dar, daher passen Sie das Gelernte an Ihre Situation an. Unsere Produkte und Dienstleistungen entwickeln sich schnell, daher können bestimmte Inhalte Fehler enthalten oder veraltet sein; denken Sie daran, auf der Website oder Dokumentation von Anthropic zu überprüfen. Beispiele und Szenarien, die im Kurs verwendet werden, sind illustrativ und oft fiktiv. Wenn der Kurs-Inhalt ein Unternehmen oder Produkt erwähnt, bedeutet das nicht, dass Anthropic es unterstützt, sie Anthropic unterstützen oder dass wir verbunden sind. Beachten Sie auch, dass Ihre Nutzung von Anthropic-Produkten und -Dienstleistungen durch unsere Bedingungen, Richtlinien und Dokumentation abgedeckt ist; wenn etwas in diesem Kurs damit in Konflikt steht, haben diese Vorrang.

Screen 2: Was das Training des Modells durchsetzt versus was Sie besitzen

TeachingAlignment11 min Was das Training des Modells durchsetzt versus was Sie besitzen Frühere Arbeiten etablierten die Architektur, das Modell und die Integration. Hier beantworten wir: Bevor Sie anfangen, Kontrollen hinzuzufügen, wie viel sicheres Verhalten wird bereits vom Modell behandelt, und wie viel ist noch Ihre Aufgabe? Sie müssen diese Grenze klar verstehen, um doppelte Schutzmaßnahmen zu vermeiden oder anzunehmen, dass das Modell eine Regel durchsetzt, die es nie gesehen hat.

Anthropic trainiert Claude gegen eine Verfassung: ein schriftliches Dokument, das die Werte und das Verhalten beschreibt, das das Modell zeigen sollte, damit das Modell mit breitem Sicherheitsverhalten bereits vorhanden ist. Anthropic überarbeitet dieses Dokument im Laufe der Zeit, und die neueste veröffentlichte Version stammt von Januar 2026. Das Dokument wird während des Trainings verwendet, um Beispiele zu generieren, die das Modell lernt, und um Kandidaten-Antworten zu bewerten. Dies formt, wie das Modell auf mehrdeutige oder sensible Anfragen reagiert, fängt aber nicht unbedingt schlechte Ausgaben ab. Es setzt eine Prioritätsreihenfolge für das Modell fest, die befolgt werden soll, wenn Ziele in Konflikt geraten: sei breit sicher, sei ethisch, befolge Richtlinien und sei genuinely hilfreich für Operatoren und Benutzer. Diese Reihenfolge ist wichtig, weil eine hilfreiche Antwort manchmal unsicher ist. Die Reihenfolge ist holistisch statt streng, daher haben höher priorisierte Ziele im Allgemeinen Vorrang, wenn sie in Konflikt geraten, obwohl das Modell sie zusammen abwägt, statt sie in einer starren Reihenfolge anzuwenden. Das Modell kommt mit einer Klasse von schädlicher Ausgabe an, die bereits reduziert ist, bevor Sie einen einzigen Prompt schreiben. Die eingebaute Schicht behandelt breite, allgemeine Schäden, deckt aber nicht Ihre spezifische Domain ab: alle Richtlinien, die spezifisch für Ihre Benutzer und Ihr Produkt sind, sind noch Ihre Aufgabe durchzusetzen.

Training-Zeit-Alignment und Inference-Zeit-Kontrolle sind zwei Schichten mit unterschiedlichen Zwecken Training-Zeit-Alignment formt das Modellverhalten vor der Bereitstellung. Es reduziert breite Klassen von schädlicher Ausgabe, indem es Claude steuert, gefährliche Anfragen abzulehnen und sicherer zu reagieren. Weil es vor jeder Bereitstellung gesetzt wird, ist es von Natur aus allgemein. Dies ist sowohl eine Stärke als auch eine Schwäche: Es kennt nicht die Domain-Policy des Partners, seine Datenbehandlungsregeln oder sein Autorisierungsmodell. Eine Anfrage kann Claudes allgemeines Alignment erfüllen und trotzdem eine bereitstellungsspezifische Regel verletzen, wie das Offenlegen von Bestellinformationen eines anderen Kunden oder das Beraten außerhalb eines genehmigten Skripts. Denken Sie daran, Claude kann eine Regel nicht durchsetzen, die ihm nie gegeben wurde. Bereitstellungsspezifische Regeln werden durch die zweite Schicht durchgesetzt: Inference-Zeit-Kontrolle. Dies umfasst die Runtime-Guardrails, die Sie für Ihre Bereitstellung konfigurieren, wie Systeminstruktionen, Input- und Output-Checks, Tool-Berechtigungen und Human-Review-Gates. Systeminstruktionen formen das Modellverhalten, aber bereitstellungsspezifische Policy wird nur durchgesetzt, wenn diese Anweisungen mit Runtime-Kontrollen wie Screening, Autorisierung und Review gepaart werden. Training-Zeit-Alignment senkt das Baseline-Risiko, und Inference-Zeit-Kontrolle durchsetzt die Regeln, die spezifisch für Ihre Bereitstellung sind.

Eine geschichtete Ansicht: Jede Schicht hat eine Aufgabe und einen blinden Fleck Behandeln Sie Sicherheit als vier Schichten, die von Claude nach außen gestapelt sind. Jede deckt etwas ab, das die Schicht darunter nicht kann, und jede fällt auf eine Weise aus, die die nächste abfangen muss. Wählen Sie jede Schicht, um zu sehen, was sie zuverlässig abdeckt, was nicht, und wer sie besitzt.

Trainiertes Verhalten System-Prompt-Anweisung Runtime-Screening Autorisierung

Was es zuverlässig abdeckt: Breite Klassen von schädlicher oder unsicherer Ausgabe, angewendet auf jede Anfrage ohne Konfiguration. Was es nicht abdeckt: Ihre Domain-Policy, Ihre Datenregeln, Ihr Autorisierungsmodell. Wer es besitzt: Anthropic.

Was es zuverlässig abdeckt: Rolle, Ton und angegebene Einschränkungen, die Claude innerhalb einer Anfrage steuern. Was es nicht abdeckt: Alles, das eine gegnerische oder ungewöhnliche Eingabe Claude ausreden kann, da Anweisungen keine Durchsetzung sind. Wer es besitzt: Architect.

Was es zuverlässig abdeckt: Input- und Output-Screening, das unzulässige Inhalte erkennt. Was es nicht abdeckt: Aktionen mit Nebenwirkungen, die Screening nicht autorisiert, und neuartige Angriffe, die ein Klassifizierer verpasst. Wer es besitzt: Architect.

Was es zuverlässig abdeckt: Ob eine bestimmte Aktion mit Nebenwirkung für diesen Aufrufer in diesem Kontext zulässig ist. Was es nicht abdeckt: Inhaltsqualität und Fairness. Wer es besitzt: Architect.

Kosten · Komplexität · Risiko Kosten: Jede hinzugefügte Schicht kostet Latenz und Engineering. Ein Pre-Screen auf Input und ein Check auf Output fügen zwei zusätzliche Aufrufe oder Regeln zu jeder Anfrage hinzu. Komplexität: Vier Schichten bedeuten vier Orte zum Entwerfen, Versionieren und Testen. Der System-Prompt und die Screening-Logik driften unabhängig, wenn nicht gesteuert. Risiko: Der gefährlichste Fehler ist ein stiller: Anzunehmen, dass Claude eine Domain-Regel durchsetzt, die ihm nie gegeben wurde. Da die Regel in keiner Schicht existiert, verhindert nichts eine Verletzung.

Screen 3: Wenn trainierte Ablehnungen mit einer Domain-Policy verwechselt werden

Watch OutAlignment3 min Wenn trainierte Ablehnungen mit einer Domain-Policy verwechselt werden

Setup-Hook Sie sind ein starker Systems-Architect. Claude lehnt bereits breite schädliche Anfragen in Tests ab, daher nehmen Sie an, dass sein Training auch die Datenbehandlungs-Policy Ihres Partners abdeckt. Sie gehen weiter, ohne eine separate Durchsetzungsschicht zu erstellen.

Eine Postmortem: eine Policy, die in keiner Schicht kodiert wurde Ein Team stellte einen internen Assistenten für einen Partner bereit, dessen Datenbehandlungs-Policy Benutzern untersagte, auf Datensätze zuzugreifen, die anderen Geschäftsbereichen gehörten. Bei der Überprüfung hatte Claude jede schädliche Anfrage abgelehnt, die das Team auf es warf, daher nahmen sie an, dass Cross-Unit-Offenlegung durch das gleiche Sicherheitsverhalten abgedeckt wurde und erstellten nie einen Autorisierungs-Check dafür. In der Produktion fragte eine normal aussehende, In-Domain-Anfrage nach einem verbotenen Datensatz. Nichts in der Anfrage sah in allgemeinen Begriffen schädlich aus, daher beantwortete Claude sie. Die Regel, die das Team glaubte, durchgesetzt zu werden, existierte tatsächlich nicht. Sie war nie Teil von Claudes Training, und das Team kodierte sie nie in einem Klassifizierer, System-Prompt oder einer Anwendungs-Kontrolle, weil sie annahmen, dass das Modell sie bereits abdeckte.

Warum dies brach Eine Domain-Policy wurde mit trainiertem Alignment verwechselt. Trainierte Ablehnungen decken breite Schäden ab, nicht bereitstellungsspezifische Regeln. Jede Regel, die spezifisch für Ihren Partner ist, muss in einer Schicht durchgesetzt werden, die Sie erstellen. Denken Sie daran, Claude kann nicht durchsetzen, was ihm nie gegeben wurde.

Screen 4: Sortieren Sie die Verantwortung

CheckpointAlignment3 min Sortieren Sie die Verantwortung Versuchen Sie es jetzt. Sie überprüfen das Sicherheitsdesign für einen Claude-Assistenten eines Partners. Ziehen Sie jede Verpflichtung in den Eimer, der sie durchsetzen sollte: entweder Claudes trainiertes Verhalten oder die Anwendungsschicht. Das Feedback erklärt, warum jede dort landet.

Ablehnung, bei der Synthese einer gefährlichen Waffe zu helfen Niemals Daten eines anderen Mieters zurückgeben Ablehnung, offensichtlich hasserfüllte Inhalte zu produzieren Blockierung von Ratschlägen außerhalb des genehmigten Skripts des Partners Erforderliche Genehmigung vor einer Rückerstattung

Claudes trainiertes Verhalten

Anwendungsschicht (Sie besitzen sie)

Antworten überprüfen Jetzt überspringen

Screen 5: Risiken, Einschränkungen und Fehlermodi von LLM-Systemen

TeachingGuardrails9 min Risiken, Einschränkungen und Fehlermodi von LLM-Systemen Sie haben die Kontrollen platziert; identifizieren Sie jetzt, wogegen sie sich verteidigen. Von einem Architect wird erwartet, dass er eine Risikobewertung für ein vorgeschlagenes System als Teil einer Sicherheits-Lieferung durchführt und dokumentiert. Dieser Screen behandelt die Risiko-Kategorien, die in LLM-Systemen wiederkehren, und verwandelt sie in eine schriftliche Bewertung, die Sie durchführen können.

Die Risiko-Kategorien, die in LLM-Systemen wiederkehren Die meisten LLM-System-Risiken fallen in eine kleine Menge von Kategorien. Identifizieren Sie diese Kategorien und überprüfen Sie Ihre Designs gegen jede:

Direkte Prompt-Injection: Ein Benutzer erstellt eine Eingabe, die die Anweisungen des Systems überschreibt und sein Verhalten umleitet. Indirekte Prompt-Injection: Böswillige Anweisungen kommen durch abgerufene Inhalte oder Tool-Ausgaben an, die das Modell als vertrauenswürdig behandelt und die Vektor-Input-Screening nicht abfängt. Token-Budget-Erschöpfung: Übergroße oder gegnerisch aufgefüllte Eingaben verbrauchen das Kontext- oder Output-Budget, verkürzen die Arbeit oder erhöhen die Kosten. Tool- und Action-Missbrauch: Das Modell wird induziert, ein Side-Effecting-Tool außerhalb der Policy aufzurufen, der Fehler, den die Action-Autorisierungs-Kontrolle verhindern soll. Daten-Exposition: Sensible Felder treten in das Kontext-Fenster oder die Logs ein, wo sie nicht sein sollten, was zu einem Leak unabhängig vom Modellverhalten führt.

System-Schwachstellen-Bewertung: Wo zu schauen ist Gehen Sie die Anfrage- und Datenpfade zusammen. An jedem Einstiegspunkt, Benutzer-Input, abgerufene Inhalte, Tool-Ausgaben, die Ausgabe des Modells selbst und die Logs, fragen Sie, was ein Gegner tun könnte und welche Kontrolle im Weg steht. Suchen Sie nach überall ohne Kontrolle, wo es einen plausiblen Angriff geben könnte.

Dokumentieren der Risikobewertung als Lieferung Die Risikobewertung sollte ein schriftliches Artefakt sein. Für jedes identifizierte Risiko zeichnen Sie die Kategorie, die betroffene Komponente, ein Wahrscheinlichkeits- und Auswirkungsurteil und die Mitigations-Kontrolle mit einem Eigentümer und einem Beweis-Artefakt auf. Dieses Dokument ist das, das der Sicherheits-Reviewer unterzeichnet, und es ist das, das die kumulative Übung am Ende dieses Moduls von Ihnen erwartet, dass Sie es produzieren können.

Screen 6: Bewerten Sie die Risiken in einer vorgeschlagenen Architektur

CheckpointGuardrails4 min Bewerten Sie die Risiken in einer vorgeschlagenen Architektur Versuchen Sie es jetzt. Sie überprüfen eine vorgeschlagene Architektur: einen Kundenservice-Agenten, der Antworten aus einer Partner-Wissensdatenbank abruft und Rückerstattungen durch ein verbundenes Tool ausgibt, mit allen Aktivitäten in einem Request-Log geschrieben. Identifizieren Sie mindestens drei Risiko-Kategorien in diesem Design, und nennen Sie für jede eine funktionierende Mitigation. Sowohl das Risiko als auch eine Mitigation, die es adressiert, sind erforderlich.

Identifizieren Sie die Risiko-Kategorien in diesem Design und paaren Sie jede mit einer Mitigation.

Modell-Antwort anzeigen Jetzt überspringen

Modell-Antwort

Indirekte Prompt-Injection über die Wissensdatenbank. Abgerufene Inhalte können Anweisungen tragen; Mitigation ist, abgerufenen Text als nicht vertrauenswürdig zu behandeln und Tool-/Inhalts-Eingaben zu screenen, nicht nur Benutzer-Input.
Tool- und Action-Missbrauch auf dem Rückerstattungs-Tool. Mitigation ist ein Action-Autorisierungs-Check, der vor der Rückerstattungs-Tool-Ausführung läuft, unabhängig von der Modell-Ausgabe.
Token-Budget-Erschöpfung auf großen Wissensdatenbank-Dokumenten. Mitigation ist Chunking und Input-Limits plus Budget-Überwachung, damit ein großes Dokument die Arbeit nicht stillschweigend verkürzt.
Daten-Exposition im Request-Log. Mitigation ist Server-seitige Redaktion von sensiblen Feldern, bevor etwas geloggt wird.

Screen 7: Platzieren Sie Screening und Autorisierung, damit das System sicher degradiert

TeachingGuardrails14 min Platzieren Sie Screening und Autorisierung, damit das System sicher degradiert Eine Kontrolle, die Anfragen screent, kann auf die gleiche Weise ausfallen wie jede Abhängigkeit ausfällt. Sie kann timeout, einen Fehler zurückgeben oder unter Last unerreichbar werden. Der Unterschied ist, dass ein fehlender Guardrail immer noch gesund aussehen kann: Wenn ein Screening-Service fehlschlägt, aber trotzdem Traffic durchlässt, fließen Anfragen weiter, während die Kontrolle keine der Arbeiten macht, für die sie dort war. Wenn also ein Guardrail fehlschlägt, muss das System eines von zwei Dingen tun: es durchlassen oder blockieren. Wenn Sie diese Wahl nicht explizit getroffen haben, entscheidet der umgebende Code für Sie. Der Standard ist fast immer, die Anfrage durchzulassen, was bedeutet, auf den ungeschützten Pfad zurückzufallen. Die gleiche Überlegung, die Retries und Circuit Breaker um Ihre Modell-Aufrufe legte, gilt hier: Entscheiden Sie, wie sich die Kontrolle verhält, wenn sie ausfällt, statt das Verhalten zu erben, das zufällig Anfragen fließen lässt.

Wo Guardrails in einem Anfragepfad sitzen Ein bewachter Anfragepfad hat ein paar Entscheidungspunkte, die jeweils eine andere Frage beantworten.

Input-Screening läuft vor dem Modell-Aufruf und entscheidet, ob die Anfrage das Modell überhaupt erreichen sollte. Output-Screening läuft vor der Antwort, die den Benutzer erreicht, und entscheidet, ob das, was das Modell produziert hat, sicher zurückzugeben ist. Tool-Call-Autorisierung läuft vor jeder Aktion mit Nebenwirkungen, wie das Senden einer E-Mail, das Schreiben in eine Datenbank oder das Ausstellen einer Rückerstattung, und bestimmt, ob dieser Aufrufer diese Aktion in diesem Kontext durchführen darf.

Weil sie an verschiedenen Orten sitzen und verschiedene Dinge überprüfen, tut eine Kontrolle an einem Ort nichts für die anderen, weshalb ein einzelner Filter nicht den ganzen Pfad abdecken kann.

Wo jeder Check passt: modellbasiert vs deterministisch nach Entscheidungspunkt EntscheidungspunktEin modellbasierter Check ist nötig, wennEin deterministischer Check ist besser, wenn

Input-Screening (vor dem Modell-Aufruf)Die Absicht ist mehrdeutig und Sie fangen Jailbreak- oder Prompt-Injection-Muster ab, die nicht erschöpfend mit Regeln erfasst werden können. Ein leichtes Modell klassifiziert die Eingabe. Die Regel ist klar und definiert: eine Blocklist, ein Regex, ein Längen- oder Format-Check. Es ist schneller, vorhersehbar und kann nicht aus seiner Entscheidung geredet werden. Output-Screening (vor der Antwort, die den Benutzer erreicht)Sie bewerten Qualitäten wie Toxizität oder Policy-Compliance, die Sprachverständnis brauchen. Ein Judge-Modell bewertet die Ausgabe. Sie überprüfen auf einen bekannten String, ein verbotenes Feld oder eine Schema-Verletzung, die ein Validator mit Sicherheit abfängt. Tool-Call-Autorisierung (vor jeder Side-Effecting-Aktion)Selten. Autorisierung sollte deterministisch sein, damit sie überprüfbar ist. Fast immer: eine Allowlist von zulässigen Aktionen, Identitäts-Checks und Scope-Validierung. Autorisierung muss eine Entscheidung sein, die Sie beweisen und wiedergeben können, daher muss sie deterministisch sein.

Warum modellbasierte und deterministische Checks unterschiedlich fehlschlagen und warum Sie sie verketten Ein modellbasierter Klassifizierer kann umgangen werden: Ein Benutzer kann eine Eingabe so formulieren, dass sie sogar den stärksten Judge-Modellen ausweicht. Eine deterministische Regel ist spröde: Sie blockiert genau das, wofür sie programmiert ist, und nichts mehr. Sie verpasst alles, das sie nicht antizipiert hat, und über-blockiert alles, das einem eingeschränkten Muster ähnelt. Es gibt keine Kontrolle, die alles abfängt, daher werden diese Kontrollen in Serie bereitgestellt. Zu identifizieren, was jede verpasst, stellt sicher, dass jede Lücke bewusst durch eine andere Kontrolle abgedeckt wird, statt offen gelassen zu werden.

Ein zweiter Injektionsvektor: Anweisungen, die durch abgerufene Inhalte und Tool-Ausgaben ankommen Benutzer-Input-Screening fängt Anweisungen ab, die der Benutzer direkt sendet. Es fängt nicht Anweisungen ab, die in Inhalten eingebettet sind, die das System abruft oder von Tools empfängt. In einem RAG-System erreicht eine böswillige Anweisung in einem abgerufenen Dokument das Modell, nachdem Input-Screening die Anfrage bereits bestanden hat. In einem agentic System kann eine Tool-Antwort Anweisungen tragen, die das Modell als autoritativ behandelt. Dies ist der dominante Injektionsvektor in Enterprise-Bereitstellungen mit Abruf oder Tool-Nutzung, und es erfordert eine separate Kontrolle: Screenen Sie abgerufene Inhalte und Tool-Ausgaben, bevor sie zum Modell-Kontext hinzugefügt werden, mit dem gleichen modellbasierten Klassifizierer, den Sie auf Benutzer-Input anwenden. Der blinde Fleck ist unterschiedlich, weil die Quelle unterschiedlich ist; identifizieren Sie ihn explizit in Ihrem Control-Design, um Abdeckung sicherzustellen.

Auf der API geben Antworten eine Ablehnung zurück, wenn Streaming-Klassifizierer eingreifen. Die Messages API meldet dies als stop_reason: "refusal" begleitet von einem stop_details-Objekt (verfügbar seit Claude Opus 4. 7). Dieses Objekt trägt eine Policy-Kategorie zusammen mit einer lesbaren Erklärung; beide Felder sind null, wenn die Ablehnung nicht auf eine benannte Kategorie abbildet. Die Kategorie-Menge ist in der stop-reasons-Dokumentation auf platform. claude. com aufgelistet. Zum Zeitpunkt des Schreibens umfasst sie cyber, bio, frontier_llm und reasoning_extraction. Überprüfen Sie die Liste zum Veröffentlichungszeitpunkt erneut, statt sie zu hardcodieren. Ihre Anwendung sollte die Kategorie lesen und verschiedene Ablehnung-Klassen unterschiedlich weiterleiten, statt jede Ablehnung als ein einzelnes, undifferenziertes Ereignis zu behandeln. Auf Modellen, die stop_details nicht zurückgeben, muss Ihr Handler ein fehlendes Objekt tolerieren und auf generische Behandlung zurückfallen. Überprüfen Sie aktuelle Modell-Unterstützung gegen platform. claude. com zum Veröffentlichungszeitpunkt. Als Regel sollten Sie nach Erhalt einer Ablehnung den Konversations-Kontext zurücksetzen: Entfernen oder umformulieren Sie den Turn, der die Ablehnung ausgelöst hat, oder löschen Sie den Verlauf. Das Senden der nächsten Anfrage auf dem gleichen abgelehnten Kontext gibt weitere Ablehnungen zurück.

Fail Open versus Fail Closed: Wie sich Ihre Guardrail-Schicht bei Fehler verhält Wenn der vom Operator erstellte Klassifizierer unter Last fehlschlägt oder Ihr vom Operator erstellter Screening-Service unerreichbar ist, tut die Anwendung eines von zwei Dingen. Sie kann offen ausfallen und den Traffic ungeschirmt durchlassen, oder sie kann geschlossen ausfallen und jede weitere Aktion blockieren, bis die Kontrolle wieder gesund ist. Die Wahl gehört Ihnen als Architect; dies sind Komponenten, die Ihr Team erstellt, hostet und konfiguriert. Sie sind getrennt von Anthropics eingebauten Modell-Sicherheits-Kontrollen, die nicht vom Operator konfigurierbar sind und nicht offen ausfallen. Ein vom Operator erstellter Guardrail, der stillschweigend Traffic durchlässt, wenn er fehlschlägt, ist schlimmer als einer, der Traffic blockiert, weil er Ihnen die Beruhigung gibt, eine Kontrolle zu haben, während er keine der Schutzmaßnahmen bietet. Dies ist die gleiche Überlegung wie der Circuit Breaker aus der Produktionsarbeit: Wenn eine Abhängigkeit in Ihrem Stack ausfällt, degradieren Sie bewusst basierend auf der Situation.

Der vollständige bewachte Anfragepfad, als ein System Eine Anfrage bewegt sich durch den Pfad in Ordnung: Sie kommt an, Input-Screening entscheidet, ob sie das Modell erreicht, das Modell produziert eine Antwort, Output-Screening entscheidet, ob diese Antwort zurückgegeben wird, und jeder Tool-Aufruf, den das Modell ausgibt, durchläuft Autorisierung, bevor er läuft. Jedes Gate kann bestehen, blockieren oder fehlschlagen, und jeder Fehler wird in die Richtung aufgelöst, die Sie gewählt haben. Jedes blockierte oder fehlgeschlagene Gate wird geloggt, damit ein Incident aus dem Datensatz rekonstruiert werden kann.

Der vollständige bewachte Anfragepfad Benutzer-Anfrage → Input-Screening (modellbasiert für mehrdeutige Absicht, deterministisch für definierte Regeln, auf Fail Closed gesetzt) → Modell-Aufruf → Output-Screening (Judge-Modell oder Validator, auf Fail Closed gesetzt) → Tool-Call-Autorisierung (deterministische Allowlist plus Identität und Scope) vor jeder Side-Effecting-Aktion → Antwort an Benutzer, mit jedem blockierten oder fehlgeschlagenen Gate geloggt für spätere Rekonstruktion

Skill-Supply-Chain-Sicherheit Sie können den folgenden Einwand im Feld hören: "Skills sind eine Black Box. Ich kann nicht alles darin sehen, bis es läuft, also wie soll ich es vertrauen? " Die Aufgabe des Architects ist es, eine Kontrolle zu bauen, die dies kompensiert. Zur Erinnerung: Skills sind wiederverwendbarer, verteilbarer Code, der mit einem Anweisungssatz gepaart ist, zusammen gebündelt und in Ihre Umgebung fallen gelassen. Dieses Verteilungsmodell ist das, was es zu einem Supply-Chain-Risiko macht. Ein nicht vertrauenswürdiger Skill kann einen Code-Execution-Exploit tragen: Logik, die Befehle ausführt, das Netzwerk erreicht oder Dateien berührt, sobald er aufgerufen wird. Das ist riskant, weil der Skill versteckte böswillige Anweisungen enthalten kann, die Ihre Input-Filter und Prompt-Screening nicht sehen können; diese beobachten die Konversation, aber die Bedrohung war upstream im Skill eingebacken. Output-Überwachung könnte einen nachgelagerten Effekt nach der Tatsache abfangen, aber bis dahin wird der Code bereits gelaufen sein. Die Verteidigung muss also früher in der Kette bewegt werden. Bevor Sie einen Skill vertrauen und aufrufen können, müssen Sie ihn überprüfen: Öffnen Sie das Bundle und lesen Sie es auf zwei Dinge. Erstens, suchen Sie nach anomalen Aufrufen: Netzwerk-Anfragen, Shell-Ausführung, Dateisystem-Zugriff, Credential-Lesevorgänge. Zweitens, Out-of-Scope-Operationen: Verhalten, das nicht dem Job entspricht, den er behauptet zu erfüllen. Ein Formatting-Skill, der nach Hause telefoniert, ist Out-of-Scope; ein Summarizer, der auf die Festplatte schreibt, ist Out-of-Scope. Der angegebene Zweck eines Skills sollte Ihre Audit-Baseline sein, und alles, das darüber hinausgeht, ist ein Finding, das Sie untersuchen sollten. Ihre Überprüfung sagt Ihnen, was in Ihrem Bundle ist; ein Skill, der die Überprüfung sauber besteht, kann immer noch zur Laufzeit Code abrufen, der nie im Paket war, das Sie gelesen haben. Deshalb braucht das Gate ein Netz. Führen Sie Skills mit minimalen Berechtigungen aus und in einer Sandbox, die ihnen begrenzten Dateizugriff, begrenztes Netzwerk, keine stehenden Credentials, die sie nicht brauchen, gibt. Die Überprüfung entscheidet, was reinkommt; Runtime-Einschließung enthält es, wenn die Überprüfung etwas verpasst. Sie sollten beide verwenden, weil keine einzelne Kontrolle perfekt ohne die andere funktioniert. Sie sollten auch berücksichtigen, woher Skills erlaubt sind zu kommen; vertrauen Sie nur Skills aus einer überprüften internen Registry, verifizierten Publishern, nur signierte Releases. Eine Trusted-Source-Policy schrumpft die Oberfläche, die Sie überprüfen müssen, und stoppt nicht vertrauenswürdige Bundles, bevor sie die Überprüfung erreichen. Eine Regel der Offenheit gilt immer: Nehmen Sie nicht an, dass die Plattform Skills für Sie screent. Überprüfen Sie, welche automatisierte Überprüfung tatsächlich existiert; lesen Sie die Dokumentation, bestätigen Sie den Umfang jedes Scannings, finden Sie heraus, was es tut und nicht tut. Jede Überprüfung muss in einem explizit aufgezeichneten Urteil enden: genehmigen, ablehnen oder beheben. Genehmigen bedeutet, es ist sauber und freigegeben zur Nutzung. Ablehnen bedeutet, es betritt die Umgebung nicht. Beheben bedeutet, Sie haben ein behebbares Problem gefunden; in diesem Fall, entfernen Sie den anstößigen Aufruf, sandbox die Operation, pin eine sicherere Version und überprüfen Sie dann erneut. Obwohl Sie möglicherweise nie alles sehen, das ein Skill tun kann, sind das Audit-Urteil und eine Trusted-Source-Policy die kompensierenden Kontrollen, die es Ihnen ermöglichen, verantwortungsvoll zu handeln.

Kosten · Komplexität · Risiko Kosten: Jeder Screening-Punkt fügt einen Aufruf oder eine Regel-Evaluierung zu jeder Anfrage hinzu. Ein Judge-Modell auf Output verdoppelt ungefähr die Modell-Kosten für diesen Turn. Komplexität: Drei Kontrollpunkte, jeder mit einem Check-Typ, einer Fail-Richtung und einer Log-Zeile, sind materiell mehr zum Bauen und Testen als ein einzelner Filter. Risiko: Offen ausfallen ist der teure Fehler: Unterladung des Systems lässt stillschweigend den Schutz fallen, während es immer noch bewacht aussieht, daher taucht die Lücke nur in einem Incident auf. Dieses Risiko gilt nicht für Anthropics API-Level-Kontrollen, die außerhalb Ihrer Konfiguration liegen. Es gilt ausschließlich für die Komponenten, die Ihr Team erstellt und betreibt.

Screen 8: Wenn ein einzelner Output-Filter wie ein fertiges Design aussieht

Watch OutGuardrails4 min Wenn ein einzelner Output-Filter wie ein fertiges Design aussieht

Setup-Hook Output-Filterung ist eine klare Kontrolle, auf die Sie zeigen können; sie zeigt sich als sauberes Kästchen auf dem Architektur-Diagramm, es feuert, wo ein Reviewer es arbeiten sehen kann, und es sitzt am Ende des Pfads, wo das Risiko sich am konkretesten anfühlt, direkt bevor der Benutzer eine Antwort sieht. Wenn Sie also einen Klassifizierer auf der Ausgabe hinzufügen, sieht das Diagramm vollständig aus, und die Überprüfung besteht. Das Problem ist, dass das Wichtigste, das das System tut, möglicherweise vor diesem Klassifizierer passiert ist.

Ein Trace-Auszug, wo das Side-Effecting-Tool vor irgendetwas lief, das die Anfrage überprüfte Das Modell erhielt eine Anfrage, rief ein Tool auf, das eine Rückerstattung ausstellte, und das Tool lief. Eine Rückerstattung ist eine finanzielle Aktion: Das Tool kehrt eine Gebühr um und gibt Geld vom Unternehmen auf das Konto des Kunden zurück. Erst nachdem das Geld sich bewegte, schaute der Output-Filter auf irgendetwas. Es inspizierte den Text, den das Modell generierte, fand nichts Unsicheres und bestand. Die Rückerstattung war bereits passiert. Eine Kontrolle könnte an drei Orten auf diesem Pfad gesessen haben: Screening der Anfrage auf dem Weg rein, Autorisierung des Tool-Aufrufs, bevor er ausgeführt wurde, und Filterung der Antwort auf dem Weg raus. Dieses System hatte nur den letzten, und er saß stromabwärts der einzigen Aktion auf dem Pfad, die nicht rückgängig gemacht werden konnte.

Ein Kundenservice-Agent hat Zugriff auf ein issue_refund-Tool. Ein Benutzer reicht eine Anfrage ein. 1 Anfrage empfangen (kein Input-Screening konfiguriert) 2 Modell gibt tool_use aus: issue_refund(order=…) 3 Tool führt aus, Rückerstattung ausgestellt (kein Autorisierungs-Gate vor der Nebenwirkung) 4 Output-Filter inspiziert generierten Text (er besteht, weil die Aktion, die er beschrieb, bereits passiert war)

Warum dies brach Eine Kontrolle wurde an einem Punkt platziert, aber wurde als Abdeckung von drei Punkten behandelt. Output-Screening beurteilt Text, nicht Aktionen. Ein Side-Effecting-Tool braucht Autorisierung, bevor es läuft, und eine ungeschirmte Eingabe hat kein Gate. Ein Filter am Ende ist kein bewachter Pfad, Sie sollten alle drei Filter hinzufügen, wenn nötig.

Screen 9: Platzieren Sie die Kontrollen auf dem Pfad

CheckpointGuardrails4 min Platzieren Sie die Kontrollen auf dem Pfad Versuchen Sie es jetzt. Ihnen werden vier Kontrollen gegeben. Jede beantwortet zwei Fragen: Wo sie auf dem Anfragepfad sitzt und welche Art von Check es ist. Legen Sie jede Kontrolle auf ein Gitter. Die horizontale Achse ist der Platzierungspunkt, von Input-Screening bis Action-Autorisierung vor einem Tool-Lauf bis Output-Filterung. Die vertikale Achse ist, ob ein deterministischer Check oder ein modellbasierter Check passt. Korrekte Platzierung offenbart die Überlegung. Nicht jede Zone wird gefüllt, zwei Zellen bleiben leer.

A. Jailbreak- und Prompt-Injection-Screen B. Verbotene Begriff-Blocklist auf der Benutzer-Nachricht C. Toxizitäts-Judge auf der generierten Antwort D. Rückerstattungs-Autorisierungs-Policy-Check vor dem Tool-Lauf

Modellbasiert Deterministisch

Input-Screening

Output-Screening

Action-Autorisierung

Antworten überprüfen Jetzt überspringen

Screen 10: Wo ungleiche Ergebnisse eindringen und was das System erklären muss

TeachingFairness11 min Wo ungleiche Ergebnisse eindringen und was das System erklären muss Runtime-Kontrollen verhindern, dass unzulässige Ausgaben das System verlassen, stellen sicher, dass Benutzer sie nie sehen. Runtime-Kontrollen berücksichtigen jedoch keine Ausgabe, die technisch jeden Check besteht, aber unterschiedliche Ergebnisse für verschiedene Menschen produziert. Dieser Fehler ist schwerer zu erkennen und schwerer zuzuordnen, weil er auf der Oberfläche wie eine normale Ausgabe aussieht.

Ungleiche Ergebnisse dringen an identifizierbaren Punkten ein Fairness wird leichter zu entwerfen, sobald Sie aufhören, sie als ein einzelnes Attribut des Modells zu behandeln, und anfangen, sie als etwas zu behandeln, das an spezifischen, identifizierbaren Punkten eindringt. In einem Claude-System gibt es vier häufige Einstiegspunkte:

Das Abruf-Corpus kann Gruppen über- oder unterrepräsentieren, daher ist der Kontext, den das Modell sieht, bereits verzerrt. Die Rahmung des Prompts kann eine Annahme kodieren, die Ergebnisse in eine Richtung drückt. Die in Few-Shot-Prompting verwendeten Beispiele können die gleiche Verzerrung tragen, die das Corpus tut. Und das nachgelagerte Routing, was mit der Modell-Ausgabe nach ihrer Produktion passiert, kann einige Gruppen auf verschiedene Pfade lenken.

Jeder dieser ist ein Injektionspunkt, den Sie inspizieren können, was Fairness zu einer echten architektonischen Eigenschaft macht.

Wer fragt, bestimmt, was das System erklärt

ZielgruppWas sie brauchenWas das erfordert, dass Sie erfassen

Ein betroffener BenutzerEine klare Erklärung, warum eine Entscheidung, die sie betrifft, getroffen oder in Begriffen ausgedrückt wurde, auf die sie handeln können. Die Eingaben, die die Entscheidung trieben, und der Grund, warum das Ergebnis erreicht wurde, in einer verdaulichen Form. Ein RegulatorsBeweise, dass das System vergleichbare Fälle konsistent behandelt und dass eine bestimmte Entscheidung auf Anfrage rekonstruiert werden kann. Ein dauerhafter, abfragbarer Datensatz von Eingaben, Ausgaben und Entscheidungspfad. Ihr Build-Team Genug Detail, um zu finden, warum eine gekennzeichnete Entscheidung schiefging und sie zu beheben. Die vollständige Trace: Prompt, abgerufener Kontext, Modell-Ausgabe und jeder Routing-Schritt, gebunden an die bestehende Observability.

Decision-Logging ist das, was diese Erklärungen möglich macht Um eine einzelne Entscheidung wiederzugeben und zu erklären, erfassen Sie die Eingaben, die sie trieben, den abgerufenen Kontext, die Modell-Ausgabe und das Routing, das sie durchlief. Dies ist die gleiche beobachtbare Instrumentierung aus der Produktionsarbeit, angewendet auf eine andere Frage. Dieses Mal, statt zu fragen, ob das System gesund ist, fragen wir, warum eine bestimmte Entscheidung passierte. Die Instrumentierung ist die gleiche, aber der Aufbewahrung und der Abfragepfad sind unterschiedlich.

Eine Fairness-und-Transparenz-Checkliste in Aktion Betrachten Sie ein Kreditentscheidungs-Support-System. Überprüfen Sie die Checkliste einmal und die Kriterien hören auf, abstrakt zu sein:

Welcher der vier Einstiegspunkte könnte dieses Ergebnis verzerren, und ist jeder instrumentiert? Für eine ungünstige Entscheidung, können Sie die Eingaben und den Grund in Begriffen produzieren, auf die der Antragsteller handeln kann? Wenn ein Regulator fragt, ob ähnliche Antragsteller konsistent behandelt wurden, können Sie das Log abfragen und eine Antwort geben? Kann Ihr Team die vollständige Trace für jede gekennzeichnete Entscheidung ziehen?

Ein "Nein" irgendwo ist eine Design-Lücke.

Discernment: Beurteilen von Ausgaben auf ungleiche Behandlung Discernment ist eine der vier AI-Fluency-Kompetenzen: Bewertung von KI-Ausgaben und -Verhalten. In der Praxis bedeutet es, zu beurteilen, ob eine Modell-Ausgabe akzeptabel ist, Überarbeitung braucht oder Überschreibung braucht, statt sie zu akzeptieren. Angewendet auf Fairness ist Discernment das, was einen Reviewer befähigt, ein verzerrtes oder ungerechtfertigtes Ergebnis zu erkennen, statt nur zu bestätigen, dass ein Wert produziert wurde. Ein Transparenz-Datensatz ist das, was diese Erkennung überhaupt erst möglich macht.

Kosten · Komplexität · Risiko Kosten: Erfassung und Aufbewahrung von Decision-Level-Logs auf jeder Anfrage fügt Speicher und einen Abfragepfad hinzu, und die Kosten wachsen mit dem Traffic statt fest zu bleiben. Komplexität: Instrumentierung von vier Einstiegspunkten und Bedienung von drei Zielgruppen ist mehr Design-Arbeit als ein einzelnes Audit-Log, weil jede Zielgruppe einen anderen Schnitt des gleichen Datensatzes braucht. Oben drauf muss die Aufbewahrungs-Policy jetzt gesteuert werden, da Sie Decision-Level-Daten länger und für einen spezifischen Zweck halten. Risiko: Die Ergebnis-Metrik kann insgesamt gut aussehen, während Schaden in einer Untergruppe konzentriert ist. Ein ungloggter oder unmessener Injektionspunkt kann Unfairness verbergen, bis jemand außerhalb des Teams sie findet. Datenbehandlung: Das Decision-Log ist selbst im Scope für das Compliance-Register. In HIPAA- oder GDPR-Kontexten enthalten geloggte Eingaben und abgerufener Kontext sensible persönliche Daten. Wenden Sie Minimierung, Aufbewahrungsgrenzen und Zugriffskontrolle auf das Log an, und ordnen Sie es als benannte Kontrolle in Ihrem Compliance-Register zu. Alles für Transparenz zu loggen und Daten für Compliance zu pinnen sind nicht in Konflikt, da sie das gleiche Log erfordern, unterschiedlich gesteuert.

Screen 11: Wenn Fairness als das Problem des Modell-Anbieters behandelt wird

Watch OutFairness3 min Wenn Fairness als das Problem des Modell-Anbieters behandelt wird

Setup-Hook Fairness mag wie eine Eigenschaft des Modells aussehen. Der Modell-Anbieter trainierte es, führte die Bias-Evaluationen durch und veröffentlichte die Ergebnisse, daher fühlt es sich vernünftig an, Fairness als etwas zu behandeln, das upstream vor dem Modell Ihre Architektur erreicht, behandelt wird. Diese Rahmung hält, bis Ihr System das Modell mit Ihrem eigenen Abruf-Corpus paart, weil ein Corpus, der einige Fälle über-repräsentiert, ungleiche Ergebnisse produziert, die der Modell-Anbieter nie testete und nicht sehen kann.

Eine Post-Incident-Überprüfung Dieser Fehlermodus ist es wert, früh erkannt zu werden; das Team machte eine vernünftige Annahme, die sich als falsch herausstellte. Sie verwendeten ein Modell, das seine Fairness-Evaluationen bestand, und die Verzerrung trat an einem Punkt ein, den sie nicht beobachten wollten. Was folgt, ist ein Architect, der die Lücke in einer Post-Incident-Überprüfung beschreibt. "Wir nahmen an, Fairness war die Aufgabe des Modells. Die Verzerrung war in unserem Abruf-Corpus, und wir hatten so wenig geloggt, dass wir es nicht beweisen konnten. " Die ungleichen Ergebnisse kamen nicht aus dem Training des Modells. Stattdessen kamen sie aus einem Corpus, der einige Fälle über-repräsentierte, ein Injektionspunkt, den das Team nie überwachte, weil sie Fairness dem Vendor zugewiesen hatten. Als die Ergebnisse in Frage gestellt wurden, hatte das Team kein Decision-Level-Log, um zu rekonstruieren, was passiert war. Sie konnten weder die spezifischen Entscheidungen erklären, die das System traf, noch den Corpus als die Ursache ausschließen, was sie unfähig ließ, die einzige Frage zu beantworten, die der Regulator stellte: Woher kam die Verzerrung?

Warum dies brach Fairness wurde als eine Modell-Eigenschaft behandelt, die der Vendor besitzt. Ungleiche Ergebnisse treten an Punkten ein, die der Architect kontrolliert, und der Abruf-Corpus ist einer davon. Ohne Decision-Logging an diesen Punkten konnte das Team den Schaden nicht erklären oder seine Quelle widerlegen. Fairness und Erklärbarkeit sind Architektur-Anforderungen. Instrumentieren Sie sie an den Punkten, wo Verzerrung eindringen kann. Anzunehmen, dass sie mit dem Modell ankommen, lässt diese Punkte unüberwacht.

Screen 12: Kritisieren Sie das Decision-Logging-Design

CheckpointFairness3 min Kritisieren Sie das Decision-Logging-Design Versuchen Sie es jetzt. Sie schauen sich einen System-Sketch für einen Decision-Support-Flow an. Klicken Sie auf die Komponenten, wo Transparenz fehlt oder unzureichend ist, wie ein Routing-Schritt, der nie geloggt wird, oder eine Entscheidung, die nicht rekonstruiert werden kann. Jeder Klick offenbart, was diese Lücke für einen betroffenen Benutzer oder einen Regulator bedeutet. Wählen Sie alle Lücken. Lassen Sie angemessen geloggte Komponenten unausgewählt.

✓ LückeEin Routing-Schritt, der einige Fälle auf einen anderen Pfad sendet, ohne Log-Eintrag.

↓

✓ LückeEin Abruf-Schritt, dessen zurückgegebener Kontext nicht erfasst wird.

↓

✓ LückeEine Modell-Ausgabe, die ohne die Eingaben gespeichert wird, die sie produzierten.

↓

✓ AngemessenEingaben, Ausgaben und Routing sind alle geloggt und an eine Session-ID gebunden.

✓ AngemessenDas Log ist pro Entscheidung abfragbar und wird 90 Tage lang aufbewahrt.

✓ LückeEin Aggregate-Accuracy-Dashboard ohne Per-Subgroup-Aufschlüsselung.

Antworten überprüfen Jetzt überspringen

Screen 13: Routing von Entscheidungen an Menschen nach Einsatz, nicht nach Volumen

TeachingReview routing10 min Routing von Entscheidungen an Menschen nach Einsatz, nicht nach Volumen Decision-Logging gab Ihnen einen Datensatz dessen, worauf jede automatisierte Entscheidung basierte: die Eingaben, die sie sah, den Pfad, den sie nahm, und die Ausgabe, die sie produzierte. Ein geloggter Entscheidung kann später erklärt werden, aber ein Log allein entscheidet nicht, welche Entscheidungen eine Person vor ihrer Wirkung wiegen sollte. Ein Log erklärt Entscheidungen nach der Tatsache. Eine Routing-Regel stoppt die falschen, bevor sie Wirkung nehmen. Sie werden herausfinden, welche Entscheidungen einen Human-Review-Schritt verdienen und was dieser Reviewer auf dem Bildschirm sehen muss, um schnell die Entscheidung zu treffen. Das Log, das Sie bereits erstellt haben, ist das Rohmaterial für diese Ansicht, daher ist dies eine Frage, was davon zu zeigen ist und wann, statt das System erneut von Grund auf zu instrumentieren.

Was die Einsätze einer Entscheidung setzt Denken Sie an Human-Review als ein Budget: Sie haben eine endliche Menge an Reviewer-Aufmerksamkeit, und Sie müssen sie auf die höchsten Einsätze konzentrieren. Die folgenden Variablen arbeiten zusammen, um die Einsätze einer Entscheidung zu setzen.

Reversibilität ist, wie leicht eine falsche Entscheidung rückgängig gemacht werden kann. Die Kosten einer falschen Entscheidung sind das, was der Fehler verursacht, wenn er unkorrigiert durchgeht. Diese zwei setzen die Einsätze der Entscheidung: eine Wahl, die schwer rückgängig zu machen ist und teuer, wenn falsch, ist hoher Einsatz, unabhängig davon, wie das System dazu kommt. Konfidenz ist die dritte Variable, die oben auf den anderen zwei sitzt. Es ist der Score, den das System über seine eigene Ausgabe produziert, und es ist nützlich nur in dem Grad, in dem es kalibriert ist, weil ein Modell zuversichtlich falsch sein kann. Konfidenz ändert nicht die Einsätze einer Entscheidung; es schätzt, wie wahrscheinlich diese Ausgabe falsch ist, was Ihnen sagt, wie viel von Ihrem Volumen zu einer Person für Review geroutet werden sollte.

Kombinieren Sie diese Variablen in eine Regel: Route Entscheidungen zu einer Person, wenn sie niedrig-Konfidenz und entweder irreversibel oder hohe-Kosten sind; lassen Sie zuversichtliche, reversible, niedrig-Kosten-Entscheidungen durch. Eine zuversichtliche, leicht reversible, niedrig-Kosten-Entscheidung kann normalerweise ohne einen Menschen laufen. Eine niedrig-Konfidenz, irreversible, hohe-Kosten-Entscheidung braucht fast immer Human-Review. Die Entscheidungen, die Ihr Review-Budget verbrauchen, sind diejenigen, wo diese Variablen nicht einverstanden sind. Ein Fall kann hohe Kosten aber leicht reversibel sein, oder niedrig-Konfidenz auf etwas trivial zu Undoing. Wenn sie in Konflikt geraten, geben Sie größeres Gewicht zu Kosten und Reversibilität, weil sie die Konsequenzen eines Fehlers bestimmen. Lassen Sie Konfidenz entscheiden, wie viel von diesem hohen-Einsatz-Volumen Sie sicher unreviewed durchlassen können. Routing auf Konfidenz trägt eine Annahme, die es wert ist, identifiziert zu werden: Das Konfidenz-Signal muss für die Regel kalibriert sein, um zu halten, und das Bestätigen dieser Kalibrierung ist eine Aufgabe seiner eigenen.

Wo der Mensch sitzt, ist ein Tradeoff zwischen Sicherheit und Geschwindigkeit Sobald eine Entscheidung zu einer Person geroutet wird, wählen Sie, wo sie im Flow sitzt. Einen Menschen früher einzubeziehen ist sicherer und langsamer.

PlatzierungWas es Ihnen gibtWas es kostet

Pre-Action-GenehmigungDie Aktion kann nicht Wirkung nehmen, bis eine Person sie genehmigt, daher passiert nichts Irreversibles unreviewed. Es fügt Latenz zu jeder gerouteten Entscheidung hinzu und eine Person muss verfügbar sein, daher skaliert es nicht zu hohem Volumen. Post-Action-AuditDie Aktion läuft sofort und eine Person überprüft sie später, daher bleibt der Durchsatz hoch. Eine falsche Aktion hat bereits Wirkung genommen, bis sie abgefangen wird, daher passt sie nur zu reversiblen, niedrigeren-Kosten-Entscheidungen. Sampled ReviewEin Bruchteil von Entscheidungen werden überprüft, um Qualität zu überwachen, ohne den Gesamtprozess zu verlangsamen. Eine schlechte Entscheidung kann unsampled durchschlüpfen, es überwacht das System statt einzelne Ergebnisse zu schützen.

Was der Reviewer sieht, entscheidet, ob Review genau ist Ein Reviewer, der nicht sehen kann, warum eine Entscheidung in seiner Warteschlange landete, kann ohne die Beurteilung genehmigen, die es brauchte. Stellen Sie sicher, dass Ihre Reviewer drei Dinge haben: die Eingaben, die die Entscheidung trieben, die Modell-Ausgabe und den Grund, warum sie gekennzeichnet wurde. Ohne diesen Grund können sie nicht zwischen einem Edge-Fall und Routine-Traffic unterscheiden. Ohne die Eingaben können sie nicht sagen, ob die Ausgabe korrekt ist. Was Sie vor den Reviewer stellen, bestimmt, ob die Review genau ist.

Anthropics Forschung zur Agent-Autonomie fand, dass das Erfordernis von Sign-Off auf jeder Aktion Reibung ohne bedeutsamen Sicherheitsgewinn hinzufügt. Ein besserer Ansatz ist, dass eine Person überwacht, was passiert, und eingreift, wenn nötig. Ein Anthropic-Muster in Agent-Workflows ist, Pro-Schritt-Genehmigungen zu reduzieren und Review zu höherwertigen Checkpoints wie Plan-Review oder Exception-Handling zu bewegen, um Consent-Fatigue zu vermeiden; das genaue Review-Design hängt vom Risiko des Workflows ab. Ohne diese Discernment kann Consent-Fatigue passieren. Consent-Fatigue ist, wenn ein System Dutzende Male in einer Reihe um Genehmigung fragt, und Reviewer anfangen, Elemente durchzuklicken und zu genehmigen, ohne zu lesen oder die Qualität der Review zu bieten, die nötig ist. Dieses Muster ist das, das zu Plan-Level-Review in Claude Code führte, wo eine Person den Plan genehmigt statt jeden Schritt. Überprüfen Sie aktuelle Rahmung gegen anthropic. com/research/measuring-agent-autonomy und anthropic. com/research/trustworthy-agents zum Veröffentlichungszeitpunkt.

Diligence: Die Kompetenz hinter Human-Review Diligence ist eine der vier AI-Fluency-Kompetenzen: Sicherstellung von verantwortungsvoller KI-Zusammenarbeit. Angewendet auf Bereitstellung bedeutet es, explizite Human-Accountability-Checkpoints zu erhalten, zu erkennen, wenn Automation-Druck Übersicht erodiert, und Workflows auf Lücken zu überprüfen, wo KI ohne Review handelt, besonders wenn Automation skaliert. Für Agent-Workflows wird die Routing-Regel zu einem Checkpoint-Muster: ein Gate, das Ausführung für Human-Review basierend auf dem Risiko und der Reversibilität dieser Aufgabe pausiert. Platzieren Sie ein Gate vor jeder irreversiblen oder hohen-Einsatz-Aktion, die ein Agent sonst autonom nehmen würde, und samplen Sie niedrigere-Einsatz-Aktionen statt jede zu gaten. Dies ist das gleiche Gate-Vokabular, das Multi-Agent-Design abhängt.

Kosten · Komplexität · Risiko Kosten: Pre-Action-Review fügt Latenz zu jeder gerouteten Entscheidung hinzu und braucht Reviewer-Zeit, die ein wiederkehrende Betriebskosten ist. Komplexität: Routing-Logik, eine Reviewer-Schnittstelle, die Eingaben und Flag-Gründe zeigt, und drei Platzierungspfade sind komplexer zu bauen als eine einzelne Review-Warteschlange. Risiko: Routing nach Volumen statt Einsatz überwältigt entweder Reviewer und riskiert Review-Qualitäts-Degradation, oder erlaubt eine hohen-Einsatz, irreversible Aktion ohne Gate überhaupt.

Screen 14: Wenn Routing alles zu Review Review sinnlos macht

Watch OutReview routing3 min Wenn Routing alles zu Review Review sinnlos macht

Setup-Hook Zu entscheiden, welche Entscheidungen als hohen Einsatz zählen, braucht Beurteilung, und alles zu Review zu senden, entfernt diesen entscheidenden Schritt. Es mag sich wie der konservative Standard anfühlen: Es ist leicht, zu einem Compliance-Reviewer oder Auditor zu verteidigen, und es erfordert keinen Aufruf darüber, wo die Einsätze sitzen. Alles zu Routing fühlt sich wie die sichere Antwort an, genau weil es Sie von der Linie-Ziehung befreit.

Ein kurzes Transkript eines Handoffs, das schlampig überprüft wurde Eine Reviewer-Warteschlange wird selten gesehen, bis sie fehlschlägt. Das Muster unten zeigt, was passiert, wenn ein System jede Ausgabe zu einer Person routet und dieser Person nichts zu überprüfen gegen gibt. Zwei separate Dinge gehen gleichzeitig falsch, und der Dialog zeigt beide: Das Volumen ist mehr als jemand lesen kann, und jedes Element kommt ohne den Kontext an, der den Reviewer beurteilen lassen würde.

Reviewer: Es gibt vierhundert Elemente in meiner Warteschlange heute. Gleich wie gestern. Lead: Liest du die Eingaben auf jedem? Reviewer: Es gibt keine Möglichkeit. Ich bekomme die Ausgabe und einen Genehmigungsknopf, das ist es. Ich sehe nicht mal die Eingaben oder warum dieses hier bei mir landete. Nach der ersten Stunde muss ich einfach Genehmigen drücken, um mit dem Tempo Schritt zu halten.

Das Design sendete alle Ausgaben zur Review und gab dem Reviewer die Ausgabe allein, ohne Eingaben und ohne Flag-Grund. Das Volumen machte sorgfältige Review unmöglich, und der fehlende Kontext machte es sinnlos, daher kollabierte Review in Genehmigung. Eine hohen-Einsatz-Entscheidung in dieser Warteschlange bekam die gleiche Routine-Genehmigung wie eine triviale.

Warum dies brach Zwei unabhängige Fehler stapelten sich hier, und jeder allein ist genug, um Review sloppy zu machen. Der erste ist Volumen. Wenn die Anzahl der Elemente, die zu einer Person geroutet werden, das übersteigt, was sie in der Zeit lesen können, die sie haben, Übersicht, die alles abdeckt, überprüft nichts, weil der Reviewer sich disengagiert, um mit dem Tempo Schritt zu halten. Der Fix ist die Routing-Regel: Senden Sie Entscheidungen zu einer Person nach Einsatz, mit Konfidenz, Reversibilität und Kosten, daher hält die Warteschlange nur die Entscheidungen, die Aufmerksamkeit verdienen, statt alle. Der zweite ist fehlender Kontext. Ein Reviewer, der nur die Ausgabe und einen Genehmigungsknopf sieht, hat nichts, um die Ausgabe gegen zu überprüfen, daher ist sogar eine kurze Warteschlange schwer genau zu beurteilen. Der Fix ist, was in der Reviewer-Ansicht sitzt, zu verschieben: Zeigen Sie die Eingaben, auf denen die Entscheidung basierte, und den Grund, warum das Element gekennzeichnet wurde, daher kann der Reviewer sehen, was sie wiegen werden. Wenn Sie nur einen dieser Fehler beheben, ist es immer noch möglich, dass die Review fehlschlägt. Eine kleine Warteschlange ohne Kontext und eine gut gebaute Reviewer-Ansicht, die unter Volumen ertrinkt, beide fehlschlagen.

Screen 15: Bauen Sie die Review-Routing-Regel

CheckpointReview routing3 min Bauen Sie die Review-Routing-Regel Versuchen Sie es jetzt. Eine Routing-Regel hat drei Kontrollen: einen Konfidenz-Schwellenwert, die Kosten einer falschen Antwort und eine Reversibilität-Einstellung. Das Ziel ist, hohen-Einsatz, niedrig-Konfidenz-Entscheidungen zu einer Person vor ihrer Wirkung zu routen, während die Review-Warteschlange unter der Reviewer-Decke bleibt. Wählen Sie die Regel, die beide Ziele gleichzeitig erfüllt.

A. Route alles unter einem hohen Konfidenz-Schwellenwert zur Review, unabhängig von Einsatz. B. Route Entscheidungen, die niedrig-Konfidenz UND entweder irreversibel oder hohe-Kosten sind, zu Pre-Action-Review; lassen Sie zuversichtliche, reversible, niedrig-Kosten-Entscheidungen durch. C. Route nach Konfidenz allein, setzen Sie niedrig genug, um die Warteschlange klein zu halten. D. Senden Sie jede Entscheidung zur Review, um sicher zu sein.

Jetzt vervollständigen Sie diesen Schritt: In 1–2 Sätzen, nennen Sie die einzelne entscheidende Kontrolle, was macht einen niedrig-Konfidenz-Fall immer noch zu einer Person routen, sogar wenn Konfidenz innerhalb der Toleranz ist?

Modell-Antwort anzeigen

Modell-Antwort Reversibilität und die Kosten einer falschen Antwort sind die entscheidenden Kontrollen, nicht Konfidenz. Konfidenz filtert das Volumen, das Sie routen, aber es ändert nicht die Einsätze der Entscheidung. Ein Fall kann zuversichtlich sein und immer noch zu einem Menschen routen, wenn er irreversibel oder hohen-Kosten genug ist, um es zu verdienen.

Markieren Sie als abgeschlossen

Jetzt überspringen

Screen 16: Jede Compliance-Verpflichtung in eine Kontrolle mit Beweis umwandeln

TeachingCompliance10 min Jede Compliance-Verpflichtung in eine Kontrolle mit Beweis umwandeln Die Compliance-Schicht des Integrations-Modells verwendete die Governing-Verpflichtung als Pre-Filter: HIPAA, GDPR, FedRAMP, Anwalt-Klient-Privileg oder eine Daten-Residenz-Policy jede herrschte Lieferungs-Routen und Einstiegspunkte rein oder raus, bevor Kosten oder Engineering-Vorliebe in das Gespräch eintrat. Diese Arbeit bringt Sie zu einem Einstiegspunkt und einer Route, die die Verpflichtung überlebt, aber der nächste Schritt ist enger und schwerer. Jede überlebende Verpflichtung muss jetzt zu einer Kontrolle mit einem benannten Eigentümer werden. Ein Reviewer behandelt einen konformen Einstiegspunkt allein nicht als Beweis, dass die Regel befolgt wird. Sie fragen auch, wer die Kontrolle besitzt und welcher Beweis zeigt, dass sie in der Praxis hält.

Eine Regulation stellt ein Ergebnis dar, aber Sie liefern die Kontrolle und den Beweis, dass sie operiert Frameworks wie GDPR, HIPAA und FedRAMP stellen Ergebnisse dar, nicht Implementierungen. Sie sagen, was wahr sein muss: dass geschützte Daten auf eine bestimmte Weise behandelt werden müssen, dass Zugriff kontrolliert werden muss und dass Verarbeitung in einer autorisierten Umgebung passieren muss, aber sie lassen die technische Kontrolle Ihnen. Jede Verpflichtung wird zu drei Dingen, die Sie besitzen: eine spezifische technische Kontrolle, die das Ergebnis erreicht, ein Eigentümer, der dafür verantwortlich ist, und ein Beweis-Artefakt, das zeigt, dass es live ist. Denken Sie immer daran, das Beweis-Artefakt einzubeziehen; dies ist das, das der Reviewer überprüft und ist das am häufigsten verpasste.

Zuordnung von Verpflichtungen zu Kontrollen, Eigentümern und Beweis Zuordnung von Verpflichtungen zu Kontrollen, Eigentümern und Beweis Verpflichtung (Framework)Technische KontrolleBeweis, den ein Reviewer akzeptiertEigentümer

Geschützte Gesundheitsdaten, die unter einer Vereinbarung behandelt werden (HIPAA)Verwenden Sie nur einen HIPAA-bereiten Enterprise-Plan oder eine First-Party-API-Konfiguration, die von einer unterzeichneten Business Associate Agreement abgedeckt ist, mit aktivierter HIPAA-Compliance und nur berechtigten Features im Scope. Die unterzeichnete BAA und die Admin-Einstellung, die HIPAA-Compliance aktiviert zeigt, plus die berechtigte-Feature-Liste. Security-Lead US-Regierungs-Workload auf der erforderlichen Impact-Ebene (FedRAMP)Liefern Sie durch eine von Anthropic dokumentierte autorisierte Route, die die erforderliche Impact-Ebene erfüllt, nicht einen nicht-autorisierten Einstiegspunkt. Der Autorisierungs-Datensatz für die gewählte Route und Bestätigung, dass der Workload ausschließlich darauf läuft. Platform-Eigentümer Daten, die in einer genehmigten Region behandelt und gespeichert werden (Daten-Residenz)Konfigurieren Sie unterstützte regionale Verarbeitung und Speicherung für die genehmigte Region, und validieren Sie, ob Logs, Caches, Überwachung und Aufbewahrungspfade innerhalb der genehmigten Grenze bleiben. Die Residenz-Konfiguration und ein Daten-Flow-Datensatz, der zeigt, wo jede Kopie lebt. Daten-Eigentümer Entscheidungen, die auf Anfrage rekonstruierbar sind (Transparenz, Cross-Framework)Das Decision-Logging, das im Fairness-Cluster gebaut wurde, aufbewahrt und abfragbar für den erforderlichen Zeitraum. Eine Beispiel-Rekonstruktion einer Entscheidung aus dem Live-Log. Architect

Training-Nutzung vs Aufbewahrung, zwei unterschiedliche Ansprüche Kollabieren Sie nicht Training-Nutzung und Aufbewahrung in den gleichen Anspruch: Daten können standardmäßig von Modell-Training ausgeschlossen werden, während immer noch aufbewahrt oder überwacht werden für Logging, Missbrauch-Prävention, rechtliche Compliance oder konfigurierte Audit-Zwecke.

Das Beweis-Artefakt ist das, das die Handoff effektiv macht Die Constraint-Eliminierungs-Überlegung aus der Integrations-Arbeit trägt hier vorwärts. Damals eliminierten Sie Lieferungs-Routen, die eine Constraint nicht überleben konnten. Jetzt zeichnen Sie, für jede Verpflichtung, die Kontrolle auf, die sie erfüllt, und das Artefakt, das es beweist. Ein Sicherheits- und Rechts-Reviewer akzeptiert Beweis, dass eine Kontrolle live ist: eine unterzeichnete Vereinbarung, ein Konfiguration-Bildschirm, ein Autorisierungs-Datensatz oder eine zurückgegebene Log-Abfrage. Was sie nicht akzeptieren, ist ein Design-Dokument, das eine Kontrolle mit keinem Eigentümer und keinem Beweis identifiziert; eine Kontrolle, die niemand demonstrieren kann, ist nicht zu unterscheiden von einer, die nicht läuft.

Kosten · Komplexität · Risiko Kosten: Produktion und Wartung von Beweis für jede Verpflichtung ist laufende Arbeit. Konfigurationen driften und Artefakte werden alt, daher wird das Register auf einer regelmäßigen Kadenz revalidiert. Komplexität: Eine Kontrolle, ein Eigentümer und ein lebendes Beweis-Artefakt pro Verpflichtung ist mehr Governance als eine Einstiegspunkt-Wahl, und es spannt Sicherheits-, Rechts- und Platform-Eigentümer, die jeweils zustimmen müssen, wer was hält. Risiko: Eine Kontrolle, die mit keinem Eigentümer und keinem Beweis spezifiziert ist, ist unsichtbar bei der Überprüfung. Sie kann ohne jemanden verantwortlich aufhören zu operieren, und die Lücke taucht in Review statt in Design auf, was der teuerste Ort ist, um sie zu finden.

Screen 17: Wenn das Bestehen der Einstiegspunkt-Auswahl sich wie das Beenden von Compliance anfühlt

Watch OutCompliance3 min Wenn das Bestehen der Einstiegspunkt-Auswahl sich wie das Beenden von Compliance anfühlt

Setup-Hook Das Bestehen des Constraint-Pre-Filters und das Beweisen von Compliance sind zwei verschiedene Dinge. Der Pre-Filter gibt Ihnen ein sauberes Signal. Das Wählen einer Lieferungs-Route, die HIPAA, GDPR oder FedRAMP überlebt, produziert ein unmittelbares, sichtbares Ergebnis: Die Route ist erlaubt, der Einstiegspunkt ist freigegeben, das Design kann weitergehen. Das Beweisen, dass jede Verpflichtung erfüllt wird, produziert nichts Sichtbares zum Design-Zeit, weil der Beweis ein Artefakt ist, das Sie bauen, an einen Eigentümer anhängen und am Leben halten müssen, wenn sich Konfigurationen ändern. Diese Lücke ist leicht zu verpassen, weil der Moment, der sich wie eine Ziellinie anfühlt, und der Moment, wenn ein Reviewer überprüft, oft Monate auseinander sind.

Eine Bereitstellung, die die richtige Route wählte, aber keinen Beweis produziert Ein Team wählte eine konforme Lieferungs-Route für einen regulierten Workload und behandelte Compliance als erledigt. Sie ordneten Verpflichtungen zu Kontrollen einmal, zum Design-Zeit, in einem Dokument zu. Kein Eigentümer wurde an die Kontrollen angehängt, und kein Logging wurde verdrahtet, um zu zeigen, dass irgendeine Kontrolle operiert. Die Daten-Residenz-Verpflichtung ist, wo der Fehler konzentriert war. Die Kontrolle war auf Papier korrekt: Verarbeitung an die genehmigte Region gepinnt. Jedoch, Monate später, änderte sich eine Logging-Konfiguration und fing an, Request-Metadaten in einen Store in einer zweiten Region zu schreiben. Nichts identifizierte die Änderung, weil niemand Residenz-Kontrolle besaß und kein Artefakt verfolgte, wo Daten landeten. Die Lücke taucht bei der Überprüfung auf, nicht beim Design, wenn ein Reviewer nach Beweis fragte, dass Daten in-Region blieben, und das Team ein Design-Dokument statt eines Daten-Flow-Datensatzes hatte.

Warum dies brach Das Überleben des Pre-Filters wurde mit dem Etablieren von Compliance verwechselt. Eine konforme Route ist eine Voraussetzung, nicht Beweis. Jede Verpflichtung braucht eine Kontrolle, einen benannten Eigentümer und ein lebendes Beweis-Artefakt, das revalidiert wird, wenn sich die Bereitstellung ändert. Die Residenz-Kontrolle in dieser Geschichte war zum Design-Zeit real und stillschweigend falsch in der Produktion, und nichts fing den Unterschied, weil kein Artefakt es beobachtete.

Screen 18: Rechtfertigen Sie die Kontroll-Wahl

CheckpointCompliance3 min Rechtfertigen Sie die Kontroll-Wahl Versuchen Sie es jetzt. Ihnen wird eine Compliance-Verpflichtung für eine regulierte Bereitstellung gegeben. Wählen Sie die technische Kontrolle, die sie evidenziert, dann wählen Sie den einzelnen Last-tragenden Grund, warum ein Sicherheits- und Rechts-Reviewer diese Kontrolle als Beweis akzeptieren würde. Sie bestehen nur, wenn beide landen: Die Kontrolle muss die Verpflichtung erfüllen, und Sie müssen nennen, warum sie als Beweis zählt, den ein Reviewer inspizieren kann. Verpflichtung: Geschützte Gesundheitsdaten müssen unter einer formalen Vereinbarung behandelt werden (HIPAA).

A. Ein HIPAA-bereiter Plan oder First-Party-API unter einer unterzeichneten BAA, weil die unterzeichnete Vereinbarung plus die aktivierte Konfiguration das Artefakt ist, das ein Reviewer als Beweis inspizieren kann. B. Ein HIPAA-bereiter Plan unter einer unterzeichneten BAA, weil das Modell angewiesen ist, Gesundheitsdaten sorgfältig zu behandeln. C. Ein modellbasierter Content-Filter auf Gesundheits-Begriffen, weil er sensible Daten zur Laufzeit abfängt.

Antwort überprüfen Jetzt überspringen

Screen 19: Montieren Sie eine verantwortungsvolle Bereitstellung

CumulativeModule8 min Montieren Sie eine verantwortungsvolle Bereitstellung Versuchen Sie es jetzt. Ihnen wird ein in sich geschlossener Brief gegeben, und Sie treffen fünf sequenzierte Entscheidungen, die eine verantwortungsvolle Bereitstellung bauen. Die Entscheidungen laufen in Ordnung, weil jede die Bedingungen für die nächste setzt. Eine schwache frühe Wahl verengt, was die späteren tun können. Wenn Sie eine Domain-Regel in trainiertem Verhalten in Entscheidung eins lassen, gibt es keine Schicht stromabwärts, die sie zurückbringen kann.

Sie haben jede Schicht auf ihre eigene über das Modul gebaut. Hier ist der Stack, den Sie montieren, in Ordnung:

Trainiertes Verhalten formt Baseline-Sicherheit; Ihre Anwendungs-Policy definiert Domain-spezifische Regeln; die Runtime-Kontrollen unten durchsetzen diese Regeln in der Operation. Runtime-Screening und Autorisierung sitzen auf dem Anfragepfad und stoppen unzulässige Inhalte und nicht genehmigte Aktionen. Fairness- und Transparenz-Kontrollen adressieren ungleiche Ergebnisse an ihrer Quelle und stellen sicher, dass jede Entscheidung später rekonstruiert werden kann. Sie hängen von effektivem Logging ab. Human-Review-Routing sendet die Entscheidungen, die ein Modell nicht allein finalisieren sollte, zu einer Person, nach Einsatz. Es hängt vom gleichen Logging ab. Das Control-Register bindet jede Verpflichtung an eine Kontrolle, einen Eigentümer und ein Beweis-Artefakt.

Der Brief Ein öffentlicher Sektor-Leistungs-Assistent hilft einer Agentur, Programm-Berechtigung zu bestimmen, empfehlt, ob genehmigt, abgelehnt oder verwiesen werden soll. Der Brief gibt Ihnen, was die Entscheidungen brauchen und nichts mehr: Framework: FedRAMP auf der erforderlichen Impact-Ebene der Agentur, plus die Agentur-Regel, dass ein abgelehnter Antragsteller den spezifischen Grund erhält. Hohen-Einsatz, niedrig-Konfidenz-Fall: Ein Antragsteller nahe der Berechtigung-Schwelle mit unvollständiger Dokumentation, wo eine falsche Ablehnung jemandem ihre Leistungen entfernt. Verzerrung-anfällige Ausgabe: Die Empfehlung und der Grund, der an eine Ablehnung angehängt ist. Daten: Von Antragsteller eingereichte Felder, Agentur-Datensätze, die zum Entscheidungs-Zeit abgerufen werden, und alle abgeleiteten Features.

Setzen Sie die Grenze zwischen trainiertem Verhalten und Ihrer Anwendungsschicht.

Platzieren Sie die Runtime-Kontrollen.

Spezifizieren Sie die Fairness- und Transparenz-Kontrollen.

Definieren Sie das Human-Review-Routing.

Bauen Sie das Control-Register.

Modell-Antwort anzeigen Jetzt überspringen

Modell-Antwort

Setzen Sie die Grenze zwischen trainiertem Verhalten und Ihrer Anwendungsschicht. Trainiertes Verhalten lehnt breite Harm-Klassen ab, aber sah nie die Berechtigung-Regeln dieses Programms, daher gehören diese zur Anwendungsschicht. Lassen Sie sie in trainiertem Verhalten und keine Kontrolle stromabwärts kann sie erreichen.
Platzieren Sie die Runtime-Kontrollen. Positionieren Sie Input-Screening, Output-Screening und Tool-Call-Autorisierung, wählen Sie modellbasiert oder deterministisch bei jedem, und setzen Sie die Fehler-Richtung. Fail Closed, weil ein Screen, der offen ausfällt, eine ungeschirmte Ablehnung zu einem Antragsteller lässt.
Spezifizieren Sie die Fairness- und Transparenz-Kontrollen. Nennen Sie, welcher der vier Injektionspunkte (Corpus, Prompt-Rahmung, Beispiele, Routing) dieses Ergebnis verzerren könnte, und bauen Sie das Decision-Logging einmal, da der betroffene Antragsteller, der Regulator, das Build-Team und das Control-Register alle darauf ziehen.
Definieren Sie das Human-Review-Routing. Route nach Konfidenz, Reversibilität und Kosten einer falschen Antwort, und wählen Sie eine Platzierung: Pre-Action-Genehmigung, Post-Action-Audit oder Sampled-Review. Senden Sie eine niedrig-Konfidenz, schwer-zu-reversible Ablehnung zu Pre-Action-Genehmigung. Schlüsseln Sie die Regel zu Einsatz, nicht Volumen, oder eine stille Warteschlange winkt eine hohen-Einsatz-Ablehnung durch.
Bauen Sie das Control-Register. Ordnen Sie jede FedRAMP-Verpflichtung einer Kontrolle, einem Eigentümer und dem Beweis zu, den ein Reviewer akzeptiert. Eine Kontrolle ohne Beweis-Artefakt ist ein Anspruch, den Sie nicht beweisen können, operiert.

Starke Antworten sind spezifisch: Sie nennen, welche Injektionspunkte, nennen die Fehler-Richtung, nennen die Routing-Regel-Variablen und nennen das Beweis-Artefakt. Schwache Antworten beschreiben das allgemeine Konzept, ohne es auf diese Bereitstellung anzuwenden. Überprüfen Sie jede Entscheidung gegen den Brief, die Compliance-Framework und die hohen-Einsatz-Fall-Details sollten in Ihren Antworten auftauchen.

Markieren Sie als abgeschlossen

Screen 20: Glossar

ReferenceWrap-up Glossar Die Schlüssel-Begriffe, die über dieses Modul verwendet werden, in alphabetischer Ordnung. Klicken Sie auf einen Begriff, um seine Definition zu erweitern.

BAA (Business Associate Agreement)Ein Vertrag unter HIPAA, der einem Vendor erlaubt, geschützte Gesundheitsdaten im Namen einer abgedeckten Entität zu verarbeiten, definiert die Schutzmaßnahmen und Haftungen jeder Partei. Ohne ihn ist die Behandlung dieser Daten durch den Vendor nicht konform, unabhängig von den technischen Kontrollen. Consent-FatigueZusammenbruch der Übersicht, wenn ein Reviewer zu vielen Aktionen um Genehmigung gefragt wird, daher genehmigen sie fast alles ohne echte Review. Es ist der Fehlermodus des Routings jeder Entscheidung zu einem Menschen. Überprüfen Sie Anthropics aktuelle Rahmung gegen anthropic. com. VerfassungDas schriftliche Dokument, das Anthropic während des Trainings verwendet, um Claudes Werte und Verhalten zu formen, das eine Prioritätsreihenfolge von breit sicher, ethisch, konform mit Richtlinien und genuinely hilfreich angibt. Es formt das trainierte Verhalten des Modells, aber kodiert nicht die Domain-Policy einer Bereitstellung. Überprüfen Sie die aktuelle Version gegen anthropic. com. Control-RegisterEine Tabelle, die jede Compliance-Verpflichtung ihrer technischen Kontrolle, einem verantwortlichen Eigentümer und einem Beweis-Artefakt zuordnet, daher kann eine regulierte Bereitstellung als Register überprüft werden, statt als Erzählung behauptet zu werden. Daten-ResidenzDie Anforderung, dass Daten in einer spezifizierten geografischen Region verarbeitet und gespeichert werden, einschließlich Kopien in Logs und Caches. Es ist die Kontrolle hinter vielen Daten-Souveränitäts-Verpflichtungen. Decision-LoggingErfassung der Eingaben, des abgerufenen Kontexts, der Modell-Ausgabe und des Routings für jede Entscheidung, geschlüsselt, daher kann eine Entscheidung später wiedergegeben und erklärt werden. Es ist die gleiche Observability-Instrumentierung, auf die Frage gerichtet, warum eine bestimmte Entscheidung passierte. Beweis-ArtefaktDer konkrete Beweis, den ein Sicherheits- und Rechts-Reviewer akzeptiert, dass eine Kontrolle live ist: eine unterzeichnete Vereinbarung, ein Konfiguration-Bildschirm, ein Autorisierungs-Datensatz oder eine zurückgegebene Log-Abfrage. Eine Kontrolle, die in einem Design-Dokument benannt ist, ohne Artefakt, ist ein Anspruch, nicht Beweis. Fail Open vs Fail ClosedWie sich ein Guardrail verhält, wenn es selbst fehlschlägt. Fail Open lässt Traffic durch ungeschirmt, während Fail Closed blockiert, bis die Kontrolle gesund ist. Für Sicherheits-Kontrollen ist Fail Closed die bewusste Wahl, weil eine Kontrolle, die stillschweigend Traffic durchlässt, keinen Schutz bietet. FedRAMPDie FedRAMP-Klassifizierung (niedrig, moderat oder hoch), die die Sicherheits-Kontrollen setzt, die ein Cloud-Service erfüllen muss, um US-Regierungs-Workloads einer gegebenen Sensibilität zu behandeln. Die erforderliche Ebene wird durch den Workload gesetzt, und die Lieferungs-Route muss auf oder über ihr autorisiert sein. GDPRDas Daten-Schutz-Gesetz der EU bezüglich, wie Organisationen die persönlichen Daten von Menschen in der EU und dem EWR sammeln, verarbeiten, speichern und übertragen. Es gewährt Individuen Rechte über ihre Daten und erfordert eine rechtliche Basis für die Verarbeitung, Daten-Minimierung und Schutz. HIPAAA US-Bundesgesetz, das Standards für den Schutz der Gesundheitsinformationen von Individuen setzt. Es regelt, wie geschützte Gesundheitsinformationen (PHI) von abgedeckten Entitäten und ihren Business Associates verwendet, offengelegt und geschützt werden. Wenn ein Vendor PHI im Namen einer abgedeckten Entität verarbeitet, erfordert HIPAA ein Business Associate Agreement (BAA), das die Schutzmaßnahmen und Haftungen jeder Partei definiert. In diesem Modul treibt es die Anforderung, durch einen HIPAA-bereiten Plan oder First-Party-API unter einer unterzeichneten BAA zu liefern. Human-in-the-Loop-RoutingEine Regel, die Entscheidungen zu einer Person basierend auf Konfidenz, Reversibilität und den Kosten einer falschen Antwort routet, statt nach Volumen, mit dem Reviewer Pre-Action, Post-Action oder in einer Sample platziert. Injektionspunkt (Fairness)Ein spezifischer Ort, wo ungleiche Ergebnisse in ein System eindringen können: das Abruf-Corpus, die Prompt-Rahmung, die gewählten Beispiele oder das nachgelagerte Routing. Sie zu nennen macht Fairness eine Architektur-Eigenschaft, die Sie instrumentieren können, statt ein Modell-Attribut, das Sie annehmen. Input-ScreeningEin Check, der vor dem Modell-Aufruf läuft, um zu entscheiden, ob eine Anfrage das Modell erreichen sollte, mit einem modellbasierten Klassifizierer für fuzzy Intent wie Jailbreaks oder einer deterministischen Regel für crisp Muster. Judge-ModellEin Modell, das verwendet wird, um die Ausgabe eines anderen Modells zu bewerten oder zu klassifizieren, für Qualitäten wie Toxizität oder Policy-Compliance, die eine deterministische Regel nicht zuverlässig kodieren kann. Es kann umgangen werden, weshalb es mit deterministischen Checks verkettet wird. Output-ScreeningEin Check, der vor der Antwort, die den Benutzer erreicht, läuft, um den generierten Inhalt mit einem Modell für Qualitäten wie Toxizität oder einem Validator für bekannte Strings und Schema-Verletzungen zu beurteilen. Tool-Call-AutorisierungEin Check vor jeder Aktion mit einer Nebenwirkung, der entscheidet, ob dieser Aufrufer diese Aktion in diesem Kontext durchführen darf. Es sollte deterministisch sein, eine Allowlist plus Identität und Scope, daher ist die Entscheidung beweisbar und überprüfbar. Training-Zeit-Alignment vs Inference-Zeit-KontrolleTraining-Zeit-Alignment ist das sichere Verhalten, das in das Modell für jeden Benutzer eingebacken ist. Inference-Zeit-Kontrolle ist das Screening und die Autorisierung, die Sie zur Request-Zeit hinzufügen, um Regeln durchzusetzen, die spezifisch für Ihre Bereitstellung sind. Die zwei zu verwechseln lässt bereitstellungsspezifische Regeln unenforced.

Screen 21: Fünf Dinge, die überall hier halten

RecapModule3 min Fünf Dinge, die überall hier halten

Sicherheit ist ein Stack von Schichten, nicht eine Einstellung Training reduziert breite Schäden für jede Anfrage, aber sah nie die Domain-Policy Ihres Partners, Datenregeln oder Autorisierungs-Modell, daher ziehen Sie die Grenze explizit und identifizieren, was jede Schicht abdeckt. Der gefährliche Fehler ist still: Anzunehmen, dass Claude eine Regel durchsetzt, die nicht in einer Schicht lebt.

Ein bewachter Pfad hat drei Kontrollpunkte und eine gewählte Fehler-Richtung Input-Screening, Output-Screening und Tool-Call-Autorisierung beantworten verschiedene Fragen, daher deckt nur ein Filter am Ende nicht die anderen zwei ab. Lassen Sie Kontroll-Fehler für Entscheidungen geschlossen ausfallen, wo ein falscher Pass Schaden verursacht, weil ein Guardrail, das stillschweigend Traffic durchlässt, Ihnen den Anschein von Schutz gibt, ohne irgendeine der Funktionen.

Fairness und Transparenz sind instrumentiert, nicht angenommen Ungleiche Ergebnisse entstehen an Punkten, die Sie kontrollieren, wie das Corpus, Prompt-Rahmung, Beispiele und Routing, daher lässt das Behandeln von Fairness als Vendor-Verantwortung diese Punkte unüberwacht. Loggen Sie jede Entscheidung, daher können Benutzer, Regulatoren und Ihr Team sie rekonstruieren. Wenn Sie eine Erklärung nicht rekonstruieren können, können Sie sie nicht zuverlässig bieten.

Route Review nach Einsatz, nicht nach Volumen Konfidenz, Reversibilität und die Kosten einer falschen Antwort setzen, welche Entscheidungen eine Person überprüfen sollte, daher senden Sie die hohen-Einsatz, niedrig-Konfidenz zu einem Menschen mit den Eingaben und dem Flag-Grund und lassen Sie den Rest durch. Alles zu routen überschwemmt die Warteschlange, bis Reviewer durchklicken, ohne zu lesen.

Ein konformer Einstiegspunkt ist eine Voraussetzung, und ein evidenzierter Kontroll-Satz ist der Beweis Eine Regulation stellt ein Ergebnis dar und lässt Sie die Kontrolle, daher verwandeln Sie jede Verpflichtung in eine spezifische Kontrolle, einen benannten Eigentümer und ein lebendes Beweis-Artefakt, das Sie über die Zeit revalidieren. Eine Kontrolle ohne Eigentümer und ohne Beweis wird schließlich nicht-operativ und schlägt bei der Überprüfung fehl, weil das, das ein Reviewer akzeptiert, Beweis ist, dass die Kontrolle live ist, nicht die Kontrolle selbst.

Was kommt als nächstes Das nächste Modul verschiebt sich vom Bauen einer verantwortungsvollen Bereitstellung zum Übergeben und Verwalten. Sie werden die Architektur, die Sie jetzt evidenzieren können, zu nicht-technischen Stakeholdern kommunizieren, sie zu einem Standard dokumentieren und sie durch den Discovery-to-Hand-Off-Lebenszyklus verwalten. Das Control-Register und die geschichtete Grenze, die Sie hier gebaut haben, werden die Dokumentation und die Baseline, auf die die Handoff ruht.

Quellen

Building with the Claude API (Skilljar Course 4), verwendet für Modell-Grader, Tool-Call-Mechanik, strukturierte Ausgaben und das Evaluator-Muster. platform. claude. com/docs und platform. claude. com, verwendet für Content-Moderation, den Guardrails-Guide, Streaming-Ablehnungen und strukturierte Ausgaben. anthropic. com, verwendet für die Januar-2026-Verfassung und aktuelle Sicherheits-Postur. Anthropic Trust Center und Privacy Center, verwendet für HIPAA, FedRAMP und Daten-Residenz-Postur. Architect M1 und M2 Storyboards, verwendet, um zu referenzieren statt zu re-lehren, Eigentümer-Zuordnung, Referenz-Architekturen, Modell- und Kontext-Strategie, Evals, Integrations-Layer und Observability.

Sie können KI-Systeme entwerfen, die Sicherheits- und Compliance-Anforderungen erfüllen. Kontroll-Design, Beweis-Sammlung, Eigentümer-Zuordnung und Audit-Bereitschaft, eine Kontrolle ohne Eigentümer und ohne Beweis schlägt fehl, wenn es am meisten zählt.

Screen 22: Glückwunsch! Sie haben dieses Modul erfolgreich abgeschlossen.

Modul Abgeschlossen · Architect · 2 min Glückwunsch! Sie haben dieses Modul erfolgreich abgeschlossen. Modul 3 behandelt die Sicherheits-Frameworks, Risiko-Kategorien und Kontroll-Design-Entscheidungen, die verantwortungsvolle KI-Architekten vor und während der Produktions-Bereitstellung anwenden. Ein bewachter Pfad ist nicht ein Filter am Ende, es ist eine Kontrolle an jedem Punkt, wo Schaden eindringen kann.

0 von 0 Checkpoints bestanden

Claude-Plattform & Lösungs-Design Modell-Auswahl, Prompt-Architektur, Tool-Design und Plattform-Layer-Tradeoffs.

Enterprise-Integration & Produktion Bereitstellungs-Muster, Integrations-Architektur und Produktions-Zuverlässigkeit.

Verantwortungsvolle KI, Sicherheit & Risiko Sicherheits-Frameworks, Risiko-Identifikation und Governance-Praktiken.

Sie sind hier

Stakeholder-Engagement, Lebenszyklus & Go-to-Market Stakeholder-Kommunikation, Lebenszyklus-Management und Go-to-Market-Strategie.

Team-Befähigung und Operative Produktivität Team-Tooling-Konfiguration und operative Support-Praktiken.

Modul überprüfen Von vorne beginnen