Accountability now attaches to the task, not only the organisation.
That is the design of version 2.0 of the Digital Transformation Agency's Policy for the responsible use of AI in government. The page states that "This version of the policy (v2.0) is effective 15 December 2025. The first version (v1.1) took effect on 1 September 2024." Its mandatory requirements include AI use case accountability, an internal AI use case register and an AI use case impact assessment. That is the position as at 26 September 2026.
The practitioner consequence is narrower than the word governance suggests. Accountability is no longer declared only once for the organisation. It is also set per task, recorded in a register, and carried with a review date attached. A team of eight cannot run an agency governance apparatus. It copies the one mechanism that carries the weight: one page, one row per assisted task, a named owner by role, the standard that row is held to, its next review date, and a standing quarterly agenda item that walks the rows that fell due and the rows that moved.
What the Commonwealth policy actually requires
Three requirements matter here, and each is narrower than it sounds.
The first is the owner. The policy's strategy and oversight page states that "Agencies must designate an accountable use case owner for each in-scope AI use case within 12 months of this policy taking effect." Each use case. Not each agency, not each tool, not each division.
The second is the container. The same page states that "Agencies must create a register of in-scope AI use cases to enable accountable official(s) to record accountable use case owners within 12 months of this policy taking effect." It also travels, because agencies must share it with the Digital Transformation Agency every 6 months from creation, and an agency may reuse a register it already keeps rather than starting a fresh one.
The third is the unit. The policy appendices define an AI use case as "a specific application of an AI system or systems to achieve certain objectives or perform certain tasks". A register built on that definition is not a list of software. It is a list of things being done.
The field list sits in the Standard for accountability 2.0, page last updated 2 December 2025. At a minimum an agency records the use case name, an agency identifier, a description, the AI technology type, the lifecycle stage, use of the technical standard, the domain, the usage pattern, the accountable use case owner by name and email address, the in-scope criteria met, inherent and residual risk ratings, and the date the impact assessment was last updated. Inherent high-risk use cases carry two further fields: the last date of review and the date for next review. The standard says agencies should keep the register "up to date via periodic review", and notes that accountability can be split between business and technology roles.
Review is not only a calendar event. The AI use case impact assessment page requires agencies to "re-validate the AI use case impact assessment by checking its accuracy and updating it when there is a material change in the use case scope, usage or operation". The same page says agencies should also monitor changes they did not initiate, vendor changes among them. For inherent high-risk use cases, agencies establish a system to review the use case "every 12 months at a minimum". For existing use cases not yet assessed, agencies must decide whether they are in scope and apply all relevant policy actions by 30 April 2027, a date stated on that page and current as at 26 September 2026.
Two clocks, then. One runs on dates, the other on change.
Does any of this bind a team of eight?
No, and claiming otherwise is a quick way to lose the room.
The policy applies to non-corporate Commonwealth entities, with some exceptions. The Digital Transformation Agency's list of Australian Government AI transparency statements, page last updated 23 June 2026, separates the mandatory statements published by non-corporate Commonwealth entities from the voluntary statements published by corporate Commonwealth entities, the defence portfolio and the national intelligence community. More than 90 mandatory statements and more than 20 voluntary statements are listed there. A private team sits in neither.
What reaches a private team is the same idea, offered rather than imposed, although the Centre pitches it at the system rather than the task. The National Artificial Intelligence Centre's Guidance for AI adoption: foundations, published 5 May 2026, carries a practice called Decide who is accountable. Its first getting started action is to "Assign a senior leader as the overall AI governance owner", and its next steps ask organisations to "Make a specific person accountable for every AI system your organisation uses." A later practice asks organisations to create and maintain an AI register covering AI embedded in other systems.
The matching artefact is already published. The Centre's AI systems register page, carrying Word and Excel templates published 22 April 2026, defines the register as "a table or database that lists all the AI systems your organisation uses". It adds the line most teams get wrong: "The register should capture all AI systems, including AI features embedded in common software packages."
So the obligation is not borrowed. The mechanism is.
The register, one row per assisted task
Here is the page. Nine columns. A tenth is where a one page register starts becoming a project.
Three rows show the shape. Replace every bracketed token; everything else is an example to overwrite. After the first build, item three of the quarterly agenda adds the rows.
The columns are a deliberate reduction of the minimum fields in the Standard for accountability. The agency, technology and risk rating fields are dropped, because they answer questions a small team is not being asked.
The use case register that gives a board evidence is built to be read cold by an audit committee. This one is built to be kept by a team of eight, which means it survives only if it fits on a page and has an owner in every row.
What each column is actually for
Task is the unit, not the tool, because the policy defines the use case that way. Two people using the same assistant for two different jobs are two rows.
What the assistant does is written in verbs, not in capability language, so a reader who has never seen the tool can tell what arrives on the page.
Tool is recorded because vendors change what a tool does without asking. The impact assessment page says agencies should also monitor changes they did not initiate, vendor changes among them, and this column is where such a change lands.
Owner, by role, is the column the register exists for. Record a role, not a person, because a role title outlives a resignation. Safe Work Australia's AI transparency statement, page last updated 29 April 2026, does that, appointing its Chief Information Officer as AI Accountable Official and its Chief Operating Officer as Chief AI Officer. The Commonwealth register records the use case owner by name and email address, so recording a role is this design's own departure.
Test met records why the row is listed. The policy appendices set in-scope tests of which any one is enough, including that "The use of AI will materially influence administrative decisions that affect individuals, communities, organisations, the environment or the collective rights of cultural groups including First Nations peoples." A team of eight is not making administrative decisions under statute, so the scaled test is this article's design rather than the policy's.
Review standard is what working means for that row, stated in a sentence somebody could fail. Not accurate, not appropriate, but something closer to every figure traced to the attached source before the section is sent.
Evidence kept names the artefact that proves the standard was applied. Usually the prompt, the draft and the version that went out.
Last reviewed and next review are the two fields the Standard for accountability adds for inherent high-risk use cases. A small team carries them on every row, because the register only has value if somebody is due to read it.
The standing quarterly agenda
A review date with nowhere to land is a date that passes. One recurring agenda item, fifteen minutes, five questions in this order:
- Which rows have a next review date on or before today, and what did the owner find when they looked?
- Which rows changed this quarter in task, in usage or in tool, including changes nobody on the team initiated?
- Which tasks started being assisted this quarter and are not yet on the register?
- What incident or near miss was raised, and which row does it touch?
- Which owner roles changed, became vacant, or moved with the work?
Item two mirrors the material change trigger from the impact assessment page. Item four needs a reporting pathway, and the policy's preparedness and operations page supplies it: agencies provide "a pathway for staff to report AI safety concerns, including AI incidents." The same page states the principle underneath every row, that "APS officers need to be able to explain, justify and take ownership of advice and decisions when using AI."
Item five is the one that quietly breaks registers: owners leave, work moves, and a row with a vacant owner is a row nobody is reading.
Three prompts that build the register and keep it
TheAICommand works to the Verified Draft Method: de-identify the inputs, ground the model in your own source material, keep a person at the decision point, verify against the primary source, and log what happened.
The worked example is a leader of [TEAM] with three things in hand: a list of the tasks the team performs, a short note of which of those tasks an assistant is already used on, and a one line list of the roles in [TEAM].
What to check: every proposed owner has to be the role that already answers for the unassisted version of that task, not the most senior role on the list. Where two rows land on the same role, ask whether that role can carry both. Then read the source line column against the attachments and confirm no row was invented. Finally, check that the test named in column four is one the leader can point to, rather than a conclusion the model reached and then labelled.
What to check: the output has to name the test rather than assert an outcome, and the quoted words have to be in the description that was supplied. Confirm also that no risk rating appeared, because a rating the leader did not supply will be repeated later as though somebody assessed it.
What to check: every date in the output, against the register, one by one. A date is the one thing here the model cannot verify and has every reason to tidy. After the dates, read list three, because a task the note mentions and the register does not is the finding the quarterly review exists to produce.
What stays internal, and what is said publicly?
These are two different documents, and conflating them is a real error.
The Standard for AI transparency statements, page last updated 1 December 2025, states that "Agencies are not required to list individual use cases or provide use case level detail." The register must go to the Digital Transformation Agency every 6 months from creation. The public statement is a high level account, reviewed annually.
A published statement shows what that looks like from an organisation the policy does not compel. Comcare's AI transparency statement, published February 2025 and reviewed April 2026, records that AI is not used in its compliance, auditing or decision-making processes without human oversight, and that "This approach ensures that there is always a human responsible for accountability and accuracy in service delivery." It names who is answerable.
For a private team, the register is internal. Anything said outside the team describes the approach and names the roles, not the rows.
Where does this design get thin?
The register is documentation, not assurance. The National Artificial Intelligence Centre says so directly on its register page, warning that a register is about transparency and documentation and should not replace more in-depth governance activities such as impact assessments and risk management. A row with a thin review standard is a row where the thinking has not been done, and the register will not tell anyone that. The column simply looks filled.
The scaled tests are this article's design, not a legal threshold. The policy's in-scope criteria are written for administrative decision making inside Commonwealth entities. The three tests offered above keep the same shape and no statutory force. A team whose work is regulated in its own right checks its own obligations rather than substituting a register for them.
A general purpose assistant resists the one row per task rule, and the policy anticipates that. The appendices give agencies a choice for a general purpose solution: treat it as a single complex use case at the highest applicable risk level, or treat each use case separately, with its own accountable use case owner and its own register entry. The second option matches this design, and it costs more rows.
The register records who is answerable; it does not put a person in the loop. The foundations guidance carries that in a getting started action, building in human override points, and the preparedness and operations page carries mandatory training for all staff on responsible AI use within 12 months. A name in a column is the start of the control, not the control.
Do this Monday
The artefact is a one page AI use register for [TEAM], with one row per assisted task and no empty owner cell.
The owner of the register is the team leader, because the register records who answers for an output and the leader already answers for the work.
The first step is an hour of your own work, in two sittings. On Monday, send one line to the team, asking each person to reply by Wednesday with the tasks they already use an assistant on and what it does on each. On Wednesday, paste the replies under the list of tasks the team performs, add a one line list of the roles in [TEAM], and run the first prompt. Then fill the five columns the model was not asked for: the tool, the review standard, the evidence kept, the last reviewed date, which on a new register is the build date, and the next review date, which is the next quarterly meeting. Build it in one sheet in the team's shared drive. The National Artificial Intelligence Centre's Excel template, linked above, is built on rows for AI systems rather than tasks and carries no review standard, evidence, last reviewed or next review column, so those four are added by hand. Finish by putting a fifteen minute quarterly item in the calendar with the five agenda questions and a link to the register in the invitation, and a week before each meeting send the owners of the rows falling due the question they answer in the room: did the review standard hold on every use since the last review, and what is the evidence.
The check that proves it worked has two parts. First, every row has a role in the owner column, a named tool, a named evidence artefact, and a sentence in the review standard column that somebody could fail. Second, the next review date on every row has a meeting that it lands in.
The bottom line
Version 2.0 of the Commonwealth policy sets a named owner per use case alongside the agency accountable official it also requires, held in a register with a review date, effective 15 December 2025 and current as at 26 September 2026. A team of eight is not bound by that policy, and the National Artificial Intelligence Centre asks voluntarily for a named accountable person against every AI system. The scaled version is one page, nine columns, one row per assisted task, then a standing quarterly item, because a review date with nowhere to land is not a control. Build the page first. Name the owners second.
TheAICommand. Intelligence, At Your Command.
