data governance ai agents gdpr security

Data governance for AI agents means deciding, before you connect anything, which information each agent may see, under what classification, how long it retains it, where every answer came from and who is accountable when something goes wrong. This is not a documentation exercise: it is the technical prerequisite that separates a deployment that scales from one that stalls at the first security review.

The reason is straightforward. An agent with access to company systems multiplies the blast radius of any permission mistake: where an employee with wrongly granted access to a folder would have opened three documents, an agent indexes four thousand and hands them to whoever asks the right question. The very capability that makes an agent useful — reading a lot and synthesising fast — is what makes bad classification dangerous. This article walks through the five pieces of data governance as they apply to agents: classification, permissions, retention, lineage and audit.

Why does data governance block so many AI projects?

Because the problem surfaces late, once the pilot works and it is time to connect real data. The demo ran on twenty hand-picked documents; production means pointing at the network drive, the document management system or the mailbox — and that is when somebody asks who can see what. If the answer does not exist, the project stops.

And it does not stop over bureaucracy: it stops because most companies discover at that moment that their actual permissions bear no resemblance to the ones they thought they had. Folders shared with the whole organisation "temporarily" four years ago, payroll exports sitting in a finance directory, contracts with personal data in a sales mailbox archive. The agent does not create that problem — it makes it visible and turns it into something queryable.

The optimistic reading is that this work pays for itself even if the AI project were cancelled: fixing classification and permissions improves security, compliance and everyday working life. The realistic reading is that you must budget for it as part of the project, not treat it as a prerequisite that will somehow appear for free.

How do you classify information before connecting an agent?

With four levels, not twenty. Any finer scheme gets abandoned within three months because nobody knows which drawer things belong in. The rule is that each level must carry a clear consequence for what an agent may do with that information.

Level	Examples	What the agent may do
Public	Catalogue, website, press releases, open documentation	Read, index and cite without restriction
Internal	Procedures, policies, templates, routine minutes	Read and index; answer only identified staff
Confidential	Contracts, customer pricing, margins, case files	Role-limited access; mandatory citation and logging
Restricted	Health data, payroll, minors' data, live negotiations	Out of scope unless an isolated, approved use case exists

The restricted level deserves its own rule: excluded by default. Not because it cannot be handled, but because the cost of governing it properly — legal basis, minimisation, impact assessment, reinforced controls — rarely pays off in your first use cases. Starting with it excluded lets you move fast on 90% of the value.

Who decides what each agent sees?

Three roles, and none of them is your technology vendor. When this question is answered with "the consultancy configured it", data governance does not exist.

• The data owner. The head of the area that produces the information — finance for margins, HR for personnel files, sales for pricing — decides its level and who may query it. This is not a technical role.
• The agent owner. The person accountable for what that specific agent does: which sources it consumes, what it may write, who it serves and what it escalates. Every agent needs a name behind it.
• Data protection. The DPO, or whoever performs that function, reviews legal basis, minimisation, retention periods and data subject rights before the agent touches anything containing personal data.

On top of those three roles sits the operating rule we always apply: one agent, one purpose, one permission set. No omniscient corporate assistant with access to everything "because it is more convenient". Several specialised agents are safer, easier to audit and, in practice, more accurate too. How those permissions are structured is detailed in AI agent governance and permissions.

How long does an agent keep what it sees?

Longer than people assume, and in more places than they imagine. A typical deployment stores the same information in four distinct locations: conversation history, the search index (the embeddings), technical logs and backups of all of the above. A retention policy that only covers the first is not a policy.

The piece that causes most trouble is the vector index. When you delete a document at source, its chunks remain inside the index until it is rebuilt, and the agent can keep citing their content. If that document held personal data and someone exercises their right to erasure, deleting at source is not enough: you need a procedure that reindexes or removes the affected chunks, and you need to be able to demonstrate it.

Our practical recommendation is to fix three periods in writing from day one: conversations (say 90 days, except those escalated into incidents), technical logs (6-12 months for security and audit) and the index (periodic rebuild plus an on-demand deletion procedure with a committed turnaround). Numbers you can genuinely honour, not the ones that look good in a document.

Lineage: where did this answer come from?

Lineage is the ability to reconstruct, for any agent answer, exactly which sources it used, in which version and on which date. Without it you cannot audit, you cannot fix an error at its root, and you cannot defend a decision to a customer, an auditor or a court.

In practice it translates into three design requirements: every indexed chunk stores its origin, version and date; every answer cites the sources supporting it; and every citation is navigable back to the real document. An agent that answers well but never cites is an agent you will not be able to govern, and that gap is always discovered at the worst possible moment.

Lineage also solves a less dramatic everyday problem: contradictory policies. When the agent cites its source, somebody notices that two versions of the returns procedure have been circulating since 2024 — and that gets fixed. Without citations, the agent silently picks one of the two and nobody finds out. This discipline is the heart of a properly built retrieval system, whose cost we break down in what a corporate RAG system costs.

What has to be logged to make auditing possible?

1. Who asked and what they asked, with a verified identity, not a shared generic account.
2. What the agent queried: systems, executed queries and retrieved documents.
3. What it answered and which sources it cited.
4. What it wrote or executed, if it has write permissions: a full record of the action, including the prior state.
5. What it escalated, to whom and why. Escalations are the best source of improvement you will get.

These logs must be immutable from the agent's perspective — it cannot erase its own trail — and retained under the agreed policy. One detail that saves grief: log the decisions not to answer as well. Knowing how often the agent declined, and why, is as informative as knowing what it said.

Which regulatory framework applies in Europe?

Three layers, best kept separate. GDPR remains the foundation for anything involving personal data: legal basis, minimisation, retention, data subject rights and, where processing is high risk, a prior impact assessment. This layer has always applied and AI has not changed it.

The second layer is the EU AI Act. Since 2 August 2026 the transparency obligations of Article 50 apply — telling people they are interacting with an AI system and labelling synthetic content — alongside AI literacy obligations. High-risk Annex III systems have their own timetable which, following the digital omnibus revision, points to December 2027 (position as of August 2026; confirm the consolidated text before planning compliance work).

The third is voluntary but increasingly requested in tenders and by large customers: ISO/IEC 42001, the AI management system standard, which gives a recognisable structure to everything above. If your company already holds ISO 27001, the step is reasonable; if not, start with data governance and leave certification until there is something to certify. And if the conclusion is that certain data must never leave your infrastructure, that decision has architectural consequences we review in on-premise vs cloud AI and privacy.

How to implement it without stalling the project

1. Weeks 1-2: inventory the use case. Not the whole company. Which sources this specific agent needs, who owns them and what they actually contain.
2. Weeks 3-4: classification and clean-up. Four levels, applied only to those sources. Exclude restricted data and fix the broken permissions you uncover.
3. Weeks 5-6: agent permissions. Its own service account, least privilege, write access only where indispensable.
4. Weeks 7-8: retention, lineage and logging. Periods in writing, mandatory citations in answers, auditing switched on before any user gets access.
5. Weeks 9-12: supervised pilot with a small group, weekly log review and phased expansion.

That sequence fits inside the 90-day start we use in any serious deployment, described in the 90-day AI-First company checklist. The key is that governance advances with the project and scoped to the use case; trying to govern all of a company's data before connecting the first agent is the most elegant way of never deploying at all.

Frequently asked questions

Can I run a pilot before this is sorted?

Yes, if the pilot uses a closed data set, contains no personal data and serves identified users. What you must not do is point the pilot at the entire network drive "to see how it goes". A scoped pilot teaches you exactly the same thing without creating a security problem you then have to explain.

Can the agent see only what the asking user can see?

That is the safest model and the one we recommend whenever the platform supports it: the agent acts on behalf of the user and inherits their permissions, so nobody obtains through chat what they could not obtain through the system. It has a cost — the index must respect per-document permissions, which complicates the architecture — but it eliminates the most common class of incident.

What about the data we send to the model provider?

It depends on the contract and the plan: enterprise agreements from the major providers exclude customer data from training and set short retention periods, but that must be verified in your specific contract rather than assumed. Your data protection officer needs it in writing before deployment, not after.

How do I handle erasure requests with a vector index?

With a documented procedure that locates the chunks derived from that source and deletes or reindexes them within a committed timeframe. Technically it requires storing the chunk-to-source relationship from the start; if you did not, the only route is rebuilding the whole index. It is one of those design decisions that is cheap early and very expensive later.

How much does this add to project cost?

On a scoped deployment, classification, permissions and retention work typically accounts for 15-30% of total effort the first time, and considerably less for subsequent agents because the framework already exists. Budgeting it from the outset avoids the awkward mid-project conversation where somebody discovers the pilot cannot go to production.