The Missing Operating Model for Enterprise AI Adoption

I once watched a brilliant AI pilot die in a meeting room with six people, three dashboards, and no owner.

The model worked. The demo worked. The vendor deck definitely worked. But enterprise AI adoption doesn’t fail because the tool can’t generate an answer; it fails because nobody has redesigned the messy human system around that answer.

I’ve built automation tools that looked beautiful in a showcase and then got quietly ignored by the operations team two weeks later.

Not because the team was resistant. Not because they “didn’t get innovation”.

Because at 2:13pm on a Tuesday, when a network exception landed, the person on the floor still had to reconcile three systems, chase an approval, screenshot evidence, and explain the decision to someone who didn’t trust the AI output.

That’s where transformation goes to die.

The AI Tool Is Not the Transformation

Right now, the market is obsessed with capability.

Agents that research for eight hours and produce 100-page strategy reports. Coding assistants that generate pipelines from prompts. Data platforms promising to remove the ancient pain of stitching operational and analytical systems together.

All useful. Some of it genuinely impressive.

But I’m going to say the quiet part loudly: most enterprises don’t have an AI tooling problem. They have an operating model problem.

Tooling gives you possibility. An operating model gives you repeatability.

Without that, every AI initiative becomes a one-off science experiment with a nice Confluence page and a slowly decaying Teams channel.

I’ve seen this pattern in telco, infrastructure, service operations, and automation CoEs. A team gets access to a powerful new platform. They build a prototype. The prototype creates excitement. Then the questions start.

Who owns the output?

Who signs off the risk?

Who maintains the prompt, workflow, data mapping, access controls, exception handling, and audit trail?

Who gets paged when the AI confidently does something stupid?

Silence.

That silence is the missing operating model.

Why This Matters More Now

AI is no longer sitting neatly inside the innovation team.

It’s leaking into procurement, engineering, field operations, finance, customer experience, HR, legal, and every spreadsheet with a “can we automate this?” comment attached.

That’s good. It means people are pulling technology into real work.

It’s also dangerous, because the enterprise now has two AI adoption curves: the official one and the hidden one.

Recent research from Ivanti suggested a funny but uncomfortable gap: plenty of IT teams believe AI agents are under control, yet far fewer people actually know who owns them. That tracks with what I see.

Shadow AI isn’t always malicious. Often it’s just a smart employee trying to survive a broken workflow.

They use a public tool to summarise a contract because the internal knowledge base is painful. They build a quick script because the approved automation backlog is nine months long. They ask an agent to generate analysis because the reporting team is drowning.

Then leadership discovers “AI usage” and reacts with either panic or a hackathon.

Neither is an operating model.

The Part Nobody Talks About: AI Creates Work Before It Removes Work

This is the bit that annoys people.

AI does not magically remove work on day one. It changes the shape of work first.

When I’ve implemented automation in operational environments, the first productivity gain is rarely “we deleted ten steps”. More often, it’s “we exposed the ugly truth about the process”.

The exception rules weren’t documented. The data owners disagreed. The approval path was tribal knowledge. The dashboard was trusted, but nobody knew how the metric was calculated.

AI is brutal at revealing organisational ambiguity.

A human can navigate ambiguity with a shrug, a phone call, and a “yeah, that’s how we usually do it”. An AI system needs the organisation to decide what “usually” means.

That decision work is real work.

This is why “vibe coding” can build your data pipeline, but it can’t explain six months later why a transformation rule exists, who approved it, what downstream report depends on it, or what happens when the source schema changes.

Speed without memory becomes technical debt with better branding.

My Operating Model Test: Can It Survive Monday Morning?

I don’t judge AI adoption by the demo anymore.

I judge it by Monday morning.

Can the workflow survive when the usual SME is on leave? Can a frontline team challenge the output? Can risk teams see the evidence? Can technology teams monitor failure modes? Can a new starter understand why the process behaves the way it does?

If not, you don’t have transformation. You have theatre.

In telco operations, the real world is not a clean prompt. It’s delayed data, conflicting inventory, ageing systems, customer impact, regulatory obligations, and a human trying to make the least-worst decision quickly.

That’s why the operating model matters.

It turns AI from a clever assistant into a dependable part of the business system.

What an Enterprise AI Operating Model Actually Needs

Here’s the practical version. Not a 90-page framework. Not a maturity model with pastel circles.

If you want enterprise AI adoption to stick, you need six things.

1. Clear ownership, not vague sponsorship

Every AI use case needs a named business owner, technology owner, data owner, and risk owner.

Not a committee. Not “the AI team”. Real people.

The business owner is accountable for the decision outcome. The technology owner is accountable for reliability. The data owner is accountable for input quality and access. The risk owner is accountable for controls, auditability, and acceptable use.

If you can’t name those people, don’t scale the use case.

2. Workflow redesign before model selection

Most teams start with “which AI tool should we buy?”

This is backwards.

Start with the work. Map the current decision flow. Find the handoffs, delays, rework, approvals, judgement points, and evidence requirements.

Then decide where AI belongs.

Sometimes the right answer is a large language model. Sometimes it’s a rules engine, a better integration, a data quality fix, or deleting a pointless approval step that everyone hates.

AI should not be used as expensive duct tape for bad process design.

3. A decision rights model for humans and machines

This is where many pilots get mushy.

Is the AI recommending, drafting, deciding, escalating, or acting autonomously?

Those are different risk categories.

An AI agent summarising internal documents is not the same as an agent triggering a customer action, changing a network configuration, or approving a financial transaction.

You need explicit decision rights.

Where must a human approve? Where can the system act? Where does confidence level matter? What conditions force escalation? What evidence must be retained?

Write it down. Boring wins.

4. Data contracts, not data vibes

I’m excited by platforms trying to solve the long-running split between operational and analytical data. Databricks and others are right to attack that problem because latency, duplication, and brittle pipelines slow down AI systems badly.

But platform improvements don’t remove the need for organisational agreements.

AI needs data contracts: what the data means, who owns it, freshness expectations, quality thresholds, allowed uses, retention rules, and downstream dependencies.

Without that, your shiny agent becomes a very confident intern reading from a messy filing cabinet.

5. Lifecycle management for prompts, agents, and automations

Enterprises are used to managing applications. They are less mature at managing prompts, embeddings, AI workflows, evaluation sets, and agent behaviours.

That has to change.

Your AI assets need version control, testing, release gates, monitoring, rollback paths, and retirement criteria.

Yes, even the prompt.

Especially the prompt.

A prompt embedded in a workflow is business logic. Treat it like business logic.

6. A learning loop that reaches the frontline

This might be the most important one.

The people closest to the work will spot AI failure before your steering committee does.

Give them a simple way to flag bad outputs, suggest improvements, challenge assumptions, and see what changed because of their feedback.

If feedback disappears into a black hole, adoption dies quietly.

Frontline trust is not built by town halls. It’s built when someone says, “This output is wrong,” and the system gets better.

The Harder Truth: AI Will Change the Shape of Organisations

Satya Nadella recently warned that AI could hollow out industries if value pools collapse into a handful of frontier models. I think that warning matters, but the enterprise version is more immediate.

AI can hollow out capability inside your own organisation if you outsource too much thinking to tools you don’t understand.

If your analysts stop learning how the business works because the agent writes the report, you have a problem.

If your engineers accept generated code without understanding operational consequences, you have a problem.

If your leaders consume AI-generated strategy without knowing which assumptions were wrong, stale, or missing, you have a problem.

The goal is not to replace organisational intelligence with artificial intelligence.

The goal is to compound it.

That requires deliberate design: what we automate, what we augment, what we preserve, and what we teach the next generation of workers to master.

Otherwise, we’ll create companies that move faster and understand less.

That is not transformation. That is fragility.

The Builder’s Rule: Don’t Scale What You Can’t Explain

Here’s a rule I use now.

Don’t scale what you can’t explain.

If the team can’t explain how the AI works at a business level, don’t scale it.

If nobody can explain what data it relies on, don’t scale it.

If nobody can explain who owns the decision, don’t scale it.

If nobody can explain what happens when it fails, definitely don’t scale it.

This isn’t anti-innovation. It’s how you keep innovation alive after the demo budget runs out.

I’ve learned this the annoying way: by building things that were technically correct but operationally homeless.

The code worked. The workflow didn’t.

That lesson sticks.

What Actually Works in Enterprise AI Adoption

The organisations that will win with AI won’t be the ones with the most pilots.

They’ll be the ones that turn learning into operating muscle.

Start small, but not casually. Pick a workflow with real pain, real users, and measurable outcomes. Keep it close enough to production that the mess shows up early.

Build a cross-functional squad around the work, not the tool. Include the process owner, frontline users, data people, engineers, risk, security, and change leads.

Define the decision rights before the model goes live. Decide what the AI can recommend, draft, decide, or trigger.

Instrument the workflow. Measure adoption, exception rates, overrides, cycle time, user trust, data quality, and failure patterns.

Then improve it like a product.

Not a project. A product.

Because AI systems drift. Business rules change. Data changes. Users learn new behaviours. Risk appetite shifts. The operating model has to keep moving.

That’s the difference between buying AI and becoming AI-capable.

Final Thought: The Future Belongs to the Boring Builders

I love the tools. I really do.

I like seeing agents reason across documents, platforms reduce data friction, and coding assistants remove repetitive engineering grunt work. The builder in me gets excited every time the ceiling moves.

But the executive in me has become deeply suspicious of tool-led transformation.

Because the hard part is not generating the answer.

The hard part is changing how a large organisation trusts, governs, improves, challenges, and acts on that answer.

That’s the missing operating model for enterprise AI adoption.

It’s less glamorous than a keynote demo. It has more RACI charts than anyone wants. It involves awkward conversations about ownership, controls, data quality, and whether the current process makes any sense.

But it’s where the value is.

The future won’t belong to the enterprise with the flashiest AI stack.

It’ll belong to the boring builders who can make AI useful on Monday morning, explain it six months later, and improve it every week after that.

That’s the work.

— Jack Hui
More thoughts on enterprise AI, automation and digital transformation at jackhui.com.au