What is the EU AI Act?
AI regulation: concepts, institutions and standards
The EU AI Act is the European Union's law for artificial intelligence, and the first comprehensive law of its kind anywhere. It does not treat all AI the same way. A small set of uses are banned outright, a defined group of higher-stakes uses such as some recruitment, credit and insurance tools carry strict duties, and certain chatbots and synthetic media must simply be transparent about what they are. Its reach extends beyond Europe: an organisation in London, New York or Singapore can fall within it if it places AI on the EU market, serves users in the EU, or produces AI output that is used there. That is why it has become a reference point for AI regulation worldwide, whatever a business's home country.
What this means
At its heart the EU AI Act is a market law for AI. It is designed to let AI be used across the European single market while applying more control where the stakes for people, safety and rights are higher. The principle is straightforward: regulate in proportion to risk rather than treat every AI tool as equally dangerous.
This matters because "AI" is too broad a word to govern with a single rule. A spell checker, an image generator, a fraud model, a hiring screener and an AI component inside a medical device are not the same thing and do not deserve the same scrutiny. So the Act works in layers. A few uses are not permitted at all. Some are permitted only with substantial controls. Some are permitted as long as people are told what is happening. The large majority of everyday, low-stakes uses carry little beyond existing law and sensible governance.
The Act applies to what it calls an AI system: software that operates with some autonomy and infers from its inputs how to generate outputs such as predictions, content, recommendations or decisions that influence the world around it. In plainer terms, if a piece of software is making inferences and producing results that shape what happens next, it may well be in scope. Working out whether a given product counts as an AI system, and which risk category it falls into, is one of the first practical questions any organisation faces.
The Act also treats general-purpose AI models, the broad models that can perform many different tasks and be built into countless downstream products, as a category of their own. The reason is practical. The company that builds a large model and the company that wraps it into a customer-facing product are usually not the same, so the Act places duties along the chain: the model provider documents what the model is and can do, and the business building on top of it has enough information to meet its own obligations.
For most organisations, the useful way to hold all this is not as a wall of legal categories but as a sequence of questions. What AI are we using or building? Where is it used, and by whom? How much does it matter when it goes wrong? The answers place a business somewhere on the Act's spectrum, and for a great many uses that place is comfortably toward the lighter end.
Why it matters
The Act matters because it does not stop at Europe's borders. It applies to organisations that place AI on the EU market, to those that use AI within the EU, and to those outside the EU whose AI output is used there. It reaches providers, the businesses that build and supply AI, and deployers, the businesses that put it to use, along with importers, distributors and others in the chain. Where a company is incorporated is not the deciding factor; what matters is where the system is placed, where it is used, and where its results land.
This is easiest to see in ordinary commercial life. A software firm selling an AI tool to customers in Germany or France is placing that system on the EU market. A services business using AI to screen applicants for a client in the EU is producing output used there. A retailer running an AI support tool for European customers is creating EU touchpoints. A lender assessing applicants in Spain or the Netherlands is within reach regardless of where its head office sits. The same logic catches organisations on every continent, which is part of why the Act has shaped how AI regulation is being discussed far beyond Europe.
For most organisations the early duties are lighter than the headlines imply, and the right response is not alarm. Many will find that little of what they do falls into the higher-risk categories, and that their immediate obligations centre on understanding their own AI use, being transparent where required, and keeping an eye on the timetable. Businesses working in areas the Act treats as higher-stakes, such as recruitment, credit, insurance pricing or public services, need a more precise plan. In all cases, the work is easier when it is done early, before a contract, a product launch or a procurement questionnaire turns a distant regulation into an immediate one.
There is a wider point as well. Most countries do not yet have a single comprehensive AI law, and many organisations are navigating a patchwork of data protection rules, sector regulation and the EU AI Act at once. A business with European exposure may effectively live under more than one regime simultaneously. The measured response is not to assume distance grants exemption, but to be able to state clearly where your systems operate, who they affect, and whether any of the Act's hooks apply. That clarity is worth having for its own sake, whatever the regulatory weather.
How it works
The Act is built around roles, and getting the role right is the start of everything else. A provider is the 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 trade mark. A deployer is the organisation using the system under its own authority in the course of work. The Act also defines importers, distributors, authorised representatives and product manufacturers. The distinction matters more than it first appears, because a business that considers itself a simple user can become a provider in law if it brands a system as its own, modifies it substantially, or changes what it is for.
A small number of uses are banned outright. These prohibited practices include AI that manipulates or deceives in ways that materially distort behaviour and cause significant harm, AI that exploits vulnerabilities tied to age, disability or economic situation, social scoring that leads to unjustified detrimental treatment, certain predictive policing based solely on profiling, untargeted scraping of facial images to build recognition databases, emotion recognition in workplaces and schools outside medical or safety reasons, biometric categorisation that infers sensitive traits such as race or political opinion, and most real-time remote biometric identification in public spaces by law enforcement. The agreed amendments add a further prohibition covering AI that generates non-consensual intimate imagery or child sexual abuse material, with a safe harbour for systems that have effective preventive safeguards. For these categories the response is not a policy document but a decision not to do it. Most ordinary organisations will not approach the law-enforcement biometric lines, but workplace emotion recognition and manipulative consumer techniques are closer to everyday practice than leaders sometimes assume.
The larger operational category is high-risk AI, and there are two routes into it. The first covers AI that is a safety component of, or itself is, a regulated product already subject to third-party assessment under existing EU product law: some machinery, medical devices, toys, lifts, vehicles and similar. The second covers AI used in the sensitive contexts listed in Annex III: biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration and border control, and the administration of justice and democratic processes.
Annex III is where many service businesses will recognise themselves. In employment it names AI used to recruit or select people, to filter applications and evaluate candidates, and to make or support decisions about terms, promotion, task allocation or termination. In essential private services it names AI used to assess creditworthiness or set a credit score, other than for fraud detection, and AI used for risk assessment and pricing in life and health insurance. For an organisation with EU-facing hiring, lending or insurance activity, these are not edge cases; they are written into the statute.
Not everything that touches a sensitive sector is automatically high-risk. The Act carves out systems that do not pose a significant risk of harm and do not materially influence a decision, for example where the AI performs a narrow procedural task, improves the result of work a person has already done, detects patterns without replacing human judgement, or handles only a preparatory step. There is a firm limit, though: a system that profiles individuals is always treated as high-risk. Because the boundary is genuinely fine in places, borderline cases deserve a written rationale rather than a confident guess, and further classification guidance has been the subject of consultation.
For providers of high-risk systems the duties are substantial and run across the whole life of the product. Before a high-risk system goes onto the EU market, the provider must meet the Act's mandatory requirements and complete a conformity assessment. Those requirements span risk management, data quality and governance, documentation and traceability, transparency, human oversight, accuracy, cybersecurity and robustness, supported by a quality management system, retained logs, an EU declaration of conformity, and ongoing responsibility for the system in use. This is a design, documentation and testing regime, not a single page of policy.
Human oversight is the requirement most often misread. The Act asks that high-risk systems be built so that real people can oversee them effectively in use, and that the people assigned have the competence, training and authority to act. It is not satisfied by a vague claim that someone is in the loop, or by the theoretical ability to override a decision after the fact. The practical test is whether the organisation has genuinely equipped a person to understand the tool, watch it, interpret it correctly, and step in when it matters.
Buying a system rather than building it does not remove obligations. Deployers of high-risk systems must use them in line with the instructions, assign capable human oversight, ensure that any input data they control is relevant and representative, monitor operation, report serious incidents and risks to providers and authorities, and keep logs under their control, generally for at least six months. Where a high-risk system is used in the workplace, employers must inform worker representatives and affected staff before it goes live, and where an Annex III system makes or supports decisions about individuals, those individuals must be told they are subject to it. Procurement, in other words, is not a substitute for governance.
In some cases deployers must go further and complete a fundamental rights impact assessment before first use. This applies to public bodies, private providers of public services, and deployers of the high-risk systems used for creditworthiness assessment and for life and health insurance pricing. The assessment sets out how and how often the system will be used, who may be affected, the likely risks, the oversight in place, and what will happen if those risks materialise. Where personal data is involved, a data protection impact assessment will usually sit alongside it, which is one reason the Act is connected to data protection law without being the same thing.
The Act also gives individuals a right to an explanation. Where a decision with legal or similarly significant effects is taken about a person on the basis of a high-risk system's output, that person can ask for a clear and meaningful explanation of the system's role in the decision and the main factors involved. For any organisation making consequential EU-facing decisions with AI, that has practical implications for how decisions are recorded and how processes are designed.
A lighter category, often called limited risk, is mostly about transparency. People interacting directly with an AI system should be told they are dealing with AI unless it is obvious. Synthetic audio, image, video or text should be marked, where feasible, as artificially generated. Emotion-recognition and biometric-categorisation systems require notice to the people exposed to them, deepfakes must be disclosed, and AI-generated text published to inform the public on matters of public interest must be flagged, subject to exceptions. In most ordinary cases this asks for clear notices and honest disclosure rather than a full compliance apparatus.
The majority of AI uses fall into a minimal-risk space that the Act largely leaves to existing law. That should not be read as nothing to do. A general obligation on AI literacy applies to providers and deployers across the board, and other law, including data protection, consumer, employment, equality and sector rules, continues to apply. Minimal risk means the Act is not building a bespoke regime for that tool, not that governance disappears.
AI literacy is easy to overlook and worth singling out. Providers and deployers must take reasonable measures to ensure the people using AI on their behalf have a sufficient understanding of it: what AI is, what the organisation uses, what opportunities and risks it creates, and what role the organisation plays. Telling staff to read the manual is rarely enough, particularly for higher-risk systems. This obligation is among the earliest to apply, which makes literacy a present concern rather than a future one for any organisation in scope.
General-purpose AI models sit in their own part of the Act. Providers of these models must keep technical documentation current, give downstream builders enough information to understand the model's capabilities and limits and meet their own duties, maintain a policy for complying with copyright law, and publish a summary of the training data along an official template. A business that consumes frontier-model APIs or embeds a broad model in its own product depends on this information flowing down the chain, even if it is not the model provider itself. The most capable models, those judged to carry systemic risk, face additional duties around evaluation, adversarial testing, risk mitigation, incident reporting and cybersecurity. That layer is aimed more at the model builders than at an organisation using an off-the-shelf assistant, but it still matters commercially, because downstream businesses rely on those providers for documentation and contractual assurance.
Open-source deserves a note of caution, because it is often misread as a blanket exemption. Some free and open-source releases are excluded, but not where the system is high-risk or falls under the prohibited or transparency rules, and some documentation reliefs for open models fall away where a model carries systemic risk. Open-source changes the analysis; it does not end it. The same questions still apply: what does the system do, what role do you play, and who in the EU is affected.
A value-chain rule catches businesses by surprise more than almost any other part of the Act. A distributor, importer, deployer or other party can itself become the provider of a high-risk system if it puts its own name or mark on the system, makes a substantial modification, or changes the purpose of a previously non-high-risk system so that it becomes high-risk. Deep customisation, white-labelling or repurposing can move an organisation from the lighter user position into the heavier provider one. For any business wrapping a third-party model into its own branded EU-facing offer, this is among the most commercially important lines in the Act.
Enforcement is shared. A European AI Office within the Commission oversees implementation and supervises the most powerful general-purpose models, while national market surveillance authorities supervise and enforce the rules for AI systems, including the prohibitions and the high-risk regime. Member States designate the authorities that oversee the bodies handling certain pre-market conformity work, and advisory and scientific structures help steer the system. In practice an organisation should expect supervision at the EU level for the largest models and interaction with national authorities for most system-level obligations.
The penalties are significant and worth reading precisely. Breaching the prohibited practices can attract fines up to EUR 35 million or 7 per cent of total worldwide annual turnover, whichever is higher. A broad set of other obligations, including provider and deployer duties and the transparency rules, can reach up to EUR 15 million or 3 per cent. Supplying incorrect, incomplete or misleading information to authorities can reach up to EUR 7.5 million or 1 per cent. For smaller firms and start-ups the fine is capped at the lower of the fixed amount or the percentage rather than the higher. Providers of general-purpose AI models face a separate route to fines of up to EUR 15 million or 3 per cent of worldwide turnover.
The timetable needs care, because it is both phased and recently revised. The Regulation entered into force in 2024. The earliest obligations, on AI literacy and the prohibited practices, applied from February 2025. Obligations for general-purpose AI models, governance and penalties followed in August 2025. A political agreement reached in early May 2026, part of a wider simplification package known as the Digital Omnibus, then moved several of the later dates. The high-risk obligations for the Annex III use-based categories, such as employment, credit, biometrics and critical infrastructure, are now set to apply from 2 December 2027 rather than August 2026. The high-risk obligations for AI embedded in regulated products, such as medical devices and machinery, move to 2 August 2028. The transparency obligations for synthetic and AI-generated content are due from 2 December 2026, after the grace period was shortened. National regulatory sandboxes move to August 2027.
Three cautions follow from that. First, as of mid-2026 this agreement is provisional and takes legal effect only on formal adoption and publication. Until then, the original date of 2 August 2026 for the use-based high-risk obligations technically still governs, which is why the institutions have said they intend to complete adoption before that date. Treat the revised dates as the operative planning baseline, but understand that the old date remains the legal position until the amendment is published. Second, the revised dates are an outer limit rather than a fixed floor: the agreement lets the authorities bring obligations forward, to roughly six months after the necessary standards and guidance are confirmed in place, so 2 December 2027 is the latest the Annex III duties would begin, not a guarantee of that exact day. Third, the sensible posture is neither "nothing applies until 2027" nor "all high-risk rules start in August 2026", because neither is accurate. Parts of the Act are already in force, others are imminent, and the high-risk timetable has been extended to give standards and guidance time to mature. A precise, dated understanding is worth more here than a single remembered deadline.
Examples
A recruitment example makes the Act concrete. A company using a third-party AI hiring platform to rank applicants, including candidates applying from Ireland and Germany, is operating in the employment category that Annex III treats as high-risk. The platform vendor is usually the provider; the hiring company is usually the deployer. Buying the tool does not close the matter. The employer still has to think about following the instructions for use, assigning real human oversight, the quality of any input data it controls, telling affected candidates, and keeping records.
Change the facts a little and the role can change. If that same company does not simply use the platform but customises it heavily, adds its own scoring logic, brands it as its own, or turns a general tool into a recruitment decision engine, it can be pulled into provider status. That is a heavier position, carrying quality-management, documentation and conformity duties across the system's life. It is why "we only use a vendor tool" is worth testing against what the business is actually doing, because white-labelling and deep modification change the legal role.
An ordinary customer-service chatbot sits in a lighter place. A retailer running a chatbot on its French and Dutch sites mainly needs to make sure people are told they are dealing with AI where that is not already obvious, and to mark synthetic content where that applies. Routine customer support is not an Annex III high-risk use, so the starting point is transparency rather than a full compliance programme. That keeps the response proportionate: identify the interaction, add clear notices, and check the bot has not quietly drifted into consequential decisions.
It does not stay trivial if it changes job. If the same chatbot begins making decisions that matter, refusing service, prioritising complaints, or routing vulnerable customers without meaningful review, other law and internal governance come into play and a fresh risk analysis is sensible. The first step is rarely a high-risk compliance regime; it is noticing when a tool has been pushed into a role it was not designed for.
A lender or insurer dealing with EU individuals is in clearer high-risk territory. A fintech scoring the creditworthiness of personal applicants in Spain, or an insurer pricing life or health cover for people in the EU, is operating in use cases Annex III names directly. Deployers of these specific systems also have to complete a fundamental rights impact assessment before first use and, in many cases, a data protection impact assessment alongside it. Here "we are just using a tool" plainly is not enough, because the business process itself is regulated by virtue of what the system does to people.
General-purpose AI inside a software product shows the value chain at work. A company building an EU-facing contract-review product on top of a broad model relies on the upstream model provider to carry the model-level duties and to pass down enough information about capabilities and limits for the downstream business to meet its own obligations. If the product is then sold into a high-risk use such as employment or credit, the downstream layer matters far more, and if the company materially changes the system's purpose or rebrands a high-risk system as its own, it can step into provider duties.
The quietest example is everyday internal use. Staff using a general AI assistant to draft copy, summarise documents or translate text for EU-facing work are unlikely to be in a high-risk scenario, but they are firmly in a governance one. The proportionate response is staff guidance, basic AI literacy, sensible controls on confidential data, and a clear record of which tools are in use, rather than pretending these tools sit outside the business.
Common misunderstandings
The first misreading is that the Act, being EU law, does not affect organisations elsewhere. It reaches providers placing systems or general-purpose models on the EU market wherever they are established, and providers and deployers outside the EU whose AI output is used within it. The real question is not whether a business has a European office but whether it has European market or output exposure.
The second is that the Act bans AI. It does not. It prohibits a defined list of practices and places stronger duties on a limited set of high-risk uses, while most systems continue under existing law without new AI Act obligations beyond the general ones. That is why a sensible programme begins with classification rather than alarm: a chatbot, a summariser, a forecasting tool and a hiring engine do not belong in the same legal bucket.
The third is that this is data protection law under another name. It is not. Data protection law governs how personal data is processed, with its own principles and individual rights. The Act asks different, sometimes overlapping, questions about classification, prohibited practices, conformity, human oversight, transparency and market governance. Many systems will have to satisfy both, and meeting one does not automatically mean meeting the other.
The fourth is that small organisations are out of scope. Size affects proportionality and some penalty mechanics, and there is relief in the form of lighter documentation and the lower fine cap for smaller firms, but it is not a blanket exemption. A small recruitment business using AI for EU candidates can still be the deployer of a high-risk system, and a small software supplier can still place a system on the EU market. Size can soften the burden; it does not remove the need to classify and govern.
The fifth is that using AI tools rather than building them puts all the responsibility on the vendor. The Act regulates both providers and deployers. Deployers of high-risk systems have duties around correct use, human oversight, monitoring, logs, and in some cases informing people and completing impact assessments. Buying a tool still requires understanding what it is and what its use triggers.
The sixth is that open-source means exempt. Sometimes, partly, but far from always. The exclusions fall away where a system is high-risk or caught by the prohibited or transparency rules, and some reliefs for open models do not apply where a model carries systemic risk. Open-source reshapes the analysis without ending it; the same questions about purpose, role and EU exposure still apply.
Risks and boundaries
It is worth being clear about what the Act does not do. It does not require approval for every AI use. It does not replace sector law, data protection law or employment law. It does not stop organisations using mainstream low-stakes AI. And it does not offer a single one-word answer for every borderline case, because the position depends on role, purpose, degree of modification, who is affected, and where the system or its output is used. It reads as both a legal framework and a classification exercise.
This article is not legal advice. It is a decision-support explainer for senior non-specialists, drawn from the Act itself, official European Commission materials, national regulatory guidance and reputable legal analysis. It can help frame the right questions, but it cannot settle every edge case. An organisation near a classification boundary, launching an EU-facing AI product, or using AI in recruitment, credit, insurance pricing, workplace monitoring, biometrics or anything law-enforcement adjacent should take specialist advice, particularly where a contractual, white-label or modification step might shift it from deployer into provider.
There is genuine risk in both directions. Under-compliance means assuming the law is irrelevant because of where the business sits, buying a tool without understanding role or use case, or failing to record why a system is or is not high-risk. Over-compliance means treating every AI feature as a regulated decision engine and freezing useful activity without legal need. The answer is disciplined classification rather than fear, which is also why continuing guidance and consultation on the finer boundaries is worth following.
A final boundary is time. The dates are phased and, following the May 2026 agreement, partly in motion. Some parts already apply, some are imminent, and several high-risk dates have been pushed back but are not yet finally adopted. Any board-level or customer-facing statement on timing should be dated and precise. A line such as "as of today, we treat the published Regulation as the baseline and are tracking the pending amendments" is far safer than presenting the timetable as either frozen or fully settled.
What to do next
Start with an inventory, not with legal theory. List the AI systems and broad models the organisation uses, buys, embeds, customises or offers, including workplace tools, customer-facing tools, supplier tooling, and any unofficial AI that has crept into operations. Without that picture, every later step is guesswork.
Then check EU exposure system by system. Are we placing this on the EU market? Are EU staff, customers, candidates, borrowers, policyholders or other people using it or affected by it? Is its output used in the EU? Is an EU partner integrating it into European use? Record the conclusion for each system, including where the position rests on the absence of any EU use.
Next, decide the legal role for each system in scope. Provider, deployer, importer, distributor, product manufacturer, or a combination. If the business brands a system as its own, modifies it substantially or changes its purpose, check whether it is drifting into provider status. The role determines which duties sit with you and which sit elsewhere in the chain.
Then classify by risk. Separate prohibited practices, high-risk systems, transparency-only systems, general-purpose model issues, and everything else. For high-risk, look first at the Annex III categories and any regulated-product context. For transparency, look at chatbots, biometric categorisation, emotion recognition, deepfakes and public-interest synthetic text. Where a classification is arguable, write down the reasoning and flag it for legal review rather than waving it through.
Do not wait for the later dates to handle AI literacy and baseline governance, because the literacy obligation already applies. Build role-based staff guidance rather than generic slides, tailored to the person's role, the system's risk and the people affected. For higher-risk uses, that guidance should cover how the system works in practice, what oversight means in your process, what signs of error to watch for, and when escalation is required. Keep a record of the training and guidance provided.
If you are deploying a likely high-risk system, prepare the operational controls now: identify the people who will oversee it, check the input data you control, set incident and suspension procedures, plan log retention, and prepare notices to workers, candidates or customers where relevant. Where the use involves creditworthiness, life or health insurance pricing, or public services, plan the fundamental rights impact assessment early, and coordinate it with any data protection impact assessment.
If you have EU-facing chatbot, synthetic-content or generative use, plan for the transparency duties rather than leaving them late. The direction is already clear: people should know when they are dealing with AI, deepfakes should be disclosed, and certain synthetic content carries marking or disclosure duties. This work is usually lighter than high-risk compliance, but it still needs an owner, some design decisions and customer-facing wording.
Tighten procurement and contracts. Ask suppliers for their classification position, the intended purpose, instructions for use, evidence of documentation, incident channels and, for general-purpose models, the information that lets you understand capabilities and limits. Where you embed third-party models, make the contract say who provides what information, who handles serious incidents, and what happens if your changes alter the classification.
Keep a dated watchlist rather than a single deadline in your head. As of mid-2026, the prohibited practices and AI literacy obligations are already in force, the general-purpose model and governance rules are in force, the transparency duties are approaching, and the high-risk dates have been provisionally extended pending formal adoption. Assign one owner, usually in legal, risk or operations, to maintain a dated note of what is in force, what is proposed, and what assumptions the business is working from.
If the conclusion is that current AI use is domestic with no EU touchpoint, do not simply file it away for good. Write down why the Act is not currently engaged and set a trigger for review. A new EU customer, a new hiring campaign in Ireland or France, a new reseller arrangement, or a new AI-enabled product can change the position quickly. For many organisations, that light, documented review is the most proportionate next step.
FAQs
Does the EU AI Act apply to companies outside the EU?
It can. The hooks are not where a company is registered but whether it places AI systems or general-purpose models on the EU market, whether the system's output is used in the EU, and whether EU users or affected people are involved. A business with no EU touchpoint may sit outside the Act directly, but many organisations with EU customers, candidates, borrowers, staff or EU-facing products will not.
When does the EU AI Act take effect?
In phases. It entered into force in 2024, with the prohibited practices and AI literacy applying from February 2025, and the general-purpose model and governance rules from August 2025. A political agreement in early May 2026 then moved several later dates: the main high-risk obligations for use-based categories to 2 December 2027, high-risk obligations for AI in regulated products to 2 August 2028, and the transparency obligations for synthetic content to 2 December 2026. As of mid-2026 those revised dates are agreed but take effect only on formal adoption and publication, so until then the original 2 August 2026 date technically still stands, and the revised dates are an outer limit that could be brought forward once standards are ready. It is worth tracking final publication rather than relying on a single figure.
What are the penalties?
Breaching the prohibited practices can attract fines up to EUR 35 million or 7 per cent of worldwide annual turnover, whichever is higher. A broad set of other obligations, including deployer duties and the transparency rules, can reach up to EUR 15 million or 3 per cent. Supplying incorrect or misleading information to authorities can reach up to EUR 7.5 million or 1 per cent. Smaller firms and start-ups are capped at the lower of the amount or percentage. Providers of general-purpose models face a separate route to fines of up to EUR 15 million or 3 per cent.
What is a high-risk AI system?
Broadly, either an AI system that forms part of a regulated product subject to third-party assessment, or one used in a sensitive context listed in the Act, such as biometrics, critical infrastructure, education, employment, creditworthiness, life and health insurance pricing, law enforcement, migration or justice. Not every system in a sensitive sector is automatically high-risk, because there are carve-outs for narrow or non-influential uses, but many consequential decision-support systems clearly are.
How does the AI Act relate to data protection law?
They are related but distinct, and often overlap where personal data is involved. Data protection law governs how personal data is processed, including lawfulness, fairness, transparency, security, minimisation and individual rights. The AI Act governs AI-specific matters such as classification, prohibited practices, human oversight, conformity and transparency. A business may need to satisfy both rather than choose between them.
What is a general-purpose AI model under the Act?
A model with significant generality that can perform a wide range of distinct tasks and be built into many downstream systems. The Act regulates providers of these models separately, requiring documentation, information for downstream builders, a copyright policy and a training-data summary, with extra duties for models that carry systemic risk. For most businesses the practical question is whether they are simply using a model inside a tool, or building and placing a downstream AI system on the EU market.
Do we need to do anything if we only use AI tools rather than build them?
Often yes. If the Act reaches the organisation, it may still be a deployer even without having built the system, and deployers of high-risk systems carry their own duties. The AI literacy obligation also applies broadly to providers and deployers, including for ordinary workplace use of general assistants. Using rather than building reduces some duties; it is not a full exemption.
Do we need an EU representative?
Possibly, though not every organisation will. The Act provides for authorised representatives of providers not established in the EU, and whether one is needed depends on the role and how systems or models are placed on the EU market. A provider of an in-scope system or model without an EU establishment should check this point early, with counsel and in its contracts, rather than after launch.
Sources
Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Official Journal of the European Union via EUR-Lex). Primary source for scope, definitions, prohibited practices, high-risk classification, Annex III use cases, transparency duties, general-purpose model obligations, value-chain provider rules, deployer duties, fundamental rights impact assessments, right to explanation, penalties and original application dates.
AI Act, regulatory framework for AI (European Commission). Commission overview of the risk-based framework, governance structure, mandatory requirements for high-risk systems, and the implementation timeline including the 2026 simplification position.
Navigating the AI Act, questions and answers (European Commission). Plain-language confirmation that most AI systems are minimal risk, deployer responsibilities, AI literacy expectations, and the general-purpose and systemic-risk model summaries.
AI Act, Shaping Europe's digital future (European Commission, AI Act page). Primary confirmation of the revised high-risk application dates: 2 December 2027 for use-based high-risk areas (biometrics, critical infrastructure, education, employment, migration, asylum, border control) and 2 August 2028 for AI integrated into regulated products.