The EU AI Act: questions to ask if you build or buy AI for Europe.

“We’re not in the EU, so it doesn’t apply to us.” It is an understandable first reaction in Türkiye and the Gulf, and it may be right for some uses and wrong for others. The EU AI Act sorts AI uses by risk, gives different duties to the companies that provide AI systems and the companies that use them, and is written to reach beyond the EU’s borders in some cases.

You don’t need to become an expert in the Act. You need a short list of EU AI Act compliance questions to settle with counsel, and an honest inventory of your AI uses to settle them with. This note offers the questions, not conclusions.

Does the Act concern a company based outside the EU?

It can. The Act is written to reach some organizations established outside the EU, for example when they place an AI system on the EU market, or when the output of their system is used in the EU. Whether that describes you is counsel’s call, use by use. Ask the question if any of these is true:

• You sell software or products with AI features to customers in the EU.
• People in the EU interact with your AI systems, for example a chat assistant on your website.
• You have subsidiaries, branches or employees in the EU that use AI systems.
• Your EU business customers ask about the Act in procurement questionnaires or contracts.

The last point matters even where the Act may not apply directly, because European customers may pass their own expectations down the supply chain.

Are you a provider, a deployer or both?

The Act gives different duties to different roles, and these are the two you will meet most often. In broad terms, a provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name. A deployer uses an AI system under its authority in a professional capacity. One company can be a deployer of a bought tool and a provider of a system it built.

Questions for counsel, for each use:

• Did we build it, buy it, or build it on someone else’s model?
• Do we offer it to others under our own name or brand?
• Have we changed a bought system substantially, or used it for a purpose its maker didn’t intend? Changes like these can affect which role you hold.
• What does the vendor say about its own role, and what documentation will it give us?

Which risk category does each use case fall into?

The Act sorts uses into tiers: a small set of prohibited practices; high-risk uses, which carry the heaviest duties; uses with transparency duties; and everything else, where the Act adds little that is specific but other laws still apply. High-risk areas include, for example, some uses in hiring and managing workers, in education, and in decisions about access to credit or essential services. Which tier a use falls into is for counsel to decide.

The risk category follows the use, not the technology.

The same model can draft internal meeting notes in one workflow and screen job applicants in another, and the two uses can land in very different tiers. So classify uses, not tools, and ask:

• What does this use decide or influence, and about whom?
• Does it touch employment, education, credit, essential services or safety?
• Would a planned change, such as moving from drafting to deciding, move it to another tier?

What do users need to be told?

Transparency is one of the Act’s stable ideas: people should know when they are dealing with an AI system rather than a person, unless it is obvious, and some AI-generated or manipulated content should be identifiable as such. What applies to your uses is for counsel; the practical questions are yours:

• Where do people interact with AI directly: chat, voice, email replies?
• If it isn’t obvious, what does the label say, where does it appear, and in which languages?
• Do you publish AI-generated images, audio, video or text, and how is it marked?
• Do your staff know what to say when a customer asks, “Am I talking to a person?”

Data protection notices may overlap; see our KVKK and GDPR questions.

Which existing practices already help?

Good engineering practice produces much of what counsel will ask about. None of it amounts to compliance on its own, but it gives you evidence instead of assurances:

• An inventory of AI systems, with owners, purposes and users.
• Evaluation sets that show how quality was tested, on which cases, and how often it is re-tested.
• Approval points that show where a person oversees or decides, with the evidence in view.
• Audit trails that record inputs, sources, versions, outputs and approvals; our note on what an audit trail should record has the field list.
• Data-flow maps, runbooks and incident records that show how data is governed and what happens when something goes wrong.

These are the same controls we build into systems as part of our guardrails.

What should you prepare with counsel?

Take counsel a short pack rather than a question as broad as “are we compliant?”:

1. The inventory: every AI use, what it does, who uses it, who is affected, and where its output is used, including in the EU.
2. Your role per use: built, bought, built on a model, rebranded or modified.
3. A proposed category per use, with your reasoning, for counsel to confirm or correct.
4. User-facing disclosures: the current wording and where it appears.
5. Oversight and documentation: approval points, evaluation results, logs and vendor documents.
6. An owner who follows changes to the Act, its guidance and its timing through counsel, and updates the inventory when a use changes.

In an illustrative case, an online retailer based in Türkiye ships to several EU countries and runs a customer chat assistant, bought from a vendor and configured with its own policies and brand. With counsel, it works through the questions. Does the Act reach it, given that EU customers use the assistant? Is it a deployer of the vendor’s system, or do its branding and configuration change that? Which tier does a customer-service assistant fall into, and would that change if it began deciding refunds? What must the chat window say, and in which languages? The retailer brings the inventory entry, the vendor contract, the disclosure text, the approval rule for refunds and a sample of logs. The conclusions are counsel’s to draw, and this note draws none.

Inventory first, then counsel

Start the inventory, one line per AI use, and book the first conversation with counsel once it exists. The rules and their interpretation keep developing, so a note like this can’t tell you the current status; counsel and official sources can. Building the inventory, the approval points and the logs is engineering and operations work rather than legal work, and it is the part we help with, for example as part of AI strategy and discovery.

This note is general information, not legal advice.

Sources

1. Regulation (EU) 2024/1689 (Artificial Intelligence Act), official text EUR-Lex eur-lex.europa.eu/eli/reg/2024/1689/oj