Governing Intelligence · Appendices
Templates and appendices
Appendix AAI use-case intake and risk-tiering template
Use this template to register a proposed AI use case and assign its risk tier. It produces a register entry and the first input to the impact assessment. Tier the use case on the higher of impact and likelihood.
| Field | Capture |
|---|---|
| Use case name and reference | A short name and a register identifier. |
| Accountable official | The single named owner accountable for this use case. |
| Purpose and public value | What it is for, in terms of the people served. |
| AI type and autonomy | Assistive, supervised, or autonomous; the maturity level. |
| Data used | Classification, personal information, source and sovereignty. |
| People affected | Who is affected, and whether decisions about them are involved. |
| Potential harms | Harms to individuals, lawfulness, privacy, security, reputation. |
| Vendor and tooling | Any third party and its proprietary tools; assurance status. |
| Proposed risk tier | Low or high, with a one-line rationale. |
| Risk tier | Indicative criteria | Assurance depth |
|---|---|---|
| Low | Assistive; no decisions about people; low classification; reversible. | Light gates; impact assessment; standard monitoring. |
| High | Affects rights, entitlements or safety; sensitive data; limited reversibility; higher autonomy. | Full gates including simulation and shadow; enhanced monitoring; executive sign-off. |
Appendix BAI Impact Assessment: alignment to the AI Ethics Principles
The agency uses the DTA’s AI Impact Assessment tool. This appendix maps each of Australia’s eight AI Ethics Principles to the evidence the assessment should capture, so the two are completed together.
| Ethics principle | Evidence to capture in the assessment |
|---|---|
| Human, societal and environmental wellbeing | The public benefit sought, and any wider impacts considered. |
| Human-centred values | How rights and human oversight are respected. |
| Fairness | Bias tested and managed; disparate impact considered. |
| Privacy protection and security | Privacy assessed; security controls and classification applied. |
| Reliability and safety | Tested against realistic and adversarial conditions; fails safe. |
| Transparency and explainability | Transparency statement; ability to explain decisions. |
| Contestability | A clear path to human review for affected people. |
| Accountability | A named accountable official and an audit trail. |
Appendix CAI governance RACI and committee terms of reference
R is responsible (does the work), A is accountable (the single owner), C is consulted, I is informed. The single-owner rule applies: where two roles appear accountable, the decision stalls.
| Activity | Auth | Cmte | Owner | Sec | Priv | Audit |
|---|---|---|---|---|---|---|
| Set AI strategy and risk appetite | A | R | C | C | C | I |
| Approve a use case and its risk tier | I | A | R | C | C | I |
| Maintain the use-case register | I | A | R | I | I | I |
| Complete the impact assessment | I | C | A | C | C | I |
| Approve a transparency statement | I | A | R | C | C | I |
| Secure the platform and enclaves | I | C | C | A | I | I |
| Pass a readiness gate (go/no-go) | I | A | R | C | C | C |
| Provide independent assurance | I | I | I | C | C | A |
Key: Auth accountable authority and executive; Cmte AI Governance Committee; Owner use-case accountable official; Sec security and platform; Priv privacy and legal; Audit internal audit and AI assurance.
Committee terms of reference (indicative)
- Purpose. To assure the safe, secure and effective use of AI across the agency, and to act as the go/no-go authority for AI use cases.
- Chair. The accountable official for AI strategy.
- Membership. Service delivery, data, security, privacy, legal and risk; the CISO; and use-case owners as required.
- Decisions. Approves use cases and risk tiers; owns the register; reviews impact assessments; approves transparency statements; decides at readiness gates.
- Cadence. Monthly, with out-of-cycle decisions for time-critical gates.
Appendix DThird-party and proprietary-AI-tool assurance checklist
Apply this checklist before any third party uses its own AI tools on agency code, data or systems. It supports the procurement cornerstone of the assurance framework and the AI procurement guidance.
- Model and tool transparency: model cards, intended use, known limitations and evaluation results provided.
- Right to audit the tooling and its behaviour, including independent or IRAP assessment of the environment.
- Data handling: no training on agency data without explicit consent; no external egress; data and keys onshore.
- Containment: the tools run in an isolated, monitored enclave with logged, least-privilege access.
- Provenance: every output is attributable, with lineage from input to result.
- IP and licensing: warranties on training-data rights and output licensing; indemnities for infringement.
- Security: vulnerability management, secure development, and supply-chain assurance evidenced.
- Exit: data and artefacts portable on exit; no lock-in; deletion certified on completion.
Appendix EAI-generated code assurance checklist
Apply this checklist to software produced or substantially modified by AI before it is accepted or deployed.
- Business-rule fidelity: rules extracted from the legacy system, reviewed and signed off by an accountable officer.
- Behavioural parity: the new code is proven to match the intended behaviour, with differences explained and approved.
- Security testing: static and dynamic analysis passed; no introduced vulnerabilities; dependencies scanned.
- Human review: a qualified engineer has reviewed and accepts the generated code; the acceptance is recorded.
- Provenance and records: the prompt, model version and rationale are captured as records under the Archives Act.
- Lawfulness: where the code applies rules affecting people, legal has confirmed the rules as implemented are lawful.
- Deployment control: change-managed, progressively deployed, with monitoring, kill switch and rollback.
Appendix FMandate compliance crosswalk
A quick reference from each major Commonwealth instrument to where this framework addresses it.
| Instrument | Addressed in |
|---|---|
| AI Ethics Principles (8) | Sections 3.1 and 9; Appendix B |
| Policy for responsible use of AI in government v2.0 | Sections 3.2, 5, 6, 9 and 10 |
| AI technical standard (Discover/Operate/Retire) | Sections 3.3, 9.5 and 10 |
| National framework for assurance of AI in government | Sections 3.4 and 9 (five cornerstones) |
| Guidance for AI Adoption (AI6) | Sections 3.5 and 10 |
| National AI Plan; AI Safety Institute | Sections 3.6, 4 and 5 |
| PSPF; ISM; Essential Eight; IRAP; Hosting Certification | Sections 3.7 and 7; Appendix D |
| Privacy Act and ADM transparency (from Dec 2026) | Sections 3.7, 8.4 and 9.6 |
| Archives Act (records and provenance) | Sections 7.3, 9.6 and Appendix E |
| PGPA Act; Commonwealth Procurement Rules | Sections 6, 12.1 and 12.5; Appendix D |
| APS AI Plan: Chief AI Officers, mandatory training, GovAI | Sections 3.6, 6.2, 13.3 and 13.6 |
| Agentic AI addendum to the technical standard (2026) | Sections 3.3, 8 and 9 |
| ASD AI security guidance and ISM AI controls (2025-26) | Sections 3.7 and 7.4; Appendix D |
| OAIC guidance on AI and privacy (2024) | Sections 3.7 and 9.6 |
| Automated Decision Making Better Practice Guide (2025) | Sections 3.8, 8.4 and 9.6 |
| ANAO AI audit criteria (2024-25 and 2025-26 audits) | Sections 3.8 and 12.4; Appendix J |
| APSC principles for AI in recruitment (2026) | Section 13.2 |
Appendix GAgent specification template
Every AI component should be specified before it is built. This template captures the four cognitive fields and the governance bindings that make a component governable.
| Field | Define |
|---|---|
| Archetype | The single role this component plays (one power, one scope, one objective). |
| Signals | What it perceives, the sources, and how inputs are validated. |
| Constraints | Hard limits, the conditions under which it must escalate, and what it is forbidden to do. |
| Goals | What it optimises, the trade-offs, and how conflicts are resolved. |
| Feedback | How it is monitored and corrected, and how trust or autonomy adjusts. |
| Autonomy gate | The Go / Ask / Stop thresholds for its decision class. |
| Human participation | Which human role is involved, at which gate, with what authority. |
| Fallback | What happens when it cannot act safely; the safe default. |
| Governance bindings | The policy reference, provenance, and records it must carry. |
Appendix HGlossary
| Term | Meaning |
|---|---|
| Agentic AI | AI built from autonomous components that sense, decide and act within constraints. |
| Machine-perspective design | Specifying an AI system from how the machine perceives and decides, then re-introducing people as governed participants. |
| Accountable official | The single named officer accountable for AI strategy or for a use case, per Policy v2.0. |
| Agent passport | The bundle of data that travels with every AI action so it can be trusted and audited. |
| Assurance | Evidence-based confidence that an AI system is safe, lawful and fit for purpose. |
| Autonomy gate | The Go / Ask / Stop control that decides whether an AI may act, ask, or stop. |
| IRAP | The Infosec Registered Assessors Program, for independent security assessment. |
| Policy-as-code | Rules and thresholds expressed as versioned data the runtime enforces. |
| Provenance | The recorded lineage of data, models and decisions; the chain of custody. |
| Risk tier | The classification (low or high) that sets how much assurance a use case needs. |
Appendix ISources and influences
Our models, and the foundations they rest on
The models in this framework, the Governed Intelligence Model, the AI Autonomy Ladder, the AI capability stack, the decision passport, the two-plane account of agent roles, the autonomy gates and the runtime controls, are an original Renly synthesis. They rest on, and are deliberately consistent with, established public sources: the NIST AI Risk Management Framework (govern, map, measure, manage); ISO/IEC 42001 and ISO/IEC 23894; and the settled engineering canon of agent design, including the perceive-reason-act-observe control loop and the common agentic workflow patterns (such as routing, orchestration and evaluation).
Wider reading
We have read widely in the current agentic-AI literature in developing this framework, including the practitioner work of Jesper Lowgren on agentic design. Section 4 sets out what we judge that body of work gets right and where we have deliberately departed from it. Where individual ideas in the field are useful we have adopted them in our own terms; where they are unrigorous or ambiguous we have replaced them.
Australian Government instruments
- Department of Industry, Science and Resources, Australia’s AI Ethics Principles; National AI Plan (2 December 2025); Guidance for AI Adoption (AI6, October 2025); Australian AI Safety Institute.
- Digital Transformation Agency, Policy for the responsible use of AI in government (v2.0, effective 15 December 2025, obligations phasing in to 15 December 2026 and 30 April 2027); AI technical standard (31 July 2025) and its Agentic AI addendum (June 2026); AI Impact Assessment tool, AI procurement guidance, and guidance for taking AI from proof of concept to scale (2026); the central list of agency AI transparency statements.
- Department of Finance and the DTA, AI Plan for the Australian Public Service (November 2025): Chief AI Officers in every non-corporate entity, mandatory foundational AI training, and the GovAI platform and GovAI Chat.
- Data and Digital Ministers Meeting, National framework for the assurance of artificial intelligence in government (June 2024).
- Department of Home Affairs, Protective Security Policy Framework; Australian Signals Directorate and the ACSC, Information Security Manual (including its AI controls, expanded from December 2025), the Essential Eight (with a proposed evolution into an Essentials series under consultation from June 2026), Secure by Design, and IRAP; ASD and international partners, Engaging with Artificial Intelligence (2024), Deploying AI Systems Securely (2024), AI Data Security (2025) and Careful Adoption of Agentic AI Services (May 2026, written with international partners); Department of Finance, Hosting Certification Framework and Commonwealth Procurement Rules.
- Office of the Australian Information Commissioner, Privacy Act and Australian Privacy Principles; OAIC guidance on privacy and commercially available AI products, and on developing and training generative AI models (2024); Privacy and Other Legislation Amendment Act 2024 (automated decision-making transparency, from 10 December 2026); National Archives of Australia, Archives Act.
- Scrutiny and better practice: Australian National Audit Office, Governance of Artificial Intelligence at the Australian Taxation Office (No. 26 of 2024-25) and Artificial Intelligence Use in IP Australia (No. 43 of 2025-26); Joint Committee of Public Accounts and Audit, Proceed with Caution (2025); Commonwealth Ombudsman, OAIC and Attorney-General’s Department, Automated Decision Making Better Practice Guide (March 2025); Australian Public Service Commission, principles for the use of AI in recruitment (2026).
- Royal Commission into the Robodebt Scheme, Report (2023); international standards ISO/IEC 42001 (adopted as AS ISO/IEC 42001:2023), ISO/IEC 23894, ISO/IEC 38507 (governance implications of AI) and ISO/IEC 42005 (AI system impact assessment), and the NIST AI Risk Management Framework with its Generative AI Profile, referenced for alignment.
Appendix JThe executive quarterly agenda
A standing agenda for the executive’s AI item, drawn from Section 12. It is designed to run in forty-five minutes on evidence generated by the framework, not on papers written for the meeting.
| Standing item | What the executive reviews | Source |
|---|---|---|
| 1 The dashboard | Register coverage, assessment currency, gate outcomes, incidents and near misses, override and drift trends, benefits against claims. | Section 12.3 |
| 2 Exceptions | Every incident and near miss since last quarter, the post-incident actions closed and open, and what changed because of them. | Section 13.5; Appendix K |
| 3 Gate decisions | What passed, what passed with conditions, what was stopped, and whether conditions are being discharged on time. | Section 10 |
| 4 The five questions | One standing question per domain, answered with evidence, with warning signs called out honestly. | Section 12.2 |
| 5 Forward look | Use cases entering intake; upcoming mandate deadlines; capability and training coverage; the next quarter’s deep dive. | Sections 5 and 11 |
| 6 Annual items | Risk-appetite refresh; transparency statement review; framework review; independent assurance plan. | Sections 5, 9 and 14 |
- Circulate the dashboard forty-eight hours ahead; spend the meeting on exceptions and decisions, not on walking through it.
- Take one deep dive per quarter: a single use case walked end to end against the lifecycle, chosen by risk, not by convenience.
- Minute decisions and named owners, not discussion. The minutes are themselves evidence at audit.
- Once a year, put the framework itself on the agenda: what the assurance loop has learned, and what should change.
Appendix KAI incident response runbook (skeleton)
A starting structure for the response path in Section 13.5, ready to adapt to the agency’s existing incident management. The severities, roles and notifications should be agreed before they are needed; the first hour of an incident is a bad time to design a process.
| Severity | Looks like | Response posture |
|---|---|---|
| S1 Critical | Unlawful or harmful decisions acted on at scale; compromise of classified data or a production model; public-safety impact. | Halt now via kill switch; accountable authority and minister’s office briefed same day; external notifications as mapped below. |
| S2 Major | Material harm to individuals or the agency; sustained behaviour outside tolerance; privacy breach under assessment. | Halt or constrain; accountable official engaged within hours; committee convened out of cycle. |
| S3 Minor | Contained errors caught quickly; no lasting harm; tolerance breached briefly. | Constrain or monitor; log, fix and review at the next committee. |
| Near miss | A gate, an override or good luck caught it before harm. | No halt required; record it, tag the control that caught it, review monthly for patterns. |
| Role | In an AI incident |
|---|---|
| Incident owner (use-case accountable official) | Runs the response, owns decisions and the record, briefs upward. |
| Security / CISO | Cyber containment, forensics, ASD and ACSC reporting where cyber-related. |
| Privacy officer | Notifiable data breach assessment and OAIC engagement where personal information is involved. |
| Legal | Lawfulness of decisions made, exposure, and advice on remediation for affected people. |
| Records | Preservation of logs, decision passports and model versions as Commonwealth records. |
| Communications | Public, ministerial and internal lines, prepared from the incident record. |
| AI Governance Committee | Out-of-cycle decisions, acceptance of the post-incident review, closure of actions. |
The first hour
- Pause or constrain the system: kill switch or rollback, per Section 10.4. Reversibility means this is always safe to do.
- Preserve the evidence: logs, decision passports, prompts, model and policy versions, as they were.
- Open the incident record and name the incident owner.
- Make the first severity and scope call: what acted, on whom, since when.
- Brief the accountable official, and the accountable authority for anything that could be S1.
- Begin the notification assessment: privacy, cyber, affected people, the minister, and the DTA where the policy requires notice (for example, a high-risk use case).
- Timestamp every step; the timeline is the first thing every reviewer will ask for.
| Trigger | Notify | Under |
|---|---|---|
| Privacy breach likely to cause serious harm | OAIC and affected individuals | Notifiable Data Breaches scheme |
| Cyber incident involving the AI or its data | ASD / ACSC (ReportCyber); PSPF reporting as applicable | ISM; PSPF |
| Decisions affecting people were wrong or unlawful | Affected people, with a review path; Ombudsman as appropriate; legal advice on remediation | ADM better practice; administrative law |
| Significant or public incident | Minister’s office; the governance body that oversees AI incidents; the DTA where a high-risk use case is affected | Policy v2.0 |
The post-incident review closes the loop: the timeline; the root cause, distinguished from the symptom; the control that failed or was missing; what the dashboard showed and when; the changes made to the register, the risk tier, policy-as-code and training; and the lessons shared through the Chief AI Officer network. An incident the agency learns from publicly is a governance credential; one it buries is a liability with interest.
Appendix LAdoption self-assessment
Twenty questions that locate an agency against the framework. Score each 0 (no), 1 (partly) or 2 (yes, and we could show an auditor); the total points to the roadmap horizon of Section 11 the agency should start from. Honest scoring is the entire value; the assessment is for the agency, not for show.
| Domain | Questions |
|---|---|
| Strategy |
|
| Operating Model |
|
| Architecture |
|
| Design |
|
| Governance |
|
| Score | Start at | Focus |
|---|---|---|
| 0 to 13 | Horizon 1: mobilise and comply | Name the owners, stand up the committee, open the register, adopt the framework. |
| 14 to 27 | Horizon 2: operationalise and assure | Embed the lifecycle and gates, harden the foundation, publish transparency, build capability. |
| 28 to 40 | Horizon 3: scale with confidence | Cross the supervision threshold deliberately, add simulation, extend policy-as-code, seek independent assurance. |
This document is thought leadership prepared by Renly and is provided as a reusable framework for adaptation by government clients. It does not constitute legal advice. Agencies should confirm current obligations against the source instruments, which may have been updated since the date of this version.
Facts checked against official sources on 7 October 2026. Confirm obligations against the source instruments, which can change. This framework is not legal advice.