Boards should ask which AI risk domain they are dealing with before discussing fixes. Separate employee use of AI, attacker use of AI, and attacks on AI systems, then gather evidence for the specific behaviour, owner, and control gap in that domain.
What Boards Should Ask Before They Fix Anything
Boards get better answers when they force the conversation into a single risk domain first, because AI programs fail in different ways depending on whether the concern is employee misuse, adversary use, or direct attacks on AI systems. The first question is not “how do we secure AI?” but “which AI behaviour are we assessing, who owns it, and what control gap are we trying to close?”
That framing prevents vague discussions and makes the evidence request concrete. It also stops management from mixing productivity concerns, cyber threat concerns, and model integrity concerns into one undifferentiated risk item.
Separate the Three AI Risk Domains
Employee use of AI is about sanctioned or unsanctioned staff behaviour, such as data entered into tools, prompts sent to external services, and reliance on generated output. Attacker use of AI is about how adversaries use AI to scale phishing, reconnaissance, social engineering, or code generation. Attacks on AI systems are about the AI service itself being targeted through prompt injection, model manipulation, data poisoning, tool abuse, or access-path abuse.
Those domains need different owners and different evidence. A productivity policy may reduce employee misuse, but it will not address attacker tradecraft or protect the AI system from hostile inputs. Board questions should therefore force management to name the domain, the business process, the control owner, and the measurable weakness.
When boards skip that separation, they often get broad assurances with no actionable follow-up. The result is usually either overcontrol, where harmless use is treated like a breach, or undercontrol, where a genuine adversarial path is hidden inside “AI adoption” reporting.
Ask for Evidence, Ownership, and the Specific Control Gap
The most useful board follow-up is evidence-led. Ask what logs, reviews, usage records, testing results, policy exceptions, or incident indicators support the claim that the chosen domain is understood and controlled. Then ask which team owns the risk, which control failed or is missing, and what changed because the risk was identified.
This is the point at which boards should require management to show whether the control gap is governance, technical enforcement, monitoring, user training, or third-party dependency. Good reporting names the domain, names the owner, and names the control objective. Weak reporting stays at the level of “AI risk awareness” and cannot show whether the organisation is safer.
For a broader governance lens, the NIST AI Risk Management Framework gives boards a way to insist on govern, map, measure, and manage discipline, while the ISO/IEC 42001:2023 AI Management System Standard helps management define accountability and operating controls for AI programmes. For AI-specific cyber exposure, the NIST IR 8596 Cyber AI Profile is useful when the board wants the cybersecurity functions mapped directly to AI risk.
Risk and Threat Considerations
Boards that do not separate AI risk domains can miss the real failure mode. Employee use risk is usually leakage, policy breach, or poor decision quality; attacker use risk is scale, speed, and deception; attacks on AI systems are integrity and trust problems that can turn a working system into a manipulated one without obvious alarms.
Failure mechanism: Management combines distinct AI behaviours into one umbrella risk and then applies the wrong control to the wrong problem, leaving the actual exposure unmeasured.
Impact: The board gets false confidence, control ownership becomes unclear, and the organisation may either overspend on low-value controls or leave a material attack path unaddressed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Govern | Boards are deciding how AI risk is governed and measured across distinct domains. |
| Recommendation — Use the govern function to assign clear accountability for each AI risk domain. | ||
| ISO/IEC 42001:2023 | AI management system | The question asks how boards should structure oversight of AI risk domains and ownership. |
| Recommendation — Define AI risk ownership and control objectives inside a formal management system. | ||
| NIST SP 800-53 Rev 5 | RA-3 — Risk Assessment | Boards are asking management to classify AI risks before selecting fixes. |
| Recommendation — Perform domain-specific risk assessments before approving AI controls. | ||
Practitioner Guidance
What to prioritise: Start every board discussion by forcing a one-sentence classification of the AI issue: staff use, attacker use, or system attack. If management cannot state the domain, they are not ready for a credible control discussion.
What to verify: Require evidence that matches the domain, not generic assurance. For staff use, verify policy, training, and data-handling rules; for attacker use, verify threat intelligence and detection coverage; for AI-system attacks, verify testing, hardening, and monitoring of the AI interaction and tool chain.
Practitioner takeaway: Boards do not need a longer AI risk list first, they need a cleaner taxonomy first, because precise domain separation is what turns AI oversight into a governable set of controls.