Chapter 11. Takeaway: the compliance operating model and the cross-jurisdictional matrix

The situation at Kompas

Kompas has gone the whole way: it determined it's in scope of the law (ch. 1), classified as high-risk (ch. 2), built the RMS, data governance, documentation, oversight and logs (chapters 3–4), distributed the roles along the chain (ch. 5), closed transparency (ch. 6) and model due diligence (ch. 7), assembled the dossier and certified conformity (ch. 8), sorted out the US, UK and the rest of the world (chapters 9–10). The temptation arises to exhale: "Done."

And here — the main trap of compliance. The product changes, the model under the hood updates, markets are added, regulation moves (Colorado was cut back in two weeks, the Omnibus shifted the dates, Canada dropped its law). Conformity is not a point you arrived at, but a state you either maintain or lose. This chapter is about the mechanism that holds the state.

What the rule says (in summary)

Conformity in the AI Act is by its construction process-based, not one-off: the Risk Management System (Art. 9) is directly described as a continuous process across the whole lifecycle, and post-market monitoring (Art. 72) obliges you to watch the system in operation. A substantial modification of the system (the link to Art. 25, ch. 5) triggers a conformity assessment anew — that is, every major change to the product or the model returns you to part of the obligations. Multi-jurisdictionality (chapters 9–10) adds a second dimension: one baseline plus deltas, which also live and change.

How it lands on the product

Kompas assembles the cross-jurisdictional matrix in full: rows — markets (EU, US states, UK, and onward as it expands), columns — triggers (hiring scoring, chatbot, foundation model), and at the intersection — what is required and the current status. This is the operationalization of the map from chapters 9–10.

On top of the matrix — the compliance operating model: conformity has an owner; a change to the product, a change of foundation model, entry into a new market or a shift in regulation are explicit review triggers, not events that pass unnoticed. The dossier is kept alive: statuses in the registry, not "remembered once a year before the audit." Here the course leans directly on the principle from the root CLAUDE.md — explicit state transitions (status in the registry) instead of logic hidden in someone's head.

The stitch with the neighboring course ai-governance: where this model requires technical implementation — immutable audit logs (ch. 4), continuous quality/drift eval, policy-as-code for classification — it maps onto the control plane. The compliance state is held not by willpower but by infrastructure. The crosslinks are in _crosslinks.md.

The artifact of the chapter and of the whole course is a compliance operating model: a registry of "systems × jurisdictions × statuses" plus a list of review triggers and an assigned owner.

Where it breaks

A matrix without an owner and triggers goes stale. Compliance debt piles up quietly, like tech debt: the model was updated — the bias profile drifted; a market was added — the row in the matrix was forgotten; the law changed — the snapshot went stale. A registry no one is obliged to update is already wrong by the next inspection.

"Substantial modification" is gray again. When an update of the foundation model or a rework of the scoring requires a repeat conformity assessment is a matter of interpretation (ch. 5). The threshold is easy to underestimate and to miss the re-triggering of obligations.

Regulatory drift. New acts, date shifts, laws being cut back — the matrix must have an update process, not be a one-off snapshot. Without that, the "map of the world" from chapters 9–10 ages unnoticed.

What to do as engineer/product

Formalize compliance as a registry with explicit statuses and triggers (a change to the system, a change of model, a new market, a change in regulation), rather than as an annual project with an end date. Assign an owner and tie the review to the release process — then conformity lives in the pipeline, not in the auditor's calendar.

Bring together the artifacts of all chapters (applicability memo, classification record, RMS, technical file, transparency map, due diligence, DoC, the ISO track) into one dossier and one matrix — that is exactly Kompas's working operating model.

Provocation

Compliance is not a project with a completion date, but a property of the product that is either maintained or degrades. A company that "passed the audit" and exhaled is already non-compliant by the next inspection — because the product, the model and the law moved ahead, and no one held the state. The real result of this course is not a passed audit of Kompas, but a mechanism under which Kompas stays compliant while it and the world around it change.

Read next

• All course chapters →
• Connect the expert as an MCP →