Technology leaders sit in the worst seat of the AI conversation: accountable for delivery of programmes whose briefs were written as ambition rather than scope. The board wants "AI in the business", the vendors want a platform decision, and the pilot that demos beautifully in week six is quietly dead by month six.
We advise on this as operators. Three AI products of our own are in market with active customers, and every scar in this article is first-hand.
Scope to keep, not to impress #
The pilot graveyard has one headstone inscription: impressive demo, no owner. Scoping to keep inverts the demo instinct. Pick a narrow, boring, recurring job over a broad impressive one. Run on live, messy data from day one, because curated extracts are how pilots lie. Name the owner, the escalation path and the maintenance budget before the build starts, and define the number that proves it worked with the date it gets checked.
The unglamorous corollary: AI will not fix a process nobody has written down. It scales the process as found, faults included. Instrumenting the process first is slower and is the actual work.
The moat is in the connections #
Tool-by-tool adoption, each team choosing its own, produces a stack where nothing compounds: every capability is one a competitor can buy tomorrow. The defensible version reads one operating picture of the business, where each capability makes the next cheaper because the data layer already exists. Our own products became productisable exactly once the connective layer did: the pattern held well enough that a product now exists because one engagement proved it.
For the technology leader this sets the architecture argument: fight for the shared data layer before the next tool purchase, because the tools are fungible and the connections are the asset.
The model is the least risky part of the build. The scope, the owner and the data layer decide whether it is still running in a year.