El coche autónomo la vio 5,6 segundos antes del impacto — y aun así no supo decidir qué era

Estaba sentado en una sala de conferencias a finales de 2023, viendo un vídeo que cambiaría para siempre mi forma de pensar sobre la seguridad de la IA. Las imágenes procedían de un robotaxi de Cruise en San Francisco. Un coche conducido por un humano había atropellado a una peatona, lanzándola a la trayectoria del vehículo autónomo, que la dejó atrapada debajo. El robotaxi se detuvo —brevemente— y después empezó a apartarse hacia el lado de la carretera, arrastrando a la mujer 20 pies por el asfalto.

La sala se quedó en silencio. Alguien de mi equipo dijo: "El coche pensó que había sufrido una colisión lateral". Y esa frase — el coche pensó — se convirtió en la semilla de todo lo que hemos estado construyendo en Veriprajna desde entonces.

Porque el coche no "pensó" nada. Ejecutó una subrutina de clasificación, obtuvo la respuesta equivocada y ejecutó una maniobra preprogramada que convirtió un accidente sobrevivible en algo mucho peor. No hubo razonamiento. Ni consciencia. Ni ninguna arquitectura de seguridad capaz de detectar un diagnóstico erróneo catastrófico antes de que se convirtiera en una catástrofe.

Esta es la brecha que no dejo de intentar explicar a inversores, clientes y colegas ingenieros: la distancia entre una IA que rinde bien en las demos y una IA que se comporta de forma segura cuando el mundo deja de cooperar. He empezado a llamarla la Brecha Percepción-Lógica: el espacio entre lo que un sistema autónomo ve y lo que realmente entiende. Y ahora mismo, esa brecha está matando a personas.

¿Qué ocurrió cuando la IA tuvo casi seis segundos y aun así falló?

El accidente de Uber ATG en Tempe, Arizona, en marzo de 2018 es el caso al que vuelvo con más frecuencia, porque es la ilustración más pura de cómo un sistema probabilístico puede tener todos los datos que necesita y aun así cometer un error fatal.

Los sensores del vehículo registraron por primera vez a Elaine Herzberg —una peatona que empujaba una bicicleta al cruzar una carretera oscura— aproximadamente 5,6 segundos antes del impacto. A 43 mph, eso equivale a unos 378 pies de distancia. Más que suficiente para que cualquier sistema de frenado competente detuviera el coche.

Pero la IA no lograba decidir qué estaba viendo. A lo largo de esos 5,6 segundos, el sistema de percepción reclasificó a Herzberg repetidamente: primero como un "objeto desconocido", luego como un "vehículo", después como una "bicicleta". Cada reclasificación no era solo un cambio de etiqueta: era un reinicio completo de la trayectoria prevista del objeto. En esencia, el sistema sufría amnesia cada vez que cambiaba de opinión.

Recuerdo haber leído el informe de la NTSB por primera vez y haberme sentido físicamente enfermo. No por el resultado —aunque fue devastador—, sino por el mecanismo. La IA determinó que el frenado de emergencia era necesario solo 1,3 segundos antes del impacto. La física hizo inevitable el resto.

Una IA que puede ver un obstáculo durante casi seis segundos y aun así no puede decidir qué es no tiene un problema de sensores. Tiene un problema de arquitectura.

Lo que lo empeoró —lo que me enfureció, sinceramente— fue enterarme de que Uber había desactivado deliberadamente el sistema de prevención de colisiones instalado de fábrica en el Volvo XC90. El coche venía con Frenado Automático de Emergencia del fabricante. Uber lo desconectó para evitar lo que llamaban un "comportamiento errático del vehículo". Querían una conducción más suave para su software experimental, así que eliminaron la única capa de seguridad determinista que podría haber salvado una vida.

Esa decisión persigue a esta industria. Es el pecado original de tratar la seguridad de la IA como un problema de ajuste en lugar de como una disciplina de ingeniería.

¿Por qué el mismo fallo se repite una y otra vez en coches distintos?

Después del accidente de Uber, esperaba que la industria aprendiera. En concreto, esperaba que las empresas construyeran arquitecturas en las que un fallo de percepción no pudiera propagarse en cascada hasta convertirse en un fallo de decisión. Donde hubiera límites de seguridad rígidos que ningún software experimental pudiera anular.

En cambio, tuvimos a Cruise.

El incidente de octubre de 2023 en San Francisco fue distinto del de Uber en sus detalles, pero idéntico en su arquitectura. Un Nissan conducido por un humano atropelló a una peatona y la lanzó a la trayectoria de un robotaxi de Cruise. El vehículo de Cruise la golpeó y se detuvo. Hasta ahí, el sistema funcionaba: de forma imperfecta, pero dentro de los parámetros.

Entonces entró en acción la lógica posterior al impacto. La detección de impactos del sistema no era lo bastante granular como para distinguir entre un atropello frontal y una colisión lateral. Clasificó el suceso como un impacto lateral. Y la respuesta preprogramada a un impacto lateral era: apartarse al lado de la carretera para no bloquear el tráfico.

El coche se apartó. Con un ser humano atrapado debajo. La arrastró 20 pies a unas 7 mph antes de detectar un "deslizamiento excesivo de las ruedas", que interpretó como un fallo mecánico, no como una persona.

Pasé una semana después de aquel incidente discutiendo con mi equipo sobre cuál debería haber sido la arquitectura de respuesta correcta. Uno de nuestros ingenieros —un tipo brillante, muy orientado a los métodos formales— insistía en que el problema se podía resolver con una mejor fusión de sensores. "Si el sistema hubiera tenido detección de ocupación bajo el chasis", dijo, "lo habría sabido".

Tenía razón. Pero también se le escapaba lo esencial. El fallo más profundo era que el sistema no tenía ningún concepto de incertidumbre sobre su propio diagnóstico. Clasificó el impacto y luego actuó según esa clasificación con plena confianza. No había ningún estado intermedio de "no estoy seguro de lo que acaba de pasar, así que no debería hacer nada hasta estarlo". La arquitectura no admitía la duda.

A eso me refiero cuando hablo de la Brecha Percepción-Lógica. No se trata solo de ver mejor. Se trata de saber cuándo no lo sabes.

El encubrimiento también era la arquitectura

Lo que ocurrió después del incidente del arrastre de Cruise fue casi tan revelador como el propio incidente. Las investigaciones descubrieron que la cúpula directiva estaba "obsesionada con corregir la narrativa mediática inexacta" en lugar de ser transparente con los reguladores. Los empleados admitieron haber mostrado a los reguladores un vídeo del accidente sabiendo que los problemas de conectividad a internet a menudo impedían que se reprodujera la parte del arrastre.

Cruise acabó pagando una multa penal de 500.000 dólares por presentar informes falsos a la NHTSA. Su permiso de operación en California fue revocado.

Menciono esto no para ensañarme con Cruise, sino porque revela algo estructural sobre cómo trata la industria la seguridad. Cuando tu sistema de IA es una caja negra —cuando ni siquiera tus propios ingenieros pueden explicar del todo por qué tomó una decisión concreta en un momento concreto—, la tentación de controlar la narrativa en lugar de arreglar la arquitectura se vuelve abrumadora.

La transparencia no es una estrategia de relaciones públicas para los vehículos autónomos. Es un requisito técnico. Si no puedes auditar cada decisión que tomó tu IA en una crisis, no tienes un sistema de seguridad: tienes una responsabilidad legal.

En Veriprajna hemos convertido las auditorías de seguridad explicables en una parte central de nuestro trabajo de arquitectura. Cada decisión que toma la IA, especialmente tras un impacto, queda registrada en un formato determinista e inviolable que los reguladores pueden auditar en tiempo real. No porque seamos más virtuosos que Cruise, sino porque hemos visto lo que ocurre cuando la alternativa es "que el vídeo hable por sí solo".

Escribí sobre el marco técnico completo que hay detrás de este enfoque en nuestro whitepaper interactivo, incluidos los modos de fallo específicos que hemos catalogado a partir de Uber, Cruise, Tesla y Waymo.

¿Qué significa realmente para la seguridad la apuesta de Tesla por la "solo visión"?

El enfoque de Tesla sobre la conducción autónoma es filosóficamente distinto del de Uber o el de Cruise, y los fallos también son distintos. Pero riman.

El sistema Full Self-Driving de Tesla depende por completo de cámaras: sin LiDAR, sin radar. Elon Musk ha llamado al LiDAR una "muleta". La apuesta es que unas redes neuronales suficientemente avanzadas pueden reconstruir una comprensión 3D completa del mundo únicamente a partir de imágenes 2D, del mismo modo que hace la visión humana.

Es una idea elegante. Incluso me parece intelectualmente convincente. Pero la NHTSA ha abierto más de 40 investigaciones sobre accidentes relacionados con el FSD entre 2024 y 2025, que abarcan 2,9 millones de vehículos, y el patrón es demoledor.

Dieciocho denuncias distintas implican vehículos que se saltan semáforos en rojo o que no detectan el estado de las señales. Múltiples informes describen coches que invaden carriles del sentido contrario. Una colisión mortal en 2023 se produjo con deslumbramiento solar sobre asfalto mojado: condiciones en las que la relación señal-ruido óptica cae por debajo de lo que cualquier sistema de cámaras puede interpretar con fiabilidad.

A esto lo llamo Teatro de Capacidades: el sistema rinde de maravilla en condiciones óptimas, creando una ilusión de competencia que se derrumba en los extremos. ¿Día soleado, carretera despejada, cruce estándar? Impecable. ¿Sol bajo, pavimento mojado, un peatón cruzando de forma inusual? El sistema no se degrada de forma progresiva. Falla de golpe.

El problema no es que el enfoque de solo visión no pueda funcionar en teoría. Es que Tesla lo está desplegando a escala sin lo que yo llamaría Puertas de Garantía: límites rígidos que impiden que la IA tome decisiones de alto riesgo cuando su confianza cae por debajo de un umbral verificado. Si la saturación por deslumbramiento supera un determinado porcentaje, el sistema debería negarse a conducir, no adivinar con más ahínco.

¿Cómo se demuestra que una IA no matará a alguien?

Esta es la pregunta que me quita el sueño. No metafóricamente: literalmente. Hubo una época el año pasado en la que estuve realizando experimentos de verificación formal hasta las 2 de la madrugada, intentando encontrar la frontera entre "suficientemente probado" y "demostradamente seguro".

Las pruebas de software tradicionales son de caja negra: haces pasar el sistema por N escenarios y, si los supera todos, lo lanzas. Pero los vehículos autónomos no se encuentran con N escenarios. Se encuentran con todo el mundo físico, con todo su caos, sus casos límite y humanos haciendo cosas inexplicables. Ninguna cantidad de pruebas por escenarios puede cubrir ese espacio.

La verificación formal adopta un enfoque distinto. En lugar de preguntar "¿superó el sistema estas pruebas?", pregunta: "¿existe alguna entrada que pueda producir una salida insegura?". Herramientas como Marabou y α,β-CROWN pueden representar una red neuronal como un conjunto de restricciones matemáticas y después buscar —de forma exhaustiva— violaciones.

Una propiedad de seguridad podría tener este aspecto: para cada entrada posible dentro de un rango de "baja visibilidad", la orden de frenado nunca debe caer por debajo de un umbral mínimo. Si el solucionador encuentra un contraejemplo —una entrada concreta que viola la propiedad—, has identificado una vulnerabilidad antes de que mate a alguien.

Una noche estábamos ejecutando la verificación sobre un modelo de percepción y el solucionador devolvió un contraejemplo que ninguno de nosotros había previsto. Una combinación muy concreta de ángulo de iluminación y distancia al objeto que hacía que la confianza de frenado cayera casi a cero. No era un escenario que a ninguno de nosotros se le hubiera ocurrido probar. El solucionador lo encontró porque no estaba adivinando: estaba demostrando.

Ese momento cristalizó algo para mí. Las pruebas preguntan "¿esto funciona?". La verificación pregunta "¿esto puede fallar?". Son preguntas fundamentalmente distintas, y la IA crítica para la seguridad exige la segunda.

Las pruebas te dicen lo que hace tu IA. La verificación te dice lo que nunca puede hacer. Para los sistemas críticos para la seguridad, solo importa la segunda pregunta.

El inconveniente es que las redes neuronales actuales son enormes —millones de parámetros— y la verificación exhaustiva de redes grandes es computacionalmente intratable. Abordamos esto mediante la poda de neuronas: eliminando sistemáticamente las neuronas redundantes que no contribuyen a la precisión pero hacen que la red sea demasiado compleja para verificarla. El resultado es un modelo más ligero que es a la vez eficiente y matemáticamente demostrable.

Para el desglose técnico completo de nuestro pipeline de verificación —incluidas la metodología del solucionador SMT y el enfoque de poda—, consulta nuestro artículo de investigación detallado.

Cuando el problema no es la IA, sino el mundo

Waymo ha registrado más de 56 millones de millas y tiene tasas de lesiones significativamente más bajas que las de los conductores humanos. Según la mayoría de las métricas, son el líder del sector. Y, sin embargo, Waymo ha revelado un modo de fallo para el que nadie en la industria del vehículo autónomo estaba preparado: el propio mundo negándose a cooperar.

Durante un apagón en Los Ángeles en 2025, decenas de robotaxis de Waymo se quedaron atascados en cruces a oscuras. Los vehículos estaban programados para tratar los semáforos apagados como cruces con stop en las cuatro direcciones, la respuesta legalmente correcta. Pero cuando decenas de vehículos autónomos llegan todos al mismo cruce sin luz, cada uno esperando educadamente su turno y cada uno solicitando asistencia humana remota de forma simultánea, se obtiene algo que he empezado a llamar la Trampa de la Independencia: cada vehículo comportándose correctamente de forma aislada mientras que, colectivamente, crean un atasco que ningún vehículo individual puede resolver.

El centro de asistencia remota se vio desbordado. Los robotaxis bloqueaban a otros robotaxis. El sistema que funcionaba a la perfección con un coche en un cruce se derrumbó al escalarlo a una flota en una emergencia a escala urbana.

Y luego está el problema del que nadie quiere hablar en público. Durante los disturbios en Los Ángeles a principios de 2025, grupos de personas atacaron vehículos de Waymo: rajaron neumáticos, rompieron ventanillas, prendieron fuego a los coches. Los vehículos, programados para una "seguridad pasiva", simplemente se detenían cuando los rodeaba gente. Que es exactamente la respuesta equivocada cuando quienes te rodean intentan destruir el vehículo con los pasajeros dentro.

Esto ha dado lugar a debates serios sobre lo que algunos investigadores llaman un "Modo de Escape ante el Peligro": la capacidad de un vehículo autónomo de cometer infracciones de tráfico menores (subirse a un bordillo, cruzar un semáforo en rojo) para proteger a sus pasajeros de la violencia. Exige replantearse de raíz la jerarquía ética de la IA, y es un problema que ninguna cantidad de mejores sensores o procesadores más rápidos puede resolver.

Saqué este tema en una reunión con un cliente potencial y alguien dijo: "¿No puedes usar simplemente GPT para gestionar casos límite como ese?". Creo que mi expresión dijo más que mis palabras. Es un problema de arquitectura de decisión que requiere razonamiento ético formal, no un chatbot.

¿Por qué no podemos simplemente probar hasta llegar a la seguridad?

La gente me lo pregunta constantemente. "Si Waymo tiene 56 millones de millas de datos, ¿no son pruebas suficientes?"

No. Y la razón es matemática, no filosófica.

El espacio de escenarios de conducción posibles es, en la práctica, infinito. Puedes conducir 56 millones de millas y no encontrarte nunca con esa combinación concreta de deslumbramiento solar, asfalto mojado y un peatón vestido de forma inusual que hace fallar a tu sistema de percepción. Los casos límite no son versiones raras de escenarios comunes: son escenarios que existen en los huecos entre todo lo que ya has visto.

Por eso el panorama regulatorio está pasando de "muéstranos los resultados de tus pruebas" a "muéstranos tus demostraciones de seguridad". La norma ISO 21448, conocida como SOTIF —Seguridad de la Funcionalidad Prevista—, se diseñó específicamente para abordar los peligros que se producen cuando la IA funciona exactamente como está programada pero se encuentra con un entorno que no puede manejar. No se trata de que el hardware falle. Se trata de las limitaciones inherentes de la IA al toparse con el mundo real.

Y la ISO/PAS 8800, que se convirtió en la norma principal para la IA en vehículos de carretera a finales de 2024, va más allá: exige gestionar todo el ciclo de vida de la IA, desde la adquisición de datos hasta la monitorización posterior al despliegue. La era del "lánzalo y ya veremos qué pasa" está terminando, al menos para las empresas que quieran operar legalmente en la UE, EE. UU. y los principales mercados asiáticos.

En Veriprajna estructuramos nuestro trabajo en torno a llevar a los clientes hacia lo que SOTIF denomina el cuadrante "Conocido/Seguro": identificando sistemáticamente las condiciones desencadenantes, mapeando los estados del entorno que provocan errores de percepción y utilizando simulación de alta fidelidad para inyectar casos límite que serían demasiado peligrosos de probar en carreteras reales.

La verdadera diferencia entre un wrapper y una solución

He pasado los últimos años viendo cómo la industria de la IA se divide en dos bandos, y la división es cada vez mayor.

Por un lado está la economía de los wrappers: empresas que construyen interfaces conversacionales sobre grandes modelos de lenguaje, optimizando para la velocidad de despliegue y la experiencia de usuario. Parte de ese trabajo es genuinamente útil. La mayor parte es irrelevante para las aplicaciones críticas para la seguridad.

Por el otro está lo que yo llamo ingeniería profunda de IA: la integración de verificación formal, resiliencia en la fusión de sensores y arquitecturas de seguridad deterministas. Es más lenta. Es más difícil. Impresiona menos en las demos. Y es el único enfoque que puede sobrevivir al contacto con el mundo físico.

La pieza técnica central de este cambio es la percepción de Vista de Pájaro (Bird's-Eye-View) con Redes de Ocupación. En lugar de procesar las señales de cada cámara por separado e intentar coserlas después —un proceso que pierde datos en cada costura—, la percepción BEV transforma los datos de cámaras multivista y de LiDAR en una cuadrícula 3D unificada vista desde arriba. Y en lugar de preguntar "¿qué es este objeto?", las redes de ocupación preguntan "¿está ocupado este espacio?".

Esa distinción importa enormemente. Si el sistema de Uber ATG hubiera estado rastreando el espacio ocupado en lugar de intentar clasificar objetos, no habría importado que el sistema creyera que Herzberg era una peatona, una bicicleta o un objeto desconocido. El espacio estaba ocupado. El espacio estaba en la trayectoria del vehículo. Frena.

De forma similar, si el vehículo de Cruise hubiera estado ejecutando detección de ocupación bajo su chasis, habría sabido que había algo debajo del coche independientemente de cómo clasificara el impacto. El espacio ocupado habría anulado la maniobra de apartarse.

La pregunta no es "¿qué es este objeto?", sino "¿está ocupado este espacio?". Ese único replanteamiento podría haber evitado los dos desastres de vehículos autónomos más notorios de la última década.

Usamos arquitecturas Transformer —la misma tecnología fundamental que hay detrás de GPT—, pero no para conversar. Las usamos como motores de razonamiento espacial que fusionan datos heterogéneos de sensores en lo que llamamos un Lienzo Compartido. La autoatención temporal permite que el sistema recuerde dónde estaba un objeto incluso durante oclusiones temporales: una peatona que camina detrás de un camión aparcado no desaparece de la conciencia del modelo solo porque las cámaras no puedan verla durante dos segundos.

La lección de 8,5 millones de dólares

El acuerdo extrajudicial de Uber ATG fue de 8,5 millones de dólares. La multa penal de Cruise fue de 500.000 dólares, una cifra que ni siquiera empieza a dar cuenta del cierre operativo, del daño reputacional o del sufrimiento humano. La investigación de la NHTSA sobre Tesla abarca 2,9 millones de vehículos. El coste medio global de una sola filtración de datos es ahora de 4,44 millones de dólares.

Cuando sumo estas cifras, la conclusión resulta incómoda para la gente del "muévete rápido y rompe cosas": el wrapper de IA barato es el error más caro que puede cometer una empresa. No porque no funcione —funciona bien en entornos controlados—, sino porque en el momento en que se encuentra con el mundo no controlado —la carretera oscura, la confusión posterior al impacto, el deslumbramiento solar sobre el asfalto mojado, la multitud enfurecida— la ausencia de una arquitectura de seguridad determinista convierte una limitación de software en una catástrofe humana.

A veces la gente pone reparos a nuestro enfoque diciendo que la verificación formal es demasiado lenta, demasiado cara, demasiado académica para los plazos de despliegue del mundo real. Entiendo la objeción. La verificación es computacionalmente cara. Podar redes para hacerlas verificables lleva tiempo. Construir arquitecturas de seguridad con puertas de garantía rígidas da más trabajo que envolver una API.

Pero a esas personas les pediría que vieran el vídeo del arrastre de Cruise. Que leyeran el informe de la NTSB sobre la muerte de Elaine Herzberg. Que miraran las 18 denuncias por semáforos en rojo en la investigación del FSD de Tesla. Y que después me dijeran que "demasiado lento" es una crítica válida a un enfoque diseñado para evitar exactamente esos desenlaces.

La era de construir sistemas autónomos sobre la esperanza probabilística está terminando. No porque los reguladores lo estén forzando —aunque lo hacen—, sino porque la física del mundo real lo exige. Un sistema de IA que navega mil cruces a la perfección y luego se salta un semáforo en rojo en el cruce mil uno no es seguro al 99,9 %. Es inseguro, punto. La seguridad no es un porcentaje. Es una propiedad: una que, o se cumple en todas las condiciones verificadas, o no se cumple en absoluto.

Ese es el cambio en torno al que estoy construyendo Veriprajna. No mejores wrappers. No demos más rápidas. Garantía determinista para sistemas en los que un fallo no es un informe de errores: es un recuento de muertos.