What do GPAI obligations mean for AI buyers?

The EU AI Act has changed what an AI buyer can reasonably demand from a model vendor. A provider that places a new general-purpose AI model on the Union market can no longer answer serious diligence questions with a polished model card and a promise that its lawyers have reviewed everything. Since 2 August 2025, Article 53 duties apply to those new models. Since 2 August 2026, the Commission can enforce them.

That does not mean every useful document sits on a public web page. The Act creates three evidence layers: a public summary of training content, documentation for companies integrating the model, and a deeper technical file for the AI Office and national authorities. Buyers who blur those layers either reject a decent vendor for not publishing confidential material or accept a weak vendor because it posted one attractive PDF.

I buy models as dependencies, not as impressive demos. The selection question is whether the provider can supply evidence that matches your intended use, keep it current, and tell you when the evidence changes. The new rules give buyers a better starting point, but procurement still has to do the hard comparison. This is practical procurement guidance, not a substitute for legal advice on your specific role or use case.

Article 53 separates public evidence from buyer evidence

Article 53 requires a GPAI model provider to create several different records, and only one of them is expressly a public publication. The distinction matters because each record answers a different procurement question.

The public item is a sufficiently detailed summary of the content used to train the model, prepared with the AI Office template. It helps rightsholders and the market see broad sources and processing choices. A provider must also maintain a copyright policy, but Article 53 says to put that policy in place; it does not turn the entire internal policy into a mandatory public report.

The downstream dossier is more useful to a buyer building an AI system. Annex XII calls for information on intended tasks, acceptable use policies, release and distribution, architecture and parameter count, input and output formats, the licence, integration requirements, and relevant training, testing, and validation information. The provider must make this documentation available to providers that intend to integrate the model. It may sit behind a customer portal or a confidentiality agreement because the Act also protects intellectual property, confidential business information, and trade secrets.

The authority file goes deeper. Annex XI covers development, training and testing, evaluation results, data characteristics, compute, energy consumption, and other technical details. The provider keeps it current and supplies it to the AI Office or competent authorities on request. A buyer has no automatic right to receive that whole file.

Ask the vendor to label every artifact by legal function: public training summary, downstream documentation, authority documentation, copyright policy, or systemic risk material. If the sales team calls all of them a "model card," require a document owner to separate them. One vague file cannot satisfy five different evidence needs.

The training summary is a map, not a dataset inventory

A compliant public training summary should show the main categories and origins of training content, not disclose every individual work or row. Buyers should use it to find exposure and gaps, not pretend it proves that every training item was lawfully used.

The Commission's mandatory template has three main parts. General information identifies the provider, model, modalities, broad size ranges, and general characteristics. The source section covers public and private datasets, scraped online material, user data, and synthetic data. The processing section addresses matters relevant to legitimate interests, including copyright and the removal of illegal content. The template also asks whether interactions with the provider's services and products contributed user data to training, without requiring personal information about users.

That structure supports concrete comparisons. If one provider names major web crawls and data collections while another writes "public internet data," the first gives you a better basis for diligence. If a summary identifies user interactions as a source, your privacy review has a clear branch to follow. If a provider says it used synthetic data, ask how it checked for contamination, model collapse, and inherited restrictions. The summary itself will not settle those questions.

Do not award points for page count. Award points for source specificity, model and version coverage, stated modalities, processing explanations, and explicit gaps. For a model placed on the market before 2 August 2025, the Commission allows the provider to explain information it cannot retrieve despite best efforts or without disproportionate burden. A candid gap with a reason is more useful than a broad claim that conceals the gap.

The summary must be visible on the provider's official site and alongside the model on public distribution channels, and it must say which models or versions it covers. Save the document, its publication date, and the model version in your procurement record. A live page that silently changes is poor evidence unless you retain the version you actually assessed.

Downstream documentation should control the shortlist

The Annex XII dossier should decide whether a vendor reaches technical evaluation, because it connects the model's design and limits to your system. Public transparency can expose obvious concerns, but integration evidence tells your engineers whether the dependency can work safely in production.

Start with identity. Record the legal provider, exact model and version, release date, distribution method, licence, and the entity contracting with you. A product name alone is not enough. A cloud reseller, model host, fine tuner, and original developer may each control different evidence. Your contract must point to the party that can update the model, answer a regulatory request, and notify you of material changes.

Then test the claimed boundary. Intended tasks and acceptable use rules should match your workload. Input and output modalities, context limits, required tooling, infrastructure needs, and integration instructions should match the service you will actually deploy, not a flagship model shown in the vendor's general documentation. Evaluation results should cover a close use case and a relevant language. A benchmark on broad question answering says little about an agent that can execute payments or modify production systems.

Capabilities without limitations are marketing. Ask for known failure modes, evaluation criteria, test conditions, mitigations, and residual limits. When a provider refuses raw evaluation data, it can still explain the protocol, population, scoring rule, model version, tool permissions, and result range. If it cannot state those basics, you cannot reproduce or interpret the claim.

Finally, identify what changes without your approval. Providers update hosted models, safety layers, acceptable use terms, tools, and rate limits. The dossier must have an update date, and your vendor process needs a change notice that maps new information to your own tests. A current file at signature time is only a snapshot.

Copyright evidence needs an operating policy

The copyright duty is an operating requirement, not a promise that the model contains no protected expression. Article 53 requires a policy for compliance with Union copyright and related rights, especially identifying and respecting rights reservations under Article 4(3) of the Digital Single Market Copyright Directive with current technical means.

The wording matters. It does not demand a warranty that every source is copyright free, nor does it erase disputes about text and data mining. It does require a repeatable way to detect reservations and act on them. The Copyright chapter of the GPAI Code of Practice translates that duty into more practical commitments, such as a policy, crawler controls, measures around lawful access, and a channel for rightsholder complaints. The Code is voluntary, so signing it is evidence of a chosen compliance route, not the legal duty itself.

For vendor selection, ask who owns the policy, which training and collection pipelines it covers, how rights reservations enter collection filters, how often controls are tested, and how complaints affect future model versions. Ask whether contractors and dataset suppliers follow the same controls. A provider that buys a dataset does not outsource the procurement risk created by that dataset.

Keep copyright diligence separate from output protection. Training source controls concern how the model was built. Output filters, indemnity, similarity detection, and customer usage rules concern what happens when you use it. A strong answer in one column does not repair an empty answer in the other. Procurement teams often combine both under "IP protection" and lose the ability to see which risk the vendor actually addressed.

Treat refusal carefully. A provider may protect trade secrets and still describe governance, control points, complaint handling, and coverage. "We cannot share the data" does not answer a question about the process. If the vendor cannot show even process evidence under confidentiality, price the uncertainty into the decision or remove the model from sensitive use cases.

Systemic risk adds a separate safety file

Providers of GPAI models with systemic risk owe model evaluation, adversarial testing, systemic risk assessment and mitigation, serious incident reporting, and cybersecurity protection for the model and its infrastructure. Those duties sit on top of the ordinary Article 53 duties.

The AI Act presumes systemic risk when cumulative training compute exceeds 10^25 floating point operations. A provider that knows the model will cross that threshold must notify the Commission without delay and no later than two weeks. The Commission can also designate a model below the threshold when its capabilities or impact match the most advanced models. Compute is a trigger, not a complete safety score.

A buyer should ask whether the exact model has been notified or designated, whether the provider disputes the classification, and which safety and security framework covers it. The answer affects the evidence you should expect, but do not turn "not systemic" into "safe." A smaller model connected to customer records, source repositories, or payment tools can create severe risk inside your company even if it does not create Union level systemic risk.

For a model in the systemic category, request the portions of safety material the provider makes available to customers: evaluation scope, risk taxonomy, release gates, incident channels, security controls, and material limitations. The provider may reserve sensitive details that would make misuse easier. You still need enough information to connect its controls to your threat model and incident plan.

Ask one awkward operational question: if the AI Office receives a serious incident report about this model, when will affected customers learn enough to act? The Act creates a reporting line to authorities, not an automatic customer notification clause tailored to your outage window. Your contract must close that gap.

Open source changes exemptions, not the buyer's exposure

An open source release does not make the GPAI chapter disappear. Under Article 53, a qualifying free and open source provider may be exempt from the authority documentation, downstream documentation, and EU representative duties when the licence permits access, use, modification, and distribution, the release is not monetised, and weights, architecture, and usage information are public. The copyright policy and public training summary still apply. The exemption also disappears for a model with systemic risk.

This is where procurement labels cause trouble. "Open weights" is not the same as the Act's free and open source conditions. A licence may restrict commercial use, weights may be available without architecture information, or a paid service may sit around the release. Check the licence and distribution facts instead of accepting the label on a model catalogue.

Your company may also change roles. The Commission's guidelines say ordinary fine tuning does not automatically make the modifier a GPAI provider. They use more than one third of the original model's training compute as the indicative threshold for an exceptional, significant modification. When that happens, the modifier documents its modification and new training data rather than reconstructing the entire original development history. The guideline is not binding law, but it states the Commission's enforcement view.

Even below that threshold, you can still become the provider of an AI system built on the model and inherit other AI Act duties. The GPAI exemption answers what the model provider owes under this chapter. It does not decide whether your hiring, credit, safety, or public service application is high risk, nor what privacy, consumer, product, or sector rules apply.

Open source can improve inspectability and deployment control. It can also transfer patching, monitoring, security, and evaluation work to your team. Compare the total evidence and operating burden with the hosted option. A licence badge is not a control.

The model's market date determines today's evidence

Dates determine whether missing documentation is a breach, a transition issue, or simply the wrong request. Record when the exact model was first placed on the Union market before you score its evidence.

For GPAI models placed on the market from 2 August 2025, the provider obligations already apply. The Commission's enforcement powers, including fines, started on 2 August 2026. Providers of models placed on the market before 2 August 2025 have until 2 August 2027 to comply. That older-model transition does not justify a vendor refusing all diligence; it means you should distinguish current legal deadlines from your commercial requirements.

"Placed on the market" reaches beyond a paid API launch. The Commission's guidelines include APIs, downloads, cloud access, application integration, and certain internal uses essential to providing a product or service in the Union or affecting the rights of people there. Supply can be free of charge. A research or prototype model before market placement sits outside the GPAI definition, but calling a customer-facing preview a prototype does not settle the facts.

Model families make the date harder. A provider may release a base model, then a tuned version, a larger context version, and a hosted revision. Ask the provider to state which release constitutes the relevant market placement and which public summary covers each version. Do not infer that a 2026 service inherits a 2024 transition merely because the brand name stayed the same.

Build a timeline in the vendor file: original market date, assessed version release, training summary publication, downstream dossier update, Code signature status, and your last review. Each date needs a source or provider attestation. This small record stops teams from applying the 2027 deadline to every old-sounding model and from demanding enforcement evidence for a version that is not yet in scope.

Convert the duties into procurement gates

A useful GPAI review ends with pass, conditional pass, or fail against defined evidence. A large questionnaire with no decision rule only creates email. I use a compact record that product, engineering, security, privacy, procurement, and counsel can each annotate.

model_evidence:
  provider_legal_name: ""
  model_and_version: ""
  eu_market_date: "YYYY-MM-DD"
  public_training_summary:
    location_recorded: false
    version_coverage: ""
    source_specificity: "low|medium|high"
    declared_gaps: []
  downstream_dossier:
    annex_xii_mapping_received: false
    limitations_relevant_to_use: false
    evaluation_protocol_explained: false
  copyright:
    policy_owner_identified: false
    rights_reservation_process_explained: false
  systemic_risk:
    status: "yes|no|undetermined"
    customer_incident_channel: ""
  change_control:
    notice_period_days: 0
    reassessment_trigger: ""
  decision: "pass|conditional|fail"

Set the gates before the favorite model runs a successful demo. For a low consequence drafting assistant, you may accept broad training source disclosure and compensate with input restrictions and human review. For an agent that reads private repositories and executes tools, missing limitations, weak incident notice, or silent model substitution should block production. The legal category informs the gate; the business consequence sets its strictness.

Verify, do not merely collect. Confirm that the training summary names the assessed version. Compare acceptable use limits with the contract and your architecture. Run your own tests against the stated limitations. Check whether the entity offering indemnity is the entity with resources to honor it. Ask a technical owner to explain one evaluation result without the sales deck.

A Code of Practice signature can reduce evidence friction because the Commission and AI Board have assessed the Code as an adequate voluntary compliance tool. It is not a universal certification, and a nonsignatory can use alternative adequate means. Record which chapters the provider signed and what evidence shows adherence. "Code aligned" is not the same statement as signed and implemented.

Put evidence changes and failures into the contract

The contract should preserve the evidence on which you selected the model and force a review when that evidence changes. Regulatory compliance language alone will not tell you that the provider replaced the model behind a stable API name.

Attach or identify the exact model, version policy, downstream dossier, public training summary, acceptable use policy, and security material reviewed during diligence. Define a material change to include a new base model, changed training source categories, reduced evaluation coverage, a different systemic risk status, new tool permissions, or a limitation that affects your use. Set notice and termination rights that match the time your team needs to retest or migrate.

A workable clause starts with operational facts:

The Provider will maintain the documentation supplied for the Model and give the Customer written notice before any material change to the Model, its documented limitations, accepted input or output modalities, training content categories, or applicable use restrictions. If advance notice is not reasonably possible because of a security event or legal order, the Provider will notify the Customer without undue delay. The Provider will identify affected versions, expected customer impact, and available mitigation. The Customer may suspend the affected use while it assesses the change.

Counsel should adapt that language to the deal, governing law, bargaining position, and use case. Procurement should then test the clause against real events: a silent routing change, an urgent safety patch, a rightsholder claim, a regulator inquiry, and a serious model incident. If nobody can say who sends the notice and where it goes, the clause is decorative.

Do not demand impossible warranties. A provider cannot promise that a probabilistic model will never produce harmful or infringing output. It can promise facts about its process, documentation, notices, response times, version controls, and cooperation. Those are enforceable operating commitments, and they give your team something to monitor.

Monitor the provider after the buying decision

Vendor selection ends when the contract is signed, but model evidence starts aging that day. Assign one owner to watch provider releases, documentation revisions, acceptable use changes, incidents, and regulatory status for every model that reaches production. Without an owner, the carefully reviewed dossier becomes an archive while the service changes underneath it.

Set review triggers instead of relying only on an annual calendar. A new model version, a changed public training summary, a revised licence, a new prohibited use, a material evaluation result, a security notice, a rightsholder complaint that affects training sources, or a Commission decision about systemic risk should reopen the relevant parts of diligence. A quiet quarter may need no full review. One silent routing change may need an immediate regression run.

The provider should supply a stable way to identify the model that produced an output. An API name that always points to the latest version makes incident reconstruction hard. Ask for version identifiers in response metadata, release notes that map aliases to versions, and a period during which you can pin a tested version. If the service cannot expose a version, require another reproducible identifier and treat unannounced substitution as a material change.

Keep your record small enough that people update it. Store the evidence file beside the technical decision, contract owner, approved use cases, data classification, tests, and deployment inventory. Record a hash or retained copy of public documents when your normal document system supports it. The purpose is to answer a real incident question: which facts did the team rely on when it approved this model, and what changed afterward?

Reassessment must connect vendor evidence to your controls. A new limitation around a language your support team uses should trigger use-case tests. A change in training source categories should go to privacy and copyright reviewers. A reduced context limit may break redaction or human review logic even though it sounds like a performance detail. A provider incident involving model theft belongs with security, while an incident involving dangerous capability may also require product restrictions.

Decide who can pause the model. Product owners often have authority to ship but no clear authority to suspend an AI dependency when evidence fails. Give a named operational owner the ability to disable a feature, route to a tested fallback, or return the work to a person. Document the conditions, because a vague escalation chain will consume the hours your notice clause was meant to save.

Your fallback deserves the same scrutiny. Switching from one hosted model to another can change data location, retention, training terms, output behavior, and legal roles. Preapprove the fallback for a narrow use or state that it cannot handle live data until review. A fallback that nobody evaluated is another vendor decision hidden inside an incident plan.

Close the loop with the provider. Report failures with the model version, prompt conditions, tool permissions, observed output, and business consequence. Ask whether the event changes documented limitations or meets the provider's incident criteria. A serious supplier will answer in a form your engineers and risk owners can use. Repeated answers that never update documentation are evidence too, and they should affect renewal.

A clean evidence chain beats a compliance badge

AI buyers now have enough regulatory structure to reject hand waving, but not enough to outsource judgment to the EU AI Act. The public summary shows broad training content. The downstream dossier explains integration and limits. The copyright policy governs collection behavior. Systemic risk status adds safety and security duties. Your own use still decides how much evidence and control the purchase needs.

The recommendation I argue against is simple: buy only from a vendor that says it is "EU AI Act compliant." The phrase is popular because it compresses a hard review into one checkbox. It is weak procurement because the Act assigns different duties by role, model date, distribution method, risk category, and use. Ask which obligation, for which model version, supported by which artifact.

In a Team & AI Audit, I treat model choice and team process as one operating system: the cheapest model is expensive when nobody owns evidence, regression tests, or supplier changes. You do not need a large governance department. You need one named owner, a dated evidence record, a decision rule, and a contract that keeps the record alive.

Pick the model on evidence you can connect to a real deployment. If the provider cannot identify the exact version, explain its limits, map documents to its duties, and notify you when those facts change, the demo is irrelevant.