Prove It, Teil 3: Eine Schritt-für-Schritt-Anleitung zur Implementierung von Automated Reasoning

In diesem Handbuch erfahren Sie, wie Sie eine Automated-Reasoning-Richtlinie aus einem vorhandenen Geschäftsdokument erstellen, sie über Amazon-Bedrock-Integritätsschutz bereitstellen, LLM-Antworten mit ApplyGuardrail validieren, einen Audit Trail erstellen und KI-Agenten mit AgentCore Policy schützen. Mithilfe dieses Prozesses können Teams in nur 30 Minuten vom Compliance-Dokument zur Produktionsüberprüfung übergehen.

Im 1. Teil („Warum ‚wahrscheinlich richtig‘ nicht gut genug ist“) haben wir uns damit befasst, warum Startups eine deterministische Verifizierung benötigen. Im 2. Teil („Formale Logik, Cedar-Richtlinien und die Wirtschaftlichkeit der Verifizierung“) haben wir die Verifizierungspipeline und die Mathematik dahinter erklärt. Jetzt ist es an der Zeit, Lösungen zu entwickeln.

Was brauchen Sie, bevor Sie beginnen?

Bevor Sie beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:

• Ein AWS-Konto mit Amazon-Bedrock-Zugriff. Wenn Sie Teil von AWS Activate sind, verfügen Sie bereits über Guthaben dafür.
• Python 3.9+ mit boto3.Wenn Sie einen MVP versendet haben, haben Sie dies.
• Ein Richtliniendokument (PDF, Markdown oder Klartext), in dem Ihre Geschäftsregeln beschrieben werden. Wenn Sie eine Compliance- oder Due-Diligence-Prüfung durch Investoren bestanden haben, verfügen Sie über dieses Dokument.

Schritt 1: Ihre AR-Richtlinie erstellen

Der schnellste Weg führt über die AWS-Konsole. Sie müssen keine formale Logik schreiben, da Bedrock Ihr Quelldokument automatisch in formale Logikregeln übersetzt.

1. Öffnen Sie die Bedrock-Konsole und navigieren Sie in der linken Seitenleiste zu Automated Reasoning.
2. Erstellen Sie eine neue Richtlinie.Geben Sie ihr einen aussagekräftigen Namen (z. B. Richtlinie zur Hypothekenberechtigung).
3. Laden Sie Ihr Quelldokument hoch. Dies ist die PDF-, Word-Dokument- oder Klartextdatei, die Ihre Geschäftsregeln beschreibt. Für ein Fintech-Startup könnte dies Ihr Dokument mit den Kreditkriterien sein. Für das Gesundheitswesen Ihre klinischen Protokolle.
4. Geben Sie Anweisungen. Schreiben Sie eine kurze Absicht, in der Sie beschreiben, was die Richtlinie validiert, und fügen Sie 2–3 Beispiele für Frage-Antwort-Paare hinzu. Diese helfen dem System zu verstehen, wie Benutzer mit der Richtlinie interagieren werden.

Für Teams, die es vorziehen, die Konsole nicht zu verwenden, gibt es auch eine Konversationsoberfläche für die Erstellung von Richtlinien, die Sie in natürlicher Sprache durch die Formalisierung führt. Es gibt einige Voraussetzungen (einschließlich Kiro-CLI), die Konsole wird jedoch vollständig aus dem Arbeitsablauf entfernt.

Beispiel für eine Absicht:

Diese Richtlinie validiert Fragen zur Hypothekenberechtigung. Benutzer fragen, ob Kunden aufgrund ihrer finanziellen Daten für bestimmte Hypothekentypen in Frage kommen.

Beispiel für Fragen und Antworten:

F: Ein Kunde möchte ein Haus im Wert von 350 000 USD mit einer Anzahlung von 30 000 USD kaufen. Erfüllt er die Voraussetzungen für eine konventionelle Hypothek?

A: Nein. Herkömmliche Hypotheken erfordern eine Anzahlung von mindestens 20 Prozent (70 000 USD für einen Kauf in Höhe von 350 000 USD).

Treuebericht lesen:

Nachdem das System Ihr Dokument verarbeitet hat, generiert es einen Treuebericht mit 2 Werten:

• Deckungswert (0,0 bis 1,0): Wie viel von Ihrem Quelldokument in der Richtlinie enthalten ist
• Genauigkeitswert (0,0 bis 1,0): Wie genau die extrahierten Regeln der Absicht Ihres Dokuments entsprechen

Der Bericht zeigt auch die spezifischen Variablen und Regeln, die extrahiert wurden, wobei auf exakte Aussagen in Ihrem Quelldokument zurückgegriffen wird. Hier überprüfen Sie, ob das System Ihre Regeln richtig verstanden hat.

Verfeinern Sie Ihre Variablenbeschreibungen anhand konkreter Beispiele aus Ihrer Anwendung. Testen Sie repräsentative Fragen, überprüfen Sie, wie das System diese übersetzt, und verbessern Sie die Beschreibungen, wo immer die Übersetzungen nicht zutreffend sind. Dies ist der wichtigste Faktor für die Genauigkeit. Schließen Sie nach Möglichkeit Einheiten, Synonyme, Konvertierungsregeln und domainspezifische Terminologie ein. Eine Beschreibung wie „Die Anzahlung des Kreditnehmers als Prozentsatz des Kaufpreises; wenn Benutzer Dollarbeträge angeben, rechne diese mit (downPayment / purchasePrice) * 100 um“ ist besser geeignet als „Wie viel der Kreditnehmer anzahlt.“

Dies ist kein Entwicklungsprojekt, das mehrere Sprints in Anspruch nimmt. In nur 30 Minuten gelangen Sie von Ihrem bestehenden Compliance-Dokument zu einer funktionsfähigen AR-Richtlinie. Überarbeiten Sie die Variablenbeschreibungen und testen Sie mit Beispielfragen, bis die Genauigkeitswerte und Testergebnisse Ihren Erwartungen entsprechen.

Den API-Pfad (nützlich für CI/CD-Pipelines) finden Sie in der CreateAutomatedReasoningPolicy-API-Referenz. Die API benötigt einen Namen, eine optionale Beschreibung und eine policyDefinition, die Regeln, Variablen und benutzerdefinierte Typen enthält.

Schritt 2: Auf einem Integritätsschutz bereitstellen

Sobald Ihre Richtlinie erfolgreich getestet wurde, stellen Sie sie für den Produktionseinsatz bereit.

Speichern Sie eine unveränderliche Version. Wählen Sie in der Konsole „Als neue Version speichern“. Dadurch wird ein nummerierter, unveränderlicher Snapshot (Version 1, 2, 3 …) erstellt, sodass Ihr Produktions-Integritätsschutz nicht beeinträchtigt wird, wenn Sie den ENTWURF weiter bearbeiten. So können Startups sicher und schnell neue Versionen bereitstellen: Ihr Compliance-Team überprüft Version 1 in der Produktion, während Ihr Entwicklungsteam an Version 2 im Entwurfsstadium weiterarbeitet. Keine Bereitstellungssperren, kein „Bitte die Richtlinie nicht ändern, bis wir sie veröffentlichen.“

Sobald Sie eine Version Ihrer Richtlinie veröffentlicht haben, verknüpfen Sie sie mit einem Integritätsschutz, damit sie bei der Laufzeitvalidierung verwendet werden kann:

Die wichtigsten Details:

• policies benötigt ein Array von Richtlinien-ARN-Zeichenfolgen (maximal 2), keine Objekte
• confidenceThreshold (optional, 0,0 bis 1,0) steuert den Mindestgrad an Übereinstimmung, ab dem Übersetzungen als zuverlässig gelten. Niedrigere Werte (0,3) liefern früher mehr Ergebnisse; höhere Werte (1,0) optimieren streng aus Zuverlässigkeit. Beginnen Sie während der Entwicklung mit niedrigen Werten und verschärfen Sie die Kriterien für die Produktion.
• crossRegionConfig ist für AR-Prüfungen erforderlich; es ermöglicht regionsübergreifende Inferenzen für die Bewertung von Integritätsschutz. Verwenden Sie das Profil für Ihre Region (z. B. us.guardrail.v1:0 für USA, eu.guardrail.v1:0 für EU)
• blockedInputMessaging und blockedOutputsMessaging sind erforderlich. Dies sind die Fallback-Meldungen, die angezeigt werden, wenn andere Integritätsschutzkomponenten (nicht AR) Inhalte blockieren
• Verwenden Sie eine nummerierte Version (:1) im ARN für die Produktion. Reservieren Sie DRAFT nur für Entwicklungszwecke

Schritt 3: LLM-Antworten mit ApplyGuardrail validieren

Das empfohlene Integrationsmuster ist die eigenständige ApplyGuardrail-API. So haben Sie die volle Kontrolle darüber, welche Inhalte wann validiert werden. Dies ist der Ansatz, den die AWS-Dokumentation ausdrücklich für AR-Prüfungen empfiehlt.

Hier ist ein minimales Integrationsbeispiel, das zu Ihrer bestehenden Inferenz-Pipeline hinzugefügt wurde:

Rufen Sie dies auf, nachdem Ihr LLM eine Antwort generiert hat, bevor Sie sie dem Benutzer bereitstellen:

Wichtig: AR-Prüfungen werden im Erkennungsmodus ausgeführt. Sie geben Erkenntnisse und Feedback zurück. Sie blockieren oder schreiben die Antwort nicht automatisch um. Ihre Anwendung prüft die Erkenntnisse und entscheidet, was zu tun ist.

Schritt 4: Erkenntnisse bearbeiten

Bei jeder Erkenntnis handelt es sich um einen Unionstyp mit genau einem Schlüssel. So lassen sie sich analysieren und verarbeiten:

Das Standardmuster zur Fehlerbehebung besteht aus einer Schleife aus Validierung und Neuschreiben: Die Antwort wird validiert, etwaige Verstöße werden an das Modell zurückgegeben, die Antwort wird erneut generiert und erneut validiert. Dieser Vorgang wird so lange wiederholt, bis die Antwort gültig ist oder ein Limit für Wiederholungsversuche erreicht ist.

Ihr Benutzer bekommt von dieser Umschreib-Schleife nichts mit. Er erhält bereits beim ersten Versuch eine korrekte Antwort. Die Iteration findet hinter den Kulissen im Millisekundenbereich statt.

Schritt 5: Audit Trail entwickeln

Jede Überprüfungsiteration sollte protokolliert werden. Wenn Ihr Unternehmenskunde SOC-2-Nachweise anfordert oder Ihre Aufsichtsbehörde wissen möchte, wie Sie eine bestimmte Entscheidung überprüft haben, rufen Sie das JSON-Protokoll ab. Jede Überprüfung ist mit einem Zeitstempel versehen und rückverfolgbar.

Dieses Protokoll wird zu Ihrem Compliance-Artefakt. Es zeigt, was der Benutzer gefragt hat, was das LLM generiert hat, was AR gefunden hat und welche Maßnahmen Ihre Anwendung ergriffen hat. Für Startups, die SOC 2, HIPAA-Compliance oder Unternehmensverkäufe anstreben, ist dieser Prüfpfad nicht optional. Es ist der Beweis dafür, dass Ihr System wie dokumentiert funktioniert.

Schritt 6: Ihre Agenten mit AgentCore Policy schützen

Wenn Ihr Startup von Chatbots zu agentenbasierten Workflows übergegangen ist (Ihre KI vereinbart Termine, verarbeitet Rückerstattungen, fragt Datenbanken ab oder versendet E-Mails), müssen Sie Grenzen festlegen, was Ihr Agent tun darf – nicht nur, was er sagt.

Policy in Amazon Bedrock AgentCore verwendet Cedar, um diese Grenzen zu definieren. Beispielsweise benötigt ein Mitarbeiter für die Terminplanung im Gesundheitswesen Richtlinien, die einschränken, auf welche Patientendaten er zugreifen kann, die Terminplanung auf die Geschäftszeiten beschränken und verhindern, dass Rückerstattungen über einem bestimmten Schwellenwert ohne Zustimmung des Managers bearbeitet werden. Beginnen Sie im Modus LOG_ONLY, um zu beobachten, was Ihr Agent tut, ohne etwas zu blockieren. Sobald Sie den Richtlinien vertrauen, wechseln Sie für die Produktion in den ENFORCE-Modus.

Das Gateway ist die Durchsetzungsebene zwischen Ihrem Agenten und dessen Tools. Jeder Tool-Aufruf durchläuft das Gateway, wo die Cedar-Richtlinien evaluiert werden, bevor die Anfrage das Ziel erreicht. Dadurch wird die Durchsetzung deterministisch und unabhängig vom Reasoning des Agenten: Der Agent kann das Gateway nicht umgehen, ignorieren oder sich daran vorbeireden.

Richten Sie ein Gateway und eine Richtlinien-Engine mithilfe der AgentCore CLI ein:

Schreiben Sie eine Cedar-Richtlinie und hängen Sie sie an die Richtlinien-Engine an. Das folgende Beispiel zeigt anschauliche Richtlinien für einen Agenten zur Terminvereinbarung im Gesundheitswesen. In der Praxis werden Ihre Aktionsnamen automatisch aus Ihrem Gateway-Ziel und Ihrem Tool-Schema generiert (z. B. HealthTarget__get_patient_record), und die Ressource muss auf Ihren spezifischen Gateway-ARN verweisen:

Cedar folgt dem Modell der Standard-Verweigerung: Jede Interaktion zwischen Agent und Tool wird blockiert, sofern sie nicht durch eine explizite Genehmigungsrichtlinie erlaubt ist. Ihre Genehmigungsrichtlinien legen fest, welche Tools der Agent unter welchen Bedingungen aufrufen darf. Die unten aufgeführten Verbotsrichtlinien enthalten Ausnahmen und blockieren bestimmte Szenarien, selbst wenn eine allgemeinere Genehmigung diese ansonsten zulassen würde.

Speichern Sie dies als healthcare_policy.cedar und hängen Sie es dann an die Richtlinien-Engine an:

Alternativ können Sie Ihre Regeln in natürlicher Sprache beschreiben und das System Cedar für Sie generieren lassen (erfordert, dass das Gateway zuerst bereitgestellt wird):

Automated Reasoning validiert die Richtlinien bei der Erstellung und erkennt übermäßig permissive, übermäßig restriktive oder ineffektive Regeln vor der Bereitstellung.

Die wichtigsten Eigenschaften, die für regulierte Startups wichtig sind:

• Standard-Verweigerung: Wenn eine Richtlinie eine Aktion nicht ausdrücklich erlaubt, wird sie blockiert
• Verbot hat immer Vorrang: Feste Regeln können nicht durch andere Richtlinien außer Kraft gesetzt werden
• Deterministische Durchsetzung: Erfolgt an der Gateway-Grenze, außerhalb vom Reasoning Ihres Agenten. Kann nicht durch Promptinjektion, Halluzination oder Bugs umgangen werden

Starten Sie im LOG_ONLY-Modus, um zu sehen, was Ihr Agent tut, ohne Ihr Produkt zu beeinträchtigen. Die Protokolle zeigen, welche Richtlinie bei jeder Anfrage an das Gateway angewendet wurde, wie die Richtlinienentscheidung ausfiel (Zulassen oder Verweigern), und es werden nicht übereinstimmende Richtlinien aufgedeckt, wenn es zu einer Tool-Abweichung kommt. Überprüfen Sie diese. Optimieren Sie die Richtlinien. Wenn Sie überzeugt sind, wechseln Sie in den ENFORCE-Modus. So gelangen Sie vom Prototyp zur Produktion, ohne Ihre Benutzer zu beeinträchtigen.

Vollständige Beispiele, einschließlich Bereitstellungsskripten und Testeinsätzen, finden Sie in den Amazon-Bedrock-AgentCore-Beispielen auf GitHub.

Was passiert, nachdem Sie Automated Reasoning bereitgestellt haben?

Sobald Sie AR-Prüfungen und AgentCore Policy ausgeführt haben, erschließen Sie etwas Wertvolleres als die Fehlervermeidung: eine einzige Informationsquelle.

Ihre AR-Richtlinie besteht aus Ihren Geschäftsregeln, die als formale Logik kodiert sind. Wenn sich diese Regeln ändern (und das tun sie immer: neue Vorschriften, aktualisierte Kreditvergabekriterien, überarbeitete klinische Protokolle), aktualisieren Sie das Quelldokument, generieren die Richtlinie neu und sofort entspricht jedes KI-System in Ihrem Stack den neuen Regeln. Kein zu aktualisierendes Prompt-Engineering. Kein erneutes Training der Modelle. Keine Hoffnung, dass jemand daran gedacht hat, den System-Prompt zu ändern.

Dadurch wird eine ganze Klasse von Drift-Bugs eliminiert. Ihre Dokumentation und Ihr KI-Verhalten sind mathematisch miteinander verknüpft. Sie können nicht aus dem Takt geraten.

Da Integritätsschutz modellunabhängig sind, bleibt Ihre Überprüfungsebene dieselbe, wenn Sie das Basismodell wechseln. Dieselbe AR-Richtlinie, die Claudes Antworten verifiziert hat, verifiziert auch die von Amazon Nova. Die Regeln hängen von Ihrer Geschäftslogik ab, nicht vom Modell.

Die Integration erstreckt sich über das gesamte Bedrock-Ökosystem: AR-Richtlinien funktionieren mit Wissensdatenbanken für Retrieval-Augmented Generation, mit AgentCore-Agenten für mehrstufige Workflows und mit der gesamten Palette von Basismodellen. Sie bauen auf einer Plattform, nicht auf einer Einzellösung.

Weitere Informationen

• Dokumentation zu Automated-Reasoning-Prüfungen
• AR-Konzepte (Variablen, Regeln, Erkenntnisse)
• Integrationsleitfaden (ApplyGuardrail-Muster)
• Dokumentation zu AgentCore Policy
• AgentCore-Beispiele auf GitHub
• Überblick über AWS Provable Security
• Was ist Automated Reasoning?
• Cedar-Sprache (CNCF)

Das ist der Abschluss unserer Reihe AR für Startups

In der gesamten Prove-It-Reihe war unsere These dieselbe: Startups, die auf KI aufbauen, benötigen deterministische, mathematische Verifikationen, nicht nur probabilistische Schutzmaßnahmen.

Im 1. Teil haben wir uns damit befasst, warum das Vertrauensproblem für Startups existenziell ist und wie die jahrzehntelange Arbeit von AWS im Bereich formeller Methoden zum Bedrock-Integritätsschutz und zu AgentCore Policy geführt hat.

Im 2. Teil haben wir die formale Logik, die Verifizierungspipeline und die Wirtschaftlichkeit genauer unter die Lupe genommen. In diesem Beitrag haben Sie den kompletten Implementierungsweg von den vorhandenen Compliance-Dokumenten bis hin zur produktionsreifen, verifizierten KI kennengelernt.

Die Startups, die im Zeitalter der KI erfolgreich sein werden, werden nicht nur intelligente Systeme entwickeln, sondern Systeme, deren Korrektheit sie nachweisen können. Automated Reasoning und AgentCore Policy machen dies bereits heute möglich – unter Verwendung der Richtlinien und Compliance-Dokumente, über die die meisten Unternehmen bereits verfügen. Die einzige Frage, die noch offen bleibt, lautet: Fangen Sie jetzt damit an oder erst, wenn der erste Vorfall Sie dazu zwingt?