A project manager asks the company's AI assistant a simple question:
“What approval do I need before moving this application to the cloud?”
The answer is clear. It lists the steps, names the review team and includes a citation. The project manager copies it into the migration plan.
Later, the security reviewer asks why the plan follows last year's process.
The assistant found a document. It even showed where the answer came from. But the document was a presentation used during an earlier pilot. The approved process had changed.
This is a hypothetical example, but the underlying question is practical: how does your organisation distinguish a useful document from one that is authorised to guide a decision?
Three documents, three different jobs
Imagine the assistant can access three files about the same process.
One is the approved policy, effective this quarter. Another is a draft proposing changes for next quarter. The third is an onboarding presentation explaining an older version.
All three discuss cloud approvals. All three may contain accurate statements about their own context. All three may be legitimate for the user to read.
They serve different purposes.
The policy defines the current requirement. The draft describes a change under consideration. The presentation helps explain what people were taught at the time.
For a question about today's approval process, those differences determine which answer the user should act on. For a question about why the process changed, all three may be relevant.
That is why simply collecting more documents does not settle the problem. The assistant needs the right source for the question, with enough context to establish its role.
Access permission and authority answer different questions
An access control answers whether a person may read a document. It does not establish whether the document expresses the organisation's current position.
Microsoft's documentation says Microsoft Copilot can summarise or reference content the user is authorised to access. That is a protection boundary. It does not make every accessible file an approved policy.[1]
An old process document may remain available for audit, training or historical analysis. A draft may be shared widely for consultation. Their availability is legitimate. Their use as current instruction may be inappropriate.
This distinction matters when reviewing an AI rollout. A permissions review and a content authority review resolve different problems. Completing one does not complete the other.
A citation gives you somewhere to check
A citation is useful. It lets the reader inspect the source behind an answer.
But a citation alone cannot establish that the source is current, approved or applicable to the user's situation. The reader still needs to know what the document represents.
Microsoft's guidance explicitly warns that Copilot can provide outdated answers if it is pointed at an old website or an earlier file version. It advises users to identify the specific current source and verify critical details.[2]
For an enterprise assistant, I would turn that concern into a design question: can the system show the source's approval status, effective date and scope alongside its citation?
A link labelled “Cloud Migration Process” leaves work for the reader. A source identified as approved, effective from a stated date, and applicable to the relevant business unit provides a better basis for checking the answer.
The information has to exist and remain accurate before the interface can display it reliably.
Define authority for a question, rather than for every file
The phrase “single source of truth” sounds straightforward until a real question crosses several domains.
A migration decision might involve a cloud policy, a data-handling standard, a security review process and a local operating procedure. One document cannot necessarily settle all four.
I would start by assigning authority to a class of questions.
| Question | Source that should settle it | Useful supporting content |
|---|---|---|
| What approvals apply today? | Current approved approval process | Examples and training material |
| Where may this data be processed? | Applicable approved data-handling rules | Design notes and assessments |
| How do I submit the request? | Current maintained operating procedure | Walkthroughs and screenshots |
| What change is being considered? | Identified draft under review | Discussion notes and feedback |
The supporting content remains useful. It should carry enough context to keep an explanation, example or draft from quietly becoming an instruction.
Where approved sources disagree, the organisation needs a precedence rule or an owner who can resolve the conflict. An assistant should not be expected to invent that decision.
Start with a small information contract
For one important use case, I would agree a minimum set of information with the content owner:
- Owner: who can confirm or correct the source.
- Status: draft, approved, superseded or historical.
- Effective period: when the instruction applies.
- Scope: which service, location, business unit or activity it covers.
- Replacement: which source supersedes it, if applicable.
These fields can live in managed metadata, a controlled register or a clearly maintained source page. The implementation depends on the platform. A field printed in a document is not automatically a retrieval filter; the search or assistant design must actually use it where required.
Nor does a metadata value prove itself. Someone needs responsibility for updating it when a decision changes.
Better ranking can help identify a relevant document, and reliable approval and effective-date information can improve that ranking. But the latest file may still be an unapproved draft. The organisation must establish which source governs the decision; retrieval should use that judgement.
The purpose is to make the organisation's judgement usable by both people and software. Renaming a file FINAL_v7_APPROVED is a fragile substitute for that judgement.
Preserve history without letting it answer today's question
Deleting every old document is a poor default. Historical content may explain decisions, support recordkeeping or show what was approved at a particular time.
The practical requirement is to distinguish its use.
For a custom assistant answering current policy questions, I would first limit the relevant retrieval scope to maintained, applicable sources. Historical material could remain available through a separate history question or clearly identified supporting evidence.
If the platform cannot enforce that distinction, narrow the pilot or require source verification before users act. Do not describe a prompt instruction as a guaranteed exclusion control.
Microsoft's governance guidance also treats content lifecycle work as part of improving Copilot answer quality, including dealing with inactive and obsolete content through appropriate retention and archiving arrangements.[3]
The exact controls differ by platform. The organisation still has to decide what should remain available, for which purpose, and under whose ownership.
Test the conflict, not just the easy answer
A pilot demonstration often asks a question for which the answer is obvious and well documented. That tests usefulness, but leaves source authority largely unexamined.
I would add deliberate conflict cases in a controlled test environment.
Ask the same current-process question when an old presentation remains accessible. Add a newer draft that has not been approved. Include a local procedure that applies to a different business unit. Then test a question for which there is no maintained approved source.
The desired behaviour should be written down before the test. For this use case, I would expect the assistant to identify the applicable approved source, distinguish a draft from current instruction, and flag an unresolved conflict or missing authority.
A failure could come from content, metadata, retrieval, indexing delays or answer generation. Recording which part failed is more useful than treating every incorrect answer as a model problem.
Also test what happens after a policy change. Updating the source does not by itself demonstrate that every index or cached result has caught up. Verify the answer again through the actual user path.
Make the ownership visible
The platform team can operate the assistant. It cannot decide whether a security policy is still valid on behalf of its owner.
The content owner should maintain the instruction and its status. The architecture team can help define source precedence across domains. The assistant team should implement the retrieval behaviour and report failures. Users need a simple way to challenge an answer and reach the person who can resolve it.
For a first step, choose one frequently asked process question. Gather the files that answer it today. Ask the responsible owner which one should govern the decision, what its scope is, and what the assistant should do if it finds a conflict.
If that discussion is difficult, it has revealed work worth doing before extending the assistant to more repositories.
The document may be easy to find. The organisation still needs to make clear when it should be trusted.
Sources
- Microsoft Learn — How data is protected and audited in Microsoft 365 and Microsoft Copilot
- Microsoft Support — What information does Copilot use to answer my prompt?
- Microsoft Learn — Configure a secure and governed foundation for Microsoft Copilot
Continue exploring