AI Compliance & Governance

Engineering controls stop attacks; governance proves to a regulator, a customer, or a board that those controls exist, are appropriate to the risk, and are actually operating. As AI moves into regulated products, the ability to show this is becoming a condition of doing business. This guide connects the technical work from the earlier lessons to the frameworks and evidence that make it defensible.

Security vs. governance

They answer different questions:

• Security — Is the system hard to attack? (input guards, least privilege, red teaming.)
• Governance — Can we demonstrate the system is managed responsibly across its lifecycle? (risk classification, documented controls, human oversight, monitoring, records.)

You can be secure without being compliant (great controls, no paperwork) or "compliant" without being secure (binders full of policy, no working guardrails). The goal is both, with governance riding on top of real controls rather than replacing them.

The frameworks that matter

Three dominate practice. You rarely pick one — larger organizations map to all three because they overlap heavily.

A pragmatic reading:

• Use NIST AI RMF as your day-to-day operating model — it's the most actionable.
• Use ISO/IEC 42001 to structure the management system if you need certification.
• Use the EU AI Act risk tiers to decide how much of the above a given system needs — a minimal-risk internal tool shouldn't carry high-risk overhead.

None of these tells you how to stop prompt injection. They tell you to identify the risk, apply proportionate controls, and keep evidence. The technical "how" comes from the earlier lessons and OWASP LLM.

A governance operating model

Governance fails when it's a document nobody reads. Make it a loop that produces artifacts as a side effect of shipping.

        ┌──────────── GOVERN ────────────┐
        │ policy, roles, risk appetite    │
        └───────────────┬─────────────────┘
                        ▼
   ┌─────────┐    ┌───────────┐    ┌────────────┐    ┌───────────┐
   │   MAP   │ ─▶ │  MEASURE  │ ─▶ │   MANAGE   │ ─▶ │  MONITOR  │
   │ classify│    │ test /     │    │ mitigate / │    │ logs,      │
   │ + inventory│  │ red-team   │    │ accept risk│    │ incidents  │
   └─────────┘    └───────────┘    └────────────┘    └─────┬─────┘
        ▲                                                   │
        └───────────────── feedback (re-map on change) ─────┘

Each box maps to work you're already doing:

• Map — an inventory of every AI feature with its EU AI Act tier and a threat model (from the Fundamentals guide).
• Measure — the red-team harness and guardrail metrics (attack success rate, false-positive rate).
• Manage — the guardrail stack plus documented decisions to mitigate or accept each residual risk.
• Monitor — production logging of inputs/outputs/tool calls (privacy-safe), drift and incident tracking.

Mapping controls to technical checks

The valuable move is a control mapping: one row per requirement, linking the framework clause to the concrete technical control and the evidence that proves it. This is what an auditor wants and what turns "we're secure" into a defensible claim.

You can bootstrap the self-assessment half of this with the Compliance Self-Assessment tool, then attach evidence to each answer.

Evidence and audit readiness

Compliance is ultimately about evidence that survives scrutiny. Design your pipeline so evidence is generated automatically:

• Version everything — system prompts, guardrail rules, and model versions in git, so you can show what was deployed when.
• Log decisions, not just data — record why a request was blocked or a risk accepted, and by whom. Keep logs privacy-safe: store hashes/metadata and redacted previews, never raw secrets or full PII.
• Automate the reports — CI produces the red-team ASR table and guardrail metrics each release; that is your robustness evidence.
• Keep a decision log — for every high-risk system, a dated record of the risk classification, controls applied, residual risk accepted, and sign-off.

A useful test: if an auditor asked "show me that this feature was risk-assessed, tested against attacks, and has human oversight for destructive actions" — could you produce the three artifacts in minutes? If yes, you're audit-ready. If you'd have to reconstruct them, your governance is theatre.

Where to go next

• Run the Compliance Self-Assessment to baseline your program.
• Revisit GenAI Red Teaming — its ASR reports are your robustness evidence.
• Deep dive: AI security compliance frameworks.

Key takeaways

• Security asks "is it hard to attack?"; governance asks "can we prove it's managed?" You need both.
• Use NIST AI RMF as the operating loop, ISO/IEC 42001 for a certifiable system, and EU AI Act tiers to right-size the effort per feature.
• The core artifact is a control mapping: requirement → technical control → evidence.
• Design pipelines so evidence (versioned prompts, decision logs, CI red-team reports) is a by-product of shipping, not a scramble before an audit.