GM's Insights Factory: What Enterprises Can Learn

GM presented their data intelligence architecture at DAIS 2024, and it deserved more attention than it got. Most of the conference coverage focused on startup architectures and platform vendor announcements. GM is a 116-year-old manufacturer with hundreds of thousands of employees, decades of legacy systems, and data operations spanning manufacturing, supply chain, dealer networks, and connected vehicle telemetry. When they show you something that's working, it's worth paying attention to, because they solved the hard version of the problem.

What Their Architecture Revealed

The core insight from GM's presentation: they built their data intelligence layer on top of a unified lakehouse, but the intelligence came not from the platform itself but from the decades of domain knowledge they encoded into their data model, their feature engineering, and their semantic catalog. The technology is Databricks. The value is in how they organized human knowledge about manufacturing, supply chain, and customer behavior into a queryable, governable form.

That's a lesson that gets lost when we talk about "AI transformations." The transformation isn't the AI. The transformation is the organizational work of capturing what the business actually knows and making it machine-accessible. The AI is just the interface for retrieving it.

What Other Enterprises Can Realistically Adopt

The pattern that's immediately portable: domain-specific semantic layers that translate business terminology into data queries. GM built a catalog of business concepts — "vehicle health status," "dealer performance tier," "supply chain risk score" — that map to specific tables, features, and calculations. This is Unity Catalog plus metadata work, and any enterprise can do it. The technology cost is low. The organizational cost — getting business and engineering aligned on canonical definitions — is high. But it's the work that makes natural language querying actually work.

The second portable pattern: tiered data access that reflects organizational trust levels. Manufacturing engineers get access to production line data. Dealer partners get access to inventory and incentive data. Customer analytics teams get access to anonymized behavioral data. These are separate Unity Catalog schemas with separate permission policies, governed centrally. The tier model is not complex — the discipline to maintain it consistently is the hard part.

My Critique: Factories Need Culture, Not Just Pipelines

Here's what I noticed wasn't said in the presentation, but which I've seen repeatedly in large enterprise engagements: the technical architecture works because there's an organizational culture behind it that takes data quality seriously. GM has teams whose job it is to define data standards, enforce them, and escalate when production systems violate them. That governance culture is the load-bearing element. You can copy the architecture. You cannot copy the culture in a conference session.

The enterprises that come back from a conference inspired by GM's architecture and try to implement it without building the governance culture first will fail at the same place everyone fails: the data quality layer. The Insights Factory runs on insights. Insights require trustworthy data. Trustworthy data requires organizational accountability. No amount of Databricks configuration substitutes for that. As always, I'm here to help.