Economics, not regulation, is stalling AI in life sciences

AI has enormous potential in life sciences. Yet despite aggressive investment, many organizations are still struggling to scale it beyond isolated pilots. The usual explanation is regulation. In a high-stakes industry, compliance has become the default culprit whenever AI initiatives lose momentum.

However, many life sciences organizations moving fastest with AI aren't doing so despite rigorous compliance. If anything, embedding compliance from the very beginning of the development process has helped them achieve better outcomes from AI.

The real blocker is getting the economics to work. AI can make individual tasks faster, but that doesn't always translate into lower costs or better results. As AI use grows, organizations have to ask a harder question: are the gains worth what they're spending?

Regulation gets a bad rap, but the problem runs deeper

In McKinsey’s 2025 State of AI survey, 88% of respondents said their organizations were regularly using AI in at least one business function, up from 56% in 2021. That’s a remarkable jump in just four years, but it comes with a cost.

Following Anthropic and OpenAI’s lead, GitHub switched from a request-based pricing model to a usage-based pricing model on June 1, 2026. This has created sticker shock for some users as Copilot usage is now tied to the models and tokens they consume. For organizations scaling AI across teams, those costs can grow quickly as usage increases.

Like many companies across industries, life sciences organizations spent the first wave of enterprise AI driving adoption, often framed as a push for productivity, without worrying much about the bottom line. Usage-based pricing is changing that calculus. With 92% of healthcare and life sciences product leaders now facing growing pressure to demonstrate ROI, organizations are starting to connect AI investment much more deliberately to measurable business outcomes.

Prioritize AI based on business value, not productivity

Organizations often optimize the part of delivery that’s easiest to accelerate with AI while the real constraints appear somewhere else. For example, an engineering team might generate code substantially faster, while testing, validation, or release hardening still consume most of the delivery cycle.

Atlassian’s 2025 AI Collaboration Index reported that only 4% of executives saw transformational benefits from using AI. Software development illustrates the problem particularly well. CodeRabbit analyzed 470 GitHub pull requests and found roughly 1.7 times as many issues in AI-authored PRs as in human-written ones. The gap was particularly pronounced in areas that are costly to catch downstream. Logic and correctness errors were 75% more common, while security vulnerabilities appeared at up to 2.74 times the rate.

That is why, instead of the individual task, the unit of AI value should be the workflow. Start by baselining the end-to-end process and identifying where time and cost accumulate. In some organizations, the highest-value opportunity will be code generation. In others, it may be testing, regression, or another downstream constraint.

Quality is only part of the equation. The other is the cost of producing each output. Some workloads can support significant AI costs because the value of even a modest improvement is enormous. Consider two AI workloads with very different economic profiles.

1. A strong bet: AI-assisted drug discovery

Using compute-intensive models to screen millions of molecular structures can be expensive, but so is the process it improves. If AI eliminates dead-end experiments or identifies promising candidates earlier, the savings in laboratory work and development time can dwarf the inference bill.

2. An expensive bet: Using frontier models to process documents

Using large reasoning models to classify and summarize thousands of regulatory and clinical documents can also generate substantial inference costs. When much of the work involves routine extraction or classification, smaller models or conventional automation may deliver the same outcome at a fraction of the cost.

The most capable model is rarely the economically optimal model for every step of a workflow. Here’s a framework that we suggest using:

• High-value decisions: Spend on reasoning when a better answer materially changes the economics.
• Routine AI work: Move extraction, classification, and other predictable tasks to smaller, cheaper models.
• Deterministic work: If a rule or conventional automation can reliably do the job, use it and save the tokens.

Shift compliance all the way left

We have seen teams generate considerably more code without moving releases any faster because all of that additional output simply arrives sooner at the same downstream gates.

That’s why, instead of aiming to speed up compliance, teams should focus on shifting left. Shifting left essentially means translating regulatory requirements, security controls, and audit expectations into the same rules that govern your engineering workflows — catching issues early, before they become costly.

The standard is simple. If someone asks why a system is compliant, you should be able to trace the answer from the requirement to the control, to what is actually running in production.

Retrieval-augmented generation (RAG) is a good example of what this looks like in an AI product. An AI assistant answering questions from SOPs or clinical material can get surprisingly far in a pilot with people checking its answers. That approach gets expensive quickly at enterprise scale. A well-designed RAG system can ground the model in approved source material, allowing teams to trace an answer back to the evidence behind it. Evaluation frameworks such as RAG assessment can then validate whether the system retrieved the correct information and whether its answers remained faithful to that evidence as the product evolves.

This is where the economics of AI adoption become tangible. A compliance issue caught while an engineer is still working on the feature might take an afternoon to fix. Find the same issue after validation has started, and you can trigger another round of remediation, evidence gathering, review, and approval.

Treat AI adoption as a continuous learning program

We have always found AI adoption to be a slightly skewed phrase. It implies a one-time event that you achieve, much like organizations used to approach cloud migration. One day you were on-premises, the next, you were in the cloud.

But AI adoption doesn’t work like that. It’s more like building a muscle. Buying licenses is the equivalent of getting a gym membership. It is useful, but it won’t build capability unless you keep putting in the work.

This is a common problem across enterprise AI programs. Organizations can put AI tools in the hands of hundreds or thousands of people and still struggle with uneven adoption. They often have a limited understanding of where the tools add the most value, and no agreed way to measure success.

Effective AI adoption looks less like a software rollout and more like an operating model. Your teams need hands-on practice applying AI to real work. They need reusable context and workflows so every employee isn’t figuring out the same problems from scratch. Internal champions can then turn what works into repeatable practices across the organization, backed by reinforcement that continues well beyond the initial training. Instead of asking only how many people are using AI, organizations should be asking what changed in quality, effort, and cost.

In life sciences, that learning curve is especially important because there is such a wide range of work under the AI umbrella. A regulatory affairs team summarizing submission documents, a scientist synthesizing literature, and an engineer debugging code may all be using generative AI, but the right model, context, and level of human oversight can be completely different for each.

We have seen people throw an entire document library at a frontier model to answer a question that required three paragraphs of context. Others default to the most expensive model available because they assume more capable must mean better. At enterprise scale, habits like these can become expensive fast.

Teams need to learn how to design prompts and workflows around the task: how much context to provide, when a smaller model is sufficient, when deeper reasoning is worth paying for, and, importantly, when AI adds so little that it should stay out of the workflow altogether.

ROI rewards boring AI

Regulation gets blamed for stalled AI programs because it is the obstacle everyone can see. The ROI concerns tend to surface later, once the pilot becomes a product and thousands of seemingly inexpensive AI interactions start appearing on the same invoice.

Some of the strongest AI business cases we have seen in life sciences are surprisingly boring. Our work on EVERSANA’s MLR is a good example. Automating routine parts of an established review process helped reduce submission errors by 86% and review costs by roughly 35%. There is a clean line from what the AI does to where the business captures value.

This is ultimately what separates an AI pilot that works from an AI product that scales. A pilot only has to prove that the technology can solve the problem. Scaling is a litmus test where the economics of AI adoption become impossible to ignore, forcing you to prove that it can solve that problem repeatedly, under real-world compliance requirements, and at a cost the business can sustain.

If you’re working through these decisions yourself, we recently surveyed 119 healthcare and life sciences product leaders to understand where AI is delivering value, what’s holding organizations back, and what it takes to scale. Explore the full healthcare and life sciences AI report →

This article was developed with contributions from: Joel Gerbino, Director, Quality Engineering; Sean Clayton, Director, Security Engineering.