Turn SOPs into a cited AI assistant without losing version control
Use this SOP-readiness scorecard and conflict test to build a cited internal AI assistant while keeping versions, approvals, and permissions controlled.
Standard operating procedures are attractive material for an internal AI assistant: they answer repetitive questions, guide onboarding, and make operations less dependent on a few experienced people. They are also risky material to connect carelessly. If the assistant retrieves an obsolete procedure, merges two site-specific variants, or ignores an exception, it can make the wrong action feel official.
The goal is not to copy SOPs into a chatbot. It is to add a conversational access layer while the document system remains the authority. Version history, approvals, owners, effective dates, permissions, and retention still belong in the source system. The assistant should retrieve that evidence, cite it, and expose conflicts.
This guide includes an SOP-readiness scorecard and a concrete test for contradictory versions.
What “ready for an AI assistant” means
ISO 10013 provides guidance for developing and maintaining documented information that supports an effective quality management system. Microsoft describes version history as a way to view, compare, restore, and audit changes in SharePoint and OneDrive. Those are document-control capabilities; an AI answer does not replace them.
For each procedure, define at least:
- a unique procedure ID and human-readable title;
- an owner who can approve changes;
- status: draft, approved, superseded, or archived;
- version and effective date;
- business unit, site, product, or jurisdiction in scope;
- roles allowed to view it;
- linked forms, records, and evidence;
- the procedure it replaces, when applicable.
Put these fields in controlled metadata when possible. Do not expect the model to reliably infer authority from filenames such as FINAL_v7_really-final.pdf.
SOP-readiness scorecard
Score every dimension from 0 to 2:
| Dimension | 0 | 1 | 2 |
|---|---|---|---|
| Owner | No accountable owner | Team named | Named owner and backup |
| Approval | Draft status unclear | Informal approval | Recorded approval and date |
| Version | Duplicates, no version | Version in filename | Controlled version metadata |
| Effective date | Missing | Present in text | Structured and queryable |
| Scope | Unstated | Implied | Site, role, product, and jurisdiction explicit |
| Exceptions | Tribal knowledge | Partial notes | Exceptions and escalation documented |
| Permissions | Broad or unknown | Folder-based guess | Tested role-based access |
| Evidence | No linked record | Example only | Required form or record clearly linked |
| Supersession | Old copies coexist | Archived manually | Replacement relationship recorded |
| Conflict behavior | Untested | Warning only | Assistant cites both and stops |
A procedure scoring below 14 out of 20 should not be used for action-critical answers without remediation. This threshold is an operating choice, not an ISO requirement. More important than the total are hard gates: unknown approval, broken permissions, or untested conflict handling should block production use.
The conflict test: two procedures enter, no invented winner leaves
Create a synthetic example:
SOP-014 v3, approved in 2025, says a store manager can authorize refunds up to €500.SOP-014 v4, effective 1 August 2026, lowers the limit to €250.- A local checklist copied before the change still mentions €500.
Ask: “Can the manager approve a €400 refund today?”
A reliable assistant should identify v4 as the current controlled procedure, cite the exact passage and effective date, mention that an older conflicting checklist exists, and say that the €400 refund requires the documented escalation route. It should not average the limits, choose the most frequently repeated value, or hide the conflict.
Now change the user to someone who cannot access refund procedures. The answer, snippets, and citations must not reveal either limit. This verifies permissions at retrieval time, not merely polite wording after restricted text has already been retrieved.
Finally, remove v4 from the index while leaving its metadata record. The assistant should state that it cannot access the current approved procedure and decline to give the limit. Missing evidence is an operational signal, not an invitation to fall back to v3.
Keep version control in the owner system
The document repository should remain responsible for drafts, approvals, check-in history, restoration, retention, and access. Microsoft notes that SharePoint version history can show who changed a file and when, compare versions, and restore a previous version. The assistant's index should preserve stable identifiers and refresh when the source changes; it should not become an unofficial fork of the SOP library.
Use one canonical location per controlled procedure. Links from handbooks, training pages, or local portals should point to it rather than hosting copies. When a new version becomes effective, mark the prior one as superseded and record the relationship. Historical versions may remain available for audit or incident review, but retrieval policy should distinguish historical evidence from current instructions.
Design the answer contract
For procedural questions, require a consistent structure:
- Applicable procedure: ID, title, version, and effective date.
- Answer: the steps relevant to the user's role and location.
- Evidence: citations to the exact source passages and linked forms.
- Conditions: prerequisites, exceptions, and stop points.
- Conflict or gap: any competing version or missing source.
- Escalation: named role, not an invented decision.
NIST's definition of retrieval-augmented generation explains the core mechanism: relevant information is retrieved from a separate knowledge base and supplied to the model for the response. The design challenge is ensuring that “relevant” also means authorized, current, applicable, and inspectable.
Secure the operational layer
The NCSC secure-AI guidance recommends tracking, authenticating, version-controlling, and protecting AI-related assets, as well as controlling what data AI systems can access. Apply the same discipline to prompts, retrieval configuration, evaluation sets, and logs. An approved SOP library is not enough if the assistant's configuration can be changed without review or if conversation logs expose sensitive procedures.
Use synthetic or redacted documents for initial tests. Record which prompts, roles, source versions, and expected answers were used. Re-run the suite after connector changes, permission changes, or a significant model update.
A four-week implementation plan
Week 1: choose one procedure family with frequent questions and manageable risk. Inventory every copy and assign canonical owners.
Week 2: repair metadata, approvals, effective dates, scope, and supersession links. Move uncontrolled copies out of the current-instructions path.
Week 3: connect the canonical library and run questions for multiple roles, sites, and ambiguous wording. Include missing-answer and conflicting-version fixtures.
Week 4: pilot with a small group. Review citations and gaps weekly. Keep a human checkpoint for safety-critical, financial, legal, or irreversible actions.
Evaluate it with Polp
Polp is designed to answer from connected company documents with traceable sources. Start with a controlled Google Drive integration folder or equivalent source and use the RAG glossary guide to align the team on how retrieval differs from model memory.
For operations across sites, compare the workflow with the AI for franchises use case. Then request a Polp demo using the v3/v4 conflict fixture. A successful evaluation is not “the assistant answered.” It is “the assistant selected the applicable version, cited it, preserved permissions, and stopped when authority was missing.”