Trusted data for AI is data whose quality, meaning, origin, owner and access rules have been checked for a specific AI use, with that proof attached where a model or agent can read it. You get it by picking one use case, setting pass marks for the data it needs, naming owners, testing the data where it lives and labeling what passed. You keep it by monitoring every change and handing those trust signals to the AI when it answers.
What makes data trusted for AI?
Trust depends on the job, so one table can be trusted for one use and untrusted for another. A sales table refreshed weekly is fine for a quarterly board slide and wrong for a pricing agent that quotes by the hour.
The NIST AI Risk Management Framework 1.0, released in January 2023, lists seven characteristics of trustworthy AI, starting with “valid and reliable”. Most are earned or lost in the data. Article 10 of the EU AI Act requires training, validation and testing data for high-risk systems to be “relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose”, under data governance and management practices.
In practice, data is trusted for AI when you can show six things for the use case in front of you:
| Property | The question it answers | Evidence you can show |
|---|---|---|
| Fit-for-purpose quality | Is it accurate, complete and fresh enough for this use? | Rule results against agreed pass marks |
| Defined meaning | What does this column or metric mean in business terms? | A glossary term linked to the asset |
| Traceable origin | Where did it come from and what changed it? | Column-level lineage from source to output |
| Named owner | Who answers for it when it breaks? | An owner and a steward on the asset |
| Governed access | Who and which agents may see it? | Classification tags and access or masking policies |
| Visible status | Is it approved, in progress or retired? | A certification label the AI can read |
If any row is missing, the AI fills the gap with a guess, and a guess delivered fluently reads like a fact.
Why is trusted data for AI a higher bar than trusted data for reports?
A dashboard has a human reader. When revenue doubles overnight, an analyst frowns, opens the query and finds the duplicate load. An agent has no frown. It reads the number, writes the answer and, increasingly, takes the next action on its own.
The Air Canada case shows what happens when two sources disagree and nothing tells the AI which one wins. In Moffatt v. Air Canada (2024 BCCRT 149), the airline’s website chatbot told a passenger he could claim a bereavement fare after travel. A separate page on the same site said he could not. The British Columbia Civil Resolution Tribunal held the airline liable for negligent misrepresentation and rejected the argument that the chatbot was a separate entity. As the law firm McCarthy Tétrault reports the ruling, “It makes no difference whether the information comes from a static page or a chatbot.” Read as a data problem, nothing marked which of the two policy texts was the approved one.
Leaders also overrate how ready they are. In a 2025 survey of 505 data and analytics leaders by Drexel University’s LeBow College of Business, 88% said their data was ready for AI, while 43% named data readiness as one of their biggest obstacles. The report calls this a gap between confidence and reality.
For why AI pilots pass on clean extracts and then stall in production, see why AI projects stall on data rather than models.
How do you get trusted data for AI, step by step?
Start narrow. Certifying a whole data estate before any AI ships is how programs run out of budget. These four steps prepare the data for one use case.
-
Pick one AI use case and list what it reads. Write down the tables, columns, documents and metrics the model or agent will touch. A support agent might need the order table, the refund policy text and the definition of “active customer”. Nothing outside this list needs certifying yet.
-
Set pass marks for that use. Decide how fresh, complete and accurate each input must be, and who signs off. A fraud model may allow no nulls in the transaction amount and need data under an hour old. A monthly forecast can accept a day’s lag. Write these as rules, because a rule can be tested and an intention cannot.
-
Name an owner for every input. Each table, metric and document gets a person accountable for fixing it and a steward who keeps its definition current. When an agent answers wrongly and nobody owns the data behind it, the fix waits.
-
Test the data where it lives. Run the rules inside the platform that already holds the data, so nothing is copied out to be checked. If your data sits in Snowflake, data metric functions measure attributes such as null counts, and a function paired with an expectation becomes a quality check. Snowflake lists more than 185 system data metric functions across completeness, freshness, uniqueness, validity and volume. The feature requires Enterprise Edition.
The output of these steps is a short list of data assets with owners, rules and current results. That list is what you certify next.
How do you keep data trusted once AI is using it?
Trust decays. Schemas change, a pipeline is rewritten, a definition is updated in one tool and not another. These steps keep the label honest after launch.
-
Define the business meaning and attach it. Link each column and metric to a business term so “revenue” means one thing to the finance team, the dashboard and the agent. A business glossary is where those definitions live, and the link from term to column is what an AI can actually use.
-
Trace lineage to the column. You need to see which upstream change broke which downstream answer. OpenLineage, an open standard for lineage data collection, lets pipelines and tools emit lineage events in one shared format. Column-level lineage also lets a failed check on one source table mark every dependent asset as suspect. The detail on lineage that serves AI is covered in how AI-ready data lineage activates trust and context.
-
Label status where the AI can read it. Mark assets that passed as certified, work in progress as draft and retired assets as deprecated. Then re-run the rules on a schedule and downgrade the label automatically when a check fails.
-
Hand trust signals to the AI at answer time. A label that only a human can see does nothing for an agent. The Model Context Protocol, an open-source standard for connecting AI applications to external systems, gives agents a standard way to ask for an asset’s definition, owner, lineage and certification before they use it. An agent that can see “deprecated” can refuse the table.
How do you check whether your data is trusted enough for AI?
Score each use case, not the whole estate. A use case passes when every input clears the checks below. One red flag on an input the agent depends on is enough to hold the launch.
| Check | Passes when | Red flag |
|---|---|---|
| Quality rules | Every input has written rules, and the latest run meets the pass marks | Rules exist only in someone’s head, or the last run is weeks old |
| Meaning | Every metric the AI reports links to one approved definition | Two teams define the same metric differently |
| Lineage | You can trace each output column back to its source | Lineage stops at the warehouse or skips the BI layer |
| Ownership | Every input has a named owner who has responded to an issue | The owner field is empty or names someone who has left |
| Access | Sensitive columns are classified, and the agent’s identity has only the access it needs | The agent runs on a shared admin account |
| Status | Inputs carry a certification label that the agent reads | Deprecated tables are still reachable and unlabeled |
Keep the evidence. For high-risk systems, Article 10 of the EU AI Act asks for data governance and management practices, and this table, saved per use case with dates, is evidence of them. It also answers what an auditor will ask after a bad answer: what did the AI know about this data when it used it?
How does Atlan help teams get trusted data for AI?
Atlan puts trust signals on each data asset and delivers them to the AI tools that use the data.
Status is visible on every asset. Atlan certificates mark an asset as Verified when it is ready to be used, Draft when it is work in progress and Deprecated when it no longer exists. Vera, Atlan’s Data Quality agent, scores critical assets on completeness, accuracy and freshness, so AI can tell which assets it can and can’t trust. Those scores propagate along lineage to every downstream asset and every AI agent that depends on them. Atlan captures column-level lineage across warehouses, pipelines and BI tools, so a failed check upstream shows its downstream impact.
Agents get the same signals. Atlan MCP is a hosted server that lets AI clients such as Claude, Cursor, ChatGPT, Gemini and Copilot use Atlan as a context layer through the Model Context Protocol, and every action respects the permissions already set in Atlan.
Definitions are the slowest input to produce, and they are where trust is easiest to measure. Customers generated 290K descriptions with Atlan AI in a year, with a 90% acceptance rate. Oliver Gomes, VP, Analytics & Strategy at Fox, says that with it, “our analysts trust AI-generated descriptions enough to make decisions on them every day.”
FAQs about trusted data for AI
Is trusted data for AI the same as AI-ready data?
They overlap. AI-ready data usually describes the whole condition of data for AI: format, access, volume, quality and governance. Trusted data is the part you can prove: rules that passed, a defined meaning, traceable lineage, a named owner and a visible status. Data can be AI-ready in format and still untrusted, because nobody has checked it for the use in front of you.
Who owns trusted data for AI?
The business owner of each data asset owns its trust, with a data steward keeping its definition current and the platform team running the checks. The AI team owns the list of inputs for its use case and the pass marks. When an agent answers wrongly, the owner of the input behind that answer is the person who fixes it.
Does unstructured data need the same treatment?
Yes. Policy documents, contracts and knowledge-base articles feed retrieval systems directly, and they go stale like tables. Give each document an owner, a status and a review date, and retire old versions so they cannot be retrieved. The Air Canada chatbot case turned on two policy texts that disagreed.
How do you start if you have hundreds of data sources?
Ignore most of them at first. Pick the one AI use case closest to production, list the inputs it reads and certify only those. Each use case you finish adds certified, owned, defined assets that the next use case can reuse, so coverage grows with the work you ship instead of ahead of it.
Sources
- AI Risk Management Framework, NIST
- AI RMF 1.0, Section 3: Characteristics of trustworthy AI systems, NIST AI Resource Center
- Article 10: Data and Data Governance, EU Artificial Intelligence Act
- Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot, McCarthy Tétrault
- Data Integrity and AI Readiness 2026, Drexel University LeBow College of Business
- Introduction to data quality checks, Snowflake Documentation
- System data metric functions, Snowflake Documentation
- OpenLineage, OpenLineage project
- What is the Model Context Protocol (MCP)?, Model Context Protocol
