AI Technologies and Controls

The two preceding chapters addressed the governance and risk dimensions of artificial intelligence — the structures of authority, accountability, and oversight, and the frameworks for identifying and managing the risks that AI systems introduce. This final domain, carrying the largest weight in the AAISM examination at thirty-eight percent, addresses the technical substance that underlies both: the nature of AI technologies themselves, the architectural and lifecycle disciplines required to deploy them securely, the data management and privacy controls that govern the information they consume, the ethical and safety mechanisms that shape their behaviour, and the monitoring and security operations that sustain their integrity in production.

The AAISM professional who has mastered Domain 1 and Domain 2 brings to this domain a crucial contextual advantage: they understand why each technical control matters, what governance structure authorises it, and what risk scenario it addresses. Technical knowledge divorced from governance context produces engineers who can implement controls; technical knowledge integrated with governance understanding produces security professionals who can design and justify them. This chapter aims to cultivate the latter.

3.1 Understanding AI Types

Before designing secure AI systems, the AAISM professional must understand what they are securing. AI is not a monolithic technology — it encompasses a diverse spectrum of models, architectures, and capabilities, each with its own security profile, data requirements, and governance implications. This section surveys the principal categories of AI systems that the AAISM professional is likely to encounter.

3.1.1 AI by Functionality

When classified by what they do, AI systems fall into several broad functional categories. Reactive AI systems respond to specific inputs with specific outputs, without learning from experience or retaining memory between interactions — early chess computers and simple rule-based classifiers are examples. Limited memory AI systems can learn from historical data and use that learning to inform future decisions; most modern machine learning models, including the neural networks that power today's language models and image classifiers, fall into this category. Theory of mind AI — systems capable of modelling the mental states and intentions of other agents — remains largely aspirational; no fully operational system of this type exists at commercial scale. Self-aware AI — systems possessing genuine self-consciousness — remains entirely in the realm of hypothesis and is not a governance concern for the contemporary AAISM professional.

For practical governance purposes, the distinction between reactive and limited-memory AI is the most operationally significant. Reactive systems are more predictable — their behaviour is fully determined by their programming — while limited-memory systems introduce the possibility of unexpected behaviour arising from the patterns in their training data that their designers did not explicitly encode.

3.1.2 AI by Capability

When classified by the breadth of their capabilities, AI systems are conventionally grouped into three tiers. Narrow AI — also called weak AI — systems are designed to perform specific tasks within defined boundaries. They may perform these tasks with superhuman accuracy and speed, but they cannot transfer their capabilities to other domains. Every commercially deployed AI system today is narrow AI. General AI — also called artificial general intelligence or AGI — refers to systems that can perform any intellectual task that a human can, with comparable flexibility and adaptability across domains. AGI does not exist in current commercial form, though the boundaries of what narrow AI can achieve are expanding rapidly. Superintelligence refers to systems that would surpass human cognitive capabilities across all domains simultaneously. This remains a topic of academic and philosophical debate rather than an immediate governance concern.

The significance of this taxonomy for the AAISM professional lies in its relationship to risk scope. A narrow AI system's failure modes are bounded by the tasks it was designed to perform. As AI systems become more general in their capabilities — as language models, for example, are deployed as agents capable of browsing the web, writing and executing code, managing files, and communicating on behalf of users — the scope of potential failure modes expands dramatically, and the governance challenge intensifies correspondingly.

3.1.3 Generative Models and Agentic AI

Generative AI models — systems that produce new content (text, images, audio, video, code, or structured data) from a statistical model of existing content — represent the most significant recent development in the commercial AI landscape. Large language models (LLMs), diffusion models for image generation, and multimodal models that process and generate across content types all fall into this category.

Generative models introduce a distinctive security profile. Unlike discriminative models that classify or predict based on inputs, generative models produce open-ended outputs whose content, accuracy, and appropriateness cannot be fully controlled through input specification alone. Prompt injection attacks, hallucination, and the generation of harmful or biased content are security risks specific to or particularly severe in generative models. The governance controls applied to generative AI — input validation, output filtering, content moderation, human oversight, and rigorous testing — must be calibrated to these specific characteristics.

Agentic AI refers to AI systems that can take sequences of actions in pursuit of goals — browsing the web, executing code, sending messages, querying databases — with a degree of autonomy that conventional AI systems do not possess. Agentic AI dramatically expands the AI attack surface: a compromised or manipulated agentic system can cause harm not merely through its outputs but through its actions in the world. The principle of least privilege, human-in-the-loop oversight, and careful action scope definition are essential governance requirements for agentic AI deployments.

3.1.4 Predictive Models

Predictive AI models — systems trained to forecast future states or classify present states based on historical patterns — are the workhorses of enterprise AI. Fraud detection, credit scoring, predictive maintenance, medical diagnosis, demand forecasting, and recommendation systems all rely on predictive models. Their governance profile is generally more tractable than that of generative models: their outputs are bounded (a classification, a probability, a numerical prediction), and the criteria for evaluating their performance are well-established.

The primary governance risks for predictive models are bias (systematic errors that disadvantage particular groups), drift (performance degradation as real-world conditions diverge from training conditions), and opacity (difficulty explaining why the model reached a specific prediction). These risks, addressed in the governance and risk chapters, manifest in the technical domain as design choices about model architecture, training data management, and monitoring infrastructure.

3.1.5 Machine Learning Model Types

Machine learning — the field of AI in which systems learn from data rather than being explicitly programmed — encompasses several distinct learning paradigms, each with specific security and governance implications.

3.1.6 Algorithms and Classes

The algorithm is the mathematical procedure that specifies how a model learns from data and generates predictions. Different algorithm classes are suited to different problem types and carry different security and interpretability properties. Decision trees and their ensemble variants (random forests, gradient boosted trees) are highly interpretable — the decision path for any prediction can be inspected step by step — and are therefore well-suited to high-stakes applications where explainability is required. Linear models are similarly interpretable but less expressive. Deep learning models — convolutional neural networks, transformer architectures, recurrent networks — are highly expressive but significantly less interpretable, creating explainability challenges in regulated domains.

The AAISM professional must understand that algorithm selection is not merely a technical decision — it is a governance decision. Choosing an interpretable algorithm over a more accurate but opaque one may be the appropriate governance choice in a domain where the right to an explanation is legally mandated or where human oversight depends on understanding the model's reasoning. The best model from a pure performance perspective is not always the best model from a governance perspective.

3.2 AI Security Architecture and Design

Architectural decisions made early in the AI system design process have profound and long-lasting consequences for security, privacy, compliance, and maintainability. The principle of secure by design — incorporating security requirements into the system's architecture from the outset rather than bolting them on after deployment — is as applicable to AI systems as to conventional software, and in some respects more demanding.

3.2.1 Secure by Design Principles for AI

Secure-by-design AI architecture begins with a structured threat model — a systematic analysis of the AI system's attack surface before any code is written. This threat model identifies: the actors who might seek to compromise the system; the assets they might target (training data, model weights, inference endpoints, output data, the infrastructure hosting the system); the attack techniques available to them; and the controls that would reduce the likelihood or impact of each identified threat. The threat model is not a one-time document — it must be revisited as the system evolves and as new attack techniques are discovered.

Key architectural principles for secure AI include: minimal data collection (collect only the data necessary for the intended purpose); data isolation (segregate training data, validation data, and production inference data to limit the blast radius of a compromise); defence-in-depth (layer multiple controls so that no single failure exposes the system to catastrophic harm); fail-safe defaults (design the system to default to the least harmful state when errors or anomalies occur); and auditability (design systems so that every significant inference decision can be reconstructed and reviewed after the fact).

3.2.2 Data Dependency and Storage

AI systems are fundamentally dependent on data — not merely for training, but for ongoing operation. A model's performance is contingent on the quality, currency, and relevance of the data it was trained on, and in many architectures, it is also contingent on the data provided at inference time (through retrieval-augmented generation, for example, or through feature engineering pipelines that draw on live data sources). This dependency creates security requirements that extend far beyond the model itself.

Data storage for AI must be designed to protect both training datasets and production data pipelines from unauthorised access, tampering, and exfiltration. Training datasets — which may contain sensitive personal information, proprietary business data, or strategically valuable information — require encryption at rest, strict access controls, and audit logging of all access events. Data pipelines that feed AI inference systems require integrity checks to detect tampering, anomaly detection to identify unexpected changes in data distribution, and fallback mechanisms for cases where pipeline failures or data quality issues threaten model performance.

3.2.3 Configuration Management

Configuration management — the disciplined control of the configurations of AI system components, including model hyperparameters, preprocessing pipelines, integration settings, and deployment parameters — is a critical security control that is often underinvestigated in AI security assessments. A misconfigured AI system may expose sensitive model parameters, apply inappropriate security controls, or fail to enforce required data handling restrictions.

AI configuration management must address: version control of model configurations alongside model weights; validation that deployed configurations match approved baselines; audit trails documenting who changed what configuration, when, and why; and change management processes that require approval before production configuration changes are applied. These requirements apply to all AI system components, including the increasingly complex configurations of cloud-hosted AI services and foundation model APIs.

3.2.4 AI Model Selection and Change Management

The selection of an AI model — the choice of architecture, training approach, and foundation model — is a governance decision with security implications that must be documented and justified. Model selection criteria should include not only performance metrics but security properties: is the model interpretable? Has it been evaluated for adversarial robustness? Does its architecture support differential privacy? What is its data provenance, and have the training data sources been assessed for bias and compliance?

AI change management governs modifications to deployed AI systems — including model updates, retraining, fine-tuning, and architectural changes. Changes to production AI systems carry unique risks: a model update that improves overall accuracy may simultaneously introduce new biases, reduce robustness to specific input patterns, or change the system's behaviour in ways that affect regulatory compliance. Change management for AI must therefore include testing requirements that go beyond conventional regression testing — specifically covering fairness assessments, adversarial robustness tests, and compliance validation — before any change is approved for production deployment.

Emergency changes — modifications required urgently in response to a security incident, a critical performance failure, or a regulatory directive — present special governance challenges. The pressure for rapid deployment must be balanced against the need for adequate testing. AI change management procedures should define criteria for emergency changes, specify the minimum testing required even under time pressure, require post-emergency review of all emergency changes, and establish rollback procedures that can be executed rapidly if an emergency change produces unintended consequences.

3.3 The AI Life Cycle: Security at Every Phase

An AI system is not a static artefact. It is born through a development process, deployed into a changing environment, operated and monitored over time, and eventually retired. Security and governance must be embedded at every phase of this life cycle — because a failure at any phase can compromise the security of the entire system, and because the risks that apply at each phase are qualitatively different.

The AAISM examination tests not only knowledge of what the phases are, but understanding of the specific security activities, risks, and controls that are appropriate at each. The following treatment addresses each life cycle phase in turn.

3.4 Data Governance Controls

Data is the essential substrate of AI — its quality, integrity, and lawfulness determine the character of every AI system built upon it. Data governance for AI is the structured application of policies, processes, and controls across the entire data lifecycle — from acquisition through disposal — to ensure that data used in AI systems meets applicable standards of quality, security, privacy, and compliance.

3.4.1 Data Acquisition

The security of an AI system's data begins at the point of acquisition — the collection, purchasing, or scraping of data that will form its training corpus. Data acquisition governance requires: verifying that the organisation has a valid legal basis for each category of data it collects (particularly personal data, which requires a lawful basis under GDPR and comparable legislation); assessing the provenance of purchased or licensed datasets for compliance with applicable data protection laws; evaluating the terms of use of publicly available datasets for restrictions on commercial AI use; and documenting the acquisition source, legal basis, and relevant consent mechanisms for every dataset in the AI training inventory.

3.4.2 Data Organisation and Preparation

Raw data collected for AI training is rarely ready for immediate use. Data preparation — the process of cleaning, normalising, structuring, labelling, and splitting data into training, validation, and test sets — introduces both opportunities and risks. Security controls at this phase include: validation checks that detect anomalies, outliers, or suspicious patterns that might indicate data poisoning; integrity checksums applied to datasets before and after preparation to detect unauthorised modification; access controls on preparation environments that limit who can modify training data; and audit logs recording all preparation operations and the personnel who performed them.

Data labelling — the process of annotating training data with the correct answers that the model will learn to predict — is a particularly sensitive preparation activity. Labelling errors, whether accidental or deliberate, directly determine model behaviour. Governance of the labelling process should include: quality checks and inter-rater reliability assessments for manual labelling; documentation of labelling guidelines and their versions; and security controls on labelling systems and the personnel with access to them.

3.4.3 Data Utilisation, Storage, and Retention

Once prepared, training data must be stored securely and used only for its approved purposes. Storage security controls for AI training data include encryption at rest using appropriate algorithms (AES-256 or equivalent); strict role-based access control that limits access to approved personnel with documented need; and network isolation of storage systems from the public internet where operationally feasible.

Data retention schedules for AI training data must account for both data protection obligations (which often require deletion of personal data when no longer needed) and AI-specific requirements (which may require retaining training data to enable model auditing, retraining, or regulatory inspection). Where these obligations conflict — a regulator requiring audit retention while a data protection authority requires deletion — the conflict must be escalated to legal counsel and senior management for resolution, and the resolution documented.

Data destruction must be documented and verifiable. When AI training data reaches the end of its approved retention period, it must be destroyed in a manner appropriate to the sensitivity of the data and the storage medium. For highly sensitive data, simple deletion is insufficient — cryptographic erasure or physical destruction may be required. A certificate of destruction, archived in accordance with the organisation's record retention policies, provides the evidentiary basis for demonstrating compliance with destruction requirements.

3.5 Data Security Controls

Data security controls protect the confidentiality, integrity, and availability of data used in AI systems. They apply across all phases of the AI lifecycle and must be tailored to the specific characteristics of AI data — which is often large in volume, complex in structure, and sensitive in content.

3.6 Privacy Controls for AI

Privacy is not merely a legal obligation — it is a fundamental dimension of trustworthy AI. AI systems that violate the privacy of the individuals whose data they process undermine the trust upon which their social licence to operate depends. Privacy controls for AI must be designed and implemented with an understanding of the specific privacy risks that AI creates, which go beyond those of conventional data processing.

3.6.1 Privacy-by-Design for AI Systems

Privacy-by-design requires that privacy protections be built into the AI system's architecture from the outset, rather than added as an afterthought. For AI systems, privacy-by-design encompasses: data minimisation (collect and use only the personal data strictly necessary for the intended AI application); purpose limitation (do not use personal data collected for one AI purpose for a different AI purpose without fresh legal authority); retention minimisation (delete personal data from AI training datasets as soon as the retention obligation has been satisfied); and subject rights support (design AI systems to be capable of responding to data subject access requests, erasure requests, and requests for human review of automated decisions).

Technical privacy controls specifically relevant to AI include: differential privacy (adding calibrated mathematical noise to model outputs or training processes to prevent inference of individual data points); federated learning (training models without centralising raw personal data); data anonymisation and pseudonymisation (removing or obscuring identifying information before use in AI training); and output filtering (preventing AI systems from reproducing verbatim personal information from training data in their outputs).

3.6.2 The Right to Human Review of Automated Decisions

One of the most significant privacy and human rights provisions applicable to AI is the right, embedded in Article 22 of GDPR and analogous provisions in other data protection frameworks, not to be subject to solely automated decisions that produce significant legal or similarly significant effects — without the opportunity for human review. This provision applies directly to many enterprise AI deployments: credit scoring, insurance pricing, hiring screening, and benefits eligibility determination are all domains where AI-influenced decisions can have significant legal or practical effects on individuals.

Compliance with this requirement demands that the AI security programme establish: a process for identifying which AI-influenced decisions meet the threshold for significant effect; mechanisms for providing individuals with a meaningful explanation of automated decisions affecting them; and a documented, auditable process for human review of such decisions upon request. These are not merely legal compliance requirements — they are governance mechanisms that ensure human accountability is maintained in consequential AI decision-making.

3.7 Ethical Frameworks and Trust Mechanisms

Ethics in the technical domain of AI is not abstract philosophy — it is the practical discipline of designing systems that behave in accordance with stated values, treating all affected individuals fairly, and maintaining the conditions of trust that allow AI systems to remain socially legitimate.

An ethical AI framework at the technical level encompasses: bias detection and mitigation tools that identify and address disparate impacts before deployment; explainability mechanisms that provide stakeholders with meaningful accounts of AI decisions; fairness metrics that measure and monitor the degree to which AI outputs treat comparable individuals comparably; and impact assessment processes that evaluate the broader social consequences of AI system deployment before they are authorised. The choice of which fairness metric to optimise — equal accuracy, equal false positive rates, demographic parity — is itself a governance decision that must be made with the active involvement of affected stakeholders and documented for regulatory scrutiny.

Trust in AI systems is built through consistent, transparent, and accountable operation over time. Technical trust mechanisms include: model confidence scores that convey the system's uncertainty to users; audit logs that provide a complete, tamper-evident record of AI system decisions; model documentation (model cards, datasheets) that communicate system properties to users and regulators; and external audit and certification processes that provide independent verification of the system's claimed properties. Trust, once lost through a significant AI failure or disclosure of harmful practices, is extraordinarily difficult to rebuild — the governance imperative is to establish and maintain trust through institutional commitment, not merely to manage its loss after the fact.

3.8 Safety Controls and Human-in-the-Loop

Safety in AI refers to the system's ability to operate within acceptable behavioural bounds — not causing unintended harm, not being susceptible to manipulation, and not generating outputs that endanger human welfare. Safety controls are the technical and procedural mechanisms that maintain these bounds in the face of unpredictable inputs, evolving conditions, and adversarial attempts at manipulation.

3.8.1 Human-in-the-Loop (HITL)

Human-in-the-loop (HITL) is the governance and safety principle that meaningful human judgement must be maintained in AI-assisted decision-making processes, particularly for decisions with significant consequences for individuals or organisations. HITL is not a binary property — it exists on a spectrum from full human control (AI provides information only, human makes all decisions) through human-on-the-loop (AI acts autonomously but human monitors and can intervene) to full automation (AI acts autonomously with no human oversight).

The appropriate position on this spectrum depends on: the severity of potential harm from AI errors; the reversibility of AI-initiated actions; the speed at which decisions must be made; and the availability and capability of qualified human reviewers. As AI systems become more capable, the temptation to move toward full automation increases — but governance must ensure that this movement is deliberate, documented, and tested, not a gradual drift driven by convenience or cost-cutting. The EU AI Act's human oversight requirements for high-risk AI systems reflect a regulatory judgement that in certain consequential domains, full automation is not permissible regardless of AI system performance.

Implementing effective HITL requires: clear criteria defining which AI outputs or decision thresholds require human review; user interfaces that present AI outputs and their confidence levels in a way that supports meaningful human judgement rather than encouraging rubber-stamping; accountability mechanisms that record the human reviewer's identity, decision, and rationale; and feedback loops that route human corrections back into the AI improvement process. A HITL process in which human reviewers automatically approve AI recommendations without genuine engagement is not a safety control — it is theatre.

3.9 AI Security Controls

The final sub-domain of the AAISM examination brings together the full range of security controls that protect AI systems in operation — from the frameworks that guide control selection, through access controls and zero trust architecture, to the operational disciplines of AI auditing, shadow AI management, and incident response. It also addresses the ongoing monitoring capabilities that sustain security awareness across the AI lifecycle.

3.9.1 AI-Assisted Security and Monitoring Tools

AI is transforming security operations at the same time that it is introducing new categories of risk. AI-powered Security Information and Event Management (SIEM) systems, User and Entity Behaviour Analytics (UEBA) platforms, and automated threat detection tools are now integral components of enterprise security architectures. Their most effective use case in the Security Operations Centre is detecting subtle, low-signal attack patterns that human analysts would miss or that would be buried in alert volume — reducing false negatives in threat detection by surfacing anomalies that conventional rule-based systems would not flag.

The governance of AI-powered security tools requires the same rigour applied to any other AI deployment: what data does the tool train on? How are its alerts validated? What is the human oversight mechanism? And critically, how does the tool perform when the attacker is also using AI to evade detection? The use of AI security tools does not eliminate the need for human judgement in security operations — it changes the nature of the human analyst's role from alert triage toward oversight, exception management, and strategic threat analysis.

3.9.2 AI Security Control Frameworks

Several specialised AI security control frameworks have emerged to supplement general cybersecurity frameworks (such as NIST CSF, ISO 27001, and CIS Controls) with AI-specific guidance. The OWASP Top 10 for Large Language Model Applications provides a curated list of the most critical security risks in LLM deployments — including prompt injection, insecure output handling, training data poisoning, model theft, and excessive agency — with corresponding mitigation guidance. The MITRE ATLAS (Adversarial Threat Landscape for Artificial Intelligence Systems) framework catalogues adversarial machine learning tactics and techniques in a structure analogous to MITRE ATT&CK for conventional cybersecurity, enabling AI security teams to map their defences against a structured threat taxonomy. These frameworks should be used in conjunction with AI threat models developed for specific deployments — they provide the vocabulary and taxonomy for threat analysis, but cannot substitute for context-specific assessment.

3.9.3 Access Controls for AI Systems

Access control for AI systems must address a broader attack surface than conventional applications. The access control requirements span: access to training data repositories; access to model weights and hyperparameters; access to model inference endpoints (both internal and external); access to monitoring systems and logs; access to AI development and MLOps platforms; and access to the cloud infrastructure hosting AI components. The principle of least privilege applies at each layer — each user, service account, and automated process should have only the access required for its specific function.

Role-based access control (RBAC) should define distinct roles for AI developers, data scientists, model validators, security reviewers, operations staff, and business users — with access rights calibrated to each role's operational requirements. Privileged access management (PAM) controls should apply to administrative access to AI infrastructure, requiring strong authentication, session recording, and just-in-time access provisioning.

3.9.4 Zero Trust Architecture for AI

Zero Trust Architecture (ZTA) — the security model that assumes no implicit trust for any entity inside or outside the network perimeter, and requires continuous verification of identity, device health, and authorisation for every access request — is particularly relevant to AI deployments, which often span multiple cloud environments, involve numerous external data sources, and are accessed by a diverse range of users and automated processes.

Applying Zero Trust to AI means: requiring strong authentication for all access to AI components, including internal service-to-service communications; implementing microsegmentation to isolate AI components from each other and from non-AI systems; applying continuous verification of the integrity of AI infrastructure and configurations; and monitoring all traffic between AI components for anomalies that might indicate compromise. The Zero Trust model is especially important for agentic AI systems, which may initiate connections to external systems — all such connections should be subject to the same continuous verification requirements as human-initiated access.

3.9.5 AI Acceptable Use Policy Enforcement

The technical enforcement of the AI Acceptable Use Policy — established in governance — requires technical controls that prevent, detect, or respond to policy violations. Technical enforcement mechanisms include: Data Loss Prevention (DLP) tools configured to detect and block the entry of sensitive data categories into AI systems; content filtering on AI outputs to prevent the disclosure of confidential or personally identifiable information; activity monitoring and logging that creates an audit trail of AI tool usage by employees; and automated alerting when usage patterns deviate from policy-defined norms (for example, an employee entering unusually large volumes of data into a generative AI platform).

3.9.6 AI Audits, Traceability, and Supply Chain Controls

Audit and traceability requirements for AI systems demand that every significant inference decision be reproducible — that a reviewer can reconstruct, for any given output, the inputs provided, the model version and configuration used, and the outputs produced. This requires logging infrastructure designed specifically for AI audit purposes, not merely general-purpose application logs. AI audit logs should capture: the model version and configuration hash; input data and its provenance; the output produced and its confidence score; the timestamp and user or process identifier; and any human review actions taken on the output.

Supply chain security controls for AI — addressed in detail in Chapter 2 — have a technical implementation layer that includes: software bill of materials (SBOMs) for AI systems that document all third-party components; cryptographic signing of model releases to enable integrity verification; and automated scanning of AI dependencies for known vulnerabilities. These technical controls complement the governance-level supply chain risk management addressed in Domain 2.

3.9.7 Shadow AI Detection and Management

Shadow AI — the use of AI tools that have not been formally reviewed or approved by the organisation — represents one of the most prevalent and consequential security gaps in enterprise AI governance. Employees and business units adopt AI tools for legitimate productivity reasons, without awareness of the data protection, security, or compliance implications. The result is an uncontrolled proliferation of AI deployments that the organisation cannot monitor, govern, or secure.

Technical approaches to shadow AI detection include: network monitoring for traffic to known AI platform endpoints (OpenAI, Anthropic, Google AI, Hugging Face, and others); endpoint monitoring for AI tool installation and usage; analysis of cloud expenditure for AI service charges not associated with approved deployments; and security scanning of browser extensions, which are a common vector for shadow AI adoption. Detection is necessary but insufficient — the governance response to detected shadow AI must include: risk assessment of the specific tool and its use context; engagement with the employees or business units involved to understand their needs; and a governance decision about whether to approve, remediate, or prohibit the use, based on that assessment.

3.9.8 AI Incident Management

AI incidents — events that compromise the security, performance, fairness, or regulatory compliance of an AI system — require a specialised incident management process that extends conventional cybersecurity incident response. The distinctive characteristics of AI incidents require adaptations at every stage of the incident lifecycle: detection (AI-specific monitoring for drift, adversarial inputs, and output anomalies, in addition to conventional security signals); classification (AI incidents may span security, performance, and fairness dimensions simultaneously); investigation (root cause analysis of AI incidents requires data science expertise as well as security expertise); containment (options may include model rollback, endpoint isolation, or routing decisions to human review); and post-incident review (AI incidents should trigger assessment of model documentation, monitoring coverage, and change management processes, not merely security controls).

3.10 AI Security Awareness Training and Skills Development

The security of AI systems depends not only on technical controls but on the awareness, skills, and judgement of the people who develop, deploy, operate, and use them. AI security awareness training is a distinct discipline from general cybersecurity awareness, because AI introduces risks — hallucination, data leakage through AI tools, prompt injection, over-reliance on AI outputs — that conventional security awareness training does not address.

Effective AI security awareness training addresses different content for different audiences. For general employees: what AI tools are approved for use; what data may not be entered into AI systems; how to identify and report AI-related security concerns; and the specific risks of using unapproved AI tools (shadow AI). For AI developers and data scientists: secure coding and design practices for AI systems; adversarial robustness requirements; data governance obligations; and model documentation standards. For security operations personnel: AI-specific threat detection techniques; how to investigate and respond to AI incidents; and how to apply AI threat intelligence to defensive operations. For executive and governance personnel: the strategic risk and opportunity landscape of AI; regulatory obligations; and the governance decisions they are accountable for.

3.10.1 Addressing AI Skills Gaps

The AI skills gap — the difference between the AI-specific security competencies that the organisation requires and those currently held by its security team — is a governance risk that must be actively managed. Skills gaps create blind spots: attack techniques that the team does not understand cannot be defended against; governance requirements that the team does not know about cannot be satisfied. Addressing AI skills gaps requires: a structured assessment of current team competencies against required competencies; a prioritised training and development plan; recruitment strategies targeted at AI security expertise; and knowledge-sharing mechanisms that distribute AI security expertise across the team rather than concentrating it in a few individuals who represent single points of failure.

Cross-functional AI security teams — integrating data scientists, security engineers, legal and compliance professionals, and business stakeholders — can partially address skills gaps by combining complementary expertise. A security engineer who does not understand machine learning working alongside a data scientist who does not understand adversarial attack techniques can together provide coverage that neither could provide alone. Governance must create the structural conditions — shared responsibilities, collaborative processes, joint training opportunities — that enable this cross-functional integration to function effectively.

3.11 Continuous Monitoring: Drift, Threat Intelligence, and Security Metrics

3.11.1 Model Drift Detection

Model drift — the degradation of AI system performance as real-world conditions diverge from the training data distribution — is the most pervasive ongoing security and governance challenge in AI operations. Drift detection requires establishing a baseline of expected model performance at deployment and continuously monitoring production performance against that baseline. There are two principal categories of drift: data drift (changes in the statistical distribution of inputs the model receives) and concept drift (changes in the relationship between inputs and correct outputs, even if the input distribution remains stable).

Technical approaches to drift detection include: statistical monitoring of input feature distributions against training distribution baselines; performance monitoring using proxy metrics when ground-truth labels are not immediately available; reference dataset comparison, where production inputs are periodically compared to training data; and shadow model testing, where a newer model is run in parallel with the production model to identify divergences. Governance must establish drift thresholds — the degree of deviation from baseline that triggers review, retraining, or replacement — and ensure that these thresholds are set in consultation with the business stakeholders who understand the operational consequences of model performance degradation.

3.11.2 Threat Intelligence for AI

AI-specific threat intelligence — information about emerging attack techniques, newly discovered vulnerabilities in AI frameworks, and adversary campaigns targeting AI systems — is an essential input to the AI security monitoring function. Threat intelligence sources relevant to AI include: research publications from academic institutions and AI security organisations (Google Project Zero, Trail of Bits, Robust Intelligence); disclosures from AI platform vendors about vulnerabilities in their systems; CVE databases for AI libraries and frameworks (TensorFlow, PyTorch, Hugging Face Transformers); and specialised AI security communities and information-sharing groups.

Operationalising AI threat intelligence requires: ingestion into the security monitoring platform with AI-specific threat indicators; mapping of threat intelligence to the organisation's specific AI deployments to assess relevance; integration with change management and control review processes so that new threat intelligence triggers timely reassessment of existing controls; and alert enrichment that provides security analysts with AI-specific context when investigating incidents that match AI threat patterns.

3.11.3 Security Metrics for AI

Meaningful security metrics for AI systems provide the governance body, the CISO, and the AI security programme manager with the quantitative basis for assessing programme effectiveness, identifying trends, and making informed resource allocation decisions. The following categories of AI-specific security metrics represent a balanced scorecard for the AI security programme.

3.12 Chapter Summary

Domain 3 of the AAISM examination — the heaviest domain at thirty-eight percent — covers the full technical landscape of AI security, from the fundamental nature of AI technologies through the security controls and monitoring disciplines that sustain their integrity in operation.

Part A established the taxonomy of AI types — by functionality (reactive, limited-memory), by capability (narrow, general, super), and by model type (generative, predictive, machine learning paradigms). Each category carries a distinctive security profile: generative models require output filtering and hallucination mitigation; agentic AI demands least-privilege and HITL oversight; supervised learning is vulnerable to label manipulation; reinforcement learning is vulnerable to reward function exploitation; and deep neural networks create explainability challenges that governance must address. Secure-by-design principles — threat modelling before development, minimal data collection, data isolation, defence-in-depth, and auditability — apply to AI as rigorously as to any other critical system. AI change management must include fairness assessment, adversarial robustness testing, and compliance validation, not merely regression testing.

Part B traced the full AI lifecycle from Plan and Design through Retire/Decommission, identifying the distinctive security activities and priorities at each phase. The data collection and preparation phase carries the greatest inherent risk — it is where poisoning, consent failures, and data quality problems are introduced. The testing phase is the last opportunity to catch security, fairness, and compliance issues before production. The decommissioning phase is the most neglected — its governance requirements (documented destruction, regulatory retention, stakeholder communication) must be planned before deployment, not improvised after.

Part C addressed data management controls — covering the full arc of data governance (acquisition, organisation, utilisation, storage, retention, destruction) and data security (encryption, access control, confidentiality/siloing, backup, integrity). The specific security requirements at each data governance stage reflect the fundamental dependence of AI system integrity on data integrity.

Part D examined privacy, ethical, trust, and safety controls. Privacy-by-design principles and technical mechanisms (differential privacy, federated learning, anonymisation) address the specific privacy risks of AI data processing. The right to human review of significant automated decisions creates enforceable legal obligations that the AI security programme must operationalise. Ethical frameworks require technical implementation — bias detection, explainability mechanisms, fairness metrics. Human-in-the-loop is a spectrum rather than a binary property; governance must determine the appropriate position based on harm severity, reversibility, and decision speed requirements.

Part E synthesised the full range of operational security controls — AI-powered security tools and their governance, AI security control frameworks (OWASP LLM Top 10, MITRE ATLAS), access controls and Zero Trust architecture, AUP enforcement, audit and traceability, shadow AI detection and management, AI incident management, awareness training and skills development, and continuous monitoring through drift detection, threat intelligence, and security metrics. Together, these controls form the operational layer of the AI security programme through which governance principles become sustained security practices.

3.13 Practice Questions

Attempt each question independently before reading the answer. These questions test technical knowledge integrated with governance reasoning, reflecting the style of Domain 3 AAISM examination questions.

End of Chapter 3 — Domain Coverage Complete.