Skip to content
④ Governance & Compliance

④ Governance & Compliance

The goal of this section is not to make you a compliance officer. It is to make you the rarer and more valuable thing: an engineer who can translate an agent’s technical failure mode into the language that decides budgets, launches, and legal exposure.

Why translation is the scarce skill

When a new agentic capability is proposed — a support agent with refund authority, a code agent with repository write access, an ops agent with cloud API keys — the questions that stop the project are always the same:

  • If this goes wrong, what exactly is the harm, and to whom?
  • Which standard or regulation does that harm fall under?
  • Are our current controls sufficient, and if not, what is missing?
  • When it fails, who notices, who stops it, and how fast?
  • How do we prove any of the above to an auditor six months from now?

Plenty of people can explain how indirect prompt injection works. Far fewer can answer those five questions in a single page that a general counsel, a product lead, and an SRE all accept. That gap is where governance-literate engineers get hired.

This section rewards structure over memorization. Nobody will ask you to recite the four NIST AI RMF functions. They will ask you to take one real agent and produce a document that maps its risks to a framework, assigns owners, and defines the evidence that proves each control works. Practice the output, not the vocabulary.

What this section covers

  1. NIST AI RMF — the Govern / Map / Measure / Manage structure, and how to run it on an agentic system rather than a static model.
  2. EU AI Act — the risk-tier classification, what obligations attach at each tier, the obligations that hit general-purpose and agentic systems, and where the timeline stands.
  3. ISO/IEC 42001 — the AI management system standard: what certification actually requires, and how it differs from a framework you can simply “follow”.
  4. Evidence Automation — building the audit trail as a product feature: inventory, traces, approvals, and policy-as-code that generate compliance evidence continuously instead of during a quarterly scramble.

What you should be able to produce afterwards

By the end of this section you should be able to take any agentic feature and, in a couple of hours, produce:

  1. A risk statement in business terms with a plausible worst case and a rough likelihood band.
  2. A mapping from each risk to an OWASP class and a MITRE ATLAS technique.
  3. A control set organized under the NIST AI RMF functions, each with a named owner.
  4. A regulatory read: which tier under the EU AI Act, which ISO/IEC 42001 clauses are touched.
  5. A defined evidence artifact per control — a specific log, trace attribute, or approval record that proves it is working.

That five-part document is the AI risk register, and it is one of the strongest portfolio pieces you can hold in an interview. Lab 5 walks through building one for an agent you wrote yourself.

Regulatory timelines, guidance documents, and framework versions change frequently, and national implementations differ. Treat every date and obligation in this section as a pointer to the primary source, not as legal advice — always confirm against the official text linked in Standards & References.