AI Risk Management Policy

Document control

1. Purpose

This Policy sets the minimum requirements for governing and managing the risks of artificial intelligence (AI) across [Organisation]. It ensures that:

2. Scope

This Policy applies to:

3. Key definitions

4. Principles

[Organisation]'s principles are consistent with Australia's AI Ethics Principles, the 6 essential practices in the Australian Government's Guidance for AI Adoption (October 2025) and the international standards referenced in section 23.

5. Three lines of accountability

6. Roles and responsibilities

7. AI use-case register

• Every AI use case must be recorded in the [AI register] before development, procurement or use starts, including pilots, proofs of concept and AI features enabled in existing vendor software. Appendix C sets the minimum fields.
• The register is the single source of truth for AI use at [Organisation]. It records AI tooling (platforms, models and products) and AI use cases, and links each to its owner, tier, risks, controls, vendors, approvals and incidents.
• AI owners keep their entries accurate and review them at least [annually] for Low tier, [half-yearly] for Medium tier and [quarterly] for High tier, and whenever the use case changes.
• Procurement, technology change, privacy impact assessment and third-party onboarding processes must check that any AI use is registered before they approve.
• Second line tests the register for completeness at least [annually], for example by comparing it with software inventories, vendor contracts, cloud AI service usage and network logs for public AI tools.

8. Risk tiering of AI use cases

8.1 How to tier

The AI owner tiers each use case when it is registered, using the matrix in Appendix A, and second line reviews the tier. The tier sets the controls, approvals and oversight required (section 9). Tier on the highest criterion met. Re-tier whenever the use case, data, autonomy or vendor changes.

8.2 Factors that raise the tier

• Customer impact: the use case makes or substantially informs a decision that could significantly affect a person's rights or interests, such as access to credit, insurance, claims, superannuation benefits, pricing or account restrictions.
• Vulnerable customers: the use case targets, identifies or is likely to affect customers experiencing vulnerability.
• Autonomy: the AI acts without a human approving each action, or can act in production systems (agentic AI).
• Data sensitivity: the use case uses sensitive information (Privacy Act s6), health, biometric, children's, or large volumes of personal information, or confidential information.
• Opacity: the outputs cannot be explained to the level needed for the decision, or the vendor does not provide enough information to assess the model.
• Scale and speed: many customers or transactions affected before a human could notice an error.
• Critical operations: the use case supports a critical operation under CPS 230 or a material service provider arrangement.
• Regulatory sensitivity: the use case touches a regulated activity such as personal advice, credit assessment, design and distribution, AML/CTF, claims handling or complaints.

8.3 Prohibited use cases

[Organisation] must not use AI to:

9. Controls by tier

10. Lifecycle controls

These controls apply across the AI lifecycle. They reflect APRA's expectation of clear ownership and accountability "from design and development through to deployment, monitoring and decommissioning" (APRA letter, 30 April 2026), the lifecycle approach of ISO/IEC 42001 and ISO/IEC 23894, and the NIST AI RMF functions (Govern, Map, Measure, Manage).

10.1 Design and impact assessment

• Define the business purpose, the decision or task, the intended users, the people affected, and what success and failure look like.
• Consider whether AI is the right tool, and whether a simpler, more explainable method would do.
• Complete an AI impact assessment proportionate to the tier, covering customer outcomes, fairness, vulnerable customers, privacy, security, legal and regulatory obligations, explainability, human oversight, third-party dependence and operational resilience. ISO/IEC 42005:2025 gives guidance on AI system impact assessment.
• Engage the people who will use the system and, for High tier, those likely to be affected or their representatives (for example customer advocates), consistent with guardrail 10 of the Voluntary AI Safety Standard.
• Set measurable acceptance criteria for accuracy, fairness, robustness and, for generative AI, groundedness and harmful-output rates, before building or buying.

10.2 Data

• Use data that is fit for purpose, lawfully obtained and permitted for the use (section 14), with documented source, lineage and quality checks.
• Assess training and reference data for gaps, errors and historical bias, including under-representation of customer groups.
• Minimise personal information; de-identify where practical; never use production personal information in development or testing without approval.
• For retrieval-augmented generative AI, control which documents the AI can access and ensure access permissions follow the user's own permissions.
• Apply the [Data Governance Policy]. APRA's CPG 235 Managing Data Risk is relevant guidance for APRA-regulated entities.

10.3 Development (built AI)

• Develop in controlled environments with version control for code, data, prompts, model parameters and configurations.
• Document the model or system: purpose, design, data, assumptions, limitations, known risks, testing results and intended use (for example a model card).
• Build in human oversight, logging, explainability and a way to switch off or fall back to a manual or non-AI process.

10.4 Procurement (bought AI)

Bought AI follows the same tiering and lifecycle as built AI. In addition, section 12 applies. Before buying, the AI owner and model owner must obtain enough information from the vendor to assess the model's purpose, training data sources, testing (including fairness and safety), known limitations, security, data handling and update practices. If the vendor cannot provide enough information for the tier, the use case must be re-tiered, redesigned or not used.

10.5 Validation and testing

• Test against the acceptance criteria before deployment, in conditions close to real use, and record the results.
• Performance: accuracy, stability and robustness, including on edge cases and stressed or unusual inputs.
• Fairness and bias: compare outcomes and error rates across customer groups, including groups protected by anti-discrimination law and vulnerable customers, using appropriate fairness measures and proxies where attributes are not held. Investigate and treat material differences before use.
• Explainability: confirm that outputs can be explained to the level the decision and the customer need (section 14).
• Generative AI: test for hallucination, groundedness in approved sources, harmful or inappropriate content, leakage of confidential information, and consistency. Carry out red-teaming (structured adversarial testing, including prompt injection and jailbreak attempts) for all customer-facing and High tier generative AI. NIST AI 600-1 Generative AI Profile describes generative AI risks and suggested actions.
• Agentic AI: test the limits on what the agent can do, its behaviour when tools fail or return unexpected results, its resistance to manipulation, and that it stops and escalates when it should.
• Independent validation: for High tier, a validator independent of development reviews the design, data, testing and limitations, and can require changes before approval.
• Testing evidence, issues found and their treatment are recorded. Failed criteria must be fixed, or the risk formally accepted under the RiskFA Incident & Issues Management Standard, before approval.

10.6 Approval and deployment

• Approvals follow section 9. The approver confirms that the impact assessment, testing, validation, privacy, security, vendor, transparency and oversight requirements are complete, using the checklist in Appendix B.
• Approval records the approved purpose, scope, conditions, limits and the monitoring thresholds. Use outside the approved purpose is a new use case.
• Deployment follows the [Change Management Standard], with a tested rollback or switch-off and, for High tier, a staged release (for example a pilot or shadow run) where practical.

10.7 Monitoring

• AI owners monitor every deployed use case against the thresholds set at approval, including performance, drift, fairness, error and override rates, complaints, and, for generative AI, hallucination and harmful-output rates sampled by human review.
• Monitoring for High tier use cases is ongoing and automated where practical, with alerts to the model owner when a threshold is breached.
• A threshold breach is recorded and acted on: investigate, then retrain, recalibrate, restrict, add human review, or switch off. A breach that has caused or could cause harm is an AI incident (section 17).
• Human reviewers' overrides and customer complaints about AI outputs are analysed for patterns.

10.8 Change

• Material changes need re-assessment and re-approval at the use case's tier. Material changes include new purpose or users, new data sources, retraining, a new model or model version, changes to prompts or guardrails that affect outputs, increased autonomy, and vendor model updates.
• Contracts and monitoring must allow [Organisation] to know when a vendor changes or updates a model (section 12).
• Self-learning models that update in production are High tier unless second line agrees otherwise, and need limits and monitoring on what may change.

10.9 Periodic review and decommissioning

• Each use case is reviewed at the frequency in section 9 to confirm it is still needed, performing, fair, compliant and within its approved purpose.
• When an AI system is retired, the AI owner ensures a controlled transition (including to any replacement or manual process), removes access and integrations, deals with data, prompts and logs under the [Records Management Policy], and updates the register.

11. Human oversight

• Each use case has a documented human oversight model (human in the loop, on the loop, or in command) suited to its tier and the decisions it supports.
• High-risk decisions require human involvement and accountability (APRA letter, 30 April 2026). For High tier use cases that make or substantially inform decisions to decline, restrict or price credit, insurance, claims or benefits, a competent person must be able to review and change the outcome before or promptly after it takes effect, and must do so where the customer asks (section 14).
• Human reviewers must have the time, training, information and authority to disagree with the AI. Monitoring of override rates helps detect rubber-stamping (automation bias).
• AI agents must operate within defined permissions, transaction and action limits, with logging of every action and a way to stop them immediately. Actions that are irreversible, high value or customer-affecting require human approval unless the AI Risk Committee approves otherwise.
• Every AI system has a documented fallback (manual process or alternative system) that has been tested, so that an AI system can be switched off without disrupting critical operations.

12. Third-party and vendor AI

[Organisation] remains responsible for outcomes when it uses AI provided by a third party. ASIC notes that licensees remain responsible for outsourced functions (REP 798, p 34). For APRA-regulated entities, CPS 230 requires the management of risks from service providers, including material service providers, and APRA expects entities to understand and manage AI supply-chain and concentration risk (APRA letter, 30 April 2026).

13. Security of AI systems

AI systems are information assets and are protected under the RiskFA Cyber Security Policy and, for APRA-regulated entities, CPS 234. APRA has observed that AI adoption is materially changing the cyber threat landscape, including prompt injection, data leakage, insecure integrations and the manipulation or misuse of autonomous AI agents, and that identity and access management needs to adjust for non-human AI actors (APRA letter, 30 April 2026). ASIC has called for urgent uplift of cyber resilience fundamentals as frontier AI accelerates cyber threats (ASIC open letter, 8 May 2026).

14. Privacy, data and customer transparency

14.1 Privacy

The Privacy Act 1988 and the Australian Privacy Principles (APPs) apply to personal information put into an AI system and to personal information it generates or infers. The OAIC's guidance on privacy and the use of commercially available AI products, and on privacy and developing and training generative AI models (both 21 October 2024), sets out how the APPs apply. In particular:

14.2 Automated decisions in the privacy policy (from 10 December 2026)

From 10 December 2026, APP 1.7 to 1.9 (inserted by the Privacy and Other Legislation Amendment Act 2024) require an APP entity's privacy policy to include information where it has arranged for a computer program to make, or do a thing substantially and directly related to making, a decision that could reasonably be expected to significantly affect an individual's rights or interests, using personal information about the individual. The privacy policy must describe the kinds of personal information used, the kinds of such decisions made solely by computer programs, and the kinds of decisions for which a computer program does a thing substantially and directly related to making the decision (APP 1.8).

14.3 Customer transparency, explanation and contestability

• Tell customers when they are interacting with an AI system (for example a chatbot), and when content they receive is substantially AI-generated, consistent with guardrail 6 of the Voluntary AI Safety Standard.
• Where AI makes or substantially informs a decision that significantly affects a customer, the customer must be told that AI was used, given the main reasons for the decision on request in plain language, and told how to ask for a human review.
• Customers must be able to reach a human. AI-supported decisions remain subject to the RiskFA Complaints Handling Policy, internal dispute resolution under ASIC RG 271 and external dispute resolution through AFCA.
• Statements to customers, the market and regulators about AI use, model performance and outputs must be accurate. ASIC notes that licensees must not make false or misleading representations, including about their AI use, model performance and outputs, and must ensure AI-generated representations are not false or misleading (REP 798, p 34; ASIC Act Part 2 Div 2).

14.4 Fairness, discrimination and product obligations

• Anti-discrimination laws (including the Racial Discrimination Act 1975, Sex Discrimination Act 1984, Disability Discrimination Act 1992 and Age Discrimination Act 2004, and state and territory laws) apply to decisions made or informed by AI, including indirect discrimination through proxies.
• AFS and credit licensees must provide services efficiently, honestly and fairly. ASIC has said licensees should consider whether AI brings risks of unfairly biased or discriminatory treatment, or leaves them unable to explain outcomes, and must ensure AI is not used to act unconscionably or to exploit consumer vulnerabilities or behavioural biases (REP 798, p 34).
• Where AI is used in product design, target market determination, distribution, marketing or eligibility, the design and distribution obligations (Corporations Act 2001 Part 7.8A; ASIC RG 274) continue to apply. AI-driven distribution must stay consistent with the target market determination.

15. Staff use of generative AI tools

• Staff may use for work only the generative AI tools listed as approved in the [Approved AI Tools List], within the data classifications approved for each tool.
• Public, consumer or personal-account generative AI tools must not be used with personal, sensitive, confidential, customer or [Organisation] proprietary information. APRA has raised concern about staff use of enterprise AI tools outside approved control frameworks (APRA letter, 30 April 2026).
• Staff remain responsible for any work they produce with AI. Outputs must be checked for accuracy, completeness and suitability before use, and must never be sent to customers without the review required for the use case.
• New business uses of an approved tool that go beyond the approved purposes must be registered as a use case.
• Appendix D sets the acceptable use rules, which all staff must acknowledge [annually]. Breaches are managed under the [Code of Conduct] and the RiskFA Consequence Management Framework.

16. Operational resilience

• AI that supports a critical operation must be included in the CPS 230 business continuity plan, with tested fallback processes and tolerance levels that take the AI dependency into account.
• Business continuity, backup and disaster recovery arrangements must cover AI systems, models, prompts and configurations (ASIC REP 798, question 9).
• Scenario analysis should include the loss of a key AI provider, widespread model failure, and AI-enabled cyber attacks.

17. AI incidents and issues

• AI incidents, near misses and issues are recorded, rated, escalated, notified, investigated and remediated under the RiskFA Incident & Issues Management Standard, using its Critical, High, Medium and Low ratings. They are flagged as AI-related in the register and linked to the use case.
• Examples of AI incidents: biased or wrong customer decisions; a chatbot giving false product information; personal information disclosed through an AI output; a successful prompt injection; an AI agent taking an unauthorised action; a vendor model change that degrades performance.
• The AI owner must be able to restrict or switch off an AI system immediately when it is causing or could cause harm, and must do so for any Critical or High AI incident unless the CRO agrees otherwise.
• Every AI incident is assessed for regulatory notification (for example CPS 230, CPS 234, ASIC reportable situations and Notifiable Data Breaches) whatever its rating, as the RiskFA Incident & Issues Management Standard requires.
• Customers harmed by AI outcomes are remediated under the RiskFA Incident & Issues Management Standard and ASIC RG 277.
• Root cause analysis for AI incidents should consider data, model design, testing gaps, monitoring thresholds, human oversight, vendor change and use outside the approved purpose.

18. Risk appetite and key risk indicators

The Board's the RiskFA Risk Appetite Statement should set appetite for AI risk, for example no appetite for AI decisions that unfairly discriminate, low appetite for unexplainable High tier decisions, and the conditions under which agentic AI may act without human approval. Key risk indicators measure whether AI use stays within appetite. Controls are tested for design and operating effectiveness under the [Risk and Control Self-Assessment] process and are adjusted when monitoring, incidents or the threat environment show they are not working.

19. Reporting

Second line reports on AI risk to the [AI Risk Committee] [monthly] and to the Board Risk Committee [quarterly]. Reports cover at least:

20. Training and capability

• All staff complete AI acceptable use training at induction and [annually].
• AI owners, model owners, human reviewers and approvers complete role-specific training on this Policy, AI risks, limitations and their responsibilities before taking up the role.
• Directors and executives receive AI briefings at least [annually] so they can provide effective challenge, as APRA expects of boards.
• Second and third line staff who review AI must have the technical capability and tools to assess AI systems, including probabilistic models and agentic workflows (APRA letter, 30 April 2026), using specialists where needed.

21. Assurance

• Second line reviews a sample of Low and Medium tier registrations and approvals at least [half-yearly].
• Internal Audit reviews the design and effectiveness of this Policy, and the completeness of the AI register, at least every [2 years], and audits High tier use cases on a risk basis.
• [Organisation] may seek certification or independent assessment against ISO/IEC 42001:2023 Artificial intelligence management system. Certification is voluntary.

22. Compliance with this Policy and exemptions

Using AI that has not been registered, tiered or approved under this Policy, or using AI outside its approved purpose, is a breach of this Policy and is managed under the RiskFA Incident & Issues Management Standard and the RiskFA Consequence Management Framework, and considered in performance and remuneration outcomes under the RiskFA Remuneration Policy (CPS 511 where it applies). Exemptions need the written approval of the CRO, must be time-limited, and are reported to the Board Risk Committee. No exemption may permit a Prohibited use case.

23. Regulatory and standards context (as at October 2026)

24. Related documents

• the RiskFA Risk Management Framework, the RiskFA Risk Appetite Statement and the RiskFA Operational Risk Management Policy
• RiskFA Incident & Issues Management Standard
• the RiskFA Cyber Security Policy, [Privacy Policy], [Data Governance Policy] and [Records Management Policy]
• [Third-Party and Outsourcing Policy], [Change Management Standard] and [Model Risk Management Standard]
• the RiskFA Business Continuity Policy, the RiskFA Complaints Handling Policy, [Code of Conduct], the RiskFA Consequence Management Framework and the RiskFA Remuneration Policy
• APRA: letter to industry on AI (30 April 2026); CPS 220, CPS 230 and CPG 230, CPS 234 and CPG 234, CPG 235 Managing Data Risk
• ASIC: REP 798 Beware the gap: Governance arrangements in the face of AI innovation; RG 271 Internal dispute resolution; RG 274 Product design and distribution obligations; RG 277 Consumer remediation
• OAIC: Guidance on privacy and the use of commercially available AI products; Guidance on privacy and developing and training generative AI models; APP 1.7–1.9 Transparency Obligation Fact Sheet; APP Guidelines Chapter 1
• Department of Industry, Science and Resources: Voluntary AI Safety Standard; Guidance for AI Adoption; National AI Plan
• Standards: ISO/IEC 42001:2023, ISO/IEC 23894:2023, ISO/IEC 42005:2025, AS ISO 31000 Risk management; NIST AI RMF 1.0 and NIST AI 600-1

Appendix A. AI use-case risk tiering matrix

Answer each question. The use case takes the highest tier reached. Any Prohibited answer stops the use case.

Appendix B. Pre-deployment checklist

• Use case registered, with AI owner, model owner and tier recorded; tier reviewed by second line.
• AI impact assessment completed and reviewed at the level required for the tier.
• Privacy impact assessment completed where required; APP 1.7–1.9 scope decided and the privacy policy updated if in scope.
• Legal and Compliance review completed for customer-facing, advice, credit, insurance, claims, marketing or distribution use cases.
• Data sources, lineage, quality and permitted use documented; bias in data assessed.
• Security assessment completed, including AI-specific threats; identity and access set up for any AI agent.
• Testing against acceptance criteria completed and recorded, including fairness testing and, for generative AI, hallucination testing and red-teaming.
• Independent validation completed (High tier) and findings resolved or formally accepted.
• Vendor due diligence and contract terms completed; material service provider assessment done; supply chain recorded.
• Human oversight model documented; reviewers trained; fallback and switch-off tested.
• Customer disclosures, explanations and contestability process in place where required.
• Monitoring metrics, thresholds, alerts and owners set; review date set.
• Business continuity and rollback arrangements in place.
• Approval obtained at the level required by section 9, with conditions recorded.

Appendix C. AI register fields

Appendix D. Acceptable use rules for staff

1. Use approved tools only. Use only the AI tools on the [Approved AI Tools List], through your [Organisation] account.
2. Protect information. Never enter personal, sensitive, customer, confidential or [Organisation] proprietary information into a tool not approved for that information. If unsure, do not enter it.
3. You are responsible. Check AI outputs for accuracy, completeness, bias and suitability. AI can be confidently wrong.
4. Customers come first. Do not send AI-generated content to customers, or use it in a customer decision, unless the use case is approved and the required review is done.
5. Be open. Do not present AI-generated work as checked when it is not. Follow the rules on disclosing AI use to customers.
6. Respect others' rights. Do not use AI to create content that infringes copyright, impersonates a real person or misleads anyone.
7. Watch for manipulation. Treat instructions inside documents, emails or web pages processed by AI with suspicion, and be alert to deepfake voices, videos and messages, especially in payment or access requests.
8. Register new uses. Any new business use of AI, including AI features turned on in existing software, must be registered before use.
9. Report problems. Report AI incidents, near misses, unexpected outputs and suspected misuse to [your manager and the incident register] straight away.
10. When in doubt, ask [the AI Risk team / Risk and Compliance].