Chapter 1. Are you in scope: what an 'AI system' is, scope and extraterritoriality

The situation at Kompas

The first conversation about the AI Act at Kompas lasts a minute and ends with nothing. The CTO states what seems obvious: "We don't train the model. All the heavy lifting is at the foundation-model provider's end. We write prompts, tune the ranking and draw the interface. They regulate the people who make models, and we're a thin layer on top." The product is hosted outside the EU, the servers are in another jurisdiction, and so is the legal entity. The team's conclusion: "A European law is for European companies."

Each of these statements sounds reasonable on its own. Together they add up to the most expensive mistake in AI regulation — the belief that the thinness of the integration and the geography of the office take the product out of scope. This chapter breaks down why Kompas is in scope of the AI Act despite everything listed, and gives the first artifact of the compliance dossier — an applicability memo.

What the rule says

The definition of an "AI system" is deliberately broad. Art. 3(1) of the AI Act defines an AI system as a machine-based system that operates with some degree of autonomy, may adapt after deployment, and from input data infers outputs — predictions, content, recommendations or decisions — that influence physical or virtual environments. The definition is aligned with the OECD wording specifically to be technology-neutral and not to age out on the next wave of models. Scoring and ranking candidates fall in without any stretch: a system, based on input (resumes, answers), infers a recommendation (a candidate's rank) that influences a hiring decision.

What is NOT an AI system. The boundary runs along the presence of an "output" and adaptivity. Pure deterministic rules, classic scripts, simple descriptive statistics, plain optimization — not AI in the sense of the law. The temptation for teams is to re-describe their product as a "set of business rules" in order to fall out of scope. But as soon as there is a model in the loop that generalizes and infers a score, "it's just rules" doesn't hold. Kompas ranks not by a rigid formula but by learned patterns — that is AI.

Material scope and exemptions (Art. 2). The law applies broadly to providers and deployers of AI systems, but with carve-outs: systems exclusively for military and national security purposes; pure scientific R&D before it is placed on the market; personal non-professional use by individuals. None of the carve-outs applies to a commercial HR SaaS.

Extraterritoriality — the key point. Art. 2(1) directly extends the law to providers and deployers located outside the EU if the output of the system is used in the EU. It is the same move that made GDPR a global standard: jurisdiction is determined not by where the server sits, but by where the output touches people. Kompas sells to European recruiters, its ranking influences hiring in the EU — therefore it is in scope, wherever its servers stand.

Roles at the entrance. Already here it matters which role you enter the law as — provider (develops and places the system on the market under its own name) or deployer (uses it under its own responsibility). This determines both applicability and the set of duties. The full breakdown of roles is ch. 5; at this step it's enough to record that Kompas places its own product on the market under its own brand, i.e. enters as a provider.

How it lands on the product

The conclusion for Kompas is unambiguous: it is in scope of the AI Act. Hosting outside the EU doesn't save it, the thinness of the layer over someone else's model doesn't save it, "we didn't make the model" doesn't save it. The trigger is European clients and the output's influence on hiring in the EU.

The chapter's artifact is an applicability memo, a short one-page note: "are we in scope of the AI Act and why." It is the first document of the compliance dossier, the one you'll return to at every inspection and in every RFP. The second output is an inventory of AI components: not "is the product regulated," but line by line — how many separate AI functions the product has (scoring, chatbot, generation of email text) and, for each, an answer to two questions: is it an AI system? is its output used in the EU? Without such an inventory you can't classify risk (ch. 2) — because it's not the product as a whole that gets classified, but each function.

Where it breaks

The "AI system vs ordinary software" boundary. The murkiest zone is hybrids, where the AI component is small and there is a lot of deterministic logic around it. Where a business rule ends and regulated AI begins is a matter of interpretation, and there is little practice yet. The survival rule: you may interpret in your favor only what is genuinely deterministic; anything that generalizes and infers, treat as AI.

Conflating the "model vs system" levels. The foundation model under the hood (GPAI) and the product on top of it are regulated on different tracks (chapters 5 and 7). At this step it's easy to lump them together and decide "since the model is someone else's, the liability is someone else's." No: the system on top of the model is your product and your liability as the provider.

The temptation of the "R&D" exemption. The exemption for scientific research is narrow and applies only until the product is placed on the market or put into service. As soon as the product is sold or used in production — the exemption doesn't apply. A pilot with a real client on real candidates is no longer R&D.

What to do as engineer/product

Compile a registry of the product's AI components before any architectural and product decisions, and for each component answer: AI system? used in the EU? That's ten minutes of work that determine the entire downstream regime.

Don't build the compliance strategy on the thesis "we're just a wrapper." The thinness of the integration is not a legal argument. If the product produces an output that affects people in the EU, geography and the volume of your own code don't matter.

Provocation

"We're just a wrapper over a model" is the most expensive phrase in AI regulation. It calms the team right up to the moment a European client asks for proof of conformity in the contract, and there is none, because for six months everyone was sure the law wasn't about them. The law looks not at how many lines of code you wrote and where your server sits, but at what your product does to people and where its output is used. By that criterion Kompas is inside, and the conversation about the AI Act begins not with "are we in scope" but with "which risk class."

Read next

• Next: Risk class — Risk class decides everything: high-risk under Annex III
• All course chapters →
• Connect the expert as an MCP →