Art. 26.4 EU AI Act: input data quality for deployers

Updated: June 2026

Introduction: data quality as compliance obligation

Art. 26.4 obliges deployersdeployerAn organization using an AI system under its own authority in its activities. It carries the operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → to "take appropriate technical and organizational measures to ensure that data used to operate and monitor high-risk AI systemshigh-risk AI systemAn AI system that falls under the EU AI Act's strictest requirements, following Article 6. There are two routes in: a system that is a product or safety component covered by the Union harmonization legislation in Annex I and subject to third-party conformity assessment, or a system used in one of the areas listed in Annex III, such as employment, education, or access to essential services. Article 6(3) contains a filter: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, although a system that profiles natural persons is always high-risk. See EU AI Act, Annex III, conformity assessment.Open full entry → is relevant, sufficiently complete, and fit for purpose, and has appropriate levels of accuracy, robustnessrobustnessA system's ability to perform reliably under realistic conditions including noise, edge cases and adversarial pressure, the engineering core of the safety-and-reliability principle.Open full entry →, and security."

This obligation acknowledges a fundamental truth about AI systemsAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs (predictions, content, recommendations or decisions) that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry →: garbage in, garbage out. An AI system operating on degraded, biased, or incomplete input data will produce degraded, biased, or incomplete outputs, regardless of how well the model was built. The deployer bears legal responsibility for ensuring the data environment the AI operates in meets quality standards.

What data does Art. 26.4 cover?

Art. 26.4 applies to all data that enters the AI system during deployment:

• Operational input data: The data the system processes to produce outputs (e.g. applicant CVs in a screening system, transaction data in a fraud detection system)
• Reference data: Baseline data the system compares against (e.g. historical customer profiles)
• Feedback data: Data fed back to the system to improve or adjust performance during deployment
• Monitoring data: Data used to assess system performance

Training datatraining dataThe data used to fit an AI model's parameters; its quality, lawful rights and representativeness are central governance concerns.Open full entry → quality is primarily a providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → obligation under Art. 10. However, if a deployer fine-tunes or retrains a model, they assume provider-like obligations for that data.

The four quality dimensions

1. relevance

Input data must be relevant to the decision the AI system is making. Using demographic proxies that have no causal relationship to the predicted outcome is a relevance failure, and may also implicate GDPRGDPRRegulation (EU) 2016/679, the General Data Protection Regulation, the EU's law on the processing of personal data. It applies to AI wherever personal data enters training, inputs, outputs, or logs, and it operates alongside the EU AI Act rather than being replaced by it. See controller, processor, lawful basis, DPIA.Open full entry → data minimizationdata minimizationProcessing only data that is adequate, relevant and necessary. In ML it is implemented through pseudonymization, feature selection, synthetic data and privacy-enhancing techniques.Open full entry → requirements.

2. completeness

Data must be sufficiently complete for the system to make valid predictions. Many AI systems perform significantly worse on incomplete data, but do not always signal this clearly. Deployers must understand their system's minimum data requirements (documented in the provider's instructions) and have processes to handle incomplete data submissions.

3. accuracy and robustness

Data must accurately represent the real-world situation. Stale data, data entry errors, and data transformation errors all degrade accuracy. For high-riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → AI, deployers should have input validation processes that catch common data quality errors before they reach the model.

4. security

Input data must be protected against unauthorised access and manipulation. For high-risk AI systems, data poisoningdata poisoningAn attack that corrupts training data so the model learns attacker-chosen behavior; a core adversarial-ML threat to the data pipeline.Open full entry →, the deliberate injection of manipulated data to influence AI outputs, is a significant security threat that deployers must address in their information security framework.

Practical measures

• Automated data validation rules that flag incomplete or out-of-range inputs
• Regular data quality audits comparing input distributions against expected baselines
• Data quality SLAs in supplier contracts for data that comes from external sources
• DriftdriftThe gradual divergence of an AI system's behavior or performance from its validated state after deployment, without any code change or error. Drift is silent by nature: nothing breaks, accuracy simply decays until someone measures it. Causes are worth separating: a shift in the mix of incoming cases, a change in the source material, a change in surrounding systems, or an update to the underlying model by its provider. See model drift, agent drift.Open full entry → detection: monitoring whether input data distributions change over time in ways that may degrade model performance
• Documentation of data quality incidents and remediation actions

Compliance checklist

1. Have you documented the minimum data quality requirements for each high-risk AI system (from provider instructions)?
2. Is there an automated validation process for input data before it reaches the AI system?
3. Is there a process for handling incomplete or low-quality input data?
4. Are data quality incidents logged and tracked?
5. Is input data security addressed in your information security framework?
6. Do you monitor for data drift that could affect AI system performance?