Navegando por el futuro de los sistemas autónomos: seguridad, ética y responsabilidad en la era de la IA
Pregunte a una sala llena de ingenieros que trabajan en pilas de percepción para vehículos autónomos qué piensan sobre el dilema del tranvía, y en su mayoría obtendrá expresiones de cansancio. El problema en sí es ciertamente sustancial. Porque es el modelo equivocado para el problema de ingeniería real que tienen delante, y explicar por qué lleva más tiempo del que la mayoría de las conversaciones durante una cena pueden tolerar.
La versión honesta del desafío de seguridad en los sistemas autónomos es mucho menos dramática desde el punto de vista filosófico y mucho más agotadora desde el punto de vista matemático: percepción probabilística bajo ruido de sensores, oclusión y latencia, alimentada en un proceso de toma de decisiones que debe optimizar una función de recompensa a través de espacios de acción continuos, sin ninguna elección binaria clara en ninguna parte del bucle. Lograr que esa realidad de ingeniería sea correcta, y construir los estándares y marcos de responsabilidad en torno a ella adecuadamente, es un problema genuinamente más difícil y trascendental que cualquier experimento mental, y merece ser tratado como tal.
Parte 1: Por qué el dilema del tranvía falla como especificación de ingeniería
El dilema del tranvía asume algo que ningún sistema autónomo real tiene: un mundo determinista, un conocimiento perfecto del estado, una elección binaria clara y certeza sobre los resultados. La pila de percepción de un vehículo autónomo real nunca tiene nada de eso. Tiene retornos de LiDAR con ruido, fotogramas de cámara degradados por la lluvia o un ángulo de sol bajo, oclusión detrás de un camión estacionado y un estado de creencia probabilístico sobre lo que realmente hay ahí fuera, no una verdad absoluta.
Lo que realmente se ejecuta bajo el capó
Los vehículos autónomos reales se apoyan en marcos formales como los Procesos de Decisión de Markov Parcialmente Observables y el aprendizaje por refuerzo precisamente porque el mundo es genuinamente observado de forma parcial. El sistema no está eligiendo entre dos destinos predeterminados. Está muestreando a través de un espacio de acción continuo, docenas de combinaciones plausibles de ángulo de dirección y aceleración, y optimizando el resultado esperado frente a una función de recompensa estructurada en torno a la evitación de colisiones y umbrales de deber de cuidado, bajo una incertidumbre genuina sobre cómo se comportará realmente el peatón, el coche que viene en sentido contrario o el ciclista en los próximos dos segundos. Programar un vehículo autónomo para "resolver" un dilema al estilo del tranvía no es una versión simplificada de la tarea de ingeniería real. Es resolver un problema completamente diferente, uno que en realidad no ocurre en la forma que asume el experimento mental.
El experimento de la Máquina Moral y por qué la ética de colaboración abierta es una trampa
El experimento de la Máquina Moral del MIT recopiló millones de respuestas de colaboración abierta a escenarios hipotéticos de accidentes de vehículos autónomos, y la variación cultural que reveló, diferentes preferencias a nivel de población sobre salvar a los jóvenes frente a los ancianos, por ejemplo, es genuinamente interesante desde el punto de vista sociológico. También es una señal de advertencia seria para cualquiera que se sienta tentado a entrenar un módulo de ética directamente con esos datos.
El razonamiento moral humano bajo presión de tiempo tiende a ser deontológico; cuando se les da tiempo para deliberar, las mismas personas tienden a ser utilitaristas. Esa no es una función de preferencia estable que uno quiera integrada en un sistema de control crítico para la seguridad. Peor aún, existe un sesgo de perspectiva bien documentado: las personas que se imaginan a sí mismas como pasajeros del vehículo autónomo quieren que el coche proteja al pasajero por encima de todo, mientras que las mismas personas que se imaginan a sí mismas como peatones quieren lo contrario. Entrene un modelo con intuición de colaboración abierta como esa y no estará codificando ética. Estará codificando inconsistencia interesada a gran escala, que es precisamente la razón por la cual la ética en este dominio no puede abordarse como un ejercicio democrático de ajuste de datos. Necesita una estructura constitucional que no sea simplemente el promedio del sentimiento popular.
De arriba hacia abajo, de abajo hacia arriba y el híbrido que realmente se despliega
La codificación algorítmica de arriba hacia abajo integra compromisos éticos específicos directamente en la lógica determinista, una regla deontológica estricta contra infringir las leyes de tráfico, excepto para evitar una colisión inminente, por ejemplo. Es auditable y predecible, y también es frágil ante escenarios que el diseñador de la regla no anticipó.
El aprendizaje automático de abajo hacia arriba permite al sistema inferir normas de comportamiento a partir de datos de entrenamiento, lo que maneja la variación desordenada del mundo real mucho mejor, al costo directo de la interpretabilidad. Una red de políticas de "caja negra" no puede explicar fácilmente después del hecho por qué eligió una trayectoria específica en un caso límite, lo cual es un problema genuino para la investigación de incidentes y la responsabilidad regulatoria.
El patrón que realmente ha surgido en el despliegue serio es híbrido: las políticas aprendidas de abajo hacia arriba manejan el problema continuo y desordenado de la percepción y la optimización de la trayectoria, operando dentro de restricciones estrictas de arriba hacia abajo que la política aprendida tiene arquitectónicamente prohibido violar, independientemente de lo que la función de recompensa pueda sugerir de otro modo. Esa capa de delimitación, implementada a veces como un filtro de seguridad explícito basado en reglas situado aguas abajo del planificador aprendido, es funcionalmente similar a cómo un límite de articulación codificado o un bloqueo de evitación de colisiones restringe una política de manipulación robótica aprendida en entornos industriales. El aprendizaje maneja los matices; la capa determinista maneja los límites no negociables.
La importancia de la seguridad está intrínsecamente tejida en el tejido del diseño del producto, palpable en los marcos regulatorios que dictan su desarrollo.
Seguridad funcional frente a SOTIF: dos categorías de falla diferentes
La norma ISO 26262 rige la Seguridad Funcional, la disciplina bien establecida de gestión del riesgo derivado de fallos de hardware o defectos sistemáticos de software. Su marco de Nivel de Integridad de Seguridad Automotriz (ASIL) escala el rigor de la actividad de diseño y verificación a la gravedad y probabilidad del peligro que una falla determinada podría causar, y la mayoría de los ingenieros de electrónica automotriz han pasado tiempo real discutiendo sobre estrategias de descomposición ASIL precisamente por esta razón.
La realización genuinamente incómoda que la industria tuvo que enfrentar es que un vehículo autónomo puede chocar con todos los componentes funcionando exactamente como fueron diseñados. Una cámara captura una imagen perfectamente limpia. La red de percepción simplemente no logra clasificar correctamente a un peatón que lleva un disfraz inusual bajo una lluvia intensa, porque esa combinación específica se encuentra fuera de lo que la distribución de entrenamiento cubrió adecuadamente. Nada falló. El sistema simplemente fue insuficiente para la complejidad de ese momento, y todo el marco de la norma ISO 26262, construido en torno al riesgo de mal funcionamiento, no tiene un vocabulario nativo para ese modo de falla.
La norma ISO 21448, SOTIF, existe específicamente para cerrar esa brecha, centrándose en los peligros derivados de la limitación del rendimiento y las condiciones operativas no anticipadas en lugar de la falla de los componentes. Vale la pena entender en detalle el modelo de cuatro cuadrantes de SOTIF porque brinda a los equipos de ingeniería una hoja de ruta real en lugar de solo una etiqueta para el problema. El Área 1 es el estado objetivo conocido como seguro. El Área 2 es el conocido como peligroso, riesgos que el equipo ya ha identificado y está mitigando activamente mediante cambios de diseño. El Área 3 es el desconocido como peligroso, la categoría genuinamente peligrosa porque el equipo aún no ha identificado estos casos límite. El Área 4 es el desconocido como seguro.
Todo el objetivo práctico de la ingeniería SOTIF, la simulación extensiva, la validación de campo estadística y el descubrimiento estructurado de casos límite, es migrar escenarios fuera del Área 3 hacia el Área 2, donde se convierten en problemas de diseño manejables en lugar de riesgos invisibles. Ejecutar ISO 26262 y SOTIF en paralelo en lugar de tratar a cualquiera de ellas como suficiente por sí sola es lo que realmente cubre tanto el riesgo de mal funcionamiento interno como el riesgo de complejidad externa simultáneamente, y omitir cualquiera de las dos deja una brecha real en el argumento de seguridad.
Robótica colaborativa: ISO 10218 y la fusión de la TS 15066 de 2025
El mismo cambio fundamental, eliminar la suposición de que un humano es siempre el último mecanismo de seguridad, se desarrolló en la robótica industrial. Los robots industriales tradicionales operaban dentro de jaulas de seguridad aisladas con bloqueos estrictos: abrir la jaula, la energía se corta inmediatamente. La introducción de robots colaborativos alteró fundamentalmente las configuraciones tradicionales del espacio de trabajo, lo que requirió la coexistencia entre humanos y robots.
La actualización de 2025 a la norma ISO 10218-2 absorbió formalmente la norma ISO/TS 15066 en un único estándar unificado de robótica colaborativa, y vale la pena conocer a fondo los cuatro modos operativos colaborativos que define si está especificando cualquier celda de cobot. La Parada Monitoreada con Clasificación de Seguridad detiene el robot por completo ante la entrada de un humano y se reanuda solo después de que la zona se despeja. Para garantizar un flujo de trabajo seguro y eficiente, los operadores gestionan activamente el movimiento del brazo robótico, controlando con precisión la velocidad en ubicaciones predeterminadas. En tiempo real, el sistema optimiza su ritmo basándose en cálculos dinámicos de velocidad relativa y proximidad a los humanos, asegurando un entorno de trabajo más seguro. Limitar los límites de potencia y fuerza no solo restringe el contacto mecánico, sino que también aplica electrónicamente fuerzas de contacto seguras para evitar que las colisiones superen los límites de seguridad predefinidos.
El detalle que más a menudo confunde a los nuevos integradores: el estándar establece explícitamente que ningún robot es inherentemente "seguro" o "colaborativo" de forma aislada. Es toda la aplicación, el efector final específico, la geometría de la pieza de trabajo, los accesorios circundantes, la tarea real, lo que debe ser evaluado por riesgos y validado como un sistema completo. Un brazo robótico que cumple perfectamente con PFL y que utiliza una pinza personalizada de bordes afilados no es una aplicación colaborativa solo porque el robot base tenga una certificación colaborativa.
IEEE P7000: Donde la ética sociotécnica se formaliza
La seguridad es la principal preocupación que impulsa los estándares ISO, que priorizan tanto los aspectos físicos como los funcionales. El conjunto IEEE P7000, lanzado bajo la Iniciativa Global de IEEE sobre Ética de Sistemas Autónomos e Inteligentes, aborda las dimensiones sociotécnicas y éticas que los marcos ISO nunca fueron diseñados para cubrir, y lo hace con estándares específicos y abordables en lugar de principios aspiracionales vagos.
IEEE P7001 se centra en la transparencia, exigiendo que los sistemas autónomos sean autoevaluables y expongan las vías de decisión en una forma realmente explicable para los humanos después del hecho, que es precisamente la capacidad que el aprendizaje de abajo hacia arriba de caja negra pura lucha por ofrecer sin trabajo arquitectónico adicional. IEEE P7003 aborda el sesgo algorítmico directamente, proporcionando marcos estructurados para identificar y prevenir resultados discriminatorios en modelos entrenados antes del despliegue. IEEE P7009 cubre específicamente el diseño a prueba de fallos, exigiendo un comportamiento de degradación elegante y seguro en lugar de modos de falla abruptos o impredecibles cuando un sistema genuinamente no puede continuar con la operación normal. IEEE P7010 va más allá de lo que suelen hacer la mayoría de los estándares de ingeniería, introduciendo métricas de bienestar que evalúan el impacto real de un sistema de IA en el florecimiento humano en lugar de detenerse en métricas estrechas de economía o finalización de tareas.
Parte 3: Construir un caso de seguridad que realmente se sostenga
Las listas de verificación de cumplimiento de la norma ISO 26262 o SOTIF son un trabajo preliminar necesario, pero por sí solas no constituyen un argumento defendible de que un sistema específico sea seguro para desplegarse en el mundo real. Ese argumento es lo que un Caso de Garantía de Seguridad construye formalmente: afirmaciones estructuradas, respaldadas por cadenas de argumentos lógicos, respaldadas por evidencia verificable concreta, registros de simulación, resultados de pruebas en pista, telemetría de campo.
UL 4600: Basado en objetivos en lugar de prescriptivo
ANSI/UL 4600 adopta un enfoque deliberadamente diferente al de los estándares prescriptivos tradicionales que dictan requisitos de implementación exactos. Se basa en objetivos, proporcionando un amplio conjunto de indicaciones obligatorias, requeridas y recomendadas que obligan a los equipos de ingeniería a abordar activamente categorías de riesgo específicas en lugar de simplemente marcar una casilla de implementación fija.
UL 4600 obliga a la confrontación directa con la fragilidad inherente del aprendizaje automático, la larga cola genuina de casos límite raros y la realidad desordenada de la interacción humano-máquina en condiciones operativas reales. Su requisito de un Dominio de Diseño Operativo estrictamente definido, el envolvente ambiental, geográfico y temporal explícito dentro del cual el sistema está realmente autorizado a operar, siendo "día, clima despejado, carreteras pavimentadas a menos de 45 mph" un ejemplo representativo, es el requisito operativamente más consecuente del estándar. Si el vehículo encuentra condiciones fuera de ese envolvente, una ventisca repentina, una zona de construcción no mapeada, el caso de seguridad tiene que demostrar que el sistema puede detectar de manera confiable esa violación del ODD y ejecutar una maniobra de respaldo genuinamente segura, no solo esperar que la pila de percepción maneje la situación con elegancia.
SACE y AMLAS: Una metodología holística y consciente del entorno
La metodología SACE de la Universidad de York, Garantía de Seguridad de sistemas autónomos en Entornos Complejos, trabaja junto con AMLAS, Garantía de Aprendizaje Automático para su uso en Sistemas Autónomos, para adoptar una visión genuinamente holística que abarca tanto el sistema en sí como el entorno operativo en el que existe.
El componente de Garantía de Operación Fuera de Contexto de SACE aborda algo que el concepto de ODD de UL 4600 implica pero no formaliza completamente por sí solo: el mundo real es infinitamente más complejo de lo que cualquier Modelo de Dominio Operativo definido puede capturar por completo, por lo que el sistema inevitablemente vagará fuera de sus límites definidos eventualmente. SACE requiere demostrar explícitamente dos capacidades distintas. Primero, que el sistema pueda reconocer con precisión y prontitud que se está acercando o que ya ha cruzado el límite del ODM, con tasas de falsos positivos y falsos negativos cuidadosamente validadas en esa detección de límites, ya que un detector de límites que grita "lobo" constantemente es casi tan inseguro como uno que pasa por alto cruces de límites reales. Segundo, que el sistema tenga una Estrategia de Riesgo Mínimo genuina lista para ejecutar una vez fuera del ODM, ya sea que eso signifique devolver el control a un operador humano, ejecutar una parada segura controlada o hacer la transición a un modo seguro degradado deliberadamente conservador centrado puramente en la autoconservación en lugar de en la finalización de la tarea.
Por qué la simulación conlleva gran parte del peso probatorio
Ninguna flota, por grande que sea, puede conducir físicamente suficientes millas en el mundo real para encontrar cada caso límite peligroso significativo solo a través de pruebas en carretera; la combinatoria del clima, la iluminación, el comportamiento del tráfico y las clases de objetos raros hace que ese enfoque sea estadísticamente desesperado dentro de cualquier cronograma de programa razonable. Los marcos de simulación estandarizados como ASAM OpenDRIVE para la descripción de redes de carreteras y OpenSCENARIO para la especificación de maniobras dinámicas permiten a los equipos de ingeniería construir entornos virtuales altamente parametrizados donde se pueden inyectar fallas deliberadamente, variar sistemáticamente las condiciones climáticas y de iluminación, y ejecutar millones de permutaciones de escenarios mucho más rápido y exhaustivamente de lo que las pruebas físicas podrían lograr, generando la mayor parte de la base probatoria en la que realmente se apoyan los argumentos de seguridad de SOTIF y UL 4600 antes de que cualquiera de ese software toque el hardware físico.
Parte 4: Responsabilidad: donde la ingeniería se encuentra con la ley
Cuando un sistema autónomo causa una fatalidad, el instinto público inmediato es a menudo preguntar qué "decidió" hacer la máquina, como si hubiera tomado una elección moral. Ese encuadre es un error de categoría, y es importante que los ingenieros y los marcos legales construidos en torno a esta tecnología lo resistan deliberadamente.
Por qué las máquinas no pueden tener agencia moral o legal
Un sistema autónomo, independientemente de su sofisticación arquitectónica, optimiza una función de recompensa matemática. No posee intencionalidad, libre albedrío o comprensión moral genuina en ningún sentido que la ley o la ética clásica reconozcan, y atribuirle agencia oscurece en lugar de aclarar dónde reside realmente la responsabilidad. Debido a que las máquinas carecen de personalidad jurídica y capacidad para el mens rea, la responsabilidad penal no puede atribuirse al sistema en sí.
Lo que se ha observado en cambio es la formación de una "zona de deformación moral", donde un humano posicionado más cerca de la falla, un conductor de seguridad que monitorea un sistema automatizado, por ejemplo, absorbe la culpa legal y moral de manera desproporcionada a su contribución causal real, mientras que las decisiones de ingeniería y organizacionales sistémicas que realmente produjeron la condición de falla escapan a un escrutinio equivalente. Esa asimetría es un modo real de falla de responsabilidad, no una consecuencia aceptable de operar tecnología avanzada.
El accidente de Uber ATG como estudio de caso de ingeniería y organizacional
El accidente fatal de Uber ATG en 2018 en Tempe, Arizona, se caracteriza erróneamente con frecuencia en la discusión pública como un dilema del tranvía del mundo real. La investigación técnica real cuenta una historia considerablemente menos interesante desde el punto de vista filosófico y considerablemente más instructiva desde el punto de vista práctico: una falla en la pila de percepción agravada por una falla en la cultura de seguridad organizacional.
La clasificación del sistema de conducción automatizada de una mujer que cruzaba la calle mientras caminaba con una bicicleta osciló repetidamente entre "vehículo", "bicicleta" y "otro" a medida que el objeto se movía por la escena. Cada reclasificación restablecía la predicción de trayectoria del sistema para ese objeto, y ese ciclo de reinicio, no una elección deliberada al estilo del tranvía, es lo que retrasó la respuesta de frenado adecuada hasta que fue demasiado tarde. Este es un modo de falla genuinamente bien entendido en los procesos de seguimiento y clasificación de múltiples objetos, donde las predicciones de clase inestables corrompen la predicción de movimiento aguas abajo, y es exactamente el tipo de problema que una arquitectura de fusión de sensores más madura con restricciones de consistencia temporal más fuertes en fotogramas consecutivos debería haber detectado en las pruebas de validación mucho antes del despliegue en la vía pública.
Superpuesta directamente sobre esa falla técnica hubo una falla organizacional separada, y posiblemente más condenatoria: Uber había suprimido las notificaciones de alerta de emergencia al conductor de seguridad humano específicamente para reducir la "fatiga de alarma" por falsas alarmas frecuentes, y los deberes de seguridad operativa para ese rol de conductor de seguridad no estaban definidos de manera clara o rigurosa en primer lugar. Ninguna de esas decisiones organizacionales aparece en un análisis técnico de causa raíz de la pila de percepción por sí sola, y ese es precisamente el punto: un marco de responsabilidad completo tiene que examinar todo el ciclo de vida del sistema, no solo el software que se estaba ejecutando en el momento del impacto.
Definir la responsabilidad del rol a lo largo de todo el ciclo de vida
La responsabilidad significativa tiene que rastrearse explícitamente a través de cada etapa del desarrollo y operación del sistema: las organizaciones y procesos responsables de recopilar y curar los datos de entrenamiento, los ingenieros que diseñaron y validaron las arquitecturas de redes neuronales, los ingenieros de seguridad que compilaron y firmaron el caso de seguridad UL 4600, los ejecutivos que establecieron los cronogramas de despliegue y la tolerancia al riesgo bajo presión comercial, y los operadores de campo que gestionan realmente el sistema en condiciones del mundo real día a día.
Esa trazabilidad de ciclo de vida completo es exactamente la razón por la cual los estándares que exigen vías de decisión transparentes y reconstruibles, siendo IEEE P7001 el ejemplo directo más claro, importan más allá del interés técnico puro. Sin ese registro reconstruible, la investigación posterior al incidente no puede rastrear con precisión la responsabilidad causal a través de las etapas del ciclo de vida donde se originaron las condiciones de falla reales, y la responsabilidad colapsa sobre cualquier individuo que estuviera físicamente más cerca de la falla cuando ocurrió, que rara vez es donde realmente residía la responsabilidad de ingeniería real.
Hacia dónde debe ir esto realmente a partir de aquí
Desplegar sistemas autónomos críticos para la seguridad de manera responsable no es un problema que se resuelva resolviendo un experimento mental filosófico de manera más inteligente. Se resuelve a través del trabajo poco glamoroso, riguroso y genuinamente difícil del análisis de seguridad funcional a nivel de componentes bajo la norma ISO 26262, la cobertura de limitaciones ambientales y de rendimiento bajo SOTIF, la evaluación de riesgos a nivel de aplicación bajo el marco de robótica colaborativa unificado ISO 10218, la estructura de responsabilidad sociotécnica bajo IEEE P7000 y la argumentación de seguridad estructurada y respaldada por evidencia bajo marcos como UL 4600 y SACE.
Ninguno de estos marcos resuelve individualmente todo el problema, y esa es exactamente la razón por la cual las organizaciones de ingeniería serias los ejecutan en combinación en lugar de tratar cualquier estándar único como una cobertura suficiente. La conclusión honesta del caso de Uber ATG y de cada incidente posterior investigado con este nivel de rigor es la misma: la responsabilidad de lo que hacen estos sistemas no se transfiere a la máquina solo porque la máquina esté tomando las decisiones momento a momento. Permanece directamente con los humanos que diseñaron la pila de percepción, definieron los límites operativos, firmaron el caso de seguridad y establecieron las prioridades organizacionales bajo las cuales ocurrió realmente toda esa ingeniería. Integrar esa responsabilidad en el proceso desde el principio, en lugar de descubrir su ausencia después de una fatalidad, es el trabajo real que este campo aún tiene por delante.