EU AI Act

NIST tells you how to organize; regulation tells you what you must do. The landmark is the EU AI Act — the world's first comprehensive AI law, and, like GDPR before it, a de-facto global template because of its reach. Even a US company governs to it if it touches the EU market, and other jurisdictions are echoing its structure. A governance leader must understand its logic, which is elegantly simple: regulate by risk tier.

The four risk tiers

• Unacceptable risk — banned. A short list of prohibited practices: social scoring (by public or private actors), manipulative systems that exploit vulnerabilities, real-time remote biometric identification in publicly accessible spaces by law enforcement (with narrow exceptions), and similar. These simply may not be deployed.
• High risk — heavily regulated. Systems in specified sensitive domains: employment (résumé screening, promotion — Meridian's HR tool lands here), credit and essential services, education, critical infrastructure, law enforcement, and more — plus regulated products like medical devices, which are high-risk via the EU's product-safety route. Permitted, but only with substantial obligations (below). This tier is where most enterprise governance effort goes.
• Limited risk — transparency obligations. Systems that interact with people or generate content: chatbots must disclose they're AI; AI-generated content (deepfakes, synthetic media) must be labeled. Meridian's support agent must tell customers it's an AI. Light but mandatory.
• Minimal risk — largely unregulated. The vast majority (spam filters, recommendation, the analytics assistant). Encouraged to follow voluntary codes; no specific legal obligations.

Provider or deployer? The first question

Before you can know your obligations, answer one question for every system in your inventory: did you build it or buy it? The Act assigns different duty sets to providers — who develop an AI system and place it on the market — and deployers — who use one under their own authority. Getting the role wrong means doing the wrong compliance work entirely.

• Providers carry the heavy build-side obligations for high-risk systems: the risk management system, training-data governance, technical documentation, and the rest of the set below — plus the conformity assessment before market.
• Deployers carry use-side obligations: use the system according to the provider's instructions, assign human oversight to people with the training and authority to intervene, retain the logs the system produces, and inform affected workers and candidates when it's used on them.
• Roles can shift. A company that fine-tunes or substantially modifies a bought model, puts its own name on it, or repurposes it into a high-risk use can become the provider — inheriting the full provider obligations.

Meridian bought its HR screening tool from a vendor, so for that system it is a deployer: its legal duties are to use the tool per the vendor's instructions, put trained humans in the oversight loop, keep the logs, and tell candidates. The vendor owes the conformity assessment and technical documentation — which is why demanding those artifacts contractually (Module 3) is a compliance activity, not procurement hygiene. This course teaches both duty sets, because you will govern systems you bought and, sooner or later, systems you built.

What high-risk systems must do

The provider-side high-risk obligations (Articles 9–15, plus the Article 43 conformity assessment) are, in effect, a governance program specified in law — and they map almost one-to-one onto the technical work of this whole track. If you build a high-risk system, this is your list; if you buy one, this is what you verify your vendor can show:

• Risk management system across the lifecycle (the AI RMF loop).
• Data governance — appropriate, representative, bias-examined training data (Module 3, and the data-quality/lineage discipline the products embody).
• Technical documentation & record-keeping — logs of the system's operation (the audit logs the engineering courses built are literally this requirement).
• Transparency to deployers and clear instructions for use.
• Human oversight — a person able to understand, intervene, and override (the approval gates and human-in-the-loop from the agent course).
• Accuracy, robustness, and cybersecurity — appropriate performance and resilience to attack (evals, red-teaming, the security course).
• Conformity assessment — demonstrating compliance before market, and ongoing.

GPAI, reach, and timing

• General-purpose AI (GPAI) models carry their own obligations — transparency, documentation, and, for the most capable models posing systemic risk, additional safety and reporting duties. If you build on foundation models (everyone in this track), the model provider carries the GPAI obligations; their documentation flows to you through the supply chain — request it and rely on it.
• Extraterritorial reach: it applies to providers and deployers whose systems' output is used in the EU, regardless of where the company sits — the GDPR pattern. 'We're a US company' is not an exemption.
• Phased timeline & real penalties: obligations phase in over time (prohibitions first, high-risk duties later), and non-compliance carries GDPR-scale fines (a percentage of global turnover). As of 2026: the prohibitions and GPAI duties are already in force; the high-risk obligations land August 2026 — check the current timeline, but do not plan as if this is far away. Governance leaders track the phase-in and prepare ahead of each deadline.