OnStar AI Assistant Transparency Overview

OnStar AI Assistant is GM’s next-generation, in-vehicle AI companion, a voice-first experience that gives drivers and passengers a natural, hands-free way to interact with their vehicle. Powered by large language models (LLMs) and deeply integrated with vehicle systems, OnStar AI Assistant understands conversational language, answers questions and takes action, all without requiring drivers to learn specific commands or take their eyes off the road. For example, you can ask the assistant to adjust the cabin temperature while merging onto the highway, get a walkthrough of how a feature works by asking, “how does one-pedal driving work?”, or ask it to find the nearest charging station and start navigation there, without lifting a finger from the wheel.

OnStar AI Assistant was built in-house by GM, not by a third-party voice platform, so that it can be deeply integrated with GM vehicle features, grounded in accurate vehicle information and designed from the ground up around the realities of the driving environment. The assistant is not a general-purpose chatbot adapted for the car; it was purpose-built for the vehicle context, where driver attention is a finite and precious resource.

This transparency artifact is written for people who are comfortable with AI and software systems and want a substantive, credible account of how OnStar AI Assistant works and where its limits are, without research-paper depth. That audience includes technology journalists, AI and automotive policy experts, researchers and practitioners evaluating in-vehicle AI, and ecosystem partners assessing how GM designs and governs an assistant experience. It is not written primarily for first-time users in the vehicle, for customers seeking a support FAQ or for specialists needing full evaluation methodology and release-decision detail.

OnStar AI Assistant was built to make interacting with the vehicle more convenient, through natural, conversational interaction rather than only menus, touchscreens and button sequences. The best moments in the car are the effortless ones, and the product objective was to build a GM-branded AI companion that is deeply integrated with the vehicle and OnStar services so drivers can control their environment, get answers and stay connected with less friction. This is not a general-purpose assistant that happens to sit in a car. Every capability decision, interaction pattern and design constraint was made for the in-vehicle context, where the experience should feel natural, useful and as effortless as possible.

Because the assistant operates in a moving vehicle, the team designed it from the start with the automotive context as the primary lens. Response length, confirmation behavior, what the assistant will and will not attempt to answer while the vehicle is in motion — all of it was shaped by the recognition that being genuinely helpful here means knowing when to redirect and when to stay out of the driver’s way entirely.

From the first architecture decision, GM framed OnStar AI Assistant as a product designed with safety in mind. Legal, privacy and responsible-AI constraints such as consent and disclosure experience, hard content policy boundaries, restrictions on safety-related driving guidance and emergency-handling constraints were all built from the start. The assistant also cannot reach safety-critical vehicle systems by design, reflecting a deliberate architectural decision to keep AI voice control above the vehicle’s functional-safety boundary.

OnStar AI Assistant is designed and tested to handle the following categories of requests:

Control vehicle features with natural language. Users can adjust temperature, fan speed, seat heat and ventilation, steering wheel heat, air conditioning, defrost (front and rear), one-pedal driving mode, dome lights, glovebox open and other in-vehicle controls by speaking naturally.

Get navigation assistance. Users can start navigation to an address, a named place, saved home or work locations or a free-form search query without touching the screen. The assistant can also answer questions about time and distance remaining mid-route and help locate nearby destinations.

Manage media and audio. Users can play music on streaming apps, switch audio sources, adjust volume and tune to radio stations by speaking, including using natural descriptions rather than exact station names or track titles.

Handle calls and messages. With the user’s consent, the assistant can read incoming messages aloud, send replies and place and manage phone calls, enabling drivers to stay connected without picking up their phone.

Learn about their vehicle. Users can ask how features in their vehicle work and receive answers.

Ask general questions and have brief conversations. Users can ask factual questions, hear a story or have a short open-ended conversation.

Medical, legal, financial and professional advice. The assistant is designed to recognize requests in these domains and redirect rather than attempt to answer, because errors carry serious real-world consequences, and the assistant is not qualified to provide such advice.

Safety-critical driving guidance. The assistant will not answer questions like “how fast can I take this curve?” or “can I drive with this warning light on?”. These requests are declined with redirection to appropriate resources.

Autonomous or agentic vehicle operations. The assistant takes explicit user-directed actions only; it does not initiate vehicle changes on its own.

Emergency services. The assistant is not an emergency service and does not replace 911 or the OnStar Emergency Advisor service. It will direct users to call emergency services or press the red emergency button when appropriate but does not serve that function itself.

The AI components of OnStar AI Assistant, including the on-device natural language understanding model and the cloud-hosted language model, may reflect patterns and biases present in the data they were trained on. Despite GM’s investment in system-level guardrails, and performance and quality evaluations, AI systems are probabilistic rather than deterministic. This creates a residual risk that some responses will be inaccurate, unexpected or imperfect in ways that cannot be fully anticipated in advance. Some of the ways those limitations may manifest are described here:

Speech recognition accuracy. The quality of the assistant’s speech recognition can be affected by background noise, fan and road noise at highway speeds, accents, speaking rate and non-native phrasing. In degraded acoustic conditions, the system may misrecognize words, produce incorrect transcriptions or fail to activate. GM tests ASR performance across a range of acoustic environments and voice profiles, but real-world conditions will introduce variation that testing cannot fully anticipate.

Intent misclassification. The on-device natural language understanding model is intentionally compact. It is designed to run at low latency without a network connection, which requires making tradeoffs in model size. As a result, it can misclassify ambiguous, unusual or multi-step requests. When the on-device model’s confidence is low, the system routes to the cloud language model for disambiguation, which improves accuracy at the cost of added latency.

Information accuracy and grounding. Vehicle education responses are grounded in the official Owner’s Manual for the vehicle’s make, model, year and region, not the individual VIN. This significantly reduces, but does not eliminate, the risk of inaccurate information. Because manuals are authored for configuration families rather than specific VINs, there may be edge cases where a particular vehicle’s equipment or behavior differs from what is described. In addition, if vehicle behavior changes after delivery (for example, via a software update), the assistant’s responses will only reflect that change once the underlying content has been revised and republished. For general knowledge responses, the assistant draws on the language model’s training data, which may be incomplete, outdated or imperfect. Users should verify information before acting on it, particularly in high-stakes situations.

Connectivity dependence. Capabilities that require the cloud language model, including general knowledge responses and intent disambiguation, are unavailable when the vehicle lacks connectivity. In low-connectivity environments, features will degrade to on-device handling or will not be available until connectivity is restored. The assistant will indicate when it cannot complete a request due to connectivity.

Language support. The speech recognition and natural language understanding pipeline supports English only. Requests in other languages will not be correctly understood, and the assistant will not attempt to detect or switch languages automatically. 

No real-time audio or emotional context. The assistant receives a text transcript of the user’s speech, not raw audio, and therefore has no access to vocal tone, speaking pace or emotional affect. It does not attempt to infer the user’s emotional state from their voice and cannot detect distress signals that are conveyed through tone rather than words.

Memory is limited. The assistant only retains conversational context for the last five turns; earlier turns are not available.

OnStar AI Assistant uses Google’s Gemini family of models, accessed through Google Vertex AI on GM’s own cloud environment, for the generative language components of the experience under a contractual agreement that includes data protection obligations specific to GM’s automotive use case. The specific model(s) in production may change over time, including newer Gemini versions or other foundation models. For information about OnStar’s broader privacy practices, see the OnStar Privacy Statement. To learn more about the data used to train the foundation models that power OnStar AI Assistant, see the following resources:

• Google Gemini Model Card
• Google Cloud Vertex AI Responsible AI Practices
• Google Transparency Center

OnStar AI Assistant invokes the Gemini model in two specific, bounded contexts: general knowledge and conversation, and intent disambiguation when the on-device model is uncertain. Using a cloud language model for these use cases lets GM match the nuance and breadth required for open-ended natural language to the right capability tier, while keeping the full set of vehicle control actions (HVAC, navigation, media, telephony and others) under a deterministic, on-device fulfillment layer that does not depend on a generative model at execution time.

The end-to-end speech recognition and on-device NLU pipeline are provided by Google’s Automotive AI Agent (AAA) framework via the Connected Car Assistant (CCA) SDK. GM authors the intent definitions, training data, state machine and fulfillment logic that run within that framework; Google provides the underlying model architecture, training tooling and runtime SDK.

Importantly, the Gemini model itself does not have agency or access to vehicle systems. It generates text responses based on GM’s system prompts, grounding context and the conversation state. All decisions about whether to execute a vehicle action, how to fulfill a command and whether a response is safe to deliver are made by GM’s orchestration and fulfillment layer, not by the model.

GM owns the product roadmap and designs the full assistant experience. Specifically, GM authors and maintains:

• The Knowledge Graph, the state machine that defines what the assistant can do, which intents are recognized, how multi-turn conversations stay on track and which capabilities route to the on-device model versus the cloud LLM
• The system prompts injected into every Gemini request at runtime, which define the assistant’s identity, response style, content boundaries, routing tokens and safety constraints
• The fulfillment engine, the Android code that validates, executes and confirms vehicle actions, media commands, navigation requests and productivity tasks
• The vehicle integrations that define how the assistant connects to each vehicle line, mapping its spoken or typed commands to the underlying Android Vehicle Hardware Abstraction Layer (VHAL) signals that control features such as climate, locks and lighting
• The data handling and privacy controls, what is logged, how logs are anonymized, what data is shared with Google and under what contractual restrictions, and the user consent flow

The assistant is designed to operate within a strictly bounded tool set. It cannot initiate arbitrary API calls, browse the internet freely or take actions that have not been explicitly authorized for voice control in the production build. Every capability the assistant has must be specifically added to the Knowledge Graph, implemented in the fulfillment layer and tested before it is enabled. This is a design choice as it keeps the assistant’s behavior predictable, auditable and consistent with what users and regulators can reasonably expect.

Every tool call goes through validation before and after execution. Before execution, the orchestration layer checks that the requested intent is in the authorized tool set for the current page/state and that the action payload is well-formed. After execution, the fulfillment layer checks the VHAL response for success or error codes and maps failures to appropriate spoken error messages (“That feature isn’t available right now”). The assistant does not silently fail or speculate about whether an action succeeded.

The guardrail architecture is enforced across the following categories that must be met before any release.

The assistant clearly discloses at first use that it is an AI, not a human, not a live OnStar Advisor and not an emergency service. This disclosure is presented in the setup experience before any voice interaction takes place, and requires user acknowledgment. A microphone activity indicator is shown visibly throughout every active voice session, so users always know when the assistant is listening and their audio is being processed.

The system is designed to detect and reject attempts to override its operating instructions. This includes: requests to “pretend” the assistant is a different system with different rules; attempts to embed instructions in the user’s speech that direct the assistant to ignore its safety guidelines; and role-play scenarios designed to elicit content the assistant would otherwise refuse. When such attempts are detected, the system declines and returns to normal operation without escalating or acknowledging the attempted bypass in a way that would encourage further attempts.

The assistant enforces a set of GM-specific content rules in addition to baseline safety policies. It does not provide or endorse safety-critical driving guidance that could be acted on while driving (e.g., speeds for specific road conditions, whether a warning light permits continued driving, how to bypass a safety feature). It will not praise competing vehicles. It applies a consequential-domain policy to medical, legal and financial questions, redirecting rather than attempting to answer, because errors in these domains carry disproportionate real-world risk.

For OnStar AI Assistant, “AI safety” and “automotive safety” are related but not identical. AI safety refers to questions such as harmful-content prevention, misuse resistance, privacy protection, data governance and whether the assistant stays within policy when generating or routing responses. Automotive safety refers to the engineering boundary around systems whose failure could directly cause physical harm, such as braking, steering, propulsion or crash-avoidance functions.

We designed the product with both in mind. On the AI side, we constrain outputs, reject unsafe requests, and test for jailbreaks, privacy leaks and unauthorized tool use. On the automotive side, we deliberately keep the assistant outside the vehicle’s functional-safety boundary: It does not have authority over safety-critical systems, and its enabled controls are limited to approved application-layer integrations rather than the vehicle’s safety-critical compute domains.

That design choice also shapes how we reduce distraction. The system is voice-first, designed for brief spoken exchanges, and constrained so that open-ended generative experiences do not turn into screen-heavy interactions while driving. We also restrict content that could encourage unsafe driving behavior or overconfidence in the vehicle’s capabilities.

The system detects a defined set of emergency-related and high-risk expressions (including self-harm and suicidal ideation phrasing) at the NLU intent level and routes them to a controlled handling path rather than a general decline message. This path directs users to emergency services as the appropriate resource. Users may also request a handoff to an OnStar Advisor and OSAI can transfer them accordingly.

Taken together, these controls are intended to make OnStar AI Assistant a bounded in-vehicle system rather than an open-ended chatbot with broad authority. The goal is not to remove all failure risk, as no AI system can do that, but to reduce risk through layered controls, limited authority, clear disclosure and design choices that respect both user trust and the realities of the driving environment.

GM evaluated OnStar AI Assistant across different dimensions before deployment. Those evaluations were used to support deployment decisions and are repeated at each release candidate.

OnStar AI Assistant undergoes performance and quality evaluations to assess whether it responds accurately, reliably and consistently across supported use cases. These evaluations focus on whether the assistant correctly understands user intent, completes requested tasks end-to-end, provides responses grounded in approved sources when applicable, and performs reliably across speech and interaction conditions. They also assess technical quality factors such as recognition accuracy, false rejects and false wakes, response latency and overall system stability.

These evaluations use end-to-end in-vehicle testing, bench testing and internal development tools. Methodologies include testing under representative driving, noise and connectivity conditions; and measuring task success, intent classification, hallucinations, completeness, word error rates, false reject and false wake rates and latency.

OnStar AI Assistant undergoes risk and AI safety evaluations to assess whether it behaves safely, responsibly and within GM policy under both normal use and adversarial conditions. These evaluations are designed to identify and reduce risks such as unsafe or misleading in-vehicle guidance, privacy leakage, identity spoofing, unauthorized or insecure tool use and other high-severity misuse cases. They also assess the system’s robustness to prompt injection, jailbreak attempts and other efforts to induce unsafe, out-of-bounds or policy-noncompliant behavior.

These evaluations use controlled human-in-the-loop workbench testing rather than in-vehicle testing and are structured to assess both unintended-consequence scenarios and cybersecurity-oriented edge cases. Methodologies include adversarial and edge-case prompting, structured review of refusal robustness and boundary-keeping, and testing for prompt injection, jailbreak resistance, privacy and security failures, and other harmful or noncompliant outputs. The evaluations are intended not only to identify whether a failure occurs, but also to assess its severity, reproducibility and potential liability exposure so that mitigations can be prioritized before broader release.

OnStar AI Assistant undergoes usability and safety evaluations to assess whether the experience is understandable, appropriately concise and suitable for use in a driving context. These evaluations focus on human factors and safety-related behaviors, including whether responses align with approved interaction patterns, whether on-screen elements support glanceability and low-friction use, and whether the assistant avoids behaviors that could increase distraction or create unsafe outcomes, such as overly long responses, guidance that encourages drivers to look away from the road, poor cancellation handling or unsupported control interactions.

These evaluations use usability testing and visual usability review for in-vehicle experiences, along with structured safety testing for edge cases and unsafe or policy-violating outputs. Methodologies include end-to-end in-vehicle testing under representative driving conditions, human review of whether interactions follow approved multimodal patterns, and controlled human-in-the-loop safety assessments designed to surface distracted-driving outputs, misleading in-vehicle guidance, poor interruption or context handling and other behaviors that may create safety risk.

OnStar AI Assistant undergoes customer acceptance evaluation to assess whether the experience is useful, understandable and satisfactory for drivers in realistic use. This evaluation focuses on how people perceive the assistant in genuine driving situations, including whether the interaction feels helpful and natural, whether responses meet user needs in context, and whether the overall experience supports confidence and trust in the product.

Customer acceptance is measured through a structured study with 100 GM testers outside of the immediate team interacting with the assistant in genuine driving contexts. The methodology combines real-world use of the assistant with structured feedback collection to understand satisfaction, perceived usefulness and areas where the experience does or does not meet expectations. Findings from this study are used to identify experience gaps, prioritize improvements and inform readiness decisions.

Current OnStar AI Assistant version is a first release, not a finished product. Some capabilities are intentionally limited compared to where the product will be in subsequent releases. The assistant will make mistakes. Intent misclassification, incomplete answers and responses that do not match exactly what the user intended will occur, especially for unusual or highly specific requests. GM’s commitment is to identify and improve these failure modes rapidly through the feedback and monitoring systems described below.

OnStar AI Assistant is designed to improve continuously through over-the-air updates. The vehicle does not need to visit a dealer to receive capability improvements, content updates, or safety and policy changes. This means guardrails can be tightened or refined after launch based on observed behavior and new vehicle control categories can be enabled after they complete evaluation.

GM’s goal is for OnStar AI Assistant to become the most trusted and capable in-vehicle AI companion in the industry, not by being the most powerful language model, but by being the one that is most deeply integrated with the vehicle, most reliably grounded in accurate vehicle information, most consistently safe in an automotive context, and most respectful of the driver’s attention and data. The platform being built is the foundation for a long-term capability roadmap, and GM intends to expand it responsibly, shaped by what customers actually need and what the evidence from evaluation and deployment shows to be safe.

How GM handles your data: GM’s Privacy Statement describes how personal information collected through OnStar AI Assistant and other GM services is used, stored and protected.

How OnStar works: OnStar’s website describes the services, plans and capabilities of the broader OnStar platform, of which OnStar AI Assistant is one component.

Google Gemini: For technical detail on the foundation model used in the generative components of this experience, refer to Google’s published model documentation.