Using Clean Data to Enable AI Adoption at Scale

Can your organization actually trust the data it uses to make decisions? The reason why we start off with this question is that if your warehouse is full of duplicates, missing values, outdated logic, undocumented transformations, or years of workarounds, AI will simply amplify those problems across the business. So, the goal should be to build clean, reliable data that AI agents can use to produce high-quality outputs you can trust.

This blog is based on insights from three Sr. Data Architects, Manuela Cannella, Darío Villalon, and Kevin Santos, who have built data pipelines for startups, fintech companies, and large enterprises across the United States, the UK, and Latin America. Immediately below, we explore what happens when AI agents are deployed on top of unreliable data and the best practices that organizations should follow before connecting AI to their data models. 

Deploying AI agents on unreliable data is a bad idea

The biggest risk of deploying AI agents on top of poor data is amplification. If the data warehouse already contains bad transformations, inconsistent relationships, or years of technical debt, the agent will use that same information as its source of truth. Our team thinks that a lot of these problems start with missing validation inside the data pipeline. When we asked Kevin Santos, one of our Senior Engineers, about this specific point, he explained that pipelines can technically run from beginning to end while still producing bad data, occurring in cases when:

• A transformation changes the data without anyone noticing. In one fintech project, transaction amounts were converted into hexadecimal values inside a serverless pipeline and later appeared in reports for one of Chile’s largest banks. The pipeline was technically running, but the numbers were wrong, which could easily lead to unreliable financial reporting and bad decisions.
• The data is technically valid, but the logic is wrong. A database may accept a negative amount or keep invoice details after the invoice itself has been deleted. Unless those business rules are clearly defined, an AI agent may treat the data as correct and use it in calculations, reports, or automated decisions.
• AI exposes sensitive data due to missing labels. In one project, an internal CRM value was being sent through an endpoint even though users should not have been able to see it. If an AI agent does not understand that the field is sensitive, it may treat it like any other piece of data and increase the risk of accidental exposure or a security incident.

The problem becomes much bigger once agents start working with each other. One incorrect value can be consumed by one agent, transformed by another, and then used in a report or automated decision. At that point, a small data-quality issue can quickly spread across the organization.

"Many companies never did the first step properly, which is cleaning and modeling all the information that lands in the data warehouse. If you then connect an MCP, an agent, or any AI layer on top of a dirty warehouse, the AI starts consuming bad data and the problem gets amplified."

Darío Villalon - Sr. Data Engineer - Ewents

AI will always give you an answer, even when it is wrong

One concern that came up over and over again in our interviews is that AI tends to produce an answer even when it does not have enough context to produce a reliable one. By nature, the model may return something that that sounds reasonable and is technically well-structured, even when the underlying assumptions are incomplete or wrong.

As Darío Villalón explained, “AI tends to look for an answer even when it does not have enough context. That is dangerous. If someone with little experience or little knowledge of the business receives a solution and accepts it without questioning it, you can start a chain of errors right there.”

Today, working with Senior Engineers is more important than ever because years in the industry give  them the “technical intuition” to:

• Spot when something looks wrong by recognizing outputs that may look perfectly reasonable at first but do not quite add up based on how the system, the data, or the business actually works.
• Anticipate problems before production by thinking ahead about what changes once a solution moves from a small test environment to millions of records, higher transaction volumes, more users, and real infrastructure costs.
• Add missing business context by understanding the rules, exceptions, and operational realities behind the data, and giving AI the information it would otherwise have no way of knowing.

Let’s not forget that keeping costs under control falls under the same validation. If you ask AI to work with a table containing millions of records, it may generate a solution without warning you that the query could be very expensive to run. As models gain more connectors and direct access to internal systems, their capabilities increase, but so does the potential impact of a bad decision. In a previous blog, our team wrote about how quickly cloud costs can grow on a legacy AWS platform and what it takes to bring them back under control. Poorly modeled data warehouses are one of the most common ways those costs start to spiral. So, let’s look at how to keep data clean.

Three tips for data validation in ETL pipelines

1. Create a diagram

Before asking AI to build anything - think, then draw. Our team suggests using an iPad or a drawing board to map out the data flow, the overall goal, and to write down the business and technical rules first. Once you give that diagram to the AI, it already has a framework to follow closely, which helps preserve the context of the project and prevents the AI model from making its own assumptions without supervision.

2. Validate at every stage of the data pipeline

Next, validate the data at all times, because a pipeline can run successfully and still produce bad data Ideally, you should start validating that the data follows the real-world logic of the company, not just that the fields are present and formatted correctly. If the overall logic works, then you can check for technical issues that could carry over once an agent starts using the data, such as null values, duplicates, types, formats, and missing relationships. 

Bonus tip: Our team uses tools like Great Expectations, dbt, and AWS Glue Data Quality to automate these checks throughout the pipeline.

3. Give AI as much context as possible

AI needs to be tested with the same kind of context and data it will face in the real world. So, before going live, test it with realistic data, business rules, edge cases, and production conditions so it learns how the information is actually used and behaves as expected. In one of our previous blogs, we share recommendations for implementing AI software solutions that also apply to data pipelines.

The last point we’d like to cover is how engineers will have to interact with agents to orchestrate these data pipelines.

Ensuring data quality for AI agents

The next evolution of AI in engineering will be a chain of specialized agents handing work off to each other: one for analysis, another for development, another for QA, another for reporting, and potentially others serving different areas of the business. Darío pointed out that many companies used to have more clearly separated roles, including DBAs, QA engineers, and Business Analysts, while today a single Data Engineer may be expected to cover much of that work with the help of AI. While working with a single engineer can reduce costs, the biggest downside is the risk that validation, business analysis, and quality controls get compressed or skipped entirely. Three ideas follow:

• Scale still requires engineering experience. Something that works perfectly on a small local dataset may behave very differently in production, where a table can contain millions of records and introduce latency, concurrency, or timeout problems. Kevin added that an experienced engineer knows to give the AI that context before asking it to design the solution.
• AI can generate a lot of output, but not necessarily correct output. Darío pointed out that experienced engineers often recognize when an AI-generated solution “doesn’t feel right” because they have years of technical intuition to compare it against. A junior engineer who has relied heavily on AI from the beginning may not yet have that reference point.
• Business context becomes part of the engineering job. Our team also believes that engineers still need to understand how different teams use the data, what the business is trying to accomplish, and what constraints the AI may not know about. Without that context, the model will still try to complete the task, even if its answer is technically plausible but wrong for the business.

So the engineer of the future may write less code manually, but that does not make the role less important. As our team expects, there will be an increased demand for Senior Data Engineers, because the work that survives automation is the work that requires context, which we also covered in our recent blog about the forward deployed engineer role. 

Finally, as data engineering agents take over more of the execution work, the cost of a bad assumption can cascade across the entire company. For instance, one engineer making a mistake in a traditional pipeline might affect one transformation or one report. In an agent-driven workflow, that same mistake can be picked up by another agent, transformed again, passed downstream, and eventually used in a dashboard, recommendation, or automated business decision. Thus, the more autonomous the workflow becomes, the more important the quality of the underlying data is.

If your team is preparing to deploy AI agents and you are not sure the data underneath is ready, we can help you assess it and fix what needs fixing. Get in touch with Ewents.

Frequently Asked Questions (FAQ)

How do I know if our company’s data is ready for AI agents?

Your company’s data is ready for AI agents when it is accurate and consistent, and from the Security side, if it is well documented, accessible, and governed. A useful thing to do is to keep a unified data catalog that allows AI to consume data without disrupting the normal operation of your services or applications. Having a data warehouse or data lake in a controlled environment makes governance easier and gives the AI agent a much more complete and useful context.

Data readiness for AI also depends on the maturity of the company’s data function. Startups usually have lower data volumes and more flexibility, so introducing these technologies can be easier. On the other hand, large companies that have grown over time with legacy systems often face a much harder transition.

That aside, you do not necessarily need to make the entire organization AI-ready at once. A good option is to start small, with a new module or a well-polished area where the data is already reliable, and expand from there. People also need to be trained to work effectively with AI agents and understand their limitations. AI needs both reliable data and guidance from experienced engineers to produce high quality outputs.

What data quality checks should we run before connecting AI to a data warehouse?

Great question. The most important checks are the ones that make sure the data can be interpreted correctly and reduce the chances of the agent getting confused or producing unreliable answers, including:

• Completeness and missing values
• Accuracy and consistency
• Duplicates
• Valid numbers, dates, and formats
• Data types
• Referential integrity
• Data freshness
• Table and field naming
• Sensitive or PII data that may need to be masked or encrypted

Additionally, you should monitor how people are using the agents, what responses they are providing, and how accurate those responses actually are. In highly automated environments, other agents may eventually perform part of that monitoring and validation as well. In our experience, a good approach to follow is to start with a pilot for a small group of users, monitor the results, and refine the system before moving it into wider production use.

Can AI agents fix dirty data in a data warehouse?

Partly, yes. This is actually one of the areas where AI has a lot of potential. AI is very good at suggesting fixes, identifying patterns (like anomalies, outliers, duplicates, and other common data-quality problems), and automating part of the cleanup process. However, without instructing the models with proper business context, the agents may recognize that something looks unusual without actually knowing if a value is wrong, why it is wrong, or what the correct value should be, and thus cascading issues across the organization. 

Our suggestion is that any important changes should still be validated by an engineer before they are applied to production data.

How does poor data quality affect AI-generated business reports?

The impact is critical. Bad data can lead to inaccurate metrics, misleading insights, and potentially incorrect business decisions. If the data is dirty, we would fix that before focusing heavily on AI because otherwise you are simply amplifying and spreading the same bad data across the organization. 

A second major risk to consider is that AI tends to produce an answer even when the information is incomplete. If the data is missing, inconsistent, or difficult to interpret, the model may try to infer what should be there. For example, A NULL caused by a failed data load, for example, can have many different meanings that cannot necessarily be inferred from the surrounding data and could be propagated by agents across other agents, reports, or databases. Hence, data quality should be addressed before deploying AI agents.

How do you validate data at each stage of an ETL pipeline?

You should check the data throughout the pipeline rather than waiting until it reaches the final report or AI agent. One approach we commonly use is a medallion architecture:

• Bronze layer: This is where the raw data lands. Validation is mostly focused on schema and structure, making sure the data arrived correctly and can be processed in later stages. You can also use monitoring tools to validate metadata or checksums as information travels from the source.
• Silver layer: Here you can start validating the values themselves. That includes uniqueness, not-null constraints, compatible data types, and rules that prevent sensitive information from flowing into later layers.
• Gold layer: This is the consumption layer, so the validation becomes much more business-driven. You can check relationships between fact and dimension tables, calculations, audit fields, timestamps, freshness, and the business logic behind the final data.

Regardless of architecture, the key point here is that a pipeline can run successfully and still produce bad data. Once the team starts performing validations, the most important thing to do is to confirm not only that the process completed, but that the information remained correct throughout every transformation.

What is the difference between data quality rules and business rules for AI?

Data quality rules verify that the data is technically reliable, covering things like structure, data types, integrity, nulls, duplicates, and consistency. Instead, business rules verify whether the data actually makes sense for the business. For example, a database may technically accept a negative value, but the business may have a rule saying that a particular type of transaction can never be negative. In this case, the data may be technically valid, but it is still wrong. So, AI agents need to follow both types of rules to produce high-quality output.

What are the security risks of giving AI agents access to company data?

Every organization should consider rebuilding or significantly refactoring its data warehouse when the existing architecture is too complex, outdated, or difficult to trust. It’s probably a good idea to refactor when there’s:

• Too much technical debt: The warehouse has accumulated years of workarounds, tightly coupled components, and legacy transformations.
• Poor documentation: Important logic is difficult to understand because of employee turnover, weak knowledge transfer, or years of undocumented changes.
• The architecture was built for a different purpose: Many older warehouses were designed primarily for BI and reporting, not for LLMs, AI agents, or real-time data consumption.
• Modernization is easier than retrofitting: In some cases, rebuilding or refactoring the platform can require less effort than trying to adapt an old architecture for AI.

Historically, rebuilding a data warehouse was extremely expensive and time-consuming. AI is starting to change that by helping teams analyze legacy systems, document transformations, generate code, and accelerate parts of the migration process.

If your goal is to become a more AI-driven or data-driven organization, it is worth evaluating whether the current warehouse can support that future or whether modernization would be the better path. Our team can help with that.