This guide is the content team's half of an AI procurement. It is for content designers, content leads and communications managers who came into a procurement late, or not at all.
The Policy for the responsible use of AI in government covers risk, accountability and assurance. It does not mention plain language, WCAG or the Australian Government Style Manual. That is not a criticism. It is a different job.
But if the system drafts, summarises, translates or publishes content the public reads, your accessibility and plain language obligations still apply. They stop being anybody's job unless a content person writes them into the schedule.
The obligation sits in another instrument. Criterion 4 of the Digital Inclusion Standard names 3 things to comply with. The Disability Discrimination Act 1992, the latest version of the Web Content Accessibility Guidelines (WCAG), and the Style Manual. It asks whether procurements have considered accessibility.
A small irony sits in that. The AI policy never says plain language or Style Manual. Its own subordinate standard, on AI transparency statements, asks for both in a single sentence.
The Digital Transformation Agency (DTA) released its Guidance on AI procurement in government on 2 December 2025. It speaks to buyers and assurance. It tells an agency how to buy AI, not what a content team should specify.
So the obligation applies. What no instrument gives you is the wording to put in a contract. That is what the schedule below is.
Before you start
You need 3 things. The draft statement of requirements. A plain answer to whether the tool will touch public-facing content. And 15 minutes with whoever owns the procurement.
That last one is the hard part, and it is the one that changes the outcome.
Step 1: establish whether the output reaches the public
Summarising internal briefings is one risk. Drafting service content or answering public questions is another. Write down which one you are buying, in a sentence, and attach it to the requirements.
Step 2: put content requirements in the business case
Requirements that arrive after the evaluation criteria become preferences. Preferences get traded away when price is tight. Name the outcome and name the test.
Step 3: specify accessibility of the output, not just the interface
A vendor conformance report covers the tool, not the content the tool generates. Ask for both. Test the output before acceptance with real content, not a vendor demo.
Step 4: set a plain language expectation you can measure
Plain English in a contract is unenforceable. Name the Australian Government Style Manual and AS ISO 24495.1:2024 instead. Do not accept a readability score as evidence.
Step 5: name who is accountable for what gets published
The policy names an accountable owner on the agency side. Your contract needs the other half. Who reviews before publication, what they check it against, and who pays to fix it.
Step 6: contract for the transparency statement
Every non-corporate Commonwealth entity has to publish an AI transparency statement, and you cannot write one from a product brochure. Ask the vendor to describe, in plain language, what the system does, what data it uses, and where its outputs reach the public.
Step 7: contract for the exit
Content created inside a vendor's system may not come out again. Require export in an open, structured format with metadata intact, and run the export once before acceptance rather than at termination.
What good looks like
A procurement officer who has never heard of WCAG can read your schedule and say what the vendor must prove.
Every requirement has a named test, a date, and somebody who signs it off.
You wrote the scope answer in one sentence and attached it to the requirements.
You have run the export once, before acceptance, rather than assuming it works.
Somebody outside the content team can say what happens if the tool publishes something inaccessible.
That last one is the real test. Give it to a colleague and ask. If they cannot answer, you have not written the clause yet.
The next AI tool your agency buys will produce content someone has to stand behind. Who in your agency has the brief to ask what standard that content has to meet?
Get the schedule
Use it two ways. Download the branded version to attach to a procurement, or open the schedule in the accordion below and copy it into your own document.
AI content requirements schedule
Attachment to: [Contract or statement of requirements reference]
Agency: [Agency name]
System or service: [Name of the AI product or service]
Prepared by: [Name, role]
Date: [Date]
Version: [1.0]
1. How to use this schedule
This schedule sets out the content requirements that apply when an AI system drafts, summarises, translates, structures or publishes content that people outside the organisation read.
Attach it to the statement of requirements before evaluation criteria are set. Requirements added afterwards become preferences.
Delete any section that does not apply. Do not delete section 9, the evidence table. It is what makes the rest enforceable.
2. Scope of AI use covered
This schedule applies to the following use of the system:
- [Describe what the system will produce or change. For example: drafts service content for review; generates plain language summaries of policy documents; translates published content into the languages listed; responds to public enquiries in a chat interface.]
The outputs of this system [will / will not] reach the public without human review.
Answer this in one sentence and keep it visible. The scope test is in Appendix C of the Policy for the responsible use of AI in government. A use case is in scope where "it is possible the public will directly interact with, or be significantly impacted by, the AI or its outputs without human review". That answer determines what evidence is proportionate. It also determines whether an impact assessment is required.
3. Accessibility of outputs
The supplier must ensure that:
- Content generated by the system conforms to Web Content Accessibility Guidelines (WCAG) 2.2 Level AA when published in [agency name]'s content management system.
- Generated markup uses a real heading hierarchy, with no heading levels skipped and no headings applied for visual styling.
- Generated tables include a header row marked up as header cells, and are not used for layout.
- Generated link text is descriptive and makes sense out of context.
- The system does not insert images without prompting for alternative text, and does not auto-generate alternative text without flagging it for human review.
- The supplier provides an accessibility conformance report for its own interface, separate from the requirements above.
Ask for both. A conformance report for the product tells you a staff member can use the tool. It says nothing about the content the tool produces.
4. Plain language and language conventions
Content generated by the system must be capable of meeting:
- The Australian Government Style Manual.
- AS ISO 24495.1:2024, Australia's adoption of the international plain language standard.
The supplier must confirm that the system:
- Produces Australian English spelling by default.
- Uses Australian date, number, currency and measurement conventions.
- Can be configured to [agency name]'s terminology and style decisions, including a maintained list of preferred and prohibited terms.
Do not accept a readability score as evidence of plain language. Name a review by a person against a named standard. Set the sample size and pass threshold in section 9.
Ask for the language conventions in writing. Most models default to United States English, and the fix costs more after go-live than before.
5. Human review and accountability for published content
- [Agency name] retains accountability for all content published from this system.
- Content generated by the system must be reviewed by [named role] against the Style Manual, WCAG 2.2 Level AA, and agency content standards before publication.
- Where the system produces content that is inaccurate, inaccessible or misleading, the supplier must notify [agency name] within [number] business days of becoming aware.
- Correction of defects attributable to the system is at the supplier's cost, within [number] business days.
- The supplier must notify [agency name] at least [number] days before any change to the underlying model, prompts, training data or output behaviour.
The last point is the one most often missing. A model update can change how content reads without anyone in the agency being told.
6. Transparency and disclosure
The supplier must provide, and keep current, a plain language description of:
- What the system does and what it is intended to be used for.
- What data the system uses, including whether [agency name] content is used to train or improve any model.
- Where and how outputs may reach members of the public.
- Known limitations, failure modes, and any content types the system should not be used for.
[Agency name] needs this information to meet its obligations under the Policy for the responsible use of AI in government. One of those obligations is the AI transparency statement. That standard requires statements to "use clear, plain language that avoids technical jargon and is consistent with the Australian Government Style Manual". Supply the description in a form you can quote directly into one.
7. Content, data, and intellectual property
- [Agency name] owns all content it supplies to the system and all content generated for it by the system.
- [Agency name] content [may / may not] be used to train, fine-tune or improve any model, including models offered to other customers.
- Content supplied to the system is stored and processed in [location], and is not disclosed to third parties without [agency name]'s written agreement.
- The supplier indemnifies [agency name] against claims that generated content infringes third-party intellectual property.
8. Export and exit
- On request, and on termination, the supplier must export all [agency name] content and associated metadata in an open, structured, machine-readable format at no additional cost.
- The export must include content, metadata, taxonomy or tagging structures, version history and review records.
- The export must be delivered within [number] business days of request.
- The supplier must confirm deletion of [agency name] content within [number] days of termination, in writing.
Test the export before acceptance, not at the end of the contract. An export you have never run is an assumption.
9. Evidence and acceptance testing
| Requirement | Evidence the supplier must provide | When it is tested |
|---|---|---|
| Accessible output | WCAG 2.2 Level AA test results for generated content, using a sample of [number] real items supplied by [agency name] | Before acceptance, then [annually] |
| Product accessibility | Accessibility conformance report for the supplier's own interface, dated within [12] months | At tender |
| Plain language | Review of [20] generated items against the Australian Government Style Manual by [named role], with a pass rate of at least [number]% | Before acceptance, then [annually] |
| Language conventions | Confirmation of Australian English spelling and Australian date, number, and currency conventions in generated output | Before acceptance |
| Transparency information | Plain language description of what the system does, what data it uses, and where outputs may reach the public | At contract start, then on material change |
| Export | Successful test export of [agency name] content in an open, structured format with metadata intact | Before acceptance, then [annually] |
Failure to provide the evidence above by the dates specified is a defect for the purposes of [clause reference].
10. Reporting and review
- The supplier reports against the requirements in section 9 [annually], in writing.
- [Agency name] reviews this schedule at each contract extension or renewal, and on any material change to the system.
- [Agency name] reviews the AI use case at least every 12 months, consistent with the Policy for the responsible use of AI in government.
Photo by Sean Fahrenbruch on Unsplash.