Five watch-outs for anyone standing up an AI platform
Here are five things to consider before signing off an enterprise AI platform strategy. All five arrive looking like engineering decisions. All five come down to users, risk appetite and money, which makes them product decisions with a technical surface.
1. AI platform access and governance: one tier for everyone.
It's the easiest thing to govern. The question underneath is how much friction your best people will absorb before they quietly open a personal account on their phone, and almost nobody measures that until it has already happened.
What I'd want to see: tiers based on the data, not the job title. Two or three of them, published, with an obvious route to ask for more. Erring too restrictive is the more common failure and the harder one to detect.
The governance sits in what's behind each tier and who can move between them. Be explicit, tier by tier, about which models are allowed, whether prompts and outputs are retained, whether anything leaves your tenancy, and what gets logged. Then map those tiers onto the data classification scheme your infosec team already runs, rather than inventing a parallel one nobody will learn. Name who signs off an exception and how long that takes. If it's more than a few days, people will route around it and you won't see them go.
2. Hard-coding something that should have stayed editable.
Organisational know-how ends up in one of two places. Either you encode it as a procedure the system follows the same way every time, or you leave it as knowledge the system looks up when it needs it. Those are different things - the first is instructions, the second is facts - and most vendors blur them, because their products bundle both and the vocabulary changes every six months.
The choice tends to get settled on architecture grounds. Change rate and ownership are the better test. Stable, uncontested, nobody needs to argue about it: encode it. Moving, or two parts of the business would answer differently: keep it as knowledge, versioned, with a named owner who can change it without waiting for a release.
Get this wrong early and you've hard-coded a bad decision into every workflow that calls it, and the person who spots it can't be the one to fix it.
3. A context system with no retirement plan.
Everything gets a growth plan. Very few create a deletion policy. Knowledge has a half life - old pricing, superseded policy, a strategy nobody has followed for a year - and it sits there being confidently retrieved. Quality degrades slowly and nobody traces it back to the source. So: who is allowed to remove things, and how often does someone look?
(Much more on building a good context system to follow in another blog very soon)
4. Token spend, nobody has forecast.
Change how you connect to a model, keep every workflow identical, and spend can move by an order of magnitude with nobody behaving any differently. Then finance finds out, and the overcorrection throttles exactly the usage you spent a year building.
The usual culprits: moving from flat-rate seats to metered API calls, prompt caching that was never switched on, retrieval that quietly grows the context you send with every single request, and agentic workflows where one user action becomes twenty model calls behind the scenes. None of those look like a change to anyone using the system. All of them change the bill. This is AI platform unit economics. Forecast it, budget per team, route the cheap work to cheap models on purpose.
5. A roadmap made of everyone's pet use case.
Most AI programmes have no mechanism for killing an idea, because killing one feels like being against AI. So the backlog only grows.
Score intake on impact, effort and risk, and publish the scores. If every division's favourite thing makes it on, you don't have a platform. You have a queue.
The deeper problem in AI platform roadmap planning is sequencing. Plenty of platforms get built because a platform is the impressive thing to build, and the use cases get retrofitted afterwards. It works better the other way round. Ship two or three use cases properly, notice what they both needed, and promote that into the platform. What you extract from working software is nearly always different from what you'd have specified up front, and it arrives with proof that somebody wanted it.
The bottom line
None of this needs the deepest AI expert in the building. What it needs is someone with enough depth to be credible in the room with them, and the product judgement to make the calls the specialists can't make on anyone's behalf.
That's the gap I keep seeing. There is no shortage of people who can build it but there isn't enough input from those whose job is to decide what and who it's for.
