Input Data Control and What Deployers Are Answerable For

Article 26 requires deployers to ensure that input data used with high-risk systems is consistent with the data the system was designed to process. This requirement is often misunderstood. It does not mean deployers must validate every input; it means deployers must understand the system’s data requirements and ensure their operating environment meets them. The regulation places accountability on deployers to protect system integrity and to catch data quality problems that could cause misclassification or harm.

When a provider builds a high-risk system, they test it on a specific type of data. A credit scoring system might be trained on data from bank customers aged 18 to 75, with full employment histories, drawn from three European countries. A fraud detection system might be trained on transaction data from retail merchants with turnovers between 1 million and 50 million euros. These are not arbitrary choices; they define the data environment in which the model was tested and performs reliably. A deployer’s first accountability is to understand these boundaries and to ensure the data they feed the system stays within them.

In practice, this means deployers must implement data governance processes that filter, validate and monitor inputs. A bank deploying a credit scoring system must confirm that applicant records include all required fields, that employment history is complete enough to be useful, and that applicants fall within the tested demographic range. A fraud detection system deployed by an e-commerce platform must be fed transaction data from merchants whose business profiles match the training data. If a deployer feeds a system data that deviates significantly from the training data, the system’s output becomes unreliable and potentially harmful.

Data drift and monitoring

Over time, the data environment changes. A hiring assessment system trained on applicants from a single university may receive applications from new universities with different educational backgrounds. A loan assessment system may see a new customer segment as the bank expands geographically. These changes are called data drift. Article 26 implicitly requires deployers to monitor for data drift and to alert the vendor if the input data is no longer representative of the training data.

A deployer’s practical responsibility is to establish monitoring processes. Log the characteristics of inputs to the system. Track the distribution of key variables over time. Compare current input distributions to the training data distributions documented by the vendor. If drift is detected, escalate to the vendor and pause expansion of the system until the vendor confirms it remains reliable. Documentation of this monitoring activity is essential evidence of Article 26 compliance.

Garbage in, garbage out

Deployers are accountable for data quality. If you feed a high-risk system corrupted, incomplete or irrelevant data, you are responsible for the consequences. A healthcare provider that deploys a diagnostic system but fails to maintain the quality of the imaging data feeding it cannot claim the vendor is at fault if diagnoses are wrong. A public authority using a benefits assessment system but failing to verify that applicant income information is accurate cannot blame the system’s errors on the vendor.

This accountability applies particularly to sensitive personal data. If a deployer uses personal data for purposes or in ways the vendor did not anticipate, they may violate both the EU AI Act and the General Data Protection Regulation. For example, using a hiring assessment system trained on data from one geographic region to make decisions in a different region may expose unfair bias or different predictive relationships. The deployer must flag this to the vendor before proceeding.

Implementation safeguards

Deployers should implement data validation checks that run before inputs reach the system. Validation might check that required fields are present and contain plausible values, that numeric fields fall within expected ranges, that categorical variables match trained categories, and that no corrupted or null values are passed through. These technical checks prevent obviously bad data from skewing system outputs.

Data quality monitoring should also include statistical checks. Does the distribution of input variables today match the distribution from the training data? Has the percentage of missing values increased? Have new outliers appeared? These checks help deployers spot data drift and take action before it degrades system performance significantly.

Contract clarity

Deployers should ensure contracts with vendors specify data governance expectations. The vendor should confirm the data types, formats, quality standards and ranges the system expects. The deployer should confirm they will monitor data drift and notify the vendor of significant changes. Both parties should agree on what constitutes acceptable data quality and what degradation triggers vendor support or system suspension.

Contracts should also address data validation. Who is responsible for data quality checks? Is it the deployer’s responsibility to validate before feeding data to the system, or does the vendor expect raw data and handle validation? Clear allocation of this responsibility prevents disputes when data quality problems arise.