Who controls the AI stack?

A regional company can contract with three AI suppliers and still depend on one model, one cloud account or one identity service. Counting suppliers will not reveal which failure could stop the workflow.

Before committing to a platform, the technology sponsor and procurement owner should map the service they are buying to the components it needs. They should then test the most consequential replacement or fallback. This makes dependence an explicit operating choice rather than a surprise discovered during a renewal, outage or model withdrawal.

Some concentration is sensible. A single platform can simplify security, integration and support. The decision is whether those advantages justify a dependency the institution understands, can govern and can survive.

Look below the supplier's name

The AI stack is the set of components that delivers the result: application, model, data stores, orchestration, identity, compute and supporting services. A document assistant may also use extraction software, search, logging and monitoring. The company selling the assistant may operate some components and buy others.

NIST's Generative AI Profile, published in July 2024, describes a value chain involving procured datasets, pre-trained models and software libraries. It warns that dependencies can reduce downstream transparency and accountability, and that extensive reuse of a limited number of models can compound the problem. These are risk mechanisms identified in voluntary guidance, not evidence that every multi-supplier architecture is unsafe.

Start with one critical workflow and draw what it requires to complete a case. Mark the supplier, service version, operating location, data involved and person responsible at each step. Include dependencies that do not generate text: a failed identity service can prevent the whole application from working, while a failed logging service can make continued operation unacceptable.

In an illustrative invoice workflow, two applications could call the same hosted model and store their records under the same cloud identity account. Switching between the applications might help if one application fails. It would not necessarily help if the common model becomes unavailable or the identity account is inaccessible. The alternative needs to address the failure being planned for.

What concentration evidence establishes

The UK Competition and Markets Authority's July 2025 cloud investigation provides a useful public account of switching constraints. Its final decision identified market concentration and commercial and technical barriers, including egress fees and differences in features and interfaces. The decision summary also describes gaps in transferable skills and difficulties comparing and integrating services.

The investigation concerns cloud infrastructure serving UK customers, with a stated UK-plus-EEA geographic market. It does not measure ASEAN cloud shares or establish an institution's exposure to a particular AI supplier. Its mechanisms are useful questions for a Singapore procurement team; its market figures should not be imported as regional facts.

The decision also supplies counterevidence to a simplistic account of lock-in. The CMA found that committed-spend agreements could influence workload allocation but, in their assessed form and application, did not harm competition. It recorded advantages of cloud services and customer perceptions of quality and innovation. Buyers should examine their own contracts and architecture rather than treat every discount, integration or proprietary feature as a reason to reject a platform.

Dependence has value as well as cost. A well-operated managed service can remove responsibilities that the institution is poorly equipped to perform. The value becomes fragile when the customer cannot explain which responsibilities it retains or how an essential service will continue if a key component changes.

Compare choices against the same workload

Deployment labels help only when the alternatives serve the same task and acceptance standard. A hosted service with broad capabilities and a smaller locally operated model are not substitutes until the latter passes the required workload tests.

These are potential advantages and investigation points, not product rankings. A mixed approach can be appropriate: centrally managed permissions and records, one primary model service, and a more limited fallback for essential tasks. It should have a reason for every extra component.

AWS's shared responsibility documentation illustrates why the service detail matters. Customer responsibilities vary between infrastructure and more abstracted services. A procurement decision needs to identify who patches, configures access, maintains recovery and produces evidence. Purchasing infrastructure does not purchase the application's accountability.

Portability has to include the operating record

An export button can retrieve documents while leaving the workflow expensive to reconstruct. Policy rules, document mappings, prompts, access permissions, evaluation cases and audit records may live in different components. Some may belong to the institution; others may be subject to licence or contract restrictions.

Ask the supplier to demonstrate an export of representative records and their metadata. Establish what can be rebuilt, what must be licensed again and what cannot be exported. Retain evaluation material the institution has the right to use so that replacement quality can be checked independently of the departing supplier.

The same principle applies to open models. The Open Source Initiative's Definition 1.0 distinguishes data information, code and parameters alongside rights to use, study, modify and share. A downloadable model may improve deployment options, but procurement still needs the exact licence and available artefacts. It does not automatically provide the operating records of the application built around it.

Switching models also changes behaviour. Two services may accept a similar request format yet differ in extraction, refusals, tool use or treatment of ambiguous instructions. Re-run the workflow's important evaluation cases before allowing a replacement to act. Interface compatibility is evidence that a request can be sent. Operational acceptance assesses whether the test evidence supports using the replacement for the agreed task and scope, with its remaining uncertainty.

Design resilience around a tolerable loss of service

Agree how long the business can wait, which records must be recoverable and which actions must stop when evidence is unavailable. A drafting assistant might tolerate a queue. A system preparing payment instructions needs a defined safe state and a controlled route for people to resume work.

The fallback does not always need another AI platform. Staff may be able to use the underlying document store and established workflow. A rules-based process may handle a narrower set of cases while uncertain cases wait. That can be easier to operate and assess than a second model expected to reproduce every capability.

Conversely, a manual fallback that requires more people than the institution can provide is not credible. Measure the work that can be completed under the fallback, the growing backlog and the conditions for resuming normal service. A recovery test should reveal these constraints before the fallback appears in a board paper as an assurance.

Compute introduces its own constraints. The Singapore National AI Strategy update of May 2026 explicitly notes uncertainty about future compute supply while combining increased availability with resource efficiency. An institution should verify the capacity and support available to its own workload, including its fallback. A provider's expansion plan does not reserve usable capacity for a particular customer.

A regional footprint requires separate acceptance

Record where inputs, outputs, backups and logs are processed, and where support personnel or additional services can access them. The application's hosting region is only part of that record.

For the Singapore entity, the PDPC's April 2026 cross-border guide offers resources for meeting the Transfer Limitation Obligation and adapting ASEAN contractual clauses. It does not determine another country's requirements or establish that a particular replacement deployment is acceptable.

An alternative cloud or model service can change processing destinations, support access and contractual arrangements. Include the relevant entity's privacy, legal and security owners in approving it. The ASEAN rollout workbook provides a per-entity record; use it to keep regional design and local acceptance connected.

Put an exit exercise into the purchase decision

For the most consequential dependency, ask the team to demonstrate six things before a long commitment:

1. Export a representative set of records, permissions and relevant operating evidence.
2. Reconstruct the agreed minimum service in the alternative environment or fallback process.
3. Run important evaluation cases, including cases that must be declined or escalated.
4. Check that approved data access, logging and human controls still work.
5. Measure the elapsed recovery time, temporary workload capacity and total transition cost.
6. Name the owner who can authorise the switch, handle the backlog and approve resumption.

An exercise can establish feasibility for its tested scope. It cannot prove uninterrupted performance under every future outage. Record the untested conditions and repeat the relevant checks after material service or architecture changes.

Use those results in the renewal decision alongside the platform's operating advantages. Fund the alternative where the consequence of dependence justifies it. Accept concentration where the institution can control the risk and gain enough value. The supplier count is a starting fact; the evidence that matters is whether the business can exercise its choices when it needs them.