Most organizations now have AI running somewhere in production, and a meaningful share of it arrived without anyone formally approving it. That sequencing problem is about to collide with a regulatory calendar that is no longer hypothetical. Colorado's AI law takes effect January 1, 2027, other states are drafting their own, and the EU AI Act, whose requirements are being phased in from August 2, 2026, through 2028, reaches organizations well beyond Europe. Jim Tunnessen, who leads GOVERNBOX.ai, argues that the companies that struggle will not be the ones with the most AI. They will be the ones that deployed first and tried to reconstruct governance afterward, an approach that produces documentation designed to defend decisions rather than evidence of how those decisions were made. The distinction matters because auditors and regulators are trained to spot the difference.
Governing AI Is Not A Special Discipline
The mythology around AI governance has done real damage. Treating it as an exotic problem requiring exotic machinery gives organizations permission to build something separate from the controls they already run, and separate systems are the ones that decay. Tunnessen's view is deliberately direct. "Running AI under scrutiny looks like monitoring and managing any other technology you are accountable for. It is due diligence, done consistently." Know what is running in the environment and who owns it. Know what data goes in and why. Watch performance, control changes, have a plan for failure, and review on a schedule rather than waiting for an incident to force the review. None of that is novel to anyone who has managed cybersecurity or privacy programs.
What makes AI different is velocity, not category. A vendor pushes a model update. A staff member finds a new use for a tool nobody anticipated. The input data shifts. Each of those changes the risk picture without any corresponding change in approval status, which is why Tunnessen frames the work as maintenance rather than sign-off. "So the work is less about one big approval and more about keeping the record current: the inventory, the assessments, the training, and the incidents." The practical consequence is a different operating rhythm. Organizations that build governance around a single gate find that gate increasingly irrelevant as the systems behind it mutate. Those that treat AI as technology deserving the same ongoing rigor as everything else, in his words, find that "scrutiny becomes a routine conversation instead of a fire drill."
The Cost Of Working Backward
There is a correct order, and it is not complicated. Identify the use case. Identify the solution that fits it.
- Review the cybersecurity posture of the model or product.
- Run the impact assessment and assess the risk.
- Make sure the AI Use Policy is in place and that staff have been trained.
- Then deploy.
What Tunnessen sees across organizations is that sequence inverted, with governance assembled after the fact, around tools already embedded in daily workflows. The failure mode is specific and it is predictable. "When you work in reverse, steps get skipped. The impact assessment gets written to justify a decision that was already made. The data question never gets a real answer. The policy exists on paper, but nobody was trained on it."
Each of those gaps has an address. They are precisely where an auditor, a regulator, or an incident will land, because reverse-engineered governance leaves a trail of documents that do not reconcile with the operational record. An impact assessment dated after deployment tells its own story. Training records that cover a policy nobody saw before the tool went live tell another. Tunnessen's prescription for organizations already in that position is uncomfortable but honest: go back and do each step properly for every deployed tool, "including the uncomfortable question of whether that tool should still be in use." That last clause is the one most organizations miss, and it is the one that separates a genuine remediation from a paperwork exercise. Some tools will not survive an honest assessment, and a governance program that never kills anything is not a governance program.
Evidence That Exists Before Anyone Asks
The real audit test is not whether a policy document exists. Everybody has a policy document. The test is whether the organization can answer five connected questions about every system:
- Who owns it?
- What data it uses?
- How it was tested?
- How it is monitored?
- What happens when it fails?
Tunnessen is blunt about why most organizations fail that test despite having done much of the underlying work. "If the answers to those five questions live in different spreadsheets, inboxes, and people's heads, you will not hold up, even if you did the work." Governance that cannot be produced on demand is functionally indistinguishable from governance that does not exist.
That argues for a single connected record where every tool, agent, assessment, risk, policy, and training entry links to the others, so a reviewer can start at a system and walk to its owner, its impact assessment, its risks, and who was trained on it. It also argues for history that cannot be quietly rewritten. "An auditor needs to see what you knew and decided at the time, not a version cleaned up the week before the visit." Agents belong in the same inventory with a named owner, no exceptions for how new or autonomous they are. Tunnessen's broader point about speed cuts against the instinct that governance slows deployment. "Smooth is fast. Repeating the process the right way every time is what makes it smooth." The organizations losing time are the ones skipping steps and then stopping to clean up. With accountability heading toward named individuals rather than departments, the executives in the strongest position two years out will be the ones who can show a program that was already running before anyone required it. "We were working on it" will not survive contact with a regulator.
Follow Jim Tunnessen on LinkedIn or learn more about AI governance programs at GOVERNBOX.ai.