Are we a provider or a deployer under the AI Act?

Most enterprise organizations integrating an existing foundation model into a downstream application are deployers, not providers. The provider is the entity that placed the model on the EU market with a view to use. Fine-tuning or wrapping a third-party model into your application generally keeps you on the deployer side, with edge cases when the fine-tune is substantial enough to constitute a new model.

Does Article 53 require us to publish our training data?

If you are a provider of a GPAI model, yes, at the summary level. If you are a deployer integrating someone else's model, no; the obligation runs to the model provider. Your deployer obligation is to use the model in accordance with the provider's instructions and to monitor it in operation.

What is the systemic-risk threshold?

The AI Act sets the threshold at 10^25 FLOPs of training compute, with the Commission authorized to designate additional models by capability criteria. Frontier models from major labs typically sit above this threshold. Open-weight models from medium-scale labs typically sit below it.

When do high-risk system obligations actually take effect?

The general high-risk obligations of Chapter III take effect August 2, 2026. The subset of high-risk systems regulated under existing harmonized product safety legislation (Article 6(1)) gets a longer transition until August 2, 2027.

How do Article 19 logs relate to Article 12?

Article 12 says high-risk AI systems must allow for automatic recording of events. Article 19 specifies what fields the automatically generated logs must contain and how long they must be retained. Article 12 is the mandate; Article 19 is the field-level specificat

EU AI Act Foundation Model Provider Obligations: A Reading of Articles 53-56 Before August 2

The August 2, 2026 enforcement date for the EU AI Act's General-Purpose AI provisions is roughly five weeks away. Articles 53 through 56 contain the bulk of the foundation model provider obligations. The article structure follows a pattern that summary press coverage often skips: Article 53 sets the baseline obligations for every GPAI model placed on the EU market, Article 54 carves out an exception for free and open-source models that meet specific conditions, Article 55 expands the obligations for systemic-risk models, and Article 56 establishes the codes-of-practice instrument that providers can sign for a compliance presumption.

I want to walk through each article at the level a deployer's compliance counsel actually needs, with the systemic-risk threshold and the downstream-deployer disclosure obligations broken out because those are where enterprise deployment programs intersect.

Article 53: Baseline provider obligations

Article 53 sets four baseline obligations on every GPAI model provider. The provider must draw up and keep up to date technical documentation of the model. The provider must draw up information for downstream providers, which the deployer can rely on to comply with its own obligations under the Act. The provider must establish a policy to respect Union law on copyright and related rights. The provider must publish a sufficiently detailed summary of the content used for training the model.

The technical documentation obligation runs to a defined set of elements: the model's general description, the development process, the architecture and number of parameters, the modalities and format of inputs and outputs, the licensing terms, the design specifications including the training approach used and the optimization rationale, and the testing and evaluation methods including the results.

The downstream-deployer information obligation matters most for enterprise integration. The provider has to supply information sufficient for a downstream deployer to understand the model's capabilities and limitations, the intended uses and the misuse cases the provider identified, the data the model was trained on at a summary level, the energy consumption and compute used in training where known, and the technical means available for the deployer to comply with its own AI Act obligations downstream.

Article 54: Open-source carve-out

Article 54 gives a narrow exemption from parts of Article 53 for free and open-source GPAI models. The exemption applies when the model is released under a free and open-source license that allows access, use, modification, and distribution, and when the parameters including weights, model architecture information, and model usage are publicly available.

Two conditions defeat the exemption. The model has systemic risk under Article 55, in which case the full obligations attach regardless of license. The model is monetized in a way that places it on the market under a commercial arrangement.

For enterprise deployers, the practical effect is that an open-weight model from a major lab can still be inside the full obligations if the lab's compute and capability profile places it in systemic-risk territory. The license alone does not exempt.

Article 55: Systemic-risk model obligations

Article 55 attaches additional obligations to general-purpose AI models classified as systemic-risk. The classification trigger is set in Article 51 at a 10^25 FLOPs training-compute threshold, with the Commission authorized to designate additional models by other criteria.

The additional obligations include performing model evaluation in accordance with standardized protocols and tools reflecting current technical practice, assessing and mitigating possible systemic risks at the Union level, tracking and reporting serious incidents and corrective measures, and ensuring an adequate level of cybersecurity protection for the model and its physical infrastructure.

The serious-incident reporting obligation creates a notification channel between provider and the AI Office. The provider must report incidents that meet the seriousness threshold to the AI Office and to the relevant national competent authorities. The reporting timeline is defined by implementing acts but is short by regulatory standards (the leading working text references days, not weeks).

Article 56: Codes of practice

Article 56 establishes the codes-of-practice instrument. The Commission, in coordination with the AI Office, encourages and facilitates the drawing up of codes of practice at Union level by providers of general-purpose AI models. Adherence to a Code creates a presumption of compliance with the corresponding Article 53 and 55 obligations.

Providers that do not adhere to a Code must demonstrate, by alternative means, compliance with the underlying article-level obligations. The Commission can review and approve alternative means under Article 56(7).

The first GPAI Code of Practice has gone through multiple drafting rounds with the AI Office and major model providers. Public signature lists for Code adherence are expected to publish around the August 2 enforcement date.

What flows to downstream deployers

A deployer integrating a GPAI model into a high-risk system inherits a set of obligations from Article 26, not directly from Articles 53 through 56. The provider-side disclosures Article 53 requires are designed to supply the deployer with the information needed to discharge Article 26 obligations.

The deployer-side obligations from Article 26 include: use the system in accordance with the provider's instructions for use; ensure the system is used by natural persons who have the necessary competence; ensure input data is relevant and sufficiently representative; monitor the system in operation; keep the logs Article 19 requires for at least six months; perform a fundamental-rights impact assessment under Article 27 where applicable.

Article 19 logging is the deployer's principal evidence stream for Article 26 compliance. The logs must include the period of use, the reference databases checked, the input data leading to a match, and the identity of natural persons involved in result verification. The deployer owns producing those records regardless of what the upstream provider supplies.

How the August 2 obligations are timed

Article 113 sets the staggered application of the AI Act. The prohibited-practice provisions of Chapter II applied from February 2, 2025. The GPAI provider obligations of Chapter V and the high-risk provisions of Chapter III apply from August 2, 2026. The full set of high-risk obligations under Article 6(1) for systems already on the market under harmonized product safety legislation applies from August 2, 2027.

Article 111 provides transition relief for GPAI models placed on the market before August 2, 2026. Providers of those models have until August 2, 2027 to bring them into compliance with Articles 53 through 56. Deployers integrating those models do not get the same transition relief; the Article 26 deployer obligations land on August 2, 2026 regardless of the upstream model's vintage.

DeepInspect

This is the gap DeepInspect closes for the deployer side. DeepInspect sits inline between authenticated users or agents and the LLMs they call, enforces identity-bound policy on every request and response, and writes a per-decision audit record that satisfies the Article 19 logging requirements. The record contains the timestamp, the principal identity, the data classification, the policy applied, and the decision outcome. The record commits before the response returns to the application, which closes the self-attestation gap a regulator's traceability questions surface.

For deployers that integrate multiple foundation models from different providers (a common pattern in regulated environments running OpenAI, Anthropic, and Bedrock side by side), the gateway produces a single audit format across all upstream models. The Article 19 logs the regulator inspects look the same whether the underlying model is signatory-Code-presumption or alternative-means-compliance.

If you are facing the August 2 deadline, let's talk.