What an Enterprise Means When It Says It Wants AI
Last year, researchers at MIT published a finding that travelled fast: across hundreds of enterprise generative-AI initiatives, roughly ninety-five per cent of pilots were producing no measurable effect on profit and loss. The figure was widely read as a verdict on the technology, and that reading says more about the market's mood than about the evidence. The models inside the failed pilots were, for the most part, the same models running inside the successful ones. What differed was not the technology, but was what the technology had been asked to do – and the broken feedback loop.
The pattern is visible from the other direction too. Executive confidence in AI returns runs above ninety per cent in industrial surveys, while the share of organisations approaching AI with any holistic architecture sits in single digits. Belief has outrun design by an order of magnitude. Something is being lost between the intention and the system, and it is worth being precise about where.
Our answer, from several years of building and deploying these systems, is that the loss happens early, at the moment a request is accepted at face value. Most post-mortems examine the model, the integration, or the change programme. The failure they are looking for usually occurred before any of those existed.
The request carries less information than it appears to
Enterprises rarely ask for what they need. They ask for what they have heard of. The requests arrive in a familiar vocabulary: we need a chatbot, we want AI for compliance, our board wants us to explore agentic systems. Each only sounds specific. It is not.
Consider what a single phrase can contain. "AI for compliance" may mean monitoring regulatory change, verifying documents against a customer's code of conduct, preparing audit evidence, tracking certificate renewals, screening counterparties, or drafting the annual filing. These are different workflows, owned by different people, carrying different consequences when they fail, and demanding different degrees of human oversight. A system built for one is useless for another. The request, as spoken, does not choose between them.
What the request does reliably record is that someone inside the organisation has noticed something. A cost has become visible. A risk has come close. A bottleneck has finally been felt at a level where budgets live. That noticing is genuine and it matters, because nothing happens without it. But it is a symptom presented in borrowed vocabulary, and treating it as a brief is how a company ends up with a capable system pointed at the wrong work.
The discipline that prevents this is translation, and it has a fixed anatomy. Which workflow does the noticed problem actually live in. Who owns that workflow and experiences its failure. What is the consequence when it goes wrong, in time, money, risk, or standing. Where must the boundary sit between what a system may do and what must remain a person's judgement. And what, concretely, is the next step the organisation will commit to in order to find out. Until those five are answered, no technology decision is legitimate, because there is nothing yet to decide about.
There is a reason this step gets skipped, and it deserves sympathy rather than scorn. Translation is unglamorous. It produces no demonstration, no screenshot, no announcement. It is also the step where an organisation is forced to articulate what has always been implicit, which is uncomfortable work, and frequently where the most considerable value of the whole exercise is created, well before any system runs.
A compliance request, translated
A pattern from our own manufacturing work illustrates the distance between the label and the thing.
The request, as first expressed, was the familiar one: help with compliance, perhaps with AI. Translated, it turned out to mean something precise. A supplier to a global retail customer must keep a large body of documentation continuously verified against that customer's supplier code: certificates with renewal windows, requirements that change without ceremony, records spread across departments. The workflow's owner sat in the compliance and HR function, not in IT. The consequence of failure was concrete and severe, since a lapsed certificate or a missed change can stop dispatch. And the boundary was non-negotiable: nothing would be sent onward to the customer without a person's review.
Notice what the translation produced. Not a technology preference, but a specification. A verification workflow, running continuously against a defined document set and rule set, surfacing exceptions to a named owner, with human review built into the architecture at the one point where the consequence lives. The system that was then built could be tested against that specification, measured against the workflow's previous state, and governed at its stated boundary. Renewal deadlines and requirement changes stopped depending on anyone's memory, and the verification cycle moved from days of manual checking toward same-day. None of that was available inside the phrase "AI for compliance". All of it was latent in the workflow the phrase was pointing at.
The same anatomy holds in a sector with nothing on the surface in common. In one premium residential property market, the request arrived sounding like a chatbot: something to answer enquiries. Translated, it was a coordination workflow. Buyers, tenants, and sellers raise queries at all hours; viewings must be scheduled against several diaries; management wants structured reporting on what the market is asking; and certain steps, terms and conditions above all, require explicit approval before anything proceeds. The system that answers to that translation is not a widget on a website. It is a governed concierge, conversational at the front and procedural behind, with an approval boundary exactly where the commercial risk sits. We have described that pattern, and why premium brands in particular need it, at length. Two sectors, one method, which is the property that makes the method worth codifying.
How to run the translation inside your own organisation
For the enterprise reader, the practical question is what this discipline looks like from the inside, before any vendor is in the room. Three practices carry most of it.
The first is to write the problem down at workflow level and refuse the thematic version. "We want to improve efficiency" is a mood. A workable statement names the work: which team, doing what, taking how long, failing how, costing what. If the statement cannot yet name the owner and the consequence, the organisation does not have an AI opportunity; it has a diagnostic task, which is cheaper and should come first. The standard to hold yourself to is that someone who was not in the room could read the statement and understand what is happening, to whom, and why it matters.
The second is to put the right two people in the conversation from the beginning: one person who does the work daily and can describe where it actually breaks, and one person who owns the outcome and can commit to change. Most stalled initiatives trace to a gap here. An enthusiastic sponsor without an operator produces a system designed for an imagined workflow. An operator without a sponsor produces a diagnosis nobody acts on. Adjacent functions, IT, security, legal, matter later and should be named early, but the operator and the owner are the two without whom nothing true can be specified.
The third is to demand a committed next step rather than a sentiment. "This sounds interesting, let's reconnect" carries no information. "The workflow owner will bring two of her reviewers to a working session on Thursday and share sample documents beforehand" carries a great deal. Inside your own organisation, apply the same test to yourself: if no one is willing to give the problem two hours and a sample of real material, the noticing has not yet matured into a mandate, and no vendor should be invited in.
None of this requires a consultant or a framework licence. It requires the patience to hold the technology conversation closed until the workflow conversation is finished, which is harder than it sounds, because the technology conversation is the enjoyable one.
Where the work actually begins
Translation decides whether the right thing gets built. It does not decide whether the right thing works, and this is the half of the subject that qualification thinking, written mostly from the seller's side, tends to leave off. Deployment has its own anatomy, and three of its parts deserve naming.
The first is the mandate: what the system may do, where its authority stops, and what happens at the edge, settled in the architecture rather than in a policy document. The second is adoption, which is decided in the design and never repaired by training at the end. A system that asks the people in the workflow for more effort than it returns will be used precisely as long as someone is watching, and no rollout communication changes that arithmetic. We have set out the full set of questions a buyer should put to any vendor on these points, ourselves included, and they are the fastest available probe of whether a vendor has genuinely deployed before.
The third part is the one experience teaches hardest, and it is the reason a serious engagement cannot end at go-live. A deployed system changes the tempo of the workflow it enters, and the operating rhythm around that workflow was tuned to the old tempo.
In one engagement, an automated quotation workflow compressed a cycle that had taken around three days into minutes. The system performed exactly as specified. But the commercial processes downstream, the follow-up cadence, the pipeline assumptions, the expectations about what a faster quotation would do on its own, had all been built for a three-day world. Speed, it turned out, is an input. Converting it into orders required redesigning the follow-up rhythm around the new tempo, and resetting, deliberately, what the system was and was not expected to change. Faster quotations shorten the lead-to-quote cycle; they do not, by themselves, close deals, and an organisation that has never had same-hour quotations has no practised motion for exploiting them.
The general lesson is structural, and we now treat it as part of scope rather than as an afterthought. When a workflow accelerates by an order of magnitude, the workflows adjacent to it must be re-examined, because they were designed around the constraint that has just been removed. This is operating-model work, consultative and human, and it belongs inside the engagement, which is precisely where a tool becomes an outcome: the moment the conversation moves from what the system does to what the surrounding operation now achieves. A vendor whose responsibility ends at the system boundary has delivered a component. The outcome lives in the rhythm around it.
The asset nobody requested
There is a further return on translation-led deployment, and it is the one that compounds quietly. A system specified against a real workflow does not only complete the work. It accumulates a structured record of how the work was decided: which exceptions were granted and why, which configurations were approved, what the market asked for and how the organisation answered. The most valuable outcome of a deployment is frequently this structured operational knowledge, rather than the automation that produced it, because the knowledge retains its value even if the system that created it were switched off tomorrow.
No enterprise asks for this in the original request, for the simple reason that no one requests what they have never had. It arrives as a by-product of doing the translation properly, and it changes the economics of the engagement over time: the second workflow starts from a mapped operation rather than a blank sheet, and the record deepens with every cycle the system runs.
What this means for an evaluation
For an enterprise weighing a partner, ourselves included, the practical use of all this is a test that can be run in the first meeting, before any commercial commitment exists.
Present the request in exactly the vague form it currently has inside your organisation, and watch what happens next. A response that reaches for a demonstration has accepted the label at face value, and everything downstream inherits that error. A response that reaches for the workflow, who owns this, where does it fail, what does failure cost, what must never be automated, is performing the translation in front of you, and the quality of those questions is the most reliable early evidence available about the quality of the eventual system. Ask as well how the engagement treats the period after go-live, and specifically whether the operating changes around the system sit inside or outside its scope, because the answer separates vendors who deliver software from partners who deliver an outcome.
In privacy-conscious, regulated markets this test carries additional weight, because the translation is also where governance is decided, and governance now precedes capability in the enterprise buying decision. The boundary between machine action and human judgement, the residency and retention of the data involved, the record available to an auditor: all of these are properties of the translated workflow, and none of them can be retrofitted onto a system built from the label alone. An organisation that lets a vendor skip the translation has not merely risked a weak deployment. It has deferred its governance decisions to whatever the demonstration happened to assume.
In closing
The MIT figure will be quoted for years as evidence that enterprise AI disappoints, and we have written elsewhere about the delivery patterns that get deployments past that failure rate. The reading we would offer is narrower and more useful: initiatives fail at the rate their requests go untranslated.
An AI request, however confidently phrased, establishes one fact, that a business has noticed a problem. Everything that determines the outcome is settled in the work that follows: the workflow named, the owner identified, the consequence priced, the boundary drawn, the baseline recorded, and the operating rhythm redesigned around the system once it runs. For the enterprise, the actionable version is short. Hold the technology conversation closed until the workflow conversation is finished. Put an operator and an owner in the room. Accept nothing vaguer than a committed next step, from a vendor or from yourselves. And judge every partner in this category by how much of the translation they insist on doing before they show you anything at all.
—
Mitochondria is an agentic AI product company based in Amsterdam and Pune. ISO 27001:2022 certified. Classified within the limited and minimal risk tiers of the EU AI Act, with controls aligned to the GDPR, UK GDPR and India's DPDP Act.