EU AI Act Preparation and DPIA: The Workflow in Brief

Two of our how-to guides cover the regulatory work most teams deploying AI in Europe meet first: how to prepare for the EU AI Act and how to do a DPIA for AI. This post gives the order of work for each and how the two fit together. It is not legal advice. Whether and how a law applies depends on your use case, your role and your jurisdiction, and you should take advice on yours. Swfte describes its approach as compliance-by-design: it provides technical controls, governance mechanisms and evidence that help an organisation work within its own requirements. It does not make an organisation compliant on its own.

A note on dates

The EU AI Act's application dates have moved. Our guide states them as they stood on 7 October 2026: Annex III high-risk duties apply from 2 December 2027, while the prohibitions, AI literacy and transparency duties already apply. The guide also says where those dates come from. The primary text on EUR-Lex could not be loaded when the guide was checked, so the post-amendment dates rest on a law-firm briefing, search summaries and our own EU AI Act timeline page. Before you plan to a date, check the Official Journal. If you read nothing else from this post, read that sentence.

The EU AI Act workflow, in eight steps

1. Start from the dates as they stand now. Different parts of the Act apply at different times, and amendments have shifted some of them. Write the dates you are planning against, with their source, at the top of your plan.

2. List every AI system, model and agent. You cannot classify what you have not found. Include the systems you build, the ones you buy, features inside other products, and the ones staff use without telling anyone. Our guide on detecting shadow AI is the companion for the last group, and the post on the AI estate inventory shows what to record.

3. Rule out prohibited practices first. Some uses are banned outright. Checking for them first is cheap and the consequence of missing one is the most severe. Where something looks close, stop and take advice.

4. Decide whether you are a provider or a deployer. Your duties depend on your role for each system. You can be a deployer of one system and a provider of another, and putting your own name on a system or substantially modifying one can change your role.

5. Classify each system by risk. The Act sorts systems into high-risk (the Annex III uses and safety-component cases), transparency-only (people must be told they are dealing with AI, or that content is generated), general-purpose AI models, and minimal risk. Our high-risk checklist is a structure for working through this, and the classification flowchart post shows it visually.

6. Start AI literacy now. Article 4 asks organisations to ensure a sufficient level of AI literacy among the staff who operate and use AI systems. It already applies, it is inexpensive to start, and it is the duty most likely to be asked about first. See AI literacy under Article 4.

7. Plan the obligations for each class. For a high-risk system that includes risk management, data governance, technical documentation, record-keeping, transparency to users, human oversight, accuracy and strongness, and for providers a conformity assessment. For a deployer there are duties around use according to instructions, oversight by trained people, monitoring and logs. List each duty against each system, with an owner.

8. Build the evidence as you go. Documents written in a rush at the end are weak. Keep the inventory, the classification reasoning, the oversight design, the test results and the training records current from the start. The validation guide shows how to produce test evidence you can reuse.

The DPIA workflow, in seven steps

A data protection impact assessment is a GDPR Article 35 requirement before processing that is likely to result in a high risk to people's rights and freedoms. AI processing often meets the criteria because it can involve new technology, large-scale or sensitive data, profiling and automated decisions. The relevant European and national data protection authorities publish criteria and lists, and you should check the ones that apply to you.

1. Decide whether a DPIA is required. Apply the authority criteria and record the reasoning. If you decide not to do one, write down why. Where in doubt, do one: it is often cheaper than defending the omission.

2. Describe the processing and the data flow. What data, from whom, for what purpose, through which systems and which models, where it is stored, who sees it, how long it is kept and which processors and sub-processors are involved. For AI, include training and fine-tuning data, prompts and outputs, logs and any third-party model provider.

3. Test necessity and proportionality. Is there a lawful basis, is the purpose specific, could the aim be met with less data or without AI, and what do you tell people?

4. Identify and rate the risks to individuals. Risks to people, not to the company: wrong or biased decisions, exposure of personal data in outputs, memorisation of training data, loss of control, inability to exercise rights. Rate likelihood and severity.

5. Choose measures to reduce each risk. Minimisation, access control, retention limits, human review of significant decisions, output filtering, and testing for the failure modes you listed. Record the residual risk.

6. See the steps on a worked example. The guide walks through a customer-service agent with a stated profile: its owner, risk level, data classification, residency, permitted systems, allowed and restricted actions and its approval rule. It shows how a Trust Profile can feed the description in step 2 and the measures in step 5. See also the Trust Profile page.

7. Record the advice, sign off and set a review date. Take your data protection officer's advice and record it, record the decision, and revisit the assessment when the system changes. A DPIA is a living document, not a form filed once.

How the two fit together

The AI Act and the GDPR overlap but do not replace each other. The inventory you build for the AI Act is the starting list for DPIAs. The AI Act's risk classification tells you where to look hardest, and the DPIA is where you look at the effect on individuals' data protection rights. Some high-risk deployers also have a duty under the AI Act to assess the impact on fundamental rights before use, and the guide explains how a DPIA can feed that. Treat it as one body of evidence with two audiences.

What teams get wrong

• Treating it as a legal team problem only. The inventory, the data flows and the oversight design live with engineering, product and operations. Lawyers can interpret; they cannot discover the systems.
• Classifying by product instead of by use. The same model can be minimal risk in one use and high-risk in another. Classify the use.
• Forgetting bought-in AI. A vendor's feature that screens candidates or scores customers is an AI system you deploy. Ask the vendor for the information you need and keep the answers.
• Forgetting that staff use AI tools you did not approve. The inventory is incomplete until you have looked for these.
• Writing the DPIA after launch. It is meant to inform whether and how to proceed. Done afterwards, it becomes a defence document and misses the changes it should have caused.
• Copying a template without describing your processing. A DPIA that could describe any company describes none.

What to do this week

1. Write the inventory, even if rough.
2. Mark anything that might be prohibited or high-risk and take advice on those.
3. Name an owner for AI literacy and start it.
4. Pick the system where personal data is most exposed and start its DPIA.
5. Put the dates you are planning against, with sources, at the top of the plan.

For the underlying pages, see the EU hub, the GDPR and AI page and the DPIA page. The two guides carry the detailed steps, sources and verification dates.