🚗💻 Una automotriz japonesa en plena reestructuración acaba de hacer una de las apuestas de software más audaces de la industria — y casi nadie fuera de la prensa especializada se dio cuenta.

El 11 de mayo de 2026, en el Red Hat Summit de Atlanta, Nissan anunció que eligió Red Hat In-Vehicle Operating System como la base del ordenador central de su próxima generación de vehículos. Es un titular discreto que esconde una pregunta ruidosa: ¿por qué una compañía que está cerrando siete fábricas y recortando 20.000 puestos de trabajo gasta su energía en una distribución de Linux? La respuesta dice mucho sobre hacia dónde va la industria automotriz — y por qué otras automotrices, incluida Volkswagen, han gastado miles de millones intentando lo mismo y fracasando.

Qué se anunció realmente

El acuerdo, presentado por Kazuma Sugimoto, gerente general de la plataforma de software SDV de Nissan, durante una conferencia magistral del Red Hat Summit, es más acotado de lo que sugieren los titulares. Red Hat In-Vehicle OS — una distribución de Linux construida sobre Red Hat Enterprise Linux (RHEL) — se ubicará en el corazón del Central Vehicle Computer de próxima generación de Nissan, la única caja de alto rendimiento que reemplazará a las decenas de pequeñas unidades de control electrónico (ECUs) actualmente dispersas por un coche moderno.

Este ordenador es el cerebro de la "Nissan Scalable Open Software Platform" (SW PF), una arquitectura cloud-native que Nissan ha estado construyendo silenciosamente sobre AWS desde 2023. Sugimoto enmarcó la decisión como una división deliberada: las funciones críticas para la seguridad permanecen en sistemas certificados de tiempo real, mientras que todo lo que necesita actualizarse con frecuencia — asistencia al conductor, infoentretenimiento, personalización del vehículo — corre sobre contenedores Linux gestionados por el sistema operativo de Red Hat. Las actualizaciones se envían por aire (OTA), apuntando a funciones individuales, sin tener que recertificar el vehículo completo.

La asociación inserta ingenieros de Red Hat directamente dentro del pipeline de desarrollo de Nissan. Ese último detalle importa más de lo que parece, y volveremos a él.

¿Por qué Red Hat, específicamente? Tres razones duras

Razón 1: la certificación que casi nadie más tiene

En el software automotriz, la diferencia entre "Linux que puede hacer funcionar un coche" y "Linux que puede hacer funcionar un coche legalmente" equivale aproximadamente a 18 meses de papeleo y decenas de millones de dólares. La barrera es ISO 26262, el estándar de seguridad funcional cuyas calificaciones ASIL (de A a D) determinan qué puede hacer una pieza de código dentro de un vehículo.

En el tercer trimestre de 2025, el In-Vehicle OS de Red Hat se convirtió en la primera plataforma Linux de código abierto y certificación continua que pasó la prueba ISO 26262 ASIL-B como Safety Element out of Context. Suena a sopa de siglas, pero su implicación práctica es enorme: una automotriz ahora puede actualizar el sistema operativo de los coches ya entregados sin enviar el nuevo código a un proceso de certificación de varios años cada vez. Sin eso, las actualizaciones OTA — la premisa central de un SDV — colapsan en un agujero negro regulatorio.

Durante años, las únicas opciones realistas de OS en este nivel eran sistemas de tiempo real propietarios como QNX (excelente, pero cerrado y con licenciamiento por vehículo) o construir una compilación Linux propia que la automotriz tuviera que certificar ella misma. Red Hat cambió esa matemática.

Razón 2: los coches viven tres veces más que los servidores empresariales

Un coche vendido en 2030 necesita soporte de software hasta aproximadamente 2045 o 2050. Casi ninguna empresa de software de consumo planifica en esa escala de tiempo. Red Hat sí — los ciclos de lanzamiento de RHEL prometen rutinariamente una década de parches y actualizaciones de seguridad, y la compañía lo ha estado haciendo durante dos décadas.

El comunicado de prensa de Nissan fue inusualmente directo en este punto: "Dado el ciclo de vida de varias décadas de las plataformas automotrices, Nissan identificó a Red Hat como un socio capaz de sostener una base de software automotriz durante un período prolongado de tiempo". Traducido: queremos a alguien que todavía esté parchando este sistema operativo cuando los hijos de nuestros clientes de 2030 hereden el coche. Pocos proveedores tecnológicos pueden prometer eso con credibilidad. Una empresa de Linux empresarial sí puede.

Razón 3: la señal de advertencia llamada CARIAD

Esta es la parte que nadie en Nissan dirá en una rueda de prensa, pero que da forma a todo.

En 2020, Volkswagen Group fundó CARIAD como su brazo interno de software, prometiendo una única plataforma unificada para VW, Audi, Porsche, Bentley y el resto del imperio. Para 2024, el proyecto era una parábola. Según análisis del sector, VW Group había gastado aproximadamente 14 mil millones de euros (unos 15.400 millones de dólares) en el esfuerzo. El Audi Q6 e-tron y el nuevo Porsche Macan eléctrico se retrasaron años. El buque insignia eléctrico de Bentley se deslizó de 2025 a 2028. Dos CEOs perdieron sus puestos en parte por CARIAD. La plataforma SSP de próxima generación, que debía lanzarse en 2024, ahora está en algún momento después de 2026, fecha exacta poco clara. Personas dentro del proyecto describieron una organización que creció a miles de empleados en pocos meses sin una estructura clara — ingenieros asistiendo a 17 reuniones semanales de estatus en lugar de escribir código.

La respuesta de VW a mediados de 2024 fue efectivamente una bandera blanca de 5.000 millones de dólares: una empresa conjunta con la startup de vehículos eléctricos Rivian para encargarse del software que VW ya no podía construir por sí misma. Incluso esa colaboración, según se informa, ha enfrentado turbulencias.

La historia de CARIAD es el cuento aleccionador que toda automotriz tradicional está estudiando ahora. Nissan la ha visto desarrollarse desde primera fila, y la lección implícita es brutal: no se puede arrancar una organización de software de 5.000 personas desde cero en tres años y esperar producción de calidad. Te asocias. Compras tiempo. Dejas que alguien que ya opera la distribución Linux más grande del mundo haga el trabajo de plataforma.

Eso es lo que hizo Nissan.

El problema del tiempo de Nissan

El contexto importa aquí, porque el momento de este acuerdo no es coincidencia.

En febrero de 2025, las conversaciones de fusión de Nissan con Honda colapsaron de manera espectacular — Honda quería una estructura tipo subsidiaria, Nissan se negó, y un acuerdo que habría creado la tercera automotriz más grande del mundo murió en tres meses. Dos meses después, Ivan Espinosa asumió como CEO y lanzó "Re:Nissan", un plan de reestructuración con cifras brutales: 20.000 puestos eliminados (15% de la plantilla), 7 de 17 plantas vehiculares cerradas, y 500 mil millones de yenes (unos 3.200 millones de dólares) en reducciones combinadas de costos fijos y variables para el año fiscal 2026.

Enterrado dentro de Re:Nissan hay una línea que, en retrospectiva, telegrafía el acuerdo con Red Hat: "el desarrollo anticipado y el desarrollo de productos desde el año fiscal 2026 en adelante se detendrán temporalmente, con 3.000 empleados redirigidos hacia actividades de reducción de costos". Cuando 3.000 de tus ingenieros de desarrollo anticipado son retirados del desarrollo anticipado, no puedes al mismo tiempo construir un CARIAD de 14 mil millones de euros.

Sin embargo, Nissan todavía tiene que entregar un SDV. La compañía se ha comprometido a que el 90% de todos los nuevos modelos contará con asistencia al conductor potenciada por IA, y en septiembre de 2025 dio a conocer un prototipo sin conductor que utiliza tecnología de la startup británica de IA Wayve — colocándolo, al menos sobre el papel, cerca de Tesla en la frontera de la autonomía. ProPILOT 2.1 ya está enviando actualizaciones OTA hoy. La próxima generación de ProPILOT está prevista para coches de producción para el año fiscal 2027.

No se hace todo eso y además se construye el sistema operativo desde cero. Se compra el OS.

La comparación con Toyota y Honda

Las tres grandes japonesas están aterrizando en tres estrategias SDV notablemente diferentes:

Toyota creó Woven by Toyota, una subsidiaria con sede en Tokio de 2.500 personas, y está desarrollando su propia plataforma llamada Arene — el enfoque más controlado internamente de los tres, en el espíritu de cómo Toyota tradicionalmente domina su cadena de suministro.

Honda se asoció con Sony para crear Afeela, una empresa conjunta de vehículos eléctricos que según informes ha tenido problemas. El plan SDV más amplio de Honda ha sido visiblemente más lento en materializarse, y la compañía registró una pérdida neta de 423.900 millones de yenes (unos 2.680 millones de dólares) en el ejercicio terminado en marzo de 2026, en parte por errores en la estrategia de vehículos eléctricos.

Nissan eligió el tercer camino: no construyas la plataforma OS tú mismo, tampoco construyas una empresa conjunta de vehículos eléctricos completamente nueva. Compra la capa del OS, construye una plataforma de software encima, e inserta a los ingenieros del proveedor en tu equipo. De las tres, es la estrategia que requiere menos capital y menos tiempo — y Nissan está corto de ambos.

Si eso hace a Nissan inteligente o simplemente limitado es una pregunta que vale la pena hacer. La respuesta puede ser ambas.

¿Qué pasa con QNX?

Una pregunta razonable después de leer hasta aquí: ¿Nissan acaba de descartar QNX de BlackBerry, el sistema operativo dominante en el 36% de los coches del mundo?

Casi con seguridad, no. La conferencia magistral de Sugimoto fue cuidadosa sobre esto: la nueva arquitectura divide el coche en un dominio crítico para la seguridad y un dominio de actualización de alta frecuencia. Red Hat IVOS se encarga del segundo. El primero — la parte que opera los sensores ADAS, los controladores de frenos y la dirección — todavía necesita el tipo de garantías de tiempo real de microkernel para las que QNX ha estado certificado desde 2010. Nada en el anuncio de Nissan sugiere que ese lado esté cambiando.

Lo que está pasando en realidad es más interesante que un reemplazo. Las arquitecturas SDV modernas ejecutan ambos — un RTOS certificado para seguridad junto con un OS de aplicaciones basado en Linux, aislados por un hipervisor en el mismo silicio. El OS de Red Hat es la capa donde viven las funciones visibles del coche: las pantallas, la personalización, las apps que van y vienen. Los sistemas tipo QNX permanecen debajo, haciendo el trabajo determinístico que evita que el coche se estrelle mientras el sistema de entretenimiento se reinicia.

Así que esto no es QNX siendo reemplazado. Es una nueva capa que se está añadiendo y que no existía hace cinco años — y Nissan eligiendo quién la construye.

Quién sigue

El ecosistema de Red Hat IVOS, anunciado junto con Nissan, incluye a Qualcomm y Renesas como socios de silicio, con el OS certificado primero en el SoC R-Car S4 de Renesas. General Motors firmó antes. El patrón que está emergiendo se parece mucho al mercado de OS para smartphones alrededor de 2009: un pequeño número de plataformas OS, un puñado de socios de silicio, y OEMs eligiendo a qué alianza unirse.

Si esa analogía se sostiene — y hay razones para dudarlo, porque los coches y los teléfonos difieren en aspectos fundamentales — entonces las automotrices que elijan la plataforma correcta en los próximos dos años ganarán la década SDV. Toyota está apostando a que puede correr la suya propia. Volkswagen está deshaciendo su apuesta de hacer lo mismo. Nissan, sin presupuesto para una estrategia tipo Toyota y con la advertencia de VW a la vista, eligió la tercera puerta.

Si eso resulta ser la decisión más inteligente en la historia automotriz japonesa o simplemente la más pragmática, lo sabremos alrededor de 2028, cuando los primeros coches que ejecutan esta plataforma realmente lleguen a los garajes.

En tu país, ¿les importa a los conductores quién hace el sistema operativo de su coche — o sigue siendo todo cuestión del emblema en el capó?

Referencias