AI automation: how European, Gulf and Turkish buyers differ

The same AI automation system, presented in Rotterdam, Riyadh and Istanbul, gets three different opening questions. This is not a difference in sophistication or appetite. It is a difference in what constrains the purchase.

This article sets out the three questions, the regulation and economics behind each, and what a proposal should say to answer them before they are asked.

Three markets, three opening questions

Market	First question	What is behind it	What settles it
Germany / Netherlands	"Where is the data processed, and in what role?"	GDPR liability chain, AI Act transparency duties	A written processing and transfer position, plus disclosure in the interface
UAE / Saudi Arabia	"Does the data stay in-country, and who can reach it?"	Local data protection law, localisation in publicly connected work	In-region deployment and a documented access model
Türkiye	"Will this talk to our existing ERP?"	A protected ERP investment; without integration the project is pointless	A named integration path and a working reference to the same system

The mistake is treating any of these as an objection to be handled. Each is the buyer telling you what has to be true for a purchase to be possible at all.

The European question: process, role and disclosure

Two things drive it. The first is that GDPR makes the buyer accountable for a processing chain they only partly control, so they need to know exactly who touches what. The second is newer: the EU AI Act’s transparency obligations became applicable on 2 August 2026 and are enforceable by national authorities. They cover systems that interact with people or generate content, whether or not the system is classified as high risk. Several high-risk obligations were deferred to later dates; transparency was not.

Alongside that, Article 14 requires human oversight for high-risk systems, specifying that the overseeing person must understand the system’s limitations, interpret its output, be able to override it and be able to stop it.

Adoption context matters here too. Eurostat reported that 20.0% of EU enterprises with ten or more employees used AI technologies in 2025, up from 13.5% the year before, with Denmark at 42.0%, Finland at 37.8% and Sweden at 35.0%. The most common single use was analysing written language, at 11.8%.

What that means for a proposal. European buyers are not asking whether you can be compliant. They are asking you to hand them the documentation they will need for their own file. Four lines: where the application and database run, whether request content leaves their infrastructure and under what contractual terms, what is logged and for how long, and where the AI disclosure appears in the interface.

The Gulf question: residency and access

Saudi Arabia’s personal data legislation has been enforceable since 2024, and the national data and AI authority published an AI adoption framework covering data governance, model accountability, transparency, human oversight and risk management. Personal data processed by organisations operating in the Kingdom is expected to be stored domestically unless specific transfer conditions are met. The UAE operates a layered structure, with the federal regime and separate financial-centre frameworks running in parallel.

What that means for a proposal. Deployment region has to be a stated fact, not a capability. So does the access model: who at the supplier can reach production data, under what circumstances, with what logging, and how that access is revoked. In publicly connected work this is frequently a qualification criterion rather than a preference.

The common error from suppliers is answering the residency question by proposing a self-hosted model. These are separate decisions. Application and database residency is usually simple. Whether the language model runs externally is a distinct trade-off between answer quality and processing scope, and merging the two makes projects more expensive than the requirement demands.

The Turkish question: integration first

Turkish mid-market buyers have almost always made a substantial ERP investment and are not replacing it. A system that cannot exchange data with that ERP is not a cheaper option; it is not an option.

The adoption data explains the second half of the picture. Türkiye’s statistical institute reported that 7.5% of enterprises used any AI technology in 2025, split by size as 6.6% for firms with 10-49 employees, 9.6% for 50-249, and 24.1% for 250 and above. Among non-adopters, the stated reasons ranked lack of necessary expertise at 74.2%, high cost at 67.4% and legal uncertainty at 62.4%.

Read those three barriers together and something useful appears: the leading obstacle is not price. It is not knowing what to ask for. A proposal that names the process, the input, the output and the approval point addresses the actual barrier better than a discount does.

On the regulatory side, the Turkish data protection authority published guidance on generative AI in November 2025 and on agentic AI systems in March 2026, emphasising data minimisation, purpose limitation and human reviewability of automated decisions — converging with the European direction even where the instruments differ.

One system, three configurations

The engineering conclusion is that these differences belong in configuration, not in separate products. Five settings cover almost all of it.

Deployment region. Which cloud account, which region. A setting, decided per customer.

Model placement. Hosted provider API or a self-hosted open model. This is the one decision with a genuine quality trade-off, and it should be made explicitly with the reasoning recorded — particularly where personal data is involved, because it feeds directly into a transfer analysis.

Logging depth and retention. What is recorded about each request and how long it is kept. Audit-heavy markets want more; data minimisation wants less. Retaining the decision record while masking content after a retention period resolves most of the tension.

Interface disclosure. Whether and how users are told they are interacting with an AI system. Cheap to include from the start, awkward to retrofit.

Approval placement. Which steps require a person. Regulation is converging on the same answer everywhere, so build to the strictest requirement and relax it where you can — the reverse never works.

Building three code bases to serve three markets produces three maintenance burdens for one product. Configuration keeps it one product.

What the three markets actually share

Underneath the different opening questions, the same four things determine whether a project succeeds anywhere.

A named process. Not “AI for operations” but one process with a defined input and output.

Access to data. Where documents live, which systems expose an API, who grants access. This sets the timeline more than any technical factor.

An owner for exceptions. Every automation produces a queue of things it could not handle confidently. Without an owner, the queue grows and the system is abandoned — this is market-independent.

A person on irreversible steps. Payments, shipments, external commitments. Three regulatory regimes are converging on this requirement, and it is also just correct design.

Gartner’s forecast that over 40% of agentic AI projects will be cancelled by the end of 2027 cites escalating cost, unclear business value and inadequate risk controls. None of those is regional.

When these differences mean you should not build

When residency is required and the process needs a hosted model to work at all. If self-hosting drops answer quality below usable and the data cannot leave the country, the honest answer is to narrow the scope until it can be done locally, or not to do it.

When nobody in the buying organisation can answer the data questions. If neither IT nor legal can say where data may be processed, the project will stall at exactly the wrong moment — after the build has started.

When the integration target has no viable path. In the Turkish case especially, if the ERP exposes no API, no import format and no supported database access, the integration is not a line item; it is the project.

When the requirement is a compliance artefact rather than a working process. Systems commissioned to demonstrate AI adoption rather than to change a process are the ones that get cancelled, in every market.

Measure your own situation

Five questions. They apply wherever you operate, and the answers shape the proposal you should be asking for.

1. In which jurisdictions do the people whose data this touches sit? Not where your office is — where the data subjects are.
2. Can the data leave the country, and can it leave your infrastructure? Two separate questions with two separate answers.
3. Who in your organisation signs off the answer to question two? Name them now. This is the most common cause of mid-project delay.
4. What is the integration target, and what does it expose? API, import file, database, or nothing.
5. Which steps in the process are irreversible? List them. Those are where approvals go, and getting them right satisfies all three regulatory regimes at once.

Answer these before requesting proposals and you will get comparable quotes instead of five documents describing different projects.

Next step

Our approach to operational automation is on the AI process automation page, the organisations and regions we work with on who we build for, and the delivery bands on the pricing page. Data residency and processing roles are covered in more depth in GDPR and nearshore development, and oversight design in human-in-the-loop AI approval design. Send the five answers above through the quote form and we will scope against your constraints rather than around them.

Frequently asked questions

Why does the first question differ so much by market?

Because the binding constraint differs. In the EU the constraint is regulatory liability and documentation. In the Gulf it is data residency and, in publicly connected work, localisation. In Türkiye it is an existing ERP investment that must be preserved. None of these is a cultural preference; each is a real obligation or a sunk cost that shapes what can be bought.

Do we need one system per market or one system for all three?

One system, with the differences expressed as configuration rather than as separate code bases. Where the database runs, whether the model is hosted or self-hosted, what is logged and for how long, and which disclosures appear in the interface should all be settings. Building three variants creates three maintenance burdens for the same product.

What changed in EU regulation in 2026?

The AI Act's transparency obligations became applicable on 2 August 2026 and are enforceable by national authorities. They apply to systems that interact with users or generate content, regardless of whether the system is high risk. Some high-risk obligations were pushed to later dates; transparency was not among the deferrals.

Does data residency mean self-hosting the model?

Not automatically, and conflating the two makes projects more expensive than they need to be. Application and database residency is usually straightforward: run them in a region you choose. Whether the model runs externally is a separate decision with its own trade-off between answer quality and processing scope. Decide them independently and write both down.

Is adoption really that different across these markets?

The published figures differ substantially. Eurostat put EU enterprise AI use at 20.0% in 2025 with Denmark at 42.0%, while Türkiye's statistical institute reported 7.5% of enterprises using any AI technology in the same year. The more useful detail is why non-adopters said no, which points at expertise and legal uncertainty rather than technology.

How should this show up in a proposal?

As four explicit lines: where the application and data run, whether request content leaves your infrastructure and under what contractual terms, what is logged and for how long, and which disclosures the interface shows. A proposal that leaves these to a later conversation will be re-priced later.

Related guides

• ERP customer portal vs dealer portal: which one your network needs
• AI workflow automation vs RPA: choosing the right layer
• Custom ERP vs SAP: what actually decides it for a mid-size manufacturer

Service page: Package vs custom