AI Is Moving Faster Than the Operating Model Around It

How much authority did the system have? How consequential was the decision? Could the error be detected? Could it be reversed? What data was involved? How frequently is the system making the decision? What is the potential blast radius?

Those questions matter because the same underlying AI capability can represent radically different levels of business risk depending on where it is deployed.

And right now, I think the promised financial upside of AI is often shining brighter than the operational risk behind it.

We have seen this pattern before

I was working in security during the major cloud-adoption wave of the 2010s, and the pressure felt remarkably similar.

Businesses saw transformational potential in cloud computing and wanted to move quickly. Infrastructure and DevOps teams were understandably focused on getting applications running, delivering new capabilities, and satisfying rapidly growing demand. Meanwhile, security expertise around cloud architectures was still developing.

Organizations eventually learned painful lessons about exposed storage, excessive permissions, poorly configured identity, flat architectures, and insecure defaults.

Too often, security controls arrived after the workload was already running… or after something had gone wrong.

I would prefer that we learn from that history rather than repeat it with AI.

That does not mean security should stand in front of innovation and say no. It means security and engineering should be designing the outcome together from the beginning.

An old construction principle applies well here:

Measure twice, cut once.

Security applied at the end often creates rework, friction, and cost. Security involved during architecture helps engineering reach the desired business outcome without having to rebuild the system afterward.

We do not need to reinvent security because AI is new. We need to learn how established principles apply to a new technology.

AI is not the same thing as automation

Before I ask how to secure an AI use case, I would ask an even simpler question:

Could a human reliably execute this process using a checklist?

If the answer is yes, I would explore traditional automation first.

Organizations increasingly use “AI,” “agentic,” and “automation” almost interchangeably. They are not the same thing.

Traditional automation is generally deterministic.

If this happens, do that.

AI is probabilistic.

Every time we ask an AI system to make a decision, we introduce some amount of uncertainty into the process. I sometimes think about that as a metaphorical dice roll.

That is not an argument against AI.

It is why AI is so valuable for problems where deterministic rules do not work well.

AI is excellent at interpreting large document sets, synthesizing information, correlating signals, generating options, identifying patterns, summarizing complex context, and helping people reason through ambiguity.

But when a rule can be reliably enforced through code, workflow, permissions, or another deterministic mechanism, we should generally prefer that approach.

Let AI reason where ambiguity is real. Let deterministic mechanisms enforce deterministic boundaries and prove the economics

There will absolutely be situations where deterministic approaches cannot scale or where AI genuinely needs to make decisions autonomously.

I am comfortable with that.

But we should recognize the trade we are making. We are accepting additional uncertainty in exchange for scale, capability, or efficiency. That decision deserves stronger governance, not weaker governance. The same scrutiny should apply to the business case.

Suppose someone says:

“This AI agent can eliminate 70% of the manual work in this process.”

My first questions are:  What data proves that, and What was that 70% of manual work actually doing?

Some of it may truly be repetitive toil but some may be quality assurance. Some may be compliance. Some may be a security control. Some may represent judgment that catches unusual situations before they become expensive mistakes.

Removing human labor does not automatically remove cost.

AI also introduces costs that may not be obvious in the first ROI calculation: model inference, tokens, compute, GPUs, orchestration, logging, evaluation, monitoring, exception handling, rework, security controls, and incident response.

So the question should not simply be:

How many human hours can AI eliminate?

It should be:

What is the total cost and risk-adjusted outcome of replacing this part of the process with AI?

Sometimes the answer will still be overwhelmingly positive.

Great. Deploy it… but prove the case rather than assuming that “agentic” automatically means cheaper or better.

Where this leaves us

The first step toward mature AI adoption is not a new policy or another governance board.

It is asking better questions before we build.

Is this actually an AI problem?
What uncertainty are we introducing?
What are we getting in return?
And what happens to the business if the system is wrong?

Those questions do not slow innovation.

They help ensure the organization is solving the right problem with the right technology.

In the next part of this series, I want to look at what happens after we decide AI is appropriate because AI does not fix the process it enters. It amplifies it.