In April 2026, the FDA issued a warning letter to Purolea Cosmetics Lab after inspecting its pharmaceutical manufacturing operation. The letter lists several serious violations. One of them should interest anyone building enterprise AI.

Purolea had used AI agents to help create drug product specifications, procedures, and master production or control records. Investigators found that the company had not performed required manufacturing process validation before distributing its drugs. According to the letter, the company said it did not know validation was required because its AI agent had “never told you it was required.”

The public record doesn’t say which model or agent architecture was involved, or what exactly caused the omission, and much of the letter has nothing to do with AI. Everything below about architecture and testing is my own engineering view, not a reconstruction of Purolea’s system.

But the question it raises is hard to ignore: how do you verify an AI-generated result when the most consequential error is something the system never mentions?

An answer can be correct and still dangerously incomplete

Most AI quality checks ask whether an output is accurate. Are its claims supported? Are the citations real? Does it follow instructions? Those checks are necessary, but they say nothing about whether the answer covers everything it had to.

Imagine an AI drafting a procedure for a regulated production process. Every step it includes is accurate and every reference is real. A second agent checks each sentence against the source material and finds no errors. The procedure still leaves out one mandatory validation activity.

Nothing in the text is false. The failure is an omission, not a hallucination, and a reviewer can confirm every claim on the page without ever noticing what isn’t there.

It’s the same thing as a software product that passes 100% of its tests while violating a business requirement nobody turned into a test case. The test results are valid; the coverage of the specification isn’t.

Correctness is about the statements you made. Completeness needs an independent definition of what you should have covered. And there is a third question behind both: adequacy, whether the controls and evidence you do have actually satisfy the requirement. These are three different assurance problems, and high-stakes AI systems need an answer for each.

Why a stronger LLM, RAG, or a second agent is not enough

A more capable model makes fewer mistakes. Retrieval-Augmented Generation (RAG) grounds answers in controlled sources. Multiple agents can critique each other. All three are worth using where they measurably help. None of them guarantees completeness.

A RAG pipeline might retrieve eleven of twelve applicable obligations, and the model might describe those eleven perfectly. Every citation check passes, and the twelfth obligation stays invisible, because good retrieval and full coverage of applicable requirements are different things.

A second agent can make it worse by adding false confidence. If it works from the same incomplete sources and the same framing of the task, it will likely approve the first agent’s work. A different model is not an independent source of truth.

Loading the whole regulatory library into a large context window doesn’t solve applicability either. The system still has to know which rules apply to this product, this process, this jurisdiction, and this intended use.

So the architecture has to keep two jobs apart:

  1. Generating and analyzing content with probabilistic models.
  2. Establishing and verifying obligations with controlled knowledge, explicit system state, acceptance criteria defined independently, and qualified human judgment.

The two can work together. They shouldn’t quietly merge into one prompt that asks, “Does this look compliant?”

Architecture: treat requirements as system state, not model output

The design I favor has a controlled knowledge layer, a way to decide applicability, an explicit graph linking requirements to evidence, AI assistants, and independent workflow gates.

Reference architecture for AI-assisted, controlled enterprise workflows

Figure 1. AI proposes and analyzes. Controlled obligations, evidence, verification gates, and authorized people decide what moves forward.

1. Build a versioned requirement registry

A vector database full of PDFs is not an authoritative definition of what the system must comply with.

A useful requirement record has a stable identifier, its source and version, applicability conditions, a responsible owner, related controls, verification criteria, and a review history.

AI can help extract and classify candidate requirements, but a qualified expert should review each one before it becomes authoritative, and regulatory updates need their own change control. The registry can be wrong too. Moving a requirement from a prompt into a database doesn’t make it correct, so it still needs source reconciliation and independent audits.

2. Make applicability explicit, including uncertainty

A rule doesn’t apply just because a model retrieved it, and it isn’t irrelevant just because a model didn’t mention it.

Applicability depends on structured context: the activity, the product’s characteristics, the jurisdiction, the process classification. Where the rules are clear, evaluate them deterministically. Where they’re ambiguous, AI can recommend a classification and a qualified reviewer decides.

The state shouldn’t be a simple yes or no. I distinguish three values: applicable, not applicable with documented justification, and unresolved. For critical obligations, unresolved must never be treated as not applicable, and nobody should be able to waive a binding requirement with an unqualified “override.”

3. Model dependencies between obligations, controls, and evidence

A quality system is a set of dependencies. An obligation is implemented by controls, a control is defined in a procedure, the procedure drives execution, execution produces records, and records need verification and approval. One control can serve several obligations, and one change can ripple through procedures, training, validation records, and approvals.

With that graph made explicit, the platform can answer concrete questions:

  • Which applicable requirements have no approved control?
  • Which controls are missing evidence or approvals?
  • What is affected when a requirement changes?
  • Which open child records should keep a workflow from closing?

I don’t want an LLM answering these from memory. They should be queries against controlled, versioned state, with semantic analysis added where it helps.

The graph has a limit worth stating plainly. It can show that a required link exists. It can’t show that the linked evidence actually satisfies the obligation. Requirement R-42 can be linked to Procedure P-17, the procedure can carry the right status and signatures, and the attached evidence can still fail to demonstrate the required control. Every structural check passes. Structural completeness and semantic adequacy are separate problems, and adequacy still needs expert review, often helped by AI analysis of the evidence itself.

4. Use AI to propose, not to certify

AI is good at drafting procedures, analyzing regulatory text, suggesting relationships, preparing impact assessments, and helping reviewers make sense of complex evidence.

But an AI saying “Procedure P-17 satisfies Requirement R-42” is not proof that it does. The system should track whether that link is proposed, reviewed, backed by evidence, or approved. This matters most when the output looks polished, because professional wording is easy to mistake for verified status.

5. Put testable conditions at release boundaries

A workflow gate can check that known applicable obligations have controls, that required evidence and approvals exist, and that no critical applicability decisions are still open. Conceptually:

release_allowed = known_obligations_covered AND required_evidence_accepted AND no_unresolved_critical_gaps AND authorized_approval_complete

Some of these checks are deterministic; others need expert judgment about whether the evidence is actually sufficient. The point is that a missing mandatory record can’t disappear just because the model left the topic out of its narrative.

A gate can’t prove the registry itself is complete, of course. It protects you inside a defined, maintained scope, and it’s one layer of assurance among several.

A failure-injection test case

Consider a hypothetical test scenario for an AI-assisted quality workflow: a process with six reviewed, applicable obligations in a test fixture. One of them is R-VAL-04: complete and approve process-validation evidence before the release decision.

Path A: generation plus LLM review. The drafting agent writes a procedure covering five obligations and skips R-VAL-04. A reviewing agent checks whether the document’s statements are accurate and supported by the retrieved sources. It verifies all five and reports no errors. The sixth obligation is never evaluated.

Path B: generation plus an obligation graph and a release gate. The same document is linked to the registry of six obligations. The verification layer checks all six, not only the ones the document mentions. It finds no accepted evidence for R-VAL-04 and blocks the release until an authorized process resolves the gap.

Evaluation LLM review of the document Independent obligation check
Are included statements factually supported? Can assess this Can use AI or other checks
Was R-VAL-04 addressed? May never ask Explicitly evaluates it
Missing validation evidence Can be overlooked Detected, if the obligation and evidence rules are modeled correctly
Controlled release May look acceptable Blocked while the condition is unmet

The takeaway isn’t that deterministic logic beats AI. The two approaches answer different questions. LLMs are good at interpreting meaning, proposing evidence links, and spotting semantic inconsistencies. Structured checks enforce known obligations. Experts still judge applicability and whether evidence is adequate.

The most useful follow-up is to delete R-VAL-04 from the registry itself. Now the gate can’t catch it either, which points to the next control you need: an independent assessment of how complete your regulatory knowledge is. A reliable system has to test both the documents it produces and the rules it uses to judge them.

How to measure reliability

Answer accuracy, latency, token cost, and user satisfaction are useful operational metrics, but they miss this failure mode entirely. A risk-based evaluation suite should also include:

  • Applicability false-negative rate. In expert-reviewed scenarios, how often does the system miss an obligation that applies? Report critical misses separately instead of averaging them away.
  • Mutation-detection rate. After you deliberately remove a required approval, evidence record, or dependency, how often does the right gate catch it?
  • Evidence-graph integrity. What share of applicable obligations have reviewed control links and the evidence required at their current lifecycle stage?
  • Change-impact recall. When a requirement or process changes, how many of the affected artifacts does the system find?
  • False-block rate and reviewer burden. How often does the system stop legitimate work or flood specialists with needless reviews?
  • Regression stability. What changes when you update the model, prompts, retrieval, tools, or regulatory corpus?

This needs independently built reference scenarios, deliberate negative cases, versioned evaluations, and a clear owner for the acceptance criteria. For high-risk areas I’d add contradictions, obsolete requirements, ambiguous jurisdiction, missing source material, and cases where the right answer is “applicability unresolved.” Even a perfect score only shows that specific controls work for a defined use case.

Human-in-the-loop is not an approval button

The Purolea letter is explicit that the Quality Unit is responsible for reviewing and clearing AI outputs used in manufacturing activities.

Now picture a reviewer facing fifty AI-generated documents, each with a green “Ready to approve” badge. What does that reviewer actually know about whether every necessary requirement was considered?

Real oversight needs visibility into source versions, applicability decisions, open dependencies, supporting records, AI-proposed changes, and the reasons behind exceptions. The reviewer has to be able to challenge the system, not just sign off on its prose, and the workflow should make missing evidence obvious instead of letting uncertainty pass for completion. A human in the loop is a control only if that person has the authority, the context, and the evidence to decide.

The engineering leadership decision

The bigger question isn’t which model to buy. It’s how an organization splits responsibility between probabilistic reasoning, deterministic controls, domain expertise, and accountable people. That split shapes the architecture, team ownership, testing budgets, acceptance criteria, and release process.

Before approving a critical AI workflow, I ask three questions:

What is the system allowed to infer? Drafting a recommendation is different from asserting that a regulated obligation is met.

What must it prove, or explicitly leave unresolved? Important decisions need traceable evidence and defined acceptance conditions, not just a convincing explanation.

Who owns the blind spots? Someone has to maintain the requirements, test negative cases, review failures, and decide how model or regulatory changes affect what has already been approved.

In practice, that means separate ownership for regulatory knowledge, AI model performance, workflow controls, and independent verification. These can sit in different teams, but the interfaces between them and the acceptance criteria at each handoff have to be written down. When they aren’t, a requirement can fall between two teams and nobody’s tests will catch it.

A team can proudly report that its AI produces a hundred procedures an hour, and that may be real productivity. For business-critical work, I’d rather measure how much verified, useful work the system safely speeds up.

The actual lesson

The Purolea case doesn’t prove that general-purpose AI can’t support regulated work. It shows how risky it is to treat an AI agent as the implicit authority on what’s required.

Models will keep getting better and will make fewer omissions. Still, a capable model is not the same as a system that can show its coverage, keep track of dependencies, flag what’s unresolved, and support accountable decisions. I wouldn’t rely on a general-purpose model alone to guarantee a complex quality system is complete, and I wouldn’t make that promise for a specialized platform without a defined scope and evidence either.

The same failure shows up well beyond regulated manufacturing. A financial AI agent can overlook a mandatory risk control. A security automation agent can skip a required remediation step. A coding agent can implement every documented feature and quietly miss an important non-functional requirement. In each case the system needs an independently defined expectation to measure completeness against.

Building a system that notices when the work is incomplete, before the gap reaches production or a patient, is an engineering job. Making sure someone owns that job is a leadership one.

Sources and scope

The CGMP provisions FDA cited concern pharmaceutical manufacturing. The architecture, experiment, and conclusions above are my own engineering proposals, not claims about Purolea’s implementation or an FDA-mandated design.