The EU AI Act: what software teams actually have to do

The Act does not regulate AI in general. It regulates specific uses, sorted into four tiers, and almost every practical question about compliance resolves once you know which tier applies to you.

<strong>Unacceptable risk</strong> practices are banned outright and have been since February 2025 — social scoring by public authorities, manipulative techniques that exploit vulnerabilities, untargeted scraping of facial images to build recognition databases, and emotion inference in workplaces and schools. If your roadmap contains any of these, the answer is not compliance work, it is removing the feature.

<strong>High risk</strong> is the tier with real engineering obligations, and it is defined by use case rather than by technical sophistication. A straightforward model that screens job applications is high risk. A far more advanced model that suggests products to shoppers is not.

<strong>Limited risk</strong> carries transparency duties only. <strong>Minimal risk</strong> — the majority of business software — carries no specific obligations beyond the general AI-literacy duty on staff who operate the systems.

Annex III lists the high-risk use areas: biometric identification, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services including creditworthiness assessment, law enforcement, migration and border control, and the administration of justice.

Two patterns catch teams by surprise. The first is recruitment: any AI that filters, ranks, or scores candidates is high risk, which pulls a great many HR-tech products and internal hiring tools into scope. The second is creditworthiness, which extends beyond banks to any lending, instalment, or buy-now-pay-later feature that uses a model to assess a person.

If you are high risk, the obligations are substantial: a documented risk management system, data governance covering training data quality and bias, technical documentation, automatic event logging, human oversight design, accuracy and robustness testing, a quality management system, and registration in the EU database. These obligations became applicable on 2 August 2026 for Annex III systems, and apply from 2 August 2027 for AI embedded in products already covered by EU product safety law.

Article 50 is the part most teams will actually have to implement, because it applies regardless of how mundane the system is.

If users interact with an AI system, they must be told, unless it is obvious from context. In practice that means a support chatbot needs to disclose that it is a bot — which most well-designed chatbots already do, because hiding it damages trust anyway.

Synthetic or manipulated image, audio, video, and text content must be machine-readably marked and disclosed. If your product generates marketing copy, images, or synthetic voice, this applies to you. Deepfakes require explicit disclosure.

These duties are cheap to satisfy if designed in and expensive to retrofit, because marking has to happen at generation time rather than being bolted on later.

The Act reaches providers who place an AI system on the EU market or put it into service in the EU, regardless of where the provider is established. It also reaches providers and deployers outside the EU where the output of the system is used in the EU.

For a US SaaS company with EU customers, an Australian product with EU users, or a South African business serving EU clients, the practical test is not where your servers are. It is whether EU users interact with the system or its output affects people in the EU. Usually they do, and it does.

Providers established outside the EU offering high-risk systems must appoint an authorised representative in the Union. This is an administrative step worth identifying early, because it takes longer to arrange than the engineering work it accompanies.

Obligations for general-purpose AI models fell on the model providers from 2 August 2025, not on you as an integrator. OpenAI, Anthropic, Google, and Mistral carry the documentation, copyright policy, and training-data summary duties for their own models.

What transfers to you is the system you build around the model. If you fine-tune a model substantially or place a system on the market under your own name, you may take on provider obligations for that system. Reselling a thin wrapper over someone else's model under your own brand is the case most often misjudged.

Practically, keep a record of which models and versions you use, what you send them, and what you do with the output. That record is the foundation of every compliance conversation that follows, and it is far easier to maintain from the start than to reconstruct.

Start with an inventory. List every place AI touches your product or operations, including features nobody thinks of as AI — scoring, ranking, routing, matching, forecasting. Most teams find more than they expected.

Classify each entry against the tiers. In our experience the majority land in limited or minimal risk, and the work reduces to disclosure and content marking. That result is worth confirming quickly, because it prevents a great deal of unnecessary anxiety.

For anything that looks high risk, get proper legal advice rather than relying on an engineering read of the annexes. The penalties are serious — up to €35 million or 7% of worldwide annual turnover for prohibited practices, and up to €15 million or 3% for other breaches — and the classification questions are genuinely finely balanced.

One thing worth saying plainly: this article is an engineering perspective on what the Act asks software teams to build, not legal advice. Use it to scope the work and brief your counsel, not to replace them.