AI Action Checklist for Founders Who Ship Before They Review

Air Canada's chatbot told a grieving customer he qualified for a bereavement fare discount. He booked the flight. The discount did not exist. The court held Air Canada liable for the commitment its chatbot made, ruling that the business could not disclaim responsibility for what its AI said to a customer. Air Canada lost. The chatbot was not a rogue employee. It was a tool the company deployed, and the company owned what it did.

Most founders read that case and think: edge case, airline, different jurisdiction. Keep reading.

The approval workflow you have does not cover this

The reasonable objection to building a separate AI oversight process is that you already have approval workflows. Invoice changes above a threshold need sign-off. Customer communications go through a review queue. Contracts require a named authority. If those controls exist, the argument goes, routing AI-generated outputs through the same gates closes the exposure. You are not starting from zero.

This holds until you test it against what automation bias research actually shows. When a human reviews an AI-generated output, they approve it at higher rates than outputs they produced themselves, including when the AI output contains errors. The approval gate exists. The reviewer's scrutiny does not. Your existing workflow was designed assuming the person at the gate would read what they were approving. The research on automation bias shows that assumption breaks down specifically in the presence of AI-generated recommendations.

The Air Canada problem is different again. The chatbot generated a customer commitment before any employee acted. Existing approval processes define authority over what employees do. They were not designed to catch what an AI does before a human is ever in the loop. That is not a coverage question. It is a sequencing question.

Your existing sign-off process was not built for an AI that commits before you review it

The EU AI Act and the NIST AI Risk Management Framework both treat human override authority as a design requirement, not a retrospective control. Both frameworks require audit logs of how that authority was exercised, not just that it existed. If your AI sends a customer email and your process is "someone would have caught a bad one," you do not have a log. You have an assumption.

The NIST AI RMF is specific: logging and override requirements are structural, not procedural. You build them into the system before deployment, or you are running without them. The EU AI Act classifies AI systems that affect rights or financial exposure as high-risk, with mandatory human oversight as a precondition, not an add-on. Neither framework treats "we had a general approval process" as a substitute.

The practical version of this for a founder is not complicated. Before you automate any action, write down what the AI is doing. Then answer two questions: does this action create a legal commitment, move money, or put words in front of a customer under your name? If yes, who is the named person who reviews it before it executes, and where does that review get recorded?

That is the checklist. It is not a framework. It is a list of your AI's action types, a column for whether each one crosses the commitment threshold, and a column for the named approver and log location.

What belongs on the list

Customer emails belong on it. Invoice updates belong on it. Anything that generates a quote, confirms a price, or modifies a contract term belongs on it. These are not hypotheticals. These are the action types the research on agentic AI in finance identifies as categorical risks when run without review.

Infrastructure optimization does not belong on it. Video compression does not belong on it. The research explicitly names these as domains where human review adds no meaningful protection. The point of the checklist is not to slow everything down. It is to identify the specific outputs where unreviewed execution creates exposure that outweighs the cost of a review step.

Trust-in-AI survey data shows customers hold businesses accountable for AI actions at the same standard as human employee actions. They do not distinguish. When your AI sends a wrong price to a customer, the customer does not think "the AI made a mistake." They think you made a mistake. The liability is yours. The record of who approved it, or the absence of that record, is the only thing that changes what happens next.