AI Data Protection in Clinical Research Depends on Record Scope

A clinical trial application sends a protocol question to an LLM over HTTPS. The retrieved context includes a coded subject identifier, a visit date and a free-text site note. Encryption protects the network hop. AI data protection clinical research still depends on who may send those fields, which endpoint may receive them and whether the resulting electronic record falls within a regulated system.

FDA Part 11 and the Common Rule answer different questions. Part 11 addresses electronic records within its stated scope, while the Common Rule gives an institutional review board a privacy and confidentiality criterion for covered research. The organization has to map the AI workflow to each source before selecting controls.

TL;DR

• Part 11 applies to specified electronic records and submissions, so teams must establish record scope before claiming an AI control satisfies it.
• Closed systems require controls for authenticity, integrity and appropriate confidentiality; open systems add measures suited to transmission risk.
• Common Rule review may require adequate provisions for subject privacy and data confidentiality in covered research.
• Inline controls cover authenticated HTTP requests routed to LLM endpoints, excluding local inference, vendor-internal calls and unmanaged bypass paths.

Part 11 starts with the electronic record

Part 11 scope in section 11.1 covers electronic records created, modified, maintained, archived, retrieved or transmitted under FDA record requirements, plus specified electronic submissions. That language makes intended use and record status the first design questions.

A prompt used to reformat a meeting agenda may sit outside that population, while an interaction that creates or modifies a record required by an FDA predicate rule may sit inside it. The label "clinical AI" settles neither case.

Document the source record and intended use. Add the system owner and disposition of model output. AI governance for clinical research covers that use-case inventory. The protection design should then follow the actual record flow, including retrieval context inserted by an application before the request leaves.

Closed-system controls reach the AI workflow

Part 11 section 11.10 requires controls for closed systems designed to ensure authenticity, integrity and, when appropriate, confidentiality of electronic records. Named measures include validation, accurate retrieval through retention, access limited to authorized individuals, time-stamped audit trails and authority checks.

The Part 11 definitions define a closed system by whether access is controlled by people responsible for the electronic records. An internet connection alone does not decide the classification.

For an AI-assisted workflow, authorized access should reach the model request. A shared API credential identifies the application while hiding the coordinator, monitor or service acting through it. Carry the authenticated principal and role into the policy decision, then record the destination and the rule applied. AI audit trails in clinical research covers reconstruction after that decision.

Open-system design adds transmission protection

Part 11 open-system requirements call for controls designed to protect authenticity, integrity and appropriate confidentiality from record creation to receipt. They carry the closed-system controls forward as appropriate and name additional measures such as document encryption and suitable digital-signature standards.

TLS can protect the request during transport to a model endpoint. It cannot establish that the endpoint was approved for coded participant data or that the authenticated caller had authority to send it. Those are policy questions above the encrypted channel.

Picture a site coordinator at a metal desk, with a paper visit worksheet on the left and a browser assistant on the right. The subject code is visible in both. A control that fires after the prompt reaches the provider preserves evidence of an exposure. Classification and destination authorization must happen before transmission.

The Common Rule adds a separate confidentiality test

Common Rule section 46.111 states that an institutional review board must find, when appropriate, adequate provisions to protect subject privacy and maintain data confidentiality. The criterion also reaches certain changes in how identifiable private information or identifiable biospecimens are stored or maintained.

This provision does not prescribe an AI log schema, an encryption method or a gateway. It asks the research institution and review process to establish adequate provisions for the covered study.

An AI workflow description should identify the information sent, recipient, purpose, retention arrangement and human review. Changes in retrieval scope or provider processing may alter that analysis. AI vendor risk in clinical research covers supplier evidence. The protocol and institutional review duties remain with the research organization.

Minimize data in requests and security records

The safest prompt often excludes direct identifiers and unnecessary free text before any route decision occurs. Coded data can still carry confidentiality risk when combined with dates, site details or rare events. Classification should examine the assembled request. That includes system instructions and retrieved context, rather than only the user's visible sentence.

Security records deserve the same restraint. Keep the principal, role, data class, endpoint, policy reference, decision, timestamp and correlation identifier needed to prove control operation. Store full content only under an approved purpose with defined access and retention. A hash can support correlation without copying an entire subject narrative into a second repository.

I would never accept "we redact names" as a complete clinical research data-protection policy. A participant's name is only one identifier among the facts that can make a request recognizable.

Validation and oversight remain outside the gateway

A routed control can enforce identity, classification and destination rules. It can also produce dated evidence that a request was permitted, redacted, rerouted or blocked.

They do not validate intended performance, establish fitness for purpose, approve protocol use or replace investigator review. Part 11 audit-trail duties for creation, modification and deletion of regulated records may extend beyond the AI interaction, while the authoritative clinical record remains in its designated system, under the sponsor's retention and change-control procedures.

Shadow AI in clinical research addresses unmanaged tools. Governance teams should report approved routed calls separately from browser use they have not brought under identity and policy.

The HTTP boundary needs named exclusions

DeepInspect's technical boundary is authenticated HTTP traffic routed between users or agents and LLM endpoints. That can include a trial application calling an external model API or a managed assistant whose requests pass through the same enforcement point.

A local model on a workstation may avoid that route, and inference performed entirely inside an electronic data-capture vendor's environment may expose no customer-controlled HTTP call. Direct browser sessions and application bypasses also sit outside the evidence population. Vendor records, endpoint controls and contractual controls have to cover those paths.

The control narrative should list included applications and excluded routes as of October 5, 2026. A diagram that sends every arrow through one gateway is useful only when the route inventory proves the picture is true.

DeepInspect

DeepInspect is a stateless proxy for authenticated HTTP traffic between clinical research users or agents and LLM endpoints. It evaluates application-supplied identity, request classification, approved destination and policy before forwarding. Every permit, redaction, reroute or block produces a signed per-decision record outside the calling application's write path.

For routed workflows, that creates an enforceable data boundary before coded subject information reaches a model provider. DeepInspect does not determine Part 11 scope, validate computerized systems, approve protocols, perform investigator review or cover local and vendor-internal inference that bypasses the proxy. Book a demo today.