The EU AI Act: What Actually Applies to Your App

Most engineers meet the EU AI Act as a rumour that something is required of them. For a large share of ordinary software the honest answer is that very little is — but working out which share you are in takes two questions, and both are about your application rather than about the model you call.

Treat this as an engineering orientation and not legal advice. The Act is long, its detailed requirements arrive through implementing acts, standards and guidance, and the phase-in has been politically live. Read the current consolidated text and take advice before concluding anything about your own obligations.

First question: which role are you

The Act assigns duties by role in a supply chain rather than by company size or by how much AI you use. The distinctions that matter to most readers:

The trap worth knowing about: a deployer can become a provider. Put your own name on a system, or substantially modify one, or use it for a purpose other than the one it was placed on the market for, and the heavier set of duties can transfer to you. Building a product on somebody else’s model and shipping it as your product is exactly the shape that raises this question — which is why it is worth asking early rather than assuming the deployer answer.

Second question: which tier

The regulation sorts uses by risk rather than by technology, so the answer depends on what your application does, not on which model serves it.

• Prohibited practices. A short list of uses that are banned outright. They concern things like manipulative techniques that cause significant harm, exploiting vulnerabilities, certain social-scoring uses and specified biometric applications. Read the actual list; ordinary business software rarely lands here, and if you think you might, that is the sentence to take to counsel first.
• High risk. Systems used as safety components of regulated products, plus an enumerated set of areas — the recurring themes are employment, education, essential services and credit, law enforcement, migration, and administration of justice. This is where the substantive engineering obligations live: risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness, and a conformity procedure before going to market.
• Transparency obligations. A tier defined by the interaction rather than the domain: telling people they are dealing with an AI system, and marking synthetic content. Treated in detail on the disclosure page.
• Everything else. No specific obligations under this regulation. Note the careful wording: no obligations under this regulation. Data protection law, consumer law and sector rules are untouched and are far more likely to apply to you.

Walking an ordinary application through it

Take a support assistant that answers customer questions from your own documentation. Role: deployer, unless you are marketing the assistant itself as a product under your name, in which case ask the provider question properly. Tier: not prohibited; not high-risk, because answering questions about your product is not one of the enumerated areas; transparency applies, because a user is interacting with an AI system and should be able to tell.

Now change one thing. Have it decide which customers get a refund and which do not, and the analysis shifts — automated decisions affecting people are the direction in which both this Act and data protection law get sharply more demanding. Have it screen job applicants and you are looking directly at an enumerated high-risk area. The lesson is that the tier is a property of the decision your software makes, and it changes when a product manager changes the feature, not when an engineer changes the model.

Which is the practical takeaway: write the tier assessment down per feature, with the reasoning, and re-run it when the feature’s purpose changes. A one-page note per AI feature stating role, purpose, who is affected, what is automated and what a human decides is cheap now and is the document somebody will ask for later.

General-purpose models and the chain

General-purpose AI models get their own regime, aimed at the parties that develop them: obligations around technical documentation, information for downstream providers who build on the model, a policy for respecting copyright law, and a summary of training content, with additional requirements attaching to models presenting systemic risk.

If you call an API you are almost certainly not the party carrying those duties. What matters to you is the second item — that the model provider is expected to supply information downstream — because that information is what you will need if your own use is ever assessed. When you next review a vendor, ask what documentation they make available to downstream providers. It is a reasonable question, it is increasingly a question they should expect, and the answer tells you how much of your own assessment you can source rather than invent.

Timing, and why to check the date yourself

The Act applies in stages rather than all at once. The ordering is the part that is stable and worth remembering: the prohibitions bite first, the general-purpose model obligations follow, and the high-risk regime lands last, with the longest lead time given to systems embedded in already-regulated products.

The specific dates are the part not to take from a summary. They have been the subject of active legislative discussion, they differ by category, and transitional provisions apply differently to systems already on the market. Anyone who needs a date needs it from the current official text — and if a page tells you a deadline without telling you to check it, that is a page written before the last time the schedule moved.