Getting company data ready for AI: quality, drift, provenance and access

In 2025, 43.51% of EU enterprises that considered using artificial intelligence (AI) and did not use it gave the availability or quality of data as a reason [1]. For enterprises with 250 or more employees the share was 43.81% [1]. A report by the OECD (the Organisation for Economic Co-operation and Development), Boston Consulting Group and INSEAD says that the public bodies set up to help firms adopt digital technology "emphasise that a lack of data maturity is a fundamental barrier to implementing AI" [8].

This page explains what data readiness means for a large company: the risks that the US National Institute of Standards and Technology (NIST) names, the international standard on data quality, how to deal with drift and track where data came from, the EU rule on input data, and a readiness check to run before any build. It is part of the guide on enterprise AI adoption.

What the surveys show

Figure	Base	Source
43.51% named data availability or quality as a reason not to use AI	EU enterprises that considered AI, 2025	Eurostat [1]
43.81% named the same reason	Large EU enterprises that considered AI, 2025	Eurostat [1]
13.82% use AI and also perform data analytics	All EU enterprises with 10 or more employees, 2025	Eurostat [1]
5.1% named lack of required data as a reason not to plan AI	US firms not planning AI	Census Bureau [2]
6.8% changed data collection or data management to use AI	US firms that used AI	Census Bureau [2]
11.3% changed data collection or data management to use AI	US firms with 250 or more employees that used AI	Census Bureau [2]

The US figures come from the Census Bureau's AI supplement, collected 17 November 2025 to 8 February 2026. Because of Executive Order 14434, signed on 29 September 2026, the Census Bureau now calls AI "Super Intelligence" or "SI" in its files [3][4]. Its questions asked about "Artificial Intelligence (AI)" until the collection that began on 19 October 2026, after this supplement closed, so this page says AI [4].

In the EU, data is a reason for not using AI in more than four of every ten enterprises that considered it. In the US, only 5.1% of firms not planning AI blame data, while 61.6% say AI is not applicable to them [2]. The US question was asked only of firms that had no plan to use AI. Among large US firms that did use AI, 11.3% changed how they collect or manage data [2]. Reveneau's view is that a large company should expect data work in its first AI projects.

What can go wrong with data

The NIST AI Risk Management Framework names data as a risk specific to AI. It says: "The data used for building an AI system may not be a true or appropriate representation of the context or intended use of the AI system, and the ground truth may either not exist or not be available" [5]. Ground truth means the correct answer for each case, against which the AI's answer can be checked. Without it, the company has nothing to check the system's answers against.

Data also ages. NIST warns that "Datasets used to train AI systems may become detached from their original and intended context or may become stale or outdated relative to deployment context" [5]. As a result, "AI systems may require more frequent maintenance and triggers for conducting corrective maintenance due to data, model, or concept drift" [5]. A trigger here is a rule that starts a review, such as a fall in accuracy below a set level.

The framework asks a company to write down how it chose its data. Item MAP 2.3 covers "data collection and selection (e.g., availability, representativeness, suitability)" [5]. Representativeness means the data looks like the cases the system will meet in real use. Item MEASURE 2.1 asks that "Test sets, metrics, and details about the tools used during TEVV are documented" [5]. TEVV stands for test, evaluation, verification and validation, the work of checking that a system does what it should.

Data quality: the ISO/IEC 5259 series

The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) publish a series of standards on data quality for AI. ISO/IEC 5259-1:2024, published in July 2024, "is the foundational part of the ISO/IEC 5259 series, focusing on data quality for analytics and machine learning (ML)" [6]. Machine learning is the method by which AI systems learn patterns from data. The series continues in "ISO/IEC 5259-2 through ISO/IEC 5259-5, which offer more specific models, measures, and guidelines for various aspects of data quality management" [6].

In Reveneau's view, the series gives a large company shared terms for data quality, so a data team and a vendor can agree what level of quality a given use needs.

Drift: data that changes after release

The AI Data Security information sheet, published in May 2025 by the AI Security Center of the US National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI) and partners, defines the problem: "Data drift, or distribution shift, refers to changes in the underlying statistical properties of the input data to an operational AI system" [7]. The cases a system sees after a year can differ from those it saw when it was built, for example after new products, new customers, new rules or new forms.

The sheet lists the mitigations: "continuous monitoring, retraining (regularly incorporating the latest data into the models), data cleansing (correcting errors or inconsistencies in the data), and using ensemble models (combining predictions of multiple models)" [7]. Reveneau's view is that where a vendor's model reads company documents and the company trains no model of its own, monitoring and data cleansing are the two that apply. Monitor the system's answers on a fixed set of test cases, and keep the documents it reads correct and current.

Provenance: knowing where data came from

The same sheet asks companies to track where data came from and to sign trusted versions: "Employ digital signatures to authenticate trusted data revisions" [7]. A digital signature is a code that proves a file has not changed since a named party approved it. The sheet also warns about large public datasets: "one cannot simply assume that these datasets are clean, accurate, and free of malicious content" [7]. The page AI security risks for a large company covers poisoned data in detail.

Privacy and access

NIST's Generative AI Profile, NIST AI 600-1, names data privacy as one of 12 risks of generative AI: "Impacts due to leakage and unauthorized use, disclosure, or de-anonymization of biometric, health, location, or other personally identifiable information or sensitive data" [11]. De-anonymization means working out who a person is from data that was meant to hide it.

When AI systems connect to company data through the Model Context Protocol (MCP), an open standard for connecting AI applications to data and tools, the specification sets a consent rule: "Hosts must obtain explicit user consent before exposing user data to servers" [12]. A host is the AI application the user works in. The page connecting AI to older systems explains how MCP works. What a model provider may do with the data it receives depends on its terms; the guide on model provider terms and data use compares them.

The EU AI Act's rule on input data

For high-risk systems, Article 26(4) of the EU AI Act puts a duty on the deployer, the company that uses the system. To the extent the deployer controls the input data, it must make sure that data is relevant and representative enough for the system's intended purpose [9]. For Annex III high-risk systems, such as credit scoring, this applies from 2 December 2027, under Regulation (EU) 2026/1744 [10]. The page AI governance for a large company covers the other deployer duties.

A data readiness check

The table below is Reveneau's readiness check, built from the sources above. Run it for each candidate use before any build starts.

Question	What a good answer looks like	Source behind it
Where does the data live?	Named systems, with an owner for each	NIST MAP 2.3 [5]
May it be used for this purpose?	Consent, contracts and privacy rules checked and written down	NIST AI 600-1 [11]
Does it look like real use?	Recent cases, from the same customers, products and regions	NIST AI 100-1 [5]
Is there ground truth?	Past cases with known right answers, enough to write tests	NIST AI 100-1 [5]
How good is it?	Error and gap rates measured with agreed terms	ISO/IEC 5259 series [6]
Where did it come from?	A record of sources and changes; trusted versions signed	AI Data Security sheet [7]
How will drift be caught?	A fixed test set run on a schedule, with a trigger for review	AI Data Security sheet [7]; NIST [5]
Who can reach it through the AI system?	Access limited by role; consent before user data reaches a tool	MCP specification [12]

Past cases with known right answers become the test cases for an eval, a written, repeatable test of an AI system's answers against cases the company chooses. With them, a company can measure its AI from the first day. The guide on LLM evals explains how to turn them into tests, and choosing your first AI use cases explains why tasks with clear right answers make good first uses.

Where Reveneau fits

Reveneau is an AI software development consultancy with offices in San Francisco and Vancouver. Reveneau says AI writes all of its code and every change must pass an eval suite written from the specification. Reveneau says it takes responsibility for the whole project through production and after release. To talk about a project, see Reveneau's services or contact Reveneau.