A US president once climbed into a Tesla on the White House lawn, looked over the interior, and delivered a one-line review: "Everything's computer."

He wasn't wrong, and the observation was remarkably prescient. Swap one word, and you have the state of enterprise software today: everything is AI.

Here is what that did to my approval process. We were trying to tiptoe carefully into the AI pool, so we wrote a sensible policy: any new system that included AI technology had to be vetted. It was a good policy for about as long as it took every SaaS vendor to add agents or a model to its product.

Then the requests arrived. The VP of HR wanted a vendor that uses AI to source and manage the talent pool. The CMO wanted a few tools that could suss out (pun intended) intent from browsing behavior. Several engineering leads wanted agentic development tools, each a little different. And employees, bless them, wanted productivity helpers for calendars and workloads, which is a polite way of saying more AI.

Within weeks, the approval queue had a single point of failure: me. The requests weren't equal, and they weren't all obvious.

So what do you do when you're the safety control?

This piece is a playbook for CISOs facing the same math: why the approval seat becomes a trap, and five moves that keep you out of it.

What is a moral crumple zone?

A car's crumple zone is engineered to fold on purpose. It absorbs the force of a crash so the cabin, and the people in it, survive.

Madeleine Clare Elish borrowed the image in a 2019 paper to name something less comforting. When a complex automated system fails, responsibility tends to be misattributed to a human who had limited control over what the system did. That person becomes the component that absorbs the blame, and the system's reputation survives at their expense. Her cases include Three Mile Island and Air France 447, where early coverage pointed at operators and pilots while design, training, and management failures got less airtime.

Now swap the car for an enterprise rolling out AI. Someone sits in that driver's seat, and too often the nameplate says CISO.

Why does the loop turn people into crumple zones?

I sort most problems the same way: strategic and tactical. Strategic (systematic) deficiencies are built into the arrangement. Tactical (operational) deficiencies are what we do when the pressure arrives.

Strategic (systematic): what's built in

🔹 Approval is a snapshot of a moving target. Some vendors practice what I call the umbrella method: they walk in with the umbrella closed, a limited AI use case, and get approved. Once the approval is in hand, they open it, expanding the use case or the access without telling anyone. The approval still carries the approver's name, and the change carries nobody's. That is a crumple zone in miniature.

🔹 The checklist looks one hop deep. Ours asked where the brain sits (where the engine is hosted), what data it consumes, whether that data trains other customers' models, and which systems and data stores it can reach. (Yes, a checklist, and yes, I see the irony. All checklists are lacking, but some are useful.) Ours was lacking in a specific way: the risk was not only what the tool could reach, but what the systems it reached could reach in turn, the secondary and tertiary connections. A questionnaire is a poor way to draw a graph.

🔹 Responsibility doesn't track control. Elish's core observation is that control has been distributed across humans and machines, while responsibility hasn't been adjusted to match. The vendor controls the product, the business owner controls the use case, and the approver controls a signature.

Tactical (operational): what we do about it

🔹 We answer volume by turning the wrong dial. Leadership wants speed, which is a legitimate business goal, so pressure to clear the queue is predictable. The obvious fix is to simplify the approval criteria so reviews go faster, and it is tempting for exactly that reason. Think of review attention as a fixed budget with two dials. One sets how many requests get reviewed. The other sets how much each review actually checks.

Simplifying the criteria turns the second dial down while the dashboard watches only the first. Suppose every request is reviewed (a proud 100%), but the shortened criteria check only the vital few: the few failure modes that, by the Pareto Principle (the 80/20 rule), tend to cause most incidents (the actual split will vary). That sounds like a bargain, and as a way to decide where to look, it is a good one. But the dashboard still says 100%. Everything outside the vital few goes unchecked, and frequency and impact don't follow the same curve, so the expensive failures may live in that remainder.

That is a lower sampling rate wearing a green dashboard. A lower rate you announce is a risk people can see and accept. A lower rate disguised as full review is the kind that ends up under one person's name.

Where does compliance come in?

At least one regulator has noticed the problem, which is more than most checklists manage. Article 14 of the EU AI Act, which governs high-risk systems, requires that the people assigned to oversee them be enabled to stay aware of "the possible tendency of automatically relying or over-relying" on the output. That is automation bias, written into law. The same article says overseers must be enabled, as appropriate and proportionate, to disregard, override, or reverse the output, and to interrupt the system through a "stop" button or a similar procedure that brings it to a safe halt.

Article 26(2) puts the same idea on the deployer, which means you: assign oversight to people with "the necessary competence, training and authority, as well as the necessary support."

A checklist can ask whether a human is assigned. It cannot ask whether that human has the time, the context, and the power to do the job.

An org chart can show a person in the loop while the loop gives that person none of the three. Passing the audit and passing a crash test are different events.

So what do we do about it?

Don't ask whether a human is in the loop. Give the people you hold accountable the authority, information, and time to do the job. Five moves, roughly in the order I'd do them. If you do only one this quarter, make it step 1, because every other move depends on knowing whose name is on the decision:

  1. Name the accountable owner before go-live. Every AI use case gets an approval record with four fields: who owns the deployment, what Security actually reviewed, who accepted the remaining risk, and what reopens the decision. Reviewing a use case, operating a control, and accepting risk are three different jobs, and the record keeps them apart. Security answers for the quality of its review and for the controls it agreed to run, not for what a vendor changes later or for a risk the business chose to take.
  2. Close the umbrella. Approve one use case, one data scope, and one access scope, and require re-approval when any of the three changes. Add a notice clause to the contract, then verify with drift monitoring (new permission grants, data flows, subprocessors). The umbrella also opens from the inside, when an internal admin enables a new integration, so count that as a change too. Then trace access one hop further than feels necessary: an agent that cannot touch production but can trigger a CI workflow that deploys to it can, in practice, touch production. Security operates the drift monitoring, and the business owner decides what to do with what it finds.
  3. Tier the review and state the sampling rate. Go deep where mistakes are costly or hard to undo (sensitive data, write access, categories regulators treat as high-risk, like hiring tools), and sample the rest. The HR sourcing tool lands in the deep tier, since it ranks people who never agreed to be ranked, while a calendar helper with no write access can sit in the sampled one. If leadership wants more speed, that is a legitimate call, so put the lower coverage in a risk acceptance the business owner signs, inside a ceiling that leadership sets and funds. A signature records who decided within delegated authority. It does not move legal duties off anyone.
  4. Report depth, not just volume. Never let "100% reviewed" stand alone. Report review depth by tier and the material changes you found after approval. Automakers crash-test the crumple zone, so crash-test yours: seed known-bad requests into the queue, like phishing simulations for approvers, and track the catch rate by failure type. It only covers the cases you thought to seed, so treat it as the best case, not the average.
  5. Make "no" safe and cheap. Give reviewers a stop button, a time budget, and an escalation path nobody can route around. Decide in advance who can pause a launch, who can suspend a live system, and who breaks the tie when an executive sponsor wants to ship on Friday with a security finding still open. The exception gets an owner and an expiry date. Containing a live agent is a different job from blocking a purchase, so name who can revoke its credentials and how you will verify it stopped. The person a hiring tool quietly ranks last never sees your queue, so the stop path is the only place their harm gets caught. Watch for drift: approval rate rising toward 100% while decision time falls toward zero. After an incident, ask what the system made easy before asking who clicked.

What is the question behind the question?

We keep asking whether there is a human in the loop. We rarely ask what happens to that human when the loop fails. And someone else is counting on that loop to hold: the person on the receiving end of the decision.

If the honest answer is "they take the blame," you haven't built a control. You've built a crumple zone, and a crumple zone works by being destroyed. Let's design oversight so that the part that folds is never a person.

Thank you for sticking with me through a long one. If you have sat in the approver's seat while everything became AI, I'd like to hear what kept you out of the crumple zone. Let's rethink this together.

Views are my own.