What the EU AI Act Actually Requires, and Who It Applies To

The EU AI Act sorts every AI system into one of four risk tiers, unacceptable, high, limited, or minimal, and the tier determines what you legally have to do. Unacceptable-risk uses (social scoring, untargeted biometric scraping) are banned outright. High-risk systems, which cover most hiring, credit, healthcare, and law enforcement use cases, need documented risk management, human oversight, and audit trails before they touch production. Limited-risk systems like chatbots just need to disclose they're AI. Minimal-risk stuff, spam filters and the like, isn't regulated at all. The full breakdown lives on artificialintelligenceact.eu's summary, which is the clearest public explainer of the tiers.

The Act also splits obligations between "providers" (whoever builds or places the AI system on the EU market) and "deployers" (whoever uses it operationally). If you commissioned a custom agent from a vendor, you're likely the deployer, but you inherit real obligations too, and if the vendor didn't build the system to be auditable, you're stuck. The regulation's full text and effective dates sit on the European Commission's official AI Act page, which is worth bookmarking over any third-party summary since the Commission updates guidance as enforcement rolls out.

Does the EU AI Act Apply to US and Singapore Companies?

Yes, if your AI system's output touches the EU market, regardless of where your company is headquartered. This catches more companies than most operators expect. A US SaaS product with EU customers is in scope. A Singapore-based firm running an AI agent that screens job applicants who happen to include EU residents is in scope. The trigger isn't your address, it's where the output lands.

This is different from how most US and Singapore founders think about compliance. GDPR trained everyone to ask "do we store EU personal data." The AI Act asks a broader question: "is an AI system's decision or output being used by, or about, someone in the EU." You can be fully US-based, have no EU office, and still be a "provider" or "deployer" under the Act the moment an EU customer interacts with your agent's output. If you're building or buying AI that touches hiring, lending, insurance, or healthcare workflows and any of your customer or employee base includes EU residents, assume you're in scope until a lawyer tells you otherwise.

The 2025-2027 Compliance Timeline You Actually Need to Track

Four dates matter, and only one of them is still ahead of you in a way that requires real preparation. Prohibited practices and AI literacy requirements took effect February 2, 2025. Obligations for general-purpose AI models, the GPT-4 and Claude-class systems underneath most agents, took effect August 2, 2025. The next major phase, and the one everyone building agents right now should be planning for, is high-risk system obligations landing August 2, 2026. Remaining provisions phase in around August 2027.

Search interest in "eu ai act deadlines" is up roughly 150% year over year, the strongest momentum signal in this entire topic cluster, which tells you compliance leads and operators are only now starting to plan for the August 2026 date instead of the earlier ones. Deloitte's own analysis of the phased rollout, at their EU AI Act page, frames August 2026 as the deadline that will actually force architecture changes at most companies, since it's the first phase that reaches deep into how systems are built rather than just what they're allowed to do.

If you're building a custom agent today that will touch hiring, credit, insurance, or healthcare decisions and might see an EU user before mid-2026, you don't have 18 months. You have however long it takes to redesign a system that was built without documentation, logging, or human-oversight hooks in mind, and that's usually longer than people think.

What Counts as "High-Risk," and Why Most Custom AI Agents Land There

Most of the agents companies are building right now fall into the high-risk tier without anyone realizing it. An agent that screens resumes, scores loan applications, triages insurance claims, or flags patients for follow-up is doing exactly what the Act's Annex III lists as high-risk: decisions that materially affect a person's access to employment, credit, insurance, or healthcare. It doesn't matter that the agent is "just automating a workflow." If the workflow decides who gets hired, who gets a loan, or who gets flagged for care, the Act treats it as high-risk regardless of how casually it was built.

This is where the SERP's existing coverage falls short for an operator. IAPP's compliance matrix lists the categories accurately, but it's written for a compliance officer inside a large enterprise, not a founder who just approved a vendor's proposal to build an applicant-screening agent. The practical takeaway: if your agent touches hiring, lending, insurance underwriting, or clinical triage, assume high-risk obligations apply and build the documentation trail from day one. Retrofitting it later, after the system is live and the vendor is gone, is far more expensive than building it in.

Why Your AI Vendor's Architecture Is Your Compliance Exposure

This is the part almost nobody writing about the AI Act says out loud: your compliance exposure under this law is mostly a function of how your vendor built your system, not a function of how carefully your legal team reads the regulation. High-risk obligations require technical documentation showing what data trained or fine-tuned the system, logging that lets you reconstruct why a given decision happened, and human-oversight mechanisms that let someone actually intervene. A black-box SaaS AI feature, where you don't know what model is running, what data touched it, or how outputs are logged, makes every one of those requirements close to impossible to satisfy. You can't document what you can't see.

A self-hosted, open-source model running on your own infrastructure with zero data retention gives you the opposite position. You control the training data provenance, you own the logs, and you can point to exactly what happened at each step. This is the same lens we use at Genta when we default to self-hosted, zero-retention deployments for regulated clients, not because it's trendy, but because it's the only architecture that actually produces the audit trail the Act demands. When we built out automated document intake and case-assignment agents for Preferred Med Network, the exception-routing logic that flags low-confidence cases for human review wasn't an afterthought bolted on for compliance. It was the design, because in a regulated operational context, "the AI decided" is never an acceptable answer on its own.

The NIST AI Risk Management Framework, which most US companies default to, is voluntary. The NIST AI RMF gives you a structured way to think about risk, but nobody fines you for skipping it. The EU AI Act is legally binding, with real penalties, and it doesn't care whether your compliance program was voluntary somewhere else. That gap between "good practice" and "legal requirement" is exactly where vendor architecture decisions turn into liability.

What to Ask Before You Sign (or Renew) an AI Vendor Contract

Before signing or renewing an AI vendor contract, get direct answers to five questions, in writing, not in a sales deck. First, does this system fall into a high-risk category under the Act's Annex III list, based on what it actually decides, not what the vendor calls it. Second, where does the training and inference data live, and who has access to it. Third, can the vendor produce technical documentation and decision logs on request, or is that a "roadmap item." Fourth, what's the human-oversight mechanism, and can a person on your team actually intervene before a high-stakes decision ships. Fifth, if the vendor's system turns out to be high-risk and they didn't disclose it, who's liable, you as deployer or them as provider, and does the contract say so explicitly.

Most vendor contracts we've reviewed don't answer any of these clearly, because most vendors weren't building for the Act's timeline when they wrote the boilerplate. We've written a longer checklist covering this exact negotiation, including the specific clauses to push for, in what to ask an AI vendor before you sign the contract. The short version: if a vendor can't answer the five questions above without stalling, that's the answer.

What Happens If You Don't Comply

Penalties scale with the violation, and they're not symbolic. Prohibited practices, the outright-banned uses, carry fines up to €35 million or 7% of global annual turnover, whichever is higher, according to the European Commission's regulatory framework page. Violations of high-risk obligations, the documentation, oversight, and risk-management requirements most companies will actually run into, carry lower but still material fines. For context, 7% of global turnover for a $30M revenue company is over $2M, a number that changes the math on "we'll deal with compliance later."

The uncomfortable part isn't the fine amount, it's that liability doesn't disappear just because you outsourced the build. If your vendor built you a high-risk system and didn't tell you, you're still the deployer, and deployers carry real obligations under the Act, including monitoring the system's performance and reporting serious incidents. "We didn't know" is not a defense the Commission has shown any interest in accepting. The EU's own compliance checker tool is a reasonable first pass to self-assess where your system lands, but it won't catch a vendor's undisclosed architecture choices, only your own diligence will.

Getting the Diagnosis Right Before You Scale

The pattern across the Act, and honestly across most regulatory frameworks we've seen clients navigate (Colorado's new AI law being the closest US analog, MAS's guidelines being the closest Singapore one), is that compliance exposure is decided at build time, not audit time. You either built a system you can document and explain, or you didn't, and no amount of legal review after the fact changes which one you have. We've covered the same architecture-first logic for Colorado's AI Act requirements and for Singapore's MAS risk management guidelines, and the throughline holds across all three: the law changes, the underlying question doesn't.

There's also a quieter cost worth naming. Undocumented, black-box AI systems don't just create legal exposure, they create insurance exposure too. We've written separately about what your AI architecture means to an underwriter, and the short version is that the same documentation gaps that trip up regulators also drive up premiums or get you declined coverage outright.

If you're staring down an August 2026 deadline and you're not sure whether your current AI vendor's architecture would survive an audit, that's exactly the kind of question our Discovery phase is built to answer before you scale any further, and you can compare notes with us here.

Frequently asked questions

Does the EU AI Act apply to US companies?

Yes. The Act applies based on where an AI system's output is used, not where the company is headquartered. A US company with no EU office is still in scope if its AI system's decisions affect people in the EU, whether that's customers, job applicants, or patients. Headquarters location doesn't matter; output location does.

How do I comply with the EU AI Act?

Start by classifying your AI system's risk tier under Annex III, then build the documentation, logging, and human-oversight mechanisms the Act requires for that tier. For high-risk systems, that means audit trails showing training data, decision logic, and intervention points. The EU's compliance checker is a reasonable starting self-assessment.

Is the EU AI Act mandatory?

Yes, unlike the US's NIST AI Risk Management Framework, which is voluntary guidance. The EU AI Act is binding law with enforceable penalties up to €35 million or 7% of global turnover for the most serious violations. There's no opt-out for companies whose AI output reaches EU users.

What are the main points of the EU AI Act?

It classifies AI systems into four risk tiers (unacceptable, high, limited, minimal), assigns different obligations to "providers" who build systems versus "deployers" who use them, and phases in enforcement between February 2025 and August 2027. High-risk systems, covering hiring, credit, insurance, and healthcare decisions, face the strictest documentation and oversight requirements.

What happens if my AI vendor built a high-risk system and didn't tell me?

You're still liable as the deployer. The Act assigns deployers real obligations, including monitoring performance and reporting serious incidents, regardless of what the vendor disclosed. This is why vendor contracts need explicit language on risk classification and liability before you sign, not after regulators come asking.