The missing half of AI governance

The senior course "AI management system: ISO 42001" closed with a confession. Seven lessons built an inventory, a policy, an impact assessment, an evidence trail, a release gate and an audit cycle. Together they make a machine for reaching a defensible decision about an AI system, again and again, as people rotate through the team. Then the last lesson said plainly that it never told you which laws that machine has to satisfy. It taught you how to prove a decision was made carefully. It didn't teach you what the decision has to get right.

That gap isn't an oversight. It's a different discipline, and this course gives it a name: regulatory compliance. A management system is process; a regulation is law. You can run a flawless process and still violate a statute you never checked. The process told you how to decide, and the statute tells you what the decision is allowed to be. An engineering team that built ISO 42001's release gate and stopped there has a well-documented way of shipping something that gets the company fined.

Why "are we compliant?" is more than one question

Ask a room of engineers "are we GDPR compliant?" and then "are we SOC 2 compliant?", and most will answer both the same way: a yes or no, a checklist, a badge on the website. They're different kinds of question.

The first asks whether you obey a law that binds you whether you like it or not, with a regulator who can fine you if you don't. The second asks whether an auditor who spent weeks watching your controls run would sign a report saying they worked. You show that report to a customer, and no government is involved. Confusing the two is the most common mistake a senior engineer makes here, and it's why this course comes before any of the deep dives.

Six regimes, six different kinds of thing

This course isn't a summary of six regulations. Six deep-dive courses follow it, and each will teach its regime better than any survey chapter could. What only this course gives you is the map. For each name a Rails engineer hears in a compliance conversation, it tells you what kind of instrument it is, because the kind decides what "comply" means.

GDPR and LGPD are laws with a legislature behind them. A regulator can open an investigation and fine you whether or not you ever asked for its opinion.

HIPAA is also a law, but it reaches you only if you fall inside a specific, defined population: you handle a defined category of health data on behalf of a defined kind of entity.

The EU AI Act is a newer shape again. It doesn't protect a category of data; it classifies a system by risk and assigns obligations to whoever plays which role in building or using it. In spirit it's closer to product-safety regulation than to a privacy law.

ISO 27001 and ISO 42001 are standards you choose to be measured against. Nobody fines you for skipping them, but a certificate, or its absence, becomes a fact a customer or a court can point to.

SOC 2 Type II is neither a law nor a certificate. It's an independent auditor's written opinion on whether your controls worked over a period of months, and its only audience is whoever you hand the report to.

The question this course answers

Each of those five categories eventually asks the same underlying question in different words: does this system, this data, this company fall inside my scope? That's a routing problem. Given facts about what a Rails app does, which regimes does it need to satisfy, in what role, and what evidence will each demand? Lessons 2 to 6 each take one regime and answer that for it. Lesson 6's challenge puts that routing logic in code.

What you'll work through

• Lesson 2: GDPR and LGPD. What triggers them, who counts as a controller or a processor, and why "we're not based in the EU" or "we're not a Brazilian company" isn't the defense engineers think it is.
• Lesson 3: HIPAA. Covered entities, business associates, the business associate agreement, and what counts as protected health information.
• Lesson 4: the EU AI Act. Risk tiers, the roles (provider and deployer), and why its obligations arrive on a staggered timeline.
• Lesson 5: ISO 27001 and ISO 42001 as certifiable management standards. What a certificate claims, what an auditor checks, and how 42001 leans on 27001's control shape.
• Lesson 6: SOC 2 Type II. The Trust Services Criteria, Type I versus Type II, and why a report isn't a certificate.
• Lesson 7: where these six regimes overlap in the evidence they demand, what that overlap means for a Rails codebase, and which course covers each regime in depth.

One thing to carry into lesson 2

None of the deep dives that follow will ask "is this data protected?" Each will ask a narrower, more answerable question: whose data, held by whom, in what role, offered into what market? That reframing, from "are we compliant?" to "which specific questions bind us, and as what?", is the skill this course teaches. Lesson 2 starts with the two regimes engineers reach for first, and with a trigger that isn't what most engineers assume.