An engineering team that ships a capable, well-guardrailed agent can still be building something that is illegal to deploy in a given market, or that exposes the company to fines and forced withdrawal, because technical soundness and regulatory compliance are evaluated by different people against different criteria. A prompt-injection defence that would satisfy a security review says nothing about whether the system falls into a regulatory category that requires a conformity assessment, a registered risk-management process, or a ban outright — and by the time that question reaches an engineering team, it is usually because a legal or compliance function raised it, not because the system design anticipated it.
This lesson exists to make engineers regulation-literate, not regulation-qualified. It covers two frameworks an AI safety engineer will keep running into: the NIST AI Risk Management Framework, a voluntary US framework that shapes how many organizations structure their AI governance regardless of jurisdiction, and the EU AI Act, a binding regulation that assigns obligations by both the AI system's risk tier and the organization's role in the system's lifecycle. Everything in this lesson is engineering guidance about how these frameworks shape system design — it is not legal advice, and a real deployment decision needs a qualified lawyer reading the current text, not a course.
Where a specific article number, exact obligation, or precise compliance date matters, this lesson states it qualitatively rather than asserting a figure that may have shifted since this course was written — EU AI Act implementation timelines have already been amended more than once, and a course that hard-codes a date is a course that goes stale on a schedule it does not control. Treat every specific figure you see cited elsewhere about this Act as something to verify against the current official text before it drives a real decision.