You Asked AI a Question. Now Follow the Data.
A documented capability is not the same as evidence of a transaction. Following one AI prompt end to end reveals what your organisation must be able to show after the fact.
Can we actually see what happened between the question and the answer?
I wrote recently about where organisational data goes when AI touches it. This week I want to follow one prompt the whole way through.
To the person typing, it looks like a single action, one question in and one answer back.
Behind that single prompt sits a chain of systems.
A prompt can trigger authentication, policy and permission checks, retrieval from enterprise data, grounding the response in that data, model inference, response generation and logging.
That's a lot of moving parts behind one question.
Microsoft publicly documents Copilot interaction records, audit events and eDiscovery capabilities, along with the architecture behind them.
That's useful.
But I think a documented capability is not the same thing as evidence of a transaction.
Which events are actually captured still depends on your product and licensing configuration. That part sits with the organisation, not the vendor.
The depth of the record should match the risk of the use case. Drafting a meeting agenda does not need the same evidence trail as summarising project risk across a sensitive program.
So here's something I've found useful.
If you are able to, take one real prompt from last week, something like "Summarise the key risks across our major projects", and follow it from the user to the AI application, through identity and permissions, into the data sources, the retrieval layer and the model.
Then follow it back out through the response and logging layers.
The answer that came back is the easy part, and the harder question is what information the system could reach to produce it.
For that one prompt, I think we should be able to answer:
Can we identify the user?
Which data was retrieved?
Where did that data come from?
Which AI service or model processed it?
What was logged?
How long is that evidence kept?
And perhaps most importantly:
Can we reconstruct the whole transaction after the fact?
If we want to test that properly, we should be asking for the evidence rather than the assurance: audit events, prompt and response retention settings, records of referenced content, identity information, connector logs and model or service identifiers where they're available.
If we're in a Microsoft environment, Purview and the related compliance tooling hold much of that evidence, including retention and eDiscovery.
If we cannot trace the transaction, we cannot investigate an inappropriate disclosure, explain an AI-generated decision or show compliance after something has gone wrong.
Last week the question was where our data goes. This week it's narrower: what can we actually show?
Microsoft can document the architecture. The record of what our own AI touched, and when, is ours to produce.
That's a conversation I'm particularly interested in exploring further.
#AI #AIGovernance #DataGovernance #AIAssurance #AuditTrail #eDiscovery #InformationManagement #ResponsibleAI #MicrosoftCopilot
Sources / further reading:
• Microsoft Learn, Microsoft Copilot data protection architecture: https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-architecture-data-protection-auditing
• Microsoft Learn, Microsoft Copilot Chat Privacy and Protections: https://learn.microsoft.com/en-us/copilot/privacy-and-protections
• Microsoft Learn, Secure and governed foundation for Copilot: https://learn.microsoft.com/en-us/microsoft-365/copilot/configure-secure-governed-data-foundation-microsoft-365-copilot
• Microsoft Learn, Microsoft Purview AI data security: https://learn.microsoft.com/en-us/purview/ai-microsoft-purview
// Want to talk?
If you have questions, concerns, or you're simply curious, get in touch with us.
Get in touch