5 Steps to Scope an AI Project in Medical Affairs That Survives Review and Outlasts the Pilot

If you work in medical affairs or digital innovation in pharma, you have probably seen a version of this story. An AI idea gets energy and a small budget. A vendor or an internal team builds a pilot. The demo impresses leadership. Then the project slows: compliance has questions nobody anticipated, the data turns out to be messier than the demo data, the business owner changes roles, and nobody has budgeted for running it at scale. Months later, the pilot is quietly retired.

There is a very human reason this happens. Most of us want a project that shows value, for the organisation and for our own growth, and we want it quickly. Keeping up with how fast AI is changing is hard, and nobody can be an expert in the technology, the data, the regulations and the workflow all at once. So shortcuts are tempting: a narrow demo, clean sample data, reviewers brought in at the end. The five steps below are designed to replace those shortcuts with a scope that holds up.

Same idea, same technology, different outcome.

Step 1

Define the problem

1. Whose problem is this, and how do they experience it today?

Strong projects start with a specific group of people and a specific frustration: medical information specialists rewriting similar responses, MSLs preparing for visits, programme teams processing enrolment documents. Talk to them before you scope. If the people who will use the tool do not recognise the problem as theirs, adoption will be difficult no matter how good the technology is.

2. What task or decision will change, and what will not?

Define the scope in terms of work, not technology. "Use a large language model for medical affairs" is not a scope. "Draft first responses to routine medical information enquiries from approved content, for medical review" is. Be equally clear about what is out of scope, because AI projects expand easily and every expansion brings new reviewers and new risks.

You are ready for step 2 when you can name the users, describe their current process, and state the task that changes in one sentence.

Step 2

Agree the value

3. How will we know it worked?

A demo shows that something is possible. A pilot should show that it is worth doing. Measure the current process before you start: time per task, turnaround, error rate, backlog, or the quality of outputs. Then agree the measures you will compare after the pilot, and what result would justify scaling. Without a baseline, even a successful pilot is hard to defend.

4. Who benefits, personally and organisationally?

Projects move when people can see what is in it for them. Think about value at three levels: for the people doing the work (less repetitive effort, more time for judgement), for the function (capacity, consistency, insight), and for the organisation (outcomes, speed, evidence). Be honest about who gains and who carries extra effort during the transition. A project owner who can speak to all three levels is far better placed to secure support for scaling.

You are ready for step 3 when you have a measured baseline, an agreed threshold for scaling, and a value statement for each level.

Step 3

Check the data

5. What data does it depend on, and is it ready?

Many AI projects are data projects in disguise. A tool that drafts from approved content depends on a clean, current content library. A tool that analyses real-world or programme data depends on records that may be scanned, multilingual and inconsistent. Pilots often use a small, tidy sample; real use brings the full variety. Assess the real data early, because it usually determines timelines more than the model does.

6. Are we allowed to use this data in this way?

Data collected for one purpose is not automatically available for another, and AI adds new questions: where data is processed, whether it leaves the country, whether a vendor stores it or uses it to train models, and whether personal or health information is involved at all. Settling these questions during scoping prevents the most common late-stage blocker.

You are ready to finalise the scope when the approach has been tested on realistic data and the data flow has been reviewed by privacy.

Step 4

Bring in reviewers

7. Who needs to review this, and have they been involved from the start?

Depending on the use case, reviewers may include medical, legal, compliance, privacy, pharmacovigilance, quality, information security and local affiliates. Bringing them in at the scoping stage turns them from gatekeepers into co-designers. Their questions are usually reasonable and predictable; answering them upfront is far cheaper than rebuilding after a late review.

8. Where do people stay in the loop, and how is quality checked?

Decide which outputs a qualified person must review, what the tool may do on its own, and how you will measure accuracy before and after launch. For anything that reaches a clinician or patient, or that could involve safety information, human review and a clear audit trail are usually essential. Writing this down early also makes the conversation with reviewers much easier.

You are ready for step 5 when each review function has seen the scope, their conditions are written down, and human review points are defined.

Step 5

Plan for scale

9. Who owns it after the pilot?

Pilots often have an enthusiastic sponsor and a project team. Products need a business owner, a budget line, support arrangements, and someone responsible for keeping content, models and integrations current. If nobody is named to own the tool after the pilot, it will struggle to survive the first reorganisation or budget cycle.

10. What will it cost to run at scale, and will it fit how people work?

Running costs are easy to underestimate: model usage grows with volume and with how efficiently prompts and data are designed, and there are also costs for integration, monitoring, review time and updates. Equally important is fit: a tool that sits outside existing systems, or adds steps to a busy day, will be used less than planned. Scope for the workflow at scale, not only the pilot.

Your scope is ready to build when there is a named owner with a budget, a running cost estimate at scale, and a plan for how the tool fits existing workflows.

Review your scope: holds up or stalls?

Before you commit budget, check your scope against this table. Most stalled pilots show several of the patterns on the right.

How Jonda Health can help

Our team has seen this from several sides: from inside pharma medical and digital teams, as investors in digital health, and as builders who have scoped, shipped and rebuilt our own products, learning a few lessons the hard way. You do not need to have everything figured out before talking to us. There are two ways we can support you.