A board director said something to me this summer that I've been turning over ever since. Halfway through a briefing on the organisation's AI plans, she stopped the presenter and said, quietly, "I understand every individual word you've used, and I have no idea what I'm being asked to decide." That sentence is the whole problem in miniature. Boards are now expected to govern AI risk — regulators expect it, shareholders expect it, and as of this month the EU AI Act is law, so the expectation has teeth. But the material reaching them is written by technologists for technologists, and it leaves the people who are accountable unable to act. Closing that gap is a translation job, and I've come to think it's one of the most valuable things a technical person can do right now.

Why the usual AI briefing fails a board

The briefings I see fail in one of two opposite directions, and both leave the board unable to do its actual job.

  • Too technical to act on. Slides full of model architectures, token costs, and framework names. Every word correct; the net message unactionable. A board cannot govern what it's been shown at the resolution of an engineering standup. Precision at the wrong altitude is just noise to the people who have to decide.
  • Too vague to matter. The overcorrection: "AI is transformative, we're being responsible, there are guardrails." Reassuring, content-free, and impossible to challenge — which means impossible to genuinely govern. A board can't oversee a warm feeling.

The board's job is neither to understand the transformer nor to nod at reassurances. It's to make a small number of consequential decisions: what risk are we accepting, what are we refusing, who is accountable when it goes wrong, and are we within the law. The briefing has to be pitched at exactly those decisions — and almost none are.

The altitude a board actually needs

Translating for a board isn't dumbing down — that's the mistake that produces the vague version. It's re-pitching the same truth at the altitude where their decisions live. In practice that means answering four questions, in their language:

  1. What could go wrong, in business terms? Not "the model may hallucinate" but "the system could confidently give a customer wrong information we're then liable for." Same fact, translated from failure mode to consequence the board owns.
  2. How likely, and how bad? Boards think in risk terms already — likelihood and impact — for every other domain. Give them AI risk in that same shape and they can reason about it with instincts they already have, instead of being asked to learn a new vocabulary first.
  3. What are we doing about it, and what remains? Every control reduces risk; none eliminates it. The honest version names the residual risk that's left after the guardrails — because that residual is the thing the board is actually being asked to accept or refuse.
  4. What does the law now require of us specifically? With the AI Act in force, "are we compliant" stops being abstract. The board needs to know which of its AI uses fall into which risk category, and therefore which obligations attach — in plain terms, not statute references.

Answer those four honestly and you've given a board something it can genuinely govern. Miss them and you've either buried them or lulled them.

The move that builds the most trust: name the residual risk

If I had to pick the single thing that changes how a board receives an AI briefing, it's the willingness to say out loud what the controls don't cover. Technologists briefing upward have a strong instinct to project control — to present the guardrails and imply completeness. Boards, who govern risk for a living, find completeness claims less trustworthy, not more, because they know there's no such thing.

So the trust-building move is counterintuitive: "here is the risk we cannot fully control, here's why, and here's the residual we're asking you to accept." That sentence does more for a board's confidence than any number of assurances, because it treats them as the risk-owners they are rather than an audience to be reassured. I've watched a board relax visibly the moment someone finally levelled with them about what wasn't covered — because now, at last, they could see the actual shape of the decision.

A board doesn't need to understand how the model works. It needs to understand what it's accepting when it says yes. Those are completely different briefings, and only the second one is governance.

Why this is a communication job, not a technical one

Here's the part that connects to something I've believed since long before AI was the word on every agenda. The gap between the board and the technology isn't a knowledge gap that more technical detail would close — pile on more detail and you widen it. It's a translation gap, and translation is a communication skill, not a technical one. The person who can stand between the engineering reality and the governance decision, holding both accurately, and move a true thing from one language into the other without distorting it — that person is doing the highest-value work in the room, and it's the same work I've been describing under different labels my whole career: documenting a migration so humans can follow it, teaching data to city-makers, getting a non-technical team to trust a dashboard. AI risk is the newest and highest-stakes instance of a very old job.

And it matters more here than almost anywhere, because the cost of the untranslated version is now legal and reputational, not just operational. A board that governs AI on the basis of briefings it couldn't really parse is a board accepting risks it never understood it was accepting — which is exactly the situation regulators, post-AI-Act, are determined to end. The translation isn't a nicety layered on top of the real technical work. With the law now watching, it is the work — the point where all the engineering either becomes a decision someone accountable actually made, or doesn't. Learn to do it well and you become the person every board suddenly needs and very few can find.