Quality Systems · AI Governance
Your SOPs Can’t Govern an AI
Your standard operating procedures live in a document management system as PDFs. They were authored by people, are read by people, and get reviewed on a calendar — once a year, maybe every two. That model has worked for decades, and it was built on an assumption so obvious no one ever wrote it down: that the only thing reading your procedures is a human being.
That assumption is about to break.
AI tooling is entering regulated operations. Depending on your organization’s digital maturity, it may already be here — generating code, drafting documents, analyzing changes, proposing actions inside your processes — or it is arriving faster than your document management was built to handle. And the moment a machine is doing work inside your quality system, your documentation acquires a job it was never designed for. A PDF can govern a person who opens it and reads it. It cannot govern a machine.
This is not a problem you can solve on the day it arrives. Codifying a quality system is a long-lead undertaking, not a switch you flip once an auditor asks how your AI tooling is controlled. The industry is moving in one direction, and the organizations that start before it’s required will have a governable quality system when they need one. The ones that wait will be retrofitting governance onto tools that are already running. The time to prepare is while it’s still optional.
The quiet assumption in every quality system
Every SOP, specification, and work instruction you have was written for a human reader. It assumes someone opens the document, interprets it, applies judgment, and acts. The prose can be a little ambiguous because a person will resolve the ambiguity with context. The review can be annual because a person only needs the current version when they happen to do the task. The whole apparatus — the DMS, the periodic review, the read-and-understood attestation — is built around occasional human reading.
That worked because it matched reality. Humans were the only ones reading, humans were the only ones acting, and humans move slowly enough that annual review kept pace.
Name the assumption plainly, because everything that follows turns on it: your documentation was designed to be read occasionally by people, not executed continuously by machines. When the reader changes, the model has to change with it.
What documentation-as-code actually is
There is already a discipline for documentation that machines can work from, and it did not come from pharma. It came from software engineering, where it is standard practice, and it is called documentation-as-code.
The idea is simple. Documentation is authored, versioned, reviewed, and stored the same way code is. There is one source of truth, not a document here and a copy there. Every change is a commit: attributable to a person, timestamped, reviewed before it merges, and diffable against every prior version. The complete history of the document — who changed what, when, and why — is captured automatically, because the system that stores it captures it as a property of how it works. You do not maintain a separate revision history. The revision history is the storage.
This is worth pausing on, because it is the same mechanism that makes modern infrastructure auditable, applied now to your procedures. Software teams already run their documentation this way — not because a regulation told them to, but because it is simply the better way to keep documentation accurate, current, and trustworthy when things change quickly. Which means the practice your quality organization is about to need is not speculative or unproven. It is mature, it is everywhere in software, and it has been working for years.
Two forces breaking the old model
The document-management-as-PDF model is being broken by two forces at once.
The first is continuous change — the same force that makes a point-in-time IQ obsolete the moment it’s signed. A procedure reviewed once a year cannot faithfully describe a system that changes every week. The annual review was always a compromise with the speed of human process; against continuous systems it fails outright, because the document and the reality drift apart in the eleven months nobody is looking.
The second force is new, and it is the one this piece is about. AI. When an AI tool generates, modifies, or acts inside your operation, your documentation stops being something that gets read and starts being something that has to govern a machine. And that is a fundamentally different requirement — one the PDF-in-a-DMS was never built to meet.
An AI is only as governed as the procedures it can be bound by
Here is the heart of it, and it needs a distinction made carefully, because it’s the one place this argument is easy to get wrong.
A modern AI can read a PDF. It can parse the text, extract the words, and summarize what a procedure says. So the problem was never that the machine can’t open the document. The problem is that reading a document and being governed by it are two entirely different things, and a PDF in a document management system delivers the first without the second.
Governance is not parsing. Governing a machine with a procedure means the machine operates from a source that is authoritative, current, versioned, structured, and bound to the record of what it did. A PDF fails every one of those tests — not because it can’t be read, but because of what it is.
Consider what a PDF actually gives an AI, and what it withholds.
It has no guaranteed authority. An AI pointed at a document store has no reliable way to know which document is the controlling one, whether the copy it ingested is the effective version, or whether a newer revision superseded it an hour ago. It parses whatever it was handed. A codified quality system has one authoritative source by construction; there is no “which copy is current” question because there is only the current version and its complete history.
It has no enforced version binding. When an AI acts on a procedure from a PDF, nothing ties that action to the specific version that governed it. You cannot later prove which revision was in force at the moment the machine acted, because the document and the action live in different systems with no link between them. In a codified system, the version is part of the record: the action and the exact procedure that governed it are bound together automatically.
It has no structure the machine can act on reliably. Prose written for human judgment is full of the ambiguity a person resolves with context — “as appropriate,” “where required,” “in a timely manner.” A human reads intent. A machine needs the acceptance criteria, the parameters, and the conditions expressed as structured, unambiguous fields it can execute against consistently. A codified procedure carries that structure; a PDF carries prose that reads differently depending on how it’s parsed.
And it has no diffability, no review gate, no change control the machine inherits. A PDF can be replaced with a new PDF and the AI consuming it has no idea anything changed, or what changed, or whether the change was reviewed and approved. A codified procedure changes only through a reviewed, attributable, diffable commit, so the governance of the document itself is intact and visible to everything downstream of it.
So the reframe is this. You do not govern an AI by writing a policy that says the AI must follow your SOPs — that sentence is meaningless to a machine — and you do not govern it merely by letting it read your PDFs, because reading is not being bound. You govern an AI by grounding it in a quality system that is authoritative, versioned, structured, and change-controlled: a source it operates within rather than a document it merely consumes.
An AI grounded in a codified quality system operates inside approved procedure, from the same authoritative source, under the same change control, as the rest of your organization. That is governance. An AI working from a pile of PDFs is parsing text with no guarantee that the text is current, controlling, or unchanged, and producing actions that can’t be tied back to a governing version. That isn’t governance. It’s an AI reading documents and hoping — and in a regulated environment, hoping is not a control.
The traceability you gain
Now the part a quality professional will actually enjoy, because it is a genuine upgrade, not a compromise.
When your quality system is code, every action an AI takes can be captured against the exact version of the procedure that governed it. You can show, for any action, at any point in time: what the AI was instructed to do, which version of which SOP was in force at that moment, and what it actually did. The governing procedure and the action are bound together in the record, automatically, because both live in a versioned system that captures them as they happen.
Compare that to what you have today. With a human following a PDF, the strongest claim you can make is that the person had access to the current version and attested they read it. You cannot prove they applied that version rather than a remembered older one, and you reconstruct what actually happened from memory, logs, and change tickets after the fact. The codified model is strictly better: it does not assert that the current procedure was followed, it demonstrates it, contemporaneously, for every action, human or machine.
And it’s worth being direct about the regulatory posture here, because the instinct will be to ask whether a code repository can possibly satisfy controlled-document requirements. It can, and it satisfies them more completely than many of the systems in use today. The properties that 21 CFR Part 11 and the controlled-document expectations behind it actually require — attributable authorship, enforced approval before a change takes effect, effective-dated versions, access control, a complete and tamper-evident history — are native properties of a version-controlled repository, enforced by construction rather than by procedure layered on top. Every change is attributable and timestamped. Nothing merges without the approval the repository requires. Every prior version is retained and diffable. The audit trail isn’t a feature someone configured and hopefully maintained; it is the storage model itself. Measured against the intent of the controlled-document rules — current, approved, attributable, access-controlled, auditable — a codified quality system meets that intent more natively than a document management system bolting those controls onto files. The question was never whether a repository is compliant. It’s why we accepted less auditable systems for so long.
This is the same pattern that runs through every part of the modern approach. The thing you adopt to make AI governable turns out to give you better evidence than the manual model it replaces. Governance and auditability stop being a burden you carry and become a property of how the system is built.
Both ends of the chain need this
This is where the software developer and the pharma customer — who look like different audiences — turn out to have the same problem.
The developer building AI tooling already needs documentation-as-code, to ground their agents in approved procedure and to keep every AI action auditable. Most software teams building with AI understand this, or are learning it fast, because an ungoverned agent is a liability they feel directly.
The pharma customer is about to need it for exactly the same reason, and many haven’t seen it coming. The moment AI tooling enters a regulated operation, the customer’s own documentation has to be able to govern that tooling, and a document management system full of PDFs cannot. The vendor codifies its quality system to govern the AI in its development process. The customer will need to codify theirs to govern the AI in their operations. Same necessity, both ends of the source-to-site chain: if a machine is doing regulated work, the rules it works under have to be machine-readable.
The organizations furthest along in digital maturity are already feeling this. The ones earlier in the journey have a short window to get ahead of it. But the direction is the same for everyone, because the reader changed for everyone.
This does not remove the human
One thing has to be said clearly, because the phrase “quality system as code” invites the wrong fear.
Documentation-as-code does not mean machines write your procedures. Humans still author the SOPs. Humans still review and approve them. Humans still own them, and own the judgment about what they should say. None of that moves. The code form changes only how the approved procedure is stored and delivered — versioned instead of filed, machine-readable instead of prose-only, enforced by construction instead of by attestation.
This is not automating away governance. It is making governance executable. The rules are still human rules, authored and approved by people; documentation-as-code is simply what lets those human rules reach, and bind, the machines that are now doing the work. The human still writes the law. You are just making it something the machine can actually be held to.
The PDF was fine when people were the only readers
The document management model was not a mistake. It was a correct design for a world where humans were the only ones reading procedures and humans were the only ones doing the work. That world is ending — unevenly, faster in some organizations than others, but ending everywhere.
When machines operate inside your regulated processes, your quality system has to become something a machine can read, follow, and be audited against. Prose in a document management system is not that, and no amount of careful authoring makes a PDF into something an AI can be governed by. The format itself is the limitation.
Your SOPs were written for people to read. The machines can’t read them the way governance requires — and depending on where your organization sits, the machines are already here, or they’re closer than your document management is ready for.
You can’t govern a machine with a document it can’t be bound by.