Strategy · 8 min read

Owning the workflow, not renting the model

By the TECHWORKSLAB platform team

There is a quiet assumption in a lot of AI adoption right now, which is that the model you build on today will still be there, priced the same way, behaving the same way, next year. In regulated life sciences that assumption is expensive. A commercial model can be deprecated on a vendor's schedule. It can be repriced. It can be restricted to certain regions or certain uses. It can quietly degrade on the specific task you care about after an update aimed at general performance. And it can be replaced by a successor that behaves differently enough to matter. None of those events are under your control, and every one of them lands on a validated workflow as rework.

So it is worth being precise about what the durable asset actually is. It is not the model of the month. The durable asset is the workflow and the artifacts it produces. The model is a part inside that workflow, and like any part, it should be replaceable. Build so that you own the logic and can swap the model underneath, and external changes stop being emergencies.

The problem with welding a workflow to one provider

Consider a validated workflow that generates a first draft of a study document, or checks a dataset against a standard, or drafts a response to a query. If that workflow is written directly against one specific model, or can only run inside one orchestration platform, then the workflow has inherited every risk that model and that platform carry. When the provider changes something, you find out through your own outputs, and then you are into an unplanned cycle of investigation, revalidation, and rework, on someone else's timeline rather than your own.

This is not an argument against commercial models. They are often the right choice on quality and cost. It is an argument against building in a way where you cannot move if you need to. In a regulated setting, the ability to move is part of the design, not an afterthought.

No model lock-in

The first principle is that the same workflow should be able to run against different providers, and against local models, without being rebuilt. The way you get there is to put model selection behind an abstraction and choose the model at configuration time rather than baking it into the workflow logic. The workflow describes what should happen. A separate layer decides which model does the reasoning for this run, in this environment, for this task.

Done this way, replacing a model is a configuration change and a fresh round of qualification for the new model, not a rewrite of the workflow. That separation between workflow logic and model provider is what keeps a repricing or a deprecation from turning into a project. It also lets you match the model to the sensitivity of the work, using a local model where data cannot leave your environment and a commercial one where it can.

No workflow-platform lock-in either

Model portability is only half of it. If your workflow can only exist inside one proprietary orchestrator, you have simply moved the lock-in up a level. When that platform changes its terms, its pricing, or its roadmap, or when it disappears, your workflow goes with it.

The alternative is to represent workflows as a portable, inspectable specification. A declarative file that describes the steps is a good form for this, because it can be exported, versioned in source control, diffed against a previous version, and run or tested outside the platform that happens to execute it today. That portability is not a convenience. In a regulated setting it is what makes independent quality control possible, because someone can read and check the workflow without trusting the tool that runs it, and it is what gives the workflow long-term viability beyond any single vendor.

Deployment on infrastructure you control

For sensitive clinical and patient data, where the workflow runs is a first-order question. Being able to self-host and keep data inside your own environment can matter more than the convenience of a hosted service, because it removes a whole class of questions about where data went and who could see it.

It is worth being honest about the tradeoff. Self-hosting adds real operational burden. You take on patching, monitoring, capacity, and the qualification of the environment itself. That cost is worth paying where data control and validation demand it. It is not worth paying everywhere, and pretending otherwise helps no one. The point is to make the choice deliberately, workflow by workflow, rather than defaulting to a hosted service because it was easier to start with.

Control and inspectability

Open source is one route to control. When you can inspect, modify, and adapt the critical infrastructure your workflows depend on, you are not waiting on a vendor to fix or explain something that is holding up a submission. But open source is not mandatory, and treating it as a requirement misses the actual principle.

The principle is broader. Do not end up unable to control or inspect the infrastructure your regulated workflows depend on. You can meet that bar with commercial software that gives you enough access, documentation, and contractual assurance to satisfy an auditor and to keep operating if the relationship changes. What you cannot afford is a black box in the middle of a validated process that you can neither examine nor replace.

A separation worth designing around

A useful way to keep all of this straight is to hold five things distinct, so each one is replaceable and governable on its own terms:

The workflow, which is what should happen, expressed as a portable specification.
The model or agent, which is who does the reasoning, chosen at configuration time.
The environment, which is where it runs, whether self-hosted or managed.
The evidence, which is what proves what happened, captured as durable artifacts.
Accountability, which is who owns the result, and stays with people regardless of the tooling.

When these are separate, you can change the model without touching the workflow, move the environment without losing the evidence, and answer for a result no matter which parts have been swapped since. When they are tangled together, every change touches everything, and that is exactly the condition that makes revalidation painful.

Own the workflow, rent the model. The logic, the artifacts, and the accountability are yours to keep. The model is a part you should be able to replace without rebuilding what sits around it.

What does owning the workflow concretely mean? It means owning the things that do not come back once a vendor relationship ends:

The workflow logic, as a specification you hold and version.
The prompts that drive each step.
The skills and instructions that shape how the work is done.
The configurations that bind a run to a specific model and environment.
The data the workflow reads and writes.
The infrastructure it runs on, or at least enough control over it to inspect and move.
The resulting artifacts, meaning the outputs and the evidence of how they were produced.

Independence as resilience, not purity

None of this is a call to avoid commercial models or hosted platforms on principle. That would be its own kind of trap, trading useful tools for a rule. Vendor independence is a resilience strategy, not a purity test. The goal is that a change in pricing, quality, regulatory status, or availability does not put a validated workflow at risk, because you designed for model portability from the start.

Designing for it later is much harder, because by then the workflow has grown around the assumptions of one provider and one platform. Set the separation up early, keep the workflow portable and the model behind an abstraction, and you buy yourself the ability to adapt calmly to whatever the market does next.

If you are building AI into regulated workflows and want them to outlast any single model or platform, talk to our team.