The audit committee heard the sentence twice a year: "AI monitoring is in place." It was true. Drift detection ran every week. An on-call rotation answered incidents inside a day. A platform team checked the third-party model vendor's status page every morning. What the committee never received was a single number, a single threshold, or a single record of what the monitoring had ever caught. The company had built oversight and then described it to its board in one declarative line.
That gap is where the exposure sits for most technology organizations running AI against regulated work. It is not a gap in the technology. The instruments exist, they are mature, and the CIO or CTO already owns them. The gap is the distance between a measurement crossing a line in an engineering system and a governance body receiving a decision to make.
The data is already built. The bridge to the board is not.
WilmerHale's February 17, 2026 analysis of the NACD 2025 Board Practices and Oversight Survey reported that 36 percent of boards had adopted a formal AI governance framework, and 6 percent had established AI-related management reporting metrics. Read as a shortage of measurement, the 6 percent looks like a build problem waiting on budget. Read against how most technology organizations actually run, it looks different. Drift jobs, incident tickets, uptime dashboards, and vendor service-level tracking are routine disciplines, and the metrics they produce exist long before any board asks for them.
So the 6 percent mostly records something else. It records how few of those metrics were ever converted into a form a director can act on, and how few CIOs and CTOs were asked to own that conversion. Nobody buys a new platform to close this gap. Someone with the authority to route existing data upward decides to do it, on a schedule, in a format the committee can read.
The board does not need to read the dashboard. It needs a threshold-crossing report.
The serious objection from inside the technology organization deserves a direct answer. Directors cannot interpret a drift metric or a confidence interval, the objection runs, and a simplified version either gets ignored or creates false confidence. The premise is correct. The conclusion does not follow.
The board does not need to understand how drift is measured. It needs to be told that a named system crossed a pre-agreed threshold on a named date, that a named owner was notified within a committed window, and that a decision was made and recorded. That is not a simplified technical briefing. It is a different work product built on the same data, and the engineering rigor underneath it stays exactly where it was. What changes is that the line is drawn in advance, so the board receives a decision point instead of a data dump.
A threshold that has never been crossed is a question, not a comfort.
A second objection is harder, because it requires no bad faith. A technical team with an ordinary wish for a clean board record can set thresholds wide enough that the report always reads clean. The artifact then has the form of oversight and none of the function.
The defense is structural. Thresholds belong in a written registry, dated, with a named owner, and open to review by someone other than the person who set them. An audit committee chair who sees a threshold that has not been crossed in eighteen months of continuous operation is entitled to ask why it sits where it does. A written threshold can be tested by a skeptical director, or by a plaintiff's expert after the fact. "Trust us, we are watching it" cannot be tested by anyone, and a Caremark-style oversight claim turns on exactly that: what the board knew, and what system existed to tell it.
Two years of evidence existed. It sat where no director could see it.
Consider a composite, not drawn from any single company. A CTO at a healthcare software firm ran a clinical documentation product with weekly drift detection against a validation set, a 24-hour incident protocol, and a vendor performance dashboard. Over two years the monitoring caught two events. A partner hospital changed its intake form language and briefly confused the product's terminology mapping until the next retraining cycle absorbed it. A vendor rate-limit change produced a latency spike, and the platform team failed over to a backup endpoint inside the four-hour window the protocol specified. Both were resolved. Neither had ever been described to anyone outside engineering.
When the general counsel asked about oversight exposure, the CTO's first reaction was defensive, and fairly so. The monitoring was better than most peers ran. The gap, once examined, was that two years of clean data lived nowhere the board could see, and no one had ever written down which crossing would send a notice upstairs instead of an engineering ticket.
Two senior engineers and a technical writer spent a fraction of their time over three weeks turning existing reports into a one-page quarterly board memo. It named the systems, wrote down the thresholds already implicit in the runbooks, and logged the two events. The board's response was not alarm. It was surprise that this had existed all along, and a request to make the memo a standing agenda item. Nothing about the monitoring changed. What changed was that it became visible to the body whose job is to ask whether the company is inside its risk boundaries.
The Declarative Board Failure Pattern runs in both directions.
The pattern is usually described as a board that declares expected behavior instead of modeling it, asking about it, and listening for it. The same failure appears when management declares oversight to the board in one line and the board accepts the line. Both parties are declaring. Neither is checking. An audit committee that receives "monitoring is in place" twice a year and asks no follow-up has not overseen anything, however sincere everyone in the room is.
The CIO or CTO is the only executive who can break the pattern from the supply side, because only the technology organization holds the underlying detail. A response log that says an incident occurred and was resolved proves nothing. One that states what was measured, which threshold was crossed, who was told and when, and who decided what, turns an engineering incident into a documented governance response. That precision cannot be added later by anyone else.
Four steps a CIO or CTO can complete in thirty days.
First, inventory every AI system that touches a regulated workflow and list the monitoring that already exists for each. Second, pull the alerting configuration already running, and write a numeric board-notification threshold for each system, deliberately coarser than the engineering alert, with one named owner who confirms a crossing and starts the clock. Third, draft the one-page reporting template and put a standing item on the board or audit committee calendar. Fourth, populate the first response log from the prior twelve months of incidents, including an explicit null entry where nothing crossed.
Add one escalation condition from the beginning. Any material system that receives a vendor breach notice, a regulatory inquiry, or a documented threshold crossing should reach the board or the committee chair within five business days of the technology team learning of it, not at the next quarterly meeting. A cadence without that override satisfies the calendar and misses the point.
Nothing here requires a purchase, a new vendor, or new board appetite. As of the date of this piece, no Delaware court has decided an AI-specific Caremark claim, so applying existing oversight doctrine to AI remains reasoned analysis and not settled law. That is a reason to build the record now, on the company's own schedule.
The Legacy Test for this work has two clauses, and both have to hold. The successor who inherits the CIO's seat inherits a written threshold, a named owner, and a dated response log for every material system, not an engineering archive she must translate for a skeptical director. And that inheritance reflects a quarter the CIO chose, before any claim arrived, rather than a record assembled after a subpoena asked what the board had been told.