Four areas of responsibility to consider as AI use develops: translation, governance, scientific review and regulatory coordination. Getting these clear early saves pharma teams from confusion later, when a tool is in daily use and nobody is sure who owns a question about its output.
Start with responsibilities, then consider roles
AI can introduce new responsibilities around how work is designed, reviewed and supported. Some organisations may need dedicated roles; others may assign responsibilities across existing teams. The appropriate structure depends on the use cases, risks and capabilities involved.
The four functions below are a framework for discussion. They are not mandatory job titles, a forecast of hiring demand or a universal reporting structure.
Starting with responsibilities has a practical advantage. A job title can be agreed in a meeting, but a responsibility has to be described in terms of what someone actually does, what they decide and who they answer to. That level of description exposes gaps quickly. If nobody can say who will check that an AI-generated summary still reflects its source after the underlying model is updated, the gap exists whatever the organisation chart says.
A simple way to begin is to list the AI use cases that are live or planned, then ask the same questions of each one. Who defined the intended use? Who approved it? Who reviews outputs, and against what standard? Who decides when something has gone wrong, and who can pause the tool? The answers will rarely be identical across use cases, and that is useful information in itself.
Translate between business, scientific and technical teams
Someone needs to connect the intended use with the technical design. That involves explaining the workflow, understanding model limitations and helping teams test assumptions using language each function can understand.
An AI translator may be a dedicated role or a responsibility shared by experienced specialists. Its placement should support collaboration and access to the relevant decision-makers, rather than follow a fixed rule about IT or medical reporting lines.
Consider a medical information team that wants help drafting standard responses to frequently asked enquiries. The team knows which questions recur and what a good response looks like. The technical team knows how retrieval and drafting tools behave. Without someone bridging the two, the technical team may optimise for fluent text while the medical team cares most about traceability to approved sources. The translator’s job is to make that difference visible before build decisions are made, and to keep it visible during testing.
Good translation work tends to produce tangible outputs: a written description of the workflow, a set of representative test cases agreed by both sides, and a short list of known limitations that users will be told about. If those artefacts do not exist, the translation responsibility is probably not being met, regardless of who holds it.
Coordinate governance across the lifecycle
Assign responsibility for documentation, evaluation, change, monitoring and escalation. The person coordinating this work needs clear authority and access to business, technical, risk and other relevant specialists.
Coordination does not remove the accountability held by existing leaders or statutory roles. Record how decisions are made and who approves changes for each use case.
Lifecycle is the important word here. Much governance effort goes into approving a tool before launch, and much less into what happens afterwards. Models are updated, prompts are refined, data sources change and users find new ways to apply a tool. Each of these can alter how the system behaves. A governance coordinator should hold a register of AI use cases, know which changes require re-evaluation, and make sure monitoring results reach the people who can act on them.
A common pitfall is to place governance coordination with someone who has the knowledge but not the standing to stop or delay a release. If the coordinator cannot escalate effectively, governance becomes a record of decisions made elsewhere. Another is to design governance processes so heavy that teams route around them. Proportion matters: a low-risk internal drafting aid and a tool that informs decisions about patient safety information deserve different levels of control.
Provide appropriate scientific review
Where AI supports scientific or clinical work, suitably qualified people should assess the outputs and their limitations. Define the review scope, authority to challenge an output and escalation process.
Quality assurance, scientific review and technical evaluation can complement each other. Avoid treating one function as a substitute for the others or assuming a job title alone establishes competence.
Scientific review of AI output differs from reviewing a colleague’s draft in one important way: the errors can be harder to spot because the text often reads well. Reviewers benefit from knowing the typical failure modes of the tool they are checking, such as omitting qualifying statements, merging findings from different sources or overstating certainty. Briefing reviewers on these patterns, and giving them access to the sources the tool used, makes the review meaningful rather than cosmetic.
It also helps to agree what reviewers should record. A simple log of corrections made, and why, gives the governance coordinator evidence about whether the tool is performing as expected and gives the translator material for the next round of improvements.
Coordinate regulatory questions where relevant
Some projects need a clear contact to coordinate questions about intended use, documentation and the relevant regulatory requirements. This may sit within an established regulatory team rather than require a new liaison title.
The need for this responsibility varies widely. An internal tool that helps staff search policy documents may raise few regulatory questions. A tool that touches promotional material, pharmacovigilance or submission content will raise many, and the expectations set by GxP, data protection law such as GDPR and the EU AI Act may all be relevant depending on the use. The point is to have a named contact who knows when to bring in regulatory colleagues and who keeps the documentation they will want to see.
Questions leaders should ask
Before approving a new AI use case, a short set of questions can test whether responsibilities are in place:
- Who owns the intended use, and is it written down?
- Who reviews outputs, with what expertise and what authority to reject them?
- Who is told when the tool changes, and who decides whether it needs re-evaluation?
- Who can pause the tool, and how quickly can they do so?
If the answers depend on goodwill rather than agreed responsibility, the operating model needs more work before the tool scales.
Where to start
Map the responsibilities against your current and planned use cases before writing job descriptions. A structured readiness review, such as the approach set out in our AI readiness assessment framework, can show where ownership is clear and where it is assumed.
Glyz can help map responsibilities, workflows and capability needs with your teams through our AI and digital strategy services, and support the training and change work through our capability and change programmes. Confirm the proposed operating model and specialist requirements before creating job descriptions or starting recruitment.
