AI Audit Logs For Copilots In Microsoft 365 And Google Workspace

Tools & Technical Tutorials

1 August 2026 | By Ashley Marshall

Copilots are becoming part of everyday work, but many UK firms still cannot answer the awkward question: who asked the AI to do what, with which data, and what happened next?

Copilot adoption changes what evidence you need

Most businesses already have audit logs. Microsoft 365, Google Workspace, CRM platforms, finance systems and identity providers all record pieces of activity. The problem is that AI copilots change the shape of the evidence. A person no longer just opens a document, sends an email or downloads a report. They may ask an assistant to summarise a folder, draft a reply using customer history, search across files they rarely open directly, or trigger a workflow through a connected app. The audit question becomes less about one click and more about a chain of intent, access, output and action.

That matters for UK leaders because AI assistants now sit close to commercially sensitive and personal data. The ICO's guidance on AI and data protection was updated on 21 January 2026 and keeps the focus on accountability, lawfulness, fairness, transparency, data minimisation, security and individual rights. None of those duties can be evidenced properly if the business cannot reconstruct how an AI assisted decision or output was produced.

The common misconception is that copilot logging is purely a security team issue. It is not. Security needs logs for investigation. Privacy needs logs for accountability and data subject rights. Operations needs logs to understand workflow failure. Legal needs logs when a customer, employee or regulator asks how an outcome happened. Finance needs logs where AI is connected to approvals, spend or revenue processes. If each team asks for a different report after the event, the evidence will be fragmented.

What this means in practice is that copilot rollout should start with an evidence map. List the AI assistants in scope, the systems they can access, the identities they act under, the data types they may touch, and the business actions they can influence. Then decide which logs prove each step. For a simple drafting copilot, identity, prompt metadata, source files and output may be enough. For an agent that can update CRM records, create tickets or send messages, you need tool-call logs, approval records, before-and-after state, and a clear human owner for each action.

Start with what Microsoft and Google actually record

For many UK organisations, the practical starting point is Microsoft 365 or Google Workspace. These platforms already provide admin and user activity logs, but the coverage, licence requirements, retention periods and search experience vary. Treat the platform documentation as a control baseline, not a complete governance model.

Microsoft says its Purview auditing solutions provide a unified audit log to monitor thousands of user and admin operations across Microsoft services. The Microsoft Purview audit overview describes searchable audit records across services such as Exchange, SharePoint, OneDrive, Teams, Microsoft Entra ID and other Microsoft 365 workloads. For businesses using Microsoft 365 Copilot, that wider audit layer matters because Copilot responses are grounded in the user's permitted content. If access permissions are messy, the assistant can surface information the user technically has permission to read even if the business would not expect it to appear in that context.

Google Workspace has a similar evidence challenge. Google Workspace Admin Help describes audit and investigation tools that let administrators review user and admin activity across services. Its data retention and reports guidance points administrators towards audit logs, reports and the security investigation tool depending on edition and configuration. For Gemini in Workspace, those logs sit alongside Drive, Gmail, Calendar, Meet and admin activity, which means the useful investigation often requires connecting AI use to file access, sharing changes and identity events.

The key buyer question is not whether the platform has logs. It is whether your business can search the right logs quickly, retain them for long enough, export them when needed, and connect them to a named workflow. Ask what AI-specific events are visible today, what is only visible as surrounding app activity, which logs require premium licensing, how long records are retained by default, and whether logs include enough context to investigate a disputed output. If the answer is unclear, treat that as an implementation gap before allowing the copilot near sensitive workflows.

Define the minimum useful copilot audit record

An audit strategy becomes useful when it names the evidence needed for a real investigation. Start with identity. Which user initiated the request? Was the action performed under the user's own permissions, a service account, an app permission, or delegated authority? Which device, session, IP range or conditional access state was involved? Without identity context, a copilot log is little more than a timestamped curiosity.

Next, capture access context. Which repositories, mailboxes, calendars, chats, CRM objects, tickets, spreadsheets or knowledge bases could the assistant access at that moment? Which specific sources were actually used or cited? Was the user already entitled to view them? Were external guests, shared links or stale group memberships involved? This is where many firms discover that their AI problem is really an information architecture problem. Copilots expose permission sprawl because they make existing access easier to exploit at speed.

Then record the request, output and action boundary. The raw prompt may contain personal data, trade secrets or privileged material, so retention needs careful design. But the business still needs enough detail to understand the user's intent, the output category, the data sources, the model or feature used, and any downstream action. A summary may be sufficient for low-risk tasks. High-risk workflows need stronger evidence, including before-and-after records, approval decisions, tool calls, exception handling and human review notes.

Finally, include governance metadata. Which policy applied? Was the request blocked, allowed, warned or escalated? Did a data loss prevention rule trigger? Did the system produce a confidence score, citation set or safety event? Which team owns review of that event? The GOV.UK Code of Practice for the Cyber Security of AI places emphasis on secure operation, monitoring, logging, incident management and supply chain risk across the AI lifecycle. A copilot audit record should reflect that operational reality. It should show not only what happened, but whether the system behaved inside agreed boundaries.

Retention is a business decision, not a default setting

Log retention is often left to whatever the platform does by default. That is a weak control for AI. Some evidence is needed only for short-term troubleshooting. Some is needed for security investigations. Some may be needed for customer complaints, employment disputes, data protection rights, insurance questions, litigation holds or regulator engagement. The retention period should follow the risk of the workflow, not the convenience of the admin console.

UK GDPR also cuts both ways. The ICO's AI guidance reminds organisations to consider data minimisation, security and accountability. Keeping every prompt forever is rarely defensible, especially if prompts can contain personal data, special category data, customer secrets or staff information. Deleting everything after a few days can be equally indefensible if the business cannot investigate a harmful output or prove that a decision was reviewed by a person. The right answer is proportionate retention with clear purpose, access controls and deletion rules.

For Microsoft 365 and Google Workspace, this means separating log classes. Security-critical events, admin changes, connector permissions, external sharing changes, data loss prevention alerts and high-risk AI actions may need longer retention. Low-risk drafting prompts may need shorter retention or only metadata. Where logs include content, apply stricter access controls and make sure legal, privacy and security teams agree who can search them. Where logs are exported to a SIEM or data lake, treat that export as a new data store with its own retention and access policy.

What this means in practice is that every copilot rollout should include a retention table. Columns should include event type, business purpose, data included, owner, retention period, storage location, access roles, deletion process and escalation trigger. Do not bury this in a generic IT policy. The teams using the assistant need to understand what is recorded. Staff transparency matters because people behave differently when they think AI use is either invisible or subject to vague surveillance. A clear policy protects the business and the people using the tools.

Use logs to catch permission creep before it becomes an incident

Copilot audit logs should not only be used after something goes wrong. They are also a way to detect permission creep, risky sharing patterns and poorly governed connectors before a formal incident occurs. The practical risk is simple: AI assistants make broad access more useful. A user who would never manually inspect hundreds of files can ask an assistant to summarise, compare or extract patterns from them. That makes stale access, overbroad groups and forgotten shared drives more consequential.

The GOV.UK AI cyber security code is useful here because it treats AI security as a lifecycle issue, not a launch checklist. It points organisations towards secure design, secure deployment, monitoring, logging, incident response and vulnerability management. For copilot environments, that means looking at the surrounding identity and data estate as much as the AI feature itself. Microsoft Entra groups, SharePoint permissions, Teams membership, Google Groups, Drive sharing, OAuth app grants, service accounts and admin roles all become part of the copilot control surface.

Build recurring reviews around the logs. Which users are asking assistants to search unusually broad repositories? Which files are frequently used as sources for AI summaries despite being old, sensitive or poorly owned? Which connectors have high privilege but low business justification? Which departments are triggering blocked prompts or data loss prevention warnings? Which users have access to content that no longer matches their role? These questions turn audit logs into a hygiene mechanism rather than a forensic archive.

The counterargument is that this level of monitoring sounds heavy for a smaller business. It does not need to be. Start with monthly exception reports for high-risk areas: finance folders, HR content, customer complaints, contracts, board papers and regulated advice. Review admin changes weekly. Review external sharing and app permissions before enabling broader AI access. If the business cannot do this manually, connect the logs to the existing SIEM, security dashboard or managed IT provider process. The aim is not to watch every employee's prompt. The aim is to catch structural risk while it is still cheap to fix.

Turn audit logs into an incident response workflow

The final test is whether the business can act on the evidence. A beautiful audit trail is not enough if nobody knows when to investigate it, who can access it, or what decision follows. Copilot logs should feed a simple incident response workflow covering detection, triage, containment, evidence preservation, customer or staff impact assessment, legal review and recovery.

Define triggers in plain language. Investigate when a copilot output may have exposed personal data to the wrong person, generated misleading customer advice, summarised restricted documents, used a connector outside its approved purpose, created or changed a business record without approval, or helped a user bypass a policy. Include non-security triggers too, such as repeated incorrect outputs in board reporting or workflow automation that creates operational errors. AI incidents are not always data breaches. Some are quality, fairness, contractual or governance failures.

For UK GDPR, the important point is that the 72-hour personal data breach reporting clock depends on becoming aware of a breach, not on when the IT team finishes perfect analysis. If copilot activity may have led to unauthorised disclosure, loss of control, unlawful access or harmful processing of personal data, the business needs a fast assessment route. Logs should help answer what data was involved, who could see it, whether it left the tenant, whether it was acted upon, and what containment steps were taken.

What this means in practice is a short runbook. Name the owner, backup owner, log sources, export process, retention hold process, decision thresholds, communications lead and recovery criteria. Test the runbook with one realistic scenario: a user asks a copilot to summarise a restricted HR folder, shares the output in a Teams channel or Google Chat space, and a manager relies on it. Can the business reconstruct source access, output, sharing path and impact? If not, the logging model is not ready. Copilots can be valuable, but only when the business can prove what happened when the answer matters.

Frequently Asked Questions

Do Microsoft 365 Copilot and Gemini for Workspace have audit logs?

Both ecosystems have audit, reporting and investigation capabilities, but coverage depends on edition, configuration and the specific service involved. Treat the platform logs as a baseline and check which AI-specific events, source access records, admin changes and retention settings are available in your tenant.

Should we store every AI prompt?

Not automatically. Raw prompts can contain personal data, trade secrets and privileged material. Use proportionate retention: keep enough evidence for accountability and investigation, but apply clear purpose limits, access controls and deletion rules.

What is the minimum audit evidence for a copilot workflow?

At minimum, record the user, time, system, data sources or repositories available, action requested, output category, downstream action, policy decision, approval status and any escalation or exception. High-risk workflows need more detail.

Who should own copilot audit logging?

Security usually owns the tooling, but the control should be jointly owned with privacy, legal, operations and the business process owner. AI logs are evidence for more than cyber incidents.

How long should AI copilot logs be retained?

Retention should follow workflow risk. Security, admin and high-risk action logs may need longer retention than low-risk drafting metadata. Document the purpose, data included, owner, access roles and deletion process for each log class.

Can audit logs solve oversharing in Microsoft 365 or Google Workspace?

No. Logs help detect and investigate oversharing, but they do not fix the underlying permissions. Copilot rollout should include access reviews for groups, shared drives, SharePoint sites, Teams, external sharing, app grants and service accounts.

When does a copilot issue become a data breach?

It depends on whether personal data was subject to unauthorised or unlawful processing, accidental loss, disclosure, access or damage. Logs should help the business assess what data was involved, who could see it, whether it left the environment and what harm might result.

What should smaller UK businesses do first?

Start with a narrow pilot, review permissions on the content in scope, turn on the available audit logs, define who can search them, set a simple retention rule and test one incident scenario before expanding access.