When we polled clinical investigation professionals on how often they use artificial intelligence (AI) in their work, about half said less than once a week. That is not a sign the tools do not exist. Clinical operations sits inside one of the most tightly regulated corners of medtech, and moving carefully there is not the same as standing still. The real question is not whether AI belongs in clinical investigations. It is where, specifically, it earns a place, and what has to be true before it gets one.
Inside clinical operations, the value of AI splits into two lanes: speed and quality. Speed is the easy one to measure. Anyone who has asked a large language model to draft an email or a paragraph of documentation has felt how fast a first draft can appear. Quality is where things get complicated, because quality is not one thing. It might mean factual accuracy, a source that actually exists, or language that does not read like it came out of a machine. A fast draft that gets the wrong site name, invents a citation, or phrases a finding awkwardly has not saved anyone real time. It has just moved the work downstream to whoever has to catch the mistake. The honest goal for most AI use in this space is not that quality improves. It is that quality holds steady while speed goes up, so a team is winning on at least one axis without losing on the other.
That framing matters because it sets the bar for where AI is worth deploying during an active study. Applications, institutional review board (IRB) submissions, and other pre-study documentation are one category, and they lean on AI to generate text from existing material. Study conduct is a different category entirely, and it is the one this piece is about: reviewing data while a study is live, coding adverse events, and clearing the tedious, repetitive tasks that eat a data manager's week without adding insight to anyone's study. The regulatory and ethical questions around AI in this space, data bias and what "trustworthy" means for a clinical dataset among them, are worth their own conversation, and we have covered that broader debate separately. This piece stays on the ground: what is built, what it does, and what it still asks of the humans running the study.
Before any AI feature ships inside Greenlight Guru Clinical, it has to clear a governance bar, not just a product one, and that bar recently produced ISO 42001 certification, the standard for AI management systems, company-wide, covering governance across both Greenlight Guru's quality and clinical products. That certification is a formal commitment to developing AI capabilities responsibly, and it shapes a specific architectural choice: AI never acts on clinical data directly. Instead, it translates a plain-language request into an intent, shows that intent back to the user in clear terms, and waits for a human to approve it before anything happens.
That single design decision does a lot of work. Because the AI is only ever passing intent, not touching the underlying data, the risk profile of the interaction is low. A user who has access to perform an action on one site cannot use AI to perform that same action on a site they are not authorized for. The permission model that already governs the platform governs AI the same way, with no separate set of rules to audit. Every approved or rejected intent gets logged, along with who reviewed it, so the audit trail reads exactly the same as it would for a manual action: a named person, a specific request, a decision.
Two capabilities built on that model are available today, not in beta.
The first is a set of natural-language actions for the tedious parts of running a study. A user can describe what needs to happen in plain English, and the system interprets it correctly even from partial information. Ask it to lock data at "Chelsea" and it resolves that to the full site name on record. The same interpretation layer understands other languages, including German and French, without any additional setup. It handles specific, recurring headaches, like reversing a discontinuation a coordinator entered by mistake, or closing out a query, always by presenting the interpreted action for review first. Because nothing executes without that review step, the risk of a prompt-based manipulation slipping through is close to zero.
The second is AI-assisted medical coding for adverse events, built on MedDRA (Medical Dictionary for Regulatory Activities) and requiring a MedDRA license to use. A coordinator enters a description as simple as "headache" or as garbled as a badly misspelled "toothache," and the system returns MedDRA code suggestions with confidence scores attached, ready for a two-step review before anything gets finalized. Greenlight Guru chose MedDRA first because it was the coding standard clients asked for most often. Support for the International Medical Device Regulators Forum (IMDRF) code set and the Universal Medical Device Nomenclature System (UMDNS) database is in progress, following the direction the updated ISO 14155 standard for medical device clinical investigations has been moving. Medical coding is generally available now. A study can turn it on as soon as licensing and contracting are in place.
The next layer is further out, still in beta, and worth understanding now because it changes how a data manager, monitor, or study coordinator might work day to day.
The approach Greenlight Guru Clinical is testing is bring-your-own-agent. A team picks its own AI agent and model, whether that is a commercial assistant or an open-source option they host themselves. They pick their own scripting language for anything that needs to be reproducible, Python or R or something else entirely. And if other systems matter, like a clinical trial management system (CTMS) or a separate electronic data capture vendor, the agent can pull from those too, provided it is integrated with them. None of that is decided for the customer. Flexibility on the agent side means the security posture has to be equally flexible, and equally deliberate.
The architecture behind it works like this: a user asks their AI agent to do something, the agent decides it needs data from Greenlight Guru Clinical, and it reaches that data through an intermediary called an MCP (Model Context Protocol) server, which enforces the same authentication and permission rules as everything else on the platform. Once the data comes back, it lands inside the agent, and whatever happens next, a summary, a chart, a report, happens there. Greenlight Guru controls the pipeline up to that point and applies the same security rigor it applies everywhere else. What happens to the data once it reaches the agent depends on decisions the customer makes, which is exactly why those decisions need to be made carefully.
Two non-exclusive paths address that. A team can own its agent outright, hosting an open-source model or working under an enterprise agreement that guarantees the data will not be used for training, giving them full control over where the model runs and what happens to any input. Or a team can avoid sharing live data with any agent at all by duplicating a study inside Greenlight Guru Clinical and sending only that synthetic copy, which preserves the full structure without exposing a single real subject's information. A generic script built and verified against that synthetic data can then be redirected to point at the live study, and run from a controlled environment the team already trusts. Either way, the live clinical dataset never has to touch the agent directly. Which path fits depends on where a company is based and what regulations apply. Teams operating in Europe, for instance, are working within GDPR (General Data Protection Regulation) constraints from the start, which shapes the calculus toward the synthetic-data route more often than not.
The longer-term picture looks like the way some teams already work with AI agents outside clinical research: one connected workspace tied to email, a calendar, project tools, and now, optionally, study data, so a monitor or data manager can ask a single assistant what needs attention today instead of checking five systems separately.
The clearest way to see the difference a good prompt makes is to look at the same tool used twice.
In a studies overview demo, a simple prompt, asking for an overview of two studies, produced a generic dashboard: basic enrollment status, a query count, a rough summary. A second attempt used a far more specific prompt asking about consent-signing progress, completion rates, and a projected last-patient-last-visit date, and the output changed accordingly, complete with a progression chart built from real enrollment and consent dates already in the system. The lesson generalizes beyond this one demo: specificity in, specificity out. And once a prompt produces the report a team actually wants, it can be converted into a script, reviewed like any other piece of code, and rerun against a live study with confidence that it does the same thing every time.
A second demo pushed further into monitoring. The prompt specified exact timing rules, consent has to be signed before baseline, a week one follow-up has to land within a set window of baseline plus a defined number of days, and asked for a breakdown by site. The output flagged genuine problems: at two separate sites, consent had been signed after baseline instead of before it, a timing violation worth catching early rather than at database lock. The AI also ranked which site needed the most attention based on the pattern of issues it found. None of that required a person to comb through every subject's timeline by hand first. The same prompting approach extends naturally to post-market work, including the ad hoc data a team collects through Greenlight Guru Clinical Cases once a device is already on the market.
Both examples come with the same caveat, and it is worth taking seriously. A chat-based report is genuinely useful for a quick look. For anything a team will rely on repeatedly, or use to make a decision, the answer is the same one that applies to human-written reports: verify the input, and rebuild it as a script that can be checked and rerun rather than regenerated from scratch each time. Spot-checking a count, like the total number of adverse events, against the source system takes a minute and closes off the most common failure mode.
Large language models are optimized to keep a conversation going, and that shapes their failure mode in a specific direction. Models are penalized during training for saying "I don't know," which means they are built to produce a confident-sounding answer even when the honest answer is that they are not sure. That is not a defect that better prompting fixes. It is closer to a permanent feature of the technology, and it is exactly why a generated report needs the same scrutiny a junior team member's first draft would get, not more trust because a machine produced it.
There is no dedicated AI tooling yet for periodic safety update reports, clinical evaluation reports, or other post-market vigilance documentation. Teams using general AI assistance for that kind of writing today should treat it the way they would treat any other unverified draft: define the structure ahead of time, confirm every input against source data before it goes anywhere near the document, and never ship something an AI wrote without a qualified reviewer's sign-off. The agent-based and medical coding features described here are not a substitute for that discipline. They are proof that the discipline can scale without slowing a study down.
The teams that get the most out of AI in clinical investigations right now are not the ones chasing every new capability. They are the ones being precise about which tasks are genuinely metadata and review work, which ones touch real study data and need a security decision made in advance, and which ones still belong to a person with the training to catch what a model cannot. Get that sequencing right, and speed stops being a tradeoff against quality. It becomes the point.
If you are building out an AI governance approach for clinical operations, these related guides go deeper on the specific components:
See how Greenlight Guru Clinical applies this approach to your studies. Get a demo and ask to see the AI-assisted medical coding and smart actions in action.
For a more in-depth walkthrough of everything covered here, including a live look at the medical coding and monitoring examples plus the full audience question and answer session, watch the on-demand webinar this post is based on: AI in practice: how clinical investigation teams are working smarter right now.