AI at the Site: Start With the Boring Stuff

When someone shows me an AI tool for clinical research, I want to know what it will take off the team's plate on an ordinary workday.

Not the most impressive thing it can do in a demonstration. The thing a coordinator currently spends time doing, checking, or doing again.

My background is in software, and I co-founded Study Catalyst. I am interested in what these tools can make possible. Being involved in site operations also makes me cautious about confusing an interesting output with a dependable process.

For an early AI project at a research site, I would start with a small administrative task that can be checked easily and reversed when it is wrong.

Pick a task with a clear finish line

Consider turning a nonconfidential meeting agenda into a draft action list. Or sorting public study-opportunity descriptions into a preliminary review queue. Or helping an employee write a clearer internal message using invented example details.

Those are candidate workflows to evaluate, not claims that every tool is suitable for them. The right choice depends on the approved environment, the information involved, and the people responsible for review.

What I like about a bounded task is that the team can describe success in plain terms. Did the action list keep the correct owner? Did it invent a deadline? Did the summary omit the one condition that changes the decision?

If nobody can explain how the result will be checked, the workflow is not ready.

Count the review time

A draft produced in seconds can still take longer to correct than writing it yourself.

That is why I would measure the complete task. Include preparing the input, reviewing the output, fixing mistakes, and moving the approved result into the team's normal process.

The same comparison should look at quality. Faster is not useful if the team misses a qualification, loses context, or has to revisit the work later.

The time saved belongs to the whole workflow, not the generation button.

A pilot that shows little benefit is still useful. It tells you where not to spend more staff time. You do not need to keep a tool just because the demonstration was persuasive.

Keep the boundaries clear

I would not begin with autonomous eligibility decisions, clinical judgments, or unreviewed changes to participant records. Those carry consequences that a simple administrative pilot is not designed to address.

Even an ordinary drafting task needs clear data boundaries. Use synthetic or appropriate public material for early testing. Do not put participant information or confidential study documents into a general tool simply because the input box accepts them. The organization needs to assess the system, permissions, intended use, and information handling before approving a real workflow.

A human reviewer also needs the original source and enough time to check it. Assigning responsibility to a person without giving them that context is a weak control.

• Choose one bounded task. Write down the intended input, expected output, and things the tool must not decide.
• Test realistic mistakes. Include missing information, conflicting instructions, and an example where the correct response is to leave an item unresolved.
• Measure the complete result. Compare time and quality with the existing process, and define when to stop or revise the pilot.

Make it easy to say “this did not help”

Employees should be able to report that a tool adds work without feeling that they are resisting progress. Their workaround may reveal more than the product's usage report.

Ask what they had to verify twice. Ask which output looked convincing but was wrong. Ask whether the tool helped them finish earlier or simply created another place to check.

This is the same test I would apply to a new clinical trial portal. A technology project needs to fit the work, and the people doing that work should help judge the result.

I am optimistic about useful AI. My first question is deliberately unglamorous: what repetitive task can we make easier, with a result we can trust after appropriate review?

What small administrative task would you test first, and how would you know the tool helped?

Enmanuel CorvoEngineer. Site leader. Always learning.

I write about the practical work behind clinical research and what sites, sponsors, and CROs can learn from each other.

Share your perspectiveAll perspectives