Skip to content
All articles
Data, privacy and GDPR

AI data residency: the law asks where, and the answer is a setting

DORA requires a financial entity's contracts to name the regions or countries where services are provided and data is processed, including the storage location. For a cloud AI service, that answer can depend on a deployment type somebody selected.

By Bastion, Cluj-NapocaPublished 6 min read

Residency and privacy are treated as the same question and they are not. Privacy asks what happens to the data. Residency asks where it is processed and stored. An organisation can satisfy one and fail the other.

What the law asks for, in its own words

DORA is explicit. Article 30(2) lists what the contractual arrangements on the use of ICT services must include, and point (b) requires:

the locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location, and the requirement for the ICT third-party service provider to notify the financial entity in advance if it envisages changing such locations

Regulation (EU) 2022/2554, Article 30(2)(b)

Read the second half. The contract must name the locations and oblige the provider to give advance notice before changing them. This is not a preference for European hosting. It is a requirement that the answer be written down and kept current.

The regulation also settles who carries the obligation. Recital 64 states that “A financial entity should at all times remain fully responsible for complying with its obligations set out in this Regulation.” Outsourcing the service does not outsource the duty.

Why the answer can be harder than it looks

A well-documented cloud AI service will answer the question, and the answer has conditions. Microsoft's documentation for models sold by Azure states that “For any deployment type labeled 'Global,' prompts and responses may be processed in any geography where the relevant model sold by Azure is deployed”, and that for a DataZone deployment created in an EU member state, processing may occur “in that or any other European Union Member Nation”.

The same page records where stored data sits: it “Is stored at rest in the Foundry resource in the customer's Azure tenant, within the same geography as the resource”.

So the Article 30(2)(b) answer for that service is not one line. It is a line per deployment type, and it changes if an engineer changes the deployment type. That is a governance problem, not a technical fault.

Residency is not compliance

Keeping data in the European Union does not make a processing activity lawful under the GDPR, and keeping it in Romania does not make a system secure. Residency answers one question out of several. It is necessary in some contracts and sufficient in none.

Residency is a question the contract asks. Compliance is a question the whole processing activity answers.

What local inference changes

With inference inside the organisation's own network, the Article 30(2)(b) answer is short and it does not depend on a console setting. The location is the building. There is no subcontracted processing location to track, and no advance-notice clause to monitor, because there is no provider who can move it.

For a thirty-person organisation with no privacy engineering team, that is worth more than it looks. Fewer moving parts is not a marketing claim. It is fewer paragraphs that have to be true.

With Bastion

What Bastion changes

Bastion is a private AI system delivered as one sealed appliance that runs inside your building. One monthly fee covers the hardware, the model, the hardened operating system and support, and nothing your team types leaves the building.

A Bastion node answers inside the customer's network without an outbound connection, so the processing location is the customer's own site and stays there.

That does not discharge the rest of DORA, and this article does not claim it does. It makes one row of the register short, stable and easy to evidence.

On the record

  1. 1
  2. 2