This template has been developed by Robbyverse Labs to support organisations across Australia in conducting a structured and evidence‑based review of their AI systems. It is a practical, fill‑in‑the‑blank tool that lays out a clear sequence of tasks and evidence requirements. Use it either as a stand‑alone checklist or as part of a broader governance programme.
1. Use‑Case Inventory
The first step is to map every AI system or model your organisation currently uses or plans to deploy. For each entry capture the business objective, scope, stakeholders and the data that drives the model. This table is the foundation on which all subsequent analysis is built.
| Use‑Case ID | Business Objective | Stakeholders | Data Sources | System Architecture | Current Deployment Stage |
|---|---|---|---|---|---|
Use‑Case ID: Assign a unique reference (e.g., UC‑01). Business Objective: Keep it short (one sentence). State what problem the AI solves. Stakeholders: List internal owners, end users and any external partners. Data Sources: Identify the types of data (structured, unstructured, sensor, third‑party). System Architecture: Add a high‑level diagram if possible (e.g., user interface → API gateway → model service → database). Current Deployment Stage: Test, pilot, production, or planned.
2. Accountable Owners
Governance hinges on clear accountability. This table assigns owners at both the organisational and technical level.
| Use‑Case ID | Organization Owner | Technical Owner | Decision Escalation Point |
|---|---|---|---|
Organization Owner: A senior executive responsible for outcomes. Technical Owner: A data scientist or engineering lead who manages the model. Decision Escalation Point: Who you call if the model fails or behaves unexpectedly.
3. Data Provenance & Privacy
AI systems are only as good as the data that feeds them. This table tracks provenance, source quality and privacy controls.
| Use‑Case ID | Data Provenance | Data Quality Metrics | Privacy Safeguards | Consent Status |
|---|---|---|---|---|
Data Provenance: Document where each data field originates. Data Quality Metrics: Record accuracy, completeness, timeliness. Privacy Safeguards: Anonymisation, encryption, access controls. Consent Status: Confirm that required consents are in place.
4. Risk & Impact Assessment
Identify and classify the risks associated with each AI system. This table is designed to surface risks early.
| Use‑Case ID | Risk Type | Likelihood | Impact | Mitigation Strategy |
|---|---|---|---|---|
Risk Type: Example: Data bias, model drift, security breach. Likelihood: Scale 1‑5. Impact: Scale 1‑5. Mitigation Strategy: Outline actions (e.g., audit, retraining, access review).
5. Human Oversight & Decision‑making
AI should augment human decision‑making, not replace it. Capture the oversight lifecycle here.
| Use‑Case ID | Decision Point | Human Reviewer | Review Frequency | Oversight Tool |
|---|---|---|---|---|
Decision Point: Stage of the process where a human intervenes. Human Reviewer: Name or role. Review Frequency: Every use, ad‑hoc, periodic. Oversight Tool: Checklist, audit logs, alert system.
6. Vendor Procurement Evidence
Document evidence that external vendors meet your internal AI risk appetite.
| Vendor | Product/Model | Due Diligence Completed | Compliance Certificates | Evidence URL |
|---|---|---|---|---|
Vendor: Company name. Product/Model: Exact model or software. Due Diligence Completed: Yes/No. Compliance Certificates: Record any third‑party reports. Evidence URL: Link to supporting documents.
7. Evaluation Tests & Validation
Every AI model should pass a suite of tests before it is released to production.
| Use‑Case ID | Test Type | Test Outcome | Pass/Fail | Notes |
|---|---|---|---|---|
Test Type: Functional, performance, bias, robustness. Test Outcome: Results with metrics. Pass/Fail: Manual flag. Notes: Any observations or required retests.
8. Incident Escalation & Review
AI can produce unexpected outcomes. This table sets the escalation path and review cadence.
| Use‑Case ID | Incident Definition | Escalation Path | Review Date | Next Review Date |
|---|---|---|---|---|
Incident Definition: Define what qualifies as an incident. Escalation Path: Who gets notified and how. Review Date: Last review of the incident response. Next Review Date: When to revisit.
9. Evidence Register
An evidential audit trail strengthens accountability. Record every source that verifies a risk assessment or mitigation.
| Use‑Case ID | Source URL | Owner | Date | Unresolved Question |
|---|---|---|---|---|
How to Use
- Populate the register as you collect evidence: audit logs, interview notes, third‑party reports.
- The Unresolved Question column is a reminder of any gaps that need addressing before moving to the next stage.
Illustrative example: proposed internal support assistant
This hypothetical planning example is an original process suggestion, not a client project or a completed evaluation. An organisation is considering an assistant that suggests answers from an approved internal knowledge base. Its proposed objective is to help staff locate relevant information. No supplier has been selected, no live data has been approved and no benefit, security finding or test result has been measured.
| Field | Proposed entry | Evidence status |
|---|---|---|
| Use case | Internal knowledge-base assistant | Scope requires owner confirmation |
| Accountable owner | Service owner role, person to be assigned | Not yet assigned |
| Data provenance | Approved documents only, inventory to be prepared | Access and retention review pending |
| Human oversight | Staff review suggestions before acting | Procedure to be tested |
| Procurement | Record official supplier documentation if a vendor is chosen | Supplier not selected |
| Evaluation | Plan tests for unsupported answers and inappropriate disclosure | Not run; results unknown |
| Escalation | Stop the pilot and contact the accountable owner on an unsafe response | Escalation route to be agreed |
| Review date | Set before any pilot begins | Date not yet agreed |
The next decision is whether sufficient information exists to design a safe, limited pilot, not whether the system has passed. Owners should document unresolved questions in the evidence register and decide who can answer each one. Proposed controls remain proposals until evidence establishes they work. Do not replace unknown cells with assumed passes, invented suppliers or fictional results.
Working with missing and changing evidence
For every entry, distinguish a suggestion, a documented fact and an unresolved question. If a document is unavailable, record that explicitly together with an owner and a follow-up date. A completed-looking table is less useful than an honest account of what still needs verification. Keep the evidence register separate from informal impressions and link each decision to the information available at that time.
Choose test conditions and acceptance criteria before testing, with input from the people affected by the proposed system. Record the test version, environment, responsible person and limitations alongside actual results. A result from one test case cannot establish general safety. Review the assessment when the model, data, vendor, access rules or use case changes, and retain the earlier version so reviewers can understand why a decision changed.
Treat this template as an original organisational working aid. These suggested practices are not externally certified requirements, a legal interpretation or proof that a particular control is effective. Seek appropriate qualified advice for obligations that apply to the organisation and leave those conclusions outside this template until they are supported.
How to Use This Template
- Download the Markdown file.
- Populate each table, ensuring every cell is filled – blank cells are not acceptable substitutes for evidence.
- Review cells with qualified business or technical owners to verify accuracy.
- Store the Markdown file in your governance repository and link it to your continuous improvement workflow.
- Update each table on the required cadence (e.g., quarterly reviews, post‑incident reviews).
This template is not legal advice, nor is it certification or proof of compliance. It is a practical tool to assist organisations in building robust AI governance.
Next Steps
If your organisation needs help tailoring this template to your specific context or you require a deeper audit of your AI systems, Robbyverse Labs can provide dedicated consulting services. Contact us via the link below to schedule a brief assessment.