Who should build, run and control this AI workflow?

Before choosing a supplier, choose an operating model. The same workflow can be built in-house, bought from a vendor, built for you by an integrator, delegated to an outsourced operation, or split across several of them. Each choice moves responsibility, cost structure, lock-in and what you can still verify.

This page compares operating models, not named suppliers. It is a decision aid, not a recommendation: the right model depends on your workflow, your constraints and your contracts. TokenShift does not resell software, does not bid on integration work and does not operate processes.

In-house

Build it and run it with your own teams.

Best used when: The workflow is close to what differentiates you, the data is sensitive, and the organisation has — or intends to build — the engineering and operating capacity to keep it running.
Who is responsible for what: Your teams hold design, build, run, incident response, model changes and evidence. Nothing is delegated, so nothing has to be contracted.
Economics: Mostly fixed: internal headcount, platform and model spend. Unit cost falls with volume only if the team is kept and actually used.
Lock-in: Lowest external dependency, highest internal one. The workflow ends up depending on the people who built it and on their availability.
Control criteria: A named workflow owner; documented human review points; an exception and incident log; a cost-per-outcome baseline; a succession plan for the build team.
Possible TokenShift role: Frame the decision and the controls before the build is funded, then review the live workflow at an executive cadence. TokenShift does not staff or run the build.

Software vendor

Buy a product and configure it.

Best used when: The workflow is close to a market standard, time-to-use matters more than exact fit, and configuration is enough — no bespoke behaviour is required.
Who is responsible for what: The vendor holds the model, the roadmap and the platform. You keep the business decision, the data you feed it, the human review, and the outcome in front of your own stakeholders.
Economics: Subscription plus usage. Predictable in shape, but indexed on seats or volume, and it moves with the vendor's pricing rather than with your effort.
Lock-in: The data model, the workflow shape and the integrations follow the product. Export rights and history retention decide what leaving would cost.
Control criteria: Documented model and version changes; export and deletion rights; an auditable log of automated decisions; a named internal owner who is not the vendor's internal champion.
Possible TokenShift role: Set the acceptance criteria and the controls the product has to satisfy, and keep the vendor review inside the monthly governance rhythm. TokenShift resells nothing and takes no vendor commission.

Systems integrator

Have it built for you, to your specification.

Best used when: Scope, architecture and governance are already settled, and the binding constraint is delivery capacity rather than decision-making.
Who is responsible for what: The integrator holds the build and, where contracted, part of the run. Acceptance, guardrails and the production decision stay with you — unless they are delegated by default, which is what usually happens.
Economics: Project or time-and-materials. Cost tracks scope changes, and the run cost appears later — in maintenance, and in the next change request.
Lock-in: The dependency is in the knowledge rather than the licence: whoever built it holds the tacit understanding of why it works. Handover quality is the whole question.
Control criteria: Written acceptance criteria agreed before the build; documented workflow and decision rules; a handover a named internal owner has actually rehearsed; an explicit reversibility clause.
Possible TokenShift role: Write the decision, the acceptance criteria and the handover test the integrator has to pass. TokenShift is not an integrator and does not bid on the build.

Outsourced operation

Delegate the process itself, AI included.

Best used when: The process is not a differentiator, volume is high and variable, and a provider is measurably better at running it than you are.
Who is responsible for what: The provider operates. Accountability towards your regulator, your customer and your board does not transfer with the work — you answer for the outcome either way.
Economics: Per unit or per FTE, presented as variable. When AI enters the provider's own workflow, their cost base changes; whether that reaches your price depends on what the contract says.
Lock-in: The strongest of the five. Process knowledge, tooling and often the working data sit with the provider, and exit cost is a function of what the contract lets you take back.
Control criteria: An AI transparency clause — what is automated, by which system, since when; evidence and audit rights at the interface; exception and escalation routes; cost-per-outcome visibility; an exit path that has been tested rather than merely written.
Possible TokenShift role: Read the relationship from the buyer's side: what is delegated, what stays controlled, what is recoverable. TokenShift does not operate processes and does not act for the provider.

Hybrid

Split the workflow by layer, not by supplier.

Best used when: Parts of the workflow differ in sensitivity or in rate of change — a stable high-volume layer worth delegating, a judgement layer worth keeping.
Who is responsible for what: Split explicitly, layer by layer. Left implicit, responsibility defaults to whoever speaks first on the incident call, and the handoff points are exactly where hybrids fail.
Economics: Mixed, and only comparable against a single baseline: the same workflow, the same period, the same definition of an accepted outcome.
Lock-in: Lower per component, higher at the seams. Interfaces, data formats and the exception path become the real dependency.
Control criteria: One owner for the whole chain rather than one per component; a single incident route; a shared definition of an exception; a baseline that survives a change of supplier on any layer.
Possible TokenShift role: Hold the baseline and the seams: one owner map across the chain, one exception route, one measure. This is the shape TokenShift most often works in.

Where TokenShift is useful

You have several AI pilots and no single decision on which workflow moves first.
You need one named executive owner before more build or outsourcing spend is approved.
You are comparing operating models and have no shared baseline: same workflow, same period, same definition of an accepted outcome.
A workflow is already live and the exceptions, costs and supplier changes are not reviewed in one executive rhythm.

Where TokenShift is not the answer

You want a broad enterprise transformation programme before narrowing the scope.
You already have a governed production workflow and need engineering capacity.
You want a supplier to build, integrate or operate the workflow itself.
You want a supplier ranking or a named competitive benchmark.

Want to pressure-test your own situation?

Start with the readiness check, or with a 20-minute conversation about your priority.

Take the readiness check Talk about your priority · 20 min