Article 10 of the AI Act, for teams that only call a model API

What Article 10 actually regulates

Every few weeks a product team asks me whether the AI Act requires them to keep prompts in the EU. The question usually arrives with Article 10 attached, because someone read the heading "Data and data governance" and assumed it was a residency rule. It is not. Article 10 is a quality rule for the data used to build and test high-risk AI systems, and it says almost nothing about where that data sits. It does reach LLM applications in ways most teams have not mapped, so it is worth reading slowly.

The article sits in Chapter III, Section 2, among the requirements for high-risk AI systems. It applies only to systems that are high-risk under Article 6: safety components of products covered by the legislation in Annex I, and the use cases listed in Annex III, such as screening job applicants, assessing the creditworthiness of individuals, or pricing life and health insurance. A support assistant that answers questions about delivery times is out of scope. The same model, wired into a workflow that ranks loan applicants, is in.

Paragraph 1 requires systems that use techniques involving the training of AI models to be developed on training, validation and testing data sets that meet the quality criteria that follow. Paragraph 2 lists the governance practices those data sets need: documented design choices, collection processes and data origin (for personal data, the original purpose of collection), preparation steps such as labelling and cleaning, assumptions about what the data measures, an assessment of suitability, an examination of possible biases with measures to mitigate them, and the identification of data gaps. Paragraph 3 asks for data sets that are relevant, sufficiently representative and, to the best extent possible, free of errors and complete. Paragraph 4 asks them to reflect the geographical, contextual, behavioural or functional setting in which the system will be used.

Who the provider is when the model belongs to someone else

Article 10 binds the provider of the high-risk AI system, through Article 16. The provider is whoever develops the system, or has it developed, and places it on the market or puts it into service under its own name, including for its own use. When a bank's platform team wires a hosted model into a credit decision workflow and runs it internally, the bank is the provider of that high-risk system. The company that trained the model is a provider too, but of a general-purpose AI model, with separate duties under Article 53 that have applied since 2 August 2025: technical documentation, information for downstream providers, a copyright policy and a public summary of training content.

Article 25 closes the obvious gap. A deployer that changes the intended purpose of a general-purpose AI system so that it becomes high-risk is treated as the provider of the resulting system. So the answer to "is this the vendor's problem?" is usually no. The vendor owes you documentation about its model. You owe the market surveillance authority evidence about your system, and Article 10 is part of that evidence.

That also settles the worry I hear most. You cannot inspect a frontier model's pre-training corpus, and Article 10 does not ask you to. It attaches to the data sets used to develop your system.

Article 10(6): when your system trains nothing

Paragraph 6 is the most important sentence in the article for application teams. For high-risk systems not developed using techniques that involve training AI models, the governance and quality requirements apply only to the testing data sets. Most counsel we work with read a prompt and retrieval system that calls someone else's model as falling here, because the system itself trains nothing. Fine-tuning is different. Supervised fine-tuning and adapter methods such as LoRA are training, and they bring training and validation data back into scope.

Narrowing the duty to testing data does not make it light. It means the evaluation set carries the whole weight of the quality and bias analysis. For an LLM application that means a documented origin, an explainable labelling method, coverage of the languages and populations the system will serve, and a written bias examination. A credit assistant for German and Austrian customers that was tested only on English examples fails paragraph 4 on its face, whatever its scores.

• Record where every test case came from and, for personal data, the purpose it was originally collected for.
• Version the evaluation set and keep every version, because your Annex IV documentation points at a specific one.
• Report results per language and per affected group, not only in aggregate.

Where Article 10 meets residency, and where it does not

The word "geographical" in paragraph 4 is about representativeness. It asks whether your data reflects the place where the system will be used, not where the data is stored or processed. Nothing in Article 10 requires EU hosting, and anyone selling AI Act compliance as a localisation requirement is selling the wrong thing.

Residency enters through GDPR, and Article 10 makes that problem bigger, not smaller. A good test set is built from real cases, which means personal data, and every evaluation run sends that data to a model endpoint. That is processing. If the endpoint sits outside the EEA without a transfer basis, it is an unlawful transfer under Chapter V, whether it happened in production or in a notebook. We regularly find teams whose production traffic is carefully pinned to Frankfurt while their evaluation harness calls the provider's default endpoint with an engineer's personal API key.

Bias work raises the stakes. The Digital Omnibus deleted Article 10(5) and moved the permission to process special category data for bias detection and correction into a new Article 4a. Its conditions include pseudonymisation, strict and documented access controls, deletion once the bias is corrected, and a requirement that the data is not transmitted, transferred or otherwise accessed by other parties. Read strictly, that sits uneasily with sending health or ethnicity data to a third-party API for a bias study. Some DPOs will accept an in-region processor bound by Article 28 terms; others will want that work on a self-hosted model. It is a question for your counsel, and one to ask before the study starts.

Run evaluations through the same route as production

The fix is unglamorous. Point the evaluation harness at the same regional base URL and policy pack as production, and keep the receipt for every test case. Each receipt records the resolved endpoint, the provider region and the exact model id, which turns "we tested this model in the EU" into a claim an assessor can check.

import json
from openai import OpenAI

client = OpenAI(
    base_url="https://eu.yttsecunet.com/v1",
    api_key="jr_live_...",
    default_headers={
        "X-YTT-Policy": "eu-ai-act-high-risk",
        "X-YTT-Tenant": "kreditpruefung-eval",
    },
)

MODEL = "mistral-large-2411"  # dated version, as recorded in the Annex IV file

with open("evalset-v7.jsonl") as cases, open("evalrun-v7.jsonl", "w") as out:
    for line in cases:
        case = json.loads(line)
        raw = client.chat.completions.with_raw_response.create(
            model=MODEL,
            messages=case["messages"],
            temperature=0,
        )
        completion = raw.parse()
        out.write(json.dumps({
            "case_id": case["id"],
            "group": case["group"],
            "output": completion.choices[0].message.content,
            "receipt": raw.headers.get("X-YTT-Proof-Signature"),
        }) + "\n")

Pin the model, or your testing evidence expires

If a provider updates the model behind an alias, your test results describe a different system from the one in production. Our eu-ai-act-high-risk pack denies any model that is not on the approved list recorded for the system in your AI inventory, so a silent upgrade becomes a refused request and a change ticket rather than a hole in your Annex IV file. When a provider retires a version, re-run the evaluation set against its successor before switching, and let your quality management process decide whether the change is a substantial modification.

An approved entry names a model version and the endpoints allowed to serve it, so one review covers both quality and location.

The timeline after the Digital Omnibus

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July. It moves the Chapter III requirements, Article 10 included, to 2 December 2027 for Annex III systems and to 2 August 2028 for high-risk systems embedded in products under Annex I. Article 4a is not deferred and applies already.

The penalty tier for breaching high-risk requirements is Article 99(4): up to EUR 15 million or 3% of worldwide annual turnover. The EUR 35 million or 7% tier in Article 99(3) is reserved for prohibited practices, and vendor material often confuses the two. Sixteen months is enough time to build an evaluation set properly, document its origin and run the bias analysis. It is not enough if you start in autumn 2027, because good test data comes from production traffic you have not yet collected.