EU AI Act Compliance in 2026: What the August 2 Deadline Means for Your Software

On 2 August 2026, the majority of the European Union's Artificial Intelligence Act became applicable. This was not a proposal, a consultation, or a future-dated warning. The obligations are live, the penalties are real, and the scope is considerably wider than most software teams outside Europe assume.

If you build software that uses AI in any form, and any part of your user base sits inside the European Union, this applies to you. This guide covers what changed, how to work out whether you are in scope, and what the first genuinely useful compliance steps look like.

What actually changed on 2 August 2026

The AI Act has been phasing in since February 2025. The August 2026 milestone is the largest single tranche: most remaining provisions became applicable on that date, including the transparency obligations set out in Article 50.

One notable exception exists. Article 6(1), which covers a particular route to high-risk classification, applies from August 2027 instead. Everything else in the main body of the Act is now enforceable.

The penalty exposure for breaching transparency obligations reaches €15 million or 3% of worldwide annual turnover, whichever is higher. Prohibited-practice breaches carry higher ceilings still. These are turnover-based penalties, which means they scale with the size of the business rather than the size of the infringing product.

The scope question most teams get wrong

The single most common misreading we encounter is treating the AI Act as a European regulation that applies to European companies. It is not structured that way.

The Act applies to providers, deployers, importers and distributors that place AI systems on the EU market. Critically, it also reaches situations where the output of an AI system is used within the European Union, even if the system itself runs entirely elsewhere.

The practical consequence: a US-registered SaaS company, hosting on US infrastructure, with an engineering team in India and no European entity, is in scope the moment it has European users. Registration and hosting location are not the test. Market reach is.

This mirrors how GDPR works, and companies that already went through GDPR scoping will recognise the pattern. The difference is that GDPR asks about personal data, while the AI Act asks about AI systems and their use cases.

Working out which role you occupy

The Act assigns duties by role, and the same company can occupy different roles for different systems.

A provider develops an AI system and places it on the market under its own name or trademark. Provider obligations are the heaviest: conformity assessment, technical documentation, risk management systems, post-market monitoring.

A deployer uses an AI system under its own authority in a professional capacity. Deployer duties are lighter but far from trivial: human oversight, input data relevance, monitoring, and record-keeping.

For most software companies building on top of foundation models, the default position is deployer. But the line moves. Substantially modifying a system, or putting your own name on it as though you built it, can make you a provider with the full obligation set. If you are white-labelling an AI capability to your own customers, assume provider status until you have taken advice saying otherwise.

The risk classification that determines your workload

The AI Act is risk-tiered, and the tier is driven by use case, not by technical sophistication.

Tier	What it covers	Practical effect
Prohibited	Social scoring, certain biometric categorisation, manipulative techniques	Cannot be deployed at all
High-risk	Employment, credit, education, essential services, biometrics, critical infrastructure	Full conformity, documentation, oversight, logging
Limited risk	Systems interacting with people, generating or manipulating content	Transparency and disclosure duties
Minimal risk	Everything else	No specific obligations

The distinction that matters most in practice: the same model can sit in different tiers depending on what you point it at. A large language model answering product support questions is generally limited risk. That identical model screening job applications is high-risk, because employment decisions are a listed high-risk domain. The regulation follows the decision being made, not the architecture making it.

This is why an inventory of AI use cases is more useful than an inventory of AI systems. Two features running on the same endpoint can carry entirely different obligations.

What Article 50 transparency actually requires

The transparency obligations that took effect are the ones most likely to catch general software products, because they apply well below the high-risk threshold.

In broad terms, people must be told when they are interacting with an AI system rather than a human, unless that is obvious from context. Synthetic content — generated or manipulated audio, image, video and text — carries marking and disclosure duties so that it is detectable as artificially generated. Systems performing emotion recognition or biometric categorisation must inform the people exposed to them.

For a typical SaaS product, this translates into concrete build work: labelling AI-powered chat interfaces, disclosing AI involvement in generated content, and making sure those disclosures survive the places your content actually travels to, including exports and API responses.

The engineering point worth internalising is that disclosure is a product surface, not a legal footer. A line in your terms of service does not discharge a duty to tell a user, in the moment, that the thing answering them is a model.

A first-90-days plan that is actually achievable

Compliance programmes fail when they start with policy documents. The sequence that works starts with facts.

Build the AI use-case inventory. Every place your product uses AI, what decision it influences, what data it consumes, which model provider sits behind it, and who the affected people are. This is a spreadsheet exercise before it is a legal one, and engineering has to lead it because engineering is the only function that knows where the calls actually happen.

Classify each use case against the risk tiers. Most entries will land in limited or minimal risk. The ones that land in high-risk deserve immediate, separate attention because their obligation set is an order of magnitude heavier.

Ship the transparency layer. Disclosure on AI interactions, marking on generated content, and documentation of what you disclose and where. This is the piece with the nearest deadline and the most direct penalty exposure, and it is largely a front-end and content-pipeline job.

Stand up logging and human oversight where required. High-risk systems need records and meaningful human review. Building this well overlaps almost entirely with good AI agent observability practice, which means the instrumentation you build for debugging can double as regulatory evidence if you design it that way from the start.

Pick a governance framework and commit to it. The Act tells you what outcomes are required, not how to organise for them. That is where ISO 42001 and the NIST AI RMF come in, and choosing one early stops the compliance work from fragmenting across teams.

The part nobody wants to hear

There is no tool that makes you AI Act compliant. The vendors selling one are selling a component of the answer — usually documentation templates or a model registry — and calling it the whole.

The work is genuinely organisational. It requires knowing what your software does, being able to prove it, and having a human who is accountable when it makes a decision about a person. Companies that have already done SOC 2 or HIPAA work will find the muscle familiar even though the subject matter is new.

The companies that will struggle are the ones that shipped AI features fast over the last two years without recording what they built, what data trained or grounded it, or who signed off on letting it make decisions. Reconstructing that history retroactively is far more expensive than capturing it as you go.

Where to start if you are already behind

The deadline has passed, which means the useful question is no longer how to prepare but how to close the gap fastest.

Start with the inventory and the transparency layer, in that order. The inventory tells you your actual exposure, which is almost always smaller and more concentrated than teams fear. The transparency layer addresses the obligations with the most immediate reach and the clearest penalty attached.

At Ortem Technologies we build AI systems for clients across the US, UK, EU and Middle East, and compliance architecture is part of how we scope them rather than a phase bolted on at the end. If you need help mapping your AI use cases against the Act's risk tiers, or building the disclosure and logging layers the Act now requires, talk to our team or review our compliance approach and AI development services.