Claude Code über Amazon Bedrock: der kontrollierte Pfad für regulierte Daten

Beginnen Sie mit dem, was tatsächlich schiefgehen kann

Die meisten Diskussionen darüber, ob ein Coding-Agent „sicher“ ist, beginnen an der falschen Stelle. Sie fragen, ob man dem Modell vertrauen kann: ob es halluziniert, ob es Daten preisgibt, ob der Anbieter mit den Eingaben trainiert. Berechtigte Fragen. Aber bevor Sie irgendeine Anbieter-Checkliste durchgehen, benennen Sie die Probleme. Wenn ein Unternehmen eine KI arbeiten lässt, sind drei verschiedene Klassen sensibler Daten im Spiel, dazu ein viertes Problem, das mit Daten gar nichts zu tun hat.

Personenbezogene Daten. Alles über identifizierbare Personen (Kunden, Mitarbeiter, Bewerber) fällt unter die DSGVO. Wo diese Daten verarbeitet werden dürfen, von wem, unter welchen Verträgen, wie lange: Das sind Rechtsfragen, und sie entscheiden sich daran, wohin die Daten fließen, nicht daran, wie gut das Modell ist.

Geschäftsgeheimnisse. Preise, Quellcode, Verträge, Roadmaps, Deal-Unterlagen. Keine Aufsichtsbehörde wacht über diese Klasse, aber der Verlustmechanismus ist härter: Ein geleaktes Geschäftsgeheimnis ist einfach weg. Entscheidend sind hier Speicherfristen, Unterauftragsverarbeiter und die Frage, ob irgendetwas, das Sie senden, an einem Ort wieder auftauchen kann, den Sie nicht kontrollieren.

Berufsgeheimnis. Ärzte, Anwälte, Steuerberater, Wirtschaftsprüfer: Berufe, in denen Verschwiegenheit eine gesetzlich geschützte Pflicht mit persönlicher Haftung ist und weit über jede Unternehmensrichtlinie hinausreicht. Für diese Klasse ist „der Anbieter wirkt vertrauenswürdig“ keine zulässige Antwort. Sie müssen anhand von Belegen zeigen können, wohin die Daten gegangen sind – und wohin nicht.

Das vierte Problem entsteht in dem Moment, in dem die KI aufhört, ein Chat-Fenster zu sein, und zum Agenten wird: Sie handelt. Ein Coding-Agent mit Shell-Zugriff kann einen Befehl genauso halluzinieren wie ein Chat-Modell eine Quellenangabe. Nur wird diese Halluzination ausgeführt. Er kann Dateien löschen, eine Konfiguration überschreiben, auf das falsche Remote pushen, einen Request an ein Produktivsystem absetzen. Eine falsche Antwort kostet Sie eine Korrektur; ein falscher Befehl kostet Sie das, was das betroffene System gerade gehalten hat.

Ein ernsthaftes Setup muss alle vier Probleme beantworten. Behalten Sie diese Liste im Blick, denn die Antworten liegen nicht alle an einer Stelle, und keine einzelne Produkteinstellung deckt sie ab.

Was Sie absichern müssen, ist nicht das Modell

Sehen Sie, was diese vier Probleme gemeinsam haben: Keines davon löst sich dadurch, dass Sie dem Modell mehr vertrauen.

In dem Moment, in dem Sie einem Coding-Agenten Shell-Zugriff, ein Dateisystem und Netzwerkzugang geben, ist das Objekt, das Sie absichern müssen, nicht mehr das Modell. Es ist der Arbeitsbereich des Agenten, und alles, was dieser Arbeitsbereich erreichen kann. Ein öffentliches Repository ist ein G0-Asset, nichts Sensibles, nichts zu verlieren: genau so lange, bis der Agent in diesem Repo .env lesen, die Logs mitverfolgen, eine Ticket-Queue öffnen, eine Produktionskonfiguration laden, unter einer Commit-Identität handeln oder einen Ausschnitt Mandantenkontext hereinziehen kann. Ab diesem Punkt ist der Arbeitsbereich faktisch G3. Das Modell war nie die Variable, die sich geändert hat. Geändert hat sich die Reichweite: welche der drei Datenklassen der Agent jetzt berühren kann, und was sein handelnder Arm jetzt zerstören kann.

In meiner täglichen Arbeit (Agenten, die gegen Systeme mit echten berufsgeheimnisgeschützten Daten laufen) ist genau diese Verschiebung das ganze Spiel. Sie entscheiden nicht abstrakt, ob Sie einem Modell vertrauen. Sie entscheiden, was ein schneller, unermüdlicher, gelegentlich mit voller Überzeugung falschliegender Prozess anfassen darf – und Sie belegen anhand von Evidenz, dass er nur genau das anfassen kann.

Dieser Text ist eine Bauanleitung für genau das. Am Ende haben Sie Claude Code über Amazon Bedrock geroutet, in einer Region Ihrer Wahl, unter einer Identität, die genau ein festgeschriebenes Modell aufrufen kann, umgeben von einer Eingrenzungsschicht, die begrenzt, was der Agent tun darf, dazu einen Weg, zu verifizieren statt anzunehmen, dass der Traffic dorthin ging, wohin Sie ihn geschickt haben. Das Ganze ist unspektakulär, es ist günstig, und jedes Einzelteil ist heute verfügbar.

Was Sie bauen und was Sie vorher brauchen

Hier ist die gesamte Form in einem Absatz. Claude Code läuft wie immer auf Ihrem Rechner; statt den Standard-Consumer-Endpunkt aufzurufen, zeigt eine Umgebungsvariable auf Amazon Bedrock: auf ein AWS-Konto und eine Region unter Ihrer Kontrolle, mit einem gepinnten Modell, das der Agent aufrufen darf, und sonst nichts. Um diesen Aufruf herum sitzt eine Sandbox: eine Allowlist von Dateien und Tools, standardmäßig Nur-Lesen und harte Obergrenzen dafür, wie weit ein einzelner Lauf kommen kann. Davor sitzt lokale Vorverarbeitung: der Schritt, in dem Geheimnisse und personenbezogene Daten entfernt werden, bevor irgendetwas den Rechner verlässt. Das ist das Ziel.

Sie brauchen vier Dinge und keine exotische Infrastruktur: eine AWS-Organisation, in der Sie ein neues Konto anlegen können; die Möglichkeit, Bedrock-Modellzugriff zu beantragen; ein installiertes Claude Code; und genug Terminal-Routine, um eine JSON-Settings-Datei zu bearbeiten und ein paar aws-Befehle auszuführen.

Und seien Sie sich im Klaren: Das hier ist eine Antwort, nicht die einzige. Ein Consumer-Chat-Konto gibt Ihnen weder Kontrolle über die Zugangsdaten noch über die Region, die beiden Dinge, auf denen ein regulierter Workload aufbaut. Und „sie trainieren nicht mit meinen Daten“ ist eine echte Zusage zu genau einem Punkt und schweigt zu den anderen: Kein Training heißt nicht keine Übermittlung, und Verarbeitungsort, Unterauftragsverarbeiter und Speicherfristen sind separate Zusagen, die ein Consumer-Login Sie nicht festlegen lässt. Ein Enterprise-Vertrag beim Anbieter ergänzt die Vertragsebene (einen Auftragsverarbeitungsvertrag, Admin-Kontrollen), lässt Zugangsdaten und Routing aber weiter in der Hand des Anbieters. Das Routing über eine Cloud, die Sie bereits selbst governen (hier Amazon Bedrock, mit Gegenstücken bei den anderen Hyperscalern) stellt das Modell hinter Ihr eigenes IAM, Ihre Regionswahl und Ihr Audit-Log; genau davon handelt dieser Artikel. Und Sandbox- oder lokale Eingrenzung (ein Agent, eingesperrt in einen freigegebenen Arbeitsbereich, ohne Reichweite darüber hinaus) greift das vierte Problem, den handelnden Agenten, am direktesten an; ernsthafte Setups kombinieren sie mit einer der Routing-Optionen. Dieser Beitrag ist der erste einer Serie, die diese Pfade einzeln abschreitet: jetzt AWS, Sandboxes und Eingrenzung in den folgenden Teilen. Bedrock ist die Tür, an der die Schlösser sitzen; der Rest dieses Artikels baut sie ein.

Ein dediziertes AWS-Konto mit Bedrock-Modellzugriff aufsetzen

Beginnen Sie mit dem Konto, denn das Konto ist die Grenze, an der alles andere hängt.

Legen Sie dafür ein dediziertes AWS-Konto an, keine Ecke in einem geteilten. Ein separates Konto ist Ihr Blast Radius, Ihre Abrechnungslinie und Ihr Regionszaun in einem einzigen Objekt. Falls der Workload des Agenten jemals eingefroren, auditiert oder abgerissen werden muss, soll er an einem Ort mit sauberen Kanten liegen.

Wählen Sie die Region bewusst, denn für regulierte Arbeit in Europa ist die Region eine Frage der Datenresidenz, nicht der Latenz. Und seien Sie präzise dabei, was „Region“ tatsächlich kauft; genau hier rutschen Teams aus. Zwei Dinge sind im Spiel. Erstens: Die Quellregion, die Sie aufrufen (die, die Sie mit AWS_REGION setzen), ist nicht zwingend der Ort, an dem die Inferenz läuft: Bedrocks regionsübergreifende Inference-Profile können den eigentlichen Modellaufruf in eine Zielregion an anderer Stelle innerhalb der Geographie des Profils routen. Zweitens: Das „EU“-Label von AWS auf diesen Profilen ist ein AWS-Routing-Konstrukt, keine rechtliche EU/EWR-Residenzgarantie: Die AWS-Gruppierung „Europa“ kann Standorte außerhalb der EU und des EWR enthalten (London / eu-west-2 gehört zu AWS Europe, aber das Vereinigte Königreich liegt außerhalb der EU/des EWR). Lesen Sie ein Profil mit eu.-Präfix also nicht für sich genommen als DSGVO-Residenz.

Für einen Workload mit Berufsgeheimnis-Daten gehen Sie in dieser Reihenfolge vor: Entscheiden Sie zuerst, wo die Daten rechtlich verarbeitet werden dürfen. Lesen Sie dann die Zielregions-Liste des konkreten Profils auf der Detailseite des Modells und bestätigen Sie, dass jede mögliche Zielregion akzeptabel ist. Die AWS-Referenz zu Inference-Profilen ist die kanonische Quelle für diese Liste. Bedrock ist in mehreren europäischen AWS-Regionen verfügbar (Frankfurt / eu-central-1, Irland / eu-west-1 und Paris / eu-west-3 liegen in der EU; London / eu-west-2 nicht), und die Modellverfügbarkeit variiert je Region: Das gewünschte Claude-Modell ist womöglich nicht überall freigeschaltet. Wählen Sie zuerst nach rechtlicher Residenz; bestätigen Sie danach, dass Modell und Routing die Daten dort halten, wo sie bleiben müssen.

Beantragen Sie jetzt den Bedrock-Modellzugriff für das Claude-Modell, das Sie pinnen wollen. In der Bedrock-Konsole ist das der Screen „model access“; der Zugriff wird pro Konto gewährt, und Sie schalten nur das Modell frei, das Sie brauchen. Über die CLI prüfen Sie, unter welcher Identität Sie arbeiten und welche Modelle und Profile in Ihrer Region sichtbar sind:

aws sts get-caller-identity
aws bedrock list-inference-profiles --region eu-central-1
aws bedrock list-foundation-models --region eu-central-1

Beachten Sie: list-foundation-models liefert alles in der Region zurück, unabhängig davon, ob Ihnen Zugriff gewährt wurde. Sichtbarkeit ist nicht dasselbe wie eine Freigabe. Bestätigt wird die Freigabe im „model access“-Screen der Konsole, und der endgültige Beleg ist ein Testaufruf, den Sie in CloudTrail verifizieren (nächster Schritt).

Der Zugriff allein ist mehr Macht, als der Agent haben sollte. Schränken Sie ihn ein, bevor Sie irgendetwas darauf richten.

IAM absichern und das Modell pinnen

Das ist der Sicherheitskern: eine Identität, die genau eine Sache aufrufen kann.

Legen Sie eine dedizierte IAM-Rolle oder einen dedizierten IAM-User für den Agenten an, mit einer Policy, die Bedrock-Modellaufrufe gewährt und nichts darüber hinaus: kein bedrock:*. Die Starter-Policy aus der kanonischen Anthropic-Bedrock-Dokumentation ist eine ehrliche Basis:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowModelAndInferenceProfileAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListInferenceProfiles",
        "bedrock:GetInferenceProfile"
      ],
      "Resource": [
        "arn:aws:bedrock:*:*:inference-profile/*",
        "arn:aws:bedrock:*:*:application-inference-profile/*",
        "arn:aws:bedrock:*:*:foundation-model/*"
      ]
    },
    {
      "Sid": "AllowMarketplaceSubscription",
      "Effect": "Allow",
      "Action": [
        "aws-marketplace:ViewSubscriptions",
        "aws-marketplace:Subscribe"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:CalledViaLast": "bedrock.amazonaws.com" }
      }
    }
  ]
}

Hängen Sie die Policy an und bestätigen Sie, dass die Identität auflöst:

aws iam put-role-policy --role-name claude-code-bedrock \
  --policy-name bedrock-invoke-pinned --policy-document file://bedrock-policy.json
aws sts get-caller-identity

Zwei Anmerkungen zu dieser Policy. Das Statement AllowMarketplaceSubscription erlaubt dem Konto, das Modell bei der ersten Nutzung zu abonnieren; sobald das Abonnement existiert (oft zentral verwaltet), können Sie es entfernen. Und lesen Sie die Wildcards unter Resource als To-do, nicht als Endzustand: Sie erlauben der Identität, jedes Profil und jedes Foundation Model aufzurufen. Für das Setup bequem, für ein gepinntes Deployment zu locker. Das ist Ihr harter Backstop: Ersetzen Sie die Wildcards durch die exakte Region und den exakten ARN des Inference-Profils (oder Foundation Models), das Sie gepinnt haben. IAM-Resource-Scoping, nicht eine Umgebungsvariable, ist das, was den Agenten tatsächlich davon abhält, ein Modell zu erreichen, das Sie nicht freigegeben haben.

Pinnen Sie das Modell explizit: Schreiben Sie die Modellversion fest, statt auf „latest“ zu treiben. Diese Anweisung wird oft ausgegeben und selten erklärt, deshalb hier das Warum vor dem Wie. Eine Modellversion ist kein austauschbares Bauteil: Jede verhält sich anders, ist anders bepreist und trägt ihre eigenen Datenverarbeitungsbedingungen. „Latest“ bedeutet: Alle drei können sich unter einem bereits validierten Workflow ändern, ohne dass irgendjemand in Ihrer Organisation das entschieden hat. Das Pinning dreht das um und kauft vier Dinge, die ein reguliertes Deployment braucht:

• Reproduzierbarkeit. Der Workflow, den Sie getestet haben, ist der Workflow, der läuft; dieselbe Aufgabe verhält sich im nächsten Quartal gleich. Ohne Pin hören „es hat in der Prüfung funktioniert“ und „das läuft heute“ leise auf, dieselbe Aussage zu sein.
• Änderungskontrolle. Ein Modell-Upgrade wird zu dem, was jedes Risikoframework für eine Änderung an einem System mit sensiblen Daten verlangt: eine Entscheidung mit Datum, Verantwortlichem und Test, statt etwas, das Ihnen zugestoßen ist.
• Kostenvorhersagbarkeit. Die Preise pro Token unterscheiden sich je Modell; ein stiller Modellwechsel ist eine stille Budgetänderung.
• Die Audit-Spur. „Welches Modell hat diese Daten verarbeitet, und unter welchen Bedingungen?“ ist eine Frage, die ein Datenschutzbeauftragter oder Auditor stellen wird, und die Bedingungen hängen am exakten Modell. Der Abuse-Detection-Vorbehalt am Ende dieses Artikels ist ein lebendes Beispiel dafür, dass sich Speicherbedingungen von Modell zu Modell unterscheiden. Wer das Modell nicht benennen kann, kann die Bedingungen nicht benennen.

Nun die Mechanik. Bedrock-Modellbezeichner sind regionsübergreifende Inference-Profil-IDs mit Geographie-Präfix: us. für die USA, eu. für die EU-Gruppierung, us-gov. für GovCloud, nach dem Muster <geo>.<provider>.<model>. Das Präfix wählt die Routing-Geographie, keine Residenzgarantie (siehe den Regionsvorbehalt oben): Ein eu.-Profil routet nur innerhalb der Zielregions-Liste des Profils, die Sie trotzdem lesen und akzeptieren müssen. Verifizieren Sie die exakte aktuelle Profil-ID und ihre Zielliste auf der Detailseite des Modells, bevor Sie sich darauf verlassen. AWS hat dieses Detail auf die einzelnen Modellseiten verlagert, und Modell-IDs rotieren. (Das im Beispiel unten verwendete eu.anthropic.claude-sonnet-4-6 war am 10.07.2026 aktuell; prüfen Sie es zum Bauzeitpunkt erneut.)

Die Umgebungsvariable zu pinnen ist nicht dasselbe wie das Modell zu erzwingen: Ein Nutzer kann innerhalb einer Session weiterhin das Modell wechseln. Zwei Dinge schließen diese Lücke: Verwaltete Claude-Code-Settings (availableModels plus enforceAvailableModels) begrenzen, welche Modelle eine Session auswählen darf (siehe die Doku zur Modellkonfiguration); und darunter ist das IAM-Resource-Scoping aus dem letzten Schritt der harte Stopp, an dem sich keine Client-Einstellung vorbeireden kann.

Zu den Zugangsdaten: Claude Code nutzt die Standard-Credential-Kette des AWS SDK. Sie haben also gute Optionen und eine Regel. Die guten Optionen sind aws configure-Profile, die Standard-Umgebungsvariablen AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN und SSO, die Option, zu der ich bei menschlichen Nutzern greife: AWS_PROFILE plus aws sso login, das kurzlebige Zugangsdaten statt langlebiger Schlüssel liefert. Die Regel: Zugangsdaten gehen durch die Kette, niemals in ein Chat-Fenster kopiert. Ein Geheimnis, das in einen Prompt getippt wurde, ist ein Geheimnis, das Sie als verloren betrachten müssen.

Der Agent hat jetzt eine schmale, kontrollierte Tür. Richten Sie ihn auf diese Tür.

Claude Code auf Bedrock umstellen und verifizieren

Das ist der Schritt, in dem es funktioniert. Und wichtiger: der Schritt, in dem Sie beweisen, dass es funktioniert.

Das Routing ist eine einzige Umgebungsvariable. Setzen Sie CLAUDE_CODE_USE_BEDROCK auf 1 (den String "1", keinen Integer), und Claude Code ruft Bedrock statt des Standard-Endpunkts auf. Konfigurieren Sie das als Shell-Umgebungsvariablen oder, dauerhafter, in ~/.claude/settings.json unter einem env-Block:

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "eu-central-1",
    "ANTHROPIC_MODEL": "eu.anthropic.claude-sonnet-4-6"
  }
}

AWS_REGION setzt die Quellregion, die Claude Code aufruft. Setzen Sie sie explizit, auch wenn Ihr Profil bereits eine trägt. Aber denken Sie daran: Es ist die Region, aus der Sie aufrufen, nicht zwingend die, in der die Inferenz läuft (ein regionsübergreifendes Profil routet in eine Zielregion seiner Geographie). Setzen Sie ANTHROPIC_MODEL auf die gepinnte Inference-Profil-ID aus dem vorigen Schritt, dieselbe, auf die Ihre IAM-Policy gescoped ist. (Defaults je Modellklasse, ANTHROPIC_DEFAULT_OPUS_MODEL / _SONNET_MODEL / _HAIKU_MODEL, und eine Service-Tier-Steuerung existieren bei Bedarf; auf Bedrock fällt Claude Code für das kleine Hintergrundmodell auf Ihr Primärmodell zurück, wenn im Konto oder in der Region kein Modell der Haiku-Klasse freigeschaltet ist.)

Authentifizieren, dann die Session starten. Mit SSO heißt das: zuerst einloggen:

aws sso login --profile your-bedrock-profile
claude

Und jetzt der Teil, den die meisten überspringen: Verifizieren Sie anhand von Belegen. Ein erster erfolgreicher Dialogschritt sagt Ihnen nur, dass der Agent mit irgendetwas spricht. Er beweist für sich genommen nicht, dass der Aufruf zu Bedrock ging, in Ihre Region, auf Ihr gepinntes Modell. Beweisen Sie es, der günstigste Check zuerst:

• /status in der Session zeigt das aktive Modell und Bedrock als Provider. Ein schneller Plausibilitätscheck: nicht audit-tauglich, aber er fängt eine offensichtliche Fehlkonfiguration in zwei Sekunden.

• CloudTrail ist der audit-taugliche Beweis. Bedrock-Aufrufe von InvokeModel und InvokeModelWithResponseStream erscheinen als Events mit dem aufrufenden Principal, der Quellregion und der angefragten modelId (bzw. Inference-Profil-ID). Bei einem regionsübergreifenden Profil steht die Region, in der die Inferenz tatsächlich lief, in additionalEventData.inferenceRegion. Dieses Feld, nicht die Quellregion, prüfen Sie gegen Ihre Residenzanforderung. Die jüngsten Events holen Sie mit:

  aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventName,AttributeValue=InvokeModel \
    --region eu-central-1

  Das gibt einem Datenschutzbeauftragten oder Auditor einen protokollierten Nachweis, welche Identität welches Modell aus welcher Quellregion aufgerufen hat und in welcher Inferenzregion das aufgelöst wurde, statt „wir glauben, es hat korrekt geroutet“.

• Bedrock-Konsole → Usage-/Model-Invocation-Metriken (CloudWatch) liefert Aufrufzahlen gegen das gepinnte Modell in der gewählten Region, ein gutes laufendes Dashboard, sobald das Setup steht.

Eine scharfe Kante ist einen Satz wert: Das Agent-Tooling kann eine nackte Foundation-Model-ID intern in ein regionsübergreifendes Inference-Profil umwandeln. Gehen Sie also nicht davon aus, dass die ID, die Sie gesetzt haben, die ID ist, die lief: Pinnen Sie die Inference-Profil-Form, die Sie wollen, und lassen Sie CloudTrail die modelId und die inferenceRegion bestätigen, die tatsächlich gefeuert haben. Nehmen Sie nichts an, was Sie loggen können.

Geroutet und verifiziert. Aber ein gerouteter Agent ist immer noch ein Agent mit Reichweite. Grenzen Sie ihn ein.

Den Agenten eingrenzen: Allowlist, Limits, Guardrails und die lokale Privacy-Firewall

Das Routing hat entschieden, wohin der Modellaufruf geht; es hat die drei Datenklassen-Fragen beantwortet. Die Eingrenzung entscheidet, was der Agent auf dem Weg dorthin und zurück tun darf, und sie ist der Ort, an dem das vierte Problem vom Anfang, der Agent, der einen destruktiven Befehl halluzinieren kann, tatsächlich gehalten wird. Das ist Least Privilege, ein zweites Mal angewandt: auf den Fähigkeitsumfang des Agenten statt auf seine IAM-Identität.

Behandeln Sie die vier Kontrollen unten als Anforderungen zur Umsetzung, nicht als einen einzelnen Befehl zum Einfügen. Allowlist, Limits und lokale Vorverarbeitung werden von der Agent-Runtime, der Sandbox oder dem Wrapper Ihres Setups durchgesetzt; Bedrock Guardrails ist ein eigener, separater Konfigurationsschritt. Was folgt, ist, was jede Kontrolle leisten muss und warum. Der exakte Mechanismus ist eine Folgeaufgabe, zugeschnitten auf Ihr Tooling.

Datei- und Tool-Allowlist. Benennen Sie die Repositories und Pfade, die der Agent anfassen darf, und stellen Sie alles andere standardmäßig ab. Home-Verzeichnisse, .env-Dateien, Schlüsselbunde und Credential-Stores stehen niemals auf der Liste. Kombinieren Sie die Allowlist mit standardmäßig nur lesen: Der Agent darf lesen und vorschlagen, aber Schreiben, Deployen, E-Mail-Versand oder der Zugriff auf ein CRM verlangen eine explizite Bestätigung. Der größte Teil der nützlichen Arbeit eines Agenten besteht aus Lesen und Entwerfen; machen Sie die irreversiblen Aktionen zu denen, die ein menschliches „Ja“ brauchen.

Limits. Setzen Sie Obergrenzen für Schritte, Kosten und Laufzeit. Sie sind die Sandbox-Grenze in Zahlenform: das, was aus „der Agent hat sich in einer Schleife den Nachmittag verbrannt“ ein „der Agent hat sein Schrittlimit erreicht und gestoppt“ macht. Stimmen Sie die Limits auf die jeweilige Datenklasse ab, nicht pauschal. Ein G0-Experiment, das an G3-Reibung erstickt, lehrt die Leute nur, die Kontrollen zu umgehen; die Arbeit mit der höchsten Sensibilität ist der Ort, an dem die Obergrenzen sinken.

Bedrock Guardrails sind eine echte Schicht, und es hilft, präzise zu sein, was sie sind und was nicht. Guardrails ist eine konfigurierbare Policy-Schicht, die den Inhalt prüft, der die Modellgrenze überquert (Inhaltsfilter, gesperrte Themen, Wortfilter, Filter für sensible Informationen und PII mit Schwärzung, Contextual-Grounding-Checks), auf der Eingabe wie auf der Ausgabe. Was Guardrails nicht tun: kontrollieren, was der Agent auf Ihrem Rechner erreichen kann. Sie filtern Prompt und Antwort; den Agenten grenzen sie nicht ein. Sie brauchen beides: Guardrails auf dem Inhalt, der zum Modell wandert, Sandbox und Allowlist auf dem, was der Agent lokal anfassen kann. Ein Guardrail in den Claude-Code-Pfad einzuhängen ist ein separater Konfigurationsschritt, eine eigene Folgeaufgabe in Ihrem Setup und nichts, was diese Anleitung für Sie einschaltet. Und wenn Sie einen Guardrail mit einem regionsübergreifenden Inference-Profil betreiben, aktivieren Sie Cross-Region auch auf dem Guardrail, sonst passen die beiden nicht zusammen.

Die lokale Vorverarbeitung ist die Privacy-Firewall, und sie ist die Kontrolle, die die meisten übersehen. Vor dem Cloud-Aufruf werden PII und Geheimnisse aus dem, was der Agent senden will, entfernt, geschwärzt oder per OCR maskiert. Die Betriebsregel ist einfach: Geheimnisse vorhanden → lokal entfernen, oder stoppen. Was den Rechner nie verlässt, reduziert materiell, was nachgelagert gespeichert oder übermittelt werden kann. Reduziert, wohlgemerkt, nicht eliminiert: Dieselben Daten können weiterhin in lokalen Logs, Temp-Dateien, der Shell-History und im Plugin-State auftauchen; die brauchen ihre eigenen Kontrollen. Und die Vorverarbeitung selbst muss getestet werden, nicht als funktionierend angenommen. Für Berufsgeheimnis-Daten ist das keine Optimierung; es ist die Linie zwischen einem verteidigungsfähigen Workflow und einem Vorfall.

Sie haben einen kontrollierten Pfad gebaut. Die letzte Frage ist, wohin er gehört.

Wo dieser Pfad in einem Datenklassen-Routing-Modell sitzt

Alles oben ist der genehmigte Pfad für ein Band Ihrer Daten, die sensiblen und produktiven Klassen, innerhalb eines Routing-Modells. Eine universelle Einstellung, die Sie überall umlegen, ist es nicht.

Das Rückgrat dieses Modells ist leicht zu skizzieren und schwer zu bestreiten: Klassifizieren Sie die Arbeit nach Datenklasse (G0 bis G3), nach Zone und danach, ob agentische Ausführung im Spiel ist, und routen Sie jede Kombination auf Grün, Gelb oder Rot. Agentische Ausführung hebt die Untergrenze an: Dieselbe Datenklasse trägt mehr Kontrolle, wenn ein Agent auf ihr handeln kann, als wenn ein Mensch ein Chat-Fenster liest. Das Bedrock-geroutete, eingegrenzte, lokal vorverarbeitete Setup aus diesem Artikel zeigt, wie „Grün für sensibel/produktiv“ in der Praxis aussieht.

Warum dieser Rahmen zählt: wegen des Satzes, den er Sie nach oben reichen lässt. Sie haben nicht „Claude Code freigegeben“ (eine Behauptung, die kein Datenschutzbeauftragter bewerten und kein Auditor eingrenzen kann). Sie haben einen bestimmten Pfad für eine bestimmte Datenklasse freigegeben: dieses Modell, in dieser Region, unter dieser Identität, mit diesen Limits, verifiziert durch dieses Log. Das ist eine beantwortbare Frage, und beantwortbare Fragen kommen durch ein Risikokomitee.

Das ist der Bau. Bevor Sie sich darauf verlassen, verifizieren Sie ihn ehrlich, und machen Sie sich klar, was er nicht ist.

Verifizieren, Vorbehalte und wie es weitergeht

Gehen Sie diese Checkliste durch, bevor Sie das Setup für fertig erklären, und erneut, wann immer es sich ändert:

• Der Traffic geht zu Bedrock, auf das gepinnte Modell, aufgelöst in eine Inferenzregion, die Sie akzeptieren, bestätigt aus CloudTrail (additionalEventData.inferenceRegion), nicht aus einer Annahme.
• Die Datei- und Tool-Allowlist hält; .env, Schlüsselbunde und Home-Verzeichnisse liegen außerhalb.
• Standardmäßig-nur-lesen hält; Schreiben, Deployen und Versenden verlangen eine Bestätigung.
• Schritt-, Kosten- und Laufzeitlimits sind gesetzt und auf die Datenklasse abgestimmt.
• Die lokale Vorverarbeitung läuft vor dem Cloud-Aufruf; Geheimnisse vorhanden heißt: entfernen oder stoppen.

Jetzt die ehrlichen Vorbehalte, klar ausgesprochen.

Bedrock ist ein Kontrollpunkt, keine Compliance. Das Routing darüber kauft Kontrolle über Zugangsdaten und Region, die der Consumer-Pfad nie hatte. Compliant macht es Sie für sich genommen nicht. Region, Speicherfristen, Unterauftragsverarbeiter und IAM-Scope korrekt zu setzen bleibt Ihre Aufgabe. Und dass die Tür richtig eingebaut ist, auditiert sich nicht von selbst. Testen Sie die Eingrenzung (versuchen Sie tatsächlich, den Agenten etwas lesen zu lassen, das er nicht lesen dürfte), statt darauf zu vertrauen, dass die Konfiguration das bedeutet, was Sie denken.

Prüfen Sie die Datenverarbeitungsbedingungen des exakten Modells, das Sie pinnen. AWS betreibt das Modell jedes Anbieters in isolierten Model Deployment Accounts; der Modellanbieter hat also keinen Zugriff auf Ihre Prompts, Completions oder Bedrock-Logs, und der Traffic ist bei der Übertragung (TLS 1.2 oder höher) und im Ruhezustand verschlüsselt. Die erklärte Position von AWS, dass Bedrock Ihre Prompts und Ausgaben nicht zum Training der Basismodelle verwendet, steht in den Bedrock-FAQ. Behandeln Sie sie als dokumentierte Zusage von AWS und verweisen Sie auf die FAQ, statt sie als unbelegtes Absolutum zu wiederholen. Und lesen Sie die eine Ausnahme genau: Bedrocks allgemeine Linie ist, Ihre Ein- und Ausgaben nicht zu speichern, aber die Abuse Detection ist eine Ausnahme. Für bestimmte einzelne Modelle speichert AWS Ein- und Ausgaben bis zu 30 Tage und verlangt, dass Sie der Weitergabe dieses gespeicherten Traffics an den Anbieter zur Missbrauchserkennung und möglichen menschlichen Prüfung ausdrücklich zustimmen (Opt-in). Mit diesem Opt-in haben diese Daten die Daten- und Sicherheitsgrenze von AWS verlassen. Für einen Berufsgeheimnis-Workload kann dieses Opt-in ein hartes Nein sein. Prüfen Sie also, bevor Sie ein Modell pinnen, ob es diese Anforderung trägt. Stand Juli 2026 galt das für bestimmte neuere Modellstufen (zum Beispiel Anthropics Fable 5, mit abweichenden Bedingungen für einige OpenAI-Modelle), aber die genaue Liste ändert sich; verifizieren Sie sie vor dem Deployment gegen die Abuse-Detection-Dokumentation für das Modell, das Sie pinnen.

Anbieter-Mechanik bewegt sich. Dieser Text spiegelt das Produkt mit Stand Juli 2026: Die Namen der Umgebungsvariablen, das IAM-Action-Set und der Routing-Mechanismus sind die stabilen Teile; die exakten Modell-IDs, die EU-Inference-Profil-Bezeichner und die Abuse-Detection-Modellliste rotieren. Pinnen Sie gegen die kanonische Dokumentation zum Bauzeitpunkt, und prüfen Sie erneut, wenn Sie upgraden.

Nichts davon ist dramatisch, und genau das ist der Punkt. Der Bau besteht aus einer Handvoll AWS-Objekten und drei Umgebungsvariablen, und jede Sicherheitseigenschaft darin ist etwas, auf das Sie ein Log richten können. Agentische Sicherheit ist eine Scoping-Entscheidung (Was darf dieser Arbeitsbereich anfassen, und können Sie das belegen?), kein Vertrauensvorschuss darüber, ob ein Modell Ihr Vertrauen verdient. Stimmt der Scope, ist der Rest Klempnerarbeit.

Dies ist der erste Bau der Claude-Insights-Serie, und zwar bewusst: Von den eingangs skizzierten Optionen ist der AWS-Pfad der, den die meisten Teams heute gehen können, also kommt er zuerst. Die folgenden Teile arbeiten den Rest ab: Der Sandboxing-Deep-Dive führt den Eingrenzungspfad weiter, für das Problem des handelnden Agenten, das dieser Artikel nur einzäunen konnte; der Artikel zum Routing-Modell liefert das Rückgrat, das entscheidet, welche Klasse von Arbeit auf welchen Pfad gehört. Folgen Sie ihnen, um aus einem verifizierten Pfad eine Policy zu machen, die alle vier Probleme vom Anfang dieses Artikels beantwortet, nicht nur das eine, das eine Anbieter-Checkliste abdeckt.

Das AI Leadership Journal wird von Claudius Gramse geschrieben. evonomics ist die unabhängige KI-Beratung, die mittelständischen europäischen Unternehmen hilft, KI in die Arbeit einzubetten, die ihr Geschäft tatsächlich trägt – evonomics.eu.