AI for SOPs, Policies and Institutional Knowledge

Why do SOPs stop matching how the work is really done?

Most companies have two procedures for everything. There is the written one, produced for a certification, a client audit or an investor, and there is the real one, which lives in the hands of the people doing the work. The written version was accurate on the day it was signed. Then a portal changed, a tax rule changed, a large customer insisted on a different label, and the real process moved on without telling the document.

The cost is easy to see once you look for it. New joiners learn from whoever sits closest, so two branches handle the same case differently. Nobody can cover for a colleague on leave. When someone with fifteen years of context resigns, a month of notice is not enough to get it out of their head, and the knowledge leaves with them. This is institutional knowledge: valuable, entirely undocumented and completely invisible on a balance sheet.

How do you get what experienced staff know out of their heads?

Asking your best dispatch supervisor to “write the SOP” usually fails. Writing is a separate skill, it competes with a full day of work, and the parts they know so well that they no longer notice them are exactly the parts a newcomer needs. Talking is easier than writing, and correcting a draft is easier still.

1. Record a thirty-minute walkthrough while they do the task, narrating what they check and why.
2. Follow one real case end to end, including a messy one, rather than the ideal version.
3. Capture exceptions as they happen. When someone handles a case unusually, ask that day why.
4. Harvest what already exists: the long chat answers, the email they resend every week, the notebook checklist.
5. Interview two people who do the job differently. The disagreement is the interesting part.

AI helps with the tedious middle. A recording becomes a transcript, the transcript becomes a first draft in your own template, and the draft comes with a list of the questions it could not answer: which system the record is created in, who approves the exception, what happens on a holiday. The supervisor then spends twenty minutes correcting a draft instead of a week failing to start a blank page.

What can AI safely draft, refresh or summarise?

Treat it as a drafting assistant with no authority. It can produce, compare and reformat text quickly. It cannot decide what your policy is, and it does not know which of two contradictory documents the business intends to follow.

Every row ends with a name, and that is the point. NIST’s profile for generative AI notes that organisational use of these systems may warrant additional human review, tracking and documentation, and greater management oversight. Its parent framework asks for policies and procedures that define and differentiate roles and responsibilities for human oversight of AI systems. India’s own AI governance guidelines make a related point, calling for human-in-the-loop mechanisms at critical decision points so that outputs can be reviewed, overridden or supplemented by human judgement before they cause harm. For SOPs that becomes one sentence in your document control note: a generated draft stays a draft until the named approver signs the version.

How should versions and approvals work?

Document control sounds like an audit word, and it is really just five fields. Any team can keep them, and without them nobody can tell which copy is real. If you already work to a quality standard, you will have most of this in place; the discipline matters more than the format.

• One live version per procedure, with a version number and an effective date.
• A named owner who maintains it, and a named approver who signed it.
• A short change note saying what changed and why, in plain words.
• Superseded versions archived rather than deleted, so you can show what applied in March.
• A review date, plus a rule that a system change triggers a review immediately.

These fields also pay off later. When a procedure becomes a source for an internal assistant, the version and the review date should travel with any answer taken from it. That is how our Enterprise Knowledge work is set up: source owners keep the content, and the answers show what was used and when it was last reviewed.

How do you keep policies from contradicting each other?

Contradiction is the quiet failure of a growing document set. Each policy is fine on its own. Read together, the branch manual and the finance approval matrix say different things about who may approve what, and staff follow whichever they were shown first. Comparing documents is dull, mechanical work, which makes it a good use for a drafting assistant: it can list every place two documents disagree and quote both.

Run the comparison when any policy changes, and once a quarter across the whole set. Keep the output as a list a person works through, not as automatic edits. The value is in surfacing the disagreement early, while it is still a document problem rather than a customer complaint.

How does this help training and onboarding?

Good procedures make a new joiner useful faster, and they make cover for leave possible. Once the documents are current and owned, a few small things help more than a training platform.

• A reading path per role, in order, with the current version of each document.
• A one-page summary of each long procedure, approved by the same owner.
• Practice questions drafted from the procedure and checked by the owner.
• A short note to the team whenever a procedure changes, saying what is different.
• A record of who has read the current version, which also answers audit questions.

Keep the limits honest. Reading a procedure is not the same as being able to follow it under pressure with an annoyed customer on the line. Supervised practice, a buddy for the first weeks and a named person to ask are still the parts that make somebody competent. Documentation makes those conversations shorter; it does not replace them.

How is this different from an internal knowledge assistant?

Two jobs sit side by side and are often confused. This one is about the source: capturing what people know, writing it down, approving it and keeping it current. The other is about the surface: answering everyday questions from those documents, with citations and permissions. How to build an internal knowledge system employees can trust covers the second in detail.

They depend on each other. An assistant sitting on a stale, contradictory document set will answer confidently and wrongly, and your team will stop using it within a month. A beautifully maintained set of procedures nobody can find at the moment they need one is only slightly better. Fix the sources first, then make them easy to reach, and give both halves the same owner so neither becomes somebody else’s problem.