Escaping POC hell

Most organisations that have been doing AI for three years are not short of proofs-of-concept. They are short of production. The symptom is recognisable: many pilots, spend scattered across functions, and a portfolio metric that counts how many AI projects we have rather than what any of them changed.

I am going to argue this from the inside, because it would be dishonest to argue it any other way. I build proofs-of-concept. That is what most of the work on this site is. Which means I have run directly into every failure mode below, and the list is written from my own wreckage rather than from a framework I read.

What is missing from a POC that never ships

Exit criteria, written before it starts. The single biggest one. A pilot without a defined kill condition cannot fail — it can only continue, quietly, forever, because there is no agreed moment at which someone says “this did not clear the bar”. A pilot is a question. It needs an answer that either kills it or scales it, and the shape of that answer has to be agreed while everyone is still optimistic.

I enforce this on my own portfolio with four verdicts and a review date: finish, pivot, park, or kill. Park carries an explicit re-examination date so that “later” cannot silently become “never”. Kill means kill. I have applied both, including to work I liked — a discovery tool that was blocked on external feedback got parked with a date; two ideas got killed outright after triage rather than lingering as open tabs. The discipline is not about being decisive; it is about the portfolio being legible rather than an accumulation of unfinished intentions.

A data foundation that grows with use. The two failure shapes are opposite and equally fatal: spend two years building the perfect warehouse before any AI value is allowed to happen, or start with no structure at all and discover the retrieval is unusable. What has worked for me is treating the foundation as infrastructure you lay progressively — canonical source of truth separated from generated views, everything regenerable, provenance recorded on anything imported from elsewhere, and an explicit policy for what is stored where and what is never stored at all. AI does not need perfect data to start. It does need to know which copy is authoritative.

Decision rights matched to reversibility. Not everything should be delegated to a system, and the useful dividing line is whether the decision can be walked back. Reversible, high-volume, low-stakes decisions with a clear objective and available data are good candidates. Irreversible, high-stakes, relationship-sensitive or genuinely novel situations stay with a person. Deciding this in advance — rather than after an incident — is what makes the autonomy question answerable.

A role change, not a headcount plan. The manager of an AI-assisted process is not defining tasks any more; they are setting objectives, success criteria, constraints and escalation triggers, then monitoring and intervening. That is a different skill set, and it is learned on the job. If the plan is to replace people rather than move them into that role, the organisation loses exactly the domain judgement that makes the objectives correct in the first place — and it will find out during the incident, not before.

Someone with an incentive to scale it. A pilot usually succeeds inside one team. That team has no reason to generalise it, and often no capacity to. Unless there is an explicit mechanism — someone whose job is to take what worked in one place, re-apply it elsewhere, and turn the repeated parts into shared infrastructure — successful pilots stay local and get rebuilt three more times.

What I built to hold myself to it

I run my own work on an operating system I built for it, and it is the closest thing I have to a scaled-down version of the enterprise problem: a canonical memory with an explicit written policy for what gets stored where, a generated human-readable view that is never the source of truth, a ticket system so that every decision and open question is visible across sessions rather than living in someone’s head, enforced budget rules, and synchronisation across several machines with the generated artefacts rebuilt idempotently so two machines can never fight over them.

That is not an enterprise platform. But every problem it solves — provenance, single source of truth, auditability, cost control, decisions surviving the person who made them — is the same problem an enterprise AI platform has, and having solved it at a scale I could hold in my head is why I can talk about it concretely rather than abstractly.

How this transfers

I would not walk into an enterprise and claim to have done this at scale. What I would do is insist on the exit criteria before the pilot, name the data authority question on day one, get the reversibility line written down before autonomy is granted, and ask early who is incentivised to generalise the result.

Those four questions are cheap to ask at the start and extremely expensive to ask in year three.