INSIGHTS

Analysis

The quiet risk of outsourcing your business reasoning

Frontier models are a reasonable choice for many tasks. They are a poor foundation for the internal processes that define how your organisation works.

30 JUNE 2026 · 15 MIN READ

Two different kinds of work

There is a meaningful difference between using a model to draft external copy and using one to decide which supplier invoice is anomalous, which case needs escalation, or how a claim should be assessed. The first is production support. The second is business logic.

When business logic sits inside a third-party model reached over an API, the organisation has moved a part of how it operates outside its own boundary — often without a design decision, a change record or an accountable owner.

The boundary is not only technical. It is organisational. Decisions that used to be documented in policy, reviewed by committees and tested in audits now live partly in prompts that evolve inside application teams. The knowledge of why the organisation does what it does becomes harder to find, harder to defend and harder to change under control.

What accumulates over time

The risk is rarely a single incident. It accumulates in ways that are easy to miss until they are expensive to fix.

  • Process knowledge migrates into prompts that live in application code and are rarely reviewed as policy.
  • Behaviour changes silently when a provider updates a model, and nobody can attribute the change to a date, a version or a reason.
  • Cost becomes a function of someone else's pricing decisions applied to a volume the organisation cannot easily reduce.
  • Continuity depends on a model version remaining available for as long as the process needs it, which is not guaranteed.
  • Regulatory explanations become harder because the reasoning layer is not under the organisation's control or record.

The decision-rights problem

Outsourcing reasoning is also a decision-rights problem. When an external model tells a case worker how to triage a complaint, or an underwriter how to interpret a risk, the final human decision may still be human, but the framing, options and emphasis have been shaped elsewhere.

This is not always wrong. A model can surface patterns a human would miss. But the organisation needs to know that it has delegated framing, understand what is being optimised for, and retain the ability to inspect, override or switch the reasoning layer.

Without that awareness, human approval becomes a rubber stamp applied to outputs the organisation does not fully understand. That is not human-in-the-loop governance. It is human-in-the-loop theatre.

Capability erosion and lock-in

A less discussed risk is capability erosion. As teams grow accustomed to a frontier model handling classification, summarisation, drafting and routing, they stop building those skills internally. Over time the organisation forgets how to do work that it once understood.

That creates a subtle form of lock-in. Even if the contract is cancellable, the operational knowledge is not. Teams no longer have the internal bench, the evaluation data, or the alternative pipelines needed to switch providers or bring the work in-house.

The antidote is deliberate capability retention. Run parallel evaluations on open-weight alternatives. Maintain internal tooling for the highest-sensitivity processes. Keep a record of why a frontier model is chosen for each task, and review it quarterly.

This is not an argument against frontier models

Frontier models do things open-weight models still do less well, and pretending otherwise produces worse systems. The argument is about placement. Use the strongest available model where the task benefits from it and the content permits it. Keep sensitive internal processing on models you host, on infrastructure you own.

That split only works if it is enforced rather than intended. Routing by policy — declared per agent, per tool, per data class — makes the placement decision inspectable instead of implicit.

The organisations that manage this well do not treat frontier models as either hero or villain. They treat them as one option in a portfolio, governed by rules the organisation sets and owns.

Questions worth asking internally

Which processes would you be uncomfortable describing to a regulator as dependent on an external model? Which of those are already dependent on one? The distance between those two answers is the work.

Other useful questions: which of our decisions could not be explained if the model's output were unavailable? Which business rules now exist only in a prompt? Which third-party model would be most painful to replace, and why?

These questions are uncomfortable because the answers often reveal that sovereignty has already been given away in increments. The value is in seeing it clearly, so it can be recovered deliberately rather than discovered in a crisis.

Recovering control without stopping innovation

The goal is not to eliminate frontier models. It is to place them under governance. That means a control plane that knows which agent is calling which model, on what data, for what purpose, with what approval and with what record.

Once that layer exists, teams can keep experimenting with frontier models while the organisation retains the ability to say no, to switch, and to prove what happened. Innovation and sovereignty become compatible because the boundary is enforced by design, not by trust.

The most resilient posture is to assume that every external model will eventually become unavailable, expensive, or unsuitable. Build so that when that day comes, the critical parts of the business keep running exactly as before.

More insights

Northern sea cliffs and dark water at evening

A more capable, sovereign future.

Put AI agents to work in your environment, with complete control.

  • Sovereign AI
  • Smarter organisations
  • Brighter tomorrows