A model provider’s AI Act obligations depend partly on when its model entered the EU market. Your obligations depend on what your organization does with the resulting system. Procurement needs both facts. A compliance statement that names one deadline without identifying the model, role and applicable transition leaves the review unfinished.
Which GPAI deadlines apply to your model?
General-purpose AI (GPAI) model obligations began applying on 2 August 2025, with Commission enforcement from 2 August 2026. The Commission’s timeline distinguishes those dates from the transition for models placed on the market before 2 August 2025, which have until 2 August 2027 under Article 111. Ask the provider which provision applies to the model you intend to use and keep the explanation with the assessment.
The AI Omnibus entered into force on 27 July 2026. The Commission gives 2 December 2027 for the Annex III high-risk rules and 2 August 2028 for high-risk AI embedded in Annex I products. These are system-level timelines; they do not replace the separate GPAI schedule. Commission announcement dated 27 July 2026.
Start with your role
Buying a model does not make you only a deployer
Under Article 3, a company developing a system and putting it on the market or into service under its own name can be its provider, even when it integrates another company’s model. A deployer uses an AI system under its authority. The same organization can have different roles in different activities. Classify the actual arrangement before assigning obligations. Article 3 definitions.
Article 53 distinguishes technical documentation for authorities from information supplied to downstream system providers. It also requires a copyright-compliance policy and a public training-content summary. It does not give every buyer an unrestricted right to the provider’s complete technical file, nor does it require the copyright policy itself to be publicly published. Article 53.
Follow the evidence dependency
Ask for the information needed for your use
Make the review specific
A model name is not a complete procurement record
Consider a vendor that says its assistant can use several model providers. Ask which model handles your workload, whether routing can change and how you will learn about a relevant change. Match the answer to the system you are buying. A public model card for one model does not describe every configuration behind the service.
Record the documentation available for the model, its limitations and any unresolved questions. Keep contractual requests separate from information the law requires a provider to supply to your role. This is part of the same due diligence as reviewing the current scope of an AI vendor’s SOC 2.
Maintain the decision
Check the model, the system and the supplier
A useful review assigns an owner to each unanswered question. It also says which changes require another assessment, rather than assuming the original approval covers every future model or deployment. Use the AI vendor risk assessment questions to connect this legal review with security, data use, and change management.
Establish the applicable requirements
Map the activity. Record whether your organization provides, deploys or otherwise makes the system available. Include its intended use and the basis for any high-risk classification.
Identify the exact model. Record the provider, version or release identifier, the relevant market-entry date and the transition the provider relies on. Ask how model changes affect that explanation.
Separate transparency duties. Article 111(4) extends the Article 50(2) deadline to 2 December 2026 only for relevant synthetic-content systems placed on the market before 2 August 2026. It is not a blanket delay of all AI-content disclosures. Article 111(4).
Check information access. Request the model information your role needs, plus the service’s retention, data-use and change-notice terms. Record unavailable evidence and its effect on the decision.
Keep supplier evidence usable
Check exceptions carefully. Qualifying open-source models can be exempt from Article 53(1)(a) and (b), unless they have systemic risk. Code-of-Practice participation is one compliance route; a non-signatory must demonstrate adequate alternatives. Non-signature alone does not prove noncompliance. Article 53(2) and (4).
Agree on change and incident notices. Define which changes matter to your deployment, when notice is required and who must review it. Avoid treating every routine release as the same level of risk.
Keep the penalty scope accurate. Article 101 provides a maximum of €15 million or 3% of preceding-year worldwide annual turnover, whichever is higher, for specified intentional or negligent infringements by GPAI providers. It is not an automatic fine imposed on every downstream buyer. Article 101.
Keep the approval traceable. Preserve the documents reviewed, their versions, the role analysis and unresolved conditions. Assign review dates based on the applicable obligations and the changes that could affect your use.
Treat the deadline as one fact in the assessment
The practical record is specific: the system’s use, your role, the model and provider, the applicable dates, the evidence reviewed and the remaining conditions for approval. Update it when a relevant fact changes. A supplier’s compliance statement helps only when you can connect it to the service you actually use.
Explore Zania’s third-party risk management →
Sources:
Share
