This deep dive expands on the Loop Asia conversation with Sutowo Wong, Managing Director, AI x Data at Temus.

If you own integration and data infrastructure decisions — CTO, CDO, Head of Architecture, Head of Data — you've lived this pattern: a pilot gets built, it works, everyone's pleased, and it never leaves the sandbox. Sutowo Wong, Managing Director of AI x Data at Temus, has a structural explanation for why. It has almost nothing to do with model quality.

It's not the model. It's who wasn't consulted.

Teams isolate pilots for a defensible reason — it reduces risk while they test whether the idea works. But that same isolation excludes the people a production rollout requires: the business users who'll work with the system, the governance owners who have to sign off on it, and the technologists who own the architecture it runs on. Miss any one of the three and the failure is predictable — something that works but stalls at an IT governance review nobody consulted, or something architecturally clean that nobody in the business adopts.

Sutowo saw this for a decade in Singapore's Ministry of Health, and sees it now at Temus across financial services and government: clinicians, administrators, and technologists all have to be at the table, or the pilot that worked in isolation dies at the integration point.

This reframes what "de-risking a pilot" should mean. The instinct — narrow scope, run lean — taken too far manufactures the exact failure it's trying to avoid: the risk that kills AI projects isn't technical, it's the integration and governance risk that surfaces once you try to widen the pilot's audience, after the architecture decisions are locked in.

What "transformative" actually requires architecturally

Sutowo is precise about what separates a pilot from a transformation: reaching production, integrating with the surrounding systems, and — where the workflow demands it — reimagining the workflow and the job roles inside it. That's where architecture decisions and organisational decisions collide, squarely in the Technical Champion's lane, rarely resourced to manage alone.

The practical version, as Sutowo describes it: deconstruct the workflow into three buckets — tasks AI runs autonomously, tasks that stay entirely human, and tasks where AI assists without replacing. That's an architecture decision, not a product one. It determines what needs an API contract versus a human-in-the-loop checkpoint, an audit trail versus a simple log, and where the governance boundary sits in the design. Get the bucket assignment wrong and you either over-automate into a compliance problem or under-automate into a pilot that never earns its production business case.

Governance designed in, not inspected in

Sutowo's closing argument: architecture teams treat governance as a compliance layer bolted on at the end, a gate before go-live. His counter — the sequencing is the problem. Governance applied after the fact is neither effective nor sufficient; it has to be part of the architecture from the first design decision.

His analogy: you drive faster in a car you know has working brakes. Governance done well isn't friction, it's clarity — an upstream design constraint on the same footing as scalability or security, not a downstream gate. That's the difference between architecture that survives the compliance review and architecture that gets reworked because of it.