AI Governance and Compliance

Modules 01 to 04 covered AI security: protecting AI systems from deliberate attacks. This module covers the security of AI: ensuring AI systems behave safely, fairly, and transparently without causing unintended harm. The distinction matters for compliance because different frameworks address different sides of it.

AI security is what your security team owns. It shows up in threat models, penetration tests, SIEM rules, and incident response playbooks. The EU AI Act's Article 15 cybersecurity requirements, the NIST AI RMF Measure function's adversarial testing requirements, and ISO 27001's security controls all sit in this domain.

The security of AI is what your compliance, legal, and risk teams own. It asks whether the AI causes harm through bias, lack of transparency, insufficient human oversight, or unintended consequences. The EU AI Act's high-risk system obligations, GDPR Articles 22 and 35, NIST AI RMF's Govern and Map functions, and ISO 42001's AI management system all sit here.

In practice, the same team often handles both because the controls overlap. An audit trail that proves who authorised each agent action (AI security: repudiation defence) is also evidence of human oversight (security of AI: governance requirement). A threat model that identifies data flows and trust boundaries (AI security: threat identification) also satisfies the DPIA documentation requirement (security of AI: GDPR Article 35).

Four frameworks cover the vast majority of AI compliance obligations that organisations face today. They overlap significantly and a well-structured compliance programme satisfies requirements across all four with the same underlying documentation.

The NIST AI Risk Management Framework (AI RMF 1.0, released January 2023) structures AI risk management around four functions. It does not prescribe specific controls but expects evidence that risks have been identified, assessed, and addressed systematically. The four functions map directly to the work you have done across Track 1.

ISO 42001, published in December 2023, is the first international standard specifically for AI management systems. If your organisation is already certified on ISO 27001, the structure will be familiar: both use the ISO High Level Structure with clauses covering context, leadership, planning, support, operation, performance evaluation, and improvement.

ISO 42001 adds AI-specific requirements on top of this structure. The key additions relevant to practical compliance:

AI policy and objectives. The organisation must define an AI policy that addresses AI-specific risks including bias, transparency, and human oversight. This goes beyond an information security policy: it must address what the organisation will and will not use AI for, how it manages AI-related societal impacts, and how it ensures human control over significant AI decisions.

AI risk assessment. ISO 42001 requires a risk assessment that covers AI-specific risks: model bias, unintended harm through automated decisions, supply chain risks in AI components, and societal impact. The threat model from Module 04 covers the security risks. You need an additional assessment covering the fairness, transparency, and impact dimensions to fully satisfy this clause.

AI system impact assessment. Before deploying a new AI system, ISO 42001 requires an assessment of its intended use, affected stakeholders, and potential negative impacts. This is similar to a DPIA but broader, covering not just data protection but also fairness, accuracy, and societal effects.

Operational controls. Controls for AI lifecycle stages including data acquisition, model training, testing, deployment, and decommission. The DiscoveR pre-deployment validation scan and the AgentIQ runtime enforcement logs directly satisfy several operational control requirements.

Performance evaluation. Regular review of AI system performance including adversarial testing, bias monitoring, and accuracy assessment. This is where DiscoveR's regular scan results become ongoing compliance evidence, not just a one-off assessment.

The EU AI Act came into force in August 2024 with a phased implementation schedule. Prohibited systems became effective in February 2025. High-risk system obligations apply from August 2026. General-purpose AI model requirements (for foundation model providers) apply from August 2025. Understanding which tier your system falls into is the first step.

If your AI system is classified as high-risk under the EU AI Act, you must satisfy six categories of obligations before deployment. The obligations apply to providers (who develop the system) and users (who deploy it in a high-risk context).

Risk management system (Article 9). A documented process for identifying, analysing, and mitigating risks throughout the AI system's lifecycle. Your threat model from Module 04 is the core of this document. It must be updated when the system changes and must include adversarial testing results.

Data governance (Article 10). Training, validation, and testing datasets must be documented, relevant, representative, free from errors, and complete. Data lineage must be traceable. This applies to both the model's original training data and any fine-tuning or RAG knowledge base data your team manages.

Technical documentation (Article 11). Comprehensive documentation of the system: its intended purpose, performance on relevant populations, known limitations, cybersecurity measures, and how human oversight is implemented. The data flow diagram and threat model from Module 04 contribute to this.

Record-keeping and logging (Article 12). Automatic logging of system operation to allow post-hoc investigation of incidents. AgentIQ's signed tool call audit trail and VectaX's retrieval audit log directly satisfy this requirement for agentic and RAG deployments.

Transparency and information provision (Article 13). Users must receive documentation sufficient to understand the system's capabilities, limitations, and monitoring requirements. Not a technical requirement but a documentation requirement for whoever deploys the system.

Human oversight (Article 14). High-risk AI systems must include features that allow oversight persons to understand, monitor, and where necessary override or stop the system. AgentIQ's deny-by-default tool policies and the human-in-the-loop escalation capability directly satisfy this.

Cybersecurity (Article 15). High-risk AI systems must be resilient against attempts to alter their behaviour through adversarial attacks. DiscoveR's pre-deployment validation scan and regular adversarial testing results directly satisfy this requirement and provide the evidence an auditor would ask for.

GDPR was passed in 2018 before large language models were mainstream. But two articles apply directly to AI systems processing personal data.

Article 22: Automated decision-making. Individuals have the right not to be subject to a decision based solely on automated processing that produces significant effects on them. "Significant effects" covers decisions about credit, employment, insurance, healthcare, and access to services. If your AI makes or substantially influences such decisions without human review, Article 22 applies. Compliance requires: informing individuals that automated decision-making is occurring, providing meaningful information about the logic involved (the system documentation from EU AI Act Article 13 serves here), and offering a right to human review and to contest the decision.

Article 25: Privacy by design and default. Technical and organisational measures must implement data protection principles from the design stage. For AI systems, this means: minimise the personal data included in prompts and context, encrypt personal data in model inputs and outputs, implement access controls on who can query AI systems that process personal data. VectaX's FHE-encrypted inference satisfies the technical privacy by design requirement: even if the inference infrastructure is compromised, the data was never in plaintext.

Article 35: Data Protection Impact Assessment (DPIA). A DPIA is required before processing that is likely to result in a high risk to individuals, including systematic evaluation of individuals through profiling. Most AI applications that process personal data require a DPIA. The DPIA must document: the processing operation and its purposes, the necessity and proportionality of the processing, the risks to individuals, and the measures to address the risks. Your threat model from Module 04 provides the data flow diagram and risk register that the DPIA requires. The DiscoveR scan results and AgentIQ logs provide evidence that controls are operating effectively.

Article 32: Security of processing. Appropriate technical and organisational measures to ensure security appropriate to the risk. For AI systems, this includes encryption of personal data in embeddings (VectaX closes this), access controls on the AI system and its knowledge base, and monitoring for data breaches through AI outputs. The threat model's information disclosure threats and the controls selected for them directly satisfy Article 32 documentation requirements.

The threat model you build using the Module 04 process produces four types of documentation that satisfy requirements across all four frameworks. This is the most direct path from security engineering work to compliance evidence.

The data flow diagram with trust boundaries satisfies: GDPR Article 35 DPIA (the processing operation description), EU AI Act Article 11 technical documentation (system architecture), ISO 42001 AI impact assessment (data flows and stakeholder interactions), NIST AI RMF Map function (system context documentation).

The STRIDE analysis with MITRE ATLAS mapping satisfies: NIST AI RMF Measure function (systematic risk identification), EU AI Act Article 9 risk management system (documented risk analysis methodology), ISO 42001 AI risk assessment (structured threat identification).

The prioritised threat register satisfies: NIST AI RMF Manage function (prioritised risk treatment), GDPR Article 35 DPIA (risks to individuals and proposed measures), EU AI Act Article 9 (risk quantification and prioritisation).

The control selection and implementation documentation satisfies: all four frameworks' requirements for demonstrating that identified risks have been addressed. The key addition that most teams miss: attach the DiscoveR scan results to the threat model as evidence that controls have been tested and verified. A threat model without test results is a hypothesis. A threat model with DiscoveR results is evidence.

The table below maps each Mirror Security product to the compliance evidence it generates and the specific framework requirements it helps satisfy. This is the output regulators, auditors, and procurement teams ask for.

Track 1 gave you the full foundation for AI security work. Each module built on the last, from the definitions that matter to the frameworks that structure the work.

Track 1 is the foundation. The tracks below go deep on specific systems, attack types, and operational practices. Choose based on what you are building or defending.