The access route decides, not the model
Chat interface, API or cloud deployment: the same AI model can be professionally out of the question or a workable basis, depending on how a firm reaches it.
The question “may we use ChatGPT or Claude in the firm?” is put the wrong way round. In professional-conduct terms it is not the model that decides but the access route: through a chat interface, through the provider’s API (the programming interface through which your own software addresses the model directly) or through a cloud deployment (running the model in your own account with a cloud provider) at a hyperscaler. The same model can be out of the question for client data on one route and a workable basis on another.
Why the model is the wrong yardstick
§ 43e BRAO (the German Federal Lawyers’ Act) attaches not to software but to the service provider: to the contracting party, to the people with access to client data and to their subcontractors. A language model, though, is reachable by several routes, and each route means a different contracting party, different data flows and different means of control.
A concrete example: the same Claude model is reachable through the claude.ai web interface, through Anthropic’s API and through AWS Bedrock (the language model service on the Amazon Web Services cloud platform). Three routes, three legal starting positions. Anyone discussing only “the tool” is negotiating the wrong level.
Route 1: the chat interface
The fastest way in, and for client data the most problematic. In consumer plans and many team plans, whether inputs are used for training depends on the plan and the account settings, and it can change with the terms of use. A data processing agreement is generally not on offer in a consumer plan, and a set of contracts meeting the four requirements of § 43e BRAO even less so. The provider decides where processing happens.
That does not mean chat interfaces have to be banished from the firm. For work with no connection to a matter, such as background legal research or drafting text with no personal data, they are defensible with a clear internal policy. The line runs at the first item of client data, and drawing exactly that line is what the policy is for.
Route 2: the model provider’s API
Through the API the firm (or its software vendor) enters into a business contract. The major providers make data processing agreements available for this and undertake by default not to use API inputs for training. That is real progress over the chat interface, but a gap remains: a data processing agreement under Art. 28 GDPR is a data protection instrument. It does not replace the professional confidentiality agreement under § 43e BRAO, with its instruction on the criminal consequences and its obligation to bind subcontractors. Treating the two as the same thing confuses two areas of law.
Then there is the processing location. Whether processing can be bindingly confined to the EU depends on the specific offer and often cannot be guaranteed with the direct APIs.
Route 3: the cloud deployment
On the third route the model runs as a hyperscaler’s service, for instance Claude on AWS Bedrock. The contracting party is then the cloud provider, with whom firms can conclude § 43e BRAO contracts anyway. The processing location can be technically enforced rather than merely selected, and the logging and the hardening of the account are in your own hands. The price for that is effort: a cloud deployment has to be set up, secured and operated.
The three routes compared
| Chat interface | API | Cloud deployment | |
|---|---|---|---|
| Contracting party | model provider (consumer/team plan) | model provider (business customer) | hyperscaler |
| DPA under Art. 28 GDPR | depends on the plan | yes | yes |
| Contracts under § 43e BRAO | practically unattainable | check, often gaps | attainable |
| EU processing controllable | no | depends on the offer | yes, technically enforceable |
| Effort | minimal | medium | high |
The table is orientation, not a substitute for reviewing the specific offer. Provider plans and assurances change; what counts is the contractual position at the time of signing.
What follows for a rollout?
The order turns around. Not pick a tool first and retrofit the legal position, but settle the access route first, then the contracts, then the technology. For work with no connection to a matter, route 1 with a policy is enough. As soon as client data is involved, the defensible path runs through route 2 with the § 43e gap closed, or through route 3, and anyone who wants full control over the processing ends up at route 3.
That makes the debate about individual models pleasantly unimportant. Models can be swapped. The access route is the architecture decision that stays. More answers to typical law firm questions are in the FAQ.
The content of this blog was created partly with the support of AI.