How audit committees can discuss AI without pretending to be engineers

An audit committee does not need to become a room of machine-learning engineers to ask good questions about AI. It needs to understand where the organisation uses AI materially, who owns the resulting risk, what controls exist, what evidence supports management’s claims and where assurance is incomplete.

Technical depth should be available when required, but complexity must not become a shield. A committee can insist that management translate architecture and evaluation into consequences, accountabilities and verifiable control outcomes.

Begin with material use and authority

Ask for an inventory filtered by materiality, not a catalogue of experiments. Which AI systems influence financial reporting, customer obligations, regulated decisions, cybersecurity, confidential data, operational continuity or significant investment? Which can take action rather than merely suggest it?

For each material system, management should describe intended use, prohibited use, users, data, external providers, decision owner and maximum authority. This lets the committee distinguish a low-consequence drafting tool from an agent that changes enterprise records.

The NIST AI RMF Core treats inventory, clear roles and risk-prioritized governance as foundational. An audit committee cannot oversee a changing population of systems if management cannot identify it.

Keep ownership with management

Ask who owns the business outcome and who operates each control. Technology may run the platform while a business leader owns the workflow; security, privacy, legal and risk functions may challenge within their mandates. Internal audit should not become the first-line control owner merely because it asked the best questions.

The IIA AI Auditing Framework distinguishes governance, management and internal-audit domains. Use that separation to clarify who designs and operates controls, who monitors or challenges them, and who provides independent assurance.

A committee question worth repeating is: if this control fails tomorrow, which named executive must decide what happens next?

Ask for control outcomes, not policy names

“We follow the AI policy” is not evidence. Ask what the policy changes in practice. Are unapproved tools blocked? Are agent permissions scoped? Are high-impact actions confirmed? Are material changes evaluated? Can credentials be revoked and queued work stopped? Are users given recourse?

Organize evidence by control objective:

Objective	Evidence the committee can request
Bounded use	Approved scope, authority map and enforced prohibitions
Reliable change	Versioned release criteria and regression results
Protected information	Data-flow map, access decisions and retention controls
Accountable operation	Owner, monitoring, exceptions and incident records
Recoverability	Tested containment, rollback and business restoration

This does not require directors to validate source code. It requires management to show that claimed controls produce observable outcomes.

Challenge the quality of evidence

AI reporting can create false precision. Ask whether a score represents the deployed workflow, which cases and users were excluded, how non-determinism was handled, whether graders were validated and what would cause evidence to expire.

The GAO AI Accountability Framework links governance, data, performance and monitoring. A strong committee pack does the same: it states provenance and coverage of evaluation data, operational measures, known limitations and management action.

Pay particular attention to unsupported “compliant,” “safe,” “independent” or “industry-leading” language. Ask for the exact criteria, scope, assessor relationship and limitation behind any assurance claim.

Protect reporting integrity

AI can affect information that flows into management and external reporting. Ask where AI generates, transforms, classifies or summarizes material information; what review exists; and whether the source-to-report trail can be reconstructed.

The OECD corporate governance principles emphasize board risk oversight and integrity of reporting systems. In practice, that means controls over data lineage, model and prompt changes, approval, exception handling and correction—not an assumption that a human glance makes generated content reliable.

If an agent acts in a reporting process, review identity and transaction evidence as well as output quality. The committee should know whether one instruction can produce duplicate or unapproved state changes.

Define the assurance map

Ask which risks management self-assesses, which second-line functions review, what internal audit has examined and where external specialists are used. Distinguish design assessment from operating-effectiveness testing. An architecture review, penetration test and workflow evaluation answer different questions.

Independence and competence should be described, not inferred from a provider label. The committee should understand scope, methods, evidence access, conflicts, exclusions and whether findings were remediated or accepted.

Set a plan that follows materiality and change. A high-authority agent may require pre-release review and frequent operational evidence; a low-risk assistant may be covered through thematic controls and sampling.

End every discussion with decisions and triggers

A useful meeting ends with an owner, action and review trigger. Examples include constraining an agent’s authority, remediating a control, commissioning scoped assurance, improving incident evidence or returning after a material provider change.

Regular reporting should highlight change: new material systems, expanded permissions, unresolved high-consequence findings, exceptions, incidents, failed interventions and stale evidence. Avoid dashboards that are green because thresholds were never defined.

The committee’s contribution is disciplined challenge. It does not need to decide how a model routes tokens. It needs to know whether management can explain what the system is allowed to do, demonstrate controls, report uncertainty honestly and act when evidence weakens.

Use a standing agenda that exposes change

A short standing agenda can improve continuity without forcing every meeting into a comprehensive AI review. First, note material additions, retirements or expansions of authority. Second, review changes in high-consequence findings, exceptions and incidents. Third, examine one rotating control theme—such as supplier change, identity, evaluation quality or recovery. Fourth, confirm actions and upcoming decisions.

The pack should distinguish management assertion, operational evidence and assurance conclusion. “Access is restricted” is an assertion. A policy configuration and denied-call test are control evidence. An internal-audit assessment of design or operating effectiveness is an assurance conclusion with a stated scope. Presenting them in separate columns prevents confidence from migrating silently between them.

The committee can ask management to maintain a coverage map:

Material area	First-line evidence	Second-line challenge	Independent assurance	Next trigger
Agent permissions	Scope and denied-call tests	Identity review	Targeted audit planned	New external tool
Release evaluation	Cases, results, findings	Model-risk challenge	Method review complete	Model or policy change
Incident recovery	Drill and restoration record	Resilience review	Not yet assessed	Production expansion

Blank cells are not automatically failures. They make prioritisation explicit. The committee can decide whether consequence, novelty or repeated exceptions justify deeper assurance rather than assuming every AI system deserves the same audit treatment.

Minutes should preserve the question, evidence requested, management answer and action—not just that “AI was discussed.” That creates continuity when membership or technology changes and helps the committee judge whether recurring concerns are actually being resolved.

Private sessions with internal audit or other assurance providers can test whether reporting to the committee is complete and whether management pressure affects scope. The committee should also ask what expertise the assurance team used, which evidence it could not access and whether recommendations address root controls or only visible symptoms.

Where external regulation or contractual duty is material, obtain qualified advice on the committee’s obligations. The operating questions in this article help expose facts and evidence; they do not determine legal responsibility. Clear boundaries make specialist advice more efficient because the actual system authority, data and control design are already documented.

The committee adds value by making management’s AI claims reviewable: material uses are visible, control evidence is distinguished from assertion, assurance gaps are explicit and every unresolved issue has a decision path.