Who must do what, and when

For a high-risk system, the provider (Article 16) owns almost the entire compliance programme:

• Build and run the risk-management system, ensure data governance and technical documentation, keep logs, design human oversight, and hit accuracy and robustness targets.
• Put the system through a conformity assessment, apply CE marking, and register it in the EU database before it goes to market.
• Set up a quality-management system and a post-market monitoring process, and report serious incidents.

The deployer (Article 26), by contrast, has a lighter and more operational set of duties: use the system according to the provider's instructions, assign competent human oversight, monitor how it performs, and keep the logs it generates. Real, but a fraction of the provider's load.

A Singapore company that builds an AI product and sells it into the EU under its own brand is the provider - the role with the heaviest obligations - even with no office in Europe. That surprises leaders who assume a distant vendor escapes the burden. It does not; the burden follows the system.

• A customer in the EU who buys and uses that system is the deployer, with its own lighter duties.
• Because the provider sits outside the EU, the Act generally requires it to appoint an authorised representative inside the EU as a point of contact for regulators.
• Watch the reassignment trap: if a deployer substantially modifies a high-risk system or puts its own name on it, that deployer can become a provider and inherit the heavy duties.

It is tempting to think a company is simply "a provider" or "a deployer", but in practice most organisations hold different roles for different systems, and sometimes several roles for a single one. A firm might be the provider of the hiring tool it sells, the deployer of a vendor's customer-service chatbot it runs internally, and the importer of a third system it brings into the EU on someone else's behalf - all at once. This is why the classification work you started in session 1 is per-system, not per-company: there is no single answer to "what is our role", only "what is our role for this system". The practical discipline is to keep a register that names, for every in-scope AI system, both its risk tier and your role, because those two facts together determine the entire set of obligations you carry for it. Do that once and keep it current, and the rest of compliance becomes a matter of executing against a known list rather than rediscovering your exposure each time a regulator or customer asks.

The Act phases in like this:

• 1 Aug 2024 - entered into force. The clock starts.
• 2 Feb 2025 - the prohibited practices become enforceable, and the AI-literacy duty applies. The banned list is live first.
• 2 Aug 2025 - GPAI model obligations, the governance structure, and the penalty regime apply.
• 2 Aug 2026 - most of the Act applies, including the Annex III high-risk obligations and the Article 50 transparency duties. This is the big one for most companies.
• 2 Aug 2027 - the high-risk rules for AI embedded in already-regulated products (Annex I) apply.

The logic is worst-first: the most dangerous uses were shut down earliest, and the heavy high-risk programme lands later so providers have time to build it. For a typical high-risk system, 2 Aug 2026 is the date to plan around.

As this course is written, the EU has proposed an amendment package - informally the "Digital Omnibus" - that would push the heaviest deadlines back:

• Annex III high-risk obligations may move from 2 Aug 2026 to around 2 Dec 2027.
• Annex I embedded high-risk obligations may move to 2 Aug 2028.
• The package has also floated adding a ninth prohibited practice to the Article 5 banned list.

The staggered timeline is not bureaucratic randomness; it follows a deliberate logic that helps you predict where regulators will focus. The uses the Act judges simply unacceptable - the Article 5 banned practices - were switched off first, only six months after entry into force, because there is nothing to build or phase in: you just stop. The general-purpose model rules and the governance and penalty machinery came next, because the ecosystem needed the enforcement structure and the foundation-model layer settled before the heavy product-level duties landed. The full high-risk programme was given the longest runway because it is genuinely hard to build - a risk-management system, data governance, technical documentation, human oversight, a conformity assessment - and rushing providers into it would have produced paper compliance rather than real safety. For a leader, the practical read is this: enforcement attention tracks the calendar. The banned list is already live and already enforced, so a prohibited use is your most acute exposure today, while the high-risk programme is a build-it-properly project you should be resourcing now against a 2026 or 2027 date. Knowing the order lets you sequence your own work to match the regulator's.