What legal teams and DPOs need to know about the AI Act

Discover the key AI Act requirements for legal teams and DPOs, including compliance, risk management and practical implementation steps.

The AI Act is no longer "just a conversation." It is a legal framework that affects how AI systems are designed, integrated, and operated. And while engineering is key, AI Act governance requires interpretation, documentary traceability, and coordination with data protection and legal responsibilities.

Why the AI Act also affects legal teams and DPOs

When an organisation incorporates AI into products, processes, or decision-making, legal and fundamental-rights questions emerge. Those questions do not disappear once you deliver "the technical part." The legal team and the DPO are usually the ones who already handle risk, responsibility, documentation, and coordination across areas. The AI Act reinforces that fit by turning governance into a verifiable process: classify, document, supervise, and demonstrate.

The legal team typically leads normative interpretation, contracts, responsibility, and governance toward executive management. The DPO typically leads the link with data protection, people's rights, and coherence with the existing privacy program. The AI Act does not replace the DPO, but it does require the DPO to understand where AI touches personal data and where AI governance needs bridges with DPIAs, records of processing activities, and privacy policies. If both teams work in silos, the typical outcome is duplicated or contradictory documentation.

Risk classification: what legal teams and DPOs should review first

The first practical step is to understand which category your AI use case falls into. The AI Act uses a layered model: prohibited systems, high-risk, transparency obligations, and in some cases, minimal risk. For the legal team and the DPO, classification is not a theoretical exercise: it determines which documentation is needed, which control mechanisms must exist, and how internal responsibilities are managed.

In practice, before you write procedures, review what real use cases exist, what impact they have on people's rights, and whether the system influences decisions (for example hiring, credit, health, or diagnosis).

A minimum inventory of use cases

Before discussing "tools," it helps to create a simple table covering: the use case name, input and output, who decides (human-in-the-loop or not), impact on people, and the provider (if a third party) with basic contractual scope. That inventory does not replace legal analysis, but it prevents the discussion from staying abstract.

High-risk: why the documentation load becomes critical

When a system falls into the high-risk category, the company faces more demanding requirements: greater need for technical documentation, conformity assessments, traceability and records, clear information for the user, and effective mechanisms for meaningful human oversight. Although engineering produces part of the evidence, legal teams and DPOs must ensure that documentation has purpose, traceability answers regulatory questions, and governance does not become a repository without coherence.

When you review a documentation package, make sure it answers clearly: what the system does and what it is for; what risks the organisation identifies and how it mitigates them; who supervises and how the system is corrected if something goes wrong; and what information the end user receives and how they can exercise rights. If documentation does not answer those questions, you likely have a governance gap, not "more PDFs."

Foundation models and general-purpose: new questions for legal

Foundation models and general-purpose systems introduce an important nuance: many organisations do not develop the model, but they do integrate it via APIs, fine-tuning, or embedded components. That can create obligations stemming from usage and from the operational context. For legal teams and DPOs, additional questions appear: what representations the providers offer, how outputs are used downstream, and how traceability of data processing is controlled across the full workflow. Instead of waiting for the technical team to solve compliance at the end, legal teams and DPOs should lead mapping uncertainties.

With providers of models or APIs, it often helps to align expectations on: service scope and usage limits; representations about compliance and updates; sub-processors and transfers; records and cooperation in case of incidents; and provider exit (what happens if you switch models).

AI Act and GDPR: they intersect, but they are not the same

The AI Act does not replace the GDPR, but in real operations they touch. The intersection usually shows up when there is personal data use in training or inference, profiling and automated decision-making, impact assessments, and responsibilities toward providers. At that point, the DPO is a natural bridge. The goal is to avoid duplication and contradictions, which requires explicit coordination between data governance and AI governance rather than two separated lines of work.

When a system uses personal data, it is common to see assessment processes in privacy. The key is to define which part the GDPR covers and which part AI governance covers, without creating two parallel universes that nobody maintains. A useful approach is a control mapping: one risk, one owner, one evidence artefact, and a defined review periodicity.

How to make AI governance auditable

The practical question for a legal team and DPO is: how do I turn these obligations into a process that survives product changes? One way to structure AI governance without inventing from scratch is to lean on management system standards such as ISO/IEC 42001:2023 (AIMS) as a reference to organise responsibilities, documentation, and continuous evaluation. It does not replace the law, but it helps keep the work coherent, auditable, and maintainable.

A useful routine is a "light" quarterly review that answers: are there new use cases? Did the provider or model change? Were there incidents or internal regulatory feedback? Did documentation and owners get updated? That routine prevents governance from freezing at the launch moment.

How to coordinate with product, engineering, and procurement without turning legal into a bottleneck

The most common risk is not "not knowing the law." It is arriving too late in the decision cycle. You do not need to block every release, but it often helps to define moments when legal and the DPO must be involved, no matter what: a new use case with personal data or automated decisions; a change in the model or AI API provider; expansion into new markets or sensitive segments; and integration into end-user flows.

Legal can also help standardise a minimum package of questions and clauses for AI providers. It does not replace commercial negotiation, but it reduces improvisation when every purchase is a different world. Much of the friction comes from vocabulary, it helps to align on simple internal definitions: what counts as a use case, what counts as personal data in your specific context, what an output is and how you record it, and what human oversight means in your product.

Mistakes that can slow you down

Treating the AI Act as an engineering-only issue. If legal and DPO are left out of the classification and documentation cycle, the result is often evidence without traceable responsibility. The AI Act asks for coordination, not full delegation.

Not doing a real classification of uses. Classifying by hand at the end creates rework. If you do not map use cases and impacts, you will not know which obligations apply, or which evidence will be missing during review.

Separating AI governance and GDPR without bridging. You can end up with procedures that say different things. Fixing the issue requires connecting DPIA and risk management logic with the AI governance documentation and supervision cycle.

Forgetting contracts and vendor management with an AI focus. Governance does not live only in the system, it lives in how you buy, integrate, and control providers and models.

How CB Partners can help legal teams and DPOs with the AI Act

We help legal teams and DPOs turn the AI Act into a governance plan that is understandable and document-coherent, focused on mapping use cases and risk classification, aligning AI Act and GDPR obligations to avoid duplication, documentation and review-ready traceability, and coordination with technology and product so implementation stays connected to compliance.

Frequently Asked Questions