What an AI Can and Cannot Read Out of Your SOPs

AI document extraction pulls structure out of your written procedures: the steps, the roles named in them, the systems they mention and the order they claim to run in. It does this quickly and accurately, and the important limitation is not accuracy at all. It is that a document can only tell you what somebody wrote down once, and the model has no way of knowing which sentences are still true.

That is the whole shape of the problem, and it is worth understanding before you feed a folder of SOPs into anything.

What comes out well

Documents are good at some things and models are good at reading them.

Named steps come out cleanly. If a procedure says the account manager raises the ticket, then finance approves it, then the ticket is closed, you get three steps with two handoffs and two roles, and you get them without anyone spending an afternoon retyping.

Systems come out well too, because documents name their tools. Every mention of a CRM, a shared drive, a ticketing system or a spreadsheet is a real signal about what the business runs on, and collected across fifty documents it produces a list that is usually longer than the one finance has.

Roles come out well, and better than names do. Documents tend to say "the operations lead" rather than "Priya", which is the form you want anyway, because roles survive resignations.

And contradictions between documents come out very well. Two SOPs describing the same handoff differently is the kind of pattern a model spots immediately and a human reading fifty files in a week will not.

What does not come out at all

Four things are simply absent from the source, and no amount of model quality recovers them.

Waiting. Documents record actions, not the gaps between them. A procedure that reads as six steps might take nine days, and every one of those days sits in the whitespace between two lines nobody wrote.

Frequency. A document describes the process once. It does not tell you whether this runs four hundred times a month or twice a year, and without that you cannot rank anything. A beautifully documented annual process is worth less attention than an undocumented daily one.

The exception path. Most procedures describe the version where nothing goes wrong, because that is the version that is easy to write. The failure branches are where a lot of the actual effort lives.

And workarounds, obviously. The whole category of thing that people invented because the official route was slow is by definition not in the document about the official route.

The confident wrongness problem

Here is the failure mode that matters, and it is not the one people expect.

A model reading a procedure written in 2023 will summarise it fluently and with no hedging, because the text gives it nothing to hedge about. If the tool named in step four was replaced eighteen months ago, the extraction is faithful to the document and wrong about the business. Nothing in the output will flag it.

That is worse than a gap. A gap is visible. A confident, well-formatted, entirely obsolete process map looks exactly like a correct one, and people act on it.

So the useful question is never "can it read the document". It reads the document fine. The question is what you check the reading against.

Documents beside accounts, not instead of them

The answer is unglamorous: you need both, and you need them side by side.

A document tells you what the business intended. A conversation with the person who runs the process tells you what happens. Where those two agree, you have something you can rely on. Where they diverge, you have found either a process that has drifted or a document that has rotted, and both are worth knowing about.

That is why abi. FDE reads your SOPs and playbooks into the same map the interviews build, so the documented version sits next to the real one and the gap between them is visible rather than assumed. Building the map by hand is free on any account. The interviews and the document reading are the paid part, because they are the parts that cost anything to run.

Which documents are worth reading

Not all of them. This is where most of the wasted effort goes.

Feed it the procedures for work that happens often and crosses between people. Quote to cash. New client to live account. Ticket to resolution. These are the ones where the gap between document and reality costs money weekly.

Feed it the things people are actually handed, which are frequently not the official SOPs. Onboarding checklists, the email someone wrote to explain a process to a colleague, the pinned message in a channel. Informal documents are often more current than formal ones, because nobody had to convene anything to update them.

Skip the policies. Skip anything written to satisfy an audit rather than to be followed. Skip the strategy decks. They describe intent at a level too high to map, and they will pull the output toward the aspirational.

The honest counter-argument

If your documentation is genuinely good, current, and maintained by someone whose job includes maintaining it, most of this piece does not apply to you. Read the documents, trust them, and spend the effort somewhere else. Companies like this exist, mostly in regulated industries where somebody is audited on it, and they should not be talked out of an asset they have paid to keep.

The other honest point is about scale. Under about ten people, do not build a pipeline for this. You can read your own procedures in an afternoon, and you already know which ones are fiction. The value of automated reading scales with volume, and at fifteen documents the volume is not there.

What to do with the output

Treat an extraction as a set of claims to be checked, not a map to be trusted.

Print the steps. Take them to the person who runs the process. Ask which lines are still true. You will find that some are, some were never true, and a few were true and quietly stopped being so, and that third category is the most valuable thing the exercise produces.

The document was never going to give you the truth. It was going to give you a fast, cheap first draft of the questions worth asking.