AI Governance Platform or Internal Review: What Covers You

A client called me last month after signing a contract with an AI governance software vendor. His question was simple: "Now that we have this, are we covered?"

I get a version of this question every few weeks, and it's almost always backwards. The tool doesn't cover you. The tool is where evidence lives, if you feed it evidence. The thing that actually covers you — in front of a regulator, an auditor, opposing counsel, or a customer's procurement team — is whether you can produce a documented, defensible account of how you identified an AI risk, what you decided to do about it, and why. A platform can hold that account. It cannot generate it for you, and buying one is not the same as having done the work.

This matters more in September 2026 than it did two years ago, because the regulatory floor has moved. Colorado's AI Act (SB 24-205) was on track to take effect June 30, 2026, requiring developers and deployers of high-risk AI systems to use "reasonable care" to protect consumers from algorithmic discrimination. But a federal court blocked enforcement in April 2026, and Governor Polis signed SB 189 on May 14, 2026, delaying the law to January 1, 2027. SB 189 also replaced that duty-of-care and impact-assessment scheme with a narrower requirement to disclose the use of automated decision systems. California's SB 53, the Transparency in Frontier Artificial Intelligence Act, became effective January 1, 2026, and requires large frontier AI developers to publish a safety framework describing how they identify and mitigate catastrophic risk. The EU AI Act's high-risk provisions are phasing in on their own timeline. None of these laws name a required software product. All of them ask, in one form or another, for the same thing: can you show your work?

What "Coverage" Actually Means

Before comparing tools to process, it's worth being precise about what you're trying to buy or build coverage against. In my experience there are three distinct exposures, and they don't respond to the same fix.

• Regulatory exposure is the risk that an agency — the FTC, a state attorney general, an EU market surveillance authority — asks you to demonstrate you had a risk management process for a specific AI system before something went wrong.
• Litigation exposure is the risk that a plaintiff's attorney, after an adverse outcome (a discriminatory hiring decision, a biased credit denial, a hallucinated medical recommendation), argues you were negligent because you had no reasonable process.
• Contractual exposure is the risk that a customer, insurer, or enterprise procurement team asks for evidence of AI governance as a condition of doing business — this is increasingly common in vendor security questionnaires and is now showing up as its own line item alongside SOC 2 and ISO 27001.

All three exposures are resolved the same way: by producing a record that shows reasoned judgment applied consistently, before the fact, not reconstructed after. That's the test. Everything else is packaging.

The Documented Internal Review Process

A documented internal review process is what it sounds like: a written procedure — who reviews a new AI use case, against what criteria, with what sign-off, logged where — that your organization actually follows. No software is required. Many organizations run this in a shared drive, a ticketing system, or a modified version of whatever change-management process they already use for IT or product launches.

The strength of this approach is that it maps directly onto what the standards actually ask for. ISO/IEC 42001:2023, the AI management system standard, requires under clause 6.1.2 that an organization establish and apply criteria for AI risk assessment and, under clause 6.1.3, that it plan AI risk treatment — with clause 8.3 covering the operational execution of that plan — as a documented process, not as a feature of any particular software. NIST's AI Risk Management Framework (AI RMF 1.0, published January 2023) organizes the work into four functions — Govern, Map, Measure, Manage — and describes practices, not products. You can satisfy both frameworks with a well-run Google Doc and a disciplined habit of using it.

The weakness shows up at scale and under scrutiny. Manual processes drift. The review template from eighteen months ago doesn't reflect the risk categories your organization uses today. Sign-offs happen in email threads that get deleted when someone leaves. When a regulator asks for every AI risk assessment completed in the last two years, "give us a week to reconstruct that from Slack and old Word docs" is not a good place to be standing. Documented process without a system of record is real coverage that degrades exactly when you need it most.

The AI Governance Platform

An AI governance platform — tools in this category include vendors positioning around AI inventory, model risk management, and compliance workflow — gives you a system of record: a place to log AI use cases, run structured risk assessments, track remediation, and generate audit-ready reports. The pitch is consistency and retrievability at a scale manual process can't match once you're running more than a handful of AI systems.

The strength is real. A platform that enforces a required risk assessment before a new AI use case goes live, and that timestamps and version-locks that assessment, produces exactly the kind of contemporaneous record a regulator or plaintiff's attorney respects. It also solves the multi-system problem: once an organization has AI embedded in twenty different tools across six departments, nobody is tracking that in a shared drive reliably.

The weakness is that a platform without a real internal review process behind it is theater with better UI. I've reviewed several governance tool deployments where the risk assessment fields were filled in with boilerplate answers by whoever was told to close the ticket, with no actual cross-functional review, no legal or compliance sign-off, and no evidence anyone weighed the risk before deployment. That produces a beautiful dashboard and a legally worthless paper trail. Under deposition, "we had a tool" is not an answer to "who reviewed this system for discriminatory impact, and what did they find?" A platform can only be as defensible as the process it's automating. If the process is thin, the platform just makes the thinness look organized.

Side-by-Side Comparison

The table makes the point I want to land: the two columns aren't really competing for the same job. One is the substance, the other is the container. A container with nothing in it and substance with no way to retrieve it both fail the same test, just in different ways.

What the Frameworks Actually Require

It's worth being specific here, because vague citations are exactly what gets an organization in trouble — a vendor telling you "you're covered under NIST" without pointing to a function, or "ISO-aligned" without a clause number, is not something you can hand to outside counsel.

ISO/IEC 42001:2023 is the first international management-system standard for AI, published in December 2023. It's structured like ISO 9001 or ISO 27001, with clauses covering leadership, planning, support, operation, and performance evaluation. Clause 6.1.2 requires the organization to define criteria for assessing AI-related risks — bias, safety, transparency, reliability. Clause 9.3 requires management review of the AI management system at planned intervals. Certification requires an accredited body to audit that these clauses are actually operating, not just documented in theory.

The EU AI Act (Regulation (EU) 2024/1689) is more prescriptive for high-risk AI systems specifically. Article 9 requires a risk management system operated as a continuous iterative process throughout the AI system's lifecycle. Article 11, together with Annex IV, requires technical documentation detailed enough that an authority can assess conformity. Colorado's SB 24-205 originally required developers and deployers to complete impact assessments for high-risk AI systems and disclose the reasonable care they exercised if the state attorney general asked, but SB 189 (signed May 14, 2026) delayed the law to January 1, 2027 and replaced that scheme with a narrower requirement to disclose the use of automated decision systems to consumers. None of these instruments certifies a piece of software as compliant. They all evaluate whether the organization behind the system did the work — a distinction that matters because plenty of vendor marketing blurs it deliberately.

So Which One Actually Covers You?

Neither, alone. In my view the sequencing matters more than the choice. Build the documented review process first — the criteria, the sign-off chain, the escalation path for a use case that fails initial review — because that's where the actual judgment happens and where ISO 42001 and the EU AI Act both look first. Bring in a platform once you have more AI use cases than a shared drive can track honestly, and configure it to enforce the process you already trust rather than inventing a new one to fit the software's defaults. An organization that buys the platform first tends to build its process around what the tool's default fields ask for, which is backwards — the tool should serve the standard, not the other way around.

The organizations that get burned are the ones that treat either extreme as sufficient: all process and no retrievable record, or all platform and no real review underneath it. The ones that hold up under scrutiny have both, and can point to specific dates, specific reviewers, and specific reasoning for specific systems. That specificity is the whole game. A generic policy statement that "AI systems are reviewed for risk" protects no one. A record showing that on a given date, a named reviewer applied a written rubric to a specific system and reached a specific, documented conclusion is what an auditor, a regulator, or opposing counsel actually credits.

If you're building this from scratch, an AI readiness assessment is the right starting point — it tells you how many AI use cases you actually have in the wild before you decide whether a platform is overkill or overdue. And if NIST's framework is the standard you're aligning to, I've laid out a practical sequence for a mid-size company in a companion piece on implementing the NIST AI RMF.

Frequently Asked Questions

Does ISO 42001 certification require a specific software platform? No. ISO/IEC 42001:2023 specifies management-system requirements — documented risk criteria, treatment plans, management review — and an accredited certification body audits whether an organization meets them. It does not mandate any tool, and certification bodies evaluate evidence regardless of where it's stored.

Is a spreadsheet-based AI risk log legally defensible? It can be, if it's used consistently, timestamped, version-controlled, and tied to actual sign-off by named reviewers. What makes a record defensible is contemporaneous, specific documentation of reasoned judgment — not the software used to hold it. The risk with spreadsheets is drift and loss, not format.

When does it make sense to buy an AI governance platform instead of running review manually? Once an organization has enough AI use cases — in my experience, once you're tracking more than roughly ten to fifteen active systems across multiple departments — that manual tracking starts missing things or going stale. At that point a platform's enforced workflow and audit trail earns its cost. Below that volume, a well-run manual process is usually more than sufficient and considerably cheaper.

What's the single biggest mistake companies make with AI governance platforms? Configuring them to auto-approve or lightly rubber-stamp review fields instead of requiring real cross-functional judgment. A platform records what you put into it. If nobody with authority to say no is actually reviewing the system, the platform just produces a well-organized record of a review that never substantively happened.

Do the EU AI Act and Colorado's AI Act require the same documentation? No — they overlap in spirit but differ in mechanics. The EU AI Act's Article 9 risk management system and Article 11/Annex IV technical documentation apply to providers of systems classified as high-risk under the Act's own taxonomy. Colorado's AI Act (SB 24-205) originally required impact assessments and a reasonable-care standard for developers and deployers of high-risk AI systems, but SB 189, signed May 14, 2026, delayed the law to January 1, 2027 and replaced that scheme with a narrower requirement to disclose the use of automated decision systems to Colorado consumers. A US company selling into the EU may need to satisfy both, and the documentation formats are not interchangeable without mapping one to the other.

Last updated: 2026-09-11