AI for Quality Control Documentation in Pharma
A batch is finished long before it is released. The last operation ends, the record closes, and then the lot sits. Not because anyone doubts the product, and usually not because anything went wrong. It sits because several hundred pages have to be read, queried, answered, read again, and finally signed by a person whose name carries the release.
That gap is the most expensive documentation problem on a pharmaceutical site. It is counted in days per lot, it repeats across every product, and almost all of it is reading and writing rather than deciding. Agents are useful here for an unglamorous reason: they can start the reading the moment the record closes, and they can draft the documents that keep the lot in the queue.
What is actually sitting in the release queue
Ask how long release takes and you get a number. Ask what the number is made of and the answer is less comfortable. The queue holds records waiting for a first review because the reviewer has three ahead of them, records returned to production carrying comments, records held against an open deviation nobody has written up properly, records held against a pending out of specification result, and records complete but for one certificate or one signature from a supervisor on nights.
None of those is a quality judgement. Every one is a documentation state, a state that exists because a document has not been produced, read or answered yet.
Batch record review and the query round trip
The review itself gets the attention, but the round trip costs more. A reviewer works through an executed record and raises a set of comments. The record goes back to production. A supervisor answers over the following days, often by asking operators what they meant by an entry made a fortnight ago. It returns, and the reviewer reads it again, because an answer in one place can invalidate a check somewhere else.
An agent working the record as it closes changes the timing of that loop rather than removing it. The comment set exists within minutes of the last entry, so production answers while the people who executed the steps are still on shift and still remember the run. Memory is a real input to record quality and it decays fast.
It also shrinks the list. A large share of review comments are not questions, they are discrepancies resolvable from data the site already holds: a recorded value that disagrees with the equipment log, a calculation that does not reproduce, a time stamp out of sequence, a referenced deviation with no matching event in the quality system, a material lot that does not match what was dispensed. An agent presents both sides of each discrepancy with its source, so the reviewer is deciding rather than investigating. What remains for production are the human gaps: a missing initial, an unclear annotation, a correction with no reason recorded.
There is a quieter benefit in consistency. Two reviewers reading the same record raise different comments, and experienced operators know which reviewer is coming. An agent applies the same check set every time.
Evidencing the review itself
The output is not only the exceptions. It is also the record of which checks ran, against which document versions, and with which result. A reviewer signing off work they did not personally perform line by line needs that record to exist, so build it as a primary output, not as logging.
Deviation write ups and the cost of bad prose
A deviation record is technical writing with rules. It has to describe what happened without asserting why, state the affected scope without pre-empting the impact assessment, and remain intelligible in three years to someone who was not in the room. Most are written days later by a supervisor between other duties, which is why so many share the same faults: a cause smuggled into the description, a no impact statement with nothing behind it, a scope written from memory, and a first paragraph QA has to rewrite before the record can proceed.
An agent can take the operator's plain account at the point of occurrence, ask the clarifying questions the procedure requires, and draft the record in the site's structure with batch, equipment, material and process context filled from the systems that hold it. The useful discipline is structural: the description field takes observations only, inferences go to the assessment section, and the agent declines to move one into the other. It proposes a classification and shows the prior events classified the same way, because classification drift is what turns a minor into a major two years later when a pattern is finally noticed. Scope gets the same treatment: which other batches or campaigns were exposed to the condition is a query, not a recollection, and it belongs in the record as a query result with its criteria visible.
One more thing is worth automating. Open deviations block releases, and the ageing report says a record is thirty four days old without saying what it is waiting for. An agent that reads the record can name the blocker: an outstanding laboratory result, an impact assessment sitting with a named person, a CAPA not yet drafted.
Out of specification investigations
This is where documentation quality decides whether an investigation holds up. A result outside specification starts a clock and a sequence, and the sequence has to be visible in the record: the laboratory phase documented before any retest, the retest plan authorised in writing before it is executed, any laboratory cause demonstrated rather than asserted. An investigation closed as analyst error with no evidence of that error is a familiar finding, and it is a documentation failure more often than a science failure.
Most of the laboratory phase is objective and already recorded somewhere. When a result outside limits is entered, an agent can open the investigation and populate the checklist from the systems of record: sample preparation entries, standards and their expiry, system suitability for that sequence, the column and instrument, the raw data with the calculation independently reproduced, other results from the same analyst, instrument and session, and the method's history of similar events. The analyst and supervisor get a record where the answerable questions are answered with sources and the rest are marked as requiring a person.
Two design choices matter more than extraction accuracy. The agent must write the hypothesis and the retest justification before the retest happens, so the record reflects the real order of events. And when no assignable cause is demonstrated it must say exactly that, then route the investigation into manufacturing rather than reaching for the most common historical outcome.
CAPA records that survive their own effectiveness check
The weakest sentence in most CAPA records is the action. Retraining is the default because it is always available and always defensible, and it rarely addresses a cause described as procedural or design related three paragraphs earlier. The second weakest is the effectiveness criterion, written loosely enough that it cannot fail.
An agent drafting the record can hold both to account. It flags where the proposed action would not have prevented the event as described, and surfaces how many prior actions on the same procedure or line were retraining and whether recurrence followed. It asks for the criterion in measurable terms, then holds that definition and drafts the verification from recurrence data when it falls due, long after attention has moved elsewhere.
Change control and the version the batch actually ran under
Changes block releases in a specific and avoidable way. A master batch record is revised, the change is approved, and a batch runs somewhere in the overlap on a version superseded two days earlier. Nobody notices until review, and then a completed lot needs an assessment nobody planned for. An agent reconciling each executed record against the master version effective on the manufacturing date catches that at closure instead, and ahead of implementation it can hold the packet open until the artefacts exist: the revised record at its effective version, the completed training, the executed requalification with attachments.
Where AI fails here
Start with what does not move. Reviewers do not read faster, the qualified person's judgement takes the time it takes, analytical testing has a lead time no agent shortens, and a real investigation should not be compressed at all. The queue drains because work starts earlier and arrives complete, not because anyone is hurried.
An agent must never determine disposition and must never invalidate a result. Invalidation is the highest stakes act in this article, and a fluent, well organised narrative is precisely what makes a weak invalidation look strong. Treat every proposed cause as a hypothesis with its evidence attached.
The pattern matching that makes agents useful on out of specification work also biases them towards the common historical outcome. If most of your closed investigations name laboratory error, an agent working from that history will lean the same way, which is the exact bias an inspector goes looking for. Impact statements carry the same warning. An agent can list every batch exposed to a condition, but the sentence saying product quality was unaffected belongs to a person who can defend it.
Extraction from handwritten and scanned entries carries a real error rate, and the dangerous failure is not the unreadable value, it is the misread one that falls inside limits and therefore never gets flagged. Configure for escalation over guessing.
A subtler risk is master data. If the limits and check definitions the agent applies are typed into a configuration rather than read from the approved master record, you have created a second source of truth that will drift from the first.
The validation burden is ongoing rather than a project, and the agent's prompts, retrieval configuration and model versions become controlled items with change control of their own. On a low volume product that cost will exceed the benefit. And once an agent's comment set is usually right, it stops being a prompt for review and quietly becomes the review, which is worth watching from the first week.
Where to start
Start in shadow on batches already released. Ground truth exists, nothing is at risk, and the comparison gives you two numbers that matter: what the agent found that the reviewer did not, and what the reviewer found that the agent did not.
From there the two contained deployments are laboratory phase assembly on out of specification results, where most inputs are structured and machine readable, and the discrepancy layer of batch record review, where the agent proposes comments and a reviewer disposes of them. Neither touches a release decision. Measure what your operations review already tracks, days from batch closure to release, and separate the days spent working from the days spent waiting.
If your release cycle is gated on paperwork rather than product, describe your review and investigation flow to Adopt AI Partners at hello@adoptaipartners.com and we will give you an honest read on which parts an agent could carry inside your quality system.