{"id":9419,"date":"2026-10-27T11:26:41","date_gmt":"2026-10-27T11:26:41","guid":{"rendered":"https:\/\/silvybrand.com\/?p=9419"},"modified":"2026-10-27T11:26:41","modified_gmt":"2026-10-27T11:26:41","slug":"gm-sterling-anderson-interview-robots-ai-autonomous-data-privacy","status":"publish","type":"post","link":"https:\/\/silvybrand.com\/?p=9419","title":{"rendered":"Sterling Anderson doesn\u2019t think humanoid robots should be building cars"},"content":{"rendered":"


\n<\/p>\n

\n
\n

At a splashy event in New York City last week, General Motors unveiled its new tech roadmap<\/a> centered on AI-driven vehicle development, advanced battery tech, high-powered car computers, and autonomous driving.<\/p>\n<\/div>\n

\n

Some of this was old news: We already knew the automaker was developing hands-free, eyes-off driving automation and had been prototyping new battery chemistries. In a sense, the real purpose of the event was to showcase how all these pieces fit together. With its new \u201cintelligence-defined vehicle\u201d paradigm, GM is banking on artificial intelligence, centralized computing, and virtualized engineering to cut vehicle development timelines in half, aiming to compress a typical four- to five-year process down to just over two.<\/p>\n<\/div>\n

\n

Yet, this high-tech overhaul arrives against a backdrop of steep industry headwinds and razor-thin margins for error. GM\u2019s aggressive pivot comes as the automaker faces a wave of hyperefficient Chinese EV makers that are aggressively expanding globally. At the same time, softening EV demand in the US has forced GM to recalibrate its electrification hopes, balancing multibillion-dollar investments in next-generation battery plants with the ongoing costs of software development.<\/p>\n<\/div>\n

\n

To be sure, for GM to bet its future on unproven software architectures and autonomous technology is a high-stakes gamble: If these complex AI systems falter or if development hits delays, GM risks burning through massive amounts of money while falling further behind agile rivals (like Tesla) that were built as software-first companies from day one.<\/p>\n<\/div>\n

\n

After the event, I sat down with Sterling Anderson, GM\u2019s chief product officer, to talk about the company\u2019s risky new ventures as well as how he plans to steer a century-old Detroit giant through an increasingly fast, software-driven world.<\/p>\n<\/div>\n

\n

This interview has been lightly edited for length and clarity.<\/em><\/p>\n<\/div>\n

\n

So this was quite the massive announcement \u2014 just lots of disparate pieces. Is there a unifying theme here, would you say? And if so, what do you think it is?<\/strong><\/p>\n<\/div>\n

\n

The car\u2019s getting smarter.<\/p>\n<\/div>\n

\n

That\u2019s it. I think so. Your vehicle is becoming a trusted, intelligent companion, and we\u2019re doing that in a variety of ways. I think I might be one of the only guys who gets as excited as I do about what we\u2019re doing in the development process and making that faster and better.<\/p>\n<\/div>\n

\n

I don\u2019t know how many people are going to come away with that takeaway in quite the spirit that I think it merits, but the level of tests and performance optimality that we can achieve when we can spin design decisions hundreds of times \u2014 that previously would have accommodated one \u2014 is huge. It\u2019s really huge. I\u2019ve been asked now by two folks I\u2019ve met afterwards, \u201cHey, what about safety, and does speed come at the cost of safety?\u201d The way we are getting speed is by virtualizing tests in a way that allows us to improve safety. Historically, I would have been able to afford X prototypes that I could send to crash tests, and it took me six months. Now, I kick off thousands of tests in the virtual world that give me feedback much quicker. So I get speed, and I get safety, better coverage, and better understanding. There\u2019s a lot of cake being eaten, too, in this process.<\/p>\n<\/div>\n

\n
\n

\u201cI kick off thousands of tests in the virtual world that give me feedback much quicker.\u201d<\/p>\n

\u2014 Sterling Anderson<\/cite><\/div>\n<\/div>\n

\n

What kind of AI models are you using? I know you talked about how data is sort of the currency here, so obviously there\u2019s a lot that you\u2019re pulling from your own customers, but there\u2019s a range of products out there. What\u2019s the dividing line between what to look for outside the company versus what to pull from inside?<\/strong><\/p>\n<\/div>\n

\n

It\u2019s a good question. It depends on what we\u2019re doing with it. In many cases, the transformer-based foundation models enable some of the generative design stuff I was talking about \u2014 we have enough data in-house based on decades of design files, analyses, etc., that we can get a pretty well-trained system to express our data well. But we have access to \u2014 and anybody has access in many cases to \u2014 a lot of data that informs us. The co-training of these models with data that exists beyond GM\u2019s walls tends to make them better. So we do it with all of them.<\/p>\n<\/div>\n

\n

You\u2019ve talked about moving from deterministic code to probabilistic AI that learns from the structure of the world and from the data. How are you specifically embedding these models into the vehicles? How much is run locally versus pulling from the cloud?<\/strong><\/p>\n<\/div>\n

\n

For any safety-critical functionality, the inference is done onboard because we can\u2019t deal with latency, possible dropouts, or whatever else. Some of these examples you saw from the team earlier today, like the OnStar AI interactions, aren\u2019t safety-critical. You probably noticed, given the latency, that you had some round-tripping happening there because we don\u2019t need to run those all onboard. Now, we\u2019re thinking about distilling them down into onboard models just to deal with the latency, but that\u2019s an on-the-edge user experience element, not a core safety consideration.<\/p>\n<\/div>\n

\n

You talked a little bit during your presentation about how big GM is, which gives you advantages with data, but also a lot of inertia. Back in 2019, GM President Mark Reuss talked about moving toward the \u201cdigital brain\u201d of the vehicle, and in 2021 you talked about Ultifi. Have things sped up now? Are you on the glide path at this point?<\/strong><\/p>\n<\/div>\n

\n

Yeah, and a big enabler of it is that common electrical system, including centralized compute. Historically, I know of very few killers to software speed quite like complexity. The moment a software team has a very large set of deployment targets that don\u2019t share a common baseline is the moment you slow that team down enormously.<\/p>\n<\/div>\n

\n

Rolling this out across our entire portfolio is specifically to enable software speed so we don\u2019t have to continue to support vehicles of various configurations. As that hardware set rolls out, software engineers will suddenly be able to operate like they would if they were in a company with two models in production, which they just haven\u2019t been able to in history.<\/p>\n<\/div>\n

\n

GM is unique in having this huge portfolio of brands with distinct identities. How do you decide what to standardize across every vehicle versus ensuring a Buick remains a Buick and a GMC Sierra remains unique?<\/strong><\/p>\n<\/div>\n

\n

It\u2019s a combination of things. First, the essence of each brand tends to manifest in aesthetics and interaction models. Aesthetics is something you can effectively skin via design, both in digital interfaces and physical sheet metal. We already do a fairly good job of commonizing the under-the-skin componentry because why wouldn\u2019t we? For a given segment of vehicle, there\u2019s a particular ride quality that tends to be best received by everybody.<\/p>\n<\/div>\n

\n

Our T1-2 platform<\/a> for our next-generation trucks is common between brands. Where you\u2019ll see us differentiate is in the feature set, the aesthetics, and interaction patterns we effectively skin segment by segment. Sales has dedicated brand channels, but engineering is all one organization. That ensures we don\u2019t ship heterogeneous, suboptimal cars for different brands just because a team that was slightly worse was assigned to one brand or another. I want our engineering team focusing all of their effort on what is the absolute best suspension, powertrain, or drive unit, and then we scale it across the portfolio.<\/p>\n<\/div>\n

\n

Speaking of autonomy, we have autonomous vehicles on the road today \u2014 Waymo, Zoox, and Tesla Cybercabs. What are the challenges GM still needs to solve to get to a point where someone can take their eyes off the road comfortably and safely?<\/strong><\/p>\n<\/div>\n

\n

When you say \u201ceyes off,\u201d you mean autonomous?<\/p>\n<\/div>\n

\n

Autonomously, yes. Hands off, mind off, eyes off. But at the same time, you wouldn\u2019t be recommending people go to sleep in their vehicles yet?<\/strong><\/p>\n<\/div>\n

\n

We are designing them such that should they fall asleep, it won\u2019t be unsafe, because we don\u2019t have the luxury of ensuring that they\u2019re paying attention. The reason you won\u2019t hear me use terms like \u201ceyes off\u201d is because I hear people use those terms in reference to nonsensical levels of automation. What do you think your mind is doing when your eyes are on your phone? Where\u2019s your mind? Let\u2019s not draw these nonsensical distinctions. If you believe that your driver assistance system is super capable, you are already at risk of complacency \u2014 at risk of treating it like it\u2019s an autonomous system. Our philosophy is: If we\u2019re going to design an autonomous system, we\u2019re going to actually design an autonomous system. The path of incrementalism that we\u2019ll take will work for personal ownership, not the one that worked for robotaxis. Instead of regionally specific, speed-limited settings, we\u2019re going to go toward road-type specific settings and expand outward from there. They both converge in the same place \u2014 self-driving everywhere at all times \u2014 but take different paths to get there.<\/p>\n<\/div>\n

\n

With robotaxis today, we see problems around nuisance situations \u2014 like blocking intersections or emergency vehicles. Do you feel personal autonomy, as GM defines it, solves some of that because the driver remains an option to fall back on?<\/strong><\/p>\n<\/div>\n

\n

The form of the fallback matters. We will not fall back in a safety-critical dynamic situation. It\u2019s just not reasonable to do that. What we can do in a non-safety-critical situation \u2014 where the vehicle is stopped and something odd is happening \u2014 is hand it back to the driver once we\u2019ve reached a safe place. Having a human in the loop is very useful for that.<\/p>\n<\/div>\n

\n

How do you structure that handoff to avoid driver complacency?<\/strong><\/p>\n<\/div>\n

\n

We\u2019re not handing back dynamically. This is not an exchange of \u201cyou drive, now I\u2019ll drive, oops, I don\u2019t recognize this.\u201d This is not Level 3. In the same way you put a robotaxi in a bounded region, we will put personally owned autonomous vehicles on a particular road.<\/p>\n<\/div>\n

\n

When on that road, we will take the human to their destination and give a graceful countdown \u2014 like, \u201cHey, you\u2019ve got 10 minutes left in this ride.\u201d If they take over preemptively, great. Should they not take over, the system brings the vehicle to a safe state off the off-ramp and says, \u201cI told you 10 minutes ago to take over. We\u2019re stopped, and I\u2019m not going any further.\u201d<\/p>\n<\/div>\n

\n

You have to operate under the assumption that bad actors will try to abuse the system \u2014 sitting in the back seat, like we\u2019ve seen with Tesla users.<\/strong><\/p>\n<\/div>\n

\n

I get far more nervous when misuse happens in the context of a driver-assist system that wasn\u2019t designed to handle every situation. If the vehicle accepts control, our system is designed to deal with more situations that can be thrown at it in that circumstance. So my anxiety level declines dramatically.<\/p>\n<\/div>\n

\n

Features like OnStar AI ask for access to calendars, emails, and personal data. Given past FTC orders regarding GM selling customer data to third-party brokers without permission, how do you ensure customers can trust you with this data?<\/strong><\/p>\n<\/div>\n

\n

Privacy has to be designed in. With end-to-end encryption, we don\u2019t see your data; you grant permission to an assistant that performs better with context. Data is only available to us at an aggregate, anonymized level. At an individual level, it is encrypted and under your control.<\/p>\n<\/div>\n

\n

When you buy a car, going through dozens of terms and conditions leads to \u201cclick, click, click\u201d without reading, which does a disservice to trust. We have dramatically simplified these authorizations down to a couple of clear choices that explain why the car needs data \u2014 like reading your calendar for smart routing. You can revoke permission, delete your data, or port it out at any time. You alluded to trust, which is foundational. Decisions made in the past by people who no longer work for this company have an overhang, but that\u2019s not the company we are today. We earn that trust back by designing the architecture so that even if someone made a bad decision internally, the system technically wouldn\u2019t allow them to access raw user data.<\/p>\n<\/div>\n

\n

And the way we do that is by designing it. Look, even if we had someone stupid work for us again and do something like this, they couldn\u2019t. They wouldn\u2019t be able to access it.<\/p>\n<\/div>\n

\n
\n

\u201cLook, even if we had someone stupid work for us again and do something like this, they couldn\u2019t. They wouldn\u2019t be able to access it.\u201d<\/p>\n<\/div>\n<\/div>\n

\n

AI is cutting vehicle development times, but we\u2019re also seeing hype around factory automation and humanoid robots from companies like Tesla and Rivian. Is GM heading in that direction?<\/strong><\/p>\n<\/div>\n

\n

If you want to be perceived as a robotics player these days, it seems you have to have a humanoid robot that does backflips. It\u2019s weird. Advocacy for humanoids often comes from people who historically advocate for first-principles engineering, but humanoids are not born from first principles. They put form over function. The logic assumes the human form factor is optimal for a factory floor, but this form factor evolved to run away from lions on the African savanna! Production environments weren\u2019t built for human forms any more than roads built for horses meant cars should have four legs. The most valuable real estate in a factory is the floor. Having bumbling humanoid robots clamoring in and out of vehicles is not where you start. You start with form factors that look alien \u2014 like an octopus hanging from a gantry that reaches into a moving vehicle line. We\u2019re ignoring the \u201creligion\u201d of humanoids and focusing on underlying AI intelligence that can operate various specialized robot form factors for specific tasks.<\/p>\n<\/div>\n

\n

Is GM building these robotics systems itself?<\/strong><\/p>\n<\/div>\n

\n

We already are. We actively work with heavy machinery suppliers like Fanuc<\/a>, but we are actively developing many of our own solutions.<\/p>\n<\/div>\n

\n

People are excited about cars getting smarter, but they also want them to be cheaper. How do these announcements lead to more affordable options?<\/strong><\/p>\n<\/div>\n

\n

LMR (lithium manganese rich) battery chemistry is a huge part of this. It delivers a range close to high-nickel packs at a cost closer to LFP. On a per-range basis, a customer will be able to buy a fourth-gen GM EV for less money than a competitor\u2019s profitable model without relying on subsidies.<\/p>\n<\/div>\n

\n

Additionally, commonizing our electrical architecture reduces wiring length and vehicle mass dramatically, making cars inherently more affordable. Virtualizing development cuts prototype costs, allowing vehicle business cases to clear at lower retail prices. This applies to ICE vehicles and hybrids as well, not just EVs.<\/p>\n<\/div>\n

\n

Will this intelligence lead to higher subscriptions and paywalls?<\/strong><\/p>\n<\/div>\n

\n

Capability advances inevitably over time without raising financial costs \u2014 the device in your lap does far more than computers years ago for less money. Regarding subscriptions: I\u2019m here to build great products. If customers like paying for services like a lease, let them; if not, don\u2019t force them.<\/p>\n<\/div>\n

\n
\n

\u201cThe most valuable real estate in a factory is the floor. Having bumbling humanoid robots clamoring in and out of vehicles is not where you start.\u201d<\/p>\n<\/div>\n<\/div>\n

\n

[GM spokesperson Chaiti Sen: For immediate features like OnStar AI, it will be included in our basic package. We aren\u2019t going to paywall core baseline experiences or hand customers a bare \u201ctin shell.<\/em>\u201d]<\/p>\n<\/div>\n

\n

For your sensor suite, you\u2019re using cameras, radar, and lidar. Do you see that remaining in perpetuity, or could you eventually scale back to a vision-only approach like Tesla?<\/strong><\/p>\n<\/div>\n

\n

If you scale back to vision-only, physics suggests you\u2019ll be in trouble in certain situations. Radar is so cheap that dropping it doesn\u2019t make sense \u2014 dropping it is a weird religious stance that ignores physics. Lidar operates on a similar wavelength to visible light and helps co-train camera systems to get better faster. Cameras can\u2019t see through dense fog or measure instantaneous velocity like radar can. Having a multisensor suite provides obvious safety advantages that physics simply demands.<\/p>\n<\/div>\n

Follow topics and authors<\/strong> from this story to see more like this in your personalized homepage feed and to receive email updates.<\/span><\/p>\n