And Then IT Walked In: The Technical Veto Theory of AI Adoption

There is a moment in AI adoption that almost never appears in the post mortem. The CEO has a view. The CFO can see a return that is not absurd. HR understands that the people side will decide whether anything sticks. A business unit has a real workflow problem rather than a conference stage use case. Someone has named two or three champions credible enough to carry a pilot through the middle of the organisation, which is where good ideas usually go to be diluted. The early maths is not clean, but it is good enough to justify a serious look. The room has moved from abstraction to possibility.

And then IT walks in.

That sentence will annoy people, so let me be precise. This is not an argument against IT. AI without technical discipline is theatre, AI without security is negligence, and a clever model with no integration path becomes an orphaned browser tab that procurement renews for three years without remembering why. Any serious deployment needs IT at the table, early. The problem is not that IT enters the conversation. The problem is where it enters, and with what mandate.

The sequence, and the reversal

The proper adoption sequence is less glamorous than anyone wants it to be. You start by assessing readiness across three things at once: data, people, and systems. Not data alone, because plenty of companies hold data that nobody is willing to act on. Not people alone, because enthusiasm without data produces workshops and slogans. Not systems alone, because a clean stack attached to a weak business case is still a weak business case.

The useful work sits in the intersection. Where is there enough data to create signal, enough human ownership to change behaviour, and enough system flexibility to deploy without building an operational monster. That is the first screen. Only then do you find the champions, map candidate pilots, size the value of each, test feasibility, and decide where to start.

Most companies claim to follow that logic. In practice many reverse it. They begin with what the estate can tolerate, then define the AI opportunity around it. That sounds responsible, and sometimes it is. Often it is risk aversion with better vocabulary.

The system-first company stops asking where AI changes the economics of the work, and starts asking where AI can be inserted without forcing anyone to confront the fact that the data layer, the workflows, the incentives, and the operating model were never designed for this. That is a different question, and it produces different pilots.

Readiness has become a polite word for delay

Companies say they are not ready because the data is fragmented, the ERP is old, the CRM fields are inconsistent, process definitions vary by region, and the permissions model needs work. All of that is usually true. It is also true of almost every mid-market company on earth, and it will still be true in three years.

If enterprise-wide readiness is the threshold, nothing ever starts. The better question is narrower and answerable. Does one specific workflow, in one part of the organisation, with one accountable owner, carry enough readiness to justify a bounded intervention. Adoption does not begin with the enterprise becoming modern. It begins where value, data, people, and feasibility overlap enough to create a learning loop.

The diagnostic habit here is the same one used for operating capability generally, and the sequencing logic in the operating maturity index transfers directly: assess the specific function, not the company in the abstract, and intervene where the gap is load bearing.

The veto test

Here is the line I would put in the governance document, because it is the only one that survives contact with a steering committee.

A technical no is a technical judgment only if it names the price of yes.

A legitimate refusal sounds like this. Doing it in the core ERP costs roughly four hundred thousand and nine months, because the master data has to be reconciled first. Doing it in a sandbox against a nightly extract costs twenty thousand and six weeks, carries a defined data exposure, and cannot scale past two hundred users. That is a real answer. It gives the CFO something to price and the CEO something to decide.

An illegitimate refusal sounds like this. The systems are not ready. That is not an assessment. It is a boundary, and it is being defended with the vocabulary of assessment.

The test cuts both ways, which is why it works. It protects IT from being overruled by enthusiasm, because a costed no is very hard to steamroll. And it protects the business from being blocked by a preference, because a no without a number can always be sent back for one. Make it a standing rule that no AI use case is killed on technical grounds without a written price and a timeline, and roughly half of the vetoes in a typical portfolio company convert into a scoped, cheaper version of the same idea.

Which pilots look wrong and are right

The unpopular corollary is that some of the best pilots look technically awkward at the start. They sit in an ugly workflow, lean on partial manual bridges, begin with imperfect data, and need a human in the loop longer than the technologists would like. They offend the architecture diagram. If they attack a real economic problem and produce measurable learning, they may still be exactly the right place to begin.

Meanwhile some of the worst pilots look pristine. They integrate neatly, pass security review, carry excellent documentation, produce handsome dashboards, and remain completely forgettable.

AI is being misclassified, and that is what breaks the ownership model

AI is not a technology layer. It is an operating capability that happens to require technology, and the distinction changes who owns it. A technology layer can be delegated. An operating capability cannot.

If AI changes how analysts diligence a deal, how sales teams prioritise leads, how finance forecasts cash, how service teams resolve cases, or how boards see risk, then the work belongs to the business at least as much as to IT. Asking IT to own AI transformation is like asking the facilities team to set hybrid work strategy because they manage the office. Essential to the answer. Not the answer.

Each seat carries a different burden, and the programme distorts the moment one of them absorbs the whole question.

The governance model that works is not business-led in the shallow sense, where business people pick dreams and IT cleans up afterwards. It is business-led, finance-tested, human-enabled, IT-shaped, and operator-owned. Business-led means the use case starts from a real economic problem. Finance-tested means the value logic survives scrutiny. Human-enabled means the adoption path is designed around actual people rather than imaginary users in a transformation deck. IT-shaped means the technical path is honest about constraints. Operator-owned means someone close enough to the work is accountable for whether behaviour changes. That last one is the same accountability structure argued for in the operating partner and CEO compact, and for the same reason.

In a hold period, the clock does the arguing for you

This matters more in private equity than in a corporate, because the clock is not theoretical. A portfolio company does not have eighteen months to become ready for a pilot that may or may not touch EBITDA before exit. The hold period is the forcing function.

If a use case cannot plausibly improve margin, growth, risk visibility, decision speed, or the exit narrative inside the relevant window, it is not a value creation initiative. It may still be useful and strategically interesting. It should not be confused with investment-grade AI. The point is not to implement AI. The point is to convert capital into time, margin, growth, or optionality faster than the next owner expects, which is the same discipline applied to the value plan itself in the thesis operating system.

Two practical consequences follow for a sponsor. First, the veto test belongs in the hundred-day plan, not in the technology workstream, because a costed no is a capital allocation decision and should reach the board as one. Second, the same displaceable, compressible, insulated logic used to grade a target's revenue in the disruption column works inside the company as a pilot filter. Attack the compressible work first. It has the clearest baseline and the least organisational resistance.

The founder version of the same mistake

There is a mirror image of this problem on the vendor side, and it is worth naming because operators sit through it weekly.

Many founders building AI applications for investors and corporates start from the technology rather than the operating reality. They walk through the model, the orchestration layer, the agents, the embeddings, the integrations, the architecture, and then somewhere near the end they try to attach the product to a business problem. That order is revealing. It usually means they understand the tool better than the world the tool is supposed to enter.

The jargon makes it worse. Agents, copilots, orchestration, vector databases, context windows, retrieval layers, synthetic data, human-in-the-loop governance. Many of these are real and some matter a great deal, but when every meeting becomes a translation exercise, the business buyer quietly checks out. In a sponsor context the language that lands is diligence cycle time, pricing power, churn, working capital, CAC payback, gross margin, revenue per head, covenant headroom, and buyer-grade evidence. In a corporate context it is throughput, adoption, control, compliance, cost, service levels, employee trust, and decision velocity. A company that cannot translate its own capability into those terms is not enterprise-ready. It is merely technically literate. The same translation gap, viewed from the buy side, is what underwriting the AI-native target is built to expose.

Where it actually dies

AI never fails in the abstract. It fails in workflow. It fails when the sales manager does not trust the recommendation. When the finance team exports the dashboard to a spreadsheet and rebuilds the answer by hand. When the field team reads the tool as surveillance. When the data owner will not fix the taxonomy because nobody changed the incentive. When the pilot sits between two functions and neither wants the burden of making it real. It fails when the steering committee celebrates deployment and forgets that deployment is the beginning of adoption rather than the end of it.

So yes, IT should walk in. At the right moment, with the right mandate. Not as the department that converts every AI question into a systems constraint. Not as the holder of a veto over ambition. Not as the function that protects the organisation from the discomfort of changing how work gets done. IT should walk in as the builder of the bridge, after the business has decided the other side is worth reaching. Sometimes the bridge is expensive. Sometimes the terrain is wrong and the honest answer is no. But no should arrive after the value has been understood, with a price attached, not before the business has learned how to ask the question.

The numbers still have to win. If the financial case does not hold, the bits and bytes will not rescue it. The reverse is also true. If the numbers hold, the people are ready, and the workflow matters, then technical discomfort is a design problem rather than an automatic veto. That is the line between an organisation using IT to govern AI and an organisation using IT to avoid it.

The fix is not to bypass IT, which is childish and dangerous. The fix is to stop confusing the architecture of the system with the architecture of value. One tells you how things connect. The other tells you why the connection is worth making. Most programmes need both. Too many start with only one, and then everyone wonders why the pilot worked in the demo and died in the company.

VCI Institute in collaboration with Mohamad Chahine
Published 2 November 2026

About the VCI Institute

The VCI Institute is a nonprofit dedicated to building practical capability and shared standards for value creation in private equity. The Institute publishes operator-grade frameworks and runs certification programmes for operating partners, portfolio company executives, and value creation analysts. You can see what each programme actually covers before deciding. Analysis published here draws on the Institute's certification curricula and on structured review of mid-market transaction patterns rather than on any single proprietary dataset. Where a figure is directional rather than measured, it is described as such.

Further material is available in the Institute's Insights library and its free resource library of templates, checklists, and case snapshots.

© 2026 VCI Institute. All rights reserved. The frameworks, terminology, and analysis presented in this article are the intellectual property of the VCI Institute. Reproduction or derivative use without written permission is prohibited. Citation with proper attribution is welcomed.