The DTA policy for responsible use of AI in government: what agencies and suppliers must do

What is the DTA AI policy?

The Policy for the responsible use of AI in government is the Digital Transformation Agency’s mandatory framework for how federal agencies adopt and govern AI. All non-corporate Commonwealth entities, as defined by the Public Governance, Performance and Accountability Act 2013, must apply it. Corporate Commonwealth entities are encouraged to.

Version 2.0 took effect on 15 December 2025 and replaced version 1.1, which had applied since 1 September 2024. The December 2025 update added requirements for a strategic approach to AI, an approach to operationalise responsible use, designated accountability for each AI use case, and risk-based actions at use case level.

The policy doesn’t apply to the defence portfolio or the national intelligence community, which may adopt parts of it voluntarily.

The DTA describes its purpose as enabling accelerated and sustainable adoption of AI by agencies while positioning government as an exemplar in responsible AI use, and it is designed to complement existing Australian Public Service (APS) frameworks rather than duplicate them. Alongside the policy, the DTA publishes the AI technical standard, an AI impact assessment tool, and separate agency and staff guidance on public generative AI tools.

What are the DTA AI policy v2.0 deadlines?

The key dates are 15 December 2025 (effective), about 15 June 2026 (6 months), about 15 December 2026 (12 months) and 30 April 2027 (existing use cases). The policy expresses most deadlines as a period after it took effect, so the calendar dates below are calculated from 15 December 2025.

Date	Requirement	Source section
1 September 2024	Version 1.1 takes effect	Implementation
30 November 2024	Accountable official requirement first takes effect (under version 1)	Standard for accountability
28 February 2025	AI transparency statements first required (under version 1)	Standard for transparency statements
15 December 2025	Version 2.0 takes effect	Implementation
About 15 June 2026 (6 months)	Strategic position on AI adoption developed and communicated to staff	Strategy and oversight
About 15 December 2026 (12 months)	Approach to operationalise responsible AI; mandatory staff training; accountable use case owners; internal use case register; begin use case assessments	Strategy and oversight; preparedness and operations; impact assessment
Every 6 months from register creation	Share the use case register with the DTA	Strategy and oversight
30 April 2027	Existing use cases not yet assessed: determine scope and apply all relevant actions	AI use case impact assessment
Ongoing	Transparency statement reviewed at least annually; high-risk use cases reviewed at least every 12 months	Transparency standard; impact assessment

A note on reporting. Several commentaries describe 15 December 2026 as the date for full compliance. The policy’s own text gives existing use cases until 30 April 2027, and it encourages agencies to act sooner where practicable.

What are the DTA AI policy requirements for agencies?

Eight mandatory areas: accountable officials, transparency statements, a strategic approach, operationalising responsible AI, use case accountability, internal use case registers, staff training and use case impact assessments.

Strategy and oversight

• AI transparency statement. Published on the agency website, covering why the agency uses AI, its use classified by usage pattern and domain, where the public interacts with AI or is significantly affected without human review, monitoring and protection measures, compliance with the policy and law, and when it was last updated. Reviewed at least annually.
• Strategic position on AI adoption within 6 months.
• Accountable officials designated and notified to the DTA.
• Accountable use case owners for each in-scope use case within 12 months.
• Internal AI use case register within 12 months, shared with the DTA every 6 months.

Preparedness and operations

Within 12 months, agencies must establish an approach to embed responsible AI, including a process for adopting use cases, a way to inform staff designing AI about Australia’s AI Ethics Principles, internal and public pathways to report AI safety concerns, and AI incident processes aligned with ICT incident management. All staff must complete responsible AI training in the same period. The DTA strongly recommends the AI technical standard and its guidance on AI procurement.

Use case impact assessment

Every new AI use case must be assessed against the in-scope criteria during design. In-scope use cases need an AI use case impact assessment, begun at design and finalised, with risk treatments applied, before deployment. High-risk use cases must be reported to the accountable official, governed by a board or senior executive, reported to the DTA once deployed, and reviewed at least every 12 months.

What does responsible use of generative AI in government look like?

Under the policy, responsible use is a workflow, not a tool choice: test whether the use case is in scope at design, assess its impact before deployment, name an accountable owner, record it in the register, keep a person reviewing outputs where the public could be affected, and monitor it once live.

1. Design. Check the use case against the in-scope criteria below. A generative AI tool that drafts replies to the public, or reads case files, will usually be in scope.
2. Assess. Complete an AI use case impact assessment, using the DTA’s tool or an equivalent internal process, and apply risk treatments before go-live.
3. Own and record. Assign an accountable use case owner and add the use case to the internal register.
4. Keep a human in the loop. Decide where a person reviews outputs before they reach the public or influence a decision, and say so in the transparency statement.
5. Monitor and re-validate. Watch performance in production and reassess when the model, data or behaviour changes materially.

For individual public servants, the DTA’s staff guidance on public generative AI works much like an acceptable use policy. Subject to their agency’s own policies, staff can use public generative AI tools with OFFICIAL level information, but must not enter information classified OFFICIAL: Sensitive or above, or personal information. The guidance also says generative AI must not make final decisions on government advice, services or outputs.

Is your AI use case in scope?

A use case is in scope if any one of five criteria applies. Suppliers should run the same test on their product, because it predicts how much scrutiny the agency will need to apply.

Criterion (from Appendix C)	Example that would meet it
Use, misuse or failure could cause more than insignificant harm	A model that prioritises welfare compliance reviews
Materially influences administrative decisions	A tool that drafts recommendations on grant eligibility
Public may interact with it or be significantly affected without human review	A public-facing chatbot giving service information
Designed to use personal, sensitive or security classified information	A summariser over case files
DTA has directed it is elevated risk	As notified by the DTA

The DTA also lists areas needing careful attention even though they are not automatically high risk: recruitment and employment decisions, automated discretionary decisions, justice and democratic processes, law enforcement and border control, health, education and critical infrastructure. Incidental uses such as grammar checks in off-the-shelf software are out of scope, as is early experimentation that doesn’t commit to a design or risk harm.

What should suppliers prepare?

The policy binds agencies, but they can’t meet it without information from you. The minimum fields in the agency use case register, and the content of the impact assessment, tell you exactly what a buyer will ask for.

Agency obligation	What a supplier should be ready to provide
Use case register (description, technology type, product name)	A plain description of what the AI does and which models and components it uses
Record of whether the AI technical standard was applied	A mapping of your design, data, testing, deployment and monitoring practices to the standard’s lifecycle statements
Impact assessment and risk ratings	Intended use, known limitations, test methods and results, bias testing, data sources and residency
Monitoring and re-validation on material change	Release notes and advance notice of model, data or behaviour changes, ideally under contract
Incident processes	A defined way to report AI incidents to the agency, with timeframes
Transparency statement and public reporting	Plain-language material the agency can adapt, and whether a person reviews outputs before they affect the public
High-risk annual review	Performance and incident data to support the review

Security assessments sit alongside all of this. The AI policy doesn’t replace the Protective Security Policy Framework or the Information Security Manual, and many agencies will also ask about IRAP for the hosting environment.

Worked example: a correspondence summariser for an agency

Consider a supplier offering an AI tool that summarises incoming correspondence from the public and suggests which team should handle it. Walking it through the policy shows what the agency will ask and when.

1. Scope test at design. The tool reads letters that contain personal and sometimes sensitive information, so it meets the Appendix C criterion on personal or sensitive data. It is in scope, even though it only routes and summarises.
2. Impact assessment. The agency completes an AI use case impact assessment using the government’s tool. It will ask the supplier how the model was tested on real correspondence, how often it misroutes urgent or vulnerable correspondence, where data is processed, and whether summaries can omit important details. If the answers put the inherent risk at high, for example because misrouting could delay help to someone at risk, the use case needs board or senior executive governance and a report to the DTA once deployed.
3. Register entry. The accountable use case owner records the tool in the internal register: description, product name, technology type (generative AI), lifecycle stage, whether the technical standard was applied, risk ratings and the assessment date. The supplier’s documentation feeds almost every field.
4. Deployment. Risk treatments are applied before go-live. Typical treatments here are a human confirming the routing of anything flagged as urgent, and a daily sample check of summaries against originals.
5. Operation. The agency monitors whether the tool works as intended and re-validates the assessment on material change. A model upgrade by the supplier is a material change, which is why the change notification clause matters.
6. Review. If rated high risk, the use case is reviewed at least every 12 months, drawing on the supplier’s performance and incident data.

A supplier that arrives with test results on representative correspondence, a data flow map, a change notification commitment and an incident process shortens every one of those steps. One that arrives with a sales deck adds months.

Common supplier mistakes

• Treating the policy as the agency’s problem. It is, legally, but an agency that can’t complete its assessment can’t buy your product.
• Hiding the model. Agencies need to record the underpinning product and technology type. “Proprietary AI” won’t fill the register.
• Silent model upgrades. Swapping the underlying model without notice forces the agency to re-validate after the fact and damages trust.
• No human review option. Whether the public is affected without human review is an in-scope criterion and a transparency statement item. Offer a review mode.
• Offshore processing by default. Data handling will be questioned closely. Know where prompts, outputs and logs are processed.

Supplier readiness checklist

• A one-page description of each AI feature: purpose, models, data, human review points.
• Your own in-scope assessment against the five Appendix C criteria.
• Test methodology and results, including accuracy, bias and adversarial testing.
• A mapping of your delivery lifecycle to the DTA AI technical standard.
• Data flow and residency documentation for prompts, outputs, embeddings and logs.
• A change notification commitment for model and behaviour changes.
• An AI incident reporting process with contacts and timeframes.
• Per-request logging the agency can use for monitoring and contestability.
• A kill switch and fallback so the agency can maintain human control.
• Plain-language text the agency can use in its transparency statement.

For the wider picture on selling into federal government, including BuyICT, see how to sell software to Australian government.

How All Webbed Labs approaches this

We’re a Sydney team building AI systems with the documentation this policy expects: use case descriptions, test evidence, data flow maps, change logs, incident processes and kill switches, prepared so an agency’s accountable officials can use them in their own assessments. We don’t hold government panel membership or security clearances, and we can’t meet the policy on an agency’s behalf; the agency remains responsible for it. See our government AI and software page and our AI governance service.