Before You Use a European AI Model, Ask for These Records

Start with one ordinary procurement ticket: a US software company wants a hosted European text model to summarize customer-support calls. The model receives a transcript, extracts the issue and promised follow-up, then writes a summary into the company’s case-management system. A person can edit the result, but most summaries pass through untouched.

The purchasing team already asks about security, uptime, data retention and subprocessors. Its missing attachment is a model evidence request: a set of records tying the model’s identity, intended use, limitations, training information and later changes to the exact service being approved.

That attachment matters because the EU AI Act’s obligations for general-purpose AI models began applying in August 2025, with enforcement and treatment of models already on the market following the law’s phased schedule. A general-purpose AI model, or GPAI model, is one capable of performing a wide range of distinct tasks and being integrated into other systems.

The statutory duties generally sit first with the model provider. They do not automatically become a US customer’s duties merely because the provider is European. But a customer that deploys the model in Europe, puts an AI system on the European market, substantially modifies certain systems or uses model output in the EU may acquire its own obligations. The records also become necessary when a customer must explain a failure to an auditor, regulator or enterprise client.

This is compliance preparation, not legal advice. Scope depends on where the system and its outputs are used, the contractual chain, the model’s release conditions and whether the finished application falls into a regulated category.

Turn the legal text into a vendor request

Article 53 of the AI Act says a GPAI provider must “draw up and keep up-to-date the technical documentation of the model.” It also requires information and documentation for downstream providers that intend to integrate the model into an AI system. That material must support a “good understanding of the capabilities and limitations” of the model and enable downstream compliance.

Those requirements do not mean every customer receives the provider’s complete engineering archive. The Act separates documentation for authorities from information supplied to downstream providers, while protecting intellectual property and confidential business information. The European Commission’s supporting materials, including its GPAI guidance, documentation templates and voluntary Code of Practice, add operational detail without turning every suggested control into a statutory requirement.

For the support-summary workflow, procurement should ask the provider to return one dated package associated with the contract and the exact API or downloadable artifact. A public model card can sit inside that package, but a link alone is weak evidence: its content may change, and a family-level page may not identify the model that processed the calls.

Use five sections.

Model identity and control. Request the provider’s legal identity, its role in the supply chain, the commercial model name, the machine-readable model or endpoint identifier, release date or release period, supported input and output modalities, applicable license, distribution method and version policy. For downloaded weights, a checksum, which is a fingerprint calculated from a file, lets the customer prove which artifact it evaluated. For an API, request a stable version identifier or a contractual explanation of whether the endpoint can change without the customer selecting a new version.

This is where the support-summary ticket first becomes auditable. “Vendor’s language model” cannot be connected reliably to an evaluation. “Hosted model family, text endpoint, provider release identifier, evaluated under this configuration” can.

Intended use and integration boundaries. Ask for the tasks the provider designed and tested the model to perform, along with acceptable-use conditions, prohibited uses, required input formatting and any human-oversight assumptions. The provider should also identify whether safety filters, retrieval components or other services are part of the offered endpoint rather than the underlying model.

That distinction affects reproducibility. If the provider’s hosted service applies a separate moderation classifier before generation, a customer testing downloaded weights has not tested the same system. If support summaries are an expected use but automated decisions about refunds are prohibited, the product team needs a handoff that stops the summary from becoming an approval signal.

Capabilities and limitations. Request evaluation results relevant to the planned workflow, including the evaluation method, test conditions, known failure modes and the model configuration used. A generic claim that the model performs well on summarization does not address mixed-speaker transcripts, negation, account numbers or promises made late in a call.

The customer should state its own acceptance tests in the ticket and keep them separate from the provider’s evidence. For this workflow, the critical failure is not awkward prose. It is a summary that turns “we cannot issue a refund yet” into “refund approved,” or assigns one speaker’s statement to another. The fallback is human review before the summary triggers a workflow with financial or customer-rights consequences.

Training and data-rights evidence. Article 53 requires GPAI providers to maintain a policy for complying with EU copyright law and publish a “sufficiently detailed summary about the content used for training” using the EU AI Office’s template. Request the public summary, the applicable copyright-policy statement and the date or model release to which each applies.

Do not describe the public summary as a complete dataset manifest. It may identify major collections, data categories and collection methods without listing every item. It also does not prove that every training record was lawfully obtained. A US buyer that needs provenance for a sensitive use should ask separately about licensed sources, public-web collection, synthetic data, personal-data controls and exclusion mechanisms, then record where the provider declines to disclose details.

Open-weight distribution does not erase this issue. The AI Act contains qualified exemptions from parts of the GPAI documentation regime for some models released under free and open-source licenses, but the exemption is not universal and does not remove the copyright-policy and public training-summary duties. Models with systemic risk face additional rules.

Changes after approval. Require notice of changes to weights, architecture, safety controls, context handling, supported modalities, training or fine-tuning data, acceptable-use terms and material limitations. The contract should say which changes trigger a new identifier, how customers receive notice and whether an older version remains available long enough to test a migration.

A provider may resist advance notice for every backend adjustment. Narrow the request to changes that could alter output behavior, compliance assumptions or evaluation results. Version pinning, which keeps an application on a specified model release, may cost more or limit access to new capabilities; silent updates cost less operationally until an unexplained output change forces the company to reconstruct what happened.

Record what the US deployer changes

Provider evidence covers only the starting point. The support-summary system may add a system prompt, retrieval-augmented generation, which supplies selected company records to the model at request time, and a fine-tuned adapter trained on earlier summaries. It may also lower randomness, redact transcripts or route difficult calls to another model.

Keep those changes in a deployer-side record linked to the provider packet. Store the prompt and configuration version, retrieval sources, fine-tuning data description, evaluation set, approval record, deployment period and rollback target. Log which model version handled each production request when the provider makes that identifier available, while avoiding unnecessary retention of raw customer content.

These records answer different questions. The provider can explain the base model’s intended capabilities. The US company must explain why it connected that model to call transcripts, which instructions it added, what action followed the output and whether its modifications invalidated the original evaluation.

Fine-tuning or other modification can also change the legal analysis. Under the AI Act, an organization may be treated as a provider in some circumstances when it places a system on the market under its own name, changes the intended purpose of a qualifying system or makes a substantial modification. A retrieval layer or prompt edit is not automatically a substantial modification, but labeling every alteration “configuration” does not settle the issue.

Reject evidence that cannot be tied to production

Three responses should hold the procurement ticket open: an undated model card, documentation covering a family rather than the contracted release, and a policy page that the provider can replace without notice. Screenshots are better than memory, but exported files with retrieval dates, contractual attachments or records stored in a controlled repository are stronger.

Ask who owns updates. Procurement can collect the first packet, yet engineering usually sees endpoint deprecations first, legal receives amended terms, and risk teams own periodic review. Assign one system owner to reconcile those notices against the production inventory. Otherwise, each department can possess a correct fragment while the deployed system no longer matches the approved record.

The evidence request adds review time and may expose a commercial limit: some providers will not disclose architecture or data details beyond their public materials. Record the gap, decide whether contractual assurances and internal testing reduce it enough, and retain an alternative model or manual workflow where they do not. For the call-summary system, that means the ticket closes only when the approved endpoint, evaluation and rollback target point to the same model release.

Questions people ask

Does every

US company using a European AI model have EU AI Act duties?

No. A provider’s European location alone does not establish the customer’s obligations. Scope can depend on whether the company places or uses the resulting system in the EU, where its output is used, its role in the supply chain and whether it modifies or rebrands the system.

Is a model card enough evidence for procurement?

Usually not by itself. A useful record must identify the contracted model or endpoint, remain available after a web page changes, describe relevant limitations and connect to change notices. A dated model card can contribute to the packet if it covers the production release rather than only the broader model family.

Must a provider disclose its complete training dataset?

The AI Act calls for a sufficiently detailed public summary of training content, not a complete row-by-row dataset inventory. Buyers can request more specific provenance and rights information for their use case, but providers may limit disclosure to protect confidential information, intellectual property or security-sensitive details.

What should happen when the provider changes the model?

The system owner should compare the notice with the approved evidence packet, rerun tests affected by the change and either approve the new release or use the documented rollback. The production log should preserve the transition date and model identifier so later incidents can be tied to the version that generated the output.