Insights · AI adoption

The value exchange — what AI is allowed to do matters more than what it can do

Every AI deployment is a trade. The organisation hands over data, decision rights and a measure of control in exchange for speed and scale. The organisations getting real value are the ones that decided the terms of that exchange before the first system was wired in.

Consulting News Desk1 September 20264 min readAI adoption

Capability is not the constraint

The conversation about enterprise AI is still dominated by how powerful the models are getting. That framing made sense two years ago, when the question was whether AI could do useful work at all. It is the wrong frame now. For most of the work organisations actually want done — classifying documents, reconciling records, drafting responses, routing requests, summarising cases — the capability has been sufficient for some time.

What separates the organisations extracting value from the ones accumulating pilots is not access to a better model. It is a set of decisions about how AI is used: what it is allowed to touch, what it may decide, what data it sees, and who answers for the outcome. Those decisions are human, and most organisations have not made them explicitly. They have let them be made by default, by whichever team wired up the first integration.

The exchange

It helps to be honest about what is being traded. In exchange for speed, scale and consistency, an organisation gives an AI system three things.

Data. The model or agent sees what it is connected to: the warehouse, the document store, the CRM, the ticket queue. Whether that access is governed — classified, permissioned, logged — or improvised through extracts is the first term of the exchange, and the one most often left unwritten.

Decision rights. Somewhere on the spectrum between “suggests and a person decides” and “acts and a person is notified,” each use case sits at a point. That point should be chosen deliberately, per workflow, according to how reversible and how consequential the action is. Most organisations have never written it down.

Attention. Once a system is trusted to handle the routine, people stop looking at the routine. That is the point — but it means the exceptions the system escalates, and the metrics that show it is still performing, become the only places human judgment is applied. Those need designing.

The question is not what the model can do. It is what you have agreed it may do, on whose data, and who is accountable when it does.

Accountability does not transfer

The most important term is the one that cannot be delegated. When an AI-driven process produces a bad outcome — a wrongly declined claim, a misrouted incident, a customer told something untrue — the organisation is accountable, and inside the organisation a person is. Not the vendor, not the model, and not “the system.”

Mature organisations make that ownership visible in advance. Each agent and each automated decision has a named owner, the way each application and each dataset does. The owner sets the scope, reviews the evaluation results, and is the one who explains an incident. This is not about blame. It is about ensuring someone is actually watching, because unowned automation is the kind that drifts.

Where the terms get written

Here is the part that is easy to miss: the terms of the value exchange are not written in the AI policy document. They are written in the information systems.

What data the model can see is decided by the warehouse’s access model and the catalog’s classification. What actions an agent can take is decided by the roles and APIs the ERP, CRM and ticketing platforms expose to it. Whether an outcome can be traced is decided by whether the action landed in a system of record with a change history, or in a chat transcript nobody will search. Whether accountability is visible is decided by whether the agent inventory sits alongside the user inventory, or in a spreadsheet on someone’s desktop.

This is why AI integration is, in the end, an information-systems discipline. The organisations that already govern their data platform and their systems of record well have most of the machinery for governing AI. They need to extend it, not replace it. The organisations that do not will find that AI inherits every gap they already had, at machine speed.

Choosing not to is a legitimate answer

One more term belongs in the exchange: the option to decline. A use case where the data cannot be governed, the action cannot be reversed, or the accountability cannot be assigned is not a use case that needs a better model. It is one that should wait, and a readiness assessment that says so is doing its job. “Not yet” is a finding, not a failure.

AI will keep getting more capable. That is the least interesting variable in the equation. How an organisation chooses to use it, and who it holds accountable for the results, will decide whether the capability turns into value — or into the next incident review.

Consulting News DeskWeekly notes on AI integration, data foundations, and agentic workflows from the IDMS consulting team — written by the people doing the integration work.