An audit trail for AI use is a traceable record of who used which AI tool and when, which data it accessed, and what happened to the result. It answers, after the fact, the question a record of processing activities cannot: what concretely happened?
The difference matters. The record of processing activities under Art. 30 GDPR describes processing in general: purposes, data categories and recipients. Logging captures the individual case. If a client asks whether her documents were loaded into an AI tool, or an employee accidentally pasted a salary list into the wrong chat, the record of processing will not help you. You need logs.
This post explains why logging AI tools is part of GDPR accountability, what a useful audit trail contains, and where logging itself becomes a data protection problem.
Do I have to log AI use?
The GDPR has no article that literally says: log every use of AI. The obligation follows from several provisions taken together.
Accountability. Under Art. 5(2) GDPR you must not only comply with the data protection principles but be able to demonstrate compliance. Art. 24(1) repeats this for technical and organisational measures. A rule whose compliance you cannot evidence is, in an audit, just a claim.
Security of processing. Art. 32 GDPR requires appropriate security measures, including a process for regularly testing their effectiveness. Without logs you cannot check whether access rules actually work.
Data breaches. Art. 33(5) GDPR requires you to document personal data breaches, including the facts and their effects. If you cannot trace which data went into which tool, you cannot describe the effects or assess the risk to the people affected. For notifying the supervisory authority you generally have 72 hours.
EU AI Act. For most office uses, such as drafting or summarising text, the AI Act adds no logging obligation of its own. High-risk AI systems are different: under Art. 26(6), deployers must keep the automatically generated logs for at least six months, to the extent those logs are under their control. If you use AI for things like hiring decisions or creditworthiness assessments, look at this more closely.
In short: there is no explicit obligation for every prompt. But without logging you cannot evidence most of your data protection obligations for AI tools.
What belongs in an AI audit trail?
I think about AI logging in five layers. Not every layer is available for every tool, but you should know which ones you have and which are missing.
1. Usage. Who used the tool, when, with which account and on which plan? This is the foundation. If employees sign in with personal accounts, it is already missing, and that is the core of shadow AI.
2. Data access. Which files, mailboxes or shared folders did the AI access for a request, and which files were uploaded? For AI assistants built into your office environment this is the most important layer, because the AI reads with the user’s permissions. An audit trail then shows whether permissions are too broad before someone else notices.
3. Configuration. Who changed which setting, and when? This includes training on customer data on or off, data region, web search, connected data sources and plug-ins. This layer is forgotten most often. Yet a changed setting is frequently the reason a cleanly introduced AI rollout no longer matches your DPIA six months later. The settings that matter for Copilot are covered in the post on Copilot settings under GDPR.
4. Use of results. Was the result reviewed and adopted, and by whom? No AI tool logs this automatically. It belongs in your own workflows, for example as a short note in the file when an AI draft went into a client letter. For law firms and tax advisors, this is the evidence that a professional takes responsibility for the result, not the machine.
5. Access to the logs themselves. Who viewed or exported the logs, and why? Logs of AI use contain employee data and often client data. Access to them must be traceable too.
Should I store the content of prompts?
In most cases no, at least not by default.
A log that stores every prompt and every answer in full creates a second copy of all the data your employees entered into the AI. If that includes client data, health information or salaries, you have not reduced the risk, you have doubled it. Art. 5(1)(c) GDPR (data minimisation) and Art. 5(1)(e) (storage limitation) apply to your logs as well.
My recommendation:
- Metadata by default: user, time, tool, type of action, files or sources accessed.
- Content only with a purpose: for example when you have to document certain matters for professional reasons, and then with a short, defined retention period and tightly limited access.
- Protection upstream of the log: if sensitive data never reaches the AI, it never reaches the log either. How to do that technically is covered in the post on automating PII redaction.
For professionals bound by confidentiality there is one more point: logs that contain client content are subject to the same secrecy as the file itself. Anyone with access to those logs, such as an external IT provider, must be bound accordingly. The basics are in the post on client data and Section 203 of the German Criminal Code.
What do AI vendors provide?
That depends almost entirely on the plan.
Business and enterprise plans usually offer audit logs, admin reports or export interfaces. In Microsoft 365, for example, Copilot interactions are recorded in the unified audit log in Microsoft Purview. How long these entries are kept and how detailed they are depends on your licence and settings. Free and single-user versions generally offer no central logging that you as an employer can review.
Check four things for every AI tool:
- Is there an audit log you can view as an administrator?
- What does it contain: only sign-ins, or also data access and configuration changes?
- How long is it kept, and can you change the period?
- Can you export it before the vendor deletes it?
The answers belong in your documentation. If a tool has none of these functions, that is a finding for your risk assessment. A tool with no traceability at all is hard to justify for personal data. You should have noted the vendor’s retention periods for prompts and logs during your DPA review anyway.
How long should I keep AI logs?
The GDPR sets no fixed period. Retention has to follow the purpose, and you have to define and justify it.
A practical approach: ask what you need the log for. To investigate security incidents, you need a period that realistically covers the time until an incident is noticed. For configuration changes a longer period can make sense, because they document your DPIA and your settings over time. For content, if you store it at all, use the shortest period that still serves the purpose.
If you operate a high-risk AI system, six months under Art. 26(6) of the AI Act is the minimum. In all other cases, write the chosen period and the reasoning into your deletion policy and into the entry in your record of processing.
Logs and employee monitoring
AI logs show who worked how much with which tool, and when. That makes them technically suitable for monitoring employee performance and behaviour. In German businesses with a works council, introducing such technical systems requires co-determination under Section 87(1) no. 6 of the Works Constitution Act (BetrVG), regardless of whether you intend to monitor anyone.
That is not a reason to skip logging. It is a reason to decide up front what logs may and may not be used for. What that looks like in a works agreement is covered in the post on the AI works agreement for Copilot. Without a works council, the same rule belongs in your AI use policy, so your employees know what is logged and why.
The three most common mistakes
Mistake 1: Assuming the vendor logs everything. Many people assume the vendor records everything and it can be retrieved when needed. Often that is not true, or the retention period has expired before anyone looks. Check before you need it.
Mistake 2: Storing everything in full. From my time in security practice I know the reflex to log as much as possible when in doubt. With AI tools that reflex is wrong. A log of complete prompts is a collection of exactly the data you wanted to protect, just in one more place.
Mistake 3: Logs nobody looks at. An audit log that is never reviewed satisfies Art. 32 only on paper. Decide who looks at the logs, how often, and what to look for, such as unusual data access or changed settings. In a small business, one spot check a month with a short note that it happened is enough.
Checklist: review your AI logging in one hour
- List every AI tool in use, including those not bought through IT.
- For each tool, note whether an audit log exists and who can access it.
- Check the content: usage, data access, configuration changes.
- Note the vendor’s retention period and compare it with what you need.
- Sort out export if the vendor’s period is too short.
- Decide whether content is stored, and if so, set purpose, retention and access.
- Define how results are documented, for example a note in the file for AI-assisted drafts.
- Write down what logs may be used for in a works agreement or your AI use policy.
- Set a review rhythm and document that it is followed.
- Carry the results into your record of processing and, if you have one, your DPIA.
The next step
Take the AI tool your business uses most and answer one question: could you prove today which employee processed which files with it last week? If not, you know where to start.
If you want to see where else there are gaps between AI use and evidence in your business, take my free AI compliance check. It takes 2 minutes and shows you which points to tackle first.
Jose Lugo is a CISSP-certified AI compliance consultant. He advises law firms, tax advisors and financial services firms in Germany on introducing AI tools in a GDPR-compliant way.