Boards are now actively asking about AI. The issue is not awareness: it is the quality of the questions. “Are we using AI?” and “Do we have a policy?” are easy to answer, and the answers do not indicate whether an AI program is safe, compliant, or delivering value.
The governance surface has also widened. Organizations are no longer deploying only models that produce recommendations. They are deploying agents that hold credentials, call tools, update systems, and act across organizational boundaries. A model inventory is no longer enough; boards need visibility into the systems, data, tools, identities, and authority assembled around it.
The regulatory calendar has already moved. The EU AI Act’s Article 50 transparency duties took effect on August 2, 2026, while the July 2026 AI Omnibus moved most standalone high-risk obligations to December 2, 2027 and product-embedded high-risk systems to August 2, 2028. The distinction matters, since a deferred high-risk program does not defer the transparency duties that reach chatbots and synthetic content, and those are in force today. The scope of each duty, and the retroactivity condition buried inside it, are worked through separately.
In the United States, obligations continue to vary by jurisdiction, sector, and use case. NIST’s voluntary AI Risk Management Framework remains a useful operating reference, supplemented by its Generative AI Profile. As of August 2026 NIST states that AI RMF 1.0 is being revised and has published no completion date, so internal controls should track the revision instead of freezing to the 2023 text. The durable board posture is therefore not compliance with one static checklist. It is an operating model that can map a changing rule or threat to a current system inventory quickly.
What follows is a practical checklist for that discussion. The questions are phrased the way they should be asked in a governance setting.
1. Inventory and accountability
You cannot govern what you cannot see. The first failure mode in most organizations is that nobody has a current, accurate picture of where AI is actually being used, including shadow deployments, embedded vendor features, background agents, and tools connected after the original system was approved.
Questions to ask:
- Do we have a current inventory of every AI and ML system in use, including embedded vendor features and unsanctioned tools?
- For each system, have we inventoried its models, data sources, tools, MCP servers, memory stores, external connections, and non-human identities?
- Who is the accountable executive for each one? (Not a committee — a named person.)
- Which systems are classified as high-risk under the EU AI Act, and who confirmed that classification?
- Which systems interact directly with people in the EU or generate synthetic content that reaches them?
- When was the inventory last refreshed, and what event — procurement, a new tool, a model change, a permission change — forces a re-review?
If ownership resolves to a committee, responsibility is diffused. Effective governance requires a named executive accountable for outcomes and a system record detailed enough to show what the organization has authorized.
2. Risk classification and proportionality
Not every AI system warrants the same level of oversight. A marketing copy assistant and a credit adjudication model should not be governed identically. Nor should a support assistant that drafts a response and an agent that can issue a refund. A useful classification considers both legal category and operational authority: what the system influences, what data it can reach, and what it can do without a person approving the specific action.
Questions to ask:
- What is our risk classification framework, and does it align with the EU AI Act’s categories?
- Does the classification separately account for autonomy, data sensitivity, reversibility, external impact, and credential scope?
- How many systems fall into each tier?
- What controls are required at each tier, and are they actually being enforced?
- When a new AI use case is proposed, who decides the tier, and can they be overruled by the sponsoring business?
- Can adding a tool, persistent memory, or a broader permission automatically trigger reclassification?
A practical test: review the last three AI systems that were blocked or materially modified through governance. If none exist, the process is likely performative.
3. Data lineage and training data provenance
Some of the most consequential AI incidents begin as data failures: training on data without appropriate rights, using customer information beyond its disclosed purpose, or allowing an agent’s shared memory to cross a tenant boundary. These become legal, contractual, and trust failures rather than ordinary engineering tickets.
Questions to ask:
- For every production AI system, do we know what data was used to train, fine-tune, ground, evaluate, or provide persistent memory?
- Do we have documented legal basis for using that data for AI purposes specifically — not just for the original collection purpose?
- How do we prevent personal data, customer data, or confidential IP from flowing into model APIs, traces, tool results, and agent memory without authorization?
- If a person exercises a valid deletion request, can we remove the data from retrieval indices, logs, caches, memory, fine-tuning corpora, and every downstream copy we control?
- Can every answer, recommendation, or action be traced to the data and tool outputs that informed it?
This is often the point where clarity breaks down. Many organizations do not have a defensible answer, and the usual reason is that deletion was designed for the source system alone — every surface that can still return the content has to be on the list, including the indexes, caches, and derived summaries built from it.
4. System evaluation and ongoing monitoring
“We tested it before launch” is not evaluation. Production AI systems change as user behavior shifts, source data changes, vendors update models, and teams add tools or permissions. For an agent, the outcome depends on the model, prompt, context, memory, tool behavior, and authorization path. Evaluating only the final text misses most of the system.
Questions to ask:
- What metrics do we track on each production AI system, and how often are they reviewed?
- Do we have golden evaluation datasets, and when were they last refreshed to reflect real production traffic?
- For agents, do we measure task completion, path quality, and intervention rate, or only whether the final output looked right?
- How do we detect and respond to quality regressions, prompt injection attempts, memory poisoning, and out-of-scope requests?
- When a foundation model vendor silently updates their underlying model, how do we know, and how do we re-qualify?
- What changes can reach production without an evaluation run and an accountable approval?
Boards should request trend data on evaluation metrics for high-risk systems. If it does not exist, that absence is itself a finding. The machinery that produces those metrics belongs to a shared platform, since every product team otherwise rebuilds it at its own standard, which is the argument in the operating model behind production AI. The measurement set that applies to each system type is on the platform checklist.
5. Human oversight and escalation
Regulatory frameworks emphasize meaningful human oversight. In practice, this is often reduced to a confirmation button shown so frequently that approval becomes automatic. That is not oversight. A human gate is meaningful only when the reviewer has enough context, time, authority, and a safe way to disagree.
Questions to ask:
- For each high-risk system, what decisions require human review, and is the reviewer empowered and equipped to disagree?
- What percentage of AI recommendations are overridden by human reviewers? (Zero is a red flag; so is ninety.)
- Which agent actions require approval at the moment of action, and which standing permissions have been delegated in advance?
- Can reviewers see the proposed action, affected records, relevant evidence, and expected consequences before approving it?
- What is the escalation path when an AI system produces a harmful or clearly wrong output?
- Can we suspend an agent, revoke its credentials, and stop in-flight work quickly?
- How are frontline reviewers trained, and how is their effectiveness measured?
The measurable version of all this is the override rate, tracked per system and reviewed over time. A reviewer population that never disagrees is either unnecessary or unequipped, and a policy document cannot tell the board which one it is looking at.
6. Security and adversarial resilience
AI systems extend the traditional application-security surface. Prompt injection can arrive through a retrieved document, a tool result, or another agent, so the untrusted-input boundary sits wherever content enters the system, well upstream of the prompt box. Persistent memory can carry a poisoned instruction into later sessions, and a compromised tool or MCP server can turn a model error into an unauthorized action. OWASP’s current Agentic Security Initiative reflects this shift from securing a conversational model to securing an autonomous, connected system.
Questions to ask:
- Have our AI systems been red-teamed, and by whom? (Internal teams are a starting point, not a conclusion.)
- What protections do we have against prompt injection in systems that process untrusted content or tool results?
- Are consequential permissions enforced outside the model, using short-lived credentials and least privilege?
- How do we verify the identity, publisher, permissions, and behavior of third-party tools and MCP servers?
- Can one user, tool, or agent poison shared memory or influence another tenant?
- Who owns AI security — and does that person have authority over both the ML and security organizations?
- Are AI incidents tracked and reported through the same process as traditional security incidents?
Ask when the last exercise ran and what it found. A programme whose findings are uniformly low-severity is usually testing the model in isolation, whereas the consequential failures live in the surrounding system of tools, memory, and permissions — which is where the testing methods that surface them are aimed.
7. Third-party and supply chain risk
Most enterprises consume AI through a chain of vendors: foundation model APIs, embedded SaaS features, agent platforms, and remote tool servers. A vendor review focused only on the model provider misses much of the operational dependency.
Questions to ask:
- Does our vendor risk process include AI-specific questions — training data sources, model update policies, data retention, subprocessors, audit rights, and incident notification?
- When a core vendor adds AI features to an existing product, does that trigger a re-review?
- Are third-party agents, tools, MCP servers, and embedded vendor agents included in the same review?
- Do our contracts address material model or capability changes, data use, service continuity, security obligations, and responsibility for harm?
- Can a vendor expand an agent’s capabilities or data access without a new approval from us?
- What happens if a critical AI vendor is acquired, goes out of business, or changes their data policy?
The practical test is whether a vendor can widen what its agent reaches without telling you. Where the contract requires no notice of capability changes, the inventory in section one goes stale on its own, and nobody inside the organization has done anything wrong.
8. Regulatory readiness and documentation
The Omnibus changed the schedule, not the need for a regulatory operating model, and two things follow from the dates above. Transparency duties are already live, so the board question is what shipped rather than what is planned. The deferred high-risk dates then create a funding question this year, because an evidence roadmap that starts in 2027 will not be ready for a December 2027 application date. The Omnibus also replaced the earlier company AI-literacy obligation with non-binding encouragement, though workforce competence remains a practical control, and U.S. requirements continue to vary enough by jurisdiction and sector that a single national checklist is not a defensible substitute for legal mapping.
Questions to ask:
- Which systems fall under Article 50, and can we demonstrate the disclosure and synthetic-content controls that have been required since August 2, 2026?
- For content generated before that date but published after it, did we apply the marking rules that still attach?
- For each high-risk system, do we have a funded plan, accountable owner, evidence roadmap, and readiness milestones for the revised application date?
- Which general-purpose AI obligations apply to us as a provider, and where are we instead acting as a downstream provider or deployer?
- Who is responsible for monitoring regulatory developments across our operating jurisdictions?
- When was our last internal audit of AI controls, and what did it find?
- Could we respond to a regulator’s request for AI system documentation within 30 days without a fire drill?
Readiness here is mostly an evidence problem, and evidence is cheap to produce as the work happens and expensive to reconstruct a year later. A board can test the whole programme by asking for one artifact — the current documentation for a single high-risk system — and noting how long it takes to arrive.
9. Board-level reporting
Finally, a test of the governance program itself: what does the board see, and how often?
Questions to ask:
- Is AI risk a standing item on the audit or risk committee agenda?
- What metrics does the board receive, and do they include value delivered, risk exposure, inventory coverage, agent autonomy, incidents, near-misses, overrides, and control exceptions?
- Who briefs the board on AI — the CIO, the CISO, the Chief AI Officer, or a rotating cast?
- When was the last time the board saw an AI incident report?
- Which three AI systems could create the greatest harm through error, misuse, or excessive authority, and what evidence shows their controls work?
If AI appears only as a line item in a broader technology update, that is itself a governance gap.
The uncomfortable conclusion
Most AI governance programs are well-intentioned but structurally incomplete. Policies, committees, and presentations exist; operational mechanisms often do not. What is missing is execution: current system and authority inventories, active evaluation, enforceable permission boundaries, empowered reviewers, and evidence that controls work.
The point of a board-level checklist is not to become the expert. It is to ask questions precise enough that the absence of a real answer becomes visible. If executives cannot answer most of the questions above with specifics — names, numbers, artifacts — the governance program is not yet real, and the board now has a decision to make about what to do next.
The decision that follows is what matters. The rest is paperwork.
If your board is asking harder questions about AI and your team is working out how to answer them, I help executives build governance programs that are both compliant and operationally real. Get in touch.