The EU AI Act is fully in motion, obligations are phasing in on a fixed calendar, and the penalties are large enough to matter to any software company touching the European market. If you build, resell, or deploy AI in your product, EU AI Act compliance is now an engineering and governance requirement, not a legal footnote.
This guide explains, in plain language, what the law covers, how to tell which obligations apply to you, and what to do about it in 2026.
What the EU AI Act actually regulates
The EU AI Act is the first comprehensive horizontal law on artificial intelligence and it entered into force in 2024. It is not about a specific technology; it regulates AI systems by the risk they pose to people, regardless of whether you built the model or simply plugged one into your product. It applies extraterritorially: if your AI system is used in the EU, the rules can reach you even if your company sits in Tallinn, Tunis, London, or elsewhere.
The core idea behind this piece of AI regulation Europe has watched closely is proportionality. The higher the potential for harm, the heavier the obligations.
The risk tiers, in plain language
The Act sorts systems into four bands:
- ▸Unacceptable risk (prohibited). Practices such as social scoring by public authorities, manipulative systems that exploit vulnerabilities, and certain biometric categorization are banned outright. These prohibitions are already in effect.
- ▸High risk. Systems used in areas like recruitment, credit scoring, critical infrastructure, medical devices, education, and law enforcement. These carry the heaviest obligations and are the main compliance burden for most serious software firms.
- ▸Limited risk. Systems like chatbots and generative tools carry transparency duties. Users must be told they are interacting with AI, and AI-generated or manipulated content must be labelled.
- ▸Minimal risk. Most software, from spam filters to recommendation features, faces no new mandatory obligations, though voluntary codes of conduct are encouraged.
The first practical step in AI Act for software teams is simply classifying every AI feature you ship into one of these bands.
Are you a provider or a deployer?
Your obligations depend on your role, and many companies are both:
- ▸A provider develops an AI system, or has one developed, and places it on the market under its own name. Providers carry the bulk of the duties for high-risk systems.
- ▸A deployer uses an AI system under its own authority in a professional context. Deployers have lighter but real obligations around proper use, human oversight, and monitoring.
Crucially, if you take a third-party model and put your own branding on a high-risk use, or substantially modify it, you can become a provider with the full obligation set. Do not assume that buying a model outsources your compliance. The same caution applies to open-weight models you fine-tune and to integrations where you materially change the intended purpose of a system. When in doubt, write down who does what across the chain, because the Act allocates responsibility along that chain and gaps tend to land on whoever ships to the end user.
What software companies must do in 2026
For a high-risk system, providers must build a compliance program, not just paperwork. In practice that means:
- ▸Risk management. A documented, ongoing process to identify and mitigate risks across the lifecycle.
- ▸Data governance. Training and testing data that is relevant, representative, and checked for bias where feasible.
- ▸Technical documentation. Detailed records that let authorities assess conformity.
- ▸Logging and traceability. Automatic record-keeping so events can be reconstructed.
- ▸Transparency and instructions. Clear information so deployers can use the system correctly.
- ▸Human oversight. Design that lets a person understand, monitor, and override the system.
- ▸Accuracy, robustness, and cybersecurity. Appropriate performance and resilience against manipulation.
- ▸Conformity assessment and registration. Demonstrating conformity and, for many high-risk systems, registering in the EU database before going to market.
Deployers, in turn, must use the system per instructions, ensure meaningful human oversight, keep logs, and monitor operation. For limited-risk systems, the main duty is transparency: label the AI and label synthetic content.
General-purpose AI and foundation-model obligations
The Act also sets rules for general-purpose AI (GPAI) models, the foundation models many products build on. Providers of these models face transparency and documentation duties, must publish a summary of training content, and must respect EU copyright rules. Models judged to carry systemic risk face additional obligations around evaluation, incident reporting, and security. If you fine-tune or heavily adapt such a model, check whether you inherit provider duties. Even if you only consume a GPAI model through an API, you should keep records of which model version you use and how.
Timelines and penalties
The obligations arrive in waves rather than all at once. Prohibited-practice bans applied first, GPAI and governance duties followed, and the heavier high-risk obligations phase in across 2026 and into 2027. The direction of travel is clear: the window to prepare is closing, not opening.
The penalties are deliberately severe. Breaching the prohibitions can draw fines up to 35 million euros or 7 percent of global annual turnover, whichever is higher. Other obligation breaches can reach 15 million euros or 3 percent of turnover, and supplying incorrect information to authorities can reach 7.5 million euros or 1 percent. For most companies, the reputational and contractual fallout of non-compliance is just as damaging as the fine.
Practical first steps this quarter
You do not need a finished program tomorrow, but you should start now:
- ▸Inventory your AI. List every AI feature, the model behind it, and its purpose.
- ▸Classify each one into a risk band and note whether you are provider or deployer.
- ▸Prioritize high-risk features for the full obligation set and flag anything that might touch a prohibited practice.
- ▸Add transparency labels to chatbots and generative outputs now, since this is low effort and already expected.
- ▸Stand up documentation and logging as a habit, not a scramble before an audit.
- ▸Assign an owner. Compliance without a named accountable person tends not to happen.
- ▸Track your model supply chain. Record which GPAI models and versions you depend on and keep the vendor documentation you may need to rely on.
Treat this as an extension of the security and privacy work you already do rather than a separate silo. Much of what the Act asks for, documented risk management, logging, access control, and clear human oversight, overlaps with good engineering and with GDPR obligations you likely address already. Building on those foundations is far cheaper than standing up a parallel compliance machine, and it means each new AI feature ships with the evidence of conformity baked in rather than bolted on before an audit.
How TuniCyberLabs helps
Most software teams do not need a law firm to get started; they need engineers who understand both the regulation and the codebase. TuniCyberLabs helps companies map their AI features to the Act, build the documentation, logging, human-oversight, and data-governance controls the law expects, and keep data handling aligned with GDPR and EU residency requirements, all delivered from an EU base with cost-efficient engineering in Tunisia.
If you are unsure which parts of the EU AI Act apply to your product, get in touch with TuniCyberLabs for a focused compliance readiness review.