The EU AI Act — Regulation (EU) 2024/1689 — applies to companies established outside the European Union. That is the sentence that matters for an Azerbaijani software company, outsourcing provider or bank with European operations, and it is the sentence most often missed because the regulation is filed mentally under "European problem".

The Act reaches you in two ways: if you place an AI system on the EU market, and if you are a provider or deployer in a third country whose system's output is used in the Union. The second limb is the broad one. An Azerbaijani company building a screening tool for a German client is in scope even though it has no EU entity, no EU office and no EU customer of its own.

This article covers who is captured, what obligations follow, how the timeline changed in 2026, and what a reasonable response looks like this year.

Who is actually in scope

Four common patterns, and the first two catch most Azerbaijani companies.

Software built for EU clients. You develop a system that includes an AI component and your client deploys it in the EU. You are the provider. Your client is the deployer. Both carry obligations, and yours are the heavier set if the system is high-risk.

Outsourced development and BPO. You build or operate part of an EU customer's AI system. Your contractual position determines whether you are a provider, but your commercial position is simpler: your client's compliance obligations arrive as contractual requirements on you, regardless of how the regulation classifies you.

An EU subsidiary or branch. Straightforwardly in scope for anything it deploys.

Serving EU-resident individuals. If your system's output affects people in the Union, the extraterritorial limb applies whether or not you have any EU corporate presence.

Not in scope: a purely domestic Azerbaijani system whose output stays in Azerbaijan. That is a real exemption, and it is worth establishing clearly rather than assuming the Act applies to everything you build.

The risk tiers

The Act classifies by use, not by technology. The same model is unregulated in one application and high-risk in another, which is why an inventory organised by system rather than by model is the only workable basis for compliance.

Prohibited practices. Social scoring by public authorities, certain biometric categorisation, manipulative techniques exploiting vulnerability, and untargeted scraping of facial images. These are banned outright, and the penalties are the highest in the regulation — up to €35 million or 7% of global annual turnover.

High risk. The tier that carries the substantive obligations. It includes AI used in employment and worker management, education access, creditworthiness assessment, access to essential public and private services, law enforcement, migration, and safety components of regulated products. For an Azerbaijani company, credit scoring and recruitment screening are the two that come up most often.

Limited risk. Transparency obligations. Users must be told they are interacting with an AI system; synthetic content must be marked as such. Most customer-facing chatbots land here, and the obligation is genuine but light.

Minimal risk. Everything else. No specific obligations, though voluntary codes are encouraged.

General-purpose AI models carry their own obligations on documentation, training data summaries and copyright policy, sitting alongside the tiers above rather than inside them.

What high-risk classification actually requires

If a system is high-risk, the obligations are substantial and several of them are data governance obligations wearing a different name.

A risk management system across the lifecycle, documented and maintained rather than produced once.

Data governance for training, validation and testing data — quality criteria, examination for bias, and documented provenance. This is the requirement that is unmeetable without a catalog, and it is where organisations discover that they cannot say where their training data came from. If you cannot trace a reporting figure, you will not be able to trace a training set either, because it is the same missing capability. See data lineage explained.

Technical documentation and automatic logging sufficient to trace the system's functioning. Logs are not optional and cannot be reconstructed after the fact.

Transparency to deployers — information sufficient for the deployer to use the system correctly and to understand its limitations.

Human oversight designed in, such that a person can understand, monitor and override. A review step that approves 99.8% of cases is a signature rather than oversight; measure the disagreement rate.

Accuracy, robustness and cybersecurity appropriate to the purpose, declared and maintained.

Plus conformity assessment, registration and a post-market monitoring plan. The practical shape of all this is close to an ISO/IEC 42001 management system, which is why organisations pursuing both find substantial overlap — see the ISO 42001 audit.

The deadlines moved — the obligations did not

This is the part where 2026 guidance diverges from 2025 guidance, and getting it wrong in either direction is costly.

The Digital Omnibus, adopted as Regulation (EU) 2026/1744, deferred most high-risk obligations from August 2026 to December 2027 and August 2028 — with high-risk systems embedded in regulated products moving to the later date. Transparency duties and GPAI enforcement began on 2 August 2026.

Two consequences worth being precise about. First, if you are building a high-risk system now, you have more time than the original schedule allowed — and the data governance work is the long pole regardless, so the extension does not change what you should start. Second, if your systems are limited-risk, your obligations are already live, and the transparency requirements are the ones most likely to be breached inadvertently by a chatbot that does not disclose itself.

Penalties, and the more likely commercial risk

The headline figures are up to €35 million or 7% of global turnover for prohibited practices, and up to €15 million or 3% for most other breaches.

For an Azerbaijani company, the enforcement risk is real but secondary. The likelier and nearer risk is commercial: your EU client cannot deploy a system that does not meet their obligations, so their compliance requirements arrive as contractual terms, procurement questionnaires and audit rights. Companies lose contracts over this well before any regulator is involved, and the first sign is usually a client questionnaire asking questions you cannot answer.

Being able to answer them is, in that light, a sales asset rather than a compliance cost. That is the honest framing for a board.

What to do this year

Five steps, in order, and none of them requires a large budget.

Inventory your AI systems. Including AI inside software you bought and models running informally. For each: what it does, whose output it affects, and whether any of that output reaches the Union.

Classify by use. Prohibited, high-risk, limited, minimal. Do this per system and record the reasoning — the classification is the thing a client questionnaire asks about, and the reasoning is what makes it defensible.

Fix the data provenance gap. For anything high-risk, establish where the training and grounding data came from, what it contains, and who owns it. This is the longest lead-time item and the one that cannot be accelerated at the end.

Turn on logging. Request-level records: who asked, what was retrieved, which model and version, which tools, what came back. The single decision that cannot be corrected retroactively.

Make human oversight real. Design the review so the reviewer has the information and the time to disagree, and measure how often they do.

Then, if it is commercially useful, pursue ISO/IEC 42001 — organisations with an existing ISO 27001 management system typically reach certification in four to six months, against six to twelve starting cold, and the certificate answers most of a client questionnaire in one document.

Key points

  • The AI Act applies extraterritorially: if your system's output is used in the Union, you are in scope with no EU entity required.
  • Classification is by use, not technology. The same model is unregulated in one application and high-risk in another.
  • High-risk obligations are largely data governance obligations — provenance, quality, documentation — plus logging, oversight and conformity assessment.
  • The Digital Omnibus deferred most high-risk deadlines to December 2027 and August 2028; transparency and GPAI enforcement began 2 August 2026.
  • The nearer risk for an Azerbaijani supplier is commercial, not regulatory: client questionnaires and contractual terms arrive first.
  • Start with an inventory, classify per system, fix data provenance, turn on logging. Provenance has the longest lead time.

We advise on AI governance and build the controls that make it evidenceable — see AI policy and governance. Related reading: what is AI governance and the ISO 42001 audit.