GDPR compliant AI outsourcing — a practical checklist for Nordic and EU companies

Key takeaways

• If an outside AI developer processes personal data on your behalf, the relationship needs a processor agreement that meets Art. 28 of the GDPR, wherever the developer is based.
• Remote access from Vietnam to personal data hosted in the EU is still a transfer under the EDPB's guidelines; because Vietnam has no EU adequacy decision, it normally needs Standard Contractual Clauses and a transfer impact assessment.
• If the transfer impact assessment finds that protection is not effective even with supplementary measures, do not make the transfer: keep personal-data access in the EU or limit the offshore team to anonymised or synthetic data.
• Unless a personal-data breach is unlikely to result in a risk to individuals' rights and freedoms, a Danish controller must notify Datatilsynet without undue delay and, where feasible, within 72 hours of becoming aware of it, so the contract should set a specific, short deadline for the vendor to notify you.
• As of October 2026, AI used to filter job applications or evaluate candidates is listed as high-risk in Annex III of the EU AI Act, with those obligations applying from 2 December 2027 after the AI Omnibus.

The GDPR-compliant AI outsourcing checklist starts with your data and AI Act risk

Before any vendor sees a brief, write down three things.

1. What personal data the AI will touch. Note whether any of it is special-category data under Art. 9 of the GDPR (health, biometric data used to uniquely identify a person, trade union membership and so on). Then ask whether the model really needs real records, or whether most of the work could use anonymised or synthetic data – artificially generated records with the same shape as the real ones. Pseudonymised data is still personal data; only properly anonymised data falls outside the GDPR.

2. Whether you need a DPIA. A data protection impact assessment (DPIA) under Art. 35 is often triggered by new technology, profiling, large-scale processing or decisions with significant effects on people. If the system will make or strongly shape decisions about individuals, also check Art. 22 on automated decision-making.

3. The EU AI Act risk tier. The AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024 and applies in stages. The prohibition on workplace emotion recognition, subject to medical and safety exceptions, has applied since 2 February 2025. The AI Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026; as of October 2026, the rules for stand-alone high-risk systems listed in Annex III apply from 2 December 2027, and those for high-risk AI embedded in products covered by Annex I from 2 August 2028.

Annex III matters more than many buyers expect. It covers AI used in recruitment, such as filtering applications or evaluating candidates, as well as creditworthiness assessment and access to essential services. For an Annex III use case, the provider and deployer roles follow from how the system is developed, supplied and used; putting it into service under your own name can make you the provider. A contract cannot simply assign those roles, but it should record who handles risk management, logging, human oversight and technical documentation.

Which contracts you need — a quick decision path

Start by working out which of four situations you are in:

1. No personal data in scope. The vendor only sees genuinely anonymised, synthetic or non-personal data. The GDPR does not apply to that data, but you still need confidentiality and IP terms, and someone should check that the anonymisation holds up.
2. Personal data, accessed only from inside the EU/EEA. If the vendor processes personal data on your behalf, it is a processor and you need an Art. 28 agreement. There is no Chapter V transfer for that access, but check the vendor's own sub-processors and where they are.
3. Personal data accessible from a third country. This includes engineers in Vietnam remotely accessing data hosted in an EU data centre: under the EDPB's guidelines on transfers, that remote access is a transfer. Where the vendor acts as your processor, you need the processor agreement, a Chapter V transfer tool and a transfer impact assessment (TIA) – a documented review of whether the destination country's law and practice let the safeguards work.
4. The TIA concludes that protection is not effective, even with supplementary measures. Do not make that transfer. Keep personal-data access in the EU, limit the offshore team to anonymised or synthetic data, or rescope the project.

In Danish, the processor agreement is the databehandleraftale. Vietnam has no EU adequacy decision, so in case 3 the usual safeguard is the European Commission's Standard Contractual Clauses (SCCs). Choose the module that matches the actual exporter–importer relationship. SCCs support a transfer only where the TIA, and any supplementary measures it calls for, give effective protection in practice. Vietnam has its own personal data protection rules, and your TIA should take them into account.

Pay attention to the breach clause. Under Art. 33, a processor notifies its controller without undue delay after becoming aware of a breach. A Danish controller notifies Datatilsynet without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. Your vendor's deadline has to leave you time to assess and report, so write a number of hours into the contract rather than "promptly".

Where the data lives and who can reach it

EU hosting is not a legal condition for GDPR compliance, but it limits exposure and makes the TIA easier to support. A practical baseline:

• EU hosting for data and backups – for example AWS Stockholm (eu-north-1), AWS Frankfurt (eu-central-1) or an Azure or Google Cloud EU region. Vector indexes (the searchable stores behind document assistants), embeddings and logs can contain personal data too.
• EU-hosted model endpoints – for example Amazon Bedrock or Azure OpenAI in an EU region. Check each provider's data-retention terms and confirm that prompts are not used for training.
• Synthetic or anonymised data by default. Real data only inside a controlled environment, with SSO, MFA, least-privilege roles and access logging.
• No stray copies – no production records in tickets, chat threads, screenshots or laptops. In AI projects the usual leak is quieter: real records pasted into a prompt-testing notebook or left in an evaluation set. Ask how test sets are built and stored.
• A named data-protection contact on the vendor side.

EU hosting does not replace the transfer safeguards; it limits and logs what crosses the border. If your company may be covered by NIS2, note that Denmark's NIS2 law has applied to covered entities since 1 July 2025, and supply-chain security is part of those obligations.

Ask vendors for evidence of work with regulated documents, and read it critically. Our closest published example is American, not European: for a US healthcare startup, we built AI compliance-document automation in 12 weeks. The published case study reports 90% less manual review time, a three-week backlog cleared in two weeks and more than 600 hours saved per month. US health data falls under different law, so treat that as evidence of building on sensitive documents, not of GDPR compliance.

To test the arrangement on one real use case before a larger build, our AI Pilot takes a single use case to a working pilot on your data in 3–4 weeks for a fixed fee, with the DPA, transfer safeguard, hosting region and breach deadline written into the scope first. Our security page describes our approach.

Questions to ask any AI vendor before you sign

A prepared partner can answer most of these on a first call.

1. What is your role (processor or otherwise) for each data flow, and will you sign a DPA based on our template?
2. Where will production data, backups, logs and vector indexes be stored? Name the regions.
3. Which model APIs will you call, in which region, and do those providers retain prompts or train on them?
4. Who on your team can access personal data, from which countries, and how is that access logged and revoked?
5. Can development run on anonymised or synthetic data? What happens when it cannot?
6. Who are your sub-processors, and how much notice do we get before that list changes?
7. Which SCC module fits our relationship, and will you contribute to our transfer impact assessment?
8. How many hours after detecting a breach will you notify us, and who are the named contacts?
9. Which EU AI Act risk tier do you think this use case falls into, and how would the system support logging and human oversight if it is high-risk?
10. Who owns the code, the prompts, the evaluation datasets and any fine-tuned weights, and how is our data returned or deleted at the end?

Red flags: a request for a full production export "to get started", a vendor that cannot name its sub-processors, or a "GDPR compliant" badge offered in place of a DPA. For the working model, see offshore development in Vietnam.

Related reading: AI development in Denmark – offshore options, costs and GDPR · Nearshore vs offshore AI development for Nordic companies · EU AI Act for recruitment AI after the AI Omnibus

Frequently asked questions

Is it legal for a Danish company to outsource AI development to Vietnam under GDPR? Yes, but the GDPR sets conditions. If the Vietnamese team can access personal data, you need an Art. 28 processor agreement, a Chapter V transfer tool (usually the EU SCCs, as Vietnam has no adequacy decision) and a transfer impact assessment showing the safeguards are effective. Anonymised or synthetic data falls outside the transfer rules.

Does the EU AI Act apply if my AI developer is outside the EU? Yes. The AI Act applies to AI systems placed on the EU market or used in the EU, and to deployers located in the EU, wherever the developer is based. Outsourcing the build does not move your deployer obligations to the vendor, and as of October 2026 the Annex III high-risk obligations apply from 2 December 2027.

Do I need a DPIA before running an AI pilot on real customer data? Not always, but a pilot on real data is still processing. If it is likely to result in a high risk to individuals, for example profiling job applicants, a DPIA is required before you start. One option is to run the first weeks on synthetic data while the DPIA is completed.