Solutioning AI in GxP: how to choose the route and prove it in phases

Still true as of September 27, 2026. Regulatory context is moving; check the dates on anything you act on. The steps below are the pattern I use and my recommendations, not regulatory requirements.

In the first post in this series I argued that the most valuable call when an AI idea is first proposed is often “not this one.” That post was about assessment: declare the value case (a baseline, a target, an owner and a check date, netted against the full lifecycle cost including validation), then sort the idea into one of four buckets: a process fix, light automation, rules, scripts or statistics without generative AI, or generative AI.

This post picks up where that one stops. An idea has passed the assessment, and someone now has to decide how to build or buy it and how to prove that it works. I call that step solutioning, and the method on its own, without the examples, is on the AI Solutioning Framework page. It is where good ideas quietly turn into expensive ones, because the route decides how the validation work is split between you and your suppliers, how much of it you carry for years, and whether the business actually uses what you deliver. No route changes who is accountable: that stays with you.

The pattern applies to AI in pharma whether or not the use is GxP. Where it is, the validation and change control steps below apply in full. Where it isn’t, your own system, privacy and risk policies set how much of that evidence you need.

Value and cost still come first. What changes is that the cost side gets concrete: you are comparing a vendor feature against a custom build, a pilot against a phased build, and a validation package you extend against one you write from scratch.

The seven steps

1. Bring the value case forward

Start with the value case from the assessment, not a new one. The baseline, targets, owner and check date carry over unchanged, so nobody can move the goalposts after an impressive vendor demo.

Add two things. The first is an adoption target. A tool that works but is not used delivers nothing, so write down who should use it, for what share of the eligible work, by when. For a drafting tool, that might be the share of eligible documents started from the AI draft, and the share of those drafts reviewers accept without a rewrite. The business owner sets these numbers with you, because they own the process that has to change.

The second is a lifecycle cost ceiling: the most you will spend over the life of the solution for the value you declared. It includes validation, periodic review and the change assessments that model, prompt or data changes will trigger, not only build and licenses. The phase gates in step 6 test against it. Without one, in my experience, a pilot that is going moderately well keeps absorbing budget.

2. Check what you already own

Before comparing new routes, look at the platforms you already run. Start from the new function’s intended use and the regulatory obligations that come with it, then ask whether an existing platform, such as a pharmacovigilance safety database, a promotional review (MLR) system, a CRM or an EDC, can support it as a feature, and whether that platform’s existing validation evidence still applies. Those four are not the same kind of system: a safety database or an EDC sits under GxP, while a commercial CRM or an MLR system sits under other rules and your own system policies, and may not be GxP at all.

Where the platform is validated for related use, in my experience extending it is often the cheapest route, because the supplier assessment, the infrastructure qualification and the core configuration testing are already done. You assess the change, test the new function against your intended use, and update the validation package. Price it anyway: integration work, supplier release changes and retesting can eat the saving, so compare actual lifecycle cost rather than assume it.

Two public examples. In a July 8, 2025 release carrying a quote from Boehringer Ingelheim’s head of patient safety and pharmacovigilance, ArisGlobal announced that Boehringer had gone live with generative AI for processing incoming safety cases on LifeSphere NavaX. The “up to 90% average data extraction accuracy” in that release is ArisGlobal’s figure. And per Veeva’s undated customer story (vendor-only, accessed September 27, 2026), Moderna was the first customer for Vault AI in PromoMats and chose it partly for easy implementation and minimal IT support.

The caveat is that “it’s already in the suite” is not the same as “it’s already validated.” A new AI feature is a change to the system, with its own intended use, risk assessment and testing. What you gain is reuse, not exemption.

3. Choose the route

If nothing you own covers the need, I compare four practical routes. They overlap: a partner co-build can run on cloud-hosted models, and a vendor product can sit inside a suite you own. I compare them first on how the validation work is divided, because that is the cost that lasts.

One thing doesn’t move between routes. Buying shifts work to the supplier, but the regulated company stays accountable for the intended use, for overseeing the supplier, and for the validation of the complete system as it is used. You can lean on a supplier’s evidence; you can’t hand over the accountability. The comparison below is my assessment, framed in GAMP 5 Second Edition’s component thinking, where each part of the solution sits somewhere on the category continuum rather than the whole system getting one label.

Buy a vendor feature or product

• You validate: intended use, configuration, integration and performance on your own data, plus supplier oversight.
• You can lean on the supplier for: product development, release testing, documentation for their releases.
• Watch: your change control has to keep up with their release cadence.

Configure an owned suite

• You validate: the change to the existing system and its intended use.
• You can lean on the supplier for: platform evidence you have already assessed.
• Watch: scope creep into functions the original validation never covered.

Build on cloud-hosted models

• You validate: the application, prompts, retrieval, integration and controls, as custom components.
• You can lean on the supplier for: hosting evidence you can assess, and whatever assurance the model provider offers.
• Watch: model version changes, deprecations and your own maintenance load.

Co-build with a partner

• You validate: the whole system you will own, plus the partner’s development practices.
• You can lean on the supplier for: build effort and development records during the engagement.
• Watch: knowledge transfer, and ownership of the validated state at handover.

Public examples cover each of the last two routes. Merck & Co. (MSD outside the US and Canada) reported in June 2025 that its internal, co-developed generative AI platform for clinical study reports cut the time to a fully human-reviewed first draft from an average of 180 hours to 80, with qualified medical writers overseeing every draft. Per Anthropic’s undated customer story (vendor-only), Novo Nordisk’s NovoScribe documentation platform is built on Amazon Bedrock and MongoDB Atlas with Claude models. The same company’s staff, writing as MSD, co-wrote an AWS blog post (November 20, 2025) on an exploratory deviation-investigation search tool built on Amazon Bedrock and OpenSearch; the post says the design mostly limits generative AI content creation to low-risk areas with human oversight. For a partner co-build, Formation Bio, OpenAI and Sanofi introduced Muse in November 2024, a patient-recruitment tool developed jointly on OpenAI models. At announcement, Sanofi planned to lead its initial deployment in Phase 3 multiple sclerosis studies.

None of these tells you which route is right for your idea. They show that capable companies choose different routes for different jobs, and that the choice is a real decision, not a default.

4. Design it with the business

Whatever the route, I recommend the pattern from the first post: rules for what must be exact, AI for the language, a person for the decision. Build a deterministic backbone for data pulls, calculations, checks and routing. Put generative AI only on the narrow step where the input or output is language. Place the human at the decision point, with the authority and the time to decide. For drafting workflows like the ones in this series, my recommendation is simple: the AI drafts and an accountable, appropriately trained person decides. Other AI uses need oversight designed for their own context and risk, and a human signature on its own doesn’t make an output acceptable.

This is also where adoption gets designed in rather than hoped for. The business owner co-designs the workflow with you: where the draft appears, what the reviewer sees next to it, and what happens when the draft is wrong. Process redesign belongs in the plan from the start, and so do the pieces that follow from it: updated SOPs and work instructions, role-based training, and change control for the process as well as the system. Leave those for after go-live and the tool arrives into a process that was never changed to use it. BCG’s January 2026 piece makes a related point with its 10/20/70 heuristic: 10 percent of the challenge is the algorithms, 20 percent the data and technology, and 70 percent people and processes.

5. Plan the less visible controls

Four controls matter for AI solutions. In my experience, public case studies say least about them, so you will have few examples to copy.

The governance layer between staff and models. Something should sit between your people and the model endpoints to handle identity, approved models, logging, cost attribution and policy. Two public examples, as of September 2026. Pfizer describes AAIP on the public landing page of its developer platform (undated, accessed September 27, 2026) as a centrally managed, OpenAI-compatible gateway to approved OpenAI, Anthropic, Google and Azure AI Foundry models, with request tracing, cost attribution and audit logs. That is self-reported, and the documentation behind the page is internal, so I couldn’t verify it further. Takeda and ZS, in a June 16, 2026 presentation at Databricks Data + AI Summit, described Takeda’s self-service AI foundation with a control tower covering policy, audit and lineage, and risk and compliance, plus continuous monitoring that includes a policy-enforcing “police agent,” a kill switch and human review for high-risk actions. Neither disclosure says anything about GxP use or validation, and two examples don’t tell you how common this layer is across pharma.

Suppliers you may not be able to audit. GAMP-style supplier assessment assumes you can assess the supplier. With a foundation model behind a cloud API, don’t assume you can audit the model developer the way you would audit a software vendor; what you can get varies by provider and contract. EMA put this question to experts at its June/July 2026 Annex 22 workshop: how supplier qualification, change-control visibility and independent audit can be preserved in cloud-based AI supply chains. It is an open question, not an approved answer. My recommendation is to map what assurance is actually available across the chain (the hosting provider, the model provider and the contract), name the gaps and the residual risk, and then decide. Output verification, contract terms and a person at the decision reduce the risk, but they don’t automatically close an assurance gap. Where adequate assurance can’t be established, restrict the use to work where the residual risk is acceptable, or reject it.

Model version change control. A model upgrade is a change to your system, even when the vendor makes it on their timeline, and so is a change to prompts, retrieval, source data, configuration or intended use. Pin model versions where the platform allows it, keep a regression test set from your development cases, and treat each change as a change record with an impact assessment, then run the verification it justifies. That is not automatically a full revalidation, and it shouldn’t be skipped either.

Performance monitoring. The FDA and EMA principles call for scheduled monitoring and periodic re-evaluation. In practice I monitor three things after go-live: sampled output accuracy against the acceptance criteria, reviewer edit rates, and usage. In my experience, a falling usage rate is often the earliest signal that something is wrong, in the workflow, the usability or the output. I treat it as a reason to investigate alongside the direct quality measures, not as proof of drift. Monitoring is the defensive half of life after go-live. The other half, deliberately improving the tool under GxP change control, gets its own post later in this series.

6. Prove it in phases

This is the step I care about most. Don’t approve the whole solution at once. Approve the first phase, and make every later phase earn its funding at a gate.

For builds, go slice by slice. Take one narrow, valuable piece and prove it before adding the next. For a medical writing tool, that could be one section type, such as safety narratives, tested on representative historical cases. An approved historical document isn’t automatically the right answer, so have an expert adjudicate the references first. Keep the cases the team develops against as your regression set, and hold back independent cases nobody tuned on for the final performance check. The next slice might be a second section type, or the same section type for a new therapeutic area.

For buys, run a paid pilot. My preference is a contracted, paid pilot with explicit deliverables, responsibilities, success criteria and an exit clause, all agreed before it starts. Test on your own documents, not on the vendor’s demo set. A demo shows what the product does at its best; your documents show what it does with your templates, your data quality and your edge cases.

The business owner co-designs both: which slice goes first, which documents go in the test set, and what “good enough to use” means to the people who will use it.

At each gate, check quality first, then four business things, and make one of three calls. Quality comes first: did the phase meet its quality and risk criteria, measured on the held-out cases, with the error types and residual risk understood? If not, the call is adjust or stop, whatever the business numbers say. Then check the value metrics against the baseline. Check real usage: are representative users working with it at the rate the adoption target assumed? Pilot participation is only a leading indicator; adoption has to be confirmed again after rollout. Check reviewer burden: how long a review takes and how much reviewers edit, because a draft that saves the author an hour and costs the reviewer two is a net loss. And check cost to date against the ceiling. A gate that checks only accuracy will pass tools nobody uses; a gate that skips quality will pass tools nobody should rely on. Then decide: expand to the next slice or a wider pilot, adjust and rerun the phase, or stop.

If the use is GxP. I recommend running pilots segregated from production, on data you are authorized to use, appropriately protected and representative of the real work. Keep pilot outputs as test evidence, but nothing operational relies on them, no GxP record and no GxP decision, until validation and release cover the intended use.

Phase evidence can feed the validation package, but only if you plan it that way with Quality from the start. Agree up front which evidence you intend to reuse, keep the methods, acceptance criteria, configurations, results and deviations traceable, and justify what carries over and what must be repeated. Pilot results don’t become qualification evidence by default. Done that way, in my experience phasing lowers validation cost as well as project risk: you build evidence in the order you need it, and stop paying for it on slices that don’t earn their place.

7. Final gate: scale it, or say “not this one”

Before scaling, recheck the total lifecycle cost with what the phases taught you: integration, licenses, human review time, maintenance, the change assessments and verification that model, prompt, retrieval, data, configuration or intended-use changes will trigger, and eventual retirement. Then check the exit plan. If the AI lives inside a vendor platform, confirm how regulated records and their audit trails come out in a usable form if you leave.

If the numbers still work, scale it: complete the validation for the intended use, roll out with the updated SOPs and training, keep monitoring, and confirm adoption against the target after rollout, not just in the pilot. If they don’t, the call is “not this one,” the same call the first post argued for, now made with evidence.

One rule holds throughout. ROI decides whether to do the AI project. It never decides whether required quality work gets done. If a deviation backlog or an overdue review is a compliance obligation, and the AI route loses at the gate, the obligation remains and still needs a properly resourced solution, whether that is a process fix, a deterministic tool or more people.

Why a solutioning pattern is needed

The guidance we work with tells you how much assurance a solution needs, and it can inform which components you choose. It doesn’t give you a practical method for comparing delivery routes, lifecycle cost and phased investment.

GAMP 5 Second Edition (ISPE, July 2022) scales life-cycle activities to risk, complexity and novelty, and applies software categories to the components of a system rather than to the whole system. As Karen Ashworth explains in Pharmaceutical Engineering (January/February 2026), the categories sit on a continuum, whole-system categorization is recommended mainly for scaling supplier assessment, and reusing a configuration that is already tested and proven in use can justify reduced verification. She also notes that critical thinking in the planning phase can help select the most appropriate solution. The ISPE GAMP Guide: Artificial Intelligence (released July 29, 2025) extends that thinking to AI-enabled systems. It is paywalled, so I will only describe it: per ISPE, it builds on GAMP 5 Second Edition and the GAMP data integrity guides and offers a holistic framework for developing and using AI in GxP-regulated areas.

For risk language beyond GxP, the NIST AI Risk Management Framework 1.0 (January 2023) and its Generative AI Profile, NIST AI 600-1 (July 2024) are useful. The profile names risks such as confabulation and “value chain and component integration,” which is the risk you take on when a third-party model sits inside your system. The FDA and EMA Guiding Principles of Good AI Practice in Drug Development (January 14, 2026) add ten shared principles, including proportionate validation based on context of use, performance assessment of the complete system “including human-AI interactions,” and scheduled monitoring over the life cycle.

Two regulatory notes, with dates. FDA’s Computer Software Assurance guidance was finalized on September 24, 2025 and replaced in February 2026 by a version aligned to the device Quality Management System Regulation. It gives nonbinding recommendations, and its scope is medical device production and quality management system software. I borrow its risk-based method (intended use, then risk, then proportionate assurance), but applying it to pharmaceutical systems doesn’t replace the drug GMP requirements that apply. In the EU, when I checked EudraLex Volume 4 on September 27, 2026, it still listed Annex 11 at its January 2011 revision and had no Annex 22. The draft Annex 22 on AI and the revised Annex 11 went to consultation from July 7 to October 7, 2025, EMA held an expert workshop on June 30 and July 1, 2026 to reconsider how generative AI should be treated, and the inspectors working group’s 2026 to 2028 work plan targets Q4 2026 for giving the Commission a final text. That is a working-group target, not an adoption date. The 2011 Annex 11 applies today, and the drafts are planning input.

The consulting frameworks I looked at come at it from a different angle. McKinsey’s taker, shaper and maker archetypes (2023) are a sourcing model: use a model as is, shape it with your data and systems, or build your own. BCG’s “The AI-First Biopharma Company” (January 2, 2026) describes stages of change, deploy, reshape and invent, rather than a build-versus-buy choice. Neither piece compares sourcing options by validation effort, supplier auditability or the work a model change triggers. That gap, together with a method for comparing routes, cost and phased investment, is what this post adds.

What comes next in this series

This series follows an AI idea in the order a decision-maker meets it. After assessment and solutioning comes the AI Adoption and Improvement Framework, written from the business owner’s side. It covers what it takes for the people whose process changes to take the tool on, and how to keep improving the tool after go-live, measured against the value-case baseline and kept cheap under change control. After that come breakdowns of common pharma AI solutions, each using the seven steps above for its solutioning part.

If you take one thing into your next project review, make it the phase gate. Ask what the first slice is, what the gate checks, and what number would make you stop. If the answers include usage and reviewer burden alongside accuracy and cost, the project has a real chance of being used.

Sources checked September 27, 2026. Regulatory context is moving. Rulings and recommendations are the author’s assessments.

Related reading: when full agentic workflows are worth it.

---

Want to choose the route for your GxP AI project? That is the work I do.