Many government AI pilots still treat governance as a late-stage paperwork exercise: build the prototype, then write the risk note when someone asks for approval. Under the current Australian Government policy settings, that sequence is backwards.
Version 2.0 of the Policy for the responsible use of AI in government is explicit. For in-scope use cases, agencies must start an AI impact assessment at design time, finalise it before deployment, and apply agreed risk treatments before the solution goes live. The assessment is not a ceremonial attachment after a successful demo. It is a release condition.
That changes the delivery job. Product owners, architects, GovCMS editors and engineers need a practical way to produce assessment evidence from the same artefacts they already use to ship software: requirements, data maps, evaluation results, access controls, monitoring plans and decision records.
What the Policy Actually Requires
The Digital Transformation Agency's policy update strengthens whole-of-government AI governance. Agencies must designate accountability, maintain transparency statements, operationalise responsible-use practices, keep an internal register of in-scope use cases, and complete use-case impact assessments.
For impact assessment specifically, the mandatory pattern is clear:
- assess every new AI use case against the policy's in-scope criteria during design, while requirements are still being formed;
- for in-scope use cases, conduct an AI use case impact assessment using the Australian Government tool or an internal process that integrates all of its provisions and produces at least the same risk outcome;
- finalise the assessment and apply agreed treatments before deployment;
- add the use case to the internal register, including risk ratings and the accountable use case owner;
- monitor and evaluate the live use case, and re-validate the assessment when scope, usage or operation changes materially.
High inherent-risk use cases attract additional obligations: report to the agency accountable official, govern through a designated board or senior executive, notify the DTA once deployment is decided, and review at least every 12 months.
The accompanying AI impact assessment tool guidance makes the operating model concrete. Each assessment needs an assessing officer and an approving officer. The first four sections form a threshold assessment of inherent risk. If every inherent risk is low, the assessment can conclude there with monitoring and re-validation plans. If any inherent risk is medium or high, the team completes the full assessment. The accountable use case owner is a separate role under the Standard for accountability, even if the same person also assesses or approves.
Why Delivery Teams Get This Wrong
Impact assessment fails when it is treated as a governance product instead of a design product. Common failure modes include:
- Assessment after architecture is frozen. By then, data flows, model choices, human-oversight points and logging designs are expensive to change.
- One generic form for every use case. A content-drafting assistant, a retrieval service over policy material and a decision-support model that affects people are not the same risk shape.
- Owner without authority. Naming a junior project officer as accountable owner without escalation paths leaves high-risk findings orphaned.
- No link to release evidence. The assessment says monitoring is required, but production has no metrics, alerts, rollback path or re-validation trigger.
- Register as a static spreadsheet. Lifecycle stage, residual risk and last assessment date drift while the live system keeps changing.
The point of the policy is proportionate control, not theatre. A low-risk internal drafting aid should not consume the same ceremony as a high-risk public-facing decision support service. But both need a documented design-time decision, an owner and a path to re-check when the system changes.
Turn the Assessment Into Release Evidence
Delivery teams already produce most of the material the assessment needs. The missing step is to make that material first-class and reviewable before go-live.
Map the assessment questions to engineering artefacts:
- People and impacts: user research, accessibility findings, affected cohorts, reversibility of outcomes, complaint and correction paths.
- Data: source inventory, classification, retention, permission boundaries, vendor processing locations and evaluation datasets. This pairs naturally with the discipline in our article on treating the data pipeline as part of the system.
- Human oversight: where a person must approve, override or reject an AI recommendation, and how that decision is recorded.
- Security and monitoring: identity, least privilege, logging of prompts/tool calls/outputs where appropriate, incident routes and fallback behaviour when the AI path is unavailable.
- Transparency: what staff and the public are told about AI involvement, and how the agency-level AI transparency statement remains accurate without listing every use case.
- Change control: the definition of a material change that forces re-validation — new data sources, new tools, new user populations, model swaps, removed human checks or vendor behaviour changes.
A practical release package can then answer four questions in one place:
- Is this use case in scope, and who owns it?
- What inherent and residual risks were accepted, by whom?
- Which controls and tests prove those treatments exist in the built system?
- What monitoring and re-validation triggers keep the assessment true after launch?
That package should sit beside the deployment checklist, not in a separate governance folder that nobody opens at release time.
A Threshold-First Workflow for Product Teams
Use the tool's threshold structure as an engineering workflow, not only a Word template.
1. Scope gate during discovery. Document whether the proposed use meets the policy's in-scope criteria. If it is out of scope, record why, keep privacy and security obligations in view, and define the material-change conditions that would bring it into scope later.
2. Draft the threshold assessment while requirements are still open. Capture intended users, data classes, autonomy level, human review points and failure modes before selecting vendors or freezing architecture.
3. Let medium or high inherent risk change the design. Do not treat a medium/high finding as a reason to write a longer justification for the original plan. Change permissions, add human approval, narrow the population, reduce data, isolate tools or drop the use case.
4. Finalise before production traffic. Complete the assessment, record the approving officer decision, update the internal register and attach the residual-risk treatments to the release.
5. Operate the assessment. Monitor the live service against the assumptions in the assessment. Re-validate when the system changes materially, and for high-risk use cases run the required annual review to the designated board or senior executive.
This is compatible with the stage-gate thinking in moving AI from proof of concept to production. A pilot should test the real assessment assumptions under controlled conditions. Production should prove the controls still hold under real load, real data drift and real support ownership.
What This Means for GovCMS and Drupal Teams
The Australian Government Architecture Web Content Management Standard requires entities to comply with the responsible-use AI policy wherever AI is involved in content management. That includes generation, summarisation, chat navigation aids and editorial copilots connected to a CMS.
For GovCMS and Drupal programmes, impact assessment should therefore cover the whole publishing path:
- whether AI drafts enter the CMS as suggestions only, or can publish without a human editor;
- how source attribution, accessibility checks, style and factual review are enforced before publish;
- whether personal information, case material or OFFICIAL content can reach a model or prompt log;
- how unpublished, embargoed or corrected content is kept out of any AI retrieval index;
- what users are told when AI assisted the page they are reading or the answer they received.
A GovCMS workflow can encode part of the control set: role-based publish rights, mandatory review states, audit logs and separation between generation and publication authority. The assessment still needs an owner who can explain residual risk when those workflow controls are bypassed, weakened or extended by a new connector.
Connect Assessment to Broader AI Controls
Impact assessment does not replace technical security design. It is the place where technical controls become accountable decisions.
If the use case is agentic — able to call tools, change records or trigger workflows — pair the assessment with stronger runtime controls. Our guide to governing agentic AI in government software delivery covers action boundaries, approval gates and auditability. The assessment should name those controls as treatments and require evidence that they exist in the deployed configuration, not only in a design slide.
Likewise, managed access to public generative-AI tools and data-pipeline controls remain relevant subordinate designs. The impact assessment is the umbrella decision that says whether a given use case is acceptable, under which residual risk, and with which monitoring burden.
A Four-Week Implementation Sprint
- Week 1 — inventory and owners. List candidate AI use cases, map them against in-scope criteria, assign accountable use case owners and stand up the minimum register fields required by the accountability standard.
- Week 2 — threshold assessments for the top active use cases. Complete sections 1 to 4 while design is still mutable. Escalate any medium or high inherent risks immediately.
- Week 3 — bind treatments to delivery. Convert accepted treatments into backlog items, tests, workflow states, logging requirements and operational runbooks. No treatment remains only a paragraph in the assessment.
- Week 4 — release and re-validation rehearsal. Finalise one pre-production assessment end to end, update the register, run the monitoring checks, and rehearse a material-change re-validation such as a model swap or new data source.
At the end of the sprint the agency should know which use cases can proceed, which are blocked on design changes, and which controls must appear in every future AI release package.
Working with NAITEC Digital
NAITEC Digital helps Australian Government teams turn responsible-AI policy into delivery practice. We can map in-scope use cases, stand up workable registers and ownership models, facilitate impact assessments against the Australian Government tool, and bind residual-risk treatments into architecture, GovCMS/Drupal workflows, evaluation, monitoring and release evidence.
We are a Newcastle, NSW software consultancy, a BuyICT registered supplier, and GovCMS/Drupal specialists on the Drupal Services Panel. Our capabilities span AI integration, automation and custom software delivery and government digital services, GovCMS and Drupal.
If your AI work can demo well but cannot yet show a completed impact assessment, accountable owner and re-validation path, talk to NAITEC Digital. We can help make the assessment a real release gate rather than a late form.
Frequently Asked Questions
Is an AI impact assessment mandatory before deployment?
For AI use cases in scope of the Policy for the responsible use of AI in government, yes. Agencies must commence the assessment at design stage and finalise it, with agreed risk treatments applied, before deployment.
Do agencies have to use the DTA Word tool exactly?
They may use the Australian Government AI impact assessment tool or an internal process that integrates all of its provisions and produces the same or a higher risk outcome for inherent and residual risk. The internal process must remain revisable when the tool is updated.
What is the difference between an accountable official and an accountable use case owner?
The accountable official is responsible for agency-level policy implementation and whole-of-government contact points. The accountable use case owner is responsible for a specific in-scope use case, including assessment, monitoring, re-validation and high-risk actions.
When must an assessment be re-done?
Re-validate when there is a material change in scope, usage or operation. High inherent-risk use cases also require review at least every 12 months after the decision to deploy. Vendor and regulatory changes can also force a fresh look.
Does AI-assisted website content need an assessment?
If AI is involved in content management, the Web Content Management Standard requires compliance with the responsible-use AI policy. Teams should assess whether the specific use case is in scope and complete the required actions before relying on AI in the publishing path.
Can NAITEC Digital help operationalise impact assessments?
Yes. NAITEC Digital can help inventory use cases, complete and evidence assessments, design residual-risk controls in software and CMS workflows, and establish monitoring and re-validation practices. Contact us to discuss the work.