This pillar requires access
Pillars 02–06 are available with the full AI6 Guidance — Compliance App. Purchase access or enter your password below.
Treat AI as a material business risk — the same way you treat safety, cyber, and contractual risk. Document your risk appetite, assess every system, and maintain controls that are reviewed and updated as systems evolve.
AI risk is not IT risk. An AI system that drifts algorithmically — producing outputs that were accurate at deployment but become unreliable over time — is a business risk, not a technical failure. This pillar requires you to treat AI as a material hazard with its own risk categories, its own risk register, and its own escalation protocols.
The AI Risk Triage System is the starting point. Before any system goes live, it must be categorised: is the risk unacceptable (do not deploy), high (deploy with significant controls), medium (deploy with standard controls), or low? That categorisation drives the level of oversight, testing, and monitoring the system receives.
Third-party and supply chain risks must be actively managed. Using an AI model built by a vendor, or embedded in commercial off-the-shelf software, does not transfer your risk to the vendor. As the deployer, you remain accountable for the outcomes that AI system produces in your operational context.
Your estimating platform uses a machine-learning model to forecast labour and material rates. The model was trained on project data from 2020–2022. By mid-2025, input cost inflation has diverged significantly from the model's baseline. The AI continues to generate rates with high apparent confidence. Without a documented risk assessment, a monitoring framework, and a scheduled model review, your organisation submits competitive tenders using systematically incorrect cost data — with no paper trail to establish when the problem was first identifiable.
A widely-used project management platform integrates an AI feature built on a third-party model. A known prompt-injection vulnerability in the underlying model is disclosed publicly. Your organisation has no documented third-party AI risk assessment, no monitoring of vendor security advisories, and no incident response pathway for AI-related cyber events. The principal asks for your AI risk management documentation. It does not exist.
The AI Risk Triage System categorises every AI use case before deployment. The classification drives the required level of controls, testing, and oversight.
| Risk level | Definition | Heavy industry examples | Required response |
|---|---|---|---|
| Unacceptable | Potential for catastrophic, irreversible harm. Risk cannot be adequately mitigated. | Fully autonomous safety-critical decision-making on a live site with no human review | Do not deploy. Document the decision and rationale. |
| High | Significant potential for harm to people, operations, or legal standing. Substantial controls required. | AI-assisted worker performance monitoring; AI-generated tender pricing; automated fatigue management decisions | Deploy only with formal risk assessment, documented controls, human oversight protocol, and independent review. |
| Medium | Moderate potential for harm. Standard controls and monitoring are sufficient. | AI-assisted document drafting; AI-powered search and retrieval; automated meeting summaries | Deploy with documented risk assessment, standard controls, and periodic monitoring. |
| Low | Minimal potential for harm. Outputs are reviewed by humans before use. | AI grammar and spell-check tools; AI-assisted image labelling for non-critical assets | Deploy with basic documentation and awareness training for users. |
AI risk management requires coordination between Risk, IT, Cyber, legal and business unit functions. Use this matrix to assign and document ownership.
| Function / Activity | Executive / Board | Risk Management | IT & Cyber Security | Business Unit Operations | Legal & Compliance |
|---|---|---|---|---|---|
| Risk appetite setting | A | R | C | C | C |
| AI system risk assessment | I | A | R | C | C |
| Risk register maintenance | I | A | C | R | I |
| Incident reporting & escalation | A | R | C | I | C |
| Third-party & vendor risk management | I | A | C | R | C |
These four artefacts form the minimum documentation set for Pillar 03 compliance. They must be system-specific, version-controlled, and regularly reviewed.
A structured matrix for categorising every AI tool as unacceptable, high, medium, or low risk based on context, consequence, and stakeholder exposure. Must be completed before any new AI system is deployed and reviewed when the system changes or the operational context changes.
An extension of the enterprise risk register that includes AI-specific threat categories: algorithmic drift, data poisoning, vendor dependency, cyber exposure through AI interfaces, IP contamination in generative AI outputs, and privacy breach via training data. Reviewed and updated at defined intervals — quarterly at minimum for high-risk systems.
Documented protocols for how your organisation detects, classifies, contains, and reports AI-related failures. Must include a severity classification framework, escalation thresholds, and reporting obligations to relevant regulators (OAIC for privacy breaches, sector regulators for safety-critical failures). Response timeframes must be specified for each severity class.
A structured assessment of every vendor-provided or open-source AI model in use, covering: vendor security and privacy practices, known model vulnerabilities, data handling and residency obligations, contractual liability allocation, and the process for monitoring vendor advisories and security disclosures. Must be completed before vendor onboarding and reviewed annually.
Your progress is saved automatically between sessions. Print this page to include your checklist status in a compliance submission.
Tick each item when you have the required documentation in place.
These are the findings that appear most frequently when heavy industry contractors are assessed against Pillar 03.
Organisations file AI-related risks under the general IT risk category in their enterprise risk register. This obscures the specific nature of AI hazards — algorithmic drift, training data bias, model hallucination — and means they are assessed and reviewed using IT risk frameworks that are not fit for purpose. AI risk must have its own category, its own taxonomy, and its own review cadence.
Organisations have an enterprise risk appetite statement that does not mention AI. When an auditor asks what risks the organisation will and will not accept in its AI use, there is no documented answer. This is not a minor documentation gap — it means every AI deployment decision was made without an approved governance framework to validate it against.
Contractors assume that software procured from a reputable vendor is safe. They do not conduct their own assessment of the AI components embedded in that software. This is an incorrect assumption: the deployer is accountable for the outcomes produced in their operational context, regardless of who built the underlying model. Vendor trustworthiness does not transfer accountability.
Organisations have IT incident response plans and HSEQ incident investigation procedures. Neither covers AI-specific failure modes — model hallucination producing incorrect safety documentation, AI scheduling errors causing fatigue-related incidents, or AI-generated tender content containing confidential third-party data. The AI Incident Response Plan must address these scenarios specifically.
The full AI Governance Compliance App includes a pre-populated AI Risk Register template, a risk triage tool, an incident response plan template, and a third-party vendor assessment framework — all configured for Australian heavy industry.