10 Essential AI Governance Questions for Board Members
Updated · Published
A board does not build AI systems. Its job is to be able to state, and evidence, that the organization knows what it is running, on what data, and under whose accountability. That claim became harder to make on 2 August 2026, when the EU AI Act moved into enforcement and its transparency rules went live, with the high-risk obligations landing in December 2027 and August 2028. These ten questions are what a board can put to management without understanding anything about model architecture. Each comes with what a good answer sounds like and what a weak one is usually hiding, and the difference is consistent. Strong answers name a mechanism, a person and a date. Weak answers name an intention.
Why AI Governance Is a Board-Level Priority
Artificial intelligence has stopped being a project and become an operating condition. It sits in credit decisions, hiring shortlists, claims triage, customer support and supply chain forecasting, and a large share of it arrived through purchased software rather than through anyone's data science team. That distinction used to feel important. The law no longer draws it.
A board does not run AI systems. Its responsibility is narrower and harder. It is to be able to state, and evidence, that the organization knows what it is running, on what data, under whose accountability, and within which legal obligations. Two years ago that was a matter of principle. Since 2 August 2026, when the European Commission's AI Office and national authorities began enforcing the EU AI Act, it has been a matter of law with dated obligations and fines attached.
The questions below are written for that job. They assume no knowledge of model architecture, and they are deliberately answerable. Each comes with what a good answer sounds like and what a weak one is usually hiding. The pattern is consistent enough to be useful on its own: strong answers name a mechanism, a person and a date, weak answers name an intention.
One clarification before the list. This is an oversight list, written for the people holding management to account. If you sit on the executive team and the question in front of you is whether to scale an AI program at all, the questions are different ones, about ambition, return, foundations and the people who have to live with the result. Those are set out separately in 10 Questions Every Executive Should Ask Before Scaling AI.
What the EU AI Act Puts on the Board
Boards do not need to read the regulation. They do need three things from it, because each one changes what a reasonable oversight question looks like. First, the compliance calendar, which is no longer the one most AI plans were built against.
| Date | What applies | Status |
|---|---|---|
| 2 Feb 2025 | Prohibited practices, and the AI literacy obligation on providers and deployers | In force |
| 2 Aug 2025 | General-purpose AI model obligations, governance structures, penalties | In force |
| 2 Aug 2026 | Transparency obligations, and the start of enforcement | In force |
| 2 Dec 2026 | Prohibition on non-consensual intimate imagery and CSAM, shortened transparency grace period | Coming |
| 2 Aug 2027 | National AI regulatory sandboxes must be established | Coming, postponed |
| 2 Dec 2027 | Stand-alone high-risk AI systems, the Annex III categories | Coming, moved from 2 Aug 2026 |
| 2 Aug 2028 | High-risk AI embedded in regulated products, the Annex I categories | Coming, moved from 2 Aug 2027 |
The high-risk dates moved under a simplification regulation given final approval by the Council on 29 June 2026. The detail of that change sits in our AI Omnibus article, and the full deadline picture in EU AI Act compliance deadlines. The two rows a board should not skim past are the ones already in force.
1. Using AI is not an exemption. Article 4 has applied since February 2025 and puts the AI literacy obligation on providers and deployers alike, which means organizations that only buy AI carry it too. Article 26 then loads a full set of duties onto deployers of high-risk systems: use the system according to its instructions, assign human oversight, monitor how it operates, retain logs, and inform workers and their representatives before a high-risk system is used on employees. A board that has been told the Act mostly targets the companies building models has been told something inaccurate.
2. Human oversight is an org-chart question. Article 26(2) is short and unusually specific. Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. Natural persons. Not a committee, not a function, not a policy document. That one sentence turns an abstract governance discussion into something a board can actually check, which is question 8 below.
3. Financial services carry a named extra duty. Article 27 requires a fundamental rights impact assessment from public bodies, from private entities providing public services, and from deployers of two specific Annex III categories: systems that evaluate the creditworthiness of natural persons or establish their credit score, and systems used for risk assessment and pricing in life and health insurance. Fraud detection is explicitly carved out of the creditworthiness category. For a bank or an insurer, that is a dated deliverable with defined contents, not a general principle.
And what non-compliance costs. Article 99 sets three tiers, each a fixed amount or a share of worldwide annual turnover, whichever is higher. Prohibited practices reach 35 million euro or 7 percent. Non-compliance with most other obligations reaches 15 million euro or 3 percent. Supplying incorrect, incomplete or misleading information to authorities reaches 7.5 million euro or 1 percent. For SMEs and startups the lower figure applies instead of the higher. The middle tier is the one most organizations should be pricing.
10 Essential AI Governance Questions for Board Members
Each question is followed by what to listen for, and by two answers drawn from the range boards actually hear.
1. How does our AI strategy support the business, and what has it returned so far?
AI budgets get approved on promise. At some point the promise has to become a number, and the board is the body that decides when that point has arrived. The failure mode is not a bad AI strategy, it is a portfolio of initiatives that were never held to the standard any other capital program would face.
Key Consideration. Ask for the same evidence you would ask of any investment: which business outcome, measured how, owned by whom, reviewed when. A program that cannot answer that after two years is not an AI problem.
Sample Good Response: "Two AI programs are funded. Fraud detection has cut confirmed fraudulent transactions by 20 percent year on year, measured by the risk function. Claims triage is in its second quarter and has not yet cleared its threshold, so it stays under review until December."
Sample Bad Response: "We are investing in AI because our competitors are. We are still working out where it fits."
2. Do we have a complete inventory of where AI is in use, including what we bought rather than built?
This is the question that most often produces a surprise. Organizations that run an honest first inventory usually find more AI in production than anyone had listed, much of it inside purchased software, some of it switched on by a vendor as a default. An inventory covering only what the data science team built is not an inventory, and every obligation in the AI Act starts from one.
Key Consideration. One register, covering built and bought, with an owner and a risk classification against every entry, and a process that catches new systems as they arrive rather than a spreadsheet refreshed once a year.
Sample Good Response: "The AI register holds 41 systems, 12 built in-house and 29 embedded in vendor products. Each carries a named owner, a risk classification and a review date. Procurement cannot approve software with AI features without an entry."
Sample Bad Response: "The data science team keeps a list of its models. We would have to ask around about the rest."
3. What legal, ethical and operational risks does our AI create, and has anyone priced them?
AI introduces compliance exposure, ethical exposure through biased or discriminatory outcomes, and operational exposure through automation failures and vendor concentration. Risks that get named but never priced tend not to get funded, and a risk sitting on its own slide rather than in the enterprise register is usually a risk nobody owns.
Key Consideration. AI risk belongs in the same register, with the same scoring, as every other enterprise risk. If it lives in a separate document maintained by a separate team, ask why.
Sample Good Response: "AI risks sit in the enterprise risk register, scored the same way as everything else. The three under active mitigation are bias in the hiring screen, drift in the credit model, and concentration on a single model provider."
Sample Bad Response: "We rely on our AI vendors to handle compliance. Nothing has gone wrong so far."
4. Where do our AI systems sit in the AI Act's risk tiers, and what does that oblige us to do?
Classification is the gate to everything else. The obligations, the deadline and the cost all follow from which tier a system lands in, and the Annex III categories reach further into ordinary business than most people expect: employment decisions, education, essential private and public services including creditworthiness, law enforcement, migration and critical infrastructure.
Key Consideration. Every entry on the register should carry a classification that is dated and justified. An undocumented conclusion that nothing qualifies as high-risk is the answer that ages worst.
Sample Good Response: "Three systems fall under Annex III, two in employment screening and one in creditworthiness, and they are scheduled against the December 2027 date. Everything customer-facing was assessed against the transparency rules that took effect in August 2026."
Sample Bad Response: "The Act mostly targets high-risk systems and we do not believe ours qualify. That assessment is not written down anywhere."
5. How would we know if a model were producing unfair outcomes?
Note the wording. Not whether management believes the models are fair, but how the organization would find out if they were not. Article 10 requires providers of high-risk systems to examine training, validation and testing data for biases that could affect health, safety or fundamental rights, and to put measures in place to detect, prevent and mitigate them. That is a detection duty, not a good-faith one.
Key Consideration. Ask about the mechanism and who runs it. An absence of complaints is not a monitoring result, and a fairness review run by the team that built the model is worth less than one run outside it.
Sample Good Response: "Outcome distributions for the hiring and lending models are reviewed quarterly against protected characteristics by a team outside the one that built them, and the findings go to the risk committee whether or not anything was found."
Sample Bad Response: "The models work from data, so bias is not really a concern for us."
6. What data powers our AI, and can we show where it came from?
A model inherits the quality and the legality of whatever it was trained or grounded on. Article 10 sets the bar plainly: training, validation and testing data sets must be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Meeting that is one problem. Proving it two years later, to someone who was not there, is a different and much harder one.
Key Consideration. Provenance captured continuously beats provenance reconstructed under audit pressure, by a margin that only becomes obvious once someone tries the reconstruction. Ask whether lineage is a system or a project.
Sample Good Response: "Every model in the register links to the datasets behind it, with lineage traced back to source systems. That link is maintained by the catalog rather than by a document, so it does not go stale when a pipeline changes."
Sample Bad Response: "We use the data that was available. Tracing it back to source would be a project in itself."
7. Could we explain a single decision to the person it affected?
Article 86 gives any person subject to a decision taken on the basis of a high-risk system's output, where that decision produces legal effects or significantly affects their health, safety or fundamental rights, the right to a clear and meaningful explanation of the role the AI system played and the main elements of the decision taken. The unit here is one decision affecting one named person, not the model in general. A model card does not answer it.
Key Consideration. The honest test is a drill. Pick a real case, ask for the explanation, and time how long it takes. Organizations that have never run it usually discover the retrieval path does not exist yet.
Sample Good Response: "Automated decisions in scope are logged with their inputs, the model version and the human review step. We have run the drill twice. The most recent one took four hours end to end."
Sample Bad Response: "The model itself is documented. Explaining one individual decision would take engineering time, and we have not tried it."
8. Who is accountable for AI governance by name, and what authority do they hold?
This is where Article 26(2) becomes a board question. Human oversight has to be assigned to natural persons with the necessary competence, training and authority, as well as the necessary support. Committees do not have competence, training and authority. People do. Organizations certifying against ISO/IEC 42001, the AI management system standard published in 2023, face the same demand from a different direction, since it requires roles, responsibilities and authorities for the management system to be defined, assigned and communicated.
Key Consideration. Ask for names, not structures. Then ask the harder follow-up: can that person stop a system without waiting for a committee, and do they have a budget.
Sample Good Response: "AI governance reports to the Chief Risk Officer. Every system on the register has a named accountable owner and a named data steward, and the owner can suspend a system without escalation."
Sample Bad Response: "A cross-functional working group meets monthly. Day to day it is handled by whoever is closest to the system."
9. Could we produce the documentation an audit would ask for, without a fire drill?
The AI Act is specific about records. Article 11 requires technical documentation for a high-risk system to be drawn up before it goes into service and kept up to date thereafter, containing at minimum the elements set out in Annex IV. Article 12 requires the systems to technically allow for the automatic recording of events over their lifetime. Both are continuous obligations, which is the part that catches organizations out. Documentation written once ages the moment the system changes.
Key Consideration. Records tied to the assets themselves stay current. Records tied to a document do not. Ask when the documentation was last updated and what triggered the update, because "annually" and "when the system changed" are very different answers.
Sample Good Response: "Documentation lives against the assets in the catalog and updates when they do. Logs are retained for the required period. We ran a mock inspection in June and closed the two gaps it found."
Sample Bad Response: "We have documentation for the main models. Some of it dates from the original build."
10. What would make us switch an AI system off, and who can make that call?
The AI Act assumes a suspension path exists. Article 26(5) requires deployers to monitor operation, to inform the provider and the market surveillance authority without undue delay where a system presents a risk, to suspend its use where appropriate, and to report serious incidents immediately. A board can reasonably ask what "where appropriate" has been defined to mean inside the organization, because a threshold nobody wrote down is a decision that will be made under pressure by whoever happens to be available.
Key Consideration. Documented suspension criteria, a named person who can act on them, and evidence that the path has been tested at least once on something real.
Sample Good Response: "Each system has written suspension criteria and a named person who can trigger them. We used it on the pricing model in March when drift crossed the threshold, and it was out of production within the hour."
Sample Bad Response: "We would escalate to the steering group. We have not defined what would trigger that."
Conclusion
Read back through the paired answers and one pattern separates them. Good answers contain a mechanism, a name and a date. Bad answers contain an intention. "We take bias seriously" is an intention. "Outcome distributions are reviewed quarterly by a team outside the one that built the model, and the findings go to the risk committee" is a mechanism. A board does not need to evaluate a model to tell those two apart, which is the whole point of asking.
Notice also what none of the ten questions require. Not one asks the board to understand a model architecture, assess an algorithm, or arbitrate a technical dispute. They ask whether the organization can produce a register, a classification, an owner, a log, a lineage and a suspension path. That is the actual shape of the obligation, and it is why so much of AI governance turns out to be metadata work rather than model work.
Most of it is a discipline that already exists. A governed data catalog holds the inventory of AI use cases and the systems behind them. Data lineage shows what data reached a model and where it came from. Classification records what is sensitive and where it lives. Kept against the assets themselves, those records stay current in a way a compliance document written once never does. More on how we approach it on the AI governance page.
The dates that matter are now as much behind us as ahead. Transparency obligations and enforcement started in August 2026. December 2027 and August 2028 look comfortably distant right up until an organization tries to classify every AI system it owns and evidence the data behind each one. The boards that will find those dates comfortable are the ones asking these questions on a standing agenda item now, rather than once, in response to a headline.
FAQ
What questions should a board ask about AI?
Is the board responsible for AI governance?
Does the EU AI Act apply if we only use AI we bought?
What are the penalties under the EU AI Act?
How often should a board review AI?
What is the difference between AI governance and data governance?
Sources
- EUR-Lex - Regulation (EU) 2024/1689, the AI Act. Articles 4, 10, 11, 12, 26, 27, 86 and 99, and Annex III
- European Commission - Commission starts enforcing AI Act rules and new transparency requirements on 2 August, 31 July 2026
- Council of the EU - Artificial Intelligence: Council gives final green light to simplify and streamline rules, 29 June 2026
- European Parliament - AI Act: EP approves simplification measures and nudifier app ban, plenary vote 15 June 2026
- ISO - ISO/IEC 42001:2023, the artificial intelligence management system standard
See it in action
AI Governance with Dawiso
Catalog your AI use cases, trace the data behind them, and keep the documentation an audit will ask for.