How to explain AI risk to the board: What directors need to hear
CISOs must build a narrative on security, reputation and financial impact when discussing AI risks with board members -- and drop the jargon and fearmongering.
AI has altered enterprise risk dynamics, although that transformation hasn't resulted in the uniformly threatening direction many security professionals assume.
Like any new technology, AI introduces new risks. It also helps mitigate existing ones. Consider a firm using a customer support chatbot. This can result in new dangers -- e.g., hallucinated answers leading to angry customers -- but it can also potentially reduce other risks, such as the likelihood of customer dissatisfaction due to long wait times. The risk equation is neither universally positive nor negative.
AI risk also affects different firms -- or parts of the same firm -- in different ways. Usage that increases risk in one situation might decrease it in another based on industry-specific, location-specific or even business-specific factors. Consider AIOps features in technology support tools. In one firm, aggregate risk might increase as a result of new threat scenarios -- e.g., adversarial input cascading impacts into operational systems -- while another firm adopting the same technology might find overall risk reduced, for example, due to complicated, inconsistently followed support processes.
It's no surprise, then, that explaining AI risk to the board is a difficult task. It's not enough to just cite and catalog new technical dangers. Instead, AI risk is a nuanced conversation. CISOs must articulate how AI risk shifts and changes, including:
How AI impacts the organization specifically.
How the organization needs to shift investments to compensate.
What the roadmap is over time.
These discussions must also account for changes in AI technology itself.
To be effective, CISOs must not only explain AI risks at technical and mechanical levels, but also incorporate usage into the picture and present it as a moving narrative that the board can act upon. This means understanding how business teams engage with AI -- both organized and shadow adoption; distilling that usage information into a risk vector -- i.e., a value that accounts for both direction and magnitude of risk; and creating a narrative that's comprehensible to the board.
Data gathering for AI risk evaluation
To be effective, CISOs must not only explain AI risks at technical and mechanical levels, but also incorporate usage into the picture and present it as a moving narrative that the board can act upon.
So what's the best approach to doing all this? The first step is to understand the usage itself. There are two parts to this: First is what's happening technically. In practice, this means establishing a baseline understanding of how AI systems actually operate, including:
How models generate output (inference).
How context is constructed -- through techniques such as retrieval-augmented generation, pruning and memory.
How associated software extends what the system can do.
Security teams need to understand the specifics because each of these areas can carry risk implications in both direct use and adversarial scenarios.
This doesn't mean everybody in the organization needs a deep understanding of the entire stack. Instead, it simply means someone on the security team should be able to 1) assess technical risks objectively and accurately, and 2) explain the technology to others in an understandable, jargon-free way.
The level of depth here is important: Evaluating risk in an organization using a commercial LLM to assist with formatting marketing documents requires less technical depth and specialized knowledge than an organization training its own models or fine-tuning pretrained models. Likewise, an organization that relies on autonomous LLM-driven AIOps has different risks than an organization using AI to vibe code. Tailor the depth of understanding to what the organization is actually doing. Note that education can extend to engineering processes -- e.g., MLOps, LLMOps or other engineering methods employed -- as well as AI engineering generally.
The second step in gathering data is knowing how the business actually uses AI. This means being plugged into adoption. This step also has several dimensions. The first is to know how the organization uses AI to interact with customers. This could range from customer service support to AI embedded directly into products and services. Second, know how AI is used internally to help drive the business. This encompasses both direct support of internal business processes -- e.g., use by development, operations, accounting -- and potential shadow adoption use cases, such as an individual or team using an unapproved LLM to help support their own workflows. Finally, there's indirect adoption -- how technology and service providers use AI and piggyback it onto products and services already in use.
To obtain the information needed, establish instrumentation into the broader business to understand how departments use AI today and what their future AI roadmap looks like. Use the same techniques CISOS have relied on for years to keep abreast with other technological developments, among them periodic informal check-ins with business teams, structured interviews, information sharing partnerships with other teams -- e.g. internal audit -- and structured data gathering exercises.
Establishing a narrative
After collecting usage information and gaining the ability to objectively evaluate risk -- both potential new risks and mitigations -- the next step is to frame a narrative for the board. This is important because, while it's critical CISOs and their security teams understand AI well enough to separate risk from hype, it's also true that almost none of those engineering details belong in board conversations themselves.
Build the narrative carefully. First, assess and draw conclusions from the information collected from the broader business. Tap into resources including NIST's AI Risk Management Framework -- in particular supporting documents such as NIST AI 600-1; Mitre ATLAS; and OWASP's Top 10 lists, both LLM and agentic. The point is to establish a method to systematically review, assess and capture the information in a structured way.
Next, build and present conclusions in a way that initiates dialog. On a micro level, CISOs should find the method that makes them most comfortable. If, for example, a CISO already relies on an existing format to present risks to the board, incorporate AI risk into the existing model.
Still, it could be a good idea to specifically and purposefully focus on AI risks alone. Individual board members are likely to have concerns here -- for example, whether risks are being managed, whether certain issues are a factor for the organization, etc. Focusing on AI-specific discussions can kill two birds with one stone -- it gives members a chance to voice concerns and gives the board assurance that these areas are being accounted for.
None of this strategy is about sounding alarms or dampening enthusiasm. The board doesn't need CISOs to tell them that AI is dangerous any more than they need CISOs to tell them it's safe. Instead, the board needs someone to tell them which way the needle is moving in their organization -- by how much and over what time horizon. That's a trickier story to tell than sharing a list of threats. It's also one that changes as fast as the technology does. But it's also the story that lets a board actually govern AI rather than simply fear it or ignore it.
Ed Moyle is a technical writer with more than 25 years of experience in information security. He is a partner at SecurityCurve, a consulting, research and education company.
