Generate the requirements and questions for an AI purchase.

A neutral synthetic procurement: internal retrieval and assisted drafting over a policy and contract library. It is invented for illustration and is not drawn from any engagement, tender or supplier. The example shows the gates and the questionnaire structure in full; the browser tool prints every section.

• Use case — Assisted drafting and retrieval across our own policy and contract library
• Intended outcome — Staff can find and cite the current version of an internal policy or contract clause without asking a specialist, with every answer traceable to a source document.
• Buyer type — Private sector
• Users — 260 people
• Deployment preference — Must run in a named jurisdiction
• Data categories involved — Internal, non-personal; Personal information about customers or staff; Commercially confidential or IP
• Decision consequence — Moderate: informs a decision a person then makes
• Integration needs — Read from internal systems; Identity and single sign-on
• Availability and recovery — Business hours, with a stated availability target
• Audit and logging — Full audit trail exportable to our own systems
• Model-change constraint — Version pinning required
• Portability and exit — Full export including configuration and evaluation sets
• Evaluation method — Paid pilot on our own data against acceptance criteria
• Include these sections — Scope and intended outcome; Gates and preferences; Requirements; Evidence requests; Vendor questionnaire; Pilot acceptance criteria; Weighted comparison matrix

Non-negotiable gates

8

Requirements

8

Evidence requests

10

Questionnaire items

31

Non-negotiable gates for this example

1. Data and privacy. Content submitted by the buyer, and output generated from it, must not be used to train or improve any model, on any plan the buyer holds.
2. Data and privacy. The supplier must state, in the contract, every location where the buyer's content is processed, stored, logged and backed up, and every sub-processor with access to it.
3. Data and privacy. Processing, storage, logging and backup of the buyer's content must remain within the jurisdiction named in the contract, including support access.
4. Data and privacy. The buyer must be able to obtain deletion of its content, including from logs and backups, within a stated period, and receive evidence that deletion has occurred.
5. Model and evaluation. A model version, once selected, must remain available to the buyer for a stated minimum period, and the buyer must be able to decline a change within that period.
6. Portability and exit. On termination the buyer must receive its content, configuration, prompts and evaluation sets in a documented, non-proprietary format, within a stated period.
7. Security and access. Access must integrate with the buyer's identity provider, honour the buyer's existing permissions, and never present a user with content they are not entitled to see.
8. Incident handling. The supplier must notify the buyer of any security or privacy incident affecting the buyer's content within a stated period, with a stated minimum content for that notice.

Pilot acceptance criteria for this example

1. Accuracy on a held-out sample of our own material, at a threshold we state before the pilot begins, measured by a person who did not build the configuration.
2. The proportion of output routed to a human review stays at or below a limit we state, because an automation that routes everything saves nobody any time.
3. Every answer is traceable to source material a reviewer can open, on every sampled case.
4. Response time at our peak load stays within a stated bound, measured from where our users sit.
5. Integration failures are visible within a stated period and none pass silently.
6. Permissions are enforced: a test user cannot retrieve content they are not entitled to see, on every attempt in the test set.
7. Our own administrators complete a defined set of routine changes without supplier involvement.
8. A deletion request completes within the stated period, with evidence, including from logs and backups.
9. The pilot has a stated stop condition, and failing these criteria is an acceptable outcome that ends the procurement rather than triggering a renegotiation.

Every clause is conditional on something you selected. Nothing is included because it sounds thorough.

The five clauses worth insisting on, whatever you are buying

1. Training use, on the plan you are actually buying. The answer often differs between a consumer tier, a team plan and an enterprise agreement for the same product, and the marketing page usually describes the best case.
2. The full processing picture, not the compute region. Where processing, storage, logging, backups, telemetry, support access and sub-processors sit, named, in the contract.
3. Deletion with evidence, including logs and backups. "We delete on request" is not a deletion path until it says from where, how fast, and what you receive as proof.
4. Model-change notice with enough lead time to re-run your own evaluation. A model change is a silent change to the thing you bought, and it is the failure mode that arrives after the procurement is over.
5. What leaves with you at exit. Data, configuration, prompts and evaluation sets, in a documented format. Anything that is only meaningful inside the supplier's product is a cost you pay later.

1. It is a starting point, not a document to issue. The wording is drafted to be edited by whoever is accountable for the procurement, and it has to be reconciled with your own templates, thresholds and approval process.
2. It is not procurement, legal, privacy or security advice. Several clauses touch obligations that differ by organisation, sector and jurisdiction.
3. It reproduces no government or standards text. The clauses are original. Where a published framework covers the same ground, it is cited below rather than restated, and you should read it directly if it binds you.
4. It does not know your procurement rules. Government and publicly funded buyers have mandatory frameworks, thresholds and processes that override anything here, and the DTA's own procurement guidance and technical standard apply to Australian Government agencies rather than to everyone.
5. It does not evaluate suppliers. It produces the questions and the matrix. Scoring is yours, and so are the weights.
6. It does not price anything. The commercial questions are in the questionnaire; the analysis is not here.

• Gate — a requirement that is pass or fail. Failing one ends the assessment rather than reducing a score.
• Evidence request — a document or artefact asked for with the response, as distinct from an assertion in it.
• Sub-processor — a third party the supplier uses that can reach your material.
• Version pinning — the ability to hold a specific model version for a stated period and to decline a change within it.
• Recovery time and recovery point objectives — how long restoration may take, and how much data loss is acceptable. Meaningful only if tested.
• Weighted comparison matrix — criteria with weights agreed before responses are read, so the weighting cannot be fitted to a preferred supplier.
• Pilot acceptance criteria — statements that can be false, tested on your own material before a commitment. The pilot plan generator develops these in full.

Cited as references. The Digital Transformation Agency's procurement guidance and technical standard apply to Australian Government agencies; the National AI Centre's practices are addressed to organisations generally. Nothing from them is reproduced here.

1. Digital Transformation Agency, Guidance on AI procurement in government (announcement and links). Released 2 December 2025; the guidance itself is hosted on BuyICT.
2. Digital Transformation Agency, Technical standard for government's use of artificial intelligence. Applies to Australian Government agencies.
3. National AI Centre, Guidance for AI adoption: implementation guidance. Part of the Essential AI practices.
4. National AI Centre, Guidance for AI adoption: foundations. Part of the Essential AI practices.
5. Office of the Australian Information Commissioner, Guidance on privacy and the use of commercially available AI products. Published 21 October 2024, updated 17 January 2025.

Primary sources last reviewed 27 September 2026. These are the publishers’ own pages; they are quoted nowhere on this site and nothing here restates them as a requirement that applies to you.