Executive Summary
The Brussels Effect is Real: Non-EU developers are legally liable if their model’s outputs are used within the EU. Geography won’t grant you immunity, and technical workarounds such as IP (Internet Protocol) blocking or legal contract disclaimers are not sufficient protection.
Large Penalties: Non-compliance can result in large fines reaching up to €35 million or 7% of global annual turnover, which scales significantly higher than existing GDPR limits.
Roles and Responsibilities: The AI Act has clearly defined roles within the supply chain, knowing whether you are a “Provider”, “Deployer”, or “User” will be key as the obligations differ significantly.
Strict Systems Classifications: Different AI systems are categorised into risk hierarchies which are: Unacceptable Risk, High Risk, Limited Risk, and No Risk. These are grouped according to their use case meaning it is not the how but the why/purpose that is important. Systems such as social scoring, and workplace emotion detection are banned, others such as recruitment require heavy regulation, and systems such as spam filters are unregulated.
Frontier Models won’t Shield you from RIsk: If all you are doing is sending API calls to foundational models (e.g. GPT-5.6, or Fable) doesn’t mean you are absolved from regulation. You inherit liability.
Proactive Architectural Action is the Best Solution: Adhering to the AI Act is not exclusively a bad thing. It can be seen as the impetus needed to get ahead of the curve and to protect your system (and your users/customers) from exploitation.
Key Deadlines:
2 August 2026 — Requirements for Transparent Use of AI systems
2 December 2026 — GenAI Porn ban and Synthetic Grace Period Ends
2 August 2027 — High Risk Systems and GPAI Grace Periods Expire
2 December 2027 — Mandatory compliance begins for standalone High-Risk AI systems.
Why Does an EU Law Impact Builders Globally?
If you aren’t an AI developer based in the EU you might not have heard of the EU’s AI Act yet but its effects are about to spread, just as GDPR did years ago. This is known as the Brussels effect and refers to the EUs ability to set global regulatory standards as many companies find it more cost effective to apply EU standards rather than maintain different rules for different countries. In particular there are two main ways the Brussel’s effect spreads outside of company’s business logic.
I. The Myth of Geographic Immunity
Geography won’t grant you immunity if your model’s output impacts someone physically in the EU, your model is subject to the law. However the Future of Life Institute (FLI) has been quite helpful, they’ve produced a 10 minute summary alongside a compliance checker to help. These are well worth a look but I will summarise my take home findings here.
So how can EU regulations affect organisations that aren’t even in the EU? Article 2(1)(c) of the AI Act states:
This Regulation applies to: (c) providers and deployers of AI systems that have their place of establishment or are located in a third country, where the output produced by the AI system is used in the Union;
In short, if the output of your AI system or model is consumed in the EU you are bound by the Act.
II. The Global Ripple Effect
Many countries also tend to either adopt similar regulations or use EU regulations as a guide. The best example for this is GDPR, some countries adopted full GDPR regulation (e.g. neighbouring countries such as the UK, Serbia, and Moldova), or have strongly GDPR-influenced regulation (e.g. Japan, South Korea, and India). This effect can even spread to the US where several states have adopted very similar legislation too (e.g. California, Colorado, Texas).
III. The Wider EU Regulatory Framework
The EU AI Act doesn’t exist in a vacuum. When building, AI developers need to navigate a broader ecosystem of EU regulations. Depending on how and where your system is deployed, your build may fall under the remit of the GDPR (data privacy), Digital Services Act, the EU Data Act, alongside standard product liability and intellectual property laws.
1.1 Different Set Ups, Different Rules
This means any builder needs to be mindful of how their systems are deployed. Imagine a Hong Kong-based developer creates a custom machine learning tool to screen CVs for a corporate client in Singapore:
Exempt from the EU AI Act: The client’s head office pulls the CV of an applicant residing in Spain to hire them for a local role in Singapore. Because the hiring decision is ultimately taken by the HR team in Singapore the AI Act doesn’t apply.
Covered by the EU AI Act: The same client has a subsidiary branch in Dublin. The Dublin office runs your model locally to screen applicants before sending the shortlisted candidates back to Singapore. Because an EU-established entity ran the software and used the outputs, the system is under the remit of the AI Act.
Essentially, it’s about who presses the button, and where the legal entity is registered. Therefore, if you are an external developer, you could be held viable via contract chains, even if you had no idea your client intended to deploy your tool within the EU market. You need to explicitly restrict your software’s geographic deployment, or ensure that your pipelines comply from day one. As a guide, here’s a table to show when it is covered and isn’t:
1.2 The Financial Stakes: Why Regulatory Risk Cascades Down the Supply Chain
Whether you are an enterprise deploying AI tools, a SAAS founder, or an upstream software vendor, the financial risks of non-compliance spread through every commercial agreement.
Under Article 99, the AI Act’s financial penalties are incredibly punitive, scaling beyond the penalties for GDPR non-compliance:
Large Enterprises: Fines scale up to €35 million or 7% of total worldwide annual turnover (whichever is higher). This means that for a global corporate entity, the final penalty can easily blow past the cap.
SMEs and Startups: To try and protect the broader tech ecosystem, the penalty is capped at whichever is lower.
Nevertheless, direct regulatory intervention from the EU is only half the threat. In reality, the immediate financial risks are likely to emerge through commercial pressure on the supply chain.
For Enterprise Deployers: Corporate legal and procurement departments are under strict mandates to reject any vendor, platform, or tool that lacks a verifiable compliance trail. Deploying a non-compliant model or system, even from a third party vendor, exposes the enterprise directly to statutory liability.
For Builders and Software Vendors: Clients with a halfway competent lawyer will actively insulate themselves by writing or rewriting Master Service Agreements (MSAs) or Statements of Work (SOWs) that demand explicit compliance warranties and pushing indemnification clauses onto developers.
1.3 The Flimsy Defense: Why IP (Internet Protocol) Address Blocking and Contract Clauses Fail
Usually our instincts are to look for quick engineering or legal backdoors. The two most common shortcuts are actually dangerous myths:
Myth 1: We can just block European IP (Internet Protocol) addresses
Geoblocking only shields you if you are running a simple, direct-to-consumer web application. If you are building B2B infrastructure, enterprise APIs, or backend data processing pipelines, data effortlessly bypasses network-level blocks. If an enterprise client in Singapore pulls data from a European subsidiary and passes it to your backend via an internal global workflow, your AI’s output is still driving decisions in the EU. Network-layer geoblocking won’t save a broken data architecture.
Myth 2: We can just put “Not for EU use” in the software contract
The non-lawyers amongst us might be tempted to just add a simple clause into our MSAs or SOWs stating “This software is strictly prohibited from use within the European Union”. But regulators have a very clear stance on this established principles of EU law (e.g., Rome I Regulation, Art. 9 on Overriding Mandatory Provisions) private commercial contracts cannot override public statutory law, regardless of what you and your client agreed on privately.
Even if your client broke the contract, your indemnity clause is unlikely to protect you. Global enforcement means:
The EU still will penalise you: The EU AI office will still fine your firm or ban your software from operating in the EU market.
You now have a secondary legal battle: Your contract clause doesn’t stop the EU fine, it most likely only gives you the right to launch a separate expensive lawsuit against your client in whichever jurisdiction you agreed on to try and claw that money back after the money has been paid. And if your client goes bankrupt under the weight of the fines and legal costs, you won’t recoup any money.
Furthermore, the Act explicitly holds developers liable for “reasonably foreseeable misuse”. If you hand over a globally capable enterprise tool to an international client with zero technical restrictions, a judge will view a boilerplate contractual restriction as willful ignorance, not a legal defense.
1.4 Aligning Legal Logic with Technical Architecture
An indemnity clause doesn’t make you immune to European penalties; it just gives you the right to sue your client after your software has been banned and your firm has been penalised. If you want to restrict your software geographically, your legal contracts must match your technical architecture by combining strict SOWs with hard code boundaries like token restrictions, localised data parsing nodes, and explicit geographical routing.
In fact (and I am not a lawyer so don’t take this as legal advice), the only ways in which you as the developer can become immune is if your client has made a “substantial modification” to the software, or they rebrand it under their trademark without stipulation in your contract.
Regulatory Precedent
Although last month the EU parliament announced that some portions of the Act have been delayed until 2 December 2026 (e.g. high-risk AI systems), while others have been pushed back to 2 December 2027, this doesn’t mean that we can ship non-compliant models now. Firstly, several aspects are already in full effect. Secondly, existing laws are already being used to penalise tech firms, meaning this legislation is far from hollow, and EU authorities appear to be willing to enforce these rules.
Early Enforcement: The EU Commission vs. X
The most high-profile tale is the dual tracking of X and TikTok charged by the EU commission. While TikTok offered structural concessions to settle, X seemed to lean into the regulatory chaos primarily driven by its Grok chatbot ecosystem. Regulators mounted several accusations against the platform across several legacy infractions:
Scraping data without consent: Irish regulators successfully used GDPR to stop X from scraping and training Grok on European users’ public posts without obtaining an explicit opt-in consent.
The Systemic Risk Investigation: The European Commission launched a formal Digital Services Act (DSA) probe after Grok’s image-generation features were easily manipulated into producing unwatermarked, highly realistic, non-consensual sexual deepfakes of public individuals and minors.
Algorithmic Complicity: Dramatically X’s offices in Paris were raided by French police as part of a probe into whether Grok was complicit in holocaust denial. This was caused by users causing Grok to generate illegal holocaust-denial text, which the automated systems then amplified by sending it to the algorithmically-driven feeds of its users.
To date, there has been a high financial fallout. At a minimum X is staring down a baseline €120 million DSA fine, a compounding criminal defense budget against Europol and French prosecutors (on top of OFCOM enquiries in the UK), and an exodus of corporate Ad spend. Locally, X’s UK revenue has dropped by 60% year-on-year, and globally these controversies seem to have stalled what was looking like a recovery to pre-acquisition 2022 revenue levels.
The takeaway for developers is this: if your model generates outputs that violate the spirit of European safety mandates, local authorities will not wait for the AI Act’s 2027 grace periods to expire. They will bypass the delays, use existing statutory weapons, and go straight for your software’s engineering foundations. And I suspect many of us lack the strategic depth of X’s reserves to fight a complex multi-jurisdictional battle (one can but dream).
Does Using Frontier Models Shield You from the Act?
3.1 Liability Traps
If you and/or your team are building applications that plug into third-party foundational models via APIs (e.g. OpenAI's GPT models, or Anthropic’s Claude), you might think you’ve also outsourced your compliance responsibilities alongside your infrastructure. In other words, it would make sense that the parties that build and maintain the models are responsible for its AI compliance. However, under Article 25 of the AI Act, there are some ways in which you can suddenly inherit the legal liability of an AI provider:
You put your name or trademark on a “high-risk AI system” (we will get to this later). In other words you are a wrapper for ChatGPT / Claude.
You’ve made substantial modifications to a high-risk AI system that has already been placed on the market, and it remains a high-risk AI system.
You modify the intended purpose of an AI system such that it becomes a high-risk AI system.
3.2 Why LLMs Prompt Injection and Structural Vulnerabilities Are Your Problem
Particularly for point 1 above, we’ve seen the humorous aspects of users hijacking McDonald’s chatbot to reverse a linked list. But, what happens if there’s a vulnerability such as the breach involving Amazon Q, where an exploited repository vulnerability put nearly one million developer environments at risk?
Under the AI Act, if your custom application or API layer has been manipulated into violating safety, copyright, or privacy mandates you can be held legally liable, even if the underlying vulnerability or prompt exploit originated with your LLM provider.
3.3 Compliance Gap in Frontier LLMs
Furthermore, relying on “Big Tech” to handle your regulatory compliance is incredibly risky. According to the LARA benchmark audit published by the research foundation Aithos (May 2026) legal compliance across the top models remains poor. The highest scoring model (Claude Opus 4.7) only managed a compliance average of 54%, and GPT-5.5 only scored 38%. Other Flagship models (both US and Chinese) trailed far behind at 7-11% compliance.
Similarly, the Future of Life Institute’s recent benchmarking showed a worryingly low legal compliance across the whole frontier model ecosystem. Foundational model providers are prioritising capability scaling over legal guardrails, and passing on compliance to downstream developers via inherited liability.
Frontier Models Legal Compliance Score
3.4 So Who is Legally Liable?
These benchmarks show you cannot trust any raw LLM to stay within legal boundaries out of the box. The AI Act mandates that developers have to build deterministic safety architectures around your models and software. This includes wrapping pipelines in validation middleware, enforcing structured payload disclosures, and maintaining continuous telemetry logging. The ultimate legal responsibility will lie with the team writing the deployment code.
⚠️ What Is Validation Middleware in an MLOps Stack?
Because frontier LLMs are non-deterministic, you cannot rely on system prompts alone to guarantee legal compliance. Validation middleware is a deterministic code layer (built via custom FastAPI/Express hooks or frameworks like Guardrails AI or NeMo Guardrails) that intercepts traffic before and after the LLM call:
Input Interception (Pre-Execution): Filters out prompt injection attacks, blocks PII/GDPR leaks, and enforces hard rate/token limits before reaching the model API.
Output Interception (Post-Execution): Inspects model outputs before they reach the end user. It ensures responses are either compliant or dropped before leaving your server.
But what if you’re building SaaS for your client? You are not the primary target for fines from the EU regulators. However, you still will face immediate exposure, if your (former) client gets penalised, their legal team will be suing you. Enterprise clients will routinely demand broad compliance warranties and full indemnification clauses in their SOWs.
So what should you do?
Don’t sign broad warranties: Don’t guarantee global compliance for an entire system, especially when you only control a part of the tech stack. Expressedly restrict your warranties to your modules.
Never compromise on guardrails: Don’t let clients cut costs by removing safeguards or aspects which make the system non-compliant with EU regulation. Contractual disclaimers won’t work, if the underlying tech stack is non-compliant.
Document the hand-off: Maintain strict-version controlled records of any technical documentation, and codebase. If they modify the code later and break compliance, your documentation is proof that the system was compliant when you shipped it.
Key Roles
The full text outlines numerous secondary supply-chain roles (e.g., Importers, Distributors, Product Manufacturers, Downstream Provider, etc.). However, I would say there are four main personas you need to consider:
Provider: The entity that develops an AI system (or commissions its development) and places it on the market, or puts it into service under its own name or trademark. Essentially, anyone who builds, brands, and sells an AI model, whether they built the code themselves or hired someone else to do it.
Deployer: The person or organization using the AI system in a professional context. These are your enterprise clients and customers. As long as they aren’t using the tool for purely personal, non-professional activities, they inherit strict obligations under the Act, such as ensuring mandatory AI literacy for their staff.
Authorised Representative: The proxy physically located or established within the EU designated by written mandate to act on your behalf. If you are a non-EU provider (like a developer based in Hong Kong) selling your tool into the European market, you legally must appoint someone in the EU to act as your regulatory liaison. They are the first port of call if the EU AI Office has compliance questions.
Affected Persons: The individuals or groups located in the EU who are directly impacted by the AI system’s output. These are your client’s end-users, employees, or job applicants being evaluated by your algorithm. Under Article 86, Affected Persons hold an explicit legal right to a clear and meaningful explanation for decisions made by high-risk AI systems. This means your software cannot be a total black box. Your architecture must be capable of generating clear, human-readable audit logs to explain exactly how the model reached a specific output.
⚠️ Developer vs. Provider
You might think you’re safe as you aren’t a provider, you just built the system, however, remember the Who is Legally Liable section. In commercial contracts, the client is likely to only sign if you either agree to obey the EU AI Act or take on the penalties of the breach.
Scope of the AI Act
5.1 The Algorithmic Line: What’s In Scope vs. What’s Out
So now we know who carries the legal liability, and where jurisdictional areas are, but we’re still left with the questions of what they define AI as, and the types of AI that are covered.
The EU’s Definition of AI
According to Article 3(1), an AI system is
a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments;
Now this is incredibly broad and reads like legalese so let’s break it down into the six key criteria:
Machine-Based System: It runs on hardware and software compute. However, I believe this has been intentionally left broad to accommodate new tech such as quantum computing, or biological/organic computing. In short you’re going to have to work very hard for whatever you are building to not be classed as a machine.
“Varying levels of autonomy”: If your system operates with a degree of independence from human intervention, you could be covered. You cannot escape by simply placing a “human in the loop” who clicks “Approve” at every single step. That system would still be autonomous if it independently calculates or infers its decision.
Adaptiveness after deployment (optional): This applies to continuous-learning models that update their weights, vectors, or parameters based on real-world user interactions.
Explicit and Implicit Objectives: The goal that the system tries to achieve. These could be directly in the code (explicit - e.g., minimising a loss function), or they may be deduced from the systems operational parameters (implicit - e.g. an LLM prompts and emergent reasoning capabilities).
Infers: This is the crucial threshold. The system must perform statistical inference, essentially going beyond raw hardcoded data mapping. To be classed as an AI system it must be beyond a simple series of if/then loops or automation scripts.
Generative Outputs That Influence Environments: The system produces an actionable result, e.g. a prediction, piece of content, a recommendation, or a decision that shapes a physical or virtual environment. Note the term generative here, it is in the classic computer science definition, that is to produce or output data, not in the commercial sense of “Generative AI” (LLMs and image generators). This means a basic random forest model is just as covered as GPT5.6.
There is a carve out in Article 2 for military, defence, applications solely used for R&D, and open-source testing performed prior to commercial market entry. So, if you are building software exclusively for academic research, internal prototyping, or national defense, you fall outside the scope of the Act—until that code is packaged and deployed into a commercial production environment.
The Four Risk Tiers of AI
As you can see unless it is what we would deem as “hard-coded” pretty much anything is in play at this point. However, the EU recognises that there is a difference between a simple linear regression and the latest LLM. As a result they have grouped AI systems into several regulatory hierarchies:
Unacceptable Risk: Systems completely prohibited from entering the EU market under Article 5. Violations risk the maximum penalty tier (up to €35M or 7% of global turnover). See the comprehensive breakdown of banned practices below (e.g., social scoring, workplace emotion detection).
High Risk: Legally permitted, but rigorous architecture audits are required, strict logging, risk mitigation systems, and mandatory conformity assessments (see Articles 6-49). Examples: AI used in job recruitment (CV sorting), educational grading, credit scoring, law enforcement, and critical infrastructure management.
Limited Risk: Systems with lower risk profiles that primarily require strict transparency and disclosures so humans know they are interacting with AI, or seeing AI outputs (see Article 50). Examples: customer service chatbots, basic text-generation LLMs, deepfakes, and AI-generated media (requiring cryptographic watermarking).
Minimal or No Risk: Applications that pose little to no risk to a citizen’s rights or safety. They are entirely unregulated and face zero restrictions under the Act, but there is a voluntary code of conduct (see Article 95). Examples: AI-powered video games, spam filters, predictive inventory software, and standard search optimization algorithms.
Note on Legacy Systems
Pre-existing systems deployed prior to 2nd August 2026, are grandfathered and fully exempt from retroactive penalties. Systems deployed before 2nd August 2027 have a grace period until 31st December 2030 to be compliant (see Article 111). However, pushing a substantial modification voids your protection, and compliance obligations begin immediately.
Banned AI Practices
Even legacy systems that are on the prohibited list in article 5 are outlawed, and will result in the biggest fine available. Here’s the rough breakdown of the unacceptable categories:
Subliminal or Manipulative Techniques: Deploying systems that use deceptive or subconscious techniques that are used to alter human behaviour.
Exploitation of Vulnerabilities: Deploying systems that take advantage of a person’s vulnerability due to age, disability or a specific social or economic situation in order to alter their behaviour.
Social Scoring: Deploying systems that evaluate or classify people or groups based on social behaviour or personal traits that can lead to detrimental or unfavourable treatment.
Predictive Policing: Essentially no Minority Report systems that are based solely on profiling, personality traits, or demographic history rather than verifiable facts.
Untargeted Facial Recognition: Creating or expanding facial recognition databases through the indiscriminate, untargeted scraping of facial images from social media, the internet, or CCTV footage.
Workplace and Educational Biometrics: No AI system can be deployed within workplace or educational environments that can predict the emotional state of people (except medical or safety applications).
Biometric Categorisation on Protected Traits: No deployment of AI systems that use biometric data to deduce an individual's sensitive characteristics such as race, political opinions, religion etc.
“Real-time” Biometric Systems: Live biometric systems are expressly banned for policing/law enforcement in public spaces with narrow exceptions for situations such as human trafficking, immediate terrorist threats, etc.
Non-Consensual Deepfakes: While not in the original AI Act, recent amendments in June 2026 now ban non-consensual deepfakes, particularly “nudification” and AI systems designed to generate child sexual abuse material.
5.2 General-Purpose AI Models
Legal definition of General Purpose AI Models
What if you’re building a foundational model? Where do models such as GPT5.6 or Llama3 sit? They could be used for a variety of purposes. The short answer is they don’t fit, instead the EU has made a distinction between the AI system (the application layer), and a General-Purpose AI Model (the underlying LLM). This is because a single GPAI model could be integrated into a variety of different AI systems, for example a “minimal risk” video game, or a “high risk” CV scanner. But what’s the legal definition of a GPAI model? It seems as if the regulators have LLMs firmly in their sights, GPAI models are…
“trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications”
Notably there is a helpful technical guideline of a GPAI having a training compute greater than 10²³ FLOPs (Floating Point Operations), and it can generate language (whether in the form of text or audio), text-to-image, or text-to-video. However, this is just a guideline the regulators could still choose to classify models as a GPAI model under their discretion.
General Purpose AI Regulations
Due to their broad capability, GPAI models are regulated by a separate framework (Chapter 5, Articles 51-56). These officially came into effect on the 2 August 2025, but active regulatory enforcement and fines take effect on 2 August 2026. The framework splits into two regulatory areas: base regulation of GPAIs and stricter governance for those GPAIs determined as having systemic risk.
I. Base GPAI Models
Under Article 53(1), all GPAI models need to fulfil four core obligations:
Internal Technical Documentation: In-depth technical records need to be supplied upon request to the EU AI Office and any relevant national regulatory office. These records need to detail the training and testing process, dataset composition and evaluation results. More details on the documentation required is in Annex XI, Section 1.
Downstream Integration Package: Provide technical documentation and capability bounds (e.g., system limits, guardrails, and model cards) for downstream developers of AI systems integrating the GPAI model into their applications (see Annex XII). This requirement explicitly respects legal protections for trade secrets and IP rights.
Copyright Compliance: Create a formal policy to comply with EU copyright law, including honouring rights-holder opt-outs to web-scraping (specifically Article 4(3) of the Digital Single Market Directive).
Public Training Summary: Publish a public summary that specifies what data was used for training purposes. This needs to be according to the EU template provided by the AI Office.
II. GPAI Models with Systemic Risk
GPAI models are classed as having systemic risk via two primary mechanisms:
High-Impact Capabilities: According to Article 51, if the model has high impact capabilities determined on the basis of “appropriate tools, methodologies, and benchmarks”.
Compute Ceilings: A commission decision using the guidelines in Annex XIII. This means they can retain flexibility as technology progresses, for example on the 1 August 2025 the EU decided, any GPAI model trained with over 10²⁵ FLOPs will automatically be considered a GPAI model with systemic risk. The European Commission can also update compute thresholds or designate models as containing systemic risk under Annex XIII to ensure regulation keeps pace with hardware and algorithmic efficiency gains.
If you cross these thresholds you likely already have a team of lawyers, and technical safety officers who can guide you through. But to be brief, you need to proactively notify the EU, conduct continuous adversarial testing, track and report serious operational incidents, and implement rigorous cybersecurity defenses (see Article 55).
III. The Open Source/Weight Exemptions
Models released under a free and open-source licence are exempt from providing detailed documentation (points 1 and 2 of the base GPAI requirements), as long as the model is not classed as a GPAI with systemic risk. However they must still adhere to copyright and public training standards (points 3 and 4).
IV. Fine-Tuning and Model Adaptation
This is where the act gets complicated. There are two separate axes to consider:
The Purpose (Application layer): That is, what is the fine-tuned model being used for?
The Compute (GPAI layer): Specifically, how heavily did you modify the weights?
The Purpose Axis
If you fine-tune an open-weight LLM and expose it via an API, or user interface, according to the EU AI Act you have built an AI system. Therefore the AI system regulations apply not the GPAI sections. Here are a few examples:
Fine-tuning for CV screening or HR automation: High-Risk AI System (strict logging, risk management, conformity assessments).
Fine-tuning for a customer service chatbot: Limited Risk (Article 50 transparency & watermarking rules).
Fine-tuning for in-game NPC dialogue or a spam filter: Minimal Risk (zero regulatory obligations).
Fine-tuning to perform emotion recognition on remote workers: Unacceptable Risk (banned under Article 5).
The Compute Axis
The EU AI Office determines whether your fine-tuning efforts turns you into a new "GPAI Model Provider" based on compute thresholds. Specifically the One-Third FLOPs Rule. For fine-tuning, if you consumed under one-third of the original compute power used to train the base model (or under one-third of 10²³ FLOPs if the base compute is unknown) then you are legally safe from being classified as a GPAI model provider and adhering to the model provider obligations.
Therefore the safest route is to stick to parameter efficient fine-tuning (PEFT) such as LoRA or QLoRA., and if you’re feeling adventurous switch to ternary models as you can make greater use of your FLOPs. This is unless by your fine-tuning you alter the model into having systemic risk, pre-existing systemic risk is covered by the initial provider.
Are Legacy Builds Exempted from the AI Act?
So what about existing AI systems? Do you suddenly need to make sure every single build in the past is now compliant? Article 111 carves out some key exemptions, but if you substantially modified your system (according to Article 3(23) and Article 25) then your exemptions no longer apply. The easiest way to view this is to look at these separate breakdowns for AI systems and GPAI models.
Enforcement Timeline
Here are the key statutory enforcement milestones and the EU AI Act compliance timelines:
Conclusion: Compliance as a Shibboleth
It has often been said that the EU leads the world in… regulation (officially known as the Brussels Effect) and it has had a negative impact on many start-ups and SMEs. Yet most of us agree that there should be some sort of regulation of AI. For example, banning Child Sexual Abuse Material (CSAM), non-consensual “nudification”, or predatory social scoring aren’t radical ideas; they are fundamental guidelines for human safety. And whether we determine the AI Act as an egregious EU overreach or a necessary shield to safeguard users from corporate exploitation, the easiest/safest thing to do is comply and not lose access to one of the largest markets available.
Furthermore, we’ve seen hiding behind “not for EU-use” clauses, and geo-blocking is not a reliable means of protection, it is naive ignorance. EU regulators don’t care where servers lie, and enterprise legal teams will gladly pass multi-million Euro liabilities straight down the contract chain. Only rigorous stress-tested architecture and disciplined engineering hygiene can protect your business.
By getting ahead of the curve here, you aren’t just pleasing EU auditors, you are setting up long-term stability for your tech stack on two fronts:
Global Regulatory Similarity is Inevitable: Just as GDPR caused jurisdictions worldwide to rewrite their privacy laws, the AI Act will establish the baseline for model governance. Even markets favouring lighter regulation (e.g. Singapore, Japan, and the UK) are asking for the same things: AI transparency, auditability and risk mitigation (just in different legal language). By following the EU framework you’re likely to be ~75-80% compliant with most markets out of the box.
Compliance Mandates can be seen as Good Engineering Practices in Disguise: If we strip away all the legal framework, most of what the EU asks for is continuous monitoring, structured validation, data auditing, clear model cards, and human-in-the-loop oversight. These are essentially standard MLOps best practices. Not having these practices will not only result in regulatory penalties, but also a loss in business performance.
In the end, I’d recommend treating compliance as a shibboleth used to distinguish good engineering from a hacky vibe-coded prototype.