There is a specific pattern emerging across the pharmaceutical industry.
Functional leaders in regulatory affairs, medical affairs, commercial, and market access have now seen enough AI demonstrations to understand what is possible. They have watched an agent draft a literature summary in a few minutes. They have seen AI support medical information triage, assemble competitive landscapes and pre-populate sections of regulatory submissions.
In many cases, the use case is clear. Leadership is interested. Budget may even be available. Yet progress often stalls.
In some cases, activity moves forward outside the appropriate validated environment, beyond established data governance boundaries, and without the level of security oversight a CISO would require.
A senior manager may be using an external LLM with sensitive clinical content (shadow AI). A medical affairs associate may have built a useful workflow in a personal workspace that cannot move into production. A vendor may be engaged for a pilot, only for the initiative to become delayed in procurement, security, and compliance review for months.
This is the gap worth addressing.
It is no longer primarily the gap between awareness and understanding of AI. In many organizations, that gap has already narrowed. The more pressing issue is the gap between identifying what an AI agent could do for a specific function and deploying a working, compliant agent inside the company’s own environment, using its own data, and governed by its own controls.
That is where many pharmaceutical teams remain stuck.
And often, they are not stuck for the reasons people assume.
The Compliance Story You’ve Been Told Is Incomplete
The dominant narrative in our industry is that the blocker is regulatory. GxP. GDPR. HIPAA. 21 CFR Part 11. Annex 11. EU AI Act. The reason we cannot move, the story goes, is that compliance simply will not allow it yet.
That story is comforting because it locates the problem outside the team. But it is mostly wrong and I say that as someone who has spent considerable time inside the rooms where these decisions actually get made.
Compliance is not the wall. Compliance is the terrain.
The teams making progress have not found regulatory loopholes. They have learned how to design AI systems that work within existing compliance, quality, security, and governance structures.
They understand which agent architectures produce auditable outputs. They know which data flows remain within validated boundaries. They are clear on where an agent may support a decision versus where a human must retain decision-making authority. They also scope initial implementations so they fit within existing SOPs rather than requiring entirely new governance models before any value can be delivered.
That last point is the one most teams miss. Almost every failed pharma AI pilot I have reviewed in the past two years attempts to introduce a solution that depends on a new governance framework being created first.
The successful ones tend to identify the structures that already exist – controlled vocabularies, document control systems, change management procedures, audit trail conventions, quality review processes, and security controls that have been refined over many years.
The agent is then designed to operate within those structures from the outset.
For teams new to this work, the instinct is often to ask:
What needs to be put in place so AI can be allowed in?
A more effective question is:
What does the existing compliant environment already require, and what kind of AI agent can satisfy those requirements by design?
What an AI Agent Actually Means in Pharma
Before going further, it is important to address a source of confusion that is slowing many teams down: the word “agent.”
Right now, the term is being used broadly and often inconsistently. In some conversations, an agent is described as a chatbot when it is not a chatbot. In others, it is presented as a single AI model response, or a workflow automation. This ambiguity creates confusion and makes it harder for pharma teams to evaluate what is actually being proposed.
When we refer to an AI agent in pharma, we mean a bounded system that combines a model, approved tools, controlled access to information, memory where appropriate, guardrails, and a clearly defined scope of action. Its purpose is to complete a specific multi-step task within a function, while ensuring that the right activities are logged, the right exceptions are escalated, and the right actions remain subject to human review or approval.
This distinction matters.
An AI agent depends on how well the workflow has been scoped, governed, and controlled.
That is where pharma organizations have a meaningful advantage.
Pharma teams already understand the discipline of scope. Standard operating procedures define scope. RACI models define scope. Role-based access controls define scope. Review and approval workflows define scope. Escalation pathways define scope. Across the industry, teams are already accustomed to defining what a person or function is authorized to do, what evidence must be produced, what decisions require review, and what must happen when uncertainty or risk increases.
This same discipline is highly relevant to AI agent design.
A well-designed pharma agent should be treated less like an open-ended LLM and more like a digital colleague operating under an SOP. It should have a defined job description, approved sources of information, clear evidence requirements, decision boundaries, escalation rules, and an audit trail.
If a team can clearly describe how a human should perform a task within a regulated workflow, that team is already much closer to specifying an AI agent that can be responsibly designed and implemented.
However, if the workflow cannot be clearly described, if ownership is unclear, if escalation rules are vague, or if evidence requirements are not defined, then even the most advanced model will struggle to deliver reliable value.
This applies across pharma functions.
In regulatory affairs, an agent supporting labelling change review must operate within defined source documents, approved comparison rules, review requirements, and escalation criteria and human verification.
In medical affairs, an agent supporting medical information response preparation must draw from approved reference materials, adhere to standard response templates, apply defined accuracy and balance checks, and route inquiries for appropriate medical review before dissemination.
In market access, an agent supporting payer dossier preparation must work from validated evidence sources, maintain traceability, structure information appropriately, and ensure expert review before use.
In marketing, an agent supporting promotional content development must operate within approved claims libraries, follow established branding and messaging guidelines, apply mandated fair balance and disclosure rules, and ensure medical, legal, and regulatory (MLR) review before release.
For pharma companies and biotech, the opportunity is not to deploy vague “AI assistants” into complex regulated workflows. The opportunity is to define focused, governed agents that can perform specific tasks with clarity, control, and accountability.
That is where real value begins.
Where Teams Actually Get Stuck
In my experience, there are four stuck points, and they are not the ones people expect.
1. Translating the use case into scope
“An agent for medical information” is not a scope. It is a category.
A buildable scope might be:
An agent that retrieves approved internal training materials for new MSL hires in a specific therapeutic area, drafts onboarding summaries using only those materials, flags any content gaps or outdated references for human review, and produces a record that fits the existing learning management system and downstream competency tracking process.
Or, an agent that retrieves approved scientific platform documents for internal congress planning in a specific therapeutic area, drafts briefing materials using only those documents, flags anything that requires updated data or strategic alignment for human review, and produces a record that fits the existing congress planning system and downstream medical team readout process and human verification.
That is the difference between an aspiration and a buildable agent.
2. Mapping data permissions
There are three separate questions:
● What data is the agent allowed to see?
● What data is the agent allowed to act on?
● What data is the agent allowed to produce?
These are not always governed by the same owners.
The teams that move faster map this early and design the agent around the existing permission structure instead of trying to renegotiate it later.
3. Designing decision boundaries
“Human in the loop” is not enough. It is the baseline.
The mature question is:
● What can the agent do autonomously?
● What can it propose for confirmation?
● What must it escalate?
● What must it refuse?
This decision boundary is one of the biggest determinants of whether an agent survives a compliance review.
4. Defining evaluation and evidence
A demo is not enough. You need to know how the agent will be evaluated, what acceptance criteria it must meet, how drift will be monitored, what evidence will be produced, and what review cadence your QA function will recognize.
This is where many pilots die.
They work in a demo. They work in User Acceptance Testing. Then they reach production without the instrumentation needed to maintain confidence.
The model matters. The framework matters.
But these four capabilities matter more:
● Scope translation
● Data permission mapping
● Decision boundary design
● Ongoing evaluation
Why Build Capability Belongs Inside Your Team
Given everything discussed so far, there is a strong temptation to hand the challenge entirely to an external partner and wait for them to deliver a solution. External partners absolutely have an important role to play. There are categories of work – particularly at enterprise scale and in systems intended for GxP-validated environments – where specialist engineering expertise is essential
However, the more important question is what changes when the capability to scope, build, and deploy agents exists inside your function rather than outside it.
The functional leaders who have moved ahead over the last 18 months tend to share one characteristic: they do not wait. When a use case emerges within their team – a recurring bottleneck in dossier preparation, a delay in medical review, or a market access analysis that routinely takes three weeks when it should take three days – they can scope the problem, stand up a working agent within their environment in days rather than quarters, validate it against the controls already required in their setting and begin generating value before the equivalent vendor-led pilot has passed its first procurement gate.
This is not because they have sacrificed rigour. It is because they have reduced the distance between the person who understands the problem and the person who can shape the solution. When those individuals are the same person, or at least sit within the same team and speak the same operational language, cycle time decreases dramatically, and the quality of fit improves. Requirements documents rarely survive the journey from functional lead to external engineer without losing the detail that ultimately determines whether a solution will work in practice.
Another important shift is one of volume. A function that can build its own agents does not stop at one. It builds the most obvious agent first, learns from the experience, develops several more, retires one that does not justify its place, improves the ones that do, and within a year may have a portfolio of small, well-scoped, compliant agents handling the unglamorous but high-volume work that previously consumed senior team bandwidth. I personally have many.
That kind of portfolio is very difficult to assemble through external builds alone. Each new solution would require its own business case, procurement cycle, and validation effort. Internally, once the team has developed the literacy, operating patterns, and governance approach, the marginal cost of building the next agent becomes low enough to justify solving problems that would never have warranted a vendor engagement.
That is the real opportunity is not one impressive agent, but the ability to produce compliant agents on demand, at the speed your function actually operates. It really is a simple thing to do and once you learn to do it easily and compliantly, you will be up and running.
The encouraging reality is that the level of technical understanding required to lead this work from within a functional role is far lower than many people assume. But it is not zero, and the part that is not zero is non-negotiable in our highly private and regulated environment.
Functional leaders need to know enough to scope correctly, define decision boundaries that reflect real model behaviour, understand what their environment will and will not tolerate, and design evaluations that produce evidence acceptable to QA and other oversight functions.
That literacy is what separates the leaders who are quietly building useful agents now from those who will still be discussing pilots in 2027.
The teams that develop this capability over the next twelve months will shape what their functions look like for the next decade. The teams that delay will likely find those decisions made for them by others.
Conclusion
Most pharma teams do not get stuck because they lack AI ideas.
They get stuck because the use case never becomes buildable.
“Medical information agent” sounds directionally right. But it is still too broad to govern, test, or deploy. Until the workflow is narrowed, the inputs are defined, the controls are set, and the operating context is clear, the team does not have an agent. They have a concept.
That distinction matters.
Because the organisations that move first will not be the ones with the longest list of AI ambitions. They will be the ones that can take one real workflow, scope it properly, and turn it into something usable inside the constraints of a pharma environment.
That is the capability gap now.
Found this article interesting?
Ps. If your team can already see where an agent could reduce friction, improve response quality, or support a critical workflow, the next question is straightforward: can you turn that use case into a working, compliant agent inside your own environment?
I am creating a 4 week (one hour a week) working hands-on intensive with a small group of pharma functional leaders to do exactly that. We will take each person’s real use case/s, scope them properly, and build working Copilot agents around them within the bounds of their compliance and security.
No code. No generic demos. They will be building real agents built for their own real workflows in their own compliant systems.
If you want the details, email me with subject line ‘PHARMA AGENT.’
For more information, contact Dr Andree Bates abates@eularis.com.