A workshop for directors and the executives beside them has a practical test. The following week, someone can point to who decides, what risk the organisation will carry, which systems are already in use, how a new use gets a yes, and what happens when a system causes harm. Those five pages are the test, and a day that does not produce them has left the organisation where it started.
The Australian Department of Industry, Science and Resources sets out the substance of those pages in its voluntary AI safety standard. The ten guardrails are voluntary. On 21 October 2025 the same department published Guidance for AI Adoption, six essential practices which it describes as an update that evolves the standard. The guardrails page remains the detailed list, and it says the guardrails align with ISO/IEC 42001 and the NIST AI Risk Management Framework. A board can treat that list as the checklist for what the room has to finish.
Decision rights
Guardrail 1 asks the organisation to establish, implement and publish an accountability process, including an overall owner for AI use. The standard is plain about where that duty sits. Leaders cannot delegate or outsource accountability for the safe and responsible deployment and use of AI. The organisation has to assign accountability and authority to named roles, communicate those roles, and document the responsibilities. Training sits in the same guardrail, because an owner who cannot explain the risk is only a name on a chart.
In the room, turn that into one page built from decisions you will actually face this year. A tool a function wants to adopt. A pilot that can write to a customer. A model already sitting inside software you bought for another job. A change of vendor. A use that touches employees, such as screening or scheduling. For each one, write who recommends, who approves, who is told, and what the board expects to see. Put the executive who runs the system on the page, and the committee that already hears operational risk. A committee created for a single slide will have nobody assigned to call it. The names should belong to people who were in the room, or to people who report to them and can be asked this month.
Directors and executives do not leave with the same copy of that page. Directors leave knowing which decisions reach them, which stay with management, and which committee will hear the exceptions. Executives leave with the names they will use on Monday, including the person who can say no to a pilot that is already talking to customers. If the two groups write their notes in separate sessions and never compare them, you will have two packs and no line between them. Do the comparison before anyone stands up.
Risk limits the board can repeat
Guardrail 2 asks for a risk management process that follows how the system is used. Assessments have to align with the organisation's risk appetite and tolerance, and they have to be repeated through the life of the system. The standard asks you to set an organisational risk tolerance for AI, and to write criteria for risks you will accept and risks you will refuse, based on that tolerance and on the harm a use could do to people. A clause in the accountability guardrail adds the missing operational piece: document and communicate the consequences when someone acts outside the appetite and the policies that go with it.
Write the appetite in three bands, in words a director can say without a slide: internal drafting on material that is not sensitive; work that reaches a customer, an employee, or a decision a regulator would recognise; and anything that spends money, changes a record, or sends a message in the organisation's name. For each band, write what is allowed on a normal day, what needs a recorded yes, and what is refused. If the risk committee already has language for operational risk, use that language so the page can sit inside a paper the committee already receives. A fresh scale that ignores the risk system you run will stay in the workshop folder.
Bring one live example into each band before you argue about the wording. A summary of public material. A draft that includes a customer's name. A tool that can file, pay, or reply. The room will discover that people do not share a picture of "low risk" until they have looked at the same file. Write the consequence beside the band as well, covering what happens to the person and to the use when the line is crossed, so the limit has a result the organisation has already agreed.
The inventory of systems
Guardrail 9 asks for an organisation-wide inventory of each AI system you use and deploy, with consistent documentation. The fields are specific. The people accountable. The purpose and the business goals. The capabilities and the limitations. The datasets used to train and test the system. The risks, the impacts and the controls. The dates of review. An inventory that cannot answer those fields is a list of product names, and a board cannot oversee a list of product names.
Fill the first rows during the day, from systems you already run. Include the enterprise tools everyone can name, the features inside software you bought for finance, HR or operations, and the pilots that can already take an action. Ten honest rows, with gaps marked, are more useful than a blank template and a plan to survey the building later. Every empty cell needs a person and a date. Executives own the hunt. Directors should see the date on which the missing rows come back, and they should expect the same fields, so the second pack is comparable with the first.
How a use gets a yes, and how you respond
Guardrail 4 says you test a system before deployment and monitor it afterwards. Authorisation to deploy has to come from the person accountable for that system. Guardrail 5 says that person needs the authority to intervene through the life of the system, including where a supplier built the components. The standard also asks for a process for raising issues, faults and incidents, and for response processes when monitoring finds a problem in a system that is already in production. Those clauses are the approval path and the incident path, written as obligations. The workshop has to turn them into a page your people will actually follow.
The approval path is short enough to fit on one sheet. A use arrives with an owner, the risk band from the appetite page is chosen, and a row is opened or updated on the inventory. The accountable person records a yes, a no, or a yes with a limit, and the record lives where the next requester can find it without asking around. Say what "find it" means in your building: a register, a ticket queue, a paper to a named committee. A message in a chat will not answer an auditor, a customer, or your own board six months later.
The incident path is the same length, and it should be written by the people who would have to walk it: who is told and how quickly, who can pause the system, what the person affected is told and by whom, and what management reports to the board, including the cases that do not wait for the next scheduled paper. Practise the path once before you leave, on a failure that could come from a row you just added, such as a wrong letter to a customer, a shortlist that keeps returning the same kind of candidate, or a tool that has started sending in the organisation's name. A path written for people who are not in the room gets rewritten on the day, usually by whoever happens to be online.
What each group carries out
Collective Campus builds high-performance teams for the AI world. The AI governance workshop is where directors and executives draft these pages against their own systems, with the guardrails as the checklist and your risk language as the wording. The questions to ask before you hire someone to run that day are in how a board chooses an AI governance workshop. The questions a product or operations team needs before a system is allowed to act are in AI governance for non-lawyers. The board and executive session sits above both. It is finished when the five pages have names on them and the two groups have read each other's version.
Directors should be able to leave with the appetite, the list of decisions that reach the board, the date the inventory will be complete enough to oversee, and the threshold of incident that comes to them outside the normal cycle. Executives should be able to leave with owners, the first inventory rows, the approval path they will run next week, and the names on the incident path. A shared summary of the ten guardrails, with the names still blank, means the briefing has already happened and the working session has not.
Before you lock the date
- Which decisions will this board and this executive team actually face this year?
- What risk language does the organisation already use, and which committee hears it?
- Which systems are in use today, including features inside products you bought for another job?
- Who can authorise a deployment, and who can pause a system that is already live?
- Which executive will bring the pages back, and on what date will the board see them?
Send the inventory you have, even if it is a rough spreadsheet, and the name of the executive who can assign owners. We will shape the workshop around those rows. The guardrails tell you which fields the pages need. Your systems, your committees and your people supply the words.
