AI governance for Australian boards: what directors need to know

The AU board members we work with most often are non-technical but commercially sharp directors who’ve been told by management that “we have an AI strategy” — and need a way to test whether that’s true. This piece is the question set we hand to directors in that situation. It’s aligned to the Voluntary AI Safety Standard (the 10 guardrails framework the DTA published in 2024), but framed in the language an audit-committee chair actually uses — not the language of AI engineers.

You don’t need to understand the technical detail to govern AI well. You need a structured set of questions that test whether management has done the work, and a clear sense of what the answers should look like. That’s what’s below.

Why AI governance is a board responsibility, not a management one

Three reasons AI rises to board-level attention even in organisations where most technology decisions delegate cleanly to management:

1. The risk surface is novel. AI systems introduce risks (hallucination, drift, regulatory exposure on automated decisions, data leakage through prompts to third-party models) that don’t map cleanly to existing risk frameworks. The board owns the risk appetite — and an appetite that hasn’t been articulated for AI specifically isn’t fit for purpose.
2. The regulatory direction is clear. The Voluntary AI Safety Standard is voluntary now; the proposed mandatory guardrails consultation makes clear they’re intended to become mandatory for high-risk settings. The Privacy Act amendments expanding obligations around automated decisions are moving in the same direction. Boards that delegate AI fully to management now will find themselves accountable for it without having been part of the decisions.
3. The decisions are commercial and strategic, not just technical. Choosing to deploy AI in customer-facing settings, choosing to fine-tune on proprietary data, choosing the level of human oversight in automated decisions — these are governance decisions, not engineering decisions. They need board visibility.

For APRA-regulated entities, the board responsibility is explicit: CPS 230 requires board oversight of operational risk, CPS 234 requires board oversight of information security, and both apply to AI systems. For non-regulated entities, the responsibility is implicit in directors’ general duties — but it’s no less real.

The 12 questions every AU board should ask management

These map to the 10 Voluntary AI Safety Standard guardrails, collapsed into the questions a board can actually act on.

Strategy and accountability (3 questions)

1. Who in the organisation is accountable for AI safety, and to whom do they report?

There should be a single named executive. Not a committee, not a working group — a person. Usually it’s the CIO, CDO or COO. The reporting line should be direct to the CEO or to a C-suite peer, not buried three layers deep in IT.

Red flag: “It’s a shared responsibility across the technology team.” Translation: no one owns it.

2. Show us the prioritised list of AI use cases currently live in the business, and the status of each.

If management can’t produce this list in 24 hours, AI governance is not where it needs to be. Every live AI system — including shadow IT use of public LLMs by employees, embedded AI in SaaS the org has bought, custom-built systems — should be inventoried. Without the inventory, the board cannot ask any of the other questions meaningfully.

3. Show us the AI risk register, and walk us through the highest-rated risk.

A real risk register is specific. “AI may produce incorrect outputs” is not a risk; it’s a description of how AI works. “Our customer-facing chatbot may produce incorrect product information that leads to a misleading and deceptive conduct claim under the Australian Consumer Law” is a risk. Test the register on specificity, on whether each risk has a named owner, and on whether the mitigations are tracked to closure.

Data and inputs (2 questions)

4. What classifications of data are being sent to third-party AI services, and under what controls?

The clean answer involves a data classification scheme (public, internal, confidential, regulated), with explicit rules about what can be sent to which categories of AI service (internal models, AU-sovereign hosted, US-hosted foundation models). If your CHRO has been pasting employee performance reviews into ChatGPT, the board should know about that — and management should be designing the controls that stop it.

5. What’s our position on AU sovereignty for AI data processing?

There’s no single right answer — some boards rationally decide that the productivity gains from frontier US-hosted models outweigh the sovereignty considerations, with appropriate redaction controls; some boards rationally decide that the sovereignty position is non-negotiable for regulated data. What matters is that the position is explicit, board-approved, and consistent with how the org is actually operating.

Decisions and oversight (2 questions)

6. For any AI-assisted decision that affects a customer, employee, or external party — what level of human oversight is in place?

The Voluntary AI Safety Standard’s framing is “meaningful human oversight.” Operationally, that means three things: (a) the decision is reviewable by a human before it’s actioned, or (b) the decision is reversible after the fact with a clear escalation path, or (c) the decision is so low-stakes that automation without human review is appropriate. Management should be able to map every AI-assisted customer-affecting decision to one of those three categories.

7. Have we explicitly identified which AI use cases qualify as “high-risk” under the proposed mandatory guardrails framework?

The DTA’s proposed mandatory guardrails apply only to high-risk settings (broadly: significant impact on rights, safety, or access to services). Management should be able to (a) list which current AI uses they consider high-risk, (b) explain the framework they used to make that judgement, and (c) describe what additional controls apply to those uses.

Transparency and disclosure (2 questions)

8. When AI is involved in a customer-facing interaction, do we disclose that?

This is moving from “best practice” to “expectation,” driven by consumer law, by the OAIC’s evolving position on transparency in Privacy Act-related AI uses, and by sector-specific guidance from regulators. Management should have an explicit policy on disclosure — not a default of obfuscation.

9. Have we published any external information about our approach to AI — to customers, to suppliers, to investors?

For listed entities and entities with public sector or regulated counterparties, external transparency about AI use is becoming material. A clear public position — even a short one — is increasingly expected. The position doesn’t need to be detailed; it needs to be honest.

Supplier and third-party (2 questions)

10. What process do we use to evaluate AI capabilities in software we buy?

Most AI exposure for most AU mid-market organisations comes through embedded AI in software they buy — not through systems they build. Microsoft 365 Copilot, Salesforce Einstein, vertical SaaS with AI features. Management should have a procurement process that explicitly evaluates AI-related risks (data sovereignty, model behaviour, contract terms on data use) before software is bought, not after.

11. For any AI capability we’ve bought, do we understand the data flows — what data leaves our environment, where it goes, what the vendor does with it, who else can see it?

This is genuinely hard. Vendor documentation on AI data flows is uneven. Management may need to push vendors for clarity, sometimes through procurement leverage. But the board should expect a clear answer for every material AI vendor — not a wave at the vendor’s privacy policy.

Incident response (1 question)

12. If an AI system in our environment produced a harmful or non-compliant output tomorrow, what would happen in the first 24 hours?

This is the litmus test for whether the rest of the governance work has landed. There should be a clear answer: the named accountable executive is notified, the system is isolated or rolled back if appropriate, the incident enters the existing incident-response process, the legal and risk teams are engaged, and external disclosures (regulator, customer, market) are considered against a pre-agreed framework. If the answer is “we’d figure that out at the time,” the governance framework isn’t real.

What good looks like — three benchmarks

After working through the 12 questions, the board should expect to land in one of three places:

Benchmark A — Governance is mature. Management can answer all 12 questions immediately with documented evidence. The register is current, the inventory is comprehensive, the controls are working. The board’s ongoing role is oversight — quarterly review, exception-based escalation, periodic deep-dives on specific use cases.

Benchmark B — Governance is in progress. Management can answer some questions but not others. There’s an inventory but it’s incomplete; there’s a policy but it’s 12 months stale; there’s a named accountable executive but the risk register is generic. The board’s role here is to set a clear timeline to close the gaps and to track progress at each meeting.

Benchmark C — Governance is nascent. Management is surprised by several questions, can’t produce documentation, and the responses contain a lot of “we’re thinking about that.” The board should treat this as a material control gap and commission an external review or focused engagement to close it on a defined timeline — typically 12 weeks.

For boards that find themselves in benchmark B or C, the productised AI Governance Review is designed exactly for this — a 4-week engagement that produces the policy, the risk register, and the supplier evaluation framework aligned to the Voluntary AI Safety Standard, in a form that’s board-defensible.

A practical operating cadence

For boards landing in benchmark A (mature governance), the operating cadence we’d recommend:

• Each board meeting: AI is a standing item under the relevant committee (typically Audit & Risk, sometimes a dedicated Technology committee for larger organisations). Brief update on inventory changes, material risk register changes, and any incidents.
• Quarterly: deeper review of the highest-rated AI risks, with the accountable executive present. Review of any net-new AI uses introduced in the quarter.
• Annually: full review of the AI policy, the risk register methodology, and the use-case inventory. Reset of risk appetite as needed.
• On exception: any AI-related incident, any new high-risk use case proposed, any material regulatory change.

This isn’t additional governance burden — it’s integrating AI into the existing risk-and-compliance cadence the board already runs. Treat it as material, not separate.

What this isn’t

Worth being explicit about three things this question set deliberately doesn’t do:

• It doesn’t ask the board to make technical decisions. Choosing a model, choosing an architecture, choosing a vendor — these stay with management. The board sets the framework within which those decisions get made.
• It doesn’t demand that AI be deployed conservatively. Some boards will rationally embrace aggressive AI deployment for competitive reasons; some will rationally take a slower approach. The framework supports either — provided the decision is explicit and the risks are managed.
• It doesn’t replace specialist advice on specific high-risk AI uses. For genuinely material AI investments — particularly in customer-facing, decisioning, or safety-critical contexts — the board should commission specialist review, separate to the standing governance cadence.

The 12 questions are the structural framework. The detail of how each one is answered in your specific context is where the real work lives — and where a focused engagement can compress months of in-house deliberation into a few weeks of structured output.