Lo que realmente se necesita para crear software automotriz impulsado por IA en 2026

El coche que compras hoy viene con una hoja de ruta, y todo se basa en el software. Las funciones que incluye son la versión 1.0, pero el producto final se define a lo largo de los próximos cinco años de actualizaciones. Este cambio transforma el desarrollo de software automotriz, pasando de ser una tarea de ingeniería puntual a una disciplina de producto continua, más cercana al SaaS que a la fabricación.

La IA también se ha convertido en una parte crucial del sistema: modelos que realizan inferencias en el extremo de la red, asistentes que gestionan las interacciones dentro del habitáculo o sistemas que predicen un componente defectuoso antes de que el conductor note algo anormal.

Si actualmente estás definiendo el alcance de un proyecto de IA para el sector automotriz o evaluando si tu equipo actual puede llevarlo a cabo, este artículo abarca en qué consiste realmente el trabajo, desde la arquitectura y los estándares hasta la pila tecnológica y los puntos donde la mayoría de los proyectos encuentran dificultades.

Del hardware al software: Vehículos definidos por software

El término «vehículo definido por software» (VDS) se usa de forma imprecisa, pero su significado técnico es específico. Un vehículo tradicional distribuye funciones entre decenas de unidades de control electrónico (ECU) aisladas, cada una con firmware propietario y una comunicación mínima entre ellas. En cambio, un vehículo definido por software consolida esas funciones en plataformas informáticas centralizadas. Allí, el software controla el comportamiento del vehículo y se pueden implementar nuevas funcionalidades de forma inalámbrica (OTA) sin necesidad de modificar el hardware.

Ese cambio arquitectónico es de suma importancia para los servicios de desarrollo de software automotriz porque significa que:

• Las funciones del vehículo que antes requerían el cambio físico de la ECU ahora se pueden actualizar de forma remota.
• Las funcionalidades pueden monetizarse después de la venta mediante modelos de suscripción o de funciones bajo demanda.
• Un único equipo de software puede gestionar todo el ciclo de vida del vehículo, no solo la fase de preproducción.
• La lógica de reversión OTA se vuelve tan crítica como la propia actualización.

El mercado de vehículos definidos por software refleja la rapidez de esta transición. Según Fortune Business Insights, el mercado global de software para la industria automotriz alcanzó un valor de 36 mil millones de dólares en 2025 y se prevé que llegue a los 113 mil millones de dólares en 2034. El sector de vehículos definidos por software crece a un ritmo anual del 25-30%, lo que representa aproximadamente ocho veces el ritmo del mercado automotriz en general.

La siguiente etapa de esta evolución tiene un nombre: el vehículo definido por IA, o AIDV. Mientras que el SDV proporciona la base arquitectónica (computación centralizada, entrega OTA, capas de software modulares), el AIDV introduce la IA no como una característica de la aplicación, sino como una capa fundamental de la plataforma. El vehículo interpreta el contexto, aprende de los patrones de conducción y adapta su comportamiento en tiempo real. Esta distinción es importante para los equipos que trabajan actualmente, ya que diseñar una arquitectura AIDV desde el principio es un proyecto completamente diferente a simplemente añadir funciones de IA a una pila SDV existente.

Los 5 componentes principales del software de IA para la industria automotriz

El desarrollo de software automotriz para vehículos con inteligencia artificial implica cinco capas funcionales distintas. Cada una de ellas tiene su propia disciplina de ingeniería, que detallamos a continuación.

Sistemas ADAS y de percepción

El desarrollo de software para sistemas avanzados de asistencia al conductor (ADAS, por sus siglas en inglés) es donde se concentra la mayor parte del trabajo computacional. Los sistemas de procesamiento de datos reciben información de cámaras, radar, LiDAR y sensores ultrasónicos simultáneamente, y los algoritmos de fusión de sensores integran esos datos en un modelo coherente y en tiempo real del entorno del vehículo.

El desafío de ingeniería no radica solo en la precisión, sino en lograrla en condiciones no contempladas en los datos de entrenamiento. La lluvia nocturna, una señal de stop parcialmente oculta y un peatón que cruza entre camiones estacionados son obstáculos que los sistemas aprenden a partir de encuentros aleatorios y poco frecuentes. El desarrollo de software ADAS de nivel de producción requiere la cobertura de escenarios adversos, no solo un rendimiento de referencia.

En CES 2026, KPIT Technologies presentó un conjunto de herramientas de IA con capacidad de gestión, basado en IA generativa, diseñado específicamente para acelerar los ciclos de desarrollo de sistemas avanzados de asistencia al conductor (ADAS) y reducir los defectos en sistemas críticos para la seguridad. La tendencia es clara: la IA se utiliza ahora para desarrollar una IA más avanzada para vehículos.

Inteligencia artificial en el vehículo y cabina digital

La cabina digital es la capa de la arquitectura de IA que interactúa directamente con el usuario. Aquí es donde la IA integrada en el vehículo se manifiesta a través de asistentes conversacionales, ajustes personalizados, navegación predictiva e información contextual. Es también una de las áreas de mayor evolución de la arquitectura, impulsada por la integración de LLM y la transición hacia arquitecturas LLM integradas en el vehículo que pueden gestionar comandos en lenguaje natural para múltiples funciones del vehículo simultáneamente.

Para lograr una IA eficaz en vehículos, se requiere más que simplemente integrar un modelo de lenguaje complejo. Los requisitos de latencia para la interacción con el conductor se miden en milisegundos. Por lo tanto, los modelos deben funcionar de manera fiable en hardware periférico con recursos limitados. Además, el sistema debe adaptarse a la pérdida de conectividad, ya que el conductor aún se encuentra dentro del vehículo, independientemente de si la nube está disponible.

Mantenimiento predictivo y diagnóstico

El software de mantenimiento predictivo para automóviles monitoriza los datos de los sensores de los sistemas de propulsión, batería, frenos y suspensión para detectar anomalías antes de que provoquen fallos. Para los operadores de flotas y los fabricantes de equipos originales que implementan programas de vehículos conectados, esta es una de las aplicaciones de IA con mayor retorno de la inversión, ya que el coste de una avería imprevista casi siempre es superior al de una reparación preventiva.

Construir un sistema de este tipo implica mucho más que entrenar un modelo de clasificación con códigos de error. Es necesario diseñar una canalización de datos que transmita la telemetría de forma fiable desde el vehículo a la capa de inferencia, gestione las señales faltantes o con ruido y genere alertas útiles en lugar de puntuaciones de probabilidad que un equipo de mantenimiento no pueda utilizar.

Infraestructura de actualizaciones OTA

La tecnología FOTA (firmware-over-the-air) es uno de los aspectos menos llamativos de la arquitectura de software automovilística, pero resulta fundamental desde el punto de vista operativo. Un sistema OTA mal diseñado puede inutilizar vehículos a gran escala, generar riesgos de incumplimiento normativo o fallar de forma silenciosa, lo cual, en algunos aspectos, es aún peor.

La infraestructura OTA de producción para software automovilístico debe gestionar:

• Compresión de actualizaciones delta para minimizar el ancho de banda en redes móviles
• Firma y verificación criptográficas en todas las capas
• Implementaciones por fases con reversión automática en caso de fallo
• Cumplimiento de la norma UNECE R156, el estándar regulatorio internacional para actualizaciones de software OTA en vehículos

El 58 % de los conductores que recibieron actualizaciones OTA en 2025 no notaron ninguna mejora apreciable, según el estudio de fiabilidad de vehículos de JD Power. Esa cifra nos dice algo importante sobre la diferencia que hay entre lanzar una actualización y lanzar una buena actualización.

V2X y canales de datos de vehículos conectados

El software de los vehículos conectados gestiona la comunicación entre el vehículo y los sistemas externos, como la infraestructura, otros vehículos, las plataformas de gestión de flotas y los backends en la nube. Los protocolos V2X (vehicle-to-everything) permiten casos de uso que van desde la optimización de los semáforos hasta la coordinación para evitar colisiones.

El reto de ingeniería de datos en este caso es significativo. Un solo vehículo genera entre 25 y 100 GB de datos de sensores y telemetría por hora. Decidir qué procesar en el borde, qué transmitir y qué almacenar requiere un cuidadoso trabajo de arquitectura desde el principio, no como una optimización del rendimiento a posteriori.

Por qué esto es realmente difícil: los verdaderos retos del desarrollo de software para automoción

Los retos del desarrollo de vehículos definidos por software no se tratan lo suficiente en los contenidos de marketing relacionados con este ámbito. A continuación, enumeramos los problemas reales a los que se enfrentan los equipos, basándonos en nuestra propia experiencia de desarrollo.

La seguridad funcional no es documentación

La norma ISO 26262 es el estándar internacional para la seguridad funcional en el software de automoción. MISRA C es el conjunto de directrices de codificación que rige el desarrollo en C y C++ en sistemas críticos para la seguridad. AUTOSAR es el marco de arquitectura de software con el que la mayoría de las cadenas de suministro de los fabricantes de equipos originales (OEM) exigen el cumplimiento.

El error que cometen la mayoría de los equipos de software no automovilísticos es tratar estos aspectos como casillas de cumplimiento, es decir, algo de lo que se encarga el equipo de control de calidad al final. En realidad, los requisitos de seguridad funcional determinan cómo se diseña el sistema, cómo se escribe y revisa el código, cómo se realizan las pruebas y cómo se documenta cada decisión de diseño.

No se trata de una capa que se añade sobre el software terminado, sino de una restricción que impregna todas las decisiones de ingeniería desde el primer día. El proceso de desarrollo de software para el sector de la automoción de un componente crítico para la seguridad implica un análisis de peligros y una evaluación de riesgos (HARA) durante la fase de diseño, pruebas de software-in-the-loop y hardware-in-the-loop, y una trazabilidad exhaustiva desde los requisitos hasta los casos de prueba. Esto no es opcional, y no se puede acelerar más allá de cierto punto.

Las limitaciones de la computación en el borde son reales

Los modelos de IA de gran tamaño funcionan sin problemas en las GPU de la nube. Sin embargo, no funcionan con la misma facilidad en el hardware de computación integrado en la mayoría de los vehículos de producción. El software automovilístico integrado para aplicaciones de IA requiere la compresión y cuantificación de los modelos y, en muchos casos, entornos de ejecución de inferencia diseñados específicamente, como ONNX o TensorFlow Lite, optimizados para el SoC concreto del vehículo.

El equilibrio entre la precisión del modelo y la latencia de inferencia en hardware con limitaciones es uno de los retos de ingeniería más importantes en el desarrollo de la IA para el sector automovilístico. Un error en este equilibrio da lugar a sistemas que son demasiado lentos para ser seguros o demasiado imprecisos para ser útiles.

Etiquetado de datos a escala automovilística

Entrenar un modelo de percepción para ADAS no es un proyecto de fin de semana. Los conjuntos de datos de producción para el desarrollo de software ADAS comprenden millones de fotogramas etiquetados en diversas condiciones de iluminación, ubicaciones geográficas, condiciones meteorológicas y casos extremos. El propio proceso de etiquetado supone un reto de ingeniería en cuanto a consistencia, control de calidad y herramientas para gestionar las anotaciones a gran escala, todo lo cual requiere una inversión específica.

Muchas empresas inician un proyecto de IA para el sector automovilístico sin comprender esto, descubren el problema de los datos a los seis meses y acaban comprometiendo la calidad del modelo o incumpliendo los plazos.

Divergencias normativas entre mercados

El cumplimiento normativo en el desarrollo de software para la industria automovilística varía según la región de formas que influyen en la arquitectura. Las normativas de la UNECE de la UE (R155 para ciberseguridad, R156 para actualizaciones OTA) establecen requisitos que difieren de las directrices de la NHTSA de EE. UU. y de las normas GB chinas emergentes.

Si se está desarrollando software para un vehículo que se venderá en múltiples mercados, esto debe tenerse en cuenta en el diseño del sistema, ya que adaptar el cumplimiento normativo a múltiples mercados resulta costoso.

La pila tecnológica de IA para automoción

Las opciones de la pila tecnológica de IA para automoción son más limitadas que en el desarrollo de software general. Así es como se presenta el panorama real en 2026.

Capa del sistema operativo:

• Automotive Grade Linux (AGL) para los ámbitos de infoentretenimiento y no relacionados con la seguridad
• BlackBerry QNX para sistemas en tiempo real críticos para la seguridad (QNX y Vector Informatik firmaron un memorando de entendimiento en junio de 2025 para desarrollar conjuntamente una plataforma SDV fundamental)
• AUTOSAR Adaptive para middleware orientado a servicios en unidades de cálculo de alto rendimiento
• AUTOSAR Classic para dominios tradicionales basados en ECU, donde permanece integrado

IA e inferencia:

• PyTorch y TensorFlow para el entrenamiento de modelos
• TensorFlow Lite y ONNX Runtime para la inferencia en el borde en los SoC de los vehículos
• CUDA para la inferencia acelerada por GPU, cuando los presupuestos de computación lo permitan
• LLM específicos de dominio ajustados con precisión sobre datos de interacción automovilística para asistentes a bordo

Comunicación:

• SOME/IP y DDS para la comunicación de servicios intravehiculares
• MQTT y AMQP para canalizaciones de telemetría en la nube
• Pilas V2X dedicadas (DSRC, C-V2X) para la comunicación con la infraestructura

Nube y backend:

• Tanto AWS como Azure ofrecen SDK específicos para el sector automovilístico y servicios para vehículos conectados
• Plataformas de gestión OTA, incluyendo Uptane (el marco de seguridad utilizado por la mayoría de los sistemas OTA en producción)

Lenguajes:
C y C++ para dominios integrados y críticos para la seguridad (con herramientas de cumplimiento MISRA)
Rust está ganando terreno en trabajos integrados donde la seguridad de la memoria es importante y la sobrecarga de C es aceptable
Python para canalizaciones y herramientas de aprendizaje automático (no en el tiempo de ejecución del vehículo)

Cómo es realmente un equipo competente de desarrollo de software de IA para el sector de la automoción

La contratación de desarrolladores de software para el sector de la automoción es donde los proyectos suelen fracasar con mayor frecuencia, ya que se lleva a cabo sin comprender las particularidades del sector. Así es como, al cabo de seis meses, te encuentras con un equipo que escribe código Python de forma excelente, pero que nunca ha trabajado bajo la norma ISO 26262 y no tiene ni idea de qué es AUTOSAR.

Un socio de desarrollo de IA para el sector automovilístico capaz de entregar un trabajo apto para producción necesita:

• Ingenieros de software embebido que hayan trabajado con sistemas operativos en tiempo real
• Ingenieros de IA y ML con experiencia en la implementación de modelos en hardware periférico, no solo en su entrenamiento
• Ingenieros de seguridad funcional que comprendan la norma ISO 26262 a nivel de arquitectura
• Un equipo de pruebas de software de control de calidad que conozca la diferencia entre las pruebas de software y la validación de software para el sector automovilístico

Cómo empezar a crear software de IA para automoción sin perder seis meses

La forma de crear software para automoción basado en IA suele plantearse como una gran cuestión de arquitectura. En la práctica, el punto de partida más eficaz es más concreto: elegir un problema bien delimitado, desarrollarlo con calidad de producción y utilizarlo para desarrollar las herramientas, los procesos y la comprensión del equipo que requiere un programa de mayor envergadura.

Por ejemplo, el software de mantenimiento predictivo para automoción suele ser un buen primer proyecto. Los datos existen (ya se recopila telemetría de los vehículos en la mayoría de los vehículos modernos), el retorno de la inversión es medible (reducción del tiempo de inactividad no planificado) y las implicaciones de seguridad son menores que en los sistemas de percepción o ADAS, lo que significa que se puede avanzar más rápido mientras se fortalece la capacidad organizativa para los procesos de seguridad funcional.

Algunas cuestiones que vale la pena decidir en las dos primeras semanas, no en el sexto mes:

• ¿Inferencia en el borde o en la nube?
  Esto determina los requisitos de hardware, la arquitectura de latencia y las hipótesis de conectividad para todo el proyecto.
• ¿Qué clasificación de seguridad se aplica?
  La norma ISO 26262 tiene niveles ASIL de A a D. Comprender en qué nivel se sitúa su caso de uso determina qué parte del proceso de seguridad necesita y qué herramientas son imprescindibles.
• ¿OTA desde el primer día?
  Incorporar la capacidad OTA en una pila de software de vehículos que no fue diseñada para ello resulta caro. Si la hoja de ruta del producto incluye actualizaciones posteriores al despliegue, estas deben incluirse en la arquitectura inicial.

Aquí es donde la fase de descubrimiento justifica su coste. En la IA para automoción, una decisión arquitectónica errónea en la segunda semana supone una corrección de seis meses en el octavo mes.

¿Está definiendo el alcance de un proyecto de IA para automoción? Llevamos suficiente tiempo en este sector como para saber qué decisiones son importantes en la primera semana y cuáles parecen urgentes pero no lo son. Póngase en contacto con Redwerk hoy mismo y hablemos de cómo desarrollar su producto.

FAQ

Vea cómo ayudamos a Mass Movement a unir activos con JB Hunt, lo que resultó en un crecimiento de ingresos de 2.740 millones de dólares

Este campo es obligatorio. no es un correo electrónico comercial

Consulta el caso práctico