cd /news/artificial-intelligence/four-versions-of-the-truth-and-no-ow… · home topics artificial-intelligence article
[ARTICLE · art-87175] src=forbes.com.au ↗ pub= topic=artificial-intelligence verified=true sentiment=· neutral

Four versions of the truth and no owner: AI’s ‘deployment debt’

A new form of organizational debt, termed 'deployment debt,' arises when companies deploy AI without redesigning accountability and workflows, according to Lucio Ribeiro, writing for Forbes Australia. Ribeiro cites examples such as Australian hospitals' ramping issue and a TV newsroom's AI tool, highlighting that while usage increases, the operating model fails to govern outputs, leading to rework and contradictory results. He distinguishes deployment debt from technical debt, noting it stems from a lack of clear ownership and decision rights.

read7 min views1 publishedAug 5, 2026
Four versions of the truth and no owner: AI’s ‘deployment debt’
Image: Forbes (auto-discovered)

Opinion: As companies rush to deploy AI, a new kind of organisational debt is building: capability without clear ownership, workflow or accountability, argues Lucio Ribeiro

Last year in South Australia, ambulances spent close to 49,000 hours parked outside hospitals with patients still inside. Six years earlier, the figure was around 15,000.

Paramedics kept monitoring patients and providing care. What the system couldn’t do was take them in. Beds were full, with every nurse already holding someone. So care continued in the ambulance bay, expensive and caught between parts of the system.

Hospitals call this ramping. It looks like an ambulance problem, but it’s really a failure of the operating model behind the hospital doors. The constraint is structural. If hospitals cannot move patients through the system, adding more ambulances only lengthens the queue. Blaming ambulances for ramping is like blaming traffic for a roadblock.

I’ve started seeing the same pattern inside companies that have gone all in on AI: blame is allocated to the tools rather than to the structural changes that are needed.

Can the organisation keep up?

Years ago, at one of Australia’s major television networks, I watched a newsroom successfully introduce technology that could tag and clip archive footage for digital and social channels.

Tasks that once took much of a morning could suddenly be completed in minutes, and the volume of content increased rapidly, to the point where some of the folks were celebrating being one of the most engaged brands on TikTok.

Then came the less glamorous questions. Did the network hold digital rights to every clip retrieved? Who checked the context? And who was responsible when speed moved content beyond the workflow designed to govern it?

I was part of the enthusiasm in that newsroom, and we didn’t spend nearly enough time asking whether the organisation behind it could keep up. We had improved the speed of production without redesigning the speed of responsibility. The capability arrived but the capacity to hold it didn’t.

The same pattern is playing out across other industries. A firm rolls out copilots, stands up agents, buys seats for the whole floor and sends adoption numbers upwards with pride. Usage is high. Underneath, something’s missing.

The work keeps arriving

As I wrote in my last Forbes column, most organisations are still optimising for the last phase of AI. Two teams answer the same customer question differently, both citing the tool. An AI-generated contract clause reaches a client before approval. An agent completes a task, but nobody knows where the decision belongs or who remains accountable. The work keeps arriving. The organisation behind it can’t take it in.

This is deployment debt: the gap between what you’ve switched on and what your operating model can govern and turn into accountable work.

Like any debt, its early benefits are visible, and the obligations arrive later – rework, duplicated licences, contradictory outputs and four versions of the truth with no owner.

Deployment Debt Isn’t Technical Debt

Technical debt refers to software shortcuts: fragile code and ageing systems that get harder to maintain.

Deployment debt sits elsewhere. It forms between a new capability and the organisation expected to use it. The technology may work exactly as promised. The failure appears because responsibilities and decision rights were never redesigned around what it can now do.

Technical debt produces brittle systems but deployment debt produces work with no clear owner or review path.

David Gatt, group managing director at Omnicom Oceania, described the mechanism in The Australian: “Accelerating disconnected systems simply creates disconnected organisations faster. AI exposes the fragmentation that was already there.”

The bill eventually arrives

The first wave of enterprise AI made experimentation and deployment feel cheap. Tools were easy to trial, and the cost could disappear inside existing technology budgets. The economics change as experimentation becomes infrastructure. The real cost is no longer the licence or the price of a token. It includes integration, security, human review and the systems needed to watch what other systems are doing.

Individual task costs may even fall as smaller models improve. The bill grows because indiscriminate deployment gets harder to defend, when unnecessary seats and duplicated workflows create recurring costs. Deployment debt used to be paid in confusion. Increasingly, it will be paid in dollars, monthly, whether the capability creates value or not.

MIT’s Networked AI Agents in a Decentralised Architecture (NANDA) initiative interviewed 150 leaders and surveyed 350 employees across more than 300 AI deployments. It found the models were capable enough and that what most organisations lacked was integration into real workflows. Companies bought capability and skipped integration. That’s deployment debt at enterprise scale.

Why restraint looks like weakness

Which brings me to a word my Forbes editor once flagged and that’s worth rescuing: restraint.

In most boardrooms, restraint sounds like caution. But restraint is also arithmetic. It asks how much output the organisation can absorb, and how many systems it can govern before oversight becomes its own layer of administration. Capacity remains finite even when compute appears abundant.

The companies that look boldest with AI may be the ones exercising restraint you can’t see. They built the plumbing (operating model) before they opened the tap. The companies spraying tools across every function may simply be mistaking motion for courage.

Restraint appears as an absence: the project that didn’t launch, the licence not bought because no one could explain what would happen to its output. No performance review has a line for the breakage you prevented. So, the competence that protects the most value is often the one the organisation can’t see and won’t reward.

Deployment debt rarely arrives as one catastrophic failure. It accumulates through coordination failure, duplicate effort, accountability gaps and compliance exposure. Five copilots produce five confident answers, and someone loses Thursday choosing one. A decision has a speed and a source but no signature. Output reaches a customer before review reaches it. These costs create rework and erase the productivity gains that justified the tool.

The four conditions of AI deployment

None of this argues for going slowly. The discipline is to make organisational readiness a condition of deployment.

Before an AI tool or agent goes wide, leaders should answer four questions.

  1. Owner: Who remains accountable for what this system produces?

  2. Workflow: Where does its output enter the organisation’s existing work?

  3. Gate: Who reviews or approves it before someone acts?

  4. Measure: What cost or business outcome should improve?

A good answer names a person and a decision point. It describes what happens when the output conflicts with another system, and how the organisation will know whether the capability is creating value rather than activity. If the answer is the enthusiasm of whoever bought the licence, you’re accruing deployment debt at a rate you haven’t priced.

Ramping didn’t ease because South Australia found more ambulances. It eased when the hospitals became better able to receive what was arriving.

AI is the same problem, moving faster and with no siren. The real test is not how much capability an organisation can switch on, but how much accountable work it can actually absorb.

Lucio Ribeiro is an artificial intelligence keynote speaker, educator and entrepreneur based in Melbourne, Australia. He writes on AI for Forbes Australia, lectures in AI at RMIT University, and holds executive certifications in AI and innovation from MIT Sloan. He has led AI and innovation at Optus, Seven West Media and Nine, and is Chief AI & Innovation Officer at Omnicom TBWA Australia.

*Want to see more Forbes articles on your feed? *Tap here to make Forbes Australia a preferred source on Google.

Look back on the week that was with hand-picked articles from Australia and around the world. Sign up to the Forbes Australia newsletter here or become a member here.

── more in #artificial-intelligence 4 stories · sorted by recency
── more on @lucio ribeiro 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/four-versions-of-the…] indexed:0 read:7min 2026-08-05 ·