EU-Hosting erzwingen, nicht auswählen
Auf AWS Bedrock entscheidet das Inferenzprofil über den Verarbeitungsort, nicht das Modell — und wie Kanzleien die EU-Grenze technisch verriegeln.
Auf AWS Bedrock bestimmt nicht das Modell den Verarbeitungsort, sondern das
Inferenzprofil. Profile mit dem Präfix eu. bleiben in EU-Rechenzentren, Profile mit
global. dürfen dieselbe Anfrage weltweit verarbeiten. Eine Kanzlei sichert die
EU-Datenresidenz deshalb nicht durch die richtige Auswahl beim Einrichten, sondern durch
eine Berechtigungsrichtlinie, die alle anderen Profile technisch unwählbar macht.
Wie sperrt man einen Kanzleiroboter zuverlässig in der EU ein? Nicht mit dem richtigen Häkchen beim Einrichten, sondern indem die falsche Option technisch gar nicht mehr wählbar ist.
Das Profil entscheidet, nicht das Modell
Wer KI-Modelle auf Amazon-Servern betreibt, wählt das Modell nicht direkt aus, sondern
über ein sogenanntes Inferenzprofil. Dieses Profil legt fest, in welchem Rechenzentrum
die Anfrage tatsächlich verarbeitet wird. Profile mit dem Präfix eu. bleiben in sechs
Rechenzentren innerhalb der EU. Profile mit dem Präfix global. dürfen dieselbe Anfrage
über die ganze Welt schicken, je nachdem, wo gerade Kapazität frei ist.
Problematisch ist weniger, dass es beide Varianten gibt, als die Art, wie sie sich präsentieren: in derselben Liste direkt untereinander, unterschieden allein durch das Präfix. Greift jemand versehentlich zum falschen Eintrag, verlässt ein Mandantengeheimnis den europäischen Rechtsraum. Es erscheint keine Warnung, keine Rückfrage, kein Hinweis im Protokoll, der beim Lesen sofort ins Auge springt. Der Fehler ist lautlos, und lautlose Fehler sind in einer Kanzlei die teuersten.
Genau deshalb ist die Auswahl der falsche Ort für diese Entscheidung. Eine Einstellung, die jede Person bei jedem Aufruf richtig treffen muss, ist keine Sicherheitsmaßnahme, sondern eine Fehlerquelle mit guter Absicht.
Zwei Riegel statt einer Gewohnheit
In AWS gibt es für diesen Fall passende Werkzeuge, und sinnvollerweise setzt man sie gestaffelt ein.
Auf der obersten Ebene steht die Service Control Policy (SCP): ein Verbot auf Organisationsebene, das für jeden Zugang innerhalb der Organisation gilt, auch für den mit den höchsten Rechten. Eine SCP erteilt keine Rechte, sie begrenzt nur, was überhaupt erteilt werden kann. Für die Frage “darf hier irgendjemand außerhalb der EU rechnen lassen” ist das die richtige Bauform, weil sie sich nicht durch eine großzügig gesetzte Einzelberechtigung aushebeln lässt.
Eine Ebene tiefer lässt sich derselbe Riegel personenbezogen einziehen. Im IAM Identity
Center bekommt jede Rolle einen Berechtigungssatz, der ausschließlich die sechs
EU-Regionen und ausschließlich eu.-Profile erlaubt. Jeder Aufruf außerhalb dieses
Rahmens wird verweigert, unabhängig davon, was in der Oberfläche angeboten wird.
Technisch geschieht das über eine Inline-Policy im JSON-Format.
Die Doppelung ist kein Übermaß. Die SCP schützt vor Fehlkonfiguration in der Kontostruktur, der Berechtigungssatz vor Fehlgriffen im Alltag. Wer nur eine der beiden Ebenen baut, verlässt sich darauf, dass die jeweils andere Fehlerklasse nicht eintritt.
Das Leck sitzt oft in der App, nicht in der Region
Damit ist die Infrastruktur abgesichert, die Anwendungsschicht aber noch nicht. Manche Funktionen der Anwendungen, über die Berufsträger*innen mit dem Modell arbeiten, laufen nicht über das eigene Bedrock-Konto, sondern über die Server des Anbieters. Beispiele sind Design-Funktionen oder ein Marktplatz für Skills. Solche Funktionen gehören in einer Kanzleiumgebung abgeschaltet, weil sie den sorgfältig gezogenen Regionsrahmen umgehen.
Dasselbe gilt für externe Connectoren. Eine Anbindung an ein Notiz- oder Wissenssystem, eine Websuche oder ein Ticketsystem reicht Inhalte an einen Dienst weiter, für den die eigene SCP schlicht nicht gilt. Ein einziger produktiv geschalteter Connector kann alles Vorstehende aushebeln. Tabu sind Connectoren deshalb nicht, aber jeder einzelne muss dieselbe Prüfung durchlaufen wie die Plattform selbst: Wohin fließen Daten, unter welchem Vertrag, mit welcher Verschwiegenheitsverpflichtung.
Das vertragliche Fundament trägt die Technik
Alles Genannte steht auf einem Vertragswerk. Der Auftragsverarbeitungsvertrag nach Art. 28 DSGVO gilt bei AWS automatisch, das ist die datenschutzrechtliche Seite. Das anwaltliche Berufsrecht verlangt darüber hinaus eine ausdrückliche Verschwiegenheitsverpflichtung nach § 43e BRAO. Ohne diese Verpflichtung gehört kein Mandantengeheimnis in das System, gleich wie sauber die Regionen verriegelt sind.
Umgekehrt gilt dasselbe: Ein unterschriebener Vertrag ersetzt keine Konfiguration. Die beiden Ebenen sichern unterschiedliche Risiken ab, die eine das rechtliche, die andere das tatsächliche. Wer nur eine davon hat, hat eine Lücke, die sich im Ernstfall nicht mit der jeweils anderen schließen lässt.
Die praktische Konsequenz ist unspektakulär: Die EU-Grenze gehört an eine Stelle, an der niemand sie im Tagesgeschäft überschreiben kann. Alles andere ist eine Gewohnheit, und Gewohnheiten haben schlechte Tage.
Wie sich anschließend nachvollziehbar machen lässt, wer wann welches Modell aufgerufen hat, ohne ein einziges Wort des Inhalts mitzuschreiben, ist ein eigenes Kapitel. Was davon für die eigene Kanzlei relevant ist, lässt sich vorab in den häufigen Fragen nachlesen.