Library · Data Practice OS
AI use case intake and risk triage
Template · Published · Source reviewed
Every AI use case gets one of these before build. It follows the shape of a government AI risk assessment, using one state's Foundational AI Risk Assessment (FAIRA) as the worked example, and triggers a Privacy impact assessment where personal information is involved. This template is a front door, not a replacement for the assessment your AI policy mandates. For example, one state's AI governance policy (v2.0.0, effective August 2026) requires a FAIRA, or an agreed equivalent, for AI solutions, and allows a FAIRA LITE for low-risk use cases, including proofs of concept and trials. Use your official assessment (for example the FAIRA framework (v2.0.0, effective September 2026)) and attach it to this intake. That policy also requires AI governance arrangements that have regard to ISO 38507; enterprises can use ISO/IEC 42001 or the NIST AI RMF in the same role.
Part A: describe it (the requester fills in)
| Field | Answer |
|---|---|
| Use case id | AI-YYYY-NNN (assigned by the AI governance group) |
| Name | |
| Business owner (accountable officer) | |
| Problem being solved | |
| Who uses it | staff / public / partners |
| What it produces | summary / classification / extraction / answer / action / decision support |
| Does any output affect a decision about a person (licence, permit, penalty, eligibility)? | Y/N |
| Data products used | links to canvases (Data product canvas) |
| Highest data classification | OFFICIAL / SENSITIVE / PROTECTED |
| Personal information involved? | Y/N; categories |
| Proposed pattern | RAG / text-to-SQL / LLM in pipeline / agent / ML model (AI-native patterns) |
| Proposed platform and model route | per ADR-005: Governed model access through an AI gateway |
| Success measure |
Part B: triage (AI governance group)
Score each from 1 (low) to 3 (high).
| Dimension | 1 | 2 | 3 | Score |
|---|---|---|---|---|
| Impact on people | Internal productivity only | Advice to staff who decide | Direct effect on a member of the public | |
| Autonomy | Human reviews every output | Human reviews samples | Acts without review | |
| Data sensitivity | Public / OFFICIAL, no PI | OFFICIAL with PI | SENSITIVE or above | |
| Transparency need | Internal draft text | Internal record | Public-facing or affects rights | |
| Reversibility | Easily corrected | Correctable with effort | Hard to reverse | |
| Novelty | Proven pattern in most organisations | New pattern, known tools | New pattern and new tools |
Total 6-9: low (standard controls, FAIRA LITE). 10-13: medium (FAIRA assessment, named reviewer, evaluation gate). 14-18: high (full FAIRA, PIA, executive sign-off, staged rollout). Any output affecting a decision about a person is at least medium whatever the total.
Part C: controls checklist
| Control | Required at | Done |
|---|---|---|
| Data products used are AI-approved, and excluded columns are honoured | all | [ ] |
Model routing pinned to Australia (Snowflake AWS_AU, Bedrock au. profile, Databricks cross-geo off); wider routing only if approved for OFFICIAL, non-personal data |
all | [ ] |
| Calls go through the gateway with use case id logging (AI gateway) | all | [ ] |
| Guardrails configured: PII redaction, topic limits, output validation | all | [ ] |
| Evaluation set with pass threshold, run before release (Evaluating AI systems) | all | [ ] |
| FAIRA assessment completed (current version) | medium+ | [ ] |
| Privacy impact assessment completed under the applicable privacy principles | any PI | [ ] |
| Human in the loop defined: who reviews, when, and how they override | medium+ | [ ] |
| Users told they are using AI; outputs labelled | public or rights-affecting | [ ] |
| Monitoring: quality drift, cost, incident route | all | [ ] |
| Executive sign-off | high | [ ] |
| Review date set (at most 12 months) | all | [ ] |
Part D: decision
| Field | Value |
|---|---|
| Risk rating | low / medium / high |
| Decision | approved / approved with conditions / not approved |
| Conditions | |
| Approver and date | |
| Next review |
Part E: readiness scope, decision impact and AI permission
From the source draft AI-Ready Data and Context Lifecycle (revised 4 Nov 2026). Proposed practice, not an agreed decision. These fields scope the AI readiness assessment, which is scored in AI readiness scorecard (workbook v2).
Assessment scope. Readiness applies to this scope and version only.
| Field | Answer |
|---|---|
| Named AI use and business process | |
| Scope version | |
| Boundary: systems, tables, documents, external services and derived assets in scope (including sources outside the platform) | |
| Exclusions and inaccessible systems | |
| Tier 1 dependencies (failure compromises the outcome or a mandatory control) | |
| Required context per decision: facts, definitions, rule versions, process state, approval authority, with source, freshness limit and fallback | link to the context map |
| Acceptance thresholds: quality, freshness, task performance, access isolation | |
| Business owner, data owner, approval authority | |
| Obligations: licensing, contractual, privacy, jurisdictional | |
| Evidence plan: sampling, observation period, access to logs, policies and content | |
| Use profiles in scope | analytics / ML / RAG / training / decision support and actions |
Decision impact. Higher impact needs stronger evidence and approval thresholds, even for unclassified public data.
| Field | Answer |
|---|---|
| Who relies on the output | officer / member of the public / partner / downstream system |
| Consequences of an error | |
| Reversibility | easily corrected / correctable with effort / hard to reverse |
| Human review | who reviews, at which step, and with what authority to override (Human in the loop) |
| Permissions needed | read / recommend / approve / execute (each separately) |
| Autonomous action? | Y/N. If Y, a separate system-level assessment is also needed |
AI-permission record. One per dataset or knowledge source used. Copy the table. Classification alone never grants AI use (AI-permission record, Governance, security and trust).
| Field | Value |
|---|---|
| Dataset or source | |
| Classification (mandated scheme) | OFFICIAL / OFFICIAL: Sensitive / PROTECTED |
| Privacy tags | personal / health / payment / employee / legal privilege / none |
| Allowed purposes | |
| Approved services and environments | |
| Redaction requirements | |
| Training restrictions | training and fine-tuning permitted / prohibited |
| Approver | |
| Basis | PIA / FAIRA / contract / licence / other |
| Review date | |
| Status | approved / prohibited / not assessed |
Agent-era fields (from AI options papers)
| Field | Answer |
|---|---|
| Consumer channel | Copilot Studio / Claude Code / web app / other |
| MCP tools used, and where each is hosted | |
| Identity mode at each hop (client to gateway to server to store) | |
| Knowledge sources, and the reason for any derived copy (Derived index) | |
| Memory: none / individual / team, with retention (Agent memory) | |
| Embedded model calls in managed services, with region confirmed | |
| New cloud services that need approval |
Controls to confirm: no general query tool, an audit log carrying the actor ID, memory retention set, and provenance fields in every tool result.
Source links: Data Practice reading list.