Does an AI gateway audit record become a clinical source record?

Its status depends on how the sponsor defines source records and uses the data. The gateway record usually supports oversight of the AI interaction. The clinical observation remains in the designated source system. Sponsors should document that relationship before use and update the definition when the workflow changes. ICH E6(R3) asks investigators to define source records, capture methods and locations before the trial starts.

What should be retained when prompt text contains participant data?

Retain only what the approved purpose requires. The record can hold identity, classification, endpoint, decision, policy reference, timestamp and cryptographic hashes without creating a second repository of full participant narratives. If reconstruction requires content, the sponsor should define access, encryption and retention controls around it. The data-minimization decision belongs in the protocol-related documentation and privacy review.

Can a model provider's usage log satisfy the audit requirement?

A provider log can contribute evidence, but its fields reflect the provider's service boundary. It may identify an API credential rather than the study coordinator who initiated the request. The sponsor's data classification and internal authorization decision may also be absent. The sponsor should map provider fields to the reconstruction question and close the missing fields on its own controlled path.

Does this architecture validate the AI system under FDA requirements?

A per-request trail supplies evidence about covered interactions. It does not establish fitness for purpose, validate a computerized system, approve a protocol use or perform investigator review. Those decisions remain with the sponsor, investigator and quality functions under the applicable regulations and guidance.

Clinical Research AI Audit Trails Must Reconstruct the Trial Record

FDA's October 2024 guidance says an inspector may request all records and data needed to reconstruct a clinical investigation, including associated metadata and audit trails. That sentence gives ai audit trail clinical research work a practical test.

Take one AI-assisted action. A sponsor should be able to show who initiated it, what class of trial data entered the request, which model received it, what policy applied and what came back. The final clinical record still lives in the validated trial system. The AI request record explains one step in how that record was prepared or reviewed.

A general chatbot transcript rarely survives this test. It may show text. The authenticated user, routing decision or policy state that governed transmission may be missing.

TL;DR

FDA says inspection records may need to reconstruct a clinical investigation, including metadata and audit trails.
ICH E6(R3) expects source-record changes to remain traceable and asks sponsors to review relevant metadata.
An AI request record should bind identity, data classification, destination, policy decision and time to one interaction.
This record supports oversight of authenticated HTTP model traffic. It does not replace source data, validation or investigator review.

Reconstruction starts with the regulated record

The FDA guidance on electronic systems in clinical investigations addresses systems used to create, modify, maintain, archive, retrieve or transmit clinical investigation records. It says regulated entities should preserve electronic records and associated metadata in a secure, traceable manner. FDA may request human-readable copies that include metadata and audit-trail information.

Consider a coordinator asking an LLM to summarize a site note. The summary might enter the trial master file or support a safety decision. If it does, the sponsor needs to understand the electronic path that produced it. The source note, approved summary and review remain in their proper systems. The AI trail adds evidence about the intermediate request.

I would reject any control description that calls a folder of exported chat transcripts an audit trail. The folder proves that text existed. It says little about authorization, data handling or the rule applied at transmission time.

ICH E6(R3) makes metadata part of trial governance

The ICH E6(R3) Good Clinical Practice guideline places data governance duties on investigators and sponsors. Its records provisions say source records should be attributable, legible and contemporaneous. Changes should remain traceable without obscuring the original entry. The data life-cycle provisions address relevant metadata, including audit trails.

The guideline also tells sponsors to focus quality control on data of higher criticality and relevant metadata. For sponsor-deployed computerized systems, it calls for records of important systems, documented access controls and a record of authorized users with their roles and permissions.

An AI assistant used for protocol queries or adverse-event drafting can sit beside those systems. It may never appear in their native audit logs. That gap is where a separate request record earns its place. AI vendor risk in clinical research covers the supplier side. The operational record has a different job: document each covered interaction.

The useful record is tied to one request

A clinical research AI audit trail should make one interaction reviewable without asking the model vendor to reconstruct it later. Start with the authenticated person or service identity and a timestamp with a defined time basis. The same record also needs the content classification applied before transmission, the resolved endpoint and the permit, redact, reroute or block decision.

The policy reference should be exact enough to reproduce the decision. A label such as clinical-data-policy-v14 is more useful than "policy passed." Store a request hash when retaining prompt text would create avoidable exposure. Record the response disposition too, especially when policy checks occur on model output.

Picture a monitor at a site desk with a laptop open to one subject query. The useful evidence is a joined sequence: the approved source record, the AI interaction identifier and the human review that followed.

A screenshot of the assistant window leaves the joins to memory.

Data criticality should change the policy

ICH E6(R3) uses proportionality throughout its treatment of computerized systems. Apply the same discipline to AI traffic.

A request containing public protocol text can follow a different route than a request containing coded participant data. A query that could affect eligibility or safety deserves stricter handling than a request to reformat a meeting agenda.

The classification decision must happen before the model receives the prompt. Logging the sensitivity after transmission documents an exposure rather than controlling it. For managed HTTP paths, an enforcement point can detect the class, compare it with the user's role and allow only an approved destination.

Shadow AI in clinical research covers browser assistants and unsanctioned endpoints. Report that population separately in the audit-trail design. Mixing sanctioned application calls with unmanaged browser use produces a reassuring total that hides the traffic a sponsor has never evaluated.

Audit trails need review and retention rules

An audit record has value when someone reviews it against a defined question. Clinical operations may sample AI interactions tied to protocol deviations. Quality can examine blocked requests involving participant identifiers. Information security can investigate unexpected destinations or repeated policy failures.

Each review needs an owner, cadence and escalation route.

FDA's guidance says backup and recovery logs should support assessment of data loss after a system failure. It also warns that when a hosted-system contract ends, sponsors should obtain retained metadata and keep it linked to the corresponding data element. Procurement teams should ask every AI service provider how those linked records will be returned at contract exit.

Retention should follow the clinical record and protocol context, rather than the default setting in an observability product. AI audit trail requirements by regulation explains why one retention period rarely works across every regime.

Document the chosen period and the deletion authority.

The HTTP boundary belongs in the control narrative

DeepInspect's relevant coverage is authenticated HTTP traffic between a user or agent and an LLM endpoint. That can include a trial application calling an external model API. It can also include managed browser traffic routed through the same enforcement point. For those paths, the request record can show identity, classification, destination and policy outcome.

Several clinical data flows sit outside that boundary. A model embedded inside an electronic data-capture product may perform inference entirely within the vendor's environment. A local model on a workstation may never make an HTTP call through the gateway. The native system record and supplier evidence have to cover those interactions.

State those exclusions in the control description. A neat architecture diagram with every arrow passing through one box is visually satisfying, but it is a poor substitute for a route inventory with named owners. Signed audit logs for AI requests covers write-path independence for the traffic that is in scope.

DeepInspect

DeepInspect is a stateless proxy for authenticated HTTP AI traffic between clinical research users or agents and LLM endpoints. Before forwarding, it evaluates application-supplied identity, request classification, approved destination and policy. Each decision produces a signed record outside the calling application's write path.

That record can connect a covered AI request to the person or service that initiated it, the policy used at that moment and the disposition of the traffic. DeepInspect does not determine the clinical source record. It does not validate the trial system, assess data quality or cover inference that stays inside a vendor platform or local process.

Book a demo today.