An AI feature can enter your business through almost any tool: a customer-support chatbot, a recruitment platform, a writing assistant, or software that helps assess applications. You don't have to develop a model yourself to have responsibilities under the EU AI Act.
The difficult part is working out which responsibilities apply. Buying an AI subscription, building a branded chatbot, and using AI to rank job applicants are different activities, even if all three involve the same underlying model.
This guide explains what the EU AI Act covers, how its risk categories work, the difference between providers and deployers, and the steps a business can take to assess its use of AI. It also separates requirements already in force from those with later deadlines.
What the EU AI Act is
The AI Act is Regulation (EU) 2024/1689, the first broad legal framework for artificial intelligence adopted by a major jurisdiction. It entered into force on 1 August 2024, and because it's a regulation rather than a directive, it applies directly in every member state without national transposition.
Its core idea is a risk-based structure. Rather than regulating "AI" as one category, it sorts uses into tiers and scales the obligations to match. A spam filter and a system that screens job applicants are both AI, but they don't carry the same potential for harm, so the Act doesn't treat them the same way.
Like GDPR, it reaches beyond EU borders. A provider outside the EU that places an AI system on the EU market, or whose system's output is used in the EU, is in scope. For a business operating in the EU, the practical starting point is the activity: what system is being used, for what purpose, and in which role?
Understanding the risk categories
The familiar four-category explanation is a useful overview, but the Act's duties depend on specific provisions. Transparency rules and general-purpose model rules can overlap with other categories.
Prohibited practices are uses the Act bans outright: certain forms of social scoring by public or private actors, manipulative techniques that exploit vulnerabilities, untargeted scraping of facial images to build recognition databases, emotion recognition in workplaces and schools (with narrow exceptions), and certain uses of real-time remote biometric identification. These bans have applied since 2 February 2025.
High-risk systems are the heavily regulated middle. These are AI systems used in areas listed in the Act's annexes, such as employment and worker management, access to education, creditworthiness assessment, essential public services, law enforcement, migration, and critical infrastructure, plus AI used as a safety component in already-regulated products. High-risk providers face requirements around risk management, data governance, technical documentation, logging, human oversight, and accuracy.
Some systems carry specific transparency duties. These include systems that interact directly with people and certain uses of generated or manipulated content. A chatbot used for ordinary customer support raises different questions from a system that makes decisions about access to employment or credit.
Lower-risk uses can include ordinary drafting, summarization, and productivity features, depending on their purpose and context. They don't automatically face the high-risk conformity regime. That doesn't remove applicable literacy, transparency, privacy, consumer-protection, or sector-specific duties.
Key dates on the timeline
The timetable has changed since the original Act. Prohibited practices and AI literacy duties first applied on 2 February 2025, and general-purpose AI model obligations began applying on 2 August 2025, subject to transitional rules for existing models.
As of October 2026, the Commission's implementation timeline reflects the AI Omnibus that entered into force on 27 July 2026. Article 50 transparency rules applied from 2 August 2026. The main high-risk requirements now apply from 2 December 2027 for Annex III systems and 2 August 2028 for AI embedded in regulated products. Existing systems can have additional transitional provisions; check the category that actually applies to yours.
The role question: Provider, deployer, or both
Your role determines which obligations apply. A business can be a provider, a deployer, or both.
A provider develops an AI system or model, or has one developed, and places it on the market or puts it into service under its own name. A deployer uses an AI system under its own authority in a professional context. Purely personal, non-professional use falls outside the deployer definition. Using the same tool for work needs a separate assessment.
Using a vendor's AI-enabled recruitment service or support tool in your business can make you a deployer. Building a system and putting it into service under your own name can make you a provider, including for internal use. The developer of an underlying general-purpose model can be a different provider from the company offering the finished application.
Your role can change if you rebrand a system, substantially modify it, or change its intended purpose. Don't assume the software supplier handles every obligation on your behalf. Record which organization supplies the model, which supplies the system, and who determines how it is used. Importers and distributors can also have responsibilities when bringing systems to market.
What this means for everyday business uses
Start with AI literacy. Article 4 as amended in July 2026 requires providers and deployers to support the development of staff AI literacy in context. It expressly does not require guaranteeing a specific level for each individual. Suitable training and guidance remain useful, but there is no general mandatory certificate.
Next comes transparency, if your system faces people. Under Article 50, providers of systems intended to interact directly with people must design them to inform users they are interacting with AI, unless that is obvious in context. This is a provider design duty, rather than a blanket duty on every deployer. Deployers who generate or manipulate image, audio, or video content constituting a deepfake have to disclose it. AI-generated text published to inform the public on matters of public interest also needs disclosure, unless it has gone through human review and someone holds editorial responsibility.
For an ordinary internal drafting or summarization tool, begin with staff guidance, privacy, and a clear understanding of what people may rely on it for. A customer-facing chatbot also needs the applicable user-facing transparency measures. These examples don't automatically require a high-risk conformity assessment, but their intended purpose still matters.
For example, summarizing a job description is different from ranking candidates. An employee using a writing assistant to improve a sentence is different from an employer using AI to assess that employee's performance. Assess the actual workflow rather than classifying the software solely by its product name.
The picture changes if the system qualifies as high-risk. Hiring, credit assessment, and access to certain essential services can fall within Annex III, subject to the Act's classification rules and exceptions. Prepare for the applicable high-risk deadline: obligations can include oversight, monitoring, logs, notices, and, for specified deployers, a fundamental rights impact assessment. Other existing laws already govern many of these decisions.
What about open-source models?
The Act includes a partial exemption for AI released under free and open-source licenses, and it's often misread as a blanket carve-out. It isn't.
There are separate provisions for open-source AI systems and general-purpose models. Qualifying open-source GPAI model providers are relieved of some Article 53 documentation duties, while copyright-policy and training-summary duties remain. Merely making weights downloadable doesn't establish that a model qualifies. It doesn't apply to general-purpose models designated as posing systemic risk, it doesn't apply to prohibited practices, and it doesn't exempt high-risk systems or Article 50 transparency obligations.
For a business adopting an AI tool, licensing is only one part of the assessment. Your responsibilities depend on your role and the system's purpose. An open-weight model used to rank job applicants can still fall within the high-risk regime; downloading it freely doesn't create an exemption for that use.
How the AI Act fits with GDPR and other rules
The AI Act doesn't replace GDPR. If an AI workflow processes personal data in prompts, documents, outputs, or logs, you still need to assess the lawful basis, transparency, retention, security, and people's rights.
That applies whether you use a subscription tool, embed a third-party API, or operate the system yourself. Review the supplier's role, the contract, and whether a data processing agreement is needed. Check where data goes, who can access it, and what happens to it after the task is complete.
An AI vendor's compliance documentation can help, but it doesn't determine whether your own use is lawful. A tool suitable for drafting public marketing copy may need a very different assessment before it processes personnel files or customer health information.
Employment law, consumer protection, copyright, and sector-specific rules can also apply. Being outside the AI Act's high-risk category doesn't mean a business can ignore those obligations.
How to assess AI use in your business
Start with an inventory of the AI systems your business uses or supplies. Include built-in features in purchased software, employee subscriptions, customer-facing tools, and systems developed in-house. Record what each one does, who uses it, and whether it processes personal data or affects decisions about people. Many teams find AI features they forgot about, such as a plugin in a helpdesk tool or an auto-tagging feature in a document system.
Then assess each use case against the prohibited practices and high-risk provisions. If it doesn't fall within them, check the transparency and literacy rules that may still apply. Keep the reasoning tied to the intended purpose, and revisit it when that purpose changes.
Confirm your role next. Are you deploying a supplier's system, putting your own system into service, or selling a system under your name? Internal use alone doesn't settle that question. Record the answer, the supplier relationships, and who is responsible for each relevant requirement.
Put appropriate staff guidance and transparency measures in place. Decide what employees can enter into AI tools, when outputs need review, how users will be informed where required, and who handles errors or complaints. Keep a record of the training, review procedures, and notices you put in place.
Finally, map the applicable dates and assign an owner. A business using an ordinary chatbot needs a different preparation plan from one supplying a high-risk system. Check supplier documentation, update contracts where needed, and get specialist advice when classification or the impact on people is unclear. Review the assessment whenever you add a new AI feature or change an existing workflow.
Wrapping up
The EU AI Act affects businesses that use AI as well as those that develop it. Your responsibilities depend on the system's intended purpose, your role, and the provisions that apply, not simply on whether you bought a subscription or built the tool yourself.
Start by knowing what AI your business uses. Identify prohibited or potentially high-risk uses, check provider and deployer responsibilities, apply the relevant transparency measures, and track the right deadlines. Keep GDPR and other existing rules in the same assessment.
Thanks for reading! If your wider technology plans include running applications on EU infrastructure, QDE offers unmanaged KVM VPS hosting in Amsterdam with NVMe storage and full root access. Hosting location is one part of a data-governance decision, rather than proof of AI Act compliance.
Have questions about hosting your applications? Contact our team to discuss the infrastructure you need.
Frequently asked questions about the EU AI Act
Does the EU AI Act apply if my business only uses AI tools?
It can. A business using an AI system under its authority can be a deployer, even when a supplier developed the software. The relevant duties depend on the use case and your role.
Does every AI tool count as high-risk?
No. The Act identifies specific high-risk uses and product categories, with classification conditions and exceptions. Ordinary drafting or summarization is different from using AI to rank job applicants or assess creditworthiness.
What's the difference between a provider and a deployer?
A provider develops, or has developed, a system and places it on the market or puts it into service under its own name. A deployer uses a system under its authority in a professional context. One business can hold both roles.
Does open-source software avoid the AI Act?
There are specific exemptions for qualifying open-source systems and models, but no blanket exemption for every open-weight model or every business use. Check the relevant provision, your role, and the system's purpose.
Do customers need to know when they're talking to an AI chatbot?
Article 50 places an information duty on providers of systems intended to interact directly with people, unless the AI interaction is obvious in context. A business deploying the system should check that the necessary notice reaches its users.
What are the fines under the EU AI Act?
Up to €35 million or 7% of worldwide annual turnover for prohibited practices, up to €15 million or 3% for most other violations, and up to €7.5 million or 1% for supplying incorrect information to authorities. For SMEs, the lower of the applicable monetary or turnover cap generally applies; for other undertakings it is generally the higher. The violation, actor, and applicable provisions determine the actual exposure.
Does complying with the AI Act also cover GDPR?
No. The rules address different issues and can apply together. If an AI workflow processes personal data, assess GDPR obligations separately, including lawful basis, notices, data minimization, processor contracts, and any international transfers.