DPA, DPIA and data residency: pragmatic Nordic approach

Privacy isn't what stops AI projects in Norway. What stops them is starting AI projects without thinking through privacy, and then having to rebuild mid-flight. Datatilsynet has been clear: AI is lawful when built right from the start, and lawful doesn't only mean GDPR-compliant. It also means sector-specific legislation, especially for finance, health and the public sector.

The DPA

The DPA is the data processing agreement between you as data controller and the vendor processing data on your behalf. It sounds bureaucratic, but it's practical because it defines what the vendor is actually allowed to do with the data. In 2026, the most common mistake is signing a standard agreement without checking four things: where data is stored, who has access, which sub-processors are used, and what happens to data on termination.

For AI projects, the fourth point is the most undervalued. What happens when the agreement ends or the vendor changes business model? Many AI vendors in 2025 demanded the right to use customer data for model training. By 2026 most serious vendors have walked that back, but it's not universal. A clause that says "no training on customer data" is a core condition for any AI project involving personal data. If the vendor won't sign on that, you have your answer.

The DPIA

The DPIA, data protection impact assessment, is required when processing is likely to result in high risk for the data subjects. This typically applies to AI projects with personal data because automated decisions often land in that category. The DPIA isn't a form you fill in to tick a box. It's an actual assessment of necessity, proportionality and risk that has to happen before processing starts.

A good DPIA for an AI project looks like this in practice. It defines what's processed, which categories of personal data are involved, and what purpose justifies the processing. It evaluates whether less intrusive methods could achieve the same purpose. It documents which risks have been identified (unfair discrimination, data leakage, lack of transparency) and which measures reduce them. It has a section on how data subjects' rights are upheld, especially the right to information and to object.

Datatilsynet won't approve the DPIA. That's not their job. You make the assessment, you document it, and you're responsible for the consequences. Datatilsynet can ask to see it in an examination, and if it's thinly filled out or missing, you have a real regulatory problem.

Data residency

Data residency is the third area that gets misunderstood. GDPR doesn't require that data always sit inside the EU/EEA. It requires that transfers outside happen on documented lawful grounds. After the Schrems II ruling, most US transfers sit in a grey zone, and many Norwegian operators have chosen to keep data inside the EU/EEA on caution rather than strict legal necessity.

For AI projects this is practically relevant. If the model inference runs at a US cloud provider, data is transferred there. Even if data isn't permanently stored, a transfer happens on every inference. That's not lawful by definition, but it requires a documented basis and usually standard contractual clauses with supplementary measures like encryption and access restriction.

The simplest path in 2026 is to choose vendors offering inference inside the EU/EEA, document it contractually, and verify that the model isn't trained on customer data. That cuts legal complexity meaningfully, and you can focus on the operational aspects of the project.

Sector legislation

Sector-specific legislation layers on top of GDPR. For finance it means Finanstilsynet's circulars on AI in credit scoring and sanction monitoring. For health it means health legislation's rules on journalling and patient rights. For the public sector it means administrative law, transparency law, and archival law. These aren't supplements to GDPR. They add new concrete requirements, and they aren't overridden by something being technically possible.

Practical recommendation

Practical recommendation for an AI project considering personal data.

Map the data sources before choosing a vendor. Which categories of personal data are involved? Where is the legal basis for the processing? Is it consent, contract performance, legal obligation, or legitimate interest? This has to be documented, not assumed.

Choose a vendor with EU/EEA residency and a documented no-training policy. In writing, in the agreement, not in marketing material. If the vendor can't or won't document this, find another vendor.

Do the DPIA before processing starts. That means before the pilot begins, not afterwards. Datatilsynet doesn't accept "we were in pilot phase" as a valid reason for not having the assessment ready.

Establish logging and retention regimes from day one. Every agent action on personal data is logged. Retention regimes follow the purpose, not the vendor's defaults. This isn't technically complicated, but it requires conscious decisions from the start.

Have a defined person who owns privacy on the AI project. It can be the DPO, but it has to be explicit. Without clear ownership, responsibility fragments, and that's exactly when mistakes happen.

Pragmatic privacy on AI in the Nordics isn't harder than pragmatic privacy elsewhere. It just requires the same seriousness. Those who take it seriously deliver AI that holds up under examination. Those who skip it end up tearing up the project after the first serious question.