Scaling Data Quality for AI: GM's Intelligent Data Analyst Model

Summary

General Motors partnered with Databricks and Anomalo to implement an intelligent data analyst model that shifts enterprise data quality from reactive debugging to proactive anomaly detection across a federated data mesh of more than 1,000 tables spanning 36 teams.
The approach standardizes four essential quality checks—freshness monitoring, volume anomaly detection, schema drift detection, and null spike flagging—across all domains, ensuring that AI systems consuming GM's data receive inputs they can trust.
Real production examples in this video show schema changes and behavioral anomalies in vehicle telemetry data caught before propagating to downstream AI systems, demonstrating that automated, measurable trust is the prerequisite for responsible AI deployment at a company building software-defined vehicles.

Scaling Data Quality for AI: GM's Intelligent Data Analyst Model

At General Motors, processing petabytes of data daily and making safety-critical decisions requires more than dashboards and manual SQL rules. GM discovered that traditional data quality approaches cannot scale in AI environments, especially across federated domains handling vehicle telemetry, manufacturing data, and operational systems simultaneously.
Learn how GM partnered with Databricks and Anomalo to implement an intelligent data analyst model that shifts from reactive debugging to proactive anomaly detection. Explore essential checks for enterprise standardization, including freshness monitoring, volume anomalies, schema drift detection, and null spike flagging. See real examples of schema changes and behavioral anomalies caught before impacting downstream AI systems, and understand why automated, measurable trust is foundational for responsible AI deployment.
🤝

Chapters

FAQs

How is General Motors scaling data quality across its federated data mesh?

General Motors uses Anomalo integrated with Databricks to monitor more than 1,000 tables across 36 teams, with each domain owning its own data quality while automated anomaly detection provides a consistent enterprise-wide signal layer. Janine Ward, GM's enterprise data quality lead, built the infrastructure so every domain benefits from standardized quality checks without centralizing all data quality work in a single team.

What are the essential data quality checks standardized across General Motors?

GM's enterprise data quality standard described in this video covers four essential checks: freshness monitoring to confirm data arrives on schedule, volume anomaly detection to catch unexpected row count changes, schema drift detection to flag structural changes to tables, and null spike flagging to identify sudden increases in missing values. These standardized signals apply consistently across all 36 teams and 1,000-plus tables in the data mesh.

Why do traditional data quality approaches fail to scale for AI workloads?

Traditional data quality approaches based on manual SQL rules and dashboard monitoring cannot scale in AI environments because AI amplifies data quality problems—a single bad input can generate many bad outputs at the speed of model inference. At GM's scale across vehicle telemetry, manufacturing, and operational systems, static rule-based monitoring creates excessive maintenance burden and misses behavioral anomalies outside predefined thresholds.

What is Anomalo and how does it integrate with Databricks for enterprise data quality?

Anomalo is a data quality platform that uses machine learning to detect anomalies in data pipelines, including behavioral patterns that static rule-based systems would miss. At General Motors, Anomalo integrates with Databricks to monitor production tables and alert teams to schema changes, volume drops, and statistical anomalies before those issues affect the AI systems and downstream consumers that depend on the data.

Full transcript

[00:07] Hi everybody. Thank you for attending today's session. I'll start again. Thank you for attending today's session, especially with the end of the England-Croatia game over there. You can't hear me? Oh, do you have headphones? Okay. Thanks, man.
[00:23] All right, my name is Kelly Dunaway and I lead one of our data solution architect teams at Anomalo. I work closely with Janine and the General Motors team on their enterprise rollout of Anomalo. Um I work closely with them every day rolling out Anomalo and I'm thrilled to be introducing today's session. Then
[00:40] I'll hand it over to Janine who will walk you through how General Motors is scaling AI with trusted data. Now most sessions at a conference like this are about building with AI. This one is about what has to be true before any of that works. The next 20 minutes are about what it actually looks like to
[00:56] operationalize data monitoring inside one of the most complex data environments on the planet. I do realize and can someone help me um put the slide up on the um on the screen? Thank you.
[01:16] All right, wonderful. So Janine Ward is senior data governance engineer and enterprise data quality lead at General Motors, a company that is quite literally building vehicles that are software-defined AI systems. Janine leads the enterprise rollout of Anomalo across a large-scale data mesh
[01:31] architecture. So she isn't solving this problem for one domain or one team. Her team has built the infrastructure that allows every domain to own their own data quality with automated anomaly detection and AI at its core. That's a fundamentally different kind of challenge that most data governance
[01:48] organizations don't even attempt. What I've come to appreciate about working with Janine is Janine works at the intersection of three things that are usually siloed: data quality, governance, and AI readiness. Her team has built solutions that truly make
[02:03] trust measurable. Following the presentation, you're invited to continue the conversation with us at the Anomalo booth. We're in zone four, if you walk back there, or the first row of booths, number 433. What Janine has built answers the question that every data leader in this
[02:19] room is silently asking: How do you make trust scalable? Please join me in welcoming Janine Ward. The demand for data keeps growing and growing, but our confidence in the data
[02:35] doesn't necessarily keep pace. Teams end up spending valuable time investigating issues, validating numbers, and answering the same question over and over: Can we trust this data? I think every data team in the world has experienced some version of this problem.
[02:52] At General Motors, we're operating at a scale where trusted data isn't optional. It's absolutely critical. What we discovered very quickly was that traditional data quality approaches simply do not scale in AI environments. At that scale, data quality isn't just
[03:08] about catching bad records. It's about enabling safe software-defined vehicles, responsible AI, and enterprise decision confidence. Manual SQL checks, reactive monitoring, and centralized governance teams simply cannot keep pace with the volume,
[03:24] velocity, and complexity of modern enterprise data. Especially when you're processing petabytes of data across vastly different environments and operational systems all simultaneously. And honestly, at a certain scale,
[03:39] manually managing data quality starts to feel a little like parenting three kids: constant monitoring, unexpected surprises, and if things get quiet for too long, you should probably be concerned. So today, I'll walk you through how GM
[03:54] partnered with Databricks and Anomalo to operationalize trusted data at enterprise scale using what we call an intelligent data analyst model. Not just to detect problems, but to help teams understand and resolve them faster.
[04:10] When I joined GM, I was given a simple assignment, learn the current data quality landscape. What I found was not a landscape at all, it was a patchwork. There was no enterprise data quality platform, no centralized repository of
[04:25] rules, consistent logging, or shared trust metric. SQL lived in personal folders on laptops. Thresholds were hardcoded and monitoring was reactive. Some teams had mature processes, whilst others were just getting started.
[04:41] Data quality existed everywhere, but nowhere in a scalable, enforceable way. As we accelerated on Databricks, the fragmentation became much more visible. The challenge wasn't that teams were weren't doing data quality, the challenge was that everyone was doing it
[04:58] differently. At GM, we operate across dozens of major business domains in a federated data mesh architecture on Databricks. Each domain owns and produces data products independently. That gives us scale and flexibility,
[05:15] but it also creates quite a bit of complexity. We're managing thousands of data sets, streaming workloads, connected vehicle telemetry, manufacturing data, customer data, operational systems, and AI and analytics workloads all simultaneously.
[05:32] And these systems are constantly evolving. New pipelines get deployed, schemas change, columns are added, business logic changes, data products evolve. What became very clear very quickly was that centralized governance teams cannot
[05:48] manually govern this environment at enterprise scale. We simply could not hire enough people to manually write, maintain, investigate, and operationalize data quality rules across the organization. Something had to change.
[06:04] Like many enterprises, our early lakehouse adoption motion was simple, put all your data here. And we did. We put all of our data there. Data from dozens of business functions and landing in Databricks workspaces. Pipelines multiplied. Tables grew rapidly. Before
[06:20] long, we had what many organizations experience. More data than ever before, but not necessarily more trust. Without lifecycle controls, we also created redundant tables, obsolete data sets, trivial one-off extracts.
[06:37] What we call rot. The irony was the more data we had, the more pressure we felt to monitor all of it. We had no standardized enforcement or enterprise trust signal. We didn't just need anomaly detection. We needed a fundamentally different
[06:53] operational model. One of the biggest things we've learned is that AI does not necessarily eliminate data problems. It amplifies them. The more organizations invest in AI models, AI agents, copilots, generative
[07:10] AI, and autonomous workflows, the more dependent they become on trustworthy data foundations. Historically, many enterprises data quality programs were designed around dashboards and reporting. They relied heavily on static business rules and manual oversight.
[07:27] But AI changes that operating model entirely. Now we're dealing with rapidly evolving schemas, streaming data, unstructured data, cross-domain dependencies, model training data sets, and real-time operational decision-making. Suddenly that one null column isn't just
[07:44] a reporting issue anymore. It's potentially influencing downstream AI behavior. The challenge became how do you maintain trust without creating operational bottlenecks? Because if your governance process requires humans manually investigating
[08:00] every issue, you'll eventually hit a scaling wall. Traditionally, data quality looks something like this. An issue happens. Someone downstream notices that a report broke. An engineer gets paged. Someone else says, "Huh? It worked yesterday."
[08:16] And then the real fun begins. Everyone suddenly turns into a detective. Bridge calls pop up like surprise meetings no one asked for. Jira tickets multiply overnight. And Slack? Absolute chaos mode. Teams spend hours, sometimes days,
[08:33] trying to identify where the issue occurred, what changed, whether upstream systems were affected, whether it affected AI and analytics consumers. At scale, this becomes incredibly expensive operationally. Static SQL rules also become difficult
[08:49] to maintain because environments evolve constantly. That's when we realized something important. We didn't have a tooling problem. We had an operating model problem. We needed a fundamentally different approach. One that could help investigate issues before anyone had to
[09:06] become involved. That's what led us to the intelligent data analyst model. Rather than building another centralized monitoring team, we implemented Anomalo on top of our data Databricks Lakehouse. What we really wanted was a system that
[09:21] could do the first hour of investigation before an engineer ever opened a laptop. The goal is creating systems capable of detecting anomalies, understanding metadata data and lineage context, recognizing schema changes, surfacing root cause indicators, and generating
[09:38] actionable trust signals. Instead of engineers manually piecing together evidence across multiple systems, we wanted intelligent systems helping teams understand problems faster. Our goal is simple. Make trust measurable, scalable, and
[09:55] part of everyday workflows. Let me walk you through a few two example two real examples. The first is schema drift. In a large federated environment, like we have, structural changes to tables happen constantly. And let's be honest,
[10:13] schema drift is one of those issues that every team experiences, but is often one of the hardest to detect before it causes downstream impact. In this particular example, a production data set experienced structural changes. New columns were introduced, and another
[10:30] column was removed. The pipeline itself continued to run successfully. No immediate failures were triggered. From a traditional monitoring standpoint, everything still appeared healthy. Underneath the surface, the structure of the data had changed, and that is
[10:46] exactly what makes schema drift so dangerous. The pipeline can still be green, but downstream consumers are quietly receiving something different than what they expected. Anomalo automatically detected these schema level changes. These types of changes are often easy to
[11:03] miss, especially when they don't immediately break pipelines, but instead introduce subtle downstream issues like null values, misaligned joins, and silently broken dashboards. What made this particularly valuable was wasn't just detecting that a schema
[11:19] change occurred. It was the ability to immediately understand the impact. From the platform, teams could immediately understand which data sets were affected, which downstream consumers could be impacted by this, and where these changes originated within the upstream pipeline. Instead of
[11:35] discovering the issue days later during a stakeholder meeting or after a dashboard failure, teams had immediate visibility. That changes the conversation. Instead of asking, "What broke?" the conversation became, "A structural
[11:50] change has occurred. Let's evaluate the impact before it becomes a business issue." At enterprise scale, that's a completely different operating model. The second example comes from critical vehicle telemetry. This is where anomaly detection becomes incredibly powerful.
[12:08] In just a single weekend, Anomalo identified unusual behavior patterns within the data set. Typically, this is routine for a Sunday when driving activity is lower, but in this instance, it was incredibly impactful. What's important here is that nothing
[12:23] had actually failed. Jobs were still running, data was still arriving, nothing appeared obviously broken. But the platform detected several signals that didn't align with historical behavior, including lower than expected incoming data volume,
[12:40] delayed freshness timing, and shifts in the distribution patterns. Individually, each signal might not trigger concern. Together, they indicated that something upstream was beginning to degrade. This is exactly the type of issue that's
[12:56] difficult to identify using traditional rule-based monitoring because no single threshold was technically violated. The system recognized that the behavior itself had changed. From the Insights view, teams could immediately see impacted data sets,
[13:11] trend deviations over time, affected consumers, lineage relationships, and potential upstream dependencies. If you've ever worked on a production issue, you know that the hardest part isn't usually fixing the problem. It's
[13:26] figuring out where to start. Reducing that investigation time has been one of the biggest operational improvements we've seen. At a high level, this is how our trusted data architecture operates. Databricks provides the core lakehouse
[13:42] and domain architecture. Metadata and governance signals are integrated across the ecosystem. Anomalo continuously evaluates anomaly patterns and operational trust conditions. Trust signals and metadata become surface directly into governance
[13:58] workflows and in data catalog experiences. Most importantly, this is not a centralized execution. The domains own their operational data quality processes. Governance provides standards, automation frameworks, and trust models,
[14:15] but accountability remains embedded within the domains themselves. That distinction is incredibly important for scalability. One of the biggest things we standardized was what we call essential checks.
[14:31] These are foundational automated quality signals that apply consistently across the enterprise, all the domains. Examples include freshness, volume anomalies, null spikes, duplicate detection, schema drift, referential integrity, and AI specific validations.
[14:49] The important part is that these checks are standardized and automated. Instead of every team reinventing data quality independently, we provide a repeatable trust baseline across domains. That consistency becomes incredibly
[15:05] important when supporting AI at enterprise scale. Once we had the operating model established, the next challenge was scale. Could we move beyond the pilot and make
[15:20] this work across the enterprise. The answer was yes. The first half of this year alone, we have onboarded and are monitoring thousands of tables across 36 different teams. We've also moved to a self-service onboarding model.
[15:37] Domain teams can now onboard data sets, configure checks, and manage monitoring all independently. That shift has been incredibly important because governance doesn't scale when every request requires governance team member.
[15:58] Governance scales when standards, automation, and tooling enable the domains to operate independently. And for everyone wondering, yes, every one of those tables came with questions, office hours, Slack messages, and at least a few conversations that started with
[16:14] "Quick question, Janine." One of the most important lessons we've learned is that trusted AI starts long before the model. AI systems inherit the quality, reliability, and governance posture of
[16:30] the underlying data products feeding them. As organizations move toward generative AI, AI agents, all the things that you've been hearing about this weekend, autonomous systems and intelligent applications, the importance of measurable operational
[16:46] trust increases significantly. Cuz AI is very confident even when the data is wrong. And that's why observability, governance, trust scoring, and automated quality control has become foundational
[17:02] capabilities for AI-ready enterprises. Every organization is asking the same question right now. How do we move faster with AI without losing trust in our data? At GM, we learned that question has
[17:18] exactly one answer. It's not more dashboards. It's not more governance head count. And it's not more brittle SQL rules to maintain. The answer is automated, measurable, embedded trust built into every domain's
[17:34] operating model from day one. The intelligent data analyst model is what makes that possible at GM scale. If you want to dig deeper, come join us at the Anomalo booth. I'm happy to answer questions and share additional insights with anybody. Thank you all so
[17:51] much for being here today. This is amazing.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.