AI Governance Training for Boards and Executives in Australia

This guide is general information for Australian boards, executives and leadership teams. Legal, prudential and privacy advice has to come from the organisation's own lawyers and advisers, including how the Corporations Act, the Privacy Act, any APRA standard that applies, and the National AI Centre's guidance fit the uses that organisation actually runs.

The page is for directors and executives who have been asked to "do something on AI governance" and want the public rules in one place before they book a room. It covers the duty of care and diligence in section 180 of the Corporations Act 2001, what the Australian Institute of Company Directors has put in front of directors, what APRA's CPS 230 and CPS 234 ask of a board where those standards apply, and the six essential practices in the National AI Centre's Guidance for AI Adoption. It then sets out what good AI governance training for a board or executive team covers, and the documents and names the session should leave behind.

Collective Campus has been running capability building programs for organisations across the globe since 2015. The programs take in design thinking, customer experience, agile, lean startup, productivity, psychological safety, critical thinking and AI. This guide is about the governance slice of that work. Two ways to run it are linked later: one for boards and executives, and one for staff and teams.

Who this guide is for

The reader is a director, a chief executive, a chief risk officer, a general counsel, a chief information officer, a chief privacy officer, or the executive who has just been told they own AI. The organisation might be a bank, an insurer, a superannuation trustee, a private company, a listed company, a government business or a large not-for-profit. The legal hooks are not the same for each of them. The habit of naming an owner is.

A board in a regulated financial institution has a thicker set of documents to connect. CPS 230 and CPS 234 are written for APRA-regulated entities. A proprietary company that sells software to those entities is in a different position: the statute on directors' duties can still apply, and the customer may push service-provider terms down the contract, but the company is not an APRA-regulated entity merely because a customer is one. Training that blurs that line teaches the wrong fear.

The guide is written for an Australian audience. The Corporations Act point is a Commonwealth statute. The National AI Centre guidance is Australian government guidance for industry. Privacy guidance cited here is from the Office of the Australian Information Commissioner. City names do not change those documents. An executive team in Sydney uses the same section 180 as an executive team in Perth. What changes is the live use on the table, the data it touches, and the sector licence the organisation already holds.

Why a board asks for the training

Staff are already using AI tools. Some of those tools were bought by the organisation. Some were opened in a browser because the approved path was slow or unclear. A board often hears about a use after a customer letter, a staff note or a vendor renewal has already assumed the tool is allowed. The training exists so directors and executives can see the uses, decide which ones may continue, and name the person who will watch them.

A policy file in a shared folder does not do that work by itself. People follow a rule they have seen, written in the language of the task they do on a Tuesday. A rule with no owner is a sentence nobody applies. Accountability split across technology, legal, the business owner and the vendor collapses the moment something goes wrong, because nobody can say who signed.

Directors do not need a product demonstration as a substitute for that decision. A demonstration shows a feature. Governance training shows the decision rights. The feature can change next quarter. The questions below should still be answerable: what is the use, whose outcome does it touch, what data goes in, what harm looks like, who can stop it, and when will the board look again.

The National AI Centre makes a related point on its foundations page. The same tool can create different risks depending on how it is used. Drafting a marketing email is a different use from assessing job applications. Training that talks about "AI" as one thing, with one risk rating, misses the distinction the guidance treats as basic.

Directors' duties and section 180

Section 180 of the Corporations Act 2001 sits in Part 2D.1, in the division on general duties. The heading in the compilation is care and diligence, civil obligation only. The latest compilation on the Federal Register of Legislation, register id C2026C00432, started on 19 September 2026. The text below is taken from the official Word volume of that compilation, Chapter 1 through to section 260E.

Section 180(1) says a director or other officer of a corporation must exercise their powers and discharge their duties with the degree of care and diligence that a reasonable person would exercise if they were a director or officer of a corporation in the corporation's circumstances, and occupied the office held by, and had the same responsibilities within the corporation as, the director or officer. The note to the subsection records that it is a civil penalty provision. See section 1317E.

Two features matter for an AI paper. First, the test is objective and situated. The comparison is a reasonable person in that corporation's circumstances, in that office, with those responsibilities. A director of a small proprietary company and a director of an APRA-regulated insurer are not measured against an abstract director with no context. Second, the duty is about powers and duties, not about a technology category. The section does not mention artificial intelligence. A decision to deploy a model, a decision to ban a tool, and a decision to leave a tool in place without a rule are all capable of being exercises of a director's or officer's role. The care and diligence question is how they informed themselves and how they supervised the matter.

Officers are a wider group than the board. The simplified outline in the same Part notes that officers include, as well as directors and secretaries, some other people who manage the corporation or its property. Definitions of director and officer are in sections 9AC and 9AD. An executive who is an officer can owe the duty even when the board paper was thin. Training that speaks only to non-executive directors and ignores the executives who approve the spend teaches half the room.

Section 181 is the neighbouring civil duty. Boards often hear directors' duties as a bundle, so the neighbouring duty is set out here. Section 181(1) requires a director or other officer to exercise their powers and discharge their duties in good faith in the best interests of the corporation, and for a proper purpose. It is also marked as a civil penalty provision. This guide does not walk through the criminal offences in section 184. The point for a training session is narrower: an AI use still has to be capable of being explained as in the best interests of the corporation, for a proper purpose, and handled with care and diligence.

The business judgment rule

Section 180(2) is the business judgment rule. A director or other officer who makes a business judgment is taken to meet the requirements of subsection (1), and their equivalent duties at common law and in equity, in respect of the judgment if they make the judgment in good faith for a proper purpose, do not have a material personal interest in the subject matter of the judgment, inform themselves about the subject matter of the judgment to the extent they reasonably believe to be appropriate, and rationally believe that the judgment is in the best interests of the corporation.

The subsection then says the director's or officer's belief that the judgment is in the best interests of the corporation is a rational one unless the belief is one that no reasonable person in their position would hold. A note records that the subsection only operates in relation to duties under section 180 and their equivalent duties at common law or in equity, including the duty of care that arises under common law negligence principles. It does not operate in relation to duties under any other provision of the Act or under any other laws.

Section 180(3) defines business judgment as any decision to take or not take action in respect of a matter relevant to the business operations of the corporation. A decision to adopt a tool, and a decision not to adopt it, can both be business judgments if the other facts fit.

The limb that training should spend time on is the duty to inform oneself to the extent the person reasonably believes appropriate. A board pack that says the vendor is a leader, and stops there, is a poor record of that limb. A better record shows what the tool will be used for, what data it will see, who is affected, what testing has been done, what the contract allows the organisation to audit or exit, and who inside the organisation remains accountable after the contract is signed. None of that is a guarantee that the business judgment rule will be available. It is the sort of information a director would want in the minutes if they later had to show they informed themselves.

Personal interest matters too. A director with a material personal interest in a vendor, a data partnership or a related-party licence has to deal with that interest under the rule and under the rest of the Act. Training should tell directors to declare the interest in the ordinary way. It should not invent a special AI form that sits outside the conflicts process the company already has.

This is the edge of what a public guide can say. Whether a particular decision meets section 180 is a question for that corporation's facts and for advice. The training outcome is more modest and more useful: directors can say what they would need to see before they approve a use, and management can see that list before the paper is written.

What the AICD has published for directors

The Australian Institute of Company Directors, in partnership with the Human Technology Institute at the University of Technology Sydney, publishes A Director's Guide to AI Governance. The AICD page for Version 2 is dated 29 June 2026. The page says the resources were updated to account for AI change and for maturing governance practice since the 2024 resources. It says AI tools and systems have become embedded in many Australian organisations, often with significant investment, and it names agentic AI as a further shift toward automation and system integration.

The page describes opportunity and risk together. It says AI presents opportunities to enhance productivity, improve decision-making and deliver products and services, and that it also introduces complex and interconnected risks, including cyber security and data governance. It says the board plays a key role in governing the balance between opportunity and risk. The stated objective of the updated resources is to equip boards with insight, including oversight of the human impact of AI on employees, customers and broader stakeholders.

The resources listed on that page are the Director's Guide to AI Governance, a SME and NFP board summary and checklist, and a concise snapshot. This guide does not summarise the full Director's Guide. The public page is the checkable source for what AICD is telling directors exists. A board session can use the public page as a prompt for its own questions: where is opportunity being claimed, where is cyber and data risk being named, and where is the human impact on staff and customers written down. A session that only recites a public guide, and never opens the organisation's own register, has not started the local work.

Smaller boards and not-for-profit boards should notice that AICD published a separate summary and checklist for them. The National AI Centre makes a similar size point. The foundations guidance says an organisation adapts each practice to its size, its use cases and its risk profile, and that it does not need to do everything at once. A training session for a large listed board and a session for a small board can share the six practices and still leave different artefacts. The small board might leave a two-page policy and a one-page register. The large board might leave a framework that ties into an existing risk management system. Both are governance if a named person owns them.

APRA CPS 230 and the board

Prudential Standard CPS 230 Operational Risk Management is a cross-industry standard. APRA's news release of 1 July 2025 said the standard came into force that day for banks, insurers and superannuation funds. The release described the requirement as preparation to keep critical services going and to respond to disruptions: identify important business services and how far they can continue in a severe disruption, test business continuity planning, and manage risk from material service providers.

On 30 April 2026 APRA's operational risk management page said APRA had released final targeted amendments to CPS 230, to Prudential Practice Guide CPG 230, and to the material service provider register template. That page says the amendments introduce limited exemptions from specific contractual requirements for material arrangements with certain categories of service providers, where contractual compliance is not practicable, and that the updated CPS 230 and CPG 230 commence on 1 July 2026. The standard page on APRA's site is marked in force from 1 July 2026 and states that the standard commences on 1 July 2026. The board duties in this section are taken from that current text. A board paper written in 2025 should be checked against the amended text rather than assumed to be unchanged.

CPS 230 applies to authorised deposit-taking institutions, including foreign ADIs, and to authorised banking non-operating holding companies. It applies to general insurers, including Category C insurers, authorised insurance non-operating holding companies and parent entities of Level 2 insurance groups. It applies to life companies, including friendly societies, eligible foreign life insurance companies and registered non-operating holding companies. It applies to private health insurers. It applies to registrable superannuation entity licensees in respect of their business operations. Obligations on a foreign ADI, a Category C insurer and an eligible foreign life insurance company apply only to the Australian branch operations.

The aim stated in the standard is that an APRA-regulated entity is resilient to operational risks and disruptions. The entity must manage its operational risks, maintain its critical operations through disruptions, and manage the risks arising from service providers. The approach must be appropriate to size, business mix and complexity.

What the board must do

The current text says the board is ultimately accountable for oversight of the entity's operational risk management. That includes business continuity and the management of service provider arrangements. For an RSE licensee, a reference to the board is to the board of directors or the group of individual trustees, as applicable. For a foreign ADI, a reference to the board is to the senior officer outside Australia.

The board must ensure the entity sets clear roles and responsibilities for senior managers for operational risk management, including business continuity and service provider arrangements. The board must oversee operational risk management and the effectiveness of key internal controls in maintaining the operational risk profile within risk appetite. The board must be given regular updates on the operational risk profile and must ensure senior management takes action as required to address any areas of concern. The board must approve the business continuity plan and the tolerance levels for disruptions to critical operations, review the results of testing, and oversee the execution of any findings. The board must approve the service provider management policy and review risk and performance reporting on material service providers.

Senior management must provide clear and comprehensive information to the board on the expected impacts on critical operations when the board is making decisions that could affect the resilience of those operations. That sentence is the one to read twice when a board is asked to approve an AI platform that sits under payments, claims, member administration or customer enquiries. Management's job is to say what happens to the critical operation if the service fails, degrades or cannot be exited.

Operational risk, incidents and new technology

The standard says an entity must manage its full range of operational risks. The list includes legal risk, regulatory risk, compliance risk, conduct risk, technology risk, data risk and change management risk. It does not use the words artificial intelligence. It does say senior management are responsible for operational risk management across the end-to-end process for all business operations. It also says the entity must maintain information and information technology capability to meet current and projected business requirements and to support critical operations and risk management, and that technology risk management must meet CPS 234.

The entity must assess the impact of business and strategic decisions on its operational risk profile and operational resilience as part of business and strategic planning. The standard says this must include an assessment of the impact of new products, services, geographies and technologies. An AI use is a technology decision, and often a new service decision, even though the standard does not name it. A leadership team in an APRA-regulated entity should be able to point to where that assessment sits, and to the control owner.

Incidents and near misses must be identified, escalated, recorded and addressed in a timely way, and taken into account in the operational risk profile and in control effectiveness. The entity must notify APRA as soon as possible, and not later than 72 hours, after becoming aware of an operational risk incident that it determines is likely to have a material financial impact or a material impact on the ability to maintain critical operations. A note says a notification of an information security incident reported under CPS 234 does not need to be reported again under this notification requirement.

Material weaknesses, including control gaps, weaknesses and failures, must be remediated with clear accountabilities and assurance, and must address root causes in a timely way. They stay in the operational risk profile until they are remediated.

Critical operations and tolerance

Critical operations are processes undertaken by the entity or its service provider which, if disrupted beyond tolerance levels, would have a material adverse impact on depositors, policyholders, beneficiaries or other customers, or on the entity's role in the financial system.

The standard sets minimum classifications unless the entity can justify otherwise. For an ADI, the minimum list includes payments, deposit-taking and management, custody, settlements and clearing. For a general, life or private health insurer, it includes claims processing. For an RSE licensee, it includes investment management and fund administration. For all APRA-regulated entities, it includes customer enquiries and the systems and infrastructure needed to support critical operations.

For each critical operation the entity must set tolerance levels for the maximum time it would tolerate a disruption, the maximum data loss it would accept, and the minimum service levels it would maintain under alternative arrangements. The board approves those tolerance levels. If an AI service is part of how a critical operation is delivered, the tolerance discussion is incomplete until someone says whether the operation can meet the tolerance without that service.

The business continuity plan must include the register of critical operations and tolerance levels, triggers and resource arrangements, the actions to stay within tolerance, an assessment of execution risks and dependencies, and a communications strategy. The entity must have a systematic testing program covering all critical operations, including an annual business continuity exercise. The program must include severe but plausible scenarios, including disruptions to services from material service providers. Internal audit must periodically review the plan and assure the board that the plan is credible and that testing has been conducted satisfactorily. The entity must notify APRA as soon as possible, and not later than 24 hours after, a disruption to a critical operation outside tolerance.

Material service providers

A material service provider is one the entity relies on to undertake a critical operation, or one that exposes it to material operational risk. The entity must keep a register and manage the material risks. It must submit the register to APRA annually. Minimum classifications, unless justified otherwise, include core technology services, risk management and internal audit for all APRA-regulated entities, plus sector lists such as claims management for insurers and fund administration, custody and investment management for RSE licensees.

The policy on service providers must cover how material providers are identified and managed, including fourth parties that a material provider relies on to deliver a critical operation. A fourth party, in the standard's note, is a party that a service provider relies on in delivering services to the entity. That is the clause that reaches a model host, a cloud region or a sub-processor sitting under an AI vendor, where the arrangement is material.

Before entering or materially modifying a material arrangement, the entity must do due diligence and assess financial and non-financial risks, including geographic location and concentration. Material arrangements need a formal agreement covering services and service levels, ownership of assets, ownership and control of data, dispute resolution, audit access, liability and indemnity, legal and compliance obligations, notification of material subcontracting, liability for sub-contractor failure, force majeure, and termination rights. The agreement must also allow APRA access to information and an on-site visit, and must say the provider will not impede APRA. The April 2026 amendments, as described on APRA's consultation page, add limited exemptions from specific contractual requirements for certain categories of provider where compliance is not practicable. The categories sit in an attachment to the standard. A board should ask which arrangements, if any, the entity is treating as exempt, and what oversight replaces the missing contract term.

An AI vendor is not automatically a material service provider. The test is reliance for a critical operation, or material operational risk. Training should make executives apply that test to the actual contract, not to the word AI.

APRA CPS 234 and information security

Prudential Standard CPS 234 Information Security says the board of an APRA-regulated entity is ultimately responsible for the information security of the entity. The board must ensure the entity maintains information security in a manner commensurate with the size and extent of threats to its information assets, and which enables the continued sound operation of the entity. The same reading notes apply: for an RSE licensee the board includes a group of individual trustees where that is the structure, and for a foreign ADI the reference is to the senior officer outside Australia.

The entity must clearly define the information security roles and responsibilities of the board, senior management, governing bodies and individuals who decide, approve, oversee or operate information security. It must maintain an information security capability commensurate with the threats, and which enables continued sound operation. It must implement controls to protect information assets commensurate with the criticality and sensitivity of those assets, and it must undertake systematic testing and assurance of those controls. It must notify APRA of material information security incidents.

The information security policy framework is the totality of policies, standards, guidelines and procedures on information security. It must be commensurate with exposures to vulnerabilities and threats, and it must give direction on the responsibilities of all parties who have an obligation to maintain information security.

Classification, third parties and notification

The entity must classify its information assets, including those managed by related parties and third parties, by criticality and sensitivity. The classification must reflect the degree to which an information security incident affecting the asset could affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries or other customers.

That classification duty is the cleanest bridge from CPS 234 to an AI tool. A prompt store, a retrieval index full of member files, a transcription of calls, or a model fine-tuned on customer complaints is an information asset or sits on top of one. If a third party manages it, the classification duty still names it. The standard does not contain the words artificial intelligence in the text reviewed for this guide. The duty is written in the language of information assets, controls, testing and notification. Those words are enough.

The entity must have an information security response plan that covers detection through to post-incident review, and escalation and reporting of incidents to the board, other governing bodies and the individuals responsible, as appropriate. Testing that finds control deficiencies which cannot be remediated in a timely way must be escalated and reported to the board or senior management. Testing must be done by appropriately skilled and functionally independent specialists. The sufficiency of the testing program must be reviewed at least annually or when information assets or the business environment change materially.

Internal audit must review the design and operating effectiveness of information security controls, including controls maintained by related parties and third parties. Where an incident affecting those assets could materially affect the entity or its customers, and internal audit intends to rely on assurance provided by the related party or third party, internal audit must assess that assurance.

Notification has two clocks. The entity must notify APRA as soon as possible and, in any case, no later than 72 hours, after becoming aware of an information security incident that materially affected, or had the potential to materially affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries or other customers, or that has been notified to other regulators in Australia or elsewhere. Separately, the entity must notify APRA as soon as possible and no later than 10 business days after it becomes aware of a material information security control weakness which it expects it will not remediate in a timely manner.

A leadership team should be able to say who starts the 72-hour clock, who decides materiality, and how the board hears about it. Those are operating facts. They belong in the incident plan, and the board should know the plan exists.

Where the prudential standards meet an AI use

Put the two standards next to a single use and the questions become specific. Take a claims-triage assistant at a general insurer, or a member-enquiry assistant at a superannuation trustee. Claims processing is on the minimum critical-operations list for an insurer. Customer enquiries are on the list for every APRA-regulated entity. If the assistant is how that operation is delivered, CPS 230 asks for tolerance levels, a business continuity path if the assistant fails, and a view on whether the provider is material. CPS 234 asks whether the transcripts, member identifiers and decision logs are classified, who holds them, how controls are tested, and how a leak or a corruption of the store would be notified.

A copilot used by a finance team to draft an internal note may sit in a different place. It can still be a technology and data risk under CPS 230's list of operational risks. It can still be an information asset if the note contains customer data. It may not be a critical operation. Training that gives every use the same red rating teaches people to ignore the rating. Training that gives every use a green rating because the vendor used the word enterprise teaches the opposite mistake. The standards ask for classification, materiality and tolerance. The session should practise those words on real uses.

Entities that are not APRA-regulated can still borrow the questions without pretending the standard binds them. A private company can ask which operations would hurt customers if they stopped, which suppliers sit under those operations, and which information assets are too sensitive for a public tool. That is ordinary risk management for a company the standard does not bind. A paper should say so, and should keep the CPS 230 label for entities the standard actually covers.

The National AI Centre's Guidance for AI Adoption

On 21 October 2025 the Department of Industry, Science and Resources published the Guidance for AI Adoption. The Department's Voluntary AI Safety Standard page says the guidance outlines six essential practices for safe and responsible AI governance, and that this updated and simplified guidance for industry evolves the Voluntary AI Safety Standard. The National AI Plan page on the same department site says the National AI Centre released the guidance on 21 October 2025, and that the guidance includes practical resources, including editable AI policy templates.

The six practices, in the order used on the National AI Centre's foundations page, are:

1. Decide who is accountable.
2. Understand impacts and plan accordingly.
3. Measure and manage risks.
4. Share essential information.
5. Test and monitor.
6. Maintain human control.

The foundations page is for teams that are starting to use AI, using it in lower-risk ways, new to AI governance, or in need of practical guidance in a business setting. It says organisations that already have mature governance, technical capability or higher-risk use cases should use the implementation guidance. It says to work through all six practices, to begin with the getting-started actions, and to move to the next-step actions as use expands. It says an organisation does not need to do everything at once, and should adapt each practice to size, use cases and risk profile.

Some practices apply across the organisation, such as having an AI policy. Others apply to an individual use. The page says to check each use and to consider how a tool could be misused. It says to keep records of the actions taken under each practice, because documentation supports audit, review and improvement. The foundations PDF linked from that page is marked published 5 May 2026. Where a board pack quotes the practices, it should say which page it used, because the Department has already moved from ten guardrails to six practices and may keep editing the supporting pages.

The implementation guidance repeats the six headings and then goes into numbered expectations: accountable people across the organisation and its contractors, supply-chain accountabilities, training for the people who carry those roles, stakeholder engagement, risk processes that distinguish traditional IT from narrower AI, general-purpose AI and agentic systems, and human oversight matched to autonomy and stakes. A board does not need to recite clause numbers. It needs to know the foundations page is the starting agenda and the implementation page is where management goes when a use is no longer small.

1. Decide who is accountable

The foundations page says the organisation is ultimately accountable for how and where AI is used, and that complexity can leave gaps where nobody takes responsibility for outcomes. The getting-started actions are to assign a senior leader as the overall AI governance owner, with enough authority and enough understanding of capabilities and risks to oversee all AI use, and to create an AI policy that tells staff how the organisation will use AI and how to manage the risks. The National AI Centre points to an AI policy template for that start.

The next steps are to make a specific person accountable for every AI system, to train those people so they can make informed decisions, to clarify supply-chain accountabilities where vendors, developers and integrators share a system, and to turn the policy into a governance framework with clear policies and procedures.

The implementation guidance goes further. It says to assign, document and communicate who is accountable, including contractors and third parties, for safe and responsible policies, for development and deployment of every system including ongoing human control, for oversight of third-party development and use, for testing, for concerns and redress, and for the performance and improvement of the management system. For each accountable person it says to define competencies and authority, and to staff them and resource them. It also treats AI literacy and training as part of accountability, including training that covers legal and regulatory obligations.

A board session should leave the overall owner's name, not a committee label with no chair. It should leave a sentence on what that person can stop without waiting for the next quarterly meeting. It should leave a rule for who inside the organisation speaks to the vendor when a shared system fails. "The vendor owns the model" is not an accountability map. The organisation remains accountable for the use, which is the sentence the foundations page starts with.

2. Understand impacts and plan accordingly

The foundations page says AI systems can operate at speed and scale, so impacts are often magnified. It gives unwanted bias in data as an example, and the hiring shortlist as a picture: a biased shortlist can reject many qualified candidates before anyone notices. The getting-started actions are a stakeholder impact assessment and contestability channels. The assessment identifies groups who may be affected, with particular attention to vulnerable or marginalised people, and it looks at impacts such as unfair decisions, inaccurate or harmful information, and over-reliance. Contestability means a channel to report problems, challenge a decision or ask a question, strong enough for the seriousness of the impact, plus a way to put things right if someone has been harmed.

Next steps are to engage staff and customers early and through the life of the system, and to watch patterns of feedback so systemic unwanted impacts are fixed rather than handled one complaint at a time.

The implementation guidance treats stakeholder identification and engagement as the way an organisation understands impacts, and it expects people who are affected to be able to raise complaints and get help. A board does not run the assessment in the abstract. It asks management which uses can change a person's job, credit, claim, benefit, grade or access to a service, and where that person can challenge the outcome. If the answer is "they can email the vendor", the channel is not the organisation's channel.

Training should also separate impact from intention. A tool bought to save time in a call centre can still produce a wrong answer at volume. The impact assessment is about who bears that wrong answer, not about the business case that funded the licence.

3. Measure and manage risks

The foundations page says AI risks change with the type and complexity of the system, and often come from how the system behaves in a situation, not only from a software update. The example is a chatbot that answers simple questions in business hours under staff watch, compared with the same chatbot running all day and night, without human oversight, on harder questions. The getting-started action is a risk screening process that flags uses which are unacceptable or need more governance attention. The National AI Centre points to a risk screening template.

Next steps are risk processes that distinguish traditional IT, narrow AI, general-purpose AI and agentic systems, a risk assessment and mitigation plan for each use and its impacts, controls matched to the level of risk, and a way to investigate, document and learn from AI-related incidents.

This is where an APRA-regulated entity should join the screen to the operational risk profile it already keeps under CPS 230, rather than inventing a second risk language that never reaches the board update. A non-regulated organisation should still put the screened uses where the existing risk register is reviewed. A side spreadsheet that the risk committee never sees is not a control.

Screening is a decision, not a colour on a slide. For each use the screen should say whether the use is refused, allowed with conditions, or allowed and watched. Conditions are concrete: data that must not be entered, a person who reviews the output, a ban on fully automated denial of a claim or a benefit, a ban on the tool in hiring without a human decision, or a requirement to tell the customer they are dealing with a system. The National AI Centre's point about misuse belongs here too. A tool approved for drafting can be misused as a decision-maker. The screen should say the misuse and the control, not only the intended use.

4. Share essential information

The foundations page says people should know when they are interacting with AI and when an AI decision affects them. The example is a customer who should know a chatbot is not a human specialist. Getting started means an AI register and a disclosure habit. The register documents all AI systems, how they are used, and other important information. It includes systems built inside the organisation and systems bought in. It includes AI embedded in other tools, such as human resources systems and customer engagement tools. The National AI Centre points to an AI register template. Disclosure is standard practice where AI makes or influences decisions, generates content that can meaningfully affect people, or can be mistaken for a human.

Next steps are to document and communicate capabilities and limitations so people do not over-rely on the system or misuse it, to be transparent across the supply chain about components, capabilities, limitations and training-data characteristics, and to explain outcomes that affect people in language those people can use. The detail of the explanation should match the seriousness of the outcome.

A board register and an operational AI register can be the same list at two levels of detail. Directors need the use, the owner, the risk, the data class and the review date. Operators need the tool name, the process step, the disclosure line and the override. Training that produces a register directors cannot read, or a register operators cannot update, produces a poster.

Disclosure is a conduct question as well as a technology question. If staff are told to "use the assistant" and customers are not told, the organisation has made a choice. The choice should be written. The OAIC guidance, covered below, makes a related transparency point about privacy policies, notices and public-facing chatbots.

5. Test and monitor

The foundations page says AI systems can change behaviour over time or act in ways that are less predictable than conventional software. The example is a system that answered well last month and answers differently after further training data. Getting started means asking a supplier for proof of testing before purchase, testing against the intended use before deployment, monitoring after deployment in line with the risk assessment, watching for risks that were not present at launch, and extending data governance and cyber security practices to AI systems, including protection of models that learned from sensitive data.

Next steps are stress tests, including attempts to break or bypass safety and policy controls, and independent testing where the use was screened as needing more governance attention. That testing should happen before deployment, after significant changes, and on a regular basis.

CPS 234 already asks APRA-regulated entities for systematic testing, independent specialists, escalation of deficiencies that cannot be fixed in a timely way, and an annual look at whether the testing program is enough. The National AI Centre's test-and-monitor practice is the industry-wide version of a habit those entities should already recognise. The extra AI point is behavioural change after deployment, not only a vulnerability scan at go-live. A monitoring owner who only checks uptime will miss a model that is up and wrong.

Proof from a supplier is a starting document, not a substitute for the organisation's own test on its own use. A vendor evaluation on a public benchmark does not show how the tool behaves on the organisation's claims, credit or member files. The pre-deployment test should use the real task, with the data class the policy allows, and a person who knows the task well enough to see a bad answer.

6. Maintain human control

The foundations page contrasts software that follows explicit instructions with systems that learn patterns and make opaque decisions. It says a person should oversee the system in a way that matches the system's autonomy and the stakes, from automated monitoring on low-stakes uses to mandatory human review on high-stakes decisions. Getting started also means clear points where a person can pause, override, roll back or shut the system down.

Next steps are training for the people who oversee systems, so they know capabilities, limitations, failure points and when to intervene, and alternative pathways so critical functions can continue if the system fails or is retired. That last point rhymes with CPS 230's tolerance and business continuity settings, again without the National AI Centre claiming to restate APRA law.

Human control is a design choice. A button labelled override, which nobody is trained to use and which does not stop the customer email already sent, is not the control the practice describes. The session should write, for the highest-stakes use in the room, the moment a person sees the output, the authority they have to reject it, and the path the work takes when the system is off. If critical operations depend on the system, the off path is a resilience question as well as an ethics question.

Agentic uses, where a system takes a series of actions rather than drafting a single answer, raise the stakes of this practice. The AICD page flags agentic AI as part of the reason for Version 2 of the director guide. The implementation guidance distinguishes agentic systems in its risk processes. A board does not need a definition contest. It needs to know whether any current use can send, pay, deny or change a record without a person in the path, and what the override does.

The six practices and the ten guardrails

The ten guardrails remain on the Department's site. In short, they cover an accountability process, a risk management process, data governance and protection, testing and monitoring, human control, telling end users, a way to challenge outcomes, transparency along the supply chain, records that let a third party assess compliance, and stakeholder engagement with attention to safety, diversity, inclusion and fairness. The Department's guardrails page says the guardrails align with international standards including ISO/IEC 42001

and the US National Institute of Science and Technology AI Risk Management Framework 1.0, which is the wording on that page. The page also carries the 21 October 2025 note about the six practices.

A practical way to hold both documents is to teach the six practices as the agenda a leadership team can finish, and to use the ten guardrails as the checklist when a use is higher risk, when several organisations share the system, or when someone must show records to a customer, a regulator or a board committee. The six practices are not a repeal. The Department describes them as an evolution and a simplification. Training that tells a board the ten guardrails have vanished is out of date. Training that makes a board memorise ten headings and write nothing local is also a failure.

ISO/IEC 42001 is an international management-system standard. Alignment language on a government page is not a certification. A leadership team can borrow the shape, put a policy and roles in place, run them and check them, and still decide separately whether to seek an audit. This guide does not set that decision.

Privacy and the OAIC guidance

The Office of the Australian Information Commissioner published Guidance on privacy and the use of commercially available AI products on 21 October 2024, and updated it on 17 January 2025. The guidance is for organisations deploying AI systems that were built with, or that collect, store, use or disclose, personal information. The OAIC describes a deployer as an individual or organisation that supplies or uses an AI system to provide a product or service, including internal use. The page says the Privacy Act applies to uses of AI that involve personal information. It says the guidance is particularly useful for generative AI and general-purpose tools, and for other uses with a high risk of adverse impacts. It says it does not cover every privacy issue and should be read with the Privacy Act 1988 and the Australian Privacy Principles guidelines.

The OAIC's top takeaways, paraphrased here from that page, are the ones a board session should be able to repeat.

Personal information put into an AI system is still personal information, and so is output that contains personal information. Before adopting a commercial product, the organisation should do due diligence on whether the product fits the intended use, whether it has been tested for that use, how human oversight is built in, what the privacy and security risks are, and who will have access to personal information the organisation inputs or generates.

Privacy policies and notices should tell people about the AI use in clear language. Public-facing tools such as chatbots should be identifiable as such. Policies and procedures for AI use support that transparency.

If an AI system generates or infers personal information, including images, that is a collection and must comply with Australian Privacy Principle 3. Generation of personal information must be reasonably necessary for the entity's functions or activities, and must be done by lawful and fair means. The OAIC says inferred, incorrect or artificially generated information, such as hallucinations and deepfakes, is personal information where it is about an identified or reasonably identifiable individual, and must be handled under the Australian Privacy Principles.

If personal information is input into an AI system, Australian Privacy Principle 6 limits use and disclosure to the primary purpose of collection, unless the individual consents or the entity can establish a permitted secondary use. A secondary use must be what the individual would reasonably expect, and it must be related to the primary purpose, or directly related where the information is sensitive. The OAIC says a secondary use may sit inside reasonable expectations if it was set out in a notice at collection and in the privacy policy. It also says that, given the risks, it may be difficult to establish reasonable expectations for a secondary AI purpose. Where the organisation cannot clearly establish that, the OAIC says that to avoid regulatory risk the organisation should seek consent and offer a meaningful, informed opt-out.

As a matter of best practice, the OAIC recommends that organisations do not enter personal information, and particularly sensitive information, into publicly available generative AI tools, because of the significant and complex privacy risks.

Australian Privacy Principle 10 requires reasonable steps to ensure personal information collected, used and disclosed is accurate. The OAIC notes that AI systems are known to produce inaccurate or false results, and that this risk is especially high with generative AI. Steps might include a human check and a clear statement of the system's limits. The page also says the use of AI for decisions that may have a legal or similarly significant effect on a person's rights is likely to be a high privacy risk activity.

The guidance recommends a privacy-by-design approach, including a privacy impact assessment, and it says due diligence is not a set-and-forget step. Reviews of the product, training of staff and monitoring should continue through the product's life. Sensitive information generally needs consent. Photographs and recordings of people, including artificially generated ones, may contain sensitive information and may not be usable as input or output without consent. Consent is not implied merely because a person was notified.

For a leadership team, the operational translation is a short acceptable-use rule. It names which systems are approved, which data must not be pasted into a public tool, when a person checks an output before it is relied on, and who to ask when a case does not fit the rule. The rule should match the privacy policy and the notices, because the OAIC treats those documents as part of whether a secondary use was reasonably expected. A staff workshop can practise the rule. A board workshop should be able to see that the rule exists and that it is the rule the privacy officer will stand behind.

OAIC guidance is guidance. A real collection still has to be read against the Privacy Act. The training should say that in the room, and the minutes should record the use and the data, not a badge that says OAIC compliance.

AI governance training for leadership teams in Australia

AI governance training for leadership teams in Australia should be a working session on the organisation's own uses, not a tour of the global policy debate. The people in the room are the ones who can change a rule after the session. If they cannot, the session is a briefing and should be labelled as a briefing.

A sound agenda has a stable shape, which this guide has already sourced.

Open with the legal and standards map that applies to this organisation. For every organisation that is a corporation, that map includes section 180 and the business judgment rule's information limb, plus section 181's good faith and proper purpose duties. Where the organisation is APRA-regulated, add the board accountabilities in CPS 230 and CPS 234, the critical operations, the material service providers and the notification clocks. Where personal information is in play, add the OAIC points on collection, use, accuracy and public tools. Where the organisation wants a plain industry agenda, use the six National AI Centre practices. Say out loud which items do not apply, so a private company is not drilled as if it notifies APRA.

Then put the live uses on the table. Include the uses nobody has approved. The National AI Centre's register expectation covers embedded AI in human resources and customer tools, not only the tools with an AI budget line. For each use, write the purpose, the data, the people affected, the owner, the risk screen and the human check.

Then draft the artefacts in the section below, at least in first form. A leadership team that leaves with a promise to "take the templates offline" has repeated the pattern the training was meant to break. The National AI Centre publishes templates for a policy, a register and risk screening. They are a start. The organisation's names and uses have to be written on them before they count.

Close with the board rhythm. What will directors see, how often, and what question they will ask if the register has not moved. CPS 230 already requires regular updates on the operational risk profile for APRA-regulated entities, and senior management information when a decision could affect critical operations. Other boards can copy the rhythm without copying the statute: a short report, exceptions that need a decision, and a date.

Leadership training should also settle the split between the executive session and the staff session. Executives write the rules and the owners. Staff need a separate practice on how to apply the rules to the work in front of them, including what must stay out of a public tool and when an output is not ready to send. Collective Campus runs those as different programs, linked at the end of this guide. Putting everyone in one undifferentiated room tends to produce a policy the board has not approved and a prompt exercise the executives did not need.

An AI governance workshop for executives in Sydney

An AI governance workshop for executives in Sydney covers the same ground as a session in any other Australian city. There is no Sydney edition of section 180, of CPS 230, of CPS 234, of the Privacy Act or of the National AI Centre's six practices. Executives based in Sydney still need the session to start from their licence, their customers and their uses. A Sydney bank executive and a Sydney hospital executive are not in the same regulatory conversation, even though they can share a city and a vendor.

What a Sydney session often has to handle, because of the mix of head offices and national functions in that city, is a group that sets rules for people in other cities and for suppliers offshore. The accountability practice asks for supply-chain clarity. CPS 230 asks an APRA-regulated entity to look at fourth parties and at geographic concentration. The OAIC asks who will have access to personal information. A workshop that treats "Sydney" as the whole operating picture will write a policy that does not survive contact with a processing team in another place. The register should name the process and the location of the data handling, not only the city where the executives sat.

Collective Campus does not need a separate product for one city to do this. The board and executive program is the place to write the policy, the rules, the owners and the framework. The staff workshop is the place to practise the rules with the people who use the tools. Both can be run with a Sydney leadership team in the room or remotely. The test of the session is the page of decisions, not the postcode on the calendar invite.

What good board and executive training covers

Good training covers the decisions directors and executives are accountable for, in the language of the sources above, applied to uses the organisation can name. It does not try to make directors into model engineers. It does not try to make the risk team into a substitute for the business owner.

A session that earns its place will usually cover all of the following, scaled to the organisation.

The duty map. Directors and officers can explain section 180(1), the four limbs of the business judgment rule that are relevant to how they inform themselves, and the good faith and proper purpose duties in section 181, without pretending the session is a legal opinion. They can say what information they expect in a paper before they approve a use.

The standards map, where it applies. An APRA-regulated entity's executives can say what CPS 230 asks the board to approve and oversee, which operations are critical, whether any AI service sits under those operations, which providers are material, and how the 72-hour and 24-hour notifications are owned. They can say how information assets used by an AI tool are classified under CPS 234, including assets a third party manages, and how the 72-hour incident clock and the 10-business-day control-weakness clock start.

The six practices, as an agenda rather than a poster. For each practice the room can say what getting started requires and what the next step is if the use grows. The practices are decide who is accountable, understand impacts and plan accordingly, measure and manage risks, share essential information, test and monitor, and maintain human control.

The privacy rule. The room can say whether personal information is in the use, what Australian Privacy Principles 3, 6 and 10 require in the OAIC's account, why a public generative tool is a poor place for personal information and a worse place for sensitive information, and how the privacy policy and notices will be changed if the use is new.

The misuse case. For at least one approved tool, the room names a way the tool could be used beyond the intended task, and the control that catches that misuse. The National AI Centre tells organisations to check how tools could be misused. A session that only documents the happy path has skipped that instruction.

The human control on the highest-stakes use. The room writes who reviews, what they can stop, and how the work continues if the system is shut off. If that use supports a critical operation, the off switch is discussed with the tolerance levels, not as a slogan about keeping humans in the loop.

The board report. The room drafts the one-page view directors will see next time: uses, owners, material risks, incidents, and decisions required. CPS 230's call for regular updates is the model for regulated entities. Others can adopt the same page because a board cannot oversee a register it never receives.

What the training can leave out is a catalogue of model names, a history of the technology, and a debate about whether AI is good for the economy. Those topics have public homes. They do not decide the use in front of this board. The training can also leave out any claim that a template, a standard or a course certifies the organisation. The National AI Centre's templates are drafts until the organisation's names are on them. ISO/IEC 42001 alignment language on a government page is not a certificate. APRA standards are obligations for regulated entities, not a logo for the slide.

What the training should leave behind

The artefacts are the point. A leadership team should be able to find them the next morning without asking the facilitator. The list below is the practical reading of the National AI Centre's getting-started actions, the OAIC's call for policies and procedures, and, where they apply, the board papers CPS 230 and CPS 234 already expect.

An AI policy. The foundations page asks for a policy that sets out responsible use and gives staff advice on risks and how to manage them. The policy can be short. It should say who the overall owner is, which uses need approval, and where the register lives.

Acceptable use rules. These are the policy in the language of a task. They say which tools are approved, what must not be entered into a public tool, what must be checked by a person before it is sent or relied on, and who to ask when the rule does not fit. They should be consistent with the privacy policy. The OAIC's best-practice line on personal information and public generative tools belongs in the rule, not in an appendix nobody opens.

Named owners. One senior leader owns AI governance across the organisation, with authority to oversee all use. Each system has a named person who is accountable for that system and who understands it well enough to decide. Supply-chain responsibilities are written down where a vendor builds or runs part of the system. A committee can advise. A committee is not a name.

A governance framework. The foundations page treats the framework as the next step after a policy: policies and procedures the organisation will run, review and improve. For a smaller organisation the framework may be the policy, the register and a review date. For a larger one it should say how this work meets the risk management framework, internal audit and the board report that already exist. A second bureaucracy with its own unused portal is a way to lose the work.

A register of uses and risks. The National AI Centre asks for an AI register of systems, uses and other important information, including embedded tools, and for a risk screening process that flags unacceptable uses and uses that need more attention. Those can live as one register or as the AI slice of the enterprise risk register, as long as the risk committee or the board actually sees them. Each line should carry the purpose, the owner, the data class, the impact, the screen outcome, the control, the review date and, where relevant, the critical operation or information asset it touches.

A stakeholder impact note and a contestability path, at least for uses that affect people in a serious way. The note says who is affected and what harm looks like. The path says how a person challenges an outcome and who can correct it. Hiring, credit, claims, benefits, grading and access to essential services are the uses to do first.

A testing and monitoring note for any use that will run on real customers, members or staff. It records what proof was asked of the supplier, what the organisation tested on its own task before go-live, who watches behaviour after go-live, and what incident process applies. APRA-regulated entities should be able to connect that note to CPS 234 testing and to CPS 230 incident notification where the thresholds are met.

A human-control note for the highest-stakes use, and an off path if a critical function depends on the system. The note names the override, the person, and the fallback.

A board or executive review date, with the report template attached. The first review asks whether the policy is findable, whether new tools appeared without a line on the register, and whether any incident was escalated the way the clocks require.

If a session ends without those artefacts, it has not finished. The templates from the National AI Centre are there so the first draft is not a blank page. The organisation still has to write its own names. Collective Campus runs this as a working program for boards, executives and risk teams so the drafts are made in the room with the people who can own them, and as a staff workshop so the acceptable use rules are practised on real tasks rather than left as a PDF.

Running the work with Collective Campus

Collective Campus has been running capability building programs for organisations across the globe since 2015. AI governance sits alongside design thinking, customer experience, agile, lean startup, productivity, psychological safety and critical thinking. Teams still need judgment, customer understanding and a way to test an idea. Governance sets which AI uses are allowed while they do that work.

Boards, executive teams and risk teams can run the work through AI Governance for Boards, Executives and Risk. That program is built to leave a policy, acceptable use rules, named owners and a governance framework. Staff and teams who need to practise everyday use, including what can go into a tool and when to check an output, can run the AI governance workshop for staff. The leadership session writes the rules. The staff session is how those rules meet the work.

A sensible order is to settle the owners and the rules with the people who can approve them, then practise the rules with the people who use the tools. Reversing the order produces confident staff habits that the board has not authorised, or a policy the staff have never tried. Either way the register lies.

Bring the uses you already know about, including the ones nobody has approved. Bring the privacy officer, the person who owns operational risk where CPS 230 applies, and the executive who will be the named owner. Leave with the policy started, the register started, and a date the board will see both.

Sources

The claims in this guide are drawn from the public pages below. Laws, standards and guidance pages are amended. Use the live page when a board paper needs the current text.

• Corporations Act 2001 (Cth), section 180, Federal Register of Legislation
• APRA Prudential Standard CPS 230 Operational Risk Management
• APRA news, 1 July 2025, CPS 230 comes into force
• APRA, Operational risk management consultation page, including the 30 April 2026 amendments
• APRA Prudential Standard CPS 234 Information Security
• Department of Industry, Science and Resources, Voluntary AI Safety Standard
• Department of Industry, Science and Resources, The 10 guardrails
• Department of Industry, Science and Resources, National AI Plan, Spread the benefits
• National AI Centre, Guidance for AI adoption: foundations
• National AI Centre, Guidance for AI adoption: implementation guidance
• Australian Institute of Company Directors, A Director's Guide to AI Governance Version 2
• Office of the Australian Information Commissioner, Guidance on privacy and the use of commercially available AI products