Thirty Years In: What I Actually Believe About AI and Enterprise Risk

I want to be straightforward about what this piece is and is not. It is not a prediction piece. I have been in this industry long enough to be deeply skeptical of anyone who tells you with confidence where a technology will be in five years, including me. What I can offer instead is a set of convictions developed across three decades of watching technology cycles play out in federal agencies, defense environments, financial institutions, and commercial enterprises. Some of these convictions will be familiar. A few of them are things I find myself having to say out loud more often than I expected.

I will start with the one that comes up most in my current work, because I think it is the most consequential gap between how organizations are approaching AI and what actually needs to happen.

Governance Is Being Treated as a Compliance Checkbox, Not an Operational Discipline

The organizations I work with are writing AI use policies and calling it governance. The policy exists. The operational infrastructure to enforce it does not. I have sat in briefings where a senior leader described their AI governance plan as getting the legal team to review the vendor terms of service. That is contract review. It is not governance.

The operational questions that actually matter were not on anyone's agenda. How do you know when the model is wrong? Who is accountable when it fails in production? How do you detect drift in model behavior over time, particularly in systems that are being fine-tuned or updated by a vendor without your direct involvement? What does your audit trail look like? If a regulator or a contracting officer asks you to demonstrate that your AI-assisted decision was made appropriately, what can you actually show them?

I watched organizations do exactly this with cybersecurity in the 1990s. They wrote security policies, had legal review them, filed them in binders, and told themselves they had a security program. Code Red and Nimda arrived and made very clear that a policy in a binder is not the same thing as an operational security program. The gap between documented intention and enforced operational reality is where risk lives, and that gap is currently very large across most AI deployments I see.

The organizations that will be in the strongest position in three years are the ones building the operational infrastructure now: telemetry on model outputs, human review protocols calibrated to decision consequence, behavioral baselining so drift becomes detectable, and accountability structures that survive an incident review. That work is harder and less visible than writing a policy. It is also the only version of AI governance that will hold up when something goes wrong.

This Technology Cycle Is Following the Same Arc the Others Did, Just Faster

I have been through several of these. The internet. Cloud. Mobile. Each one produced the same sequence with remarkable consistency.

Early adopters generate real value. The market overcorrects into hype. Governance infrastructure lags badly behind deployment because organizations are moving fast and governance feels like it slows things down. A high-visibility failure forces a reckoning. Then the organizations that built operational discipline during the hype phase emerge in a fundamentally stronger position than those that chased capability without infrastructure.

AI is following that arc. The difference is velocity. What took years in previous cycles is taking months now. The gap between deployment and governance infrastructure is widening faster than I have seen before, partly because the technology moves quickly and partly because the business pressure to deploy is intense. Nobody wants to be the organization that missed AI. A lot of organizations are going to be the organization that deployed AI badly, and that distinction is going to matter more than it currently appears to.

I am not saying slow down. I am saying build the infrastructure in parallel rather than as an afterthought. The organizations that did that during the cloud transition are not the ones spending the most on cloud security remediation today. That relationship is not a coincidence.

Organizations Are Confusing Capability With Reliability

A model that performs well 95 percent of the time is impressive in a demonstration and dangerous in a mission-critical workflow. The gap between impressive and dependable is where most enterprise AI deployments are quietly struggling right now, and it is a gap that tends to be invisible until it is not.

In my work on enterprise governance and operational assurance across federal, defense, and commercial environments, I see this pattern regularly. Organizations evaluate AI tools on capability benchmarks during procurement. They deploy them into production workflows. The tools perform well most of the time. And then something happens in the five percent, and the organization discovers it had no real mechanism to detect the problem, no clear accountability for the outcome, and no audit trail adequate to support the incident review.

This is not a technology problem. It is a governance and operational design problem. The technology does what it does. The question is whether the organization has built the surrounding infrastructure to catch the cases where what it does is wrong. Most have not, because building that infrastructure requires accepting that the technology will sometimes be wrong, and that acceptance is uncomfortable when you have just spent significant political and financial capital on an AI initiative.

The federal and defense environments I have worked in over the years have specific reasons to care about this that commercial organizations sometimes do not fully appreciate. Decisions in those environments carry consequence. Errors are not always recoverable. The accountability requirements are real and external, not internal. A 95 percent accuracy rate on a fraud detection model is a business metric. A 95 percent accuracy rate on a targeting recommendation, a benefits eligibility determination, or a security clearance adjudication is something else entirely. The stakes shape what reliable actually means, and governance frameworks need to be built around the specific consequence profile of each application, not around generic AI policy language.

The Perimeter Mythology Has a New Name

In the late 1990s, the security industry had built a compelling story about layered perimeter protection. Firewalls at the edge, intrusion detection at the boundary, antivirus at the endpoint. The mythology was that if you controlled the perimeter, you controlled the risk. The operational reality was that trust inside the perimeter was largely implicit, and the moment an attacker got past the edge, they inherited broad lateral access to everything behind it.

I watched that mythology dissolve in real time when Code Red and Nimda arrived. I was responsible for security across an environment processing more than $2.3 trillion in annual transactions at the time. The question was never whether we had exposure. Everything connected to a network had exposure. The question was what we had already built that could contain damage when the perimeter mythology met the actual threat.

The AI version of the perimeter mythology is the belief that the model itself is intelligent enough to be trusted with consequential decisions without surrounding operational infrastructure. The mythology says the model is smart, therefore the output is reliable, therefore governance is overhead. The operational reality is that most organizations do not have the telemetry to know when their AI systems are producing anomalous outputs, the human review protocols to catch high-consequence errors before they propagate, or the behavioral baselining to detect when a model's behavior has shifted from what was evaluated during procurement.

They are flying partially blind and calling it transformation. I have seen that particular combination before. It does not end well, and the organizations that build the operational infrastructure now will be the ones in a position to help the ones that did not.

What I Have Actually Found Useful

I want to be direct about this because I think the conversation benefits from specificity rather than more abstract commentary about AI potential.

In my current work, AI-assisted analysis of large document sets, policy frameworks, compliance artifacts, and technical specifications provides genuine value. The ability to synthesize and identify patterns across material that no human team has adequate time to fully process is real and meaningful. It changes what is operationally possible in governance and assurance work in ways that were not available even two years ago.

What I find overhyped is autonomous decision-making in any workflow where the downstream consequence of a wrong answer is not immediately visible and correctable. The further you get from human review of AI outputs in consequential workflows, the more risk accumulates invisibly. The model does not know it is wrong. The system does not flag it as wrong. The output moves downstream and compounds before anyone recognizes there is a problem. That dynamic is not a technology limitation that future models will solve. It is a structural characteristic of probabilistic systems operating in deterministic accountability environments, and it requires governance infrastructure, not better benchmarks.

The Honest Version of Where This Goes

Thirty years of watching technology cycles has taught me that the honest version of where things go is usually less dramatic than the hype in both directions. AI will not transform everything overnight. It also will not be rolled back or contained. It is already embedded deeply enough in critical systems that the question of whether to adopt it is largely settled. The question that remains is whether organizations will build the operational discipline to use it responsibly at the speed the environment demands.

The organizations that come through this period in the strongest position will be the ones that treated AI governance as an engineering problem rather than a compliance exercise. That means telemetry, accountability structures, behavioral monitoring, human oversight protocols calibrated to decision consequence, and continuous validation of model behavior in production environments. Not because regulators will eventually require it, though they will, but because the alternative is discovering the failure mode at the worst possible moment.

That is what three decades at the intersection of technology, governance, and operational consequence has taught me to watch for. The infrastructure you build before the incident is the only infrastructure that matters during it.