The Article 25(3) Information Request Framework

Article 25(3) gives the provider of a high risk ai system a statutory right to request from the gpai model provider the information necessary to ensure the high-risk system's compliance with the AI Act. This is not a courtesy or a commercial negotiation point; it is a legal entitlement embedded in the regulation. The AI System Assessor exercises this right through a structured information request that covers six defined categories, each mapped to specific modules of the AI System Description Profile.

The structured request must be submitted in writing, specifying the legal basis under Article 25(3), the information categories required, the intended use of the information, and the downstream system's risk classification. Each request is documented in the GPAI disclosure register with the date, content, and recipient, creating an auditable trail from the moment the information need is identified through to the provider's response. GPAI Integration and Downstream Provider Obligations

The structured information request covers six categories, each feeding specific AISDP modules and each carrying characteristic disclosure patterns from GPAI providers. These categories provide the downstream provider with the information architecture needed to assess whether the GPAI model component meets the requirements the AI Act places on the overall high-risk system.

Training data governance covers sources, collection methodology, geographic and demographic coverage, temporal scope, known biases, copyright compliance measures, and opt-out mechanisms. This feeds AISDP Module 4 (Data Governance). GPAI providers typically disclose high-level categories but withhold granular source lists. Copyright compliance statements are generally provided, though representativeness data at subgroup level is rarely available.

Model architecture and behaviour covers architecture family, parameter count, training methodology, alignment approach, known failure modes, output constraints, and behavioural limitations. This feeds AISDP Module 3 (Architecture). Providers usually disclose architecture family and parameter count. Alignment methodology is described at a high level, but detailed failure mode analysis is rarely shared.

Safety and security evaluation covers red-teaming methodology and results, adversarial testing, vulnerability disclosure policy, incident response capabilities, and security certifications. This feeds AISDP Module 9 (Cybersecurity). Disclosure varies widely: some providers publish model cards and safety reports, others share results under NDA, and some refuse substantive disclosure entirely. Risk Management System Design

Versioning and change policy covers version scheme, deprecation policy, change notification commitments, scope of within-version updates, and rollback availability. This feeds AISDP Module 10 (Version Control). This information is usually available in service documentation, though a critical gap remains: many providers apply silent updates within a version identifier without notification.

Data handling practices covers inference data retention, use of inference data for training, data processing agreements, sub-processor disclosure, and data residency. This feeds AISDP Modules 4 and 9. Major providers now publish DPAs and sub-processor lists, though inference data use for training remains a contested area.

Systemic risk documentation covers model evaluation results, risk assessments, and serious incident reports for models classified under Article 51. This feeds AISDP Module 6 (Risk Management). Article 55 obligations took effect in August 2025, meaning the corpus of available systemic risk documentation is still developing.

The downstream provider follows a graduated four-level escalation when a GPAI provider refuses or restricts the information disclosure that Article 25(3) entitles. Providers typically refuse for three reasons: commercial confidentiality around training data and model architecture, intellectual property protection where safety evaluation results may reveal vulnerabilities, and operational scalability where bespoke disclosures to every integrator are commercially impractical.

Level 1: Negotiate. The AI System Assessor requests the information through the GPAI provider's enterprise or partnership channel. Many providers maintain dedicated compliance teams that can provide information under NDA that is not available through standard API documentation. The Assessor documents the negotiation, including what was requested, what was offered, and what was refused.

Level 2: Escalate to the AI Office. Where the GPAI provider participates in the Code of Practice under Article 56, the downstream provider can refer the provider's non-disclosure to the AI Office. The Code of Practice defines specific transparency commitments, and a participating provider's refusal to honour those commitments is a matter for the AI Office's enforcement powers under Article 88.

Level 3: Implement compensating controls. Where disclosure cannot be obtained through negotiation or escalation, the downstream provider must fill the information gaps through its own testing, evaluation, and monitoring. The compensating control architecture addresses the four dimensions of information asymmetry: training data opacity, behavioural unpredictability, version instability, and security opacity.

The GPAI disclosure register is a structured register maintained by the AI System Assessor as a standing AISDP artefact. Each row records the Code of Practice commitment area, the information category requested, the disclosure received or its absence, the date of disclosure, the AISDP module it informs, the compensating control applied where the disclosure is absent or insufficient, and the residual risk assessment.

The register functions as both an audit trail and a change management trigger. When the GPAI provider updates its disclosures, the Assessor reviews the register and determines whether any AISDP modules require corresponding updates. When the GPAI provider releases a new model version, the Assessor re-evaluates whether the existing disclosures remain valid for the new version. This version-triggered review is essential because model updates can invalidate previous safety evaluations, behavioural characterisations, and fairness assessments.

The structured format pairs every information gap with a corresponding compensating control and residual risk assessment across each of the six information categories. When a gap appears in the training data governance row, for instance, the register links directly to the behavioural proxy testing and output distribution analysis documented in AISDP Module 4.

The compensating control architecture addresses four dimensions of information asymmetry that arise when GPAI provider disclosures are insufficient: training data opacity, behavioural unpredictability, version instability, and security opacity. Each dimension requires a distinct set of controls because the nature of the information gap differs.

Training data opacity arises because the downstream provider cannot inspect, audit, or reproduce the GPAI model's training data. Article 10's requirements for training data documentation, completeness, representativeness, and bias assessment cannot be satisfied at the pre-training level. The compensating approach operates at two layers.

Behavioural proxy testing requires the Technical SME to design a sentinel evaluation dataset that exercises the fairness, accuracy, and safety dimensions the training data disclosures do not address. The dataset includes balanced representation across the protected characteristic subgroups relevant to the downstream system's intended purpose, adversarial examples testing for known bias patterns in the domain such as gender bias in recruitment language, racial bias in credit-related terminology, and age bias in clinical descriptions. It also includes edge cases that probe the model's behaviour at the boundaries of its training distribution, and multilingual samples where the system serves non-English populations. The sentinel dataset is versioned, maintained, and re-evaluated whenever the GPAI model version changes. Evaluation results are documented in AISDP Module 4 alongside an explicit statement that the downstream provider could not conduct Article 10 data documentation at the pre-training level and has substituted behavioural proxy testing.

GPAI providers update their models on their own schedule, and these updates can change the model's behaviour in ways that affect the downstream system's compliance posture. Some providers apply changes within a version identifier without notification: a model accessed under the same identifier today may behave differently from the model accessed three months ago.

Three controls address version instability. Version pinning, where the GPAI provider's API supports requesting a specific model checkpoint rather than the latest version, allows the Technical SME to pin the production system to a specific version. Version upgrades are then treated as system changes that trigger the governance pipeline gates and the change classification logic.

Sentinel monitoring maintains a continuous evaluation pipeline that tests the GPAI model's behaviour against the sentinel dataset on a defined schedule, daily for high-risk systems. If the evaluation detects a behavioural shift exceeding defined tolerances, whether output distribution shift, fairness metric change, or hallucination rate increase, an automated alert triggers investigation. The alert is documented in the PMM records (AISDP Module 12) and may trigger the substantial modification assessment.

Contractual notification requirements stipulate that the procurement contract should require the GPAI provider to notify the downstream provider before making changes that could affect the model's behaviour, with a minimum notice period of 30 days recommended for high-risk systems.

The downstream provider cannot audit the GPAI provider's security infrastructure, training pipeline security, or model integrity controls. Article 15's resilience requirements must be satisfied through the downstream system's own security architecture.

Prompt injection defence in depth requires multiple layers of protection. Input sanitisation validates and constrains user inputs before they reach the GPAI model. System prompt isolation separates the system prompt from user content using the provider's recommended separation mechanisms. Output validation verifies that the model's output conforms to expected format and content boundaries. Action gating, for agentic systems, requires explicit approval before the system acts on the model's output. These controls are documented in AISDP Module 9 with test evidence from the red-teaming programme.

Model integrity verification addresses the risk that the model has been tampered with or replaced. Where the GPAI model is accessed via API, the downstream provider cannot directly verify integrity. The sentinel monitoring pipeline provides a behavioural proxy: if the model's behaviour on the sentinel dataset changes unexpectedly, this may indicate an integrity issue as well as a version change. Where the GPAI model is deployed on-premises or in a private cloud, the Technical SME verifies model artefact integrity using cryptographic hashes at deployment time and periodically during operation. Both prompt injection controls and integrity verification measures are documented in AISDP Module 9 as evidence of the downstream system's compliance with Article 15's resilience requirements.