Summarize this article with
The EU AI Act dominated headlines when it passed. Most of the coverage focused on model providers, high-risk AI system operators, and the obligations facing AI developers building systems for healthcare, law enforcement, and critical infrastructure.
Privacy teams at enterprise organizations read those headlines and breathed a cautious sigh of relief: that's not us, we use AI, we don't build it.
That relief may be premature.
The EU AI Act creates specific data governance obligations that apply to organizations using AI systems to process personal data, not just the companies building those systems. For privacy and data teams managing GDPR compliance alongside a growing portfolio of AI deployments, the Act introduces new documentation requirements, audit obligations, and consent questions that map directly to your existing program.
This guide covers what those obligations are, why they fall on privacy teams rather than (or in addition to) engineering, and how to meet them without starting from scratch.
Who the EU AI Act applies to?
The EU AI Act creates a tiered risk framework. Systems are categorized as unacceptable risk (banned), high risk (tightly regulated), limited risk (transparency obligations), and minimal risk (largely unregulated).
The obligations that matter most for enterprise privacy teams cluster around high-risk AI systems. Under the Act, high-risk AI systems include systems used for:
- Biometric identification and categorization of people
- Management and operation of critical infrastructure
- Education and vocational training (access decisions)
- Employment, worker management, and access to self-employment
- Access to essential private services, including credit scoring and insurance
- Law enforcement
- Administration of justice and democratic processes
Many enterprise AI deployments, particularly in HR, financial services, healthcare, and marketing, touch these categories. If your organization uses AI for candidate screening, credit risk modeling, customer triage, or any system that makes consequential decisions affecting individuals, the high-risk provisions apply.
Even for lower-risk deployments, the GDPR already applies to any AI system that processes the personal data of EU residents. The AI Act adds a layer on top, particularly around data governance for training datasets and transparency obligations for automated decision-making.
What the EU AI Act requires from data and privacy teams
Article 10: Data governance for training datasets
Article 10 is the provision privacy teams need to understand first.
For high-risk AI systems, Article 10 requires that training, validation, and testing datasets be subject to documented data governance and management practices. This includes:
Relevance and representativeness. Datasets must be appropriate for the system's intended purpose and representative of the environments in which the system will operate.
Data quality. Practices must address errors, completeness, and bias in training data.
Lawful basis. The data used to train high-risk AI systems must have been collected on a lawful basis, such as consent, legitimate interest, or another GDPR-recognized ground, and that basis must cover the AI training purpose, not just the original collection purpose.
That last point is where most organizations have an undisclosed gap. Data collected for "personalized marketing" may have been consented to for that purpose. Using that same data to train a model that makes employment-related recommendations is a different processing purpose, one that requires either a fresh consent or a documented legitimate interest assessment.
If you cannot demonstrate that the consent or lawful basis covering your training data extends to AI training, you have an Article 10 problem.
What to document: A record of the data sources used to train each high-risk AI system, the lawful basis for each source, any data minimization or anonymization applied, and the bias evaluation performed before deployment.
Article 13: Transparency and information provision
Article 13 requires that high-risk AI systems be designed to enable human oversight. It also requires that deployers provide consumers with meaningful information about the use of AI in decisions that significantly affect them.
For privacy teams, this translates to disclosure obligations that sit alongside, and sometimes intersect with, GDPR's Article 22 (automated decision-making) and Article 13/14 (information to data subjects).
Practical implication: Your privacy policy and data subject information notices may need to be updated to disclose the use of high-risk AI systems. The disclosure must be specific enough to be meaningful, not just "we may use automated systems to process your data."
Article 17: Quality management systems
Deployers of high-risk AI systems must implement quality management systems that include, among other elements, data governance procedures and a post-market monitoring system.
For privacy teams, "post-market monitoring" means ongoing assessment of whether the AI system continues to perform as intended without introducing new data risks, a requirement that aligns with continuous privacy monitoring but adds a formal obligation.
Documentation requirements: what privacy teams need to produce
The EU AI Act's documentation obligations for high-risk AI systems are extensive. For privacy teams, the most relevant are:
How the EU AI Act intersects with GDPR for privacy teams
The EU AI Act adds to GDPR rather than replacing it. For organizations processing personal data in AI systems, both frameworks apply simultaneously.
The practical intersections that require attention:
Consent scope. GDPR requires a specific, informed, lawful basis for each processing purpose. If AI training is a new purpose, existing consent for data collection may not cover it. This requires either re-consent (difficult at scale) or a documented legitimate interest assessment that can withstand regulatory scrutiny.
DPIA requirements. GDPR already requires DPIAs for processing that is "likely to result in a high risk to the rights and freedoms of natural persons." Deploying a high-risk AI system as defined by the EU AI Act almost certainly meets this threshold. Organizations should treat EU AI Act deployment as a DPIA trigger.
Data subject rights. Article 22 of the GDPR gives individuals the right not to be subject to solely automated decisions with significant effects, and the right to request human review. The EU AI Act's transparency obligations reinforce this. Privacy teams need to ensure that AI systems subject to Article 22 have documented human review pathways.
Cross-border data transfers. If AI systems process EU personal data outside the EU, existing GDPR transfer mechanisms (SCCs, adequacy decisions) apply, and AI Act compliance documentation must be maintained regardless of where the processing occurs.
A practical compliance roadmap for privacy teams
Step 1: Inventory your AI deployments
Before you can assess EU AI Act compliance, you need to know which AI systems your organization uses, what data they process, and what decisions they influence. This is a privacy inventory, not an engineering list, and it belongs to your team.
The Ketch Agent Network performs this discovery automatically through agentic data mapping, connecting to your SaaS systems and classifying data processing activities including AI-driven workflows. If you're maintaining a manual inventory, use this as the starting framework:
- System name and vendor
- Processing purpose and data categories processed
- Lawful basis for personal data processing
- Whether the system makes or influences consequential decisions about individuals
- Risk tier under the EU AI Act (high-risk, limited risk, minimal risk)
Step 2: Assess training data lawful basis
For each AI system in your inventory, identify the data sources used for training. For each source, document:
- The original collection purpose and lawful basis
- Whether AI training was contemplated in that lawful basis
- If not, whether a legitimate interest assessment covers AI training as a compatible further processing purpose
Where gaps exist, assess whether re-consent is feasible or whether a fresh LIA is the appropriate path.
Step 3: Update DPIAs and processing activity records
Existing DPIAs should be reviewed for AI-specific considerations. New AI deployments should trigger fresh DPIAs. Processing activity records (ROPA) should include AI systems as data controllers and processors in the processing chain.
Ketch runs this as agentic risk assessments: DPIA templates auto-populate from live system data, and ROPA-ready processing activity records are generated with full system context, reducing the documentation burden from a blank-template project to a review-and-approve process.
Step 4: Update privacy notices
Review your privacy policy and data subject information notices for EU AI Act disclosure requirements. For high-risk AI systems that make or influence decisions about individuals, update notices to include:
- A description of the AI system and its role in the decision
- The categories of personal data used
- The right to request human review of automated decisions
- Contact information for AI governance queries
Step 5: Implement ongoing monitoring
EU AI Act compliance is not a one-time project. Article 17 requires post-market monitoring, Article 12 requires ongoing logs, and GDPR requires continuous data protection by design.
The organizations that manage this well do so with continuous monitoring infrastructure: systems that detect new AI deployments, flag new data processing activities, and surface compliance gaps as they emerge rather than at the next audit cycle.
Ketch AI Sentry adds the enforcement layer on top of that monitoring. It inspects prompts before they reach the model, checks the consent record, and blocks or redacts personal data that lacks a lawful basis for the AI processing purpose.
Every decision is logged with the request, the data involved, and the policy that applied, which gives privacy teams an operational record that supports the record-keeping expectations in Article 12 without standing up a separate logging project.
For the broader model behind this approach, see our guide to agentic privacy.
