The best way to follow the EU AI Act is not to treat it as one deadline. Treat it as three separate workstreams: banned uses, transparency duties, and heavier obligations for high-risk systems and general-purpose AI. For most organizations, the first moves are straightforward: build an AI inventory, classify each use by role and risk, then tighten procurement, disclosures, documentation, and governance.
Key takeaways
The AI Act regulates AI by risk, with prohibited uses banned, some uses classified as high-risk, and lighter transparency duties applying to chatbots and deepfakes.
According to the AI Act summary, the main application timeline after entry into force was 6 months for prohibited systems, 12 months for GPAI, 24 months for Annex III high-risk systems, and 36 months for Annex I high-risk systems, while codes of practice were due after 9 months.
The TechTarget report says the Digital Omnibus entered into force on July 27, 2026 and pushed many high-risk AI obligations for standalone Annex III systems to Dec. 2, 2027, with some Annex I product-related obligations moved to August 2028.
Transparency obligations under Article 50 largely remain on track, including disclosure when people interact with AI and labeling certain AI-generated or manipulated content.
For most buyers and deployers, the first practical compliance question is not whether a model is famous or frontier; it is whether the intended use triggers prohibited, high-risk, or transparency duties.
What is the best search query to optimize for?
The clearest target query is EU AI Act compliance. That phrase matches what most professionals actually need: scope, deadlines, practical obligations, and the changes they should make now.
It also fits the source material better than a generic “AI Act summary.” People searching for “EU AI Act compliance” usually want an action plan, not a recital-by-recital walk through the law.
1. Decide whether the EU AI Act applies to you
Yes, the Act can apply even if your company is not based in the EU. Geography matters, but it is not the only filter. The real question is whether you provide, place on the market, put into service, or deploy covered AI in ways that affect the EU.
The high-level summary states that obligations primarily fall on providers of high-risk AI systems placed on the EU market or put into service in the EU, including providers based outside the EU where the output is used in the EU. It also says deployer obligations apply to users located in the EU and third-country users where the output is used in the EU. In the Act’s vocabulary, a provider is the organization developing or placing the system on the market, while a deployer is the organization using it professionally.
That distinction matters because companies often misjudge their burden:
If you build or white-label AI products, you may be closer to a provider role.
If you buy a model or SaaS and use it in HR, support, marketing, fraud, or operations, you are often a deployer.
If you fine-tune, rebrand, or materially modify an upstream system, your role can shift.
Decision rule: classify every AI use case by role first: provider, deployer, importer or distributor if relevant, or mixed. Do not start with the architecture diagram. Start with commercial and operational responsibility.
2. How does the EU AI Act classify AI systems?
The Act uses a risk-based structure. In plain English, some uses are banned, some are high-risk and heavily regulated, some trigger transparency duties, and many lower-risk uses face little direct regulation under the Act.
The summary source lays out four broad buckets:
Unacceptable risk: prohibited.
High-risk: allowed, but subject to substantial obligations.
Limited risk: mainly transparency obligations, such as making users aware they are interacting with AI.
Minimal risk: largely unregulated by the Act.
This is where many internal compliance efforts go off track. Teams ask, “Are we using GPT-4, Claude, Gemini, or open source?” The law often cares more about what the system does than which model powers it.
A practical mental model: model risk is upstream, use risk is downstream
This is one of the most useful ways to operationalize the Act. General-purpose AI model obligations sit upstream with model providers. Your obligations as a buyer or deployer usually sit downstream and depend on the use case you build around the model.
Example:
A general chatbot that answers product FAQs may mainly raise transparency duties.
The same underlying model used to rank job applicants can become high-risk under the employment category.
The same model used to generate deceptive impersonation content may create prohibited or separate legal problems, even if the model itself is lawful.
If you want a related framework for operational AI governance beyond legal compliance alone, LAXIMA’s guide on how to make your employees use AI effectively complements this well because policy only works when it connects to real workflows.
3. Which AI uses are prohibited under the AI Act?
The prohibited category is short, but it is the first thing to review. If a use falls here, the task is not to mitigate it. The task is to stop it.
According to the high-level summary of Article 5, prohibited systems include AI that uses subliminal, manipulative, or deceptive techniques causing significant harm; exploits vulnerabilities tied to age, disability, or socioeconomic status causing significant harm; social scoring; certain criminal-risk assessments based solely on profiling or personality traits; untargeted scraping of facial images to build facial recognition databases; certain emotion inference in workplaces and schools; and certain biometric categorization and real-time remote biometric identification uses, subject to narrow law-enforcement exceptions.
What to change now:
Ban these use cases explicitly in internal AI policy.
Add prohibited-use screening to procurement intake forms.
Require business owners to sign intended-use statements before launch.
Review experimental pilots, not just production systems. A lot of exposure hides in prototypes.
Practical warning: for most companies, prohibited-use exposure will not come from a grand AI platform strategy. It will come from a local team improvising with cheap tools: scraping faces, scoring worker emotions, or nudging vulnerable users with persuasion systems that no one reviewed.
4. What counts as high-risk AI under the EU AI Act?
High-risk AI is not “anything important.” It is a defined legal category tied either to regulated products in Annex I or to listed use cases in Annex III, subject to exceptions.
The summary explains that high-risk systems include AI used as a safety component of products covered by Annex I laws where third-party conformity assessment is required, or AI used in Annex III use cases unless an exemption applies for narrow procedural, supportive, or preparatory functions. It also notes that Annex III systems are always high-risk if they profile individuals.
The listed Annex III areas include:
Biometrics
Critical infrastructure
Education and vocational training
Employment and worker management
Essential public and private services, including creditworthiness and some insurance contexts
Law enforcement
Migration, asylum, and border control
Administration of justice and democratic processes
A practical triage test for high-risk candidates
Ask these five questions in order:
Does the system help decide access to work, education, credit, benefits, insurance, public services, or legal outcomes?
Does it influence safety-critical infrastructure or regulated products?
Does it profile individuals or score them in ways that affect material outcomes?
Does it replace, constrain, or heavily steer a human decision rather than merely assist with clerical steps?
If we removed the AI, would the underlying decision still be considered sensitive or rights-affecting?
If the answer is yes to several of these, escalate. This triage test is not the law. It is a shortcut for catching likely high-risk cases early, before legal review.
5. What are the main obligations for high-risk AI providers?
Providers of high-risk AI face the heaviest operational burden. The core obligations are not one form or one filing. They amount to an operating system for controlled development and deployment.
According to the summary of Articles 8 to 17, providers of high-risk AI must establish a risk management system, conduct data governance, create technical documentation, enable record-keeping, provide instructions for use, enable human oversight, meet appropriate levels of accuracy, robustness, and cybersecurity, and maintain a quality management system.
What to change if you are a provider:
Create one accountable owner for each high-risk system.
Write intended-purpose statements and prohibited-purpose statements.
Version training data sources, evaluation methods, and material model changes.
Define human-oversight checkpoints that are real, not cosmetic.
Log inputs, outputs, overrides, incidents, and post-release changes.
Bundle customer-facing instructions into product delivery, not legal fine print.
This overlaps with basic engineering discipline. If your AI stack is already weak on reliability, observability, and change control, the Act will expose it. LAXIMA’s guide AI-Generated Code Is Cheap. Reliability Isn’t is relevant here because AI compliance breaks down when the underlying software process is messy.
6. What about GPAI models and downstream users?
General-purpose AI, or GPAI, refers to models with broad capability across many tasks that can be integrated into many downstream systems. The Act places direct obligations on GPAI model providers, but downstream companies still need to care because those documents and controls feed their own compliance work.
The summary says all GPAI model providers must provide technical documentation, information for downstream providers, a policy to respect the Copyright Directive, and a sufficiently detailed summary of training content. It adds that free and open licence GPAI model providers have lighter obligations unless the model presents systemic risk.
For GPAI models with systemic risk, the summary says the threshold is training compute greater than 10^25 FLOPs, after which providers must notify the Commission within 2 weeks and take additional steps including model evaluations, adversarial testing, systemic risk mitigation, incident reporting, and cybersecurity measures.
What to change if you buy third-party models:
Ask vendors for the documentation the Act expects them to maintain.
Map each vendor model to each internal use case, not one generic approval.
Do your own task-specific testing instead of trusting a model card alone.
Update contracts to define incident reporting, documentation refresh, and change-notice duties.
The TechTarget piece makes the procurement point clearly: enterprises need evidence, not marketing claims. It also warns against assuming certifications like ISO 27001 or ISO 42001 automatically prove AI Act compliance.
That matters even more as teams adopt multiple agents and copilots. If visibility is already a problem, LAXIMA’s analysis of the agent sprawl problem is worth reading.
7. What deadlines should you actually track?
Track the implementation timeline by obligation type. Do not rely on a single memorized date. The timeline has already shifted, and guidance can arrive close to the deadlines.
The high-level summary states that after entry into force, the Act would apply after 6 months for prohibited AI systems, 12 months for GPAI, 24 months for Annex III high-risk systems, and 36 months for Annex I high-risk systems, with codes of practice due after 9 months. TechTarget reports that the Digital Omnibus entered into force on July 27, 2026 and delayed many high-risk obligations, moving standalone Annex III systems to Dec. 2, 2027 and Annex I product-related obligations to August 2028, while transparency requirements under Article 50 largely remained on track and GPAI requirements were unaffected by the delay.
The only timeline dashboard most teams need
Workstream | What to watch | Why it matters first |
|---|---|---|
Prohibited uses | Immediate identification and shutdown | You cannot mitigate your way out of a banned use. |
Transparency | Chatbot disclosure, AI-generated content labeling, deepfake rules | These obligations hit many ordinary business uses sooner than high-risk regimes. |
GPAI procurement | Vendor docs, copyright policy signals, incident channels | Your provider’s compliance posture affects your own downstream risk. |
High-risk readiness | Inventory, classification, documentation, oversight design | Even with delayed dates, the heavy lifting is organizational and takes time. |
Useful planning frame: separate the AI Act into urgent, ongoing, and conditional work.
Urgent: prohibited-use screening and transparency fixes.
Ongoing: inventory, procurement, training, governance, logging.
Conditional: full high-risk controls only where classification confirms they are needed.
That approach reduces two common mistakes at once: over-compliance panic and under-compliance drift.
8. What should most companies change first?
Start with the boring controls. They matter more than polished AI principles pages.
For most organizations, the right first changes are:
Build an AI inventory. Include bought tools, embedded features, internal prototypes, and department-level automations.
Classify each use case. Role, intended purpose, affected users, geography, risk bucket, and vendor dependency.
Patch transparency gaps. Add disclosure where people interact with AI and where synthetic content needs labeling.
Fix procurement. Require model documentation, change notices, testing evidence, and escalation routes from vendors.
Assign ownership. Every material AI system needs a business owner and a technical owner.
Train staff. Especially HR, legal, procurement, marketing, support, and operations.
This is why AI literacy matters operationally, not just legally. A policy no one understands is theater. LAXIMA’s AI Readiness Assessment can help teams spot whether governance, process, and adoption basics are actually in place.
9. How do you follow the AI Act without building a full compliance department?
You need a repeatable monitoring loop, not a giant policy program. Most mid-sized organizations can track the Act with one monthly review cycle and a small cross-functional group.
Use this structure:
Monthly tracking loop
Review European Commission guidance and AI Office updates relevant to your use cases.
Review vendor notices for model changes, documentation updates, or new restrictions.
Review your AI inventory for new pilots and shadow AI.
Review incidents, complaints, override patterns, and false positives.
Review whether any use case has moved closer to a high-risk category.
Minimum governance group
Legal or privacy lead
Security lead
Procurement owner
AI or data lead
Business owner from each sensitive function: HR, operations, customer service, marketing, finance
Cost and effort reality check: the expensive part is rarely the policy draft. It is the inventory, the cross-functional review time, the testing, and the documentation discipline. Small firms should use the lighter-weight support mechanisms the SME guide highlights, including sandboxes, simplified documentation, training, and dedicated communication channels where available.
The SME guide notes that the Act mentions SMEs 38 times, compared with 7 mentions of industry and 11 of civil society, and describes measures such as at least one national regulatory sandbox per Member State, priority and free access for SMEs, and proportional conformity assessment fees. It also cites the EU SME definition thresholds: medium-sized enterprises have fewer than 250 employees and turnover below €50 million and/or balance sheet total below €43 million; small enterprises have fewer than 50 employees and turnover and/or balance sheet below €10 million; microenterprises have fewer than 10 employees and turnover and/or balance sheet below €2 million.
10. Common pitfalls that create AI Act exposure
Most failures will come from misclassification, overreliance on vendors, and weak internal visibility.
Treating all AI as the same. A writing assistant and a hiring ranker are not the same regulatory problem.
Confusing model compliance with system compliance. Your vendor can be well documented while your use case is still high-risk or unlawful.
Ignoring transparency because the system seems harmless. Many ordinary chat and content workflows still trigger disclosure duties.
Waiting for perfect standards. Delay is not a strategy. Inventory, governance, and procurement can start now.
Forgetting legacy and shadow tools. The unapproved browser plugin is often a bigger compliance risk than the official platform.
Assuming open source means exempt. Some obligations lighten for free and open licence GPAI models, but downstream use-risk analysis still remains.
11. Verification checklist: are you actually ready?
If you cannot answer these questions with evidence, you are not ready yet.
Do we have a current inventory of AI systems, models, and AI-enabled features in use?
Has each use case been classified by role, intended purpose, geography, and risk bucket?
Have we screened for prohibited uses under Article 5 categories?
Do our chatbots and synthetic content workflows meet applicable transparency expectations?
Do we know which vendors provide GPAI models or AI subsystems to us?
Have we requested and stored the vendor documentation we need for downstream risk review?
For sensitive use cases, do we have human oversight, logging, incident handling, and change control?
Do HR, procurement, marketing, and operations know what kinds of AI use need escalation?
Do we have a monthly process to track guidance, vendor changes, and new internal pilots?
Have we documented why borderline cases are not high-risk where we rely on an exemption?
The broader lesson is simple. The AI Act is not mainly a paperwork law. It is a systems-and-accountability law. Organizations that already know what AI they use, why they use it, who owns it, and how they monitor it will adapt faster than organizations still treating AI adoption as scattered experimentation.
For ongoing practical updates on frontier AI governance and implementation shifts, follow LAXIMA’s free AI Signal news feed.
Frequently asked questions
Does the EU AI Act apply to companies outside Europe?
Yes. The Act can apply to organizations outside the EU when they provide or deploy covered AI systems whose output is used in the EU. The key issue is not only where a company is headquartered, but whether its AI systems are placed on the EU market, put into service there, or used in ways that affect people or operations in the EU.
What is the difference between a provider and a deployer under the EU AI Act?
A provider is generally the organization that develops an AI system or places it on the market under its own name. A deployer is the organization using that AI system in a professional context. This distinction matters because the heaviest obligations often fall on providers, while deployers usually face narrower duties tied to use, oversight, and transparency.
Are all chatbots high-risk under the EU AI Act?
No. Many chatbots are not high-risk, but they can still trigger transparency obligations. The major question is what the chatbot does. A general customer-service bot may mainly need clear disclosure that a person is interacting with AI, while a chatbot used inside a high-stakes workflow like hiring or eligibility decisions can create a different compliance profile.
Does using an open-source model avoid EU AI Act obligations?
No. Some obligations are lighter for certain free and open licence GPAI model providers, according to the Act summary, but that does not remove downstream obligations for companies using those models in products or workflows. The intended use still determines whether a system is prohibited, high-risk, or subject to transparency duties.
What should small businesses do first about EU AI Act compliance?
Small businesses should start with an AI inventory, basic use-case classification, prohibited-use screening, and vendor review. The SME-focused guidance in the sources also highlights support measures such as regulatory sandboxes, simplified documentation, training, dedicated communication channels, and proportional fees. Small firms usually get the best return from governance basics before building heavier formal processes.
Why does AI procurement matter so much under the EU AI Act?
Because many organizations do not build foundation models themselves; they buy tools, APIs, copilots, or embedded features from others. That means compliance depends partly on what vendors can document about capabilities, limitations, copyright-related policies, testing, and incident handling. Procurement becomes the point where legal, technical, and operational risk information must be collected before deployment.
