The IRB does not need to decide whether AI is good or bad. It needs to ask whether an AI workflow preserves the protections, boundaries and responsibilities that apply to the study.
Part of the AI Security for Research Institutions guide series.
The research question is no longer only whether AI can improve a study.
It is whether the AI system changes the security and privacy risk of the study itself.
When an AI agent processes participant data, summarizes research records, retrieves study documents, or assists with decisions, the institution needs to understand what the system can access, what it can infer, and what it can cause.
The Common Rule, codified for HHS at 45 CFR Part 46 Subpart A, provides a core federal framework for protection of human subjects in applicable research.
AI does not replace that framework.
Instead, AI can change the operational risk that an IRB or research institution needs to understand.
An AI agent may process information across multiple systems. It may combine records that researchers previously handled separately. It may retrieve documents dynamically. It may maintain persistent memory. It may invoke tools.
The question for the research institution becomes:
Does the AI workflow create a new way for participant information to be exposed, combined, changed, or acted upon?
A common mistake is to treat every research-data AI question as a healthcare AI question.
Some research environments involve PHI and HIPAA-covered entities. Others involve research data governed by the Common Rule, informed-consent restrictions, data-use agreements, institutional policies, funding terms, or controlled-access repository requirements.
The governing question is therefore broader:
What obligations attach to this research data, this protocol, this institution, and this AI workflow?
Before approving or expanding AI use in human-subjects research, institutions should document:
This creates an AI-specific extension to the study's existing risk analysis.
An AI agent may retrieve information from multiple research systems in a single task.
A researcher might ask:
“Summarize the adverse events for this study cohort.”
The agent could potentially retrieve safety reports, visit notes, coding metadata, investigator notes, and other records.
That may be useful.
It also creates an aggregation risk.
Information that was separately protected may become combined inside one AI context.
The security question is not only whether each source is individually authorized.
It is whether the combined context is appropriate for the user's task.
A participant-facing or research-facing AI system can encounter instructions inside data.
A research document can contain malicious text.
An email can contain attacker instructions.
A web page can contain prompt injection.
A retrieved PDF can contain hidden instructions.
If an AI agent treats the text as instructions rather than data, the attacker may influence the workflow without ever contacting the AI interface.
For human-subjects research, the consequence can be particularly serious because the downstream data may contain highly sensitive participant information.
AI may create new questions about how research participants are informed about data processing.
The key issue is not that every AI use automatically requires a new consent process.
The issue is whether the proposed AI use fits within the research purpose, protocol, consent framework, institutional policy, and applicable requirements.
Examples that may trigger deeper review include:
These are governance questions that should be assessed with the IRB, privacy, legal, security, and research teams as appropriate.
Suppose an AI system is used to summarize participant outcomes.
If malicious or inaccurate context causes the summary to omit events, misclassify findings, or introduce false information, the incident is no longer only a cybersecurity problem.
It may affect the scientific record.
The more consequential the output, the more important it becomes to preserve provenance and human review.
This is especially important for safety-related reporting, eligibility assessment, protocol deviations, and other research processes where errors can have material consequences.
An AI agent may have broad research privileges because developers want the workflow to “just work.”
That can create unnecessary exposure.
An agent that only summarizes should not automatically have write permission to study records.
An agent retrieving participant data should not automatically have access to every study.
An agent assisting one investigator should not automatically inherit a department-wide service account.
The safest research AI architecture begins with narrow, task-specific authority.
IRBs and research institutions can ask:
These questions make AI risk concrete without requiring an IRB to become an AI engineering organization.
A strong institutional baseline includes:
The IRB should not have to answer whether AI is “good” or “bad.”
The governance question is narrower and more actionable:
Does this AI workflow preserve the protections, boundaries, and responsibilities that apply to this research?
That question brings AI security into the same institutional conversation as participant protection, protocol governance, data stewardship, and research integrity.
HexTyx tests AI agents against live, LLM-backed applications that use synthetic data in controlled environments. Our record covers 28 domain applications. These are not research-institution deployments and no real participants or studies were involved, but the failure patterns map directly onto the boundaries in this guide.
Human oversight only counts if the approval is real. In a synthetic clinical-records app (Concord), a fake-confirmation attack led the agent to execute a medication order for a patient on warfarin, even though the system had already detected a genuine drug-interaction conflict. The agent treated a claimed confirmation as an actual one. The same pattern appeared in a synthetic banking app (Vault), where a $5,000 transfer executed with no real confirmation.
For an IRB, the practical question is where approval is enforced by the system rather than asserted in a conversation, and whether the reviewer can see what the agent retrieved and changed.
Run the free playground scanner against your own AI application, or read the other guides in this series.