Summary: The operational layer — what an organisation actually builds: audits, accountability structures, incident response plans, and AI-specific security tooling (AI-SPM, DSPM, CNAPP).
Sources: raw/Laws/What Is AI Governance_Paloaltonenetworks.md
Last updated: 2026-07-29
A vendor overview (Palo Alto Networks), so read the tooling sections with that in mind. The audit and IR structure is generic and useful; the product mapping is not neutral.
Five components
Ethical guidelines · regulatory frameworks · accountability mechanisms · transparency · risk management (source: What Is AI Governance_Paloaltonenetworks.md).
The stated challenges
- Frameworks need continuous update as capabilities and risks emerge.
- Balancing innovation with regulation — “Overly restrictive governance measures can stifle innovation… Conversely, insufficient governance can lead to unintended consequences and ethical breaches.”
- Lack of standardisation across jurisdictions for multinationals.
- Data privacy — AI systems can “infer sensitive information about individuals, even from seemingly innocuous data. For example, AI analysis of social media activity or purchasing behavior could potentially reveal information about an individual’s health status, political beliefs, or sexual orientation, even if this information was never explicitly shared.”
- Data minimisation vs data-hungry systems — a direct tension, not a solvable one.
- Bias, and the technical difficulty of explainability for deep models.
The inference point is worth holding onto: it means data classification based on what was collected understates exposure. What the system can derive is the actual sensitive-data surface.
AI audits — the six-step structure
- Define audit objectives — “Assess model accuracy, check for biases, ensure data privacy, and verify compliance with regulations.”
- Assemble an audit team — “expertise in AI, data science, and regulatory compliance,” including external members “to provide an unbiased perspective.”
- Develop an audit plan — scope, methodology, timeline; “a review of data sources, model development processes, deployment protocols, and monitoring mechanisms.”
- Conduct the audit — “Ensure that the audit covers all stages of the AI lifecycle, from data collection to deployment.”
- Report findings and recommendations — with confirmation “that corrective actions are implemented.”
- Continuous monitoring.
Maps onto NIST’s independent-review point under MEASURE, and onto the Code of Practice’s Commitment 8 assurance role. See nist-ai-rmf, gpai-code-of-practice.
AI incident response plan — seven elements
- Identify potential incidents — “data breaches, biased outcomes, model inaccuracies, and regulatory violations.”
- Establish a cross-functional IR team — “IT, legal, compliance, data science, and public relations.”
- Develop response procedures — identify, assess impact, contain, mitigate harm.
- Communication protocols — internal and external, “including employees, customers, and regulators.”
- Documentation and reporting — a detailed incident log, “Regularly review and analyze incident reports to identify patterns.”
- Post-incident review.
- Training and drills.
This is a competent but conventional IR plan. What it does not address is what the dedicated IR sources say makes AI incidents different — probabilistic behaviour, ambiguous root cause, context-dependent severity, and responder wellbeing. See AI incident response and Microsoft IR readiness for the AI-specific extensions.
Securing AI systems
The framing: “AI systems can be targets for cyberattacks, including data poisoning, model inversion, or adversarial attacks that manipulate outputs.”
Frameworks recommended:
- MITRE’s Sensible Regulatory Framework for AI Security — “risk-based regulation, collaborative policy design, and adaptability.”
- MITRE ATLAS — “a detailed matrix of potential threats to AI systems… categorizes threats based on their objectives and methods.” Organisations “can map their AI systems to relevant threat categories in the ATLAS matrix, identify potential vulnerabilities, and implement recommended mitigation strategies.”
ATLAS is now ingested — see MITRE ATLAS. It supplies the mapping layer this page recommends, including the technique-level mitigations the rest of the governance corpus lacks. The ATLAS IDs PITAX cites (AML.T0077, AML.T0051.002) now resolve to real pages.
Tooling categories:
- AI-SPM (AI Security Posture Management) — “continuously monitoring the security posture of AI systems, identifying and remediating vulnerabilities in AI models and infrastructure, and implementing automated security checks throughout the AI development lifecycle.”
- DSPM (Data Security Posture Management) — “discovering and classifying sensitive data, enforcing data access controls and encryption, and monitoring data usage patterns.”
- CNAPP — incorporates both, plus “runtime protection for AI workloads.”
Technical mitigations: adversarial training, federated learning, homomorphic encryption, differential privacy.
External system analysis — the supply chain part
- Evaluate vendors’ and partners’ security practices; “verifying the integrity of AI models and datasets.”
- “Engage ethical hackers to identify vulnerabilities in AI systems from an external perspective.”
- Leverage external threat intelligence feeds for “emerging AI-specific threats and attack techniques.”
- Develop “a vendor risk assessment framework specific to AI technologies,” with “secure supply chain practices for AI components, including cryptographic signing of models and datasets.”
- Regular penetration tests; integrate AI-specific threat intelligence into SOC processes.
Cryptographic signing of models and datasets is the concrete control against Art 15(5) model poisoning via “pre-trained components used in training.” It is also absent from the Code of Practice Appendix 4 control set, which covers protecting your weights but not verifying inbound ones.
That material is now ingested — see provenance and assurance.