Una conversación con el Dr. Luc Julia

Recableando las fábricas de hoy para codificar los autos del mañana

Dr. Luc Julia, Director Científico del Grupo Renault

El Dr. Luc Julia es Director Científico de Renault Group, donde lidera los esfuerzos de la organización en IA, datos y transformación impulsada por software. Con experiencia en informática y una carrera que abarca roles en Apple, Samsung y el Centre national de la recherche scientifique (CNRS, Centro Nacional Francés para la Investigación Científica), el Dr. Julia es reconocido como pionero en reconocimiento de voz e IA y es el cocreador de la tecnología Siri. Desde 2020 ha sido miembro de l’Académie des technologies (la Academia Francesa de Tecnologías). En octubre de 2020, fue galardonado con la Légion d’Honneur (la más alta orden francesa al mérito) por el Secretario de Estado para la Economía Digital, en reconocimiento a su trabajo en los campos de IA, interacción humano-computadora, medios digitales y otras tecnologías avanzadas.

---

Código en el taller

¿Qué hace el director científico de un fabricante de automóviles?

Mi mandato es flexible. Tengo la libertad de incorporar ideas y prácticas de software en cualquier departamento. Durante los últimos cuatro años, hemos trabajado para integrar la IA en las fábricas y en los propios vehículos. Estamos introduciendo prácticas que serían beneficiosas para un vehículo completamente definido por software (SDV) y promoviendo la modularidad, el tipo de diseño modular que los SDV pueden ofrecer.

De hecho, tengo un KPI irónico: aspiro a una tasa de fracaso del 90 % en nuestros proyectos. Claro que nunca lo logro; solo llego a un 70 % de fracaso. Pero hay una filosofía detrás: si fallamos mucho, significa que intentamos hacer cosas muy avanzadas y difíciles. Estamos superando los límites. Así que, para mí, una alta tasa de fracaso es señal de que estamos asumiendo riesgos e innovando. En la práctica, termino cancelando alrededor del 70 % de los proyectos que empezamos en un año. Y eso está bien. Significa que aprendemos y pasamos a la siguiente idea desafiante. En mi función, el rendimiento se mide por si intentamos innovaciones audaces, no por si tienen éxito o no (y, naturalmente, muchas fracasarán).

---

¿Cuáles son las razones detrás del fracaso de los proyectos?

Normalmente, se debe a que descubrimos que no podemos implementarla con éxito en el mundo real. Rara vez se debe a que la tecnología principal no funcione; se trata más bien del contexto. Por ejemplo, supongamos que desarrollamos una nueva herramienta de IA para una fábrica. Si nos damos cuenta de que a los trabajadores les resultará demasiado complicada o simplemente no les gusta, entonces no tiene sentido continuar. La tecnología puede haber sido genial, pero si no se puede aplicar debido a barreras prácticas, ahí es cuando lo dejo.

---

¿Cómo seleccionas los proyectos o temas en los que trabajas?

Priorizamos proyectos que podemos ejecutar rápidamente y que pueden tener un impacto a corto plazo, especialmente proyectos que mejoran las operaciones diarias. Algunas iniciativas pueden cambiar el funcionamiento de un equipo o una fábrica en cuestión de meses. Claro que también tenemos proyectos más largos. Cualquier cambio en el hardware o los sistemas centrales de un vehículo puede llevar entre 18 y 24 meses. Pero los compensamos con resultados rápidos.

Otro criterio clave es la reutilización. La modularidad es fundamental para nosotros. Nos preguntamos: si construimos esto, ¿podemos reutilizar los componentes en otros lugares? Hemos desarrollado ciertos módulos de software que pueden integrarse en diferentes proyectos. Si surge una nueva idea y nos damos cuenta de que ya tenemos el 60 % de las piezas de trabajos anteriores, es más probable que la implementemos. Ahorra tiempo y evita tener que reinventar la rueda.

En resumen, seleccionamos proyectos que 1) puedan entregarse rápidamente para un impacto a corto plazo, y 2) reutilicen componentes básicos existentes o aporten nuevos que podamos reutilizar en el futuro. Si un concepto de proyecto cumple con estos criterios, lo aceptamos. Si requiere empezar desde cero y no tiene un gran impacto inmediato, podríamos posponerlo para más adelante.

---

Prepararse para el software

¿Qué cambios de liderazgo o gobernanza cree usted que son necesarios para que la organización se oriente más hacia el software?

Ante todo, la formación y la mentalidad. Los fabricantes de automóviles están dominados por profesionales con experiencia en hardware: ingenieros mecánicos, expertos en la construcción de automóviles. Esa experiencia es valiosa y necesaria, pero necesitamos liderazgo para comprender a fondo las prácticas de desarrollo de software. Implementar Agile en nuestro entorno puede ser un desafío debido a la forma en que se ejecutan los programas de automóviles.

Piénselo. Un fabricante define el hardware de un coche con cuatro o cinco años de antelación, paso a paso, con largos plazos de entrega y puntos de congelación. El software debería actualizarse e iterarse continuamente, no congelarse años antes del lanzamiento. Pero en la situación actual, incluso nuestro desarrollo de software se ve obligado a seguir ese rígido cronograma para alinearse con la producción del coche. Para cuando el software llegue al vehículo, podría estar ya obsoleto.

Durante décadas, la mentalidad en la cúpula ha sido “priorizar el hardware”. Cambiar eso implica capacitar y convencer a la gente para que piense en términos de ciclos de software, actualizaciones inalámbricas (OTA), mejoras rápidas, etc., algo nuevo para muchos. Existe mucha resistencia interna simplemente porque “así es como siempre lo hemos hecho”.

Otro problema importante es la estructura organizativa. Los fabricantes de automóviles tienen demasiados niveles jerárquicos. En las divisiones de ingeniería, puede haber siete niveles de gestión entre el director técnico (o jefe de ingeniería) y el ingeniero que escribe el código o diseña un componente. Esto diluye o incluso bloquea la transformación.

Para estar más orientados al software, necesitamos capacitar a nuestro personal (especialmente a los directivos) sobre las prácticas modernas de software, adoptar una mentalidad ágil y simplificar la organización o, al menos, optimizar la toma de decisiones. De lo contrario, incluso las mejores ideas se perderán en la burocracia.

---

Al utilizar Agile y DevOps para actualizaciones de software continuas, ¿cómo se garantiza que la seguridad funcional y la ciberseguridad estén correctamente integradas?

Este es uno de los desafíos más difíciles, algo con lo que se enfrenta todo el mundo del software. Lo cierto es que, a pesar de nuestras mejores intenciones, la “ciberseguridad por diseño” o la “seguridad por diseño” son más fáciles de predicar que de practicar. En teoría, se supone que se debe considerar la seguridad desde el primer día, integrarlas en la arquitectura y verificarlas continuamente. En la práctica, cuando los ingenieros se apresuran a desarrollar una función o corregir un error, puede que no consideren todas las posibles vulnerabilidades en los sistemas de seguridad. A menudo, nos encontramos en una postura de seguridad reactiva: primero desarrollar la función, luego probarla, encontrar vulnerabilidades y aplicar parches.

Aunque contamos con procesos para mitigar riesgos, la seguridad es una carrera continua. Nunca se puede decir: “Bien, ya estamos 100 % seguros. Listo”. En el momento en que piensas eso, alguien encontrará un nuevo exploit. Lo mismo ocurre con la seguridad. Por eso, nuestro enfoque es la vigilancia continua. Incorporamos la seguridad en el flujo de trabajo de DevOps (como análisis de seguridad automatizados, análisis de código estático, etc.), pero también realizamos monitoreo sobre el terreno. Si detectamos algo sospechoso en los datos de la flota (anomalías que podrían indicar un intento de hackeo o un fallo de software, por ejemplo), lo investigamos de inmediato. Y gracias a las capacidades de los vehículos conectados, si se encuentra una vulnerabilidad grave, podemos publicar un parche OTA. Integramos la seguridad al máximo desde el principio, realizamos pruebas exhaustivas, seguimos las normativas de las mejores prácticas básicas y nos mantenemos alerta. El desarrollo ágil no implica comprometer la seguridad. Simplemente significa que debemos ser extremadamente rigurosos.

---

Datos sintéticos e IA generativa

¿Cómo se utilizan los datos de los vehículos en la carretera y qué papel juegan los datos sintéticos?

Los datos sintéticos se han vuelto extremadamente importantes para nosotros, principalmente para fines de simulación. Tomemos como ejemplo las pruebas de choque. Tradicionalmente, se chocaban autos reales para recopilar datos, pero, obviamente, eso es costoso y tiene limitaciones. Hoy en día, utilizamos escenarios de choque simulados para generar datos sintéticos de sensores que representan colisiones. De esta manera, podemos probar virtualmente cómo responden los sistemas de un auto a innumerables situaciones de choque sin tener que destrozarlo en cada ocasión.

Otro uso es la simulación de escenarios de conducción. Contamos con pistas de pruebas, pero nunca cubriremos todos los escenarios posibles. Por lo tanto, cuando nos enteramos de un nuevo escenario o imaginamos algo inusual (“¿Qué pasaría si un canguro saltara delante del coche?”), podemos simularlo utilizando datos sintéticos.

Utilizamos la IA en dos ámbitos: fuera y dentro del coche. En el exterior, comprendemos el entorno: reconocemos peatones, otros vehículos, señales y tomamos decisiones de conducción (todos los sistemas ADAS y la conducción autónoma). En el interior del coche, interactuamos con el conductor mediante asistentes de voz, monitorizamos su estado de alerta, etc. En el exterior (donde la seguridad es crucial), los datos sintéticos son una bendición.

Una de las razones por las que dependemos de datos sintéticos es la sorprendentemente limitada disponibilidad de datos del mundo real. Existen dos grandes obstáculos para recopilarlos a gran escala:

Regulación (p. ej., el RGPD en Europa): Las leyes de privacidad son muy estrictas en cuanto a la recopilación y el uso de datos de los vehículos de los clientes. Necesitamos el consentimiento explícito, e incluso cuando las personas hacen clic en “sí” en algo, puede que no cubra todos nuestros requisitos.

Propiedad y acceso: En ocasiones, no podemos acceder directamente a los datos generados por un componente. Por ejemplo, durante mucho tiempo no pudimos acceder a las imágenes sin procesar de las cámaras frontales de nuestros coches porque el módulo de cámara provenía de un proveedor que las trataba como si fueran de su propiedad.

Por lo tanto, entre los obstáculos legales de privacidad y algunos contratos con proveedores heredados, nuestros datos de flota utilizables reales son mucho menores de lo que podrían ser.

Los datos sintéticos cubren las necesidades. Creamos los datos que nos faltan. Simulamos escenarios que sospechamos que ocurren en el mundo real, pero que aún no están representados en nuestros conjuntos de datos. Esto nos ayuda a cubrir nuestros puntos ciegos y a entrenar modelos robustos de IA sin depender de la recopilación de datos del mundo real.

---

¿Ya estás incorporando IA generativa (Gen AI) o IA agentiva?

Sí. Por ejemplo, en nuestro modelo eléctrico Renault 5 recientemente lanzado, tenemos un asistente inteligente integrado. Este es un pequeño avatar en la pantalla de infoentretenimiento con el que puedes hablar. Esto está impulsado completamente por Gen AI, específicamente modelos de lenguaje grande (LLM) bajo el capó. Empezamos a trabajar en esto antes de que ChatGPT explotara en 2023, por lo que estábamos un poco por delante de la curva de publicidad. La idea es que puedas preguntarle a este asistente cualquier cosa, ya sea conocimiento general o específico para el auto. Puede aprovechar un LLM o su sistema interno, según sea necesario. El asistente puede incluso tener un poco de personalidad. Es una demostración de cómo Gen AI puede hacer que la interfaz de un auto sea más parecida a la humana.

En nuestro contexto, la IA agencial podría ser extremadamente útil. Imagine el automóvil como un ecosistema de agentes de IA: un agente vigila constantemente los carriles, otro supervisa el estado de alerta del conductor, etc. Estos agentes pueden operar de forma semiindependiente y, posteriormente, un orquestador o una lógica de alto nivel combina sus resultados para tomar decisiones generales.

Esto se ajusta a nuestro enfoque modular y también se adapta a nuestras limitaciones de hardware. Por ejemplo, no podemos ejecutar un modelo de IA gigantesco del tamaño de una nube en el coche en tiempo real. Simplemente, no disponemos de esa potencia de procesamiento a bordo, para empezar. Pero podríamos ejecutar un conjunto de agentes más pequeños y eficientes en los ordenadores del coche. Es como tener un equipo de especialistas en lugar de un multitalento.

Así que, sí, estamos aprovechando la IA Gen para la interfaz de usuario y la experiencia, y la IA basada en agentes está influyendo en nuestra forma de pensar sobre la arquitectura del sistema. La IA agentica adquirirá cada vez mayor importancia en el software automotriz. La industria podría necesitar algunos años para adoptarla plenamente, pero sin duda la tenemos en la mira.