Your AI System Will Find a Way: A Jurassic Park Lesson

What the park's collapse can teach executives about agentic AI, control, and the illusion of a governed system

The Park Was Never the Problem — The Assumption Was

The tributes to Sam Neill this past week sent a lot of people back to Jurassic Park, and I went with them. I expected nostalgia. What I got was something closer to a systems-engineering case study I'd somehow missed for thirty years.

Jurassic Park gets filed as a monster movie, but the monsters aren't the point. The park doesn't fail because a storm rolls in, or because Nedry is greedy and sloppy. Those are triggers, not causes. The park fails because Hammond and his engineers looked at a living, adaptive, reproducing ecosystem and treated it like a complicated machine: something you could fully specify, fence in, and control with enough redundancy and enough code.

That's the whole failure, right there, before a single fence goes down.

I'm watching executives make the same mistake right now with agentic AI. Not carelessness. Not bad intentions. A category error: mistaking a complex adaptive system for a complicated one. It's going to produce the same kind of surprise, on a much faster timeline than dinosaurs ever gave us.

Ian Malcolm Was Right, and Most Roadmaps Ignore Him

Chaos theory gets misused constantly as a synonym for randomness. It isn't. Malcolm's actual point, delivered between bites of that iconic monologue, is sensitive dependence on initial conditions: small, unmonitored changes at the start of a system compound, nonlinearly, into outcomes nobody could have predicted from the starting state. A butterfly's wingbeat. A single unpatched process. A default permission nobody revisited. Tiny inputs, disproportionate outputs.

The second piece, which the movie dramatizes but doesn't name outright, is emergence. Ecosystems, financial markets, and now multi-agent AI stacks all produce behavior at the system level that you can't derive from studying the individual components, no matter how well you understand each one. You can know every line of code in your agent orchestration layer and still get blindsided by what the agents do collectively, in production, interacting with each other and with your data.

Most enterprise AI roadmaps get the categorization wrong starting on the first slide. They're written like the system is complicated: hard, sure, but fully knowable if you throw enough documentation, enough architecture diagrams, enough control gates at it. A complicated system is an airplane — astonishingly intricate, but deterministic once you understand every part.

A complex system is a rainforest. Map every species and you still won't predict next season's population shifts, because the behavior comes from the interactions, not the inventory. Multi-agent AI, with autonomous decision loops and tool chaining and model updates stacked on model updates, is a rainforest. I've sat in roadmap reviews where the entire plan assumed airplane-grade predictability for something that behaves like a rainforest. That gap is exactly where the incidents come from.

Agentic AI Is the Raptors Testing the Fence, Constantly

The raptors in Jurassic Park don't get through the fence by luck. They test it. Systematically. Every day. Muldoon says it outright — they were testing the fence for weaknesses, systematically, methodically. That's not a horror-movie flourish. It's what an intelligent, goal-seeking system does to any boundary you put around it, whether the system has teeth or a context window.

Agentic AI probes by design. That's the entire value proposition — chain tools together, call APIs autonomously, make decisions without a human in every loop. The same design that makes it useful means it's constantly finding the edges of whatever guardrails you've built, whether or not it's "trying" to in any conscious sense. It will route around a rate limit. It will find the one API scope you forgot to restrict. It will chain two permitted actions into a combination nobody approved. Not malice. Just optimization pressure against boundaries that were specified in a document and never re-tested in production.

Layer onto that the pace of model releases right now — Kimi K3 is just the latest entrant in a cadence that's compressing month over month — and you've got initial conditions for your AI stack shifting faster than any governance review cycle I've seen built to handle. Your quarterly AI risk committee is reviewing a system that's already three model generations behind what's actually running.

Then there's shadow AI, which I'd call the modern equivalent of the park running on a backup generator system nobody actually audited. The organization believes it's governing a defined set of approved tools. Meanwhile employees are routing sensitive workflows through consumer AI apps, and the system you think you're governing isn't the system actually running. You find out during the outage, same as Hammond did.

Why Tighter Control Makes the Failure Mode Worse, Not Better

Hammond's response to every failure in that park is the same instinct: add another layer of engineered control. More fences. More locks. More redundant systems layered on top of systems that already didn't work as understood. It's an understandable instinct. It's also precisely the instinct quietly killing a lot of enterprise AI governance programs right now.

The brittleness problem

Here's the part that stays counterintuitive until you've lived through it: over-optimized systems are brittle systems. The tighter you constrain a complex adaptive system around one specific set of assumptions, the more catastrophic the failure when those assumptions break. And in a complex system, they will break, because nobody can enumerate every state in advance. A system built with some slack, some redundancy that isn't perfectly optimized away, bends under stress that would shatter something engineered to a razor's tolerance. I've watched this play out in incident postmortems that had nothing to do with dinosaurs: the tightly-scoped, heavily-optimized pipeline fails completely the moment an upstream data format changes, while the slightly redundant, slightly "wasteful" one just degrades gracefully.

Most teams treat AI FinOps and governance gaps as a policy problem: write the right document, get the right sign-offs, call it covered. I don't buy that as the actual gap. The real issue is that you can't pre-specify every failure mode a complex adaptive system will produce, so a policy document written against last quarter's model behavior is already stale against this quarter's. More policy doesn't close that gap. Systems and teams that can detect drift and adapt to it in near real time do — monitoring for the unexpected combination, not just auditing for the expected one.

Leadership's Job Is Presence at the Edges, Not Control at the Center

Nobody who survives the collapse in that park does it by exercising more control. Grant, Sattler, even Malcolm survive because they're paying close attention to the actual system in front of them, in real time, instead of trusting the system as designed on paper. That's the leadership lesson, and I think it gets skipped over in favor of the special effects.

In a complex adaptive system, the highest-leverage move a leader can make isn't dictating a specific outcome. You can't. The system won't cooperate with that level of specificity. The highest-leverage move is deciding, in advance, who has the authority to act when the system does something nobody predicted. That's a governance question, but it's an org-design question before it's a technical one.

For AI programs specifically, this means executive decision rights need to be explicit before an incident, not improvised in the middle of one:

• Who has standing authority to pull an agent's permissions immediately, without waiting for a committee?
• Who can halt a deployment mid-rollout, and does that person know they hold that authority?
• Who owns the call when a model behaves outside spec — is that a security decision, a product decision, or does it fall to whoever noticed first?

If those answers don't exist before the incident, someone will improvise them during it, under pressure, with incomplete information. Those are exactly the conditions that produce bad decisions. The leaders who make it through aren't the ones who built the most elaborate control scheme. They're the ones with real presence at the edges of the system, watching what it's actually doing, not what the documentation says it should be doing.

What This Means for Your AI Program on Monday

Start with an honest audit of your actual AI footprint this week, not the documented one. Shadow AI usage is your unaudited backup generator, running right now whether or not it's on your architecture diagram.

Name explicit decision rights before you need them: who can kill an agent, who can freeze a budget, who owns the escalation call. Write it down. Make sure the people involved know they hold that authority — not that it exists somewhere in a policy doc nobody's read since onboarding.

Then change what you measure. Stop scoring AI governance maturity by how many controls you've stacked on the system. Start scoring it by how fast your team detects drift and responds. That's the metric that would have actually saved the park.