Governing the decision, not the code

An auditor asks a simple question: "Show me who approved putting this model into production, and what they looked at before they said yes." The team has the model. They have the code. They have a Slack thread where someone wrote "looks good, ship it." What they don't have is anything that survives the person who wrote that message leaving the company. The approval existed once, as a fact about a moment. Now it exists only as a memory nobody can produce on demand.

The last course, the senior course "Decommissioning legacy systems", spent seven lessons on a version of this problem pointed at code: instrumentation instead of memory, a decision log instead of a lost Slack thread, a runbook instead of "someone will remember the steps." That course and the two before it, "Zero-downtime Rails upgrades" and "Large scale migrations: gh-ost", taught you how to change a production system safely.

None of the three taught you who is allowed to decide a system is safe to change. They didn't cover what has to be written down before that decision counts as made, or how an organization proves its process to someone outside the team that built it. That's a different discipline: governance. This course gives it a name.

What a management system is

"Management system" sounds like software, and it isn't. It's a set of policies, roles and repeatable processes an organization runs, on paper and in practice, to keep making a certain kind of decision correctly as people rotate through the team. ISO 9001 is a management system for quality. ISO 27001 is one for information security. ISO/IEC 42001, published in December 2023, is a management system for AI, and the first international standard of its kind.

The distinction that matters: a management-system standard certifies a process, and never a product. ISO 42001 certification never says "this model is safe". A model can be retrained tomorrow, and the certification says nothing new about it. What it says is "this organization has a repeatable, documented, audited process for deciding what counts as safe, for this model and every model after it." That's a narrower claim than it sounds, and a more durable one. The model changes constantly; the process the organization runs to govern it is what gets audited.

Why certify a process instead of a model

A model's behavior is a moving target: new training data, a fine-tune, a prompt change, a vendor's silent update to a hosted API you call. Any point-in-time claim about a specific model is stale within a release cycle.

What an organization can hold constant is how it decides. Who has to sign off before a model reaches production? What evidence does that sign-off require? How do issues get investigated and fixed, and how does the whole thing get checked and improved on a schedule? ISO 42001 audits that machinery, and no single model running inside it. It's the same logic as auditing a company's expense-approval process instead of re-approving every expense report by hand.

The shape: Plan-Do-Check-Act, clauses 4 to 10

ISO 42001 follows the same skeleton as other modern ISO management-system standards, ISO 27001 among them. It's built around a Plan-Do-Check-Act cycle: plan what you'll do and why, do it, check whether it worked, and act on what you find. That cycle maps onto seven numbered clauses:

• Clause 4, context of the organization: what the organization does with AI, who's affected, what's in scope.
• Clause 5, leadership: top management commits, roles get assigned, an AI policy gets written.
• Clause 6, planning: risk and opportunity assessment, and objectives.
• Clause 7, support: resources, competence, awareness, documented information.
• Clause 8, operation: running the AI system lifecycle day to day. Most of the concrete engineering work in this course lives here.
• Clause 9, performance evaluation: internal audit and management review.
• Clause 10, improvement: nonconformity, corrective action, continual improvement.

Alongside the clauses sits Annex A: a reference list of controls grouped into named areas. It covers things like the AI policy, roles, resourcing, AI system impact assessment, and lifecycle practices such as data governance and third-party sourcing. Annex B gives implementation guidance for the same controls.

An organization doesn't have to adopt every Annex A control. It documents which ones apply, and why, in a Statement of Applicability, the same pattern ISO 27001 uses for its own Annex A. This course treats ISO 27001 as the sibling standard whose Annex A shape ISO 42001 borrows; the senior course "Compliance: ISO 27001" covers its controls in depth.

Two companion standards, mentioned once and set aside

Two more ISO documents come up constantly in ISO 42001 material, and this course names them once so you recognize them, without teaching their content.

ISO/IEC 23894 is guidance on AI risk management: how to think about risk to the organization from an AI system. ISO/IEC 42005 is guidance on AI system impact assessment. That's a related but different question, about effects on people instead of effects on the business, and the next lesson draws a hard line around it. Neither is a certifiable management-system standard; both feed into how an organization meets ISO 42001's requirements.

GDPR, LGPD and the EU AI Act come up in this course only in passing. The senior courses "Compliance: GDPR deep dive", "Compliance: LGPD deep dive" and "Compliance: the EU AI Act" teach them properly.

What you'll work through

• Lesson 2: leadership, the AI policy and the AI system inventory, the one artifact everything else in this course hangs off.
• Lesson 3: risk assessment versus AI impact assessment, and why conflating them is the most common mistake teams make adopting this standard.
• Lesson 4: lifecycle controls: data governance, documented design decisions, testing before release, human oversight.
• Lesson 5: operational records, the evidence trail that turns a claim into an auditable fact, and the release-gate check that reads it.
• Lesson 6: internal audit, management review, nonconformity, corrective action and continual improvement, the Check and Act half of the cycle.
• Lesson 7: putting a small AI management system together in a Rails codebase, and where the next course picks up.

One thing to carry into lesson 2

The Slack thread that opened this lesson had a decision buried in it. It just wasn't recorded anywhere a management system recognizes as evidence. Lesson 2 starts with the artifact that closes that gap for the most basic question of all. The question isn't whether the decision was good. It's whether anyone knows this AI system exists in the first place.