Vendor-agnostic AI in biopharma: seven layers, not one router

Picture the meeting. Somebody has drawn a box labelled "model layer" with four logos underneath it, and the slide says the company is now vendor-agnostic. It is a good slide. It is also a claim about one component in a system that has seven, and it is a claim about the component that was already the easiest to replace.

Here is the test. Suppose your preferred model disappeared tomorrow. Not degraded, not repriced, gone. How long until the work it was doing runs somewhere else at a quality you can defend to an inspector? For most organisations the honest answer is months, and none of those months are spent changing the endpoint. They are spent rewriting prompts that were tuned to one model, rebuilding a search index that a different embedding model created, reconstructing an audit trail that lived in a vendor console, and above all proving the replacement is good enough, which nobody can do because nobody wrote down what good enough was.

The order below is not a stack diagram. It is a cost ordering, and it runs the opposite way to where budget usually goes. The bottom of the list is where switching is expensive and where the leverage sits. The top is where the architecture conversation happens.

Expand

Switching costs are our own estimates from working with regulated teams, not measured figures. The ordering is the argument; the durations are illustrative.

Each layer below constrains the one above it. The data layer decides which models are even eligible. The substrate decides which of those you can lawfully and reliably reach. Orchestration decides how much work a swap actually is. Validation decides whether a swap is defensible, and pricing decides whether it is worth making. A router with none of the other six is not vendor-agnostic. It is vendor-indifferent, which is a different thing and a worse one.

Most published versions of this idea stop at four: data, model, evaluation, cost. Having watched where regulated programmes actually get stuck, we think three more belong on the map. Each one is a place where you can hold every other layer constant and still find you cannot move.

Substrate: two vendors, one building

The substrate is the physical and legal ground the inference stands on. Whose hardware, in which jurisdiction, under whose export rules. It is not the model layer, because a model is a file and a substrate is a building, and the same model can run in several of them.

This matters because the standard mitigation, a second supplier, does not necessarily buy a second substrate. Model vendors rent compute from a small number of providers and none of them expose which one is serving your request. You can hold a contract with two companies and a dependency on one data centre, and you will not find out until the day both go quiet together.

Orchestration: the layer that quietly does not move

Between your data and your model sits the part nobody photographs: the prompts, the tool schemas, the retrieval logic, the chunking, and the embedding model that built your vector index. This is where the actual coupling lives.

A prompt is not portable. It is a set of instructions tuned, usually by trial and error, to the quirks of one model, and the same words produce different behaviour elsewhere. Tool schemas differ by provider. And embeddings are worse than prompts, because changing the embedding model does not degrade your search, it invalidates it: the vectors in your index and the vectors in your new query are no longer in the same space, so the whole corpus has to be re-embedded before anything works at all. None of that is visible from a gateway dashboard, which is exactly why it survives the architecture review.

Oversight: the audit trail belongs to the vendor

In a regulated setting somebody has to be accountable for an output, and you have to be able to reconstruct how it was produced. That is a distinct concern from validation. Validation asks whether the model is good enough. Oversight asks who signed, what they saw, and whether the record survives an inspection two years from now.

It is a lock-in surface because the record usually lives in the supplier's console, in the supplier's schema, with the supplier's retention policy. Move vendor and the history does not come with you. We have written more about where the human belongs in that loop in where to put the human checkpoint and about the attributability requirements themselves in validating a non-deterministic agent under GxP.

The clearest published example of the data layer doing the choosing comes from French pharmacovigilance. The national medicines agency, the Bordeaux pharmacovigilance centre and a software company took more than eleven thousand adverse drug reaction reports that patients had filed in their own words, and which the regional centres had already coded by hand, and trained models to do the first pass.

There were two jobs. One was to read the free text and say what the reaction was. The other was to say whether it was serious, which depends on the patient as much as the event: age, sex, outcome. The team tried an end-to-end transformer for the seriousness job and set it aside, on the judgement that seriousness leans on structured fields a transformer cannot take directly. So they kept a language model, but only to turn the text into numbers, and handed those numbers plus the structured fields to a gradient-boosted classifier. Worth being precise here, because it is easy to over-read: they did not abandon transformers, they demoted one to a component, and they report no score for the version they dropped.

Read that as a rule rather than a detail. Where judgment depends on structured context, your data layer has already narrowed the model layer to architectures it can feed. No amount of frontier capability changes it, because it is an interface problem, not an intelligence one.

The second thing the data layer did was make the models comparable at all. Because the required output was a code from a controlled medical vocabulary rather than a paragraph of prose, two completely unrelated approaches could be scored against the same answer key.

Internal and external validation, rounded. The paper's own conclusion is that neither approach outweighed the other, and it notes separately that the gradient-boosted models are lighter and quicker to run. The national deployment dates from January 2021, which is before this validation study's data even ends, so read the sequence as our framing rather than a causal claim the authors make.

That is four layers doing their jobs in sequence. The data layer normalised the output so a comparison was possible. The validation layer established that the two were equivalent. The pricing layer broke the tie on operating cost. The model layer did what it was told.

And then the data layer moved under it. When coding rules changed during the COVID-19 vaccine campaign, so that a cluster of symptoms was to be recorded under a single preferred term rather than the separate terms the models would suggest, the authors noted the mismatch and said they planned to deal with it through online learning. No model changed. A vocabulary did, and that was enough to put the system out of step with the people using it. If you want a longer treatment of why that failure mode is so common, we wrote one in identifier hell and ontology mapping.

The tempting shortcut is one global router pointed at whichever model is winning this month. The largest published evaluation of language models on medical work argues against it, and the reason is not the one people expect.

Across nine models and thirty-seven benchmarks, the spread between categories of work was consistently wider than the spread between models doing the same work. Note generation and patient communication sat high for everyone. Administrative and workflow tasks sat low for everyone. A model that led one category could sit near the bottom of another.

The authors' own explanation is a data-layer explanation: administrative workflows lean on data the models never saw in training. So the fix for a weak score there is a better data layer, not a better model, and a global ranking cannot see that. It optimises the smaller variance and ignores the larger one. Our piece on why agents disagree covers the related trap of treating one aggregate score as if it described every question you will ask.

This is the finding that reorders the whole economic argument, and it is sitting in a benchmark appendix.

When that evaluation priced its own work, it separated the cost of running the medical task from the cost of judging the answers. For the cheapest model tested, judging cost nearly twenty times what running the task did. The inference was pocket change. The assessment was the budget.

Shape rather than precise figures, because the published numbers are upper-bound estimates on 2025 list prices and have moved since. The exact table is in the source.

Follow that through to a pricing layer. If your switch logic reads inference cost alone, moving to a cheaper model looks like an enormous saving. Include the cost of proving the cheaper model is good enough and most of the saving disappears. Include your own re-qualification against a labelled hold-out set, which a regulated switch requires and a benchmark never has to pay for, and you may find the switch costs more than it saves.

Which gives the pricing layer its actual job. It is not there to find the cheapest tokens. It is there to answer one question: at the quality bar we have written down, does this change save more than it costs to prove.

Two things happened in 2026, twelve weeks apart, that between them dispose of both the naive position and the naive fix.

One vendor, removed by law

Two newly released frontier models were withdrawn within days in June 2026, after the US Commerce Department told the vendor that supplying them to any foreign person, anywhere, now required an export licence. That included the vendor's own staff. Citizenship cannot be checked over the internet, so the only compliant response was to switch the models off for everyone, and that is what happened. Note the mechanism, because it is not the one people describe: nobody ordered a shutdown. A licence requirement made continued service non-compliant, and the shutdown was the vendor's own way of complying. Three weeks later one model returned worldwide. The other came back only for an approved set of US organisations.

What makes this a substrate problem rather than a model problem is the scope. It was written around nationality, not geography. A European region does not help. A European legal entity does not help. A second model from the same vendor does not help. A service level agreement certainly does not help. None of the mitigations a procurement team believes it holds are aimed at this.

Three vendors, one data centre

Then, in September, three major providers had availability problems inside about ninety minutes of each other. The obvious suspects were clear: the big clouds reported nothing relevant and the usual network layer said it was fine. Afterwards a compute supplier apologised for an outage at one of its sites, and separately to its affected compute partners.

The commercial relationship here is not a secret: that compute supplier publicly announced a capacity agreement with one of the affected model vendors earlier in 2026, and the site in question is the one it named. What nobody has published is a post-incident report naming a shared cause, and we are not asserting one. The supplier runs more than one facility in that city, so even the obvious chain has a gap in it. But the shape of the risk is exactly right: a carefully configured failover from one vendor to another can land in the same building, and no vendor exposes the field that would tell you. Which is the practical argument for keeping one set of weights you run yourself in every fallback chain. Not because self-hosting is better, but because it is the only entry whose failure domain you can actually see.

Regulation shapes the layers. It does not replace them.

The European draft annex on artificial intelligence in good manufacturing practice is narrower than it is usually described. Four conditions have to hold together before it applies at all: the application is critical, meaning it bears directly on patient safety, product quality or data integrity; the model learned its behaviour from data rather than being programmed; it is static, so it does not adapt while in use; and its output is deterministic, which the draft defines as identical inputs giving identical outputs.

That fourth condition is the one people misread, so it is worth separating two things it does not distinguish between. Deterministic here means reproducible, not free of probability. A gradient-boosted classifier that emits a 0.83 likelihood of seriousness is deterministic in this sense: run it again on the same report and you get 0.83 again. It sits inside the scope. What sits outside is output that varies between runs on the same input, which is what sampling from a distribution gives you. Read the other way, the annex would exclude almost all of classical machine learning, including the pharmacovigilance models described earlier in this piece, which have been in national use since 2021. That reading is our own, resting on the definitional clause rather than on any commentary, and it is worth checking against the text yourself if a programme depends on it.

Generative models and large language models fall outside all four conditions, and the draft says they should not be used in critical applications, while permitting non-critical use where a qualified person remains responsible for the output. For the uses it does cover it wants a documented baseline, acceptance criteria at least as good as the process being replaced, and a justification whenever a change is not fully retested.

Translated into layers, every one of those requirements lands somewhere specific, and none of them lands on the router.

One caution about that draft, because an article can date badly here. After the consultation closed, the regulator convened a workshop in mid-2026 and reported support for potentially enabling generative models in medicines manufacturing, with final text targeted for late 2026. The exclusion described above is a consultation position under active reconsideration, not settled policy, and the layers are what will outlast whichever way it lands.

The release cadence points the same way. The frontier changed hands repeatedly through 2026 and the gaps between the leaders were small enough to be noise for most real work. That cadence is a fact about the model layer and an argument for automating the other six, not for chasing it.

Data first. An egress classifier wired into the gateway rather than written into a policy document, so the rule is enforced instead of circulated. Extraction and entity linking that lands on the standard vocabularies, with structured fields kept alongside the text rather than flattened into it. A knowledge graph only where the questions are genuinely relational. And an evaluation store nothing leaves.

Substrate second. Write down, per workload, where inference physically happens and under whose law. Then make sure at least one option in each chain is weights you hold.

Orchestration third. Keep prompts, tool schemas and retrieval config in version control as first-class assets, with a per-model variant where one is needed. Pin the embedding model and treat changing it as a migration with a budget, not a config edit.

Then validation, oversight, model and pricing. A task taxonomy with your own hold-out set per node, a documented incumbent baseline, a chosen operating point per business decision, and a multi-vendor jury for anything open-ended. An audit record in your own schema. A router driven by your scores rather than a public leaderboard. And a switch proposal that clears both the saving and the cost of proving it.

One measure tells you whether the whole thing works: the number of days between a new model existing and you knowing, in writing, what it does on your own work. If that number is a quarter, you are choosing models on marketing. A week is achievable, and it is achievable only if six layers were built before the router.

This architecture is assembled from parts that have each been demonstrated separately. A national pharmacovigilance deployment showed the data layer choosing the model. A public benchmark suite showed the validation layer costing more than the model layer. Two 2026 incidents showed what the substrate does when nobody is looking at it. We could not find a biopharma company that has published an end-to-end description of the whole thing working together. The most-cited industry example shows why that matters. At a capital markets day in March 2024 the company told its own investors that the tool made document production roughly 70 percent faster. Eight weeks later a supplier's case study described the same work as twelve weeks reduced to ten minutes, which is not 70 percent but something nearer 99.99. From there the figure wanders: ten weeks on one vendor page, twelve on another, fifteen in a trade report, every one of them landing on the same ten minutes, and not one stating a sample size, a comparator or a quality metric.

The first number carries securities liability. The second carries a logo. When a company's own disclosure and its supplier's marketing differ by three orders of magnitude about the same tool, the useful conclusion is not which one is right. It is that the public evidence base for AI in this industry is mostly the second kind, which is the gap this whole architecture is trying to close.

So treat this as a synthesis rather than a proven pattern. That gap is the opportunity, and it is also a good reason to be sceptical of anyone offering to sell you the finished article.

Drawing seven layers takes an afternoon. The work is deciding which of your workloads belong in which egress class, writing the first hold-out set for a task nobody has ever measured, and getting an audit record into a schema you own rather than one your supplier lends you. It is mostly not a modelling problem, which is why it tends to stall in organisations that have staffed it as one.

That is the work we do with companies. Our data and AI strategy engagements start with where the leverage is and what to build first, which in a regulated organisation means deciding which layer is actually holding you before anyone buys a gateway. From there it is custom AI workflows on proprietary data and bespoke development from proof-of-concept to production, built so the evidence a regulator will ask for is a by-product of running the work. Our portfolio monitoring and in vivo augmentation case studies are both work that had to survive outside scrutiny rather than simply produce an answer.