AI Risk & Governance Unleashed

NovaTech Energy's board of directors issues an urgent mandate to the CIO: produce a complete inventory of every AI system currently running across the company within two weeks. The CIO has no central register, no classification system, and no way to distinguish a basic automation script from a full generative AI deployment. Without a taxonomy and a framework, governance cannot begin — and the board deadline is already live.

You will describe the full spectrum of AI types — from narrow AI and machine learning models through to generative and agentic systems — and explain why each category carries different governance implications. This section intro references the NovaTech board mandate to frame why classification must come before governance can function.

You will build the full technical AI classification model using the ISACA taxonomy — covering machine learning paradigms, algorithm families, neural network types, and additional technical concepts required for the AAIR exam. Functionality types and capability levels are bridged from Lesson 2.2. This lesson focuses on predictive models, ML variants, algorithms, neural networks, additional AI concepts, business use cases, and ROI evaluation.

You will analyse the NIST AI Risk Management Framework, the EU AI Act, and the recurring principles that appear across global AI governance frameworks, and identify how each structures risk, accountability, and oversight. This lesson walks through the key components of each framework and shows how they map to different organisational governance needs.

NovaTech's predictive maintenance AI has been running without a designated owner for eighteen months. When it generates a faulty recommendation that causes a $2M equipment failure, three departments — IT, Operations, and Data Science — each claim the other was responsible. The audit that follows reveals no AI charter, no steering committee, and no accountability structure of any kind. The board classifies the incident as a governance failure, not a technical one.

You will identify the core components of an effective AI governance structure and explain why informal ownership models consistently fail under regulatory or incident scrutiny. This lesson references the NovaTech accountability failure directly — showing what a $2M governance gap actually looks like — before framing what the correct structure requires.

You will analyse how AI governance integrates into established enterprise frameworks including COBIT and the COSO ERM model, and identify the structural components each contributes to AI oversight without duplicating what is already in place. This lesson walks through practical integration points and shows how AI governance sits inside — not alongside — existing risk infrastructure.

You will apply a structured AI roles model to assign responsibilities across internal and external stakeholders, design the components of an AI charter, and configure an AI steering committee with genuine authority over AI decisions at enterprise level. This lesson covers the full stakeholder map — governing body, AI owners, operators, and vendors — and builds from role definition to governance structure in a single walkthrough.

NovaTech deployed an AI-assisted hiring tool to streamline candidate screening. A whistleblower report reveals the tool has been systematically downscoring applicants from specific demographic groups — a pattern nobody noticed because no acceptable use policy, no ethical review gate, and no audit mechanism ever existed. Three rejected candidates are pursuing legal action. The fine exposure estimate is $1.2M.

You will identify the components of effective AI policy governance and explain why the existence of a written policy is insufficient without the organisational culture, enforcement mechanisms, and audit processes required to operationalise it. This lesson uses the NovaTech hiring scandal to show the specific gap between policy intention and operational reality.

You will apply a structured policy development model to design an AI acceptable use policy covering scope, prohibited uses, approved workflows, and enforcement mechanisms, alongside the AI procedures and manuals that support day-to-day operational compliance. This lesson walks through each policy component with a working example applied to a high-risk AI deployment.

You will analyse the legal and ethical landscape facing AI deployments, including regulatory mapping across jurisdictions, assessing legal liability for AI-generated decisions, managing intellectual property in AI-created content and training data, and applying ethical principles — bias, fairness, transparency, explainability, and societal impact — as operational governance requirements.

NovaTech's operations team procures a third-party AI solution for field logistics optimisation, selecting the vendor based on a product demo and a price comparison. Six months after go-live, it emerges the model was trained on publicly scraped datasets without a consent framework, the data quality was never validated, and the vendor contract includes no clause for model change notification. The solution is embedded in critical operations and cannot be easily replaced.

You will identify the key phases of the AI lifecycle — from design through procurement, build, and documentation — and explain how decisions made early in the lifecycle compound into governance risk if the right controls are not built in from the start. This lesson references the NovaTech procurement failure to frame lifecycle governance as a continuous discipline, not a one-time checkpoint.

You will apply security-by-design, privacy-by-design, and MLSecOps principles to the AI design phase, identifying the infrastructure and architectural decisions that determine risk exposure before a model is ever trained. This lesson covers hardware, software, and network considerations alongside scalability requirements and the documentation standards required for model cards and ongoing governance.

You will analyse the data requirements for AI models — including structured vs. unstructured data, privacy concerns, consent requirements, and data collection standards — and apply a procurement due diligence model to vendor selection that includes a build vs. buy assessment framework and mandatory contract terms covering model change notification and shared responsibility.

You will identify the key risks that emerge after a model passes initial testing — including adversarial training vulnerabilities, model collapse, data lag, and concept drift — and explain why a one-time validation event is not sufficient governance for a production AI system. This lesson frames the full training, testing, and validation section using the NovaTech drift incident as its continuous reference.

You will apply dataset sourcing and validation standards to assess the quality, representativeness, consent compliance, and fitness-for-purpose of training data before model development begins. This lesson covers how data lag creates hidden model risk, what structured vs. unstructured data requirements look like in practice, and how to build a data validation gate into the pre-training workflow.

You will analyse the risks introduced during model training — including intentional and unintentional changes, adversarial training techniques, model collapse conditions, and fairness and bias evaluation requirements — and identify the controls that prevent training-phase vulnerabilities from reaching production. This lesson also covers stress testing, performance evaluation metrics, and the documentation artefacts a trained model must produce before deployment.

You will apply six robustness controls to a production AI system, implement quantitative drift monitoring thresholds, and select appropriate mitigation strategies when drift is detected. This lesson covers the six AI-specific components of change management that go beyond conventional software governance — including data dependency, model swaps, emergency changes, and continuous learning risks — and designs a compliant decommissioning process covering the five formal elements and AI data disposal requirements.

You will identify the key components of a comprehensive AI data management programme — covering asset inventory, classification, quality, security, and privacy — and explain how gaps in any layer compound risk across the full AI system lifecycle. This lesson uses the NovaTech data consent violation to frame data governance as a core AI risk discipline, not a secondary IT function.

You will apply a structured methodology to build and maintain an AI asset inventory, covering model documentation standards, data source registration, model card design, and the governance procedures that keep the inventory current as systems evolve. This lesson also covers data collection principles including consent, fit-for-purpose validation, and data lag management.

You will implement a data classification framework for AI environments, apply security controls including data encoding, access management, backup integrity, and confidentiality validation, and evaluate how data minimisation and privacy considerations change the permissible scope of AI training data. This lesson walks through each control layer with practical examples applied to structured and unstructured AI data environments.

You will identify the technical and non-technical threat vectors targeting AI systems — including prompt injection, data poisoning, model theft, adversarial evasion, model inversion, training data leakage, and supply chain threats — and explain how each exploits a specific vulnerability in the AI lifecycle. This lesson uses the NovaTech chatbot breach to anchor the threat taxonomy in a real incident outcome.

You will apply a structured threat landscape model to categorise AI-specific threats by attack type, target, likelihood, and impact — and identify which systems in NovaTech's AI portfolio are exposed to each threat category. This lesson covers the complete threat taxonomy, from training data leakage through AI solution disruption, and applies classification frameworks including the MIT AI Risk Repository, the EU AI Act risk tiers, and FAIR-AIR.

You will design a threat modelling process for AI systems using automated threat profile generation, attack path simulation, and risk scenario development — and apply the process to produce a risk scenario register for NovaTech's active AI systems. This lesson covers both the methodological steps and the risk assessment techniques — quantitative and qualitative — that turn threat identification into structured governance input.

You will differentiate between the four AI risk treatment strategies — acceptance, avoidance, mitigation, and risk transfer or sharing — and apply each to defined risk scenarios, determining the correct response given organisational risk appetite, the nature of the risk, and the availability of controls. This lesson references the NovaTech demand forecasting incident to show what uncontrolled risk acceptance looks like at operational level.

You will apply AI control frameworks to conduct a structured gap analysis, evaluate alternative and compensating controls where gaps exist, and design a control validation process that includes testing, continuous monitoring, documentation, and independent assurance. This lesson covers how control selection connects to the broader risk treatment framework and what it means to close a gap versus simply acknowledging one.

There's a persistent failure mode in AI risk governance: applying IT security controls to AI-specific threats and calling the job done. MFA against prompt injection, encryption against model inversion — directionally useful, structurally insufficient. A biased model isn't fixed by a firewall; a hallucinating model isn't secured by endpoint detection. This lesson maps the complete ISACA mitigation framework — all 36 threat categories across both technical and governance/non-technical dimensions — against the AI-aware controls designed to address each one. You'll work through the three principles that cut across every category: AI-specific controls over repurposed IT security, human-in-the-loop as a governance pattern rather than a single control, and continuous transparency, monitoring, and auditing. By the end you can select the right mitigation controls for any AI threat category in the framework.

You've mapped every threat to a control — but two things remain. First, risk is never zero: even with mitigation and human oversight, AI outputs carry residual inaccuracy, and regulations like the EU AI Act require you to define what level of residual impact on humans is "acceptable." This lesson applies the four-phase residual risk framework — framing, scenario building, evaluation, and residual risk calculation — to AI-embedded products, and explains why it must be revisited as models and contexts evolve. Second, a pile of technical controls means nothing without an architecture to hold it: you'll establish the governance and organisational control layer — accountability matrices and charters, executive AI ownership through a CDO or CAIO, AI policy, standards and frameworks, AI asset registries, risk committees with KRIs and independent audit, and AI legal contracts that bind vendors to regulatory obligations. This is what turns scattered controls into an auditable enterprise AI risk programme.

AI introduces risk that standard IT governance never anticipated — and the controls to manage it sit outside the conventional security playbook. This lesson covers the six governance and oversight controls every AI risk practitioner must establish: AI-specific data privacy including differential privacy and privacy-enhancing technologies, ethics controls with human-in-the-loop oversight and an AI ethics committee, safety and observability for autonomous decision-making, AI access controls that govern who sees data inside mixed-data models, zero trust applied to the model itself rather than just the perimeter, and the AI Acceptable Use Policy that sets organisation-wide intent. These are the controls that separate genuine AI governance from repurposed IT security.

Governance ends and assurance begins the moment someone asks you to prove a control is working. This lesson covers the controls that verify, detect, harden, and automate. You'll trace how data and decisions move through black-box models using audits, metadata logging, and model cards, then detect and contain shadow AI before unapproved tools trigger a regulatory breach. You'll harden the models themselves — prompt templates against injection, adversarial testing mapped to the MITRE ATLAS framework, and defensive distillation and regularisation against the small-perturbation attacks that exploit decision boundaries. Finally, you'll turn AI onto the control process itself: AI-assisted control selection, automated monitoring, and SIEM, SOAR, XDR, and UEBA powered by anomaly detection. The section closes by assembling everything into a living, self-monitoring control framework — the shift from reactive AI risk response to proactive AI risk governance.

You will identify the components of an effective AI risk monitoring and reporting programme and distinguish between model performance metrics, AI programme performance metrics, and executive-level risk reporting — evaluating how each must be structured for its specific audience and decision purpose. This lesson references the NovaTech vendor incident to show how the absence of monitoring creates multi-week operational blind spots.

You will design a set of AI risk metrics — covering model performance, deployment risk, and programme-level indicators

You will apply an AI supply chain risk management framework to evaluate third-party vendor relationships, design contract terms that govern model change notifications, shared responsibility clauses, and audit rights, and assess the governance risks specific to open-source AI models and vendor lock-in. This lesson applies directly to every failure mode exposed in the NovaTech vendor update incident.

You will apply Business Impact Analysis principles to AI-dependent business functions — identifying which AI systems are critical, what the consequences of their disruption are, and what recovery objectives must be defined before an incident occurs. This lesson establishes why AI incidents cannot be handled with conventional cybersecurity incident response alone, introduces the ISO 27035-1 framework as applied to AI, and frames the five-phase incident response lifecycle.

You will apply the full five-phase AI incident response lifecycle to a data poisoning scenario — building the policies, response team, detection framework, containment techniques, eradication strategy, and postincident review process required for AAIR exam certification.

Configure an automated reporting and escalation framework that connects monitoring signals to specific governance actions. This lesson also covers how business intelligence tools are applied to AI risk reporting and what board-level AI risk communication must include to be useful rather than decorative.