The new pharma roles being created by AI.

Most career-trend content focuses on individuals chasing emerging roles. The harder question is the organisational one: which new roles need to exist inside pharma to make AI work — and how should they be designed, where should they sit, and what authority should they hold.

Career-trend content about AI mostly addresses individuals: which jobs to chase, which skills to add, which titles will be hot in five years. That framing is fine for individuals, but it is the wrong question for an organisation. The organisational question — the one that decides whether an AI programme scales successfully or stalls in pilot — is which new roles need to exist inside the company, where they should sit, and what authority they should hold.

Across our pharma engagements, four new roles emerge as standard inside twenty-four months of an AI programme reaching production. Fewer than twenty per cent of pharma organisations have formally defined any of them today. The lead time being lost is roughly six months — the period between recognising the need for a role and having a credible incumbent sitting in the seat doing the work.

Three of these new roles are particularly distinctive, and each is being misread in a predictable way. They are not data science roles. They are not IT roles. They are not QC roles. Reading them as any of those is the design mistake that stops most pharma AI programmes from scaling.

THE THREE POINTSWhat this post unpacks

POINT ONEThe AI Translator — why this is not a data science role

The first role is the AI Translator. The vague version of this role is that the organisation needs more data scientists, or should hire more ML engineers, or that the tech team will handle AI. The specific version is that the AI Translator is neither a data scientist nor a tech person — they are the bridge between clinical logic and model logic, and they sit between functions, not above them.

An AI Translator can articulate, in clinical terms, what a model is actually doing and where its limitations are. They can also articulate, in technical terms, what the clinical workflow actually requires. They are senior enough to be heard in both rooms, and they have no incentive to side with either. The role typically reports into clinical or medical leadership, not into IT. Placing it inside IT is the single most common organisational error in early-stage pharma AI programmes.

POINT TWOThe Model Governance Lead — why this is not an IT role

The second role is the Model Governance Lead. The vague version is that IT governs the models, that the risk team approves AI use, or that the vendor manages model performance. The specific version is that the Model Governance Lead owns the model lifecycle end to end — from data lineage at training through to performance drift in production — and they report to clinical or medical leadership, with a dotted line to risk.

This role defines decision rights and escalation paths for AI-influenced decisions. When an AI output triggers a regulated decision, the Model Governance Lead is the person accountable for whether that output should have been trusted, what the audit trail looks like, and what the escalation path was if it should not have been. This is not paperwork. It is a structural accountability that has to sit somewhere, and if it does not sit in a defined role, it sits nowhere — which is the regulatory exposure most pharma organisations are running today.

POINT THREEThe Clinical AI Reviewer — why this is not a QC role

The third role is the Clinical AI Reviewer. The vague version is that AI outputs get spot-checked, that someone reviews the edge cases, or that QC will handle validation. The specific version is that the Clinical AI Reviewer is an independent scientific role with the authority to override the model, and the career-grade scientific seniority to make that override credible.

QC is the wrong frame for this role. QC implies sampling. The Clinical AI Reviewer is not sampling — they are providing scientific judgement on the cases where the model's output materially affects a clinical or regulatory decision. The role requires the same seniority as a senior clinical scientist or senior regulatory scientist. Pharma organisations that under-grade this role find that the reviews are not credible to regulators or to internal scientific governance, which means the AI programme cannot scale into the decision-grade workflows that justify its investment.

THE SEQUENCEHow to act on this

Designing these roles is not difficult. The mistake is treating it as a job-description exercise. It is an operating-model exercise, and the sequence that works has four steps.

Hiring against these roles is the hardest part. The market for senior scientists who can also operate inside an AI programme is shallow. The organisations that win these hires are the ones that can describe the role credibly, place it on the right reporting line, and offer the career path. Posting the role into a generic AI hiring queue produces the wrong applicants and the wrong outcomes.

WHY THIS MATTERSThe bigger picture

These roles are not optional and they are not new in name only. They carry real authority — to escalate, to override, to slow down — and they report into clinical and medical leadership, not into IT. Pharma organisations that put these roles inside IT, or under-grade them, will watch their AI programmes stall in exactly the same pilot trap that stops most pharma AI today.

There is a fourth role that completes the set — the Regulator-AI Liaison — but it deserves its own treatment, and we will cover it separately. Together, these four roles form the operating-model spine for any pharma organisation running AI in decision-grade workflows. Without them, AI programmes hit a ceiling at the boundary between technical capability and clinical authority, which is exactly the boundary regulators care about most.

Glyz designs these roles, places them in pharma operating models, and supports client search teams in hiring against them. If you are thinking about which roles your AI programme needs to formalise — or whether the roles you have today are configured correctly — this is the work we do.