Short answer: the EU AI Act is the European Union's horizontal law for artificial intelligence. It does not regulate every piece of software touched by AI. It regulates AI systems, general-purpose AI models, and specific uses of AI according to risk.
The question many software teams are asking in 2026 is simple: if a product has AI, is it now regulated in Europe? And if a product has no AI at runtime but was coded with Claude, Codex, GitHub Copilot, Cursor, or another AI tool, does the EU AI Act apply?
The answer depends on what is being placed on the EU market or put into service. The AI Act focuses on the system offered or used, not on the developer's private toolchain. A customer-facing chatbot, AI hiring screener, medical triage model, biometric identification system, credit scoring assistant, or AI product safety component can fall into the Act. A normal website, CRM, mobile app, or backend that was written with AI assistance usually does not become an “AI system” merely because AI helped write the code.
What Is The EU AI Act?
The AI Act is Regulation (EU) 2024/1689. The European Commission describes it as the first comprehensive legal framework on AI worldwide, intended to support trustworthy AI while protecting health, safety, and fundamental rights. Its structure is risk-based: prohibited uses, high-risk systems, transparency obligations, rules for general-purpose AI models, and minimal-risk uses.
The legal definition matters. Article 3 defines an “AI system” as a machine-based system that operates with varying levels of autonomy and infers from input how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. That is broader than “chatbot,” but narrower than “any software.”
The same article defines a “provider” as the person or organisation that develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. A “deployer” is the person or organisation using an AI system under its authority, except personal non-professional use. Those roles decide who carries which obligations.
Does It Start On 2 August 2026?
Not exactly. The AI Act entered into force on 1 August 2024, but its obligations apply in phases. So the clean answer is: 2 August 2026 is a major application date, not the beginning of the whole law.
| Date | What applies | Practical meaning |
|---|---|---|
| 1 August 2024 | AI Act entered into force | The law became part of EU law, but most obligations were staged. |
| 2 February 2025 | Prohibited AI practices and AI literacy duties | Certain unacceptable uses are already banned; organisations using AI need baseline AI literacy measures. |
| 2 August 2025 | Governance rules and general-purpose AI model obligations | Providers of GPAI models such as large foundation models became subject to transparency, copyright, and risk obligations. |
| 2 August 2026 | Most remaining rules, including transparency rules | Chatbot disclosure, synthetic content marking, deepfake disclosure, and much of the enforcement framework become practically central. |
| 2 December 2027 | High-risk systems in certain sensitive areas, after the AI Omnibus political agreement | High-risk uses in areas such as biometrics, critical infrastructure, education, employment, migration, asylum, and border control move to this later date. |
| 2 August 2028 | High-risk AI integrated into regulated products, after the AI Omnibus political agreement | AI used as part of products such as robotics, industrial machinery, lifts, toys, or other regulated products has a longer transition. |
This timeline is important because many summaries still repeat the original 2 August 2026 and 2 August 2027 high-risk dates without reflecting the 2026 political agreement on the AI Omnibus. The safest public statement today is that the AI Act is already in force, applies progressively, and the high-risk timeline is being simplified and extended under the Commission's current AI Omnibus implementation path.
The Risk Categories
The AI Act does not treat all AI the same way. It uses a risk ladder.
The category depends on intended purpose, real deployment context, and the product's effect on people. A model used to summarize a harmless internal note is not the same risk as a model used to rank job applicants, assess creditworthiness, support a medical decision, or control a machine safety function.
What Counts As High-Risk?
Article 6 gives two main routes into high-risk classification. First, an AI system is high-risk if it is a safety component of a product, or is itself a product, covered by EU harmonisation legislation and the product requires third-party conformity assessment. Second, AI systems listed in Annex III are high-risk, unless a limited exception applies because the system does not pose a significant risk of harm and does not materially influence decision-making. If an Annex III system performs profiling of natural persons, it is always high-risk.
Annex III covers sensitive areas such as biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private or public services, law enforcement, migration/asylum/border control, and administration of justice or democratic processes.
For high-risk systems, the practical obligation is not just “write a policy.” Providers and deployers need an auditable operating model: risk management, appropriate training/validation/testing data governance, technical documentation, logging, information for users, human oversight, accuracy, robustness, cybersecurity, post-market monitoring, serious incident handling, and role-specific duties.
How It Affects Products That Have AI
If a product includes AI at runtime, the product team needs to classify it before launch in the EU. The first question is not “which model are we using?” but “what does the system do, for whom, and with what effect?”
| Product type | Likely AI Act angle | Why it matters |
|---|---|---|
| Customer service chatbot | Transparency obligations | Users may need to know they are interacting with an AI system unless it is obvious from context. |
| AI image, audio, video, or text generator | Synthetic-content marking and disclosure | Providers may need machine-readable marking; deployers may need disclosure for deepfakes and public-interest text. |
| Hiring screener or worker-ranking tool | Potential high-risk system | Employment and worker management are Annex III areas, so the system may need high-risk compliance. |
| Medical triage or diagnosis support | Potential high-risk and product regulation overlap | Medical devices and health-related use can trigger sectoral rules and AI Act obligations. |
| Credit scoring or eligibility assessment | Potential high-risk system | Access to essential private services and financial eligibility decisions can affect fundamental rights and opportunities. |
| AI inside robotics, industrial machinery, toys, lifts, or regulated devices | Potential high-risk product-integrated AI | If the AI is a safety component or part of a regulated product requiring conformity assessment, product compliance and AI compliance meet. |
| Internal developer assistant | Usually not high-risk by itself | Risk increases if its outputs are automatically used in regulated decisions or safety-critical systems without controls. |
For Nythral-style product work, the engineering implication is clear: if AI affects user rights, safety, access, eligibility, employment, health, identity, or public-interest information, compliance evidence must be part of the architecture. Logging, model/version tracking, prompt and policy controls, human review, evaluation datasets, incident handling, and vendor documentation are not afterthoughts.
What About Products Without AI, But Built With Claude Or Codex?
A website, app, CRM, database workflow, or backend does not become an AI system just because the developer used an AI coding assistant. The Act regulates the system made available or used, not every tool used during development. If the deployed product has no AI functionality, does not infer outputs from runtime inputs, and does not itself generate predictions, recommendations, content, or decisions using AI, then it is normally ordinary software for AI Act purposes.
That does not mean “no risk.” AI-assisted development still raises legal and engineering issues: IP provenance, license contamination, security review, hallucinated dependencies, vulnerable code, privacy leakage into tools, and auditability of critical changes. But those are not the same as AI Act product classification. They are software governance, security, copyright, data protection, and vendor management issues.
There is one important exception pattern. If the product is marketed as AI, integrates an AI model after launch, uses AI to make decisions, or includes hidden AI features in production, then the product must be classified based on that real functionality. The fact that some code was written by a human and some by AI is secondary.
Known Products That Need AI Act Classification Work
This section is intentionally careful. Saying that a well-known product “falls under the AI Act” does not mean it is illegal, non-compliant, or under enforcement. It means the product category and EU market role are the kind that should be assessed under the Act.
| Known product or product family | Why it should be assessed | Likely classification question |
|---|---|---|
| OpenAI ChatGPT / GPT models, Anthropic Claude, Google Gemini, Mistral models, Meta Llama distributions | They are general-purpose AI model or general-purpose AI system offerings used across many downstream products. | GPAI obligations, systemic-risk designation for the most capable models, downstream-provider obligations, and transparency where deployed to users. |
| Microsoft Copilot, GitHub Copilot, Cursor, Replit AI, JetBrains AI | They generate code or assist professional work; they can be deployed as productivity systems in businesses. | Usually not high-risk merely as coding tools, but vendor transparency, data handling, IP/security controls, and downstream high-risk use need review. |
| Notion AI, Slack AI, Google Workspace AI, Microsoft 365 Copilot | They summarize, draft, classify, and recommend content inside business workflows. | Usually transparency and enterprise governance; high-risk only if configured for Annex III decisions or materially influencing regulated outcomes. |
| Salesforce Einstein, HubSpot AI, Intercom Fin, Zendesk AI | They can generate responses, classify customers, recommend actions, or automate support and sales workflows. | Transparency for user-facing AI; high-risk only if used for sensitive eligibility, essential services, employment, or other Annex III decisions. |
| Workday AI, LinkedIn Recruiter AI features, enterprise HR screening tools | AI used in recruitment, candidate screening, worker evaluation, or employment decisions sits in a sensitive Annex III area. | Potential high-risk classification depending on the exact feature and deployment. |
| Duolingo Max and AI tutoring systems | Education and vocational training can be an Annex III area when AI determines access, admission, evaluation, or learning outcomes in consequential settings. | Consumer language practice may be lower-risk; assessment, admission, certification, or vocational scoring needs stronger review. |
| Tesla Full Self-Driving, advanced driver assistance, robotics and industrial automation AI | AI can be embedded into safety-relevant regulated products. | Product-safety route to high-risk classification, sectoral regulation overlap, conformity assessment, and post-market monitoring. |
| Clearview-style face recognition, biometric categorisation, emotion recognition products | Biometrics is one of the most sensitive areas under the Act and can be prohibited or high-risk depending on use. | Prohibited-practice analysis first; if permitted, high-risk and transparency obligations may apply. |
The right way to use this list is as a classification map, not as an accusation list. The same vendor product can be low-risk in one deployment and high-risk in another. For example, an AI assistant drafting internal meeting notes is very different from an AI system scoring job candidates or deciding whether someone receives an essential service.
What Companies Should Do Now
For any company selling into the EU, serving EU users, or using AI outputs in the EU, the practical first step is an AI inventory. List every system with AI functionality, every third-party AI provider, every model/API used, every user-facing AI interaction, every automated decision, and every workflow where AI materially affects people.
Then classify each system by role and risk: provider, deployer, importer, distributor, downstream provider, GPAI user, transparency-only system, high-risk system, prohibited-risk red flag, or minimal-risk internal tool. This should be tied to the product architecture, not left in a detached policy document.
Penalty Risk
Article 99 sets serious maximum administrative fines. Prohibited AI practices can lead to fines up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher. Other specified breaches, including many operator obligations and transparency obligations, can reach EUR 15 million or 3%. Incorrect, incomplete, or misleading information to authorities can reach EUR 7.5 million or 1%. For SMEs and startups, the Act applies the lower of the percentage or amount in the relevant tier.
These are maximums, not automatic penalties. Authorities must consider circumstances such as gravity, duration, affected persons, damage, organisation size, cooperation, responsibility, negligence or intent, and mitigation steps. But for product teams, the message is still blunt: if a product can affect rights, safety, employment, access, biometric identity, or public-interest information, the engineering evidence has to be real.
The Clean Product Rule
If your product has AI at runtime, classify it. If your product uses GPAI APIs or models, understand whether you are only a deployer or also a downstream provider. If your product affects people in sensitive areas, assume high-risk review is needed until proven otherwise. If your product only used AI during development but ships with no AI functionality, the AI Act usually does not regulate the shipped product as an AI system, though normal software, privacy, copyright, and security duties still matter.
For a serious business, the safest stance is not panic. It is evidence. Keep a product-level AI inventory, design transparency into the UX, avoid prohibited use cases, separate low-risk copilots from high-risk decision systems, record model and prompt changes, preserve logs where appropriate, and review vendor terms before relying on third-party models in regulated workflows.
Sources
- EUR-Lex: Regulation (EU) 2024/1689, official AI Act text
- European Commission: AI Act overview, risk categories, GPAI, timeline, and AI Omnibus update
- AI Act Service Desk: Article 3 definitions
- Article 6: classification rules for high-risk AI systems
- Annex III: high-risk AI system areas
- Article 50: transparency obligations for providers and deployers
- AI Act Service Desk: Article 99 penalties
- European Commission: high-risk AI guidelines and updated enforcement timeline
- AI Act Service Desk FAQ: AI agents, GPAI enforcement, and implementation questions
- European Commission press release: AI Omnibus political agreement, 7 May 2026