The EU AI Act and Legal Practice: A Compliance Roadmap

The AI Act is now the reference framework for AI governance in Europe, and legal teams are being asked two questions with increasing urgency: does this apply to what we are doing, and what do we have to do about it. This is a practitioner’s roadmap — obligations, timing and a staged programme — rather than a survey of the legislation.

The structure worth internalising

The Act is risk-tiered, and almost every practical question resolves to placing a system in the right tier and identifying your role in relation to it.

Prohibited practices sit at the top: manipulative techniques exploiting vulnerability, social scoring by public authorities, certain biometric categorisation and untargeted facial-image scraping. These are outright bans, not compliance obligations.

High-risk systems carry the bulk of the substantive requirements. Two routes qualify a system: it is a safety component of a product already subject to EU product legislation, or it falls within the enumerated areas — biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice. That last category is the one legal teams should read carefully.

Limited-risk systems attract transparency duties: people should know they are interacting with an AI system, and synthetic content should be marked as such.

General-purpose AI models sit in their own regime, with heavier obligations where a model presents systemic risk.

Provider or deployer?

This distinction determines almost everything, and organisations regularly misclassify themselves.

A provider develops a system, or has one developed, and places it on the market or puts it into service under its own name or trade mark. A deployer uses a system under its own authority in a professional capacity.

The trap: a deployer becomes a provider by putting its own name on a system, by making a substantial modification, or by changing the intended purpose of a system in a way that brings it within a high-risk category. Fine-tuning a general-purpose model on your own data and deploying it for a new purpose is exactly the fact pattern that triggers this. If your organisation is building on top of third-party models, that assessment needs to be documented rather than assumed.

What high-risk actually requires

For providers, in outline: a risk management system operating across the lifecycle; data governance covering training, validation and testing data, including examination for bias; technical documentation sufficient to demonstrate conformity; automatic logging; instructions for use enabling deployer compliance; human oversight designed into the system; appropriate accuracy, robustness and cybersecurity; a quality management system; conformity assessment; registration in the EU database; and post-market monitoring with serious incident reporting.

For deployers, the list is shorter but not trivial: use the system in accordance with the instructions; assign human oversight to people with the competence, training and authority to exercise it; ensure input data is relevant and sufficiently representative where you control it; monitor operation and suspend use where risks emerge; keep logs; inform workers’ representatives and affected workers before putting a high-risk system into use in the workplace; and, for certain systems, carry out a fundamental rights impact assessment.

A staged programme that does not stop the business

The failure mode we see most often is a compliance programme that begins by asking every team to pause. It does not work, and it drives AI use underground. A staged approach works better.

Stage 1 — Inventory (weeks 1–4)

You cannot classify what you have not found. Build an inventory of AI systems in use or in development: what it does, who supplied it, what data it consumes, who relies on the output, and whether a human reviews decisions before they take effect. Include the shadow estate — the marketing team’s content tool, the recruiting team’s screening add-on, the analytics feature switched on in an existing product. Ask about capabilities, not about “AI”: teams do not always know that is what they have bought.

Stage 2 — Classification (weeks 3–8)

For each entry, determine the tier and your role. Record the reasoning, not only the conclusion — when a supervisory authority or an auditor asks in two years, the reasoning is the deliverable. Prohibited practices are addressed immediately; high-risk entries move to a remediation track; limited-risk entries move to a transparency track.

Stage 3 — Gap analysis (weeks 6–14)

Assess each high-risk system against the applicable requirement set. Most organisations discover that documentation, logging and human oversight are the weak points; data governance is frequently better than expected because it inherits GDPR work already done.

Stage 4 — Remediation and governance (ongoing)

Fix the gaps, and put in place the standing machinery: an approval gate for new AI systems, contractual terms for AI suppliers, incident response covering AI-specific failures, a training programme for people exercising oversight, and periodic re-assessment.

Contracting for AI supply

The commercial terms that matter have shifted. For any AI supplier, the agreement should address: the supplier’s classification of the system and the basis for it; provision of the technical documentation and instructions for use you need in order to comply as a deployer; log retention and access; notification of substantial modification; cooperation with regulators and with your own assessments; training data provenance representations; and the allocation of liability for regulatory non-compliance rather than only for IP and confidentiality.

Suppliers who cannot answer the classification question in writing are telling you something useful about their own readiness.

Interaction with the GDPR

The two regimes overlap without aligning. A system can be entirely AI Act compliant and unlawful under the GDPR, and the reverse. Where personal data is processed, you still need a lawful basis, a completed DPIA where the threshold is met, transparency to data subjects, and a defensible position on automated decision-making under Article 22. Practically, the efficient path is a single assessment covering both, with a mapping that shows which finding satisfies which obligation — not two parallel programmes producing two sets of documents about the same system.

What good looks like in twelve months

A maintained inventory with a named owner per system. Documented classifications with reasoning. A functioning approval gate that engineering teams use because it is faster than the alternative. Standard contractual terms for AI suppliers. Oversight assigned to people who have been trained and who have the authority to stop a system. And an evidence trail that lets you answer, in a morning, the question a regulator will eventually ask: what did you know about this system, and when.