What to Tell the Board About AI-Written Code?
Directors want a number, not a policy. Learn what to tell the board about AI-written code and how to back it with a record. Connect your estate free.
Directors are asking about AI risk, and the usual answer is a policy and a survey. The better answer is a number you can reproduce and a record behind it.
Part of our AI Code Governance: A 2026 Field Guide series: the operating model for attributing, classifying, deciding, and proving AI-written code.
The question comes late in the audit committee agenda, from a director who has been quiet all meeting. How much of our code is written by AI now, and who checks it?
The CISO has a slide listing the approved AI coding tools. There is a vendor report showing how many seats are active. Neither answers the question. The chair writes down an action item: come back next quarter with a number.
What is the board really asking?
Boards stopped asking whether the company uses AI a while ago. The Conference Board and ESGAUGE reviewed S&P 500 Form 10-K filings through August 2025 and found that 72% of companies disclosed at least one material AI risk, up from 12% in 2023.
When a company tells investors that AI is a material risk, the directors who approved that filing want to know what sits behind it. For software, it comes down to three questions:
• How much? What share of merged code is AI-authored?
• Who checked? Where it matters, did a human review it, and is that recorded?
• Can you show it? If an auditor, regulator or customer asked tomorrow, could you produce the record?
Why the usual answers fall short
Each common answer is true and still not an answer.
• The policy states intent. It doesn't show that anything operated.
• Seat counts measure usage. Seats activated is not code merged.
• Scanner totals count findings. A scanner can report hundreds of them and still not say how many came from an AI agent.
The visibility gap is wide. Cycode's 2026 survey of more than 400 CISOs found that 100% of enterprises have AI-generated code in production and 81% of security teams can't see it. A board report built on what the security team can't see is a report built on a guess.
The scanners were never the problem. The missing layer was.
Why this lands on the CISO personally
A board slide is a statement, and someone owns it. Under regimes such as New York's NYDFS Part 500, the annual attestation to the regulator carries the CISO's name alongside the chief executive's. Your counsel can tell you how any regime applies to your company.
The exposure is simple. A line that says AI-written code is reviewed, with nothing behind it, is one deposition away from being a liability.
Nobody asked you to review every line. They asked you to know.
Board-grade means reproducible
A number for the board has to survive a follow-up question. That rules out estimates from a developer survey. It rules in numbers derived from signals your estate already emits: merge history, review records, and the agents' own settings files.
Reading a value is not the same as asking a model for an opinion. "Auto-approve is enabled in a repository that touches production" is a fact anyone can reproduce. "Our AI usage looks moderate" is an opinion nobody can sample.
A one-page board view needs four things:
• Share of AI-authored merges, so the first question has a number.
• Share of those with a recorded human review, weighted toward your most sensitive repositories.
• Blind spots, meaning the repositories and tools you could not read, stated out loud.
• Open decisions, each with an owner and a date.
Blind spots are what make the other numbers credible. A figure that hides what it can't see is a figure a director will later find out about.
Presence is a fact. Coverage is a disclosure.
What to do before the next board meeting
Four steps. None needs a new tool to start.
Write the three questions down. Agree with your GRC lead or counsel who owns each answer before the meeting, not during it.
Pull your own sample. Take 25 merged changes from your most sensitive repositories last quarter and mark which ones an AI tool authored. The number 25 is a working sample size, not a standard.
Count the gaps. List the AI-authored changes with no recorded reviewer, and the repositories you couldn't read at all.
Bring decisions, not a status. For each gap, propose fix, waive or accept, with a named owner and a date. A board can act on a decision. A status report only tells it you're still looking.
Do the first three this week. It takes an afternoon, and you walk in with a number instead of an action item.
Where Provenance fits
Diwo Provenance is the governance layer above the scanners and pipeline tools you already run. It reads the signals your estate already emits, derives which changes AI wrote and whether a human reviewed them, and turns the gaps into decisions with owners and deadlines.
For the board, it rolls the estate into one visibility-weighted Provenance Score, where blind spots hold the number down instead of hiding behind it. It also writes a first-person board briefing in the voice of an AI Risk Officer, and its audit exports map to the EU AI Act, NIST AI RMF, SOC 2 and ISO 27001. That is evidence readiness, not a legal determination. Your counsel makes the legal call.
On a real 52-repo engineering org, the first connection surfaced 25 AI-authored pull requests merged with zero recorded human review. That is the kind of number you want to find before a director asks.
It is not a scanner, and it reads code signals, never your source. A coach, not a blocker.
Seeing your own estate takes about 15 minutes with a free, read-only connection: connect your estate free and see what you would tell the board today.
The board asked for a number. Give them one you can reproduce.
Related reading
• The pillar: AI Code Governance: A 2026 Field Guide: the full operating model and the three risks to govern first.
• Who's Accountable When AI Writes the Code?
• Your AI Agent Has Your Production Keys: Here's How to Find Out
FAQ
What should a CISO tell the board about AI-written code?
Three things, each backed by a record: how much of the merged code AI authored, whether a human review is recorded where it matters, and which parts of the estate you cannot see yet. Naming the blind spots is part of the answer.
Do I need to give a governance tool access to my source code?
No. Provenance reads signals such as merge and review history and the agents' settings files. It reads code signals, never your source.
Does a board briefing from Provenance settle our regulatory obligations?
No tool can make that determination. Provenance grades evidence readiness against the frameworks you answer to, and your counsel makes the legal call.
---
See it in action
Your scanners detect. Provenance decides.