Governance, security and validation

Architecture

The system has three parts: a retrieval layer that indexes and queries your data, an agent runtime that plans a workflow and calls tools, and a model endpoint that does the language work. Ideally, the first two always run inside your environment. The third is the only component where a deployment decision has to be made.

Where each component runs

Three deployment patterns

• Fully in-tenant. The model endpoint is one you already own: Azure OpenAI in your subscription, Amazon Bedrock in your account, or Google Vertex in your project. No data crosses your network boundary at any point in a session.
• In-tenant runtime, vendor model API. Retrieval and orchestration stay in your environment; prompt content goes to a model provider. Faster to stand up and tends to be user-focused. Requires your security team to accept a named third-party processor, so it needs a real decision rather than a default.
• Self-hosted open-weight model. For environments where no third-party inference is acceptable at all. Runs entirely on your infrastructure. Capability is lower than a frontier model.

Who is on my side of the engagement

One person. I have no subcontractors, no offshore development team and no bench. There is no second party for you to vet, no staff rotation, and no one else who ever holds your credentials or your data.

Data handling

The agent is read-only by default. It has no write path into any validated system. Where write capability is ever discussed, it is a separate, explicitly scoped decision with its own risk assessment.

What the output actually is

The agent produces drafts and analysis: an investigation packet, a release readiness summary, a stability projection, a draft Module 3 section. These are working documents. They are not GxP records, they are not the system of record, and they carry no signature. They become records only when a qualified human reviews the content and enters it into the validated system under that system's existing controls.

Retention and destruction

Session logs and the retrieval index live in your storage under your retention policy. At the end of an engagement, any working copy on my side is destroyed. During an engagement I prefer to work against a validation or UAT instance rather than production wherever the data supports it.

21 CFR Part 11 and ALCOA+

The Part 11 position rests on one distinction: the agent does not create, modify, sign or delete electronic records in a validated system. Your LIMS, MES, QMS and ERP remain the record of authority and remain governed by the Part 11 controls they already have. The agent reads from them and produces analysis for a human. Part 11 applies to the systems holding the records; the controls below describe how the agent layer preserves record integrity rather than undermining it.

Where the human approval step sits

Between the agent's output and any GxP consequence. Always. The agent assembles evidence and proposes; a named, qualified human reviews the evidence, accepts or rejects the proposal, and applies their own electronic signature inside the validated system under that system's existing Part 11 controls. The agent holds no credentials in a validated system, has no signature manifestation, and cannot execute an approval. If the human does nothing, nothing happens.

Validation approach

Validation is risk-based and driven by intended use, following GAMP 5 second edition and ICH Q9. The intended use statement does most of the work here: the system is decision support, its output is reviewed by a qualified human before it has any GxP effect, and it has no write path into a validated system. That places it materially lower on the risk scale than a system making autonomous GxP decisions.

GAMP category positioning

• Infrastructure (cloud tenant, container platform, storage) is Category 1 and leans on your existing qualified infrastructure. I do not re-qualify your platform.
• Retrieval and orchestration components are Category 4, configured products. They are commercially available or open-source components used as intended and configured for your environment.
• Workflow-specific configuration (the tool definitions, the queries, the prompts, the output templates for your particular workflow) is Category 5, bespoke. This is where the testing effort concentrates, and it is the honest place to put it.

Testing something that is not deterministic

A language model does not return byte-identical output on every run, and you cannot test it the way you test a calculation in a spreadsheet. The approach splits the system in two:

• Everything deterministic is tested deterministically. Retrieval, queries, calculations and data transformations return the same result every time and are tested with fixed inputs and expected outputs, exactly like any other computerized system. This covers every number that appears in an output.
• The generative layer is tested against acceptance criteria over a fixed challenge set. A defined set of representative cases with known correct answers is executed against the system, and each output is assessed against criteria that are objectively checkable: is every factual claim traceable to a retrieved record, is any claim present that the retrieved data does not support, is the correct conclusion reached, is the required content present. The pass threshold is agreed up front and the challenge set is version-controlled as a validation artifact.

What I don't do

These are scope boundaries, not current limitations waiting to be lifted in a later phase. If an engagement would require crossing one of them, that is a conversation with your quality organization before it is a conversation with me.

• No autonomous changes to validated systems. Ever, in any deployment pattern.
• No writes to the QMS. No deviations raised, no CAPAs closed, no change controls modified.
• No writes to LIMS, MES or ERP. No results entered, no batch records altered, no master data changed.
• No electronic signatures. The agent has no signature manifestation and no credentials to apply one.
• No batch disposition. Release remains a human decision made by a qualified person.
• No decisions without a named human approver. If no one is accountable for the output, the workflow is not in scope.
• No training on your data. Not for my models, not for a provider's, not for a future client's.
• No shadow system of record. Your validated systems stay authoritative and the agent's output store never competes with them.

Access required

This is the minimum footprint for a Data Diagnostic, which is where nearly every engagement starts. It is deliberately small, because a diagnostic is an assessment rather than a build, and because a smaller ask is easier for you to approve.

What I do not need

• Write access of any kind, to anything.
• Administrator or superuser credentials.
• Patient data. CMC and manufacturing data is the scope. If PHI or PII is present in a system in scope, it is excluded and I will say so in writing before access is granted.
• Access to systems outside the agreed scope list, which is fixed in the statement of work.
• A VPN account that outlives the engagement. Access is time-boxed and revoked at close.