Australian Standard for AI (Data Governance and Consent) 2027
Status and provenance note. This is a model legislative instrument, drafted by a private party and published in July 2026, before any consultation opened. It is written as if made under the framework legislation the Government announced on 15 July 2026, using the chapter structure that announcement implies. Where the eventual act differs, the mechanics below transplant. It exists because agencies, not parliamentary drafters, write instruments - and the agency in question is weeks old. Adopt it, gut it, or use it as the thing your better draft is better than. A definition no examiner can apply serves only the party hoping not to be examined; every definition below is written to be examined.
Model instrument - published for adoption, adaptation or improvement
Part 1 - Preliminary
1. Name. This instrument is the Australian Standard for AI (Data Governance and Consent) 2027.
2. Commencement. The day after registration, except obligations at conformity classes B and C, which commence as set out in section 32.
3. Authority. Made under the standards-making power of the framework Act [Ch 3, Pt 3.1 of the announced architecture].
4. Simplified outline. This Standard does five things. It defines what a valid consent to use data is, as a record with five mandatory elements. It provides for that consent to travel with the data it governs, including by cryptographic binding, so that use outside the consent's terms can be prevented rather than merely prohibited. It requires provenance records for training data and for system outputs, and defines when those records must be verifiable rather than asserted. It defines three classes of revocation and states which contexts require which. And it provides for a body representing a group of grantors to require proof, on demand, that data is held under a current grant, and to revoke collectively where an organisation cannot show it. Obligations in this Standard specify required properties, not required technologies; conformity is assessed against the classes in Part 8.
5. Definitions. In this instrument:
automated system means a system that performs a task without human action at the moment of performance.
consent grant means a record of permission issued by the person or entity that a set of data is about or belongs to (the grantor), authorising a named party (the grantee) to access or use that data.
cryptographic binding means a technical measure by which data is encrypted or otherwise protected such that access or use outside the terms of its consent grant is technically prevented.
determination means a conclusion adopted by a person or body with standing to make it, from which consequences follow for a person.
author, of a determination, means the identified person or body answerable for it.
inferred result means a conclusion produced by running a trained model on inputs, recorded as such.
mandate means a set of data bound to its consent grant such that the grant's scope, purpose, period and revocation state travel with the data.
provenance record means a record of the sources that produced an artefact or output; a provenance record is verifiable if a party that does not trust the record-keeper can confirm its accuracy, and is otherwise declarative.
representative body means a body with standing to act on behalf of a group of grantors, whether by the grantors' authorisation, by membership, or by a recognition or declaration under a law of the Commonwealth; a representative body may exercise the grantors' rights under this instrument collectively to the extent of that standing.
trained model means a file or set of files of numerical parameters produced by a training process over a body of data.
training data means the body of material consumed by a training process.
Note: These definitions are drawn from a published glossary whose selection criteria are testability, accountability and durability. Terms deliberately not used in operative provisions include "artificial intelligence" (no testable referent), "autonomous" (status claim) and "human in the loop" (satisfiable by a rubber stamp).
6. Application. This Standard applies to a deployer or developer of an automated system that (a) uses personal data or data belonging to another entity, or (b) produces inferred results used in making determinations. Thresholds and phase-in by entity size are set by the classes in Part 8, not by exemption from the obligations themselves.
Part 2 - Consent grants
7. The five elements. A consent grant is well-formed only if it records: (a) the grantee; (b) the data or classes of data covered; (c) the purpose or purposes of use; (d) the period, with an end date or a defined review interval; and (e) the method by which the grantor may revoke.
8. Effect of deficiency. A grant missing any element of section 7 is unenforceable by the grantee and remains enforceable by the grantor. A grantee cannot cure deficiency by inference from conduct.
9. Grant as record. A consent grant must exist as an inspectable record available to the grantor for the life of the grant and for seven years after its end. Consent obtained through an interaction is not the record; the record is what section 7 describes.
Note: This provision moves consent from a ritual at collection time to an object with a lifecycle - the pattern the Consumer Data Right already operates for designated sectors.
10. Purpose limitation. Use of granted data for a purpose outside paragraph 7(c) is a contravention regardless of any other lawful basis the grantee asserts, unless a law of the Commonwealth expressly compels the use, in which case Part 6, section 25 applies.
Part 3 - Mandates
11. Binding. A deployer holding granted data at conformity class B or above must maintain the data as a mandate: the grant's elements and current revocation state must be resolvable from the data itself or from an identifier inseparable from it.
12. Cryptographic binding. At conformity class C, binding must be cryptographic for data at rest: the data is protected such that decryption or use outside the grant's period or purposes is technically prevented, and a breach in which the deployer's copy is exfiltrated does not yield usable data.
Note: Class C converts "we promise not to" into "we cannot". A breach in which only sealed mandates are exfiltrated exposes nothing a hacker can use, so the person whose data it is suffers no exposure - the accidental-breach case is neutralised by design, not by promise. Read with the decryption records at section 25C, the protection becomes provable both ways: a deployer that can produce the records shows it held the data sealed and is protected; a deployer that cannot was holding the data decrypted against its obligations, and is answerable for the exposure. A deployer meeting section 12 may therefore say plainly what few services can - that it keeps borrowed data only as sealed packages, never as decrypted data, so a customer's data is safer in its hands than with a service that can only be trusted to behave. Compliance here is not a cost; it is a security claim a competitor cannot make.
13. Organisational grantors. Parts 2 and 3 apply where the grantor is an organisation in the same way as they apply where the grantor is an individual.
Part 4 - Provenance
14. Training data provenance. A developer must maintain a provenance record for each trained model identifying the datasets and classes of material consumed in training, sufficient to establish whether material subject to a consent grant, or to the licensing provisions of the framework Act, was used within the terms of that grant or those provisions.
15. Output provenance. A deployer whose automated system produces inferred results used in determinations must maintain a provenance record for each such result identifying, at minimum, the trained model (by version or hash) and, at class C, each separable capability component involved.
16. Verifiability escalation. Provenance records may be declarative at class A, must be independently auditable at class B, and must be verifiable at class C.
Part 5 - Determinations
17. Author required. Every determination made with the assistance of an automated system must be recorded, and the record must identify its author. A record in which no natural person or identified body is the author records an automated determination, and section 18 applies.
18. Automated determinations. An automated determination affecting a person is permitted only where the framework Act permits it for the decision class, and must be accompanied by: (a) notice to the affected person that the determination was automated; (b) a statement of what produced it, drawing on the section 15 record; and (c) a right to review by a person with authority to substitute their own determination.
19. Review means substitution. A review process in which the reviewer lacks authority, information or time to reach and give effect to a different conclusion does not satisfy paragraph 18(c).
20. Inferred results distinguished. A system record must distinguish structurally between an inferred result and a determination. Displaying an inferred result as if it were a determination, or defaulting a determination field to the content of an inferred result without an author's act of adoption, is a contravention.
Note: Sections 17-20 give effect to the human-oversight and contestability guardrails in the 2024 proposals paper, and to the findings of the Royal Commission into the Robodebt Scheme regarding determinations without identifiable authors. A reference implementation is publicly available.
Part 6 - Revocation
21. Classes of revocation. Revocation of a consent grant or of a capability authorisation takes one of three forms: (a) advisory - relying parties are notified to cease reliance; (b) access-gated - further access or use is prevented; (c) erasure - previously issued material is rendered permanently unusable by destruction of key material.
22. Minimum class. At conformity class B and above, a grantor's revocation must be given effect at class (b) or above. Advisory-only revocation satisfies this Standard only at conformity class A.
23. Erasure availability. At conformity class C, a deployer must be capable of class (c) revocation for mandates it holds, subject to section 25.
24. Propagation. Revocation must take effect against the deployer's systems within a defined period stated in the grant (default: 30 days at class A, 7 days at class B, at next access at class C).
25. Retention laws prevail. Where a law of the Commonwealth or a State requires retention of records, revocation operates at class (b) with audit of any compelled access, and class (c) is unavailable for the retained material. Compelled access to granted data must be logged, scoped to the compelling instrument, and the log made available to the grantor unless a law prohibits it, in which case the log must be retained for later accountability.
Note: Section 25 is the interface between consensual and compelled use. It does not restrain lawful compulsion; it makes lawful compulsion demonstrable.
Part 6A - Collective representation, proof of authority, and decryption records
25A. Representative bodies. A representative body may exercise, on behalf of the grantors it represents, any right this instrument confers on a grantor, including the right to inspect a grant (section 9), the right to require proof under section 25B, and the right to revoke under Part 6.
25B. Proof of current authority. On request by a grantor, or by a representative body acting for that grantor, a grantee must produce within 14 days evidence, verifiable by the requester, that its holding and any use of the identified data is covered by a consent grant that is valid and current - that is, that a live grant authorises that data for that purpose and has neither expired nor been revoked. At conformity class C the evidence must be cryptographic.
25C. Decryption and use records. A grantee holding a mandate at conformity class B or above must maintain, for each decryption or use of the granted data, a signed and time-stamped record sufficient to establish that the decryption or use occurred while a valid grant was in force. On request under section 25B, the grantee must produce the record for the data identified.
25D. Effect of failure to produce. Failure to produce the evidence required by section 25B or the record required by section 25C, on request and within the period, is a contravention of this instrument, and entitles the grantor or representative body to treat the data as held without demonstrated authority and to revoke under Part 6. The absence of a producible record is itself the finding: a grantor so informed knows the grantee cannot attest to lawful holding, and may act accordingly.
25E. Investigation and collective revocation. A representative body may investigate a grantee's compliance with this instrument in respect of data it administers. On finding that the grantee has failed to meet an obligation under this instrument, the representative body may revoke the grants it administers on the grantors' behalf. Revocation under this section has the effects in Part 6 at the applicable conformity class, including rendering unusable, at class C, the mandates the grantee holds.
Note: This Part gives a collective the standing that a single grantor rarely has the resources to exercise. It is the institutional form Australia's collecting societies and the framework Act's creative-works licensing already assume - a body that holds and enforces rights on members' behalf - applied to data. It creates no power to read member data: a representative body's power is to require proof and, failing it, to revoke. The cryptographic binding sections 25B-25C build on (sections 11-12) has a running reference implementation; the proof-on-demand and collective-revocation flow is specified here as design.
Note - open question, flagged for debate, not settled drafting. Part 6A lets a private representative body investigate, reach a finding of contravention (section 25D), and revoke collectively (section 25E). That is deliberately strong, and it raises unresolved questions: whether a body that is not a court should reach a "finding" carrying legal consequence; proportionality, where one body's investigation can render an organisation's whole mandate set unusable; and the natural-justice and defamation exposure of a published finding. We have not resolved these, and a model instrument should not pretend to. This Part is published so the controversy can be had in the open, with a worked example in front of it, rather than deferred - and if the right answer is that only a court or a conferred regulator makes the finding while the representative body may only require proof and refer, that is a legitimate and perhaps better resolution. Read sections 25A-25E as a design proposal inviting scrutiny. We would rather debate the mechanism than assume it.
Part 7 - Prohibited practices
26. A deployer must not: (a) condition provision of a service on a grant broader than the service requires; (b) obtain a grant through an interface designed to obscure any of the five elements; (c) treat silence, inactivity or continued use as a grant; (d) reconstruct, from other sources, data whose grant has been revoked; or (e) use, or continue to use, data after the grant covering it has been revoked, including where the deployer retains a copy.
Note: A deployer that continues to use data after revocation contravenes paragraph (e) whether or not it still holds a technical copy. Liability for the contravention, including any civil penalty, is a matter for the framework Act and, where a grantor or a representative body brings proceedings, for a court.
Part 8 - Conformity
27. Classes. Conformity with this Standard is assessed at one of three classes:
- Class A (documentary) - records exist and are produced on request.
- Class B (operational) - obligations are tested against system behaviour by an assessor.
- Class C (continuous) - the properties in this Standard are verifiable in use by relying parties, including by attestation of the systems involved.
28. Minimum class by context. The Minister may, by notice, specify contexts (by sector, decision class or scale) requiring a minimum class. Until specified: class A applies generally; class B applies to determinations affecting eligibility for benefits, employment, credit, housing, or education; class C applies where a Commonwealth entity is the deployer.
29. Self-assessment limits. Class A conformity may be self-assessed. Classes B and C may not. An assessment is not independent if the assessor's remuneration depends on the outcome.
30. Reference implementations. Conformity may be demonstrated by adoption of a reference implementation evaluated and listed by the AI Safety Institute, without further assessment at the listed class.
Note: Section 30 makes compliance the cheap path. Listing is open to any implementation, including open-source implementations, that passes evaluation.
31. Attestation. At class C, a claim that a system possesses a property required by this Standard must be supported by evidence checkable by a relying party. Assurance by the provider is not attestation.
32. Phase-in. Class B obligations commence 12 months after this instrument; class C obligations, 24 months after, or on the listing of two independent reference implementations for the relevant property, whichever is earlier.
Part 9 - Records, audit and review
33. Retention and production of records. Records required by this Standard must be retained for seven years and produced to a regulator exercising conferred functions under the framework Act.
34. Review of this instrument. This instrument must be reviewed within three years of commencement, and the review must be published.
Schedule 1 - Matters deliberately left to the framework Act
These are flagged so that their absence here is not read as their absence: the classes of decision that must never be automated regardless of consent (decisions over liberty, the use of force, the exercise of mercy, and the framing of law); the licensing scheme for Australian creative works; the conferral of enforcement functions on regulators; and civil penalties.
A model instrument by Meanwhile (meanwhile.computer), written with model assistance, read and edited by its human author, and published so that its provenance is a matter of record. Definitions derive from the published glossary; sections 11-12 and 15 have a running reference implementation, published at git.meanwhile.computer; corrections via the contact page will be published with the version history.
Reviewed and checked by the human author: 2026-07-19.