The Deployer Compliance Record

A deployer that does not trigger Article 25 provider status prepares a deployer compliance record documenting its own obligations in an eight-module structure. Each module maps a specific deployer responsibility to a discrete documentation area.

Module D1 covers system identification and provider reference: the system's name, version, and provider identity; the EU database registration reference; confirmation that the Declaration of Conformity has been received and reviewed; the date the system was put into service; and the authorised representative's contact details where the provider is established outside the EU.

Module D2 documents the intended purpose and deployment context: the deployer's specific use described in sufficient detail to confirm it falls within the provider's documented intended purpose; the operational domain; the categories of decisions supported; the geographic scope; the categories of affected persons; and any configurations or customisations with assessment of whether each remains within the provider's operating parameters.

Module D3 contains the full Fundamental Rights Impact Assessment under Article 27, following the FRIA methodology. This includes stakeholder consultation records, intersectional analysis, market surveillance authority notification and publication record for public authorities, and supplementary controls where the provider's mitigations are insufficient for the deployer's context.

Module D4 documents human oversight arrangements: the deployer's oversight structure mapped to the Instructions for Use, identity and qualifications of oversight personnel, training and certification records, override and escalation procedures, break-glass procedures, and records of break-glass tests.

Module D5 covers monitoring and incident response in comprehensive detail: monitoring activities aligned to the IFU including the specific metrics tracked, their thresholds, the review frequency for each metric, and the persons responsible for each review activity; log retention arrangements under Article 26(6) documenting how automatically generated logs are stored with a minimum retention period of six months, the storage and access controls applied, and the retention schedule and deletion procedures; the internal incident register tracking every event assessed against the serious incident criteria; the triage process for classifying events by severity; the escalation path to the provider for incident notification; procedures for reporting serious incidents under Article 73 including the tiered timelines; and all deployer-provider communications as a documented record.

Module D6 addresses data protection comprehensively: the Data Protection Impact Assessment where required under GDPR Article 35, the lawful basis for processing personal data through the AI system, the data processing agreement with the provider governing how data flows between the deployer and provider, and data subject rights procedures specific to AI-generated decisions. These procedures must address both the AI Act's Article 86 right to explanation, which requires transparency about the role of the AI system in decisions affecting individuals, and GDPR Article 22 rights regarding automated individual decision-making.

Module D7 applies to public authority deployers and Union institutions only, covering the Article 49(3) registration record and the FRIA summary and DPIA summary submitted to the EU database. This registration must be completed before the system is put into service. Module D8 documents compliance review and maintenance: a quarterly review schedule ensuring the compliance record remains current, a process for assessing whether context changes affect the risk profile documented in the FRIA, the Article 25 reassessment process that evaluates whether the deployer's relationship with the system has changed in ways that might trigger provider status, and a version history with change logs recording every material modification to the compliance record.

Technical controls are effective only if the people operating the system use them correctly. An AI system that passes its conformity assessment may still cause harm in production. Data distributions shift. User behaviour evolves. Deployer configurations drift. Operators develop automation bias. Business pressures incentivise ignoring warning signals. Operational oversight is the deployer's defence against these realities, providing the human and organisational dimension of deployer compliance that technical monitoring alone cannot address.

The deployer oversight pyramid organises this defence across five levels, each with distinct responsibilities, capabilities, and escalation authorities. Each level is staffed by a different function within the deploying organisation, ensuring that technical, operational, compliance, and strategic perspectives are all represented. The pyramid design ensures that every dimension of the system's behaviour is observed by someone with the capability and authority to act on what they observe. Each level escalates to the next when an issue exceeds its authority or expertise, with defined escalation triggers at every level ensuring that problems are routed correctly without delay.

The five levels progress from automated technical monitoring at Level 1, through human oversight of individual outputs at Level 2, business-level alignment monitoring at Level 3, compliance and regulatory assessment at Level 4, to strategic decision-making at Level 5. This layered approach ensures that a failure at any single level does not leave the system unmonitored: even if an operator fails to catch a problematic output at Level 2, the pattern may be detected through complaint analysis at Level 3 or through PMM metric breach at Level 4.

Level 1 technical monitoring is staffed by IT operations, platform engineers, or the team managing the system's infrastructure. Their function is continuous monitoring of system availability, response times, error rates, and log integrity. They require real-time visibility into operational metrics through dashboards, automated alerting for threshold breaches that triggers notification without requiring constant human observation, access to the logging infrastructure for investigation when alerts fire, and authority to escalate infrastructure issues to the provider without requiring prior internal approval. Escalation triggers include system unavailability or degraded response times, error rate spikes indicating potential infrastructure or model problems, log generation failures that create blind spots in the compliance record, and unexpected behaviour changes following a provider-initiated system update.

Level 2 AI system operators are the human operators who interact with the system's outputs in daily operation: recruiters using a screening tool, credit analysts reviewing model recommendations, clinicians reviewing diagnostic suggestions, case workers assessing eligibility determinations, and claims assessors reviewing fraud detection outputs. Their function is real-time human oversight of the system's outputs, exercising override, intervention, and escalation capabilities.

Operators require training and certification on the system's capabilities, limitations, and failure modes before they begin operating the system. They must understand the meaning of confidence indicators and explanation outputs. They must know when and how to override the system's recommendations, with the override capability always available and low-friction. They must have a clear escalation pathway for reporting concerns. They must be able to recognise patterns suggesting the system is behaving differently from its documented purpose.

The deployer compliance record is a living document, not a one-time compliance exercise. The quarterly review schedule in Module D8 ensures that the record remains current as the deployment context evolves, the provider updates the system, the regulatory landscape changes, and operational experience accumulates.

At each quarterly review, the deployer assesses whether any context changes affect the risk profile documented in the FRIA. A change in the population served, a modification to the deployer's operational procedures, an expansion to new geographic regions, or a shift in the decision context may all require FRIA review. The Article 25 reassessment evaluates whether the deployer's relationship with the system has changed in ways that might trigger provider status, particularly if the deployer has made configuration changes, extended the use beyond the documented intended purpose, or modified the system's integration in ways that could constitute a substantial modification.

The Article 25 reassessment is particularly important at each quarterly review. The deployer evaluates whether any of the three provider-escalation triggers have been activated: has the system been rebranded under the deployer's own commercial identity, has a substantial modification been made to the system, or is the system being used for a purpose outside the provider's documented intended purpose. Each assessment is documented with the reasoning and conclusion, creating an audit trail that demonstrates ongoing awareness of the provider-deployer boundary.

The version history in Module D8 records every material change to the compliance record with the date, the nature of the change, and the trigger that prompted it. This version trail demonstrates to a competent authority that the deployer maintains active compliance awareness rather than treating the compliance record as a static document filed at deployment and never revisited. A deployer who can produce a well-maintained, continuously updated compliance record with a clear version history is in a materially stronger position during a regulatory inspection than one who can only produce the initial document from deployment date.