Does Article 13 apply to general-purpose AI models, or only high-risk systems?

Article 13 applies to high-risk AI systems as defined in Article 6 and Annex III of the EU AI Act. General-purpose AI models have their own transparency obligations under Article 53, which require disclosure of training data summaries and copyright compliance. The two regimes are distinct. A general-purpose model integrated into a high-risk system inherits the high-risk obligations through the system that uses it. The deployer of the high-risk system carries the operational transparency obligation under Article 13, regardless of whether the underlying model is general-purpose or purpose-built.

Is a published model card sufficient to satisfy Article 13?

A model card alone fails the regulation. The text requires transparency sufficient to enable deployers to interpret outputs and exercise human oversight. A model card describes the model at the design level. It omits the per-request operational context that Article 14 oversight requires. The complete transparency stack includes the model documentation, the instructions for use, and the runtime telemetry that links specific outputs to the inputs, identity, classification, and policy that produced them.

What is the relationship between Article 13 and Article 50 transparency obligations?

Article 50 covers transparency obligations toward natural persons interacting with AI systems. It requires that users be informed they are interacting with an AI, that synthetic content be labeled, and that deepfakes be disclosed. Article 13 covers transparency toward deployers of high-risk systems. Article 50 applies more broadly across AI use cases. A deployer of a high-risk system that interacts with natural persons carries both obligations.

How do we measure compliance with the cybersecurity disclosure requirement?

Article 13 requires disclosure of accuracy, resilience, and cybersecurity properties measured against Article 15 metrics. The compliance posture turns on whether the provider has tested the system against the threats listed in Article 15 and disclosed the results in the instructions for use. For deployers, the operational obligation is to apply the cybersecurity controls described in the instructions and to record their application. An external enforcement proxy that produces per-request audit records is the architectural artifact that demonstrates the controls are in place.

What penalty applies to an Article 13 transparency failure?

Article 13 is a high-risk obligation. Failure to comply with the transparency requirement falls under the Article 99 tier of €15 million or 3% of global annual turnover, whichever is higher. The penalty applies to providers who fail to design and document transparency into the system, and to deployers who fail to act on the transparency provided. The supplying-misleading-information tier of €7.5 million o

EU AI Act Article 13: The Transparency Mandate for High-Risk Systems

Article 13 of the EU AI Act requires providers of high-risk AI systems to design and develop those systems so deployers can interpret outputs, understand the system's capabilities and limitations, and use the output appropriately. The obligation attaches at the design layer and follows the system through deployment. It takes effect August 2, 2026, the same date the rest of the high-risk regime activates. Most deployments today rely on generic model cards, which fail the regulation's requirement that transparency be sufficient for the deployer to exercise human oversight under Article 14.

I want to walk through what Article 13 actually requires, where the implementation gap sits, and what infrastructure produces transparency that satisfies a regulator.

Mandate

Article 13 obliges the provider of a high-risk system to ensure its operation is "sufficiently transparent to enable deployers to interpret a system's output and use it appropriately." That language places three concrete requirements on the design.

First, the system must be accompanied by instructions for use that include the identity and contact details of the provider, the characteristics of the system, the level of accuracy expected under normal use, the resilience properties of the system against errors and adversarial conditions, and any known or foreseeable circumstances that may lead to risks. Second, the instructions must describe the system's intended purpose and any reasonably foreseeable misuse. Third, the documentation must explain the human oversight measures expected of the deployer under Article 14, including the input data on which the system was tested.

The text is short. The implementation runs across model documentation, runtime telemetry, and per-request output annotations. A generic "model card" published once at release fails the operational requirement.

What transparency looks like in practice

A high-risk credit scoring system must disclose, in the deployer-facing documentation, the feature set it evaluates, the data on which it was trained and validated, the populations on which performance was tested, and the known failure modes. The transparency obligation extends to runtime: when the system produces an output that materially affects a natural person, the deployer must be able to explain which inputs drove the decision and what policy state was in effect at the moment.

A static model card does not produce that record. Per-request transparency requires structured telemetry at the inference call layer.

Cybersecurity and accuracy disclosure

Article 13 also requires disclosure of the accuracy and resilience properties of the system together with its cybersecurity profile, measured against the metrics defined in Article 15. A vague "the system is highly accurate" statement fails the requirement. The provider must publish specific accuracy figures, the test set used to measure them, and the conditions under which performance degrades.

Compliance gap

Most high-risk AI deployments today produce two artifacts that look like transparency and fail under audit.

The model card problem

A model card published at training time describes the model in the abstract. It lists the training data, the architecture, the known biases, and the intended use. It does not describe how the deployed system behaves with the specific prompts a deployer's users submit, what data classifications flow through it, or what policy state the deployer has configured. A regulator inspecting transparency under Article 13 is not asking about the model in the abstract. The regulator is asking about the system in operation.

The instructions-for-use gap

Deployers receive instructions for use that are written for the provider's marketing audience, not for a CISO who needs to assess risk. The instructions describe what the system can do. They omit the failure modes, the data conditions under which accuracy drops below the published figure, and the cybersecurity controls the deployer must layer on top to satisfy Article 15. Article 13 explicitly requires both.

Runtime explainability is missing

The transparency obligation extends to the point where the deployer must support the human oversight measures of Article 14. That means a person must be able to interpret a specific output, understand which inputs drove it, and decide whether to act. Most deployments produce a model response and a request ID. They do not produce structured records of which features were evaluated, which policy applied, and what classification the prompt carried.

What surviving an audit requires

An architecture that satisfies Article 13 produces, for every high-risk decision, a record that links the output to its inputs, the data classification that applied, the policy version in effect, and the operational context.

That record is per-request, structured, and independent of the application that generated the output. The provider's documentation describes the system's accuracy, intended purpose, and foreseeable misuse at the design level. The runtime infrastructure produces the operational evidence at the call level. The two together satisfy the regulation. Either one alone fails the test.

Article 13 connects to Article 14 and Article 12

Article 13 is the design-time half of the transparency obligation. Article 14 covers human oversight at runtime, and Article 12 covers record-keeping. The three operate together. Article 13 requires the system to be interpretable. Article 14 requires the deployer to act on that interpretability. Article 12 requires the action to be recorded. An architecture that satisfies one without the others fails the regime as a whole.

DeepInspect

This is the operational layer Article 13 requires above the model documentation. DeepInspect sits at the AI request boundary as an external enforcement and observability layer. Every request that passes through is annotated with the identity behind it, the data classification applied to the prompt, the policy version that governed the decision, and the outcome. The annotation is structural, not an opt-in logging mode.

For Article 13, that record is the runtime transparency the regulation requires. The deployer can produce, per request, the inputs, the policy, the classification, and the outcome. Combined with the provider's model documentation, the deployer holds the evidence needed to satisfy both the design-time and runtime halves of the transparency obligation.

If you are running AI in a high-risk category and your Article 13 readiness depends on a static model card, that readiness is incomplete.

Book a demo today.