Enterprise AI adoption in Azerbaijan is concentrated in banking, telecoms and the public sector, and it is bounded by three things: data that is not yet in a state where models can use it, regulatory constraints that rule out the easiest deployment path, and a shortage of people who have taken an AI system to production and operated it afterwards. The organisations making real progress are not the ones with the largest ambitions. They are the ones that picked narrow problems with measurable outcomes and fixed their data first.

Two figures frame the whole discussion. McKinsey's 2026 State of AI research finds 88% of organisations using AI in at least one function while only 39% report any EBIT impact, with around two-thirds not yet scaling beyond pilots. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027 on cost, unclear value and inadequate risk controls. Those are global numbers. Nothing we see in Azerbaijan contradicts them; the local constraints simply make the gap wider and the causes easier to name.

This article describes what we observe implementing these systems here. Where a local statistic would help, it says so rather than borrowing an international average and presenting it as Azerbaijani — no credible survey of this market exists yet, which is why Yukon Labs is running one.

The policy context has changed

The government has moved AI from aspiration to programme, and the timing matters for anyone building a business case this year.

Azerbaijan's Innovation and Digital Development Agency approved an Artificial Intelligence Strategy for 2025–2028, with data governance, workforce, public-private collaboration, security and ethics as named priorities. The Action Plan for the Acceleration of Digital Development for 2026–2028 was approved by presidential decree on 27 February 2026 and carries 58 initiatives across digitalisation, artificial intelligence, the innovation ecosystem and cybersecurity. A Digital Development Council, chaired at vice-presidential level, held its first meeting on 29 June 2026 and put the legislative framework for AI on the agenda.

For a state institution, that is a mandate with dates attached. For a bank, it signals the regulatory direction: documentation, traceability and accountability requirements are being written now, not later.

Where the market actually is

Adoption is bimodal rather than gradual, which is the most useful thing to understand about it.

A small number of large institutions — the major banks, the largest telecoms operators, several state entities — have moved past experimentation and are running AI in production against real business processes. They have dedicated teams, they have made infrastructure decisions, and they are dealing with second-order problems: evaluation, model governance, cost per query.

Most other large organisations are in a longer pilot phase. There is a chatbot somewhere. Someone has tried a document extraction proof of concept. A vendor has demonstrated something impressive. None of it has changed a business process, and there is quiet uncertainty about why the gap between the demo and production has proved so wide.

The distance between those two groups is not budget and it is not talent. It is almost always data readiness, and secondarily the absence of anyone who has previously operated an AI system after launch.

The sectors that move first, and why

Banking leads, for structural reasons. Sector assets stood at roughly 57.1 billion manats — about $33.6 billion — as of 1 April 2026, up 6.7% year on year, and the digital baseline is already high: Kapital Bank's Birbank passed 3.4 million active users, and CBAR is targeting cashless payments above 40% of retail transactions with over 90% of customer transfers through digital channels. Banks have digitised transaction data going back years, a clear set of expensive processes worth automating, regulatory pressure that forces disciplined documentation, and budgets that can absorb infrastructure. They also have the strictest deployment constraints, which is why almost every serious banking AI project here becomes an on-premise project.

Telecoms follow, with large volumes of behavioural data and well-defined use cases in churn, support automation and network operations.

The public sector is moving, driven by service-delivery digitisation and now by the 2026–2028 action plan. The constraints are strongest here — citizen data, sovereignty, procurement — and the potential impact is largest, because the processes being automated are high-volume and currently manual.

Large industrial and energy organisations have the most valuable untapped data in the country and are generally the least far along, because their data lives in operational systems that were never designed to be read by anything else.

The four barriers that actually bind

Not the ones usually listed. These are the ones that stop projects.

1. Data readiness — the barrier behind most others

The pattern is consistent enough to be predictable. An organisation defines a promising use case, builds a proof of concept on a hand-curated dataset, gets a good result, and moves to production — where it encounters the real data. Four systems with overlapping customer records. No agreement on which is authoritative. Key fields populated inconsistently across a decade. Documentation that describes an earlier version of the schema.

The project does not fail loudly. It slows, absorbs effort, and quietly becomes a pilot again. This is the mechanism behind Gartner's cancellation forecast: nearly four in ten teams cite data cleaning as a factor in project outcomes, and a review that cannot answer "what is this returning and what could it break" ends the project.

This is why AI initiatives so often turn into data governance initiatives — and why the organisations that did governance work first move visibly faster afterwards. A model is a function of its inputs, and no amount of model quality compensates for inputs nobody can vouch for. We have written the practical version of this in data governance in Azerbaijan.

The uncomfortable implication: if your data is not ready, the fastest route to production AI is to stop working on AI for two quarters.

2. Deployment constraints

For banks and state institutions, sending data to a foreign AI API is generally not available, for the reasons set out in sovereign AI. This removes the easiest path — the one every international case study assumes — and replaces it with a procurement, an infrastructure decision and an operational capability that has to be built.

It is entirely solvable. Open-weight models are sufficient for the overwhelming majority of enterprise use cases, and on-premise inference is a well-understood engineering problem. But it converts a two-week integration into a two-quarter programme, and organisations that budgeted for the former stall.

The corollary is that this constraint should be surfaced in week one, not discovered in month four when the pilot is ready to scale and legal reviews it for the first time.

3. Language

Azerbaijani is a low-resource language for large language models. General-purpose models handle it, with quality below what they achieve in English or Russian, and the gap widens on domain-specific vocabulary — banking, legal and technical terminology in particular.

This has practical consequences that are frequently discovered late:

  • Retrieval over Azerbaijani documents needs embedding models that handle the language competently. Not all do, and the difference in retrieval quality is large.
  • Evaluation sets must be built in Azerbaijani. An evaluation harness in English tells you nothing about production performance on Azerbaijani inputs.
  • Mixed-language corpora are the norm, not the exception — a single document set will contain Azerbaijani, Russian and English, sometimes within one document. Retrieval architecture has to accommodate this deliberately.

None of this is a blocker. It is a design constraint that has to be handled explicitly, and the organisations that treat Azerbaijani as an afterthought ship systems that work in the demo and disappoint in the field.

4. Operating capability

The scarcest resource in this market is not people who can build an AI prototype. It is people who have run one in production for a year.

The skills that matter after launch — evaluation, monitoring for drift, incident response when a model behaves unexpectedly, managing a model upgrade without regressing behaviour — are different from the skills that produce a working demo, and they are much less common here.

The consequence is that systems get built and then decay, because nobody owns the ongoing question of whether they are still working. Plan for the operating function from the start, or plan to rebuild.

What reaches production

Consistent patterns across the deployments that succeed. All of them share the same shape: bounded scope, retrieval-grounded, measurable outcome, human in the loop for consequential decisions.

Internal knowledge retrieval. Employees asking questions against policy documents, procedures and regulations, and getting sourced answers. High volume, low risk, immediately measurable, and it works well in every language once retrieval is set up properly. This is the most reliable first production use case and it is what we recommend organisations start with.

Document extraction. Pulling structured fields out of contracts, invoices, applications and statements. Replaces genuinely expensive manual work, the accuracy is measurable against a ground-truth set, and errors are caught by existing downstream validation.

Customer service assistance for agents. Not replacing the agent — drafting the response, retrieving the relevant policy, summarising the case history. Adoption is high because it removes work rather than threatening the role, and the human remains accountable.

Compliance and risk document review. First-pass review of transaction narratives, KYC documentation or regulatory correspondence, with human confirmation. High-value because the manual baseline is expensive and slow.

Operational summarisation. Incident reports, meeting records, case files. Unglamorous, widely useful, low risk.

What consistently stalls

Fully autonomous customer-facing agents. Organisations aim here first because it is the most visible. It requires the highest reliability, carries the most reputational risk, and depends on the most complete data. It should be the third or fourth deployment, not the first.

Anything requiring a unified customer view that does not exist. Personalisation and next-best-action projects assume a single coherent customer record. If four systems disagree about who the customer is, the project is a data integration project wearing an AI label, and it should be scoped as one.

Predictive models without a decision attached. A churn model that produces scores nobody acts on is a research output. Define the operational response before building the model, or do not build it.

Point solutions bought per department. Three departments buy three AI tools, each with its own data connection, its own security review and its own vendor. Eighteen months later there is no shared governance, no reuse and three separate audit problems. This is where an orchestration layer earns its place — one control plane, one audit trail, one set of permissions. See what is AI orchestration.

A sequence that works

For an organisation with real ambition and a realistic view of where it is starting.

Phase 1 — Foundation (months 1–4). Data readiness assessment on the domain that matters most. Catalog and lineage for the systems in scope. Deployment posture decided and infrastructure procured. This phase produces no AI and is the reason the later phases work.

Phase 2 — First production use case (months 4–7). Internal knowledge retrieval, scoped to one department. Deliberately low-risk and high-volume. The objective is a working system in production with an evaluation harness, monitoring and an owner — the organisational muscle, not the use case itself.

Phase 3 — Extend (months 7–12). Two or three more use cases on the same platform. Document extraction and agent assistance are the usual candidates. Marginal cost per use case falls sharply here, which is the whole argument for building a platform rather than buying point solutions.

Phase 4 — Consequential decisions (year 2). Only now, with a proven evaluation and governance capability, do you put AI near decisions that affect customers. By this point you can demonstrate to a regulator how the system works, what it was tested against and how a specific output was produced.

Organisations that invert this — starting at phase 4 because it has the largest business case — are the ones still piloting two years later.

What to do in the first month

If you are starting from a standing position, three things are worth more than a strategy document:

  1. Establish where your data actually stands in the one domain you care most about. Not a survey — an inventory, with lineage for the systems that feed the decisions you want to automate.
  2. Settle the deployment question early, with legal and security in the room. Discovering the constraint in month four costs a quarter.
  3. Pick one narrow use case with a number attached to it. Hours saved, cases handled, time to resolution. The purpose of the first deployment is to prove the organisation can operate one, and that requires a measurement.

Our AI readiness assessment is structured around exactly those three, and produces a scoped deployment plan rather than a recommendation deck.

Key points

  • Globally, 88% of organisations use AI and 39% see EBIT impact; the gap is an execution gap, and in Azerbaijan its main cause is data readiness.
  • National policy has hardened: an AI Strategy for 2025–2028 and a 58-initiative digital development action plan for 2026–2028 approved by presidential decree.
  • Adoption here is bimodal. The gap between the leaders and everyone else is not budget or talent.
  • Deployment constraints for banks and state institutions rule out the easy path. Surface this in week one.
  • Azerbaijani is a low-resource language for LLMs — a design constraint to handle explicitly, not a detail to discover in testing.
  • The scarcest skill is operating an AI system after launch, not building one.
  • Start with internal knowledge retrieval. Customer-facing autonomy is the third or fourth project, never the first.

Yukon Labs builds HAVAA and deploys it inside the perimeter for organisations that cannot use foreign AI services. We are based in Baku and work in Azerbaijani, Russian and English.