Don’t have time to read the full post? Watch how Soda solves data quality in a live demo on November 17. Register for the free livestream.

The future of data quality is a small team managing a nearly automated system across the enterprise. People define what good data means, decide what the system can do, and step in when their judgment is needed. The system carries out the daily work of finding problems, understanding them, and fixing them.

The technical pieces are here. We can now build toward that future.

For anyone working through a backlog of data quality issues, “solved” may sound ambitious. There is always another source, another broken pipeline, another definition to agree on. But the persistence of that work tells us something about how we have organized it.

W. Edwards Deming, a pioneer of quality management, wrote: “Cease dependence on inspection to achieve quality.” He urged manufacturers to improve the process that produced the defects. The same principle applies to data. If a pipeline keeps producing the same bad records, detecting and cleaning them every day leaves the cause in place.

So why did we end up building enormous data quality programs? Because inspection was the first thing we could automate. Tools could detect issues, but rarely understood what the numbers meant to the business, what depended on them, or how to safely fix them.

People connected those steps. An engineer traced the pipeline. A domain expert explained the exception. Someone agreed to the fix. Someone else made it. And someone checked again the next morning.

The program was a reasonable response. It was the human machinery needed to connect incomplete technical pieces. But we started treating that machinery as permanent. More coverage meant more findings, and more findings could mean more work, even when we were buying tools intended to reduce it.

AI gives us a way to change that.

We have the components to express what good data looks like, find familiar failures and unfamiliar patterns, investigate their causes, and correct the data. Agents can connect those capabilities, carrying context from one step to the next and doing much of the work that previously waited for a person.

An investigation can lead to a correction and a check that it worked. What the system learns can inform the next investigation. When the problem originates upstream, that understanding can help address the process producing it.

This brings Deming’s principle within reach: quality built into the way data is produced and used.

It also arrives at a moment when we need it.

When humans see a number that looks wrong, they may pause and question it. That pause is an informal quality control. As agents take on more work, we need to build that care into the systems they depend on.

Agents are becoming both producers and consumers of data. They create new information, act on it, and pass their results to other systems. Each new workflow increases the demand for dependable data. Expanding a queue of investigations for people to work through cannot keep pace indefinitely.

But the same technology creating that demand can help us meet it. Agents can also carry more of the work required to keep data usable.

That changes what a data quality team can be.

A small team could oversee a system that continuously manages quality across the enterprise. People who understand the business would define expectations and decide which actions the system could take on its own. Routine work would proceed within those boundaries. Unfamiliar cases would reach the right person with the context needed to make a decision.

Those decisions should keep working after the conversation ends. An agreed expectation should apply wherever it is relevant. A resolved exception should inform how similar cases are handled. As the business changes, people should be able to update the system’s direction.

The team would spend more of its time extending coverage, improving the operation and addressing the causes of recurring failures. Its knowledge would reach further than its members could through individual investigations.

That is an exciting prospect for anyone who has had to choose which data deserved attention because there was never enough time to cover it all.

Soda was founded in 2019 to solve data quality. We made it easier to find problems, but customers still had to do much of the work that followed. That gap has shaped what we have built since. The pieces can now come together, from the first agreed expectation through to a verified correction.

Putting them to work still requires people to define what matters and decide how much responsibility to give the system. But we can approach that work with a different ambition: enterprise-wide data quality managed by a small team, with most of the daily work automated.

The future of our work will depend on systems that can keep data trustworthy at scale. That foundation will allow people and agents to take on problems we would once have considered beyond reach.

We have spent years helping people find what is wrong with their data. What comes next should give them far more freedom to build with it.

Want to see what comes next? We’re launching it on November 17, streamed live from New York and free to watch. Save your spot.