AI and patient data privacy in clinical trials: a four-level access model

Ask your data protection officer whether the study team can use AI on trial data. You will get one of two answers. "No" blocks every use case, including the ones that touch no patient data. "Yes" without conditions puts health data in a tool nobody has assessed.

Both answers miss what your EDC does every day. When a person joins a study, you give them a role, and the role decides what they see.

A four-level access model applies the same rule to AI. You classify study data by how close it sits to a person, from L0 (metadata) to L3 (identifying data), and each AI tool gets the levels its task needs and its compliance status allows. Datacapt uses this model in its EDC and its MCP connector.

A health-data compliant AI meets GDPR, HIPAA and HDS or an equivalent standard, or runs in your own infrastructure. The Datacapt connector gives every other tool L0 and L1 by default.

[[takeaways]]

Role-based access: you already limit what each user sees

Open the role settings of any EDC used in a regulated trial and you will find the same pattern:

This table is how you prove to an inspector that each person accessed what their job required and nothing more.

The regulations ask for this in their own words:

• GDPR, Article 5(1)(c) requires data minimisation: you process the personal data the purpose needs, and no more. Article 25 asks for data protection by design and by default.
• HIPAA sets a minimum necessary standard: a covered entity limits a use or disclosure of protected health information to the minimum needed for the task.
• 21 CFR Part 11, section 11.10(d) requires you to limit system access to authorised individuals. Section 11.10(g) adds authority checks on who can perform which operation, and section 11.10(e) requires a secure, time-stamped audit trail.

None of these texts mentions AI. All of them describe access control by role, and you can apply them to an AI tool the way you apply them to a person. For the full set of EDC requirements, see regulatory compliance of EDC systems.

Treat an AI tool as one more user

When a data manager asks Claude to draft edit checks, or a study manager asks ChatGPT for a site status, the AI reads study data. For your quality system, that makes it a user. It needs a role, a scope and a trace in the audit trail.

Two questions set its role:

1. What does the task need? Edit checks need the protocol and the form structure (L0). A site status needs counts (L1). A medical review of subject 012 needs that subject's answers (L2).
2. What has the tool proved? A tool your company has approved, under a contract that stops the vendor from training on your inputs, qualifies for L0 and L1. A tool that meets health-data rules qualifies for L2 and L3.

The task decides what the AI needs. The tool's compliance decides what it may get. When the task needs more than the tool has proved, you change the tool and keep the rule.

In Datacapt, the AI takes the role of the person who connects it. It gets the same permissions as that user's login. A CRA's agent sees the CRA's sites. A data manager's agent sees what the data manager sees, and nothing more. Every action it takes goes into the audit trail.

L0: metadata carries no personal data

The protocol, the visit schedule, forms, variables, codelists, validation rules and the blank eCRF describe the study without describing a person. GDPR applies to personal data, so L0 falls outside it. HIPAA and HDS do not apply either.

The risk at L0 is confidentiality. Your protocol is sponsor intellectual property. Your legal team handles that with the AI vendor's contract: no training on your inputs, retention limits, and the vendor's security commitments.

L0 is the one level where the AI may write. An agent can build forms, set conditional logic or add a study language. In Datacapt those writes land in a study in DRAFT status. A study designer reviews and validates the build before go-live, so the validated system that collects patient data stays under human control.

💡 Start your AI programme at L0. Study build saves the most time, and your DPO has no personal data to assess.

L1: aggregates answer most monitoring questions

Completion rates, query counts, SDV status, recruitment per site and missing data by form are aggregates. The platform computes them and sends the AI a number. The model reads "site 102 has 14 open queries older than 30 days" and never reads the 14 values behind it.

GDPR Recital 26 excludes anonymous information from its scope: data that no longer relates to an identifiable person. An aggregate built on enough subjects meets that test, which is why any approved AI tool may read L1.

The AI reads aggregates and never writes them. Collected data belongs to the site user who entered it, with an audit trail entry and a reason for change, as Part 11 expects.

⚠️ Watch small counts. If a site has enrolled one subject, "1 serious adverse event at site 104" points to a person. Set a minimum cell size with your data protection team, and treat any figure below it as L2.

L2: pseudonymised data is still personal data

L2 is the eCRF itself: answers linked to a subject number such as 012, with no name or direct identifier.

Many teams assume a subject number makes data anonymous. GDPR Recital 26 treats pseudonymised data as personal data, because someone holds the key: the investigator site can link 012 to a patient. In September 2025 the EU Court of Justice (EDPS v SRB) accepted that a recipient with no reasonable means to re-identify may hold data that is not personal for them. That does not help a study team, a sponsor or an EDC vendor, who can trace a subject through the site. Clinical data is also health data, a special category under Article 9.

An AI tool that reads L2 becomes a processor of health data. Your organisation then needs:

• a data processing agreement with the AI vendor (GDPR Article 28),
• a data protection impact assessment that covers the AI use (Article 35),
• a transfer mechanism when the vendor processes data outside the EU, such as an adequacy decision or standard contractual clauses (Chapter V),
• HDS-certified hosting when the data falls under French health data rules,
• a Business Associate Agreement when HIPAA applies,
• or a model you run on your own servers, where the data never reaches a third party.

L2 gives you what counts cannot. An AI with L2 access can read a subject's visits in order and flag that V3 is dated before V2. It can propose MedDRA or WHODrug codes or draft a narrative for a medical reviewer.

L3: identifying data stays with the people who need it

L3 holds what identifies a person on its own: name, contact details, date of birth. It also holds uncontrolled free text, because a site user can type a name or a phone number in any comment field, and you cannot know until someone reads it.

L3 follows the same bar as L2. In practice, few AI tasks in a study need it. Recruitment follow-up is one, when a coordinator wants help scheduling calls with pre-screened candidates. Data minimisation and the HIPAA minimum necessary standard both point the same way: keep L3 out of an AI workflow unless the task requires it.

The Datacapt MCP server never returns a participant's name, contact details or date of birth. Its tools know a participant by subject number and Datacapt ID.

What each regulation asks, and how the levels answer

The EU AI Act adds its own timeline, pushed back in 2026. Most AI tools used to run a trial are not high-risk systems under it. Read what Regulation 2026/1744 changes for clinical trials for the dates.

Responsibility is shared, as in software validation

You already share responsibility for your EDC. The vendor validates the platform: its development process, its tests, its release notes. You validate your use of it: the study build, the user acceptance tests, the roles you grant. GAMP 5 and ICH E6(R3) describe this split, and an inspector expects to find it in writing. Our guide to computerized system validation in clinical trials covers the method.

AI use follows the same split:

The sponsor keeps final responsibility for the trial data under ICH E6(R3), even when it delegates tasks to a CRO or a vendor. The decision to use AI on a study belongs to the sponsor.

If you run a study for a sponsor, ask them before an AI tool touches it. Write their answer into the contract or the quality agreement: which tools, which levels, for which tasks, and who validates the output. If you are the sponsor, add the same clause to your CRO and vendor contracts.

Do it for L0 and L1 too. Your protocol belongs to the sponsor, and most confidentiality clauses forbid sharing it with a third party the sponsor has not approved. The sponsor also qualifies every system that handles its study, and an inspector will ask the sponsor how the team used AI. A signed clause gives the sponsor that answer, and the audit trail shows you stayed inside it.

💡 Add one AI clause to your contract template: approved tools, maximum level per tool, tasks, and the person who validates AI output. You then negotiate it once per sponsor.

How Datacapt enforces the levels

Your team should not have to enforce this by memory. Datacapt builds the levels into the connector:

• A tool that does not meet the health-data bar receives L0 and L1 by default.
• AI writes go to metadata in DRAFT studies. A human validates before go-live.
• Names, contact details and dates of birth never leave the platform through the MCP server.
• The AI gets the same permissions as the user who connects it. It cannot open a study, a site or a form that user cannot open.
• Each user connects with their own MCP key, scoped and revocable, so every AI action carries a name.
• Every MCP action goes into the audit trail with its origin, so an inspector can separate an AI action from a human one.

For the mechanics of an MCP server, read MCP and LLMs in clinical research. To compare what EDC vendors let an agent do, read the four levels of AI agent access. That article grades agent capability, from reading documentation to writing a study; this one grades the data an AI may see.

Six questions for your DPO and quality team

1. Which level does each AI use case need? List the use cases and assign the lowest level that works. Most study build and monitoring tasks stop at L1.
2. Which tools qualify for which level? Keep the BAA, the DPA, the transfer clauses or the HDS certificate on file for each tool cleared for L2.
3. Does the vendor train on your inputs? Get the answer in the contract, for every level.
4. Where do AI writes land? They should land in a draft that a named person validates.
5. Can an inspector trace what the AI did? The audit trail should show each AI action, under which user, on which data.
6. Has the sponsor approved the AI use in writing? The contract or quality agreement should name the tools and levels, L0 and L1 included.

Write the answers into your DPIA, your computerised system risk analysis and your contracts. An inspector who asks how you control AI then gets the same answer as for any user: a role, a scope and a trace.

[[cta]]