You don't need the AI Act. Article 5 already said no.

Compliance teams are waiting for AI Act guidance before touching their AI deployments. The obligations that actually bite are eight years old and already in force.

The most common sentence in European AI governance right now

"We're holding off until there's clearer guidance on the AI Act."

I hear it in almost every conversation, usually from someone competent who is genuinely trying to do this properly. It sounds prudent. It is the single most expensive mistake being made in European data protection at the moment, and it rests on a misreading of which regulation is doing the work.

Two things are true and they point in opposite directions. The AI Act asks less of a normal enterprise than most people fear. GDPR asks more, applies today, and most AI pipelines already fail it.

What the AI Act actually asks of you

Start by finding out what you are. The Act's obligations are stratified by role, and the difference between them is enormous.

If you build and place an AI system on the market under your own name, you are a provider, and you carry the heavy end: conformity assessment, technical documentation, risk management systems, post-market monitoring.

If you buy Copilot, or Gemini, or an API, and use it in your business, you are a deployer. Your obligations are considerably lighter — largely human oversight, using the system in line with the provider's instructions, transparency toward affected people, and input data relevance where you control it.

The overwhelming majority of European enterprises are deployers. They are budgeting for provider obligations they will never carry.

The timeline reinforces the point. The Act entered into force in August 2024. Prohibited practices and AI literacy duties applied from February 2025. General-purpose AI model obligations from August 2025. The high-risk categories — the ones that generate the conformity paperwork everyone is afraid of — sit at August 2026 and August 2027, and only for systems that fall into the Annex III use cases or safety components. Recruitment, credit scoring and worker management are in scope. Your internal knowledge assistant almost certainly is not.

So for a typical deployer, the AI Act is a governance and documentation exercise, phased, and mostly not yet due.

What GDPR asks, and has asked since 2018

Now look at what happens the moment you point a retrieval pipeline at a file share.

Article 5(1)(b), purpose limitation. Personal data collected for one purpose cannot be further processed in a way incompatible with it. The CVs collected to fill a role in 2019 were collected to fill a role. Indexing them into a corporate assistant is a new purpose, and you need to have assessed its compatibility. Almost nobody has documented this.

Article 5(1)(c), data minimisation. Processing must be adequate, relevant and limited to what is necessary. Indexing an entire tenant because scoping it was hard is the definition of failing this test. "We ingested everything and rely on permissions to filter it" is not minimisation; it is the absence of minimisation with a compensating control bolted on.

Article 5(1)(e), storage limitation. You do not keep personal data longer than the purpose requires. Every organisation I have reviewed is holding personal data years past any defensible purpose. That was already a violation when it sat quietly in a file share. Feeding it into a system designed to surface it on demand converts a dormant violation into an active one.

Article 5(2), accountability. You must be able to demonstrate compliance with all of the above. Not achieve it. Demonstrate it. If you cannot produce a record of what you hold, why, and under what retention rule, you fail this regardless of how well-behaved your model is.

Add Article 6 — you need a lawful basis for the new processing, and the one you had for collection does not automatically travel — and Article 35, because large-scale processing of personal data with new technology is close to a textbook DPIA trigger.

None of this is pending. None of it needs guidance. It has been enforceable for eight years, with the fine ceiling of Article 83(5) attached, which is the higher tier: up to 4% of global annual turnover.

What this means for the data protection software you buy

There is a genuine efficiency here and almost nobody takes it.

NIS2 Article 21 requires risk management measures proportionate to the risk, and it explicitly covers information system security policy and asset handling. GDPR Article 32 requires security of processing. The AI Act's deployer duties require you to know what data goes into the system.

All three want the same underlying artefact: a defensible inventory of what data you hold, where it is, who is responsible for it, and what happens to it over time. Build it once. Three regulators, three frameworks, one piece of evidence. Most organisations are running three separate projects that each produce a partial version of it.

This is also the test to apply when you are evaluating data protection software. Ask whether it produces that single artefact or another siloed report. A tool that does PII detection but cannot tell you who owns the data, what the retention rule is, and whether deletion was executed has solved the easy third of the problem and left you the other two.

Four questions

If you want to know where you stand without commissioning anything, answer these. No tooling required, and every one of them is answerable this week.

1. What personal data has your AI system been given access to? Not "which SharePoint sites" — what categories of personal data are in them. If the answer is "we don't know, we scoped by site", you have failed Article 5(1)(c) and you can stop here.

2. What was that data originally collected for? For each significant category. If you cannot answer, you cannot assess compatibility under 5(1)(b).

3. What is your retention rule for it, and is it enforced? A policy document that describes deletion nobody performs is worse than no policy. It proves you knew.

4. Can you demonstrate all of the above to a supervisory authority? With records, not assertions. That is Article 5(2), and it is the one that turns a defensible position into an indefensible one.

If you fail these, the AI Act is not your problem. It is the second layer on a foundation that is already non-compliant, and no amount of guidance from Brussels will change the answer.

The good news, such as it is

The remediation for all four is the same piece of work, and it is not an AI project.

Classify what you hold. Make the people who own the data confirm what still has a purpose. Delete what does not, and keep the evidence that you did. Then connect your AI system to what is left.

Do that and the AI Act becomes what it should have been all along — a documentation exercise on top of a data estate you can actually describe. Skip it, and you are asking a regulator to accept that you deployed a retrieval system across personal data you could not inventory, for purposes you had not assessed, retained past a limit you had not enforced.

That conversation does not go well. It has nothing to do with AI.

If you want to know what is actually sitting in your unstructured data, we run a free review.