The EU AI Act’s high-risk obligations arrive in August 2026, and a lot of security leaders are about to give their first serious AI briefing to a board that has started asking pointed questions. Most of those briefings will go badly, for a predictable reason: they will describe AI risk in general terms when the board wants to know about this company.
A board does not need an education in transformer architectures. It needs to know whether the organization is exposed, who owns the problem, and what decision is being asked of it.
What the board is actually deciding
Boards do not manage risk. They allocate authority and money, and they establish whether management has the situation in hand. Every AI security briefing should therefore end in a specific ask: fund an inventory, authorize an approval gate with teeth, accept a documented risk, or approve headcount.
If you reach the end of your slot without asking for something, you have delivered a status report. Boards tolerate those and forget them.
Bring four numbers you can defend
The difference between a credible briefing and a nervous one is whether the speaker can say where each number came from. Four are worth the slot.
How many AI systems are deployed, and how many have a named owner. The owner count matters more than the total. Pull the list from procurement records, your CMDB, and the OAuth application grants in your identity provider (Entra ID or Okta will show you which third-party AI tools employees have already connected to corporate accounts, which is usually the number that surprises people).
What data classes are reaching external model providers. Source this from DLP and egress tooling (Microsoft Purview, Netskope, Zscaler) rather than from policy. Policy tells the board what is permitted. The board is asking what is happening.
How many AI systems can take an action, not merely produce text. A summarizer and an agent with write access to a ticketing system belong in different risk tiers. This number is your blast radius, and it is the one that most cleanly separates AI risk from ordinary vendor risk.
What fraction of AI vendor contracts carry data retention and training-use terms. Legal usually has this and has never been asked to count it.
Four numbers, each traceable to a system of record. That is a defensible briefing. A maturity score you cannot reconstruct under questioning is not.
The three questions you will get
Are we exposed? Answer with the inventory and egress numbers, then name the single largest concentration of risk rather than listing everything. Boards remember one thing.
Are we behind our peers? Resist the benchmark you cannot substantiate. What you can say honestly is which practices are becoming standard: an AI asset inventory, a documented approval gate, and contract terms covering retention and training use. Position against those, not against an invented industry percentile.
What will this cost? This is where briefings collapse, because the honest answer depends on a scope decision the board has not made. Present two or three scoped options with costs attached and let the board choose. Inventing a single number to sound decisive is how CISOs end up defending a figure they never believed.
What to leave out
Framework recitation. Naming NIST AI RMF, ISO/IEC 42001, and the EU AI Act is fine as one line establishing that a structure exists. Walking a board through the four functions of the NIST framework is not a board conversation, and it reads as filling time.
Threat theater, too. Deepfake fraud is real and directors will ask about it, but if it consumes more of your slot than your own deployment posture, the agenda came from the news rather than from your risk register. The same applies to technical attack detail: prompt injection is worth one clear sentence about why an AI assistant connected to internal documents is an exploitable path (OWASP LLM01, MITRE ATLAS AML.T0051), and not worth a diagram.
Where this structure does not apply
It assumes you have an inventory. If you cannot say what AI is running in your environment, do not build a four-number deck on estimates. The correct briefing in that situation is short: state the gap, explain that everything else depends on closing it, and ask for a window and a budget. That version is uncomfortable to deliver and considerably more survivable than a dashboard that falls apart on the second question.
It also assumes the board is engaged enough to decide something. A board that wants reassurance rather than decisions is a different problem, and a governance problem rather than a briefing problem.
The judgment to hold this conversation is what the executive AI course we teach for security leaders is built around. For the underlying material, the posts on AI governance for security executives and the AI risk blind spots CISOs miss go deeper. The one-day executive course works through it with other security leaders in the room, and if the board date is sooner than that, we also brief leadership teams directly.