A quality director at a mid-size biopharma wants to deploy an AI agent to help investigators write deviation summaries. The pilot works beautifully — the model produces first drafts in minutes instead of days. Then the validation team asks three questions:
- How do you validate a system that produces different outputs for the same input?
- How do you audit a decision you cannot trace?
- How do you explain to an FDA inspector that a hallucinated root cause made it into a CAPA record?
The pilot stalls. Not because the technology failed, but because nobody designed the harness around it.
This is the defining problem of AI in life sciences quality. The regulatory framework — FDA 21 CFR Part 11, EU Annex 11, GAMP 5, ICH Q9/Q10, ALCOA+ — was built for deterministic software. It assumes that given the same inputs, a system produces the same outputs, that every decision is traceable, and that human accountability is never ambiguous. LLMs violate all three assumptions.
But banning AI from quality systems is not an answer. The deviation backlog grows. The CAPA cycle time stretches. Auditors expect faster, more consistent responses. Competitors are already gaining the advantage.
The answer is not “an AI agent.” The answer is an AI Harness.
The core paradox
Life sciences quality demands properties that LLMs do not natively provide:
| Quality System Requirement | LLM Reality |
|---|---|
| Deterministic behavior (same input → same output) | Probabilistic generation; temperature > 0 produces variance |
| Full auditability of every decision | Black-box reasoning; cannot inspect the “thought process” |
| Validated software (GAMP 5 / CSA) | Continuously retraining models with shifting behavior |
| Data integrity (ALCOA+) | No inherent understanding of data provenance |
| Human accountability for quality decisions | Can generate authoritative-sounding but fabricated claims |
The resolution is not to make LLMs deterministic. It is to shift the validation boundary. You validate the harness — the orchestration, routing, guardrails, and approval gates — as deterministic code. The LLM operates probabilistically inside bounded, checkable steps. This is what makes the system defensible under CSA (Computer Software Assurance): you validate the harness once, and the LLM’s variability is contained to scoped tasks with verifiable outputs.
The architectural pattern:
AI Agent → AI Harness → Enterprise Systems
Not:
AI Agent → Quality System
This is the same insight behind the general agent harness concept — the model is the engine, the harness is everything else. But in life sciences, the “everything else” includes regulatory validation, e-signatures, immutable audit trails, and patient safety gates. The harness is not optional infrastructure. It is the product.
The 12-layer architecture
The harness is organized as a layered platform. Every layer has a distinct governance or operational function. Here is the full stack:
Users
│
┌────────────────┼─────────────────┐
│ │ │
Web UI Microsoft Teams API
│ │ │
└────────────────┴─────────────────┘
│
Identity / SSO
│
──────────────────────────────────────────────────
AI HARNESS PLATFORM
──────────────────────────────────────────────────
1. Session Management
2. Prompt Orchestration
3. Agent Runtime
4. Memory (multi-scope)
5. Model Router
6. Safety Guardrails
7. Human Approval Gates
8. Evaluation Harness
9. Audit Logging (immutable)
10. Version Control (prompts, models, knowledge)
11. Cost Management
12. Validation Layer (CSV/CSA)
──────────────────────────────────────────────────
KNOWLEDGE FABRIC
──────────────────────────────────────────────────
Hybrid: Semantic + Keyword + Graph + Metadata
Filtered by: version, status, site, product
──────────────────────────────────────────────────
DOCUMENT LAYER
──────────────────────────────────────────────────
SOP | Deviation | CAPA | Change Control
Validation | Batch Record | Risk Assessment
Training | Policies | FDA Guidance | ICH
──────────────────────────────────────────────────
ENTERPRISE SYSTEMS
──────────────────────────────────────────────────
Veeva | TrackWise | MasterControl | LIMS
MES | ERP | LabVantage | DMS
Each layer is independently validatable, independently replaceable, and independently auditable. Let me walk through the ones that matter most.
Layer 1-2: Identity and prompt orchestration
Everything begins with identity. If a QA Specialist cannot access a CAPA manually, the AI cannot access it either. No exceptions. The harness integrates with Azure AD, Okta, or corporate SSO. Role-based access, document-level permissions, and electronic signatures are non-negotiable.
Users never prompt the LLM directly. The harness intercepts every request:
User: "Summarize this deviation."
Harness expands to:
- Reference SOP 103 (effective version)
- Reference Deviation Procedure 201
- Apply site terminology and approved glossary
- Answer in company template format
- Do not speculate
- If confidence < 95%, state uncertainty explicitly
The user never sees this expansion. It is the harness’s job to ensure the model receives only approved context, structured instructions, and safety constraints.
Layer 3: Specialized agent runtime
One general-purpose “quality assistant” agent is an untestable monster. The harness deploys narrow, single-purpose agents instead:
| Agent | Single Responsibility |
|---|---|
| Investigation Agent | Deviation root cause analysis |
| CAPA Agent | Corrective/preventive action drafting |
| SOP Agent | Gap analysis and regulatory cross-reference |
| Validation Agent | IQ/OQ/PQ document generation |
| Audit Agent | Inspection readiness assessment |
| Supplier Agent | Supplier risk scoring |
| Regulatory Agent | Guidance interpretation and mapping |
Each agent has its own prompts, its own tools, its own permission scope, its own memory, and its own evaluation criteria. This is what makes validation tractable — you validate one narrow agent at a time, not a monolithic system.
Layer 5: Model router
The user never chooses the model. The harness does.
| Task | Model Routing |
|---|---|
| Simple SOP lookup | Small local model |
| Deviation investigation | Claude (reasoning) |
| Large report generation | GPT-4 class |
| Structured classification | Fine-tuned model |
| Image analysis (visual inspection) | Vision model |
As foundation models evolve, the harness remains stable. Swapping a model is an implementation change, not an architecture change. This is how you adopt new capabilities without re-validating the entire system.
Layer 6-7: Guardrails and human approval
The guardrail layer runs independent verification on every model output:
- Citation check: Does every claim trace to a retrieved document?
- Schema validation: Is the output structurally correct (JSON Schema / Pydantic)?
- Hallucination detection: Are there ungrounded claims?
- Confidence scoring: Does the model’s self-assessed confidence meet the threshold?
Then the human gate:
AI generates draft
↓
Reviewer sees: draft + full citation trail + confidence score
↓
Reviewer action: approve / edit / reject
↓
Electronic signature (21 CFR Part 11)
↓
Record enters QMS
The reviewer’s action is the ALCOA+-attributable event. Timestamped, identity-bound, immutable. Nothing enters the quality system without a human signature. This is the hardest architectural constraint and the one that makes the whole thing defensible.
Layer 8: Evaluation harness
Every response is evaluated against multiple dimensions:
| Metric | What It Measures |
|---|---|
| Faithfulness | Claims supported only by retrieved documents |
| Citation Accuracy | Every claim maps to verified GxP records |
| Completeness | All required fields/sections addressed |
| Hallucination Rate | Un-grounded text (< 0.1% tolerance for GxP) |
| Compliance | Adherence to templates and SOPs |
| Confidence | Model’s self-assessed certainty |
Failures become training data. Not for fine-tuning the model — for improving the harness. Better prompts, better retrieval, tighter guardrails.
Layer 9: Immutable audit trail
Every action logs:
- Prompt version used
- Model version used
- Documents retrieved (with version numbers)
- Raw model output
- Guardrail scores
- Reviewer decision
- Timestamp and user identity
This is a GxP record itself. Append-only, tamper-evident, time-stamped. When an FDA inspector asks “why did the system recommend this root cause?”, you can reconstruct the exact chain of reasoning, retrieval, and human approval — six months later.
Layer 12: Validation layer
Each execution references a specific, versioned configuration:
Execution Context:
- Prompt version: v2.3.1
- Model version: claude-sonnet-4-20250514
- Knowledge snapshot: 2026-07-15T00:00:00Z
- Retrieval config: hybrid-v3, top-k=12
- Tool versions: SOP-search-v1.4, CAPA-lookup-v2.1
This creates reproducible evidence for validation and inspection readiness. If something changes — a model update, a prompt revision, a retrieval configuration tweak — it is a controlled change with an impact assessment.
The knowledge fabric
Vector search alone is insufficient for regulated documents. The harness combines five retrieval strategies:
| Component | Purpose |
|---|---|
| Vector DB | Semantic similarity |
| BM25 | Keyword / lexical matching |
| Knowledge Graph | Relationship traversal (batch → deviation → CAPA → SOP) |
| Metadata Index | Filter by site, product, process, version, status |
| Taxonomy / Ontology | Controlled vocabularies and domain model |
The metadata layer is the critical differentiator. When an investigator asks about a deviation, the system does not just find semantically similar text. It retrieves:
- The deviation record with all structured fields
- Related SOPs (effective versions only — never archived or draft)
- Previous CAPAs on similar issues
- Equipment history for involved equipment
- Training records for involved personnel
- Relevant FDA guidance
Metadata (site, product, process, equipment, department, risk level, author, approval status, effective date, version) dramatically improves retrieval precision. A vector search for “microbial contamination” returns every document mentioning the phrase. A metadata-filtered search returns the effective SOP for the specific facility, product, and process — and nothing else.
The chunking strategy is also document-type-specific. SOP procedural steps chunk differently from deviation narratives, which chunk differently from CAPA structured fields. One-size-fits-all chunking is one of the most common failure modes in life sciences RAG.
Risk classification: the GAMP 5 adaptation
Not all AI use cases carry the same risk. The harness classifies every model:
| Class | Description | Validation | Example |
|---|---|---|---|
| AI-1 | No direct quality impact | IQ/OQ only | SOP knowledge search |
| AI-2 | Informs decisions, human decides | Risk-based validation + monitoring | Deviation similarity search |
| AI-3 | Recommends decisions with human review | Full validation + HITL + monitoring | Batch record review assistant |
| AI-4 | Autonomous quality-critical decisions | Full validation + PCCP + continuous re-validation | Automated release testing (future) |
This classification determines everything downstream: how much testing, how much monitoring, what kind of human oversight, what change control process. A Tier 1 SOP search engine needs lightweight fitness-for-purpose validation. A Tier 3 batch record review assistant needs the full lifecycle.
The phased roadmap
You cannot deploy this all at once. The roadmap is designed to build trust incrementally:
Phase 1: Read-only knowledge engine (Weeks 1-6)
Goal: Search, SOP Q&A, and regulatory grounding. Zero write permissions.
Deployments:
- Identity and SSO integration
- Hybrid retrieval over controlled document repository
- Basic prompt orchestration
- Central audit logging
This is low-risk, non-GxP-impact. It builds user trust and generates retrieval quality data.
Phase 2: Assisted drafting (Weeks 7-14)
Goal: Deviation summaries, CAPA first drafts, RCA scaffolding — all as drafts for human review.
Deployments:
- Investigation agent (deviation summary)
- CAPA agent (first draft generation)
- Structured output validation (JSON Schema / Pydantic)
- Evaluation harness (faithfulness, citation accuracy, hallucination detection)
This is medium-risk, human-reviewed. Every output is explicitly a draft.
Phase 3: Bounded action engine (Weeks 15-22)
Goal: Read/write access to enterprise systems through structured approval gates.
Deployments:
- Deep QMS API integrations (Veeva, TrackWise)
- Tool calling execution sandboxes
- 21 CFR Part 11 e-signature workflow
- Full immutable audit trail
This is high-risk, direct QMS writes. The e-signature gate is the critical control.
Phase 4: Continuous evaluation and validation (Weeks 23-30)
Goal: Automated regression evaluations, GAMP 5 AI validation, self-correction loops.
Deployments:
- Automated evaluation harness with golden benchmark datasets
- Regression test suite for prompt and model updates
- Predetermined change control plans (PCCPs)
- Periodic audit reporting
- Performance monitoring dashboards
Phase 5: Continuous improvement (Ongoing)
- Periodic model reviews (annual minimum)
- SOP updates aligned with regulatory evolution
- New use case pipeline management (quarterly)
- Technology stack evaluation (semi-annual)
- Regulatory intelligence tracking (continuous)
Validation under CSA
The key insight from FDA’s Computer Software Assurance guidance: validate the harness, not the model. You cannot script-test every possible LLM response, but you can validate that:
- The orchestration logic routes correctly
- Schema validation catches malformed outputs
- Guardrail thresholds behave as specified
- A bad output can never bypass the human gate
- The audit trail is complete and immutable
Additional CSA-aligned practices:
- Prompts are controlled documents. Versioned, reviewed, effective-dated, change-controlled. Every audit log entry links to the exact prompt version used.
- Risk-based tiering by use case. A CAPA drafting assistant that only produces drafts is lower risk than one that classifies deviation severity. Scale rigor accordingly.
- Periodic performance monitoring. Track guardrail flag rates, reviewer edit rates, and reviewer override rates over time. A rising override rate is the signal that the model and the SOPs have drifted apart.
- Golden benchmark dataset. Maintain a curated set of historical quality records (e.g., 200 real-world deviations with human-verified root causes and CAPAs) for automated regression testing.
The validation deliverables
Every deployed model carries a validation package:
| Phase | Deliverable |
|---|---|
| Concept | Use case definition, feasibility, ethical review |
| Risk Assessment | ICH Q9 risk assessment; AI-1 through AI-4 classification |
| Planning | Validation master plan, acceptance criteria, traceability matrix |
| Data | Data quality report, training data validation, lineage documentation |
| Validation | Protocol → execution → report; edge case testing; bias assessment |
| Deployment | Deployment qualification, integration testing, UAT |
| Monitoring | Ongoing performance reports, drift reports, periodic review |
| Change Control | Change request → impact assessment → re-validation → approval |
What to avoid
These are the failure modes that derail AI projects in regulated environments:
Building a chatbot instead of a harness. A chatbot with an SOP database is not an AI harness. It has no guardrails, no structured approval gates, no audit trail, no risk classification, no evaluation framework. It is a liability dressed as an innovation project.
Treating prompts as afterthoughts. In a harness, prompts are controlled documents. They need version control, change control, review cycles, and effective dates — the same governance you apply to SOPs. An uncontrolled prompt is an uncontrolled process.
Validating the model instead of the harness. You cannot validate every possible LLM output. The number of possible inputs is effectively infinite. Instead, validate the harness boundaries — the code that routes, constrains, verifies, and gates every model interaction. The harness is your testable, defensible boundary.
Retrofitting the audit trail. Build the logging layer before any pipeline touches real data. Retrofitting auditability is painful, expensive, and undermines your defensibility story with regulators.
Building one general-purpose agent. A single “quality assistant” agent that handles SOPs, deviations, CAPAs, change control, validation, and audits is an untestable monolith. Narrow agents with narrow validation scopes are the only defensible architecture.
Over-relying on the AI. If your quality team trusts the AI’s output without reading it, you have not improved quality — you have automated negligence. The framing matters: “AI is the intern. You are the senior investigator. The intern does the heavy lifting, but you sign the deviation.”
Use cases with measured impact
| Use Case | Impact | Risk Class |
|---|---|---|
| NLP-powered deviation triage | 75% reduction in triage time, 20% faster CAPA initiation | AI-2 |
| Automated batch record review | 70% reduction in manual review time, 30% fewer inspection findings | AI-3 |
| Predictive process quality | 15-20% reduction in batch failure rates | AI-3 |
| CAPA first-draft generation | 50% reduction in drafting time, 25% faster closure | AI-2 |
| SOP gap analysis | Near-instant regulatory cross-reference vs. days of manual work | AI-1 |
The organizational model
The harness requires a cross-functional governance structure:
┌──────────────────────────────────────────────────┐
│ AI QUALITY GOVERNANCE BOARD │
│ Head of Quality (Chair) · Head of IT │
│ · Regulatory Affairs · Data Science Lead │
│ · Legal/Compliance · Business Sponsor │
├──────────────────────────────────────────────────┤
│ │
│ ┌───────────────┐ ┌─────────────────────────┐ │
│ │ AI Center │ │ Quality Assurance │ │
│ │ of Excellence│ │ (AI Validation & │ │
│ │ │ │ Oversight) │ │
│ │ - Data Sci │ │ - Validation leads │ │
│ │ - ML Eng │ │ - QA reviewers │ │
│ │ - MLOps │ │ - Risk managers │ │
│ └───────────────┘ └─────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐│
│ │ Business Domain Teams ││
│ │ (Manufacturing · Lab · PV · Regulatory) ││
│ │ - Process owners · End users · SMEs ││
│ └──────────────────────────────────────────────┘│
└──────────────────────────────────────────────────┘
The bottom line
The AI Harness is not a product. It is an architectural commitment.
It means every new AI capability plugs into the harness instead of talking directly to enterprise systems. Every model is a versioned, validated, change-controlled artifact. Every prompt is a controlled document. Every output is a draft until human-approved. Every interaction is logged immutably. Every use case is risk-assessed and tiered.
As foundation models evolve — and they will, faster than any validation cycle can keep up — the harness remains stable. The models become implementation details. The orchestration, guardrails, approval gates, and audit trail continue to provide the reliability that regulators expect.
The organizations that build this harness will be able to adopt new AI capabilities continuously, safely, and defensibly. The ones that skip it will either avoid AI entirely (and fall behind) or deploy ungoverned AI (and fail inspections).
The harness is the moat. In life sciences quality, it is also the license to operate.
Deep-dive research note: [[AI-Harness-Life-Science-Quality-Comprehensive-Report-2026]] Related: [[Agent-Harness-Deep-Dive-Multi-LLM-Consensus-2026]] | [[AI-Agents-Life-Sciences-Quality-CSV-Comprehensive-Report]] | [[FDA-EMA-Guiding-Principles-Good-AI-Practice-2026]]
Saram Consulting