The AI Act is product safety, not data protection

The senior courses "Compliance: GDPR deep dive", "Compliance: LGPD deep dive" and "Compliance: HIPAA deep dive" regulate the same thing from different angles. Each targets a category of data (personal data, health data) and, for HIPAA, a category of entity. The EU AI Act does neither. It's closer in shape to product-safety regulation, the kind that governs medical devices or toys, pointed at software instead of hardware. Carry a GDPR mental model into the AI Act and you skip the two questions that matter.

Two questions, not one

The Act asks what the intended purpose of this AI system is, and what role you play around it. Neither question is "whose data is this". A system can process no personal data and still be high-risk under the AI Act. A model that scores exam answers, or one that controls a factory robot's safety cutoff, touches no PHI-shaped or GDPR-shaped data. Both still sit inside this regulation. Conversely, a system can process enormous amounts of personal data and sit in the Act's lowest risk tier. A recommendation engine picking what to show a logged-in user is one example. Recommending content isn't one of the purposes the Act treats as high-stakes.

This is the core reframe for the rest of this course. The AI Act classifies systems by what they're for, then assigns obligations by who you are in relation to that system. The data flowing through it doesn't decide either.

Risk tiers, in one pass

The senior course "Compliance: the regulatory landscape" introduced this shape at overview depth. It chose to teach the pattern of the staggered timeline instead of a date table. That timeline has already been revised once since the Act was adopted, by an amending regulation in 2026. This course goes one level deeper on both the tiers and the roles, and later lessons build the engineering obligations on top of them.

The Act sorts an AI system into one of four tiers:

• Unacceptable risk: a short list of prohibited practices, banned outright. These systems aren't regulated or burdened with paperwork. They may not operate in the EU market at all.
• High-risk: the Act's heaviest compliance regime. It covers a system whose purpose falls into a listed set of high-stakes use cases, or one that is a safety component of a product already regulated elsewhere. Think of the AI inside a medical device or a lift.
• Limited risk, or transparency obligations: a system doesn't need to be high-stakes to owe people a disclosure. Chatbots and systems that generate synthetic audio, images, video or text carry specific transparency duties, even when nothing else about them is high-risk.
• Minimal risk: everything else, with no AI Act-specific obligations. This is the tier most Rails features land in, and saying so plainly matters as much as explaining the other tiers. A spam filter, an internal search-ranking tweak or a support-ticket triage heuristic doesn't become a compliance project because it uses a model.

Lesson 2 goes deep on what puts a system in each of the top two tiers. It's worth getting right, because a mistake in either direction is expensive. Treating a minimal-risk feature as high-risk burns months of engineering time on controls nobody needed. Treating a high-risk system as minimal-risk is a regulatory violation with real fines behind it.

Roles, in one pass

The second axis is role, and the Act defines several. A provider places a system on the market or puts it into service under its own name. A deployer uses a system under its own authority, in a professional context. Importers and distributors sit in the supply chain between them. Most Rails teams reading this course deploy AI features built on someone else's model. They aren't providers of a foundation model. But lesson 3 covers a rule that flips that assumption more often than teams expect. A deployer can become the provider of a high-risk system by modifying it substantially or by putting its own name or trademark on it. "We're just the customer" isn't a permanent legal position.

GPAI: a third axis for model builders and fine-tuners

Alongside risk tiers and roles sits a separate set of obligations for general-purpose AI (GPAI) models. These are the foundation models increasingly plugged into Rails apps directly. Lesson 4 covers what a provider of such a model owes and the heavier tier for models with systemic risk. It also covers the part that reaches ordinary application teams: how those obligations flow down to anyone building on top of one.

What this course covers

1. This lesson: why the AI Act is shaped like product safety, with risk tiers and roles as the two governing questions.
2. Risk tiers in depth: what puts a system in the high-risk tier, through Annex III use cases and the safety-component route, and what stays minimal-risk.
3. Roles and the deployer-becomes-provider trap: provider, deployer, importer and distributor, and the Act's most consequential "we thought we were the customer" mistake.
4. GPAI obligations: what a model provider owes, the systemic-risk tier, and how those duties reach a team building on top of the model.
5. High-risk obligations as engineering work: risk management, data governance, documentation, logging and oversight. They map onto the ISO 42001 AIMS artifacts from the senior course "AI management system: ISO 42001".
6. Transparency obligations, conformity assessment and enforcement: the disclosure duties that hit ordinary products, plus CE marking, the EU database and who enforces all this.
7. Putting it together: how the AI Act and GDPR apply to the same system for different reasons, and a Rails-shaped checklist.

One note before any of that: nothing in this course is legal advice. AI Act applicability and conformity decisions belong with counsel who knows your system and your role around it. This course teaches the engineering shape of the law well enough that you can have that conversation instead of guessing.