GDPR and the EU AI Act for operational AI agents
Privacy and AI governance shape purpose, data flows, transparency, oversight and operations. They cannot be added as a notice after the system is built.
This is general orientation, not legal advice. Duties depend on the actual purpose, data, affected people, organisational roles and providers.
Describe the actual use
“AI agent” is not a sufficient legal description. Record what it does, who uses it, which data categories and sources are involved, which recipients and providers receive data, and whether it can change systems. GDPR and the EU AI Act have different scopes and may apply in parallel.
Start with a data-and-action map. For each channel, show inputs, intermediate storage, retrieved knowledge, model providers, business systems, logs and recipients. Mark personal and special-category data, write actions and automated recommendations. This map gives privacy, security and operational teams a shared object to review.
Do not assume that an internal-facing tool is low impact. Employee data, performance signals or access to confidential records can raise material concerns. Conversely, a customer-facing assistant is not automatically high-risk under the AI Act. The intended purpose and actual effect require case-specific assessment.
Follow the personal-data flow
Define purpose and legal basis for each processing activity. Apply data minimisation and restrict tools to what the workflow needs. Clarify controller and processor roles, contracts, storage, deletion, security and any transfer outside the EEA. Operational procedures must support relevant access, correction, deletion, restriction and objection rights. Where decisions have legal or similarly significant effects, Article 22 GDPR requires particular attention.
Separate purposes and retention
Handling a request, monitoring security and improving a system are distinct purposes. They may involve different data, access and retention. A blanket statement that conversations are retained “for quality” does not replace a defined purpose and legal assessment. If production interactions are reused for evaluation, decide what is necessary, remove identifiers where possible and control who can access the material.
Assess high-risk processing early
Where processing is likely to result in high risk to people’s rights and freedoms, assess whether a data protection impact assessment is required. Describe necessity and proportionality, risks and measures before architecture and procurement are fixed. Revisit the assessment when purpose, data categories, affected groups or system discretion changes.
Establish role, risk and transparency
Determine whether the organisation acts as provider, deployer or in another role. Check prohibited practices and whether the intended use falls within a high-risk area. High-risk systems carry extensive requirements; the concrete purpose matters more than the product label.
Transparency duties for certain interactive and generative AI systems became applicable on 2 August 2026. In relevant cases, people should understand that they are interacting with AI unless that is already obvious. Clear human contact and an explanation of the agent’s scope make that disclosure useful rather than cosmetic.
Make transparency work in the channel
A voice agent can identify itself clearly at the beginning of a call. A chat can keep an AI label visible throughout the interaction. An internal drafting tool should show reviewers which content was generated and which sources were used. The wording should describe meaningful limits and the human contact route, not merely attach an “AI” badge.
Avoid interfaces that imply human review when none occurred. Where a person does approve an action, preserve an appropriate record of that approval. Transparency therefore touches interface design, operating procedure and logs as well as legal copy.
Make governance operational
- Maintain an inventory with purpose, owner, providers, data, tools and risk classification.
- Evaluate normal, edge, security and misuse cases before releases.
- Define human oversight, escalation thresholds and sufficient handoff context.
- Plan incident detection, containment, documentation and learning.
- Version models, instructions, knowledge sources and permissions.
- Provide role-appropriate AI literacy.
Ask providers operational questions
Confirm hosting locations, subprocessors, storage, training use, deletion, security controls, logging and change notification for the actual service configuration. Marketing pages do not establish contractual behaviour. Document which party handles incidents and how a model or platform change triggers re-evaluation.
Define an incident path before launch
Staff need a route to report harmful output, unintended disclosure, repeated actions and suspicious requests. Assign authority to contain the workflow, preserve relevant evidence and decide on internal or external notification. After containment, update the risk record, test cases and controls rather than treating the event as an isolated support ticket.
Review purpose as well as performance
A periodic and event-driven review should ask whether purpose, data access, affected groups and providers remain unchanged. It should also check complaints, failure patterns, handoff practice and staff AI literacy. Material changes should be assessed before release, not deferred to the next scheduled meeting.
Record decisions, open items, responsible roles and the event that will trigger the next review. This keeps governance traceable through staff and supplier changes instead of depending on the memory of the original project team.
Related pages
Primary sources
Current as of 3 August 2026. Monitor legal and regulatory updates.