Regulations, governance, and AI security policy
Requirement / business driver
Meet regulatory and governance obligations and manage the new corporate-security-policy risks that AI introduces.
AI governance
Model and data governance - lineage, versioning, auditability; assurance and integrity (the model behaves as intended; training/inference data is trustworthy and unaltered); and access control to models and datasets. Regulations as provided in a scenario (sector/region rules) become design constraints (audit, residency, explainability).
AI's impact on corporate security policy
A distinct CCDE concern (Exam-Topics 5.1.g): AI creates new ways to leak IP / proprietary information - e.g., staff pasting confidential data into external AI services ("shadow AI"), or proprietary data ending up in a model. Govern what data may go to which AI (internal vs external), enforce data classification before ingestion, and protect corporate credibility and quality.
Concrete governance standards
Governance is easier to defend when anchored to recognised standards. Examples a design may be asked to align to: ISO/IEC 38505 (governance of data - accountability for how data is collected, used, and retained) and IEEE 7010-2020 (assessing the wellbeing / ethical impact of autonomous and intelligent systems). They operationalise the abstract goals - ethical management, individual-rights protection, accountability, trust - into checkable criteria.
Compliance vs governance vs regulation
A clean way to sort the obligations a scenario hands you is the three distinct categories they fall into. Compliance is conforming to a defined legal or technical standard - a checklist you can be measured against. Governance is the organisation's own ethical, accountable management of the whole AI system - internal frameworks and oversight, broader than any single rule. Regulation is a rule imposed by an external authority that you must follow. They overlap but answer different questions ("Do we meet the standard?", "Are we managing this responsibly?", "Does the law require it?"), and a design usually has to satisfy all three at once. Beyond ISO/IEC 38505 and IEEE 7010, the framework most cited for the risk dimension is the NIST AI Risk Management Framework - a voluntary process to identify, measure, and mitigate AI risk - a governance/risk anchor distinct from data-governance (ISO/IEC) and wellbeing (IEEE). The data-protection regulations a scenario is most likely to invoke are GDPR (EU), CCPA (California), and sector rules such as HIPAA (US health data); the design response is the same whichever is named - classification, residency/sovereignty (Data sovereignty and data gravity), access control, and auditability become constraints. Underpinning all of it are human oversight (a named person accountable for high-impact AI decisions) and bias mitigation (testing models so outputs are not discriminatory) - governance controls a CCDE design is expected to leave room for.
Why it matters for design
The CCDE expects governance and the AI-specific security-policy risks woven into the design - not just the fabric. This connects to zero trust / data protection (Zero Trust and ZTNA, Transport security and encrypted-traffic implications) and to sovereignty (Data sovereignty and data gravity).
Recommendation / justification
Establish data classification + governance (lineage, audit, access), a policy on external AI-service use, and assurance/integrity controls for models and data; map provided regulations to concrete constraints. Justify by IP-protection, compliance, and corporate-credibility risk.
What would change this (mid-scenario twist)
- Sensitive IP + popular external AI tools -> explicit policy + controls on external AI use (DLP, allow-list).
- Regulated/audited sector -> model/data lineage and auditability become mandatory.
Validation checks
- Is there data classification and a policy governing external AI services?
- Are model/data governance (lineage, audit, access, integrity) in place for the regulations provided?
IPv6 / dual-stack note
Governance/policy are address-agnostic; DLP/controls must cover both v4 and v6 egress to AI services.
Related
- Data sovereignty and data gravity
- Zero Trust and ZTNA
- Transport security and encrypted-traffic implications
Spaced repetition
What new corporate-security risk does AI introduce (Exam-Topics 5.1.g)?
IP/proprietary-information leakage - e.g., staff feeding confidential data to external AI services ("shadow AI") or proprietary data entering a model.
AI governance covers [...].
AI governance covers model/data lineage, versioning, auditability, assurance/integrity, and access control.
The control for external-AI-service risk is [...].
The control for external-AI-service risk is a policy on what data may go to which AI + data classification + DLP/allow-listing.
Name two AI/data governance standards a design might align to.
ISO/IEC 38505 (governance of data - accountability for collection/use/retention) and IEEE 7010-2020 (wellbeing/ethical-impact assessment of autonomous and intelligent systems).
Compliance vs governance vs regulation - the distinction?
Compliance = conforming to a defined legal/technical standard (measurable); governance = the organisation's own ethical, accountable management of the whole AI system (internal, broader); regulation = a rule imposed by an external authority. A design usually must satisfy all three at once.
Name the AI risk framework and the canonical data-protection regulations a scenario might provide.
NIST AI Risk Management Framework (voluntary identify/measure/mitigate AI risk - the risk category, vs ISO/IEC 38505 for data and IEEE 7010 for wellbeing); data-protection regulations: GDPR (EU), CCPA (California), HIPAA (US health data).
Sources
- Cisco AI/ML blueprint; responsible-AI / governance and security-policy references.