A note for IT heads and CIOs evaluating AI for IT operations

If you run IT for an enterprise, you've probably sat through a dozen AI pitches this year. And I'd bet almost every one of them made the same claim, in different words: we already have your enterprise context.

The ITSM platform says it. The asset management tool says it. The identity and access vendor says it. Every new conversational service desk and AI agent says it. Deploy us, connect us to your systems, and outcomes will follow.

I've spent my career on the delivery side of enterprise IT, and I don't believe any of them. Not because the tools are bad (most of them are very good at what they do), but because the context you actually need was never in any of them to begin with.

Your systems know the "what." None of them knows the "why."

Walk through your own stack honestly.

Open a closed ticket in your ITSM. You'll find a problem statement and a resolution note that says "issue resolved." It records that something was fixed. It doesn't record the judgment call, the three things the engineer ruled out first, or why this fix works in your environment and wouldn't in another.

Your asset system knows who has which laptop and which licence. It doesn't know why they have it.

Your identity layer knows a particular VP has access to a particular module. It doesn't know why that privilege was granted, or what breaks if you take it away.

Your change policy says a production firewall change needs CIO approval. What it doesn't capture is how that actually works in practice: it goes to the infra head first, then the CISO, then to you. And each of those people is checking for something specific that's written down nowhere.

Every system of record holds the final state and the stated policy. Not one of them holds the reasoning that got you there.

So, when every software vendor in your stack tells you they have your enterprise context, here's how I'd read that claim. Each of them has state: a real, accurate snapshot of their slice of your environment. The ITSM has ticket state. The asset tool has inventory state. The identity platform has access state. The approval engine has workflow state.

But the sum of states is not the context. Context is the reasoning that connects those states: why they are the way they are, and what should happen next. Add up every snapshot you own, and you still won't have it.

Your real context lives in your people

Much of how your IT organisation actually runs isn't documented. It isn't even formal policy. It's tribal knowledge, held by your service desk leads, your program managers, the IT managers and partner teams who've been inside your organisation for years, sometimes decades.

Nobody ever built software whose job was to capture that reasoning. So it accumulated in people instead. You already know this: it's why losing one long-tenured engineer can hurt more than losing a system.

And it's why the current rush won't work. The instinct is to take an identity engine, an ITSM, an asset tool and a conversational layer, wire them together, and call it enterprise context. But stitching together fragments of what doesn't produce why. The why was never in the fragments.

Context can only be built by doing

There's no shortcut here. The only way to build real enterprise context is to learn it by doing the work, not by connecting tools.

No enterprise is going to automate every IT function on day one, and none should try. You start somewhere: one function, one process, one approval flow. Every time a request comes in that the AI has no path for, a person on your team handles it, and in doing so, the knowledge in their head becomes part of the system. The next time that request arrives, the path exists.

Over months and years, function by function, the context accumulates. It doesn't get bought. It gets earned.

Automation is the incentive. Context is what your team pays for it.

Why would your people hand over knowledge that took them years to build? Because they get something they genuinely want in return: automation. Time back. Fewer repetitive tickets. Better experience for the users they support. Room to do more meaningful work.

That's the exchange. The system gives your team time; your team gives the system context. Every exception handled is context captured, and the whole thing compounds.

Which leads to the point I'd most like IT leaders to take away: the automation is the incentive, but the real product is your enterprise context. Automation is how it gets built. The context is the asset that stays, and it belongs to you.

You've done this before

If this sounds familiar, it should. It's exactly what happens when you bring in a new managed services partner.

You don't expect miracles in week one. You establish processes together. You give them time. Their people learn how your environment actually behaves, they build runbooks and artifacts, and the knowledge grows. When individuals rotate out, the context doesn't walk out with them. Continuity holds.

AI in IT operations should follow the same path. The difference is that instead of a team of people, you're building a fleet of AI agents, one function at a time, and every agent shares the context your organisation has accumulated along the way.

So here's my suggestion for your next AI evaluation. Be wary of any tool that promises outcomes the moment it's switched on. Ask instead: how will this learn the way we actually work, and who keeps that knowledge when it does?

Enterprise context has never been installed. It's always been built, patiently, by doing the work.

That's still the only way.