LAW/FLOW
DE EN
// All posts

Enforce EU hosting, do not just select it

On AWS Bedrock the inference profile decides the place of processing, not the model. How law firms bolt the EU boundary shut in technical terms.

On AWS Bedrock (Amazon Web Services is Amazon’s cloud platform, Bedrock its service for language models) the place of processing is determined not by the model but by the inference profile. Profiles with the prefix eu. stay in EU data centres, profiles with global. may process the same request anywhere in the world. A law firm therefore secures EU data residency not by making the right choice during setup but through a permissions policy that makes every other profile technically unselectable.

How do you reliably lock a law firm robot inside the EU? Not with the right tick box during setup, but by making the wrong option unselectable in the first place.

The profile decides, not the model

Anyone running AI models on Amazon servers does not select the model directly but through what is called an inference profile. That profile determines which data centre actually processes the request. Profiles with the prefix eu. stay in six data centres inside the EU. Profiles with the prefix global. may send the same request around the world, depending on where capacity happens to be free.

The problem is less that both variants exist than the way they present themselves: in the same list, directly one below the other, distinguished only by the prefix. If someone reaches for the wrong entry by mistake, a client secret leaves the European legal area. No warning appears, no confirmation prompt, no note in the log that catches the eye on reading. The error is silent, and silent errors are the most expensive kind in a law firm.

That is exactly why the selection screen is the wrong place for this decision. A setting that every person has to get right on every call is not a security measure but a well-intentioned source of error.

How do you enforce EU processing in AWS?

AWS has suitable tools for this case, and it makes sense to use them in layers.

At the top sits the Service Control Policy (SCP): a prohibition at organisation level that applies to every login inside the organisation, including the one with the highest rights. An SCP grants no rights, it only limits what can be granted at all. For the question “may anyone here have computation done outside the EU”, that is the right design, because a generously assigned individual permission cannot undo it.

One level down, the same bolt can be drawn on a per-person basis. In IAM Identity Center (AWS’s user and permissions management) every role gets a permission set that allows only the six EU regions and only eu. profiles. Every call outside that frame is denied, regardless of what the interface offers. Technically this happens through an inline policy in JSON format.

The duplication is not excessive. The SCP protects against misconfiguration in the account structure, the permission set against slips in daily work. Build only one of the two layers and you are relying on the other class of error never occurring.

The leak often sits in the app, not in the region

That secures the infrastructure, but not yet the application layer. Some features of the applications through which admitted lawyers work with the model run not through your own Bedrock account but through the provider’s servers. Design features or a marketplace for skills are examples. In a law firm environment such features belong switched off, because they bypass the carefully drawn regional frame.

The same goes for external connectors. A link to a note-taking or knowledge system, a web search or a ticketing system passes content on to a service that your own SCP simply does not cover. A single connector put into production can undo everything above. Connectors are therefore not taboo, but each one has to pass the same review as the platform itself: where does data flow, under which contract, with which confidentiality undertaking.

The contractual foundation carries the technology

Everything named here rests on a set of contracts. The data processing agreement under Art. 28 GDPR applies automatically at AWS, and that is the data protection side. Lawyers’ professional conduct law demands on top of that an express confidentiality undertaking under § 43e BRAO. Without that undertaking no client secret belongs in the system, however cleanly the regions are bolted shut.

The reverse holds as well: a signed contract does not replace a configuration. The two layers cover different risks, one the legal, the other the factual. Have only one of them and you have a gap that the other cannot close when it matters.

The practical consequence is unspectacular. The EU boundary belongs somewhere nobody can override it in day-to-day work. Anything else is a habit, and habits have bad days.

How you then make it traceable who called which model and when, without recording a single word of the content, is a chapter of its own. What of that is relevant for your own firm can be read up in advance in the frequently asked questions.

The content of this blog was created partly with the support of AI.

Professional conductAWS