Ganancias:
- Capacidad para explicar los marcos de seguridad funcional ISO 26262 e ISO 21448 (SOTIF) y sus efectos en sistemas que contienen inteligencia artificial.
- Capacidad para gestionar la privacidad de los datos, los datos del conductor, la ciberseguridad (ISO/SAE 21434) y los riesgos éticos en el contexto de la automoción.
- Capacidad para mantener la responsabilidad humana en las decisiones críticas para la seguridad al comprender que los resultados de la IA no sustituyen la aprobación de un ingeniero competente.
Estás en la unidad más crítica de este módulo. Hasta ahora hemos visto la IA como un acelerador desde el diseño hasta la fabricación, desde las pruebas hasta la cadena de suministro. Pero la pregunta decisiva en el ámbito del automóvil es: ¿este sistema perjudicará a alguien y quién es el responsable? Esta unidad cubre en lenguaje sencillo los marcos para el uso responsable de la IA en una industria crítica para la seguridad: seguridad funcional, SOTIF, ciberseguridad, privacidad y ética. El principio básico permanece constante: los resultados de la IA nunca reemplazan la aprobación de un ingeniero competente; La decisión y la responsabilidad críticas para la seguridad pertenecen al ser humano.
ISO 26262: seguridad funcional
ISO 26262 es la norma de seguridad funcional para sistemas eléctricos/electrónicos de vehículos de carretera. Seguridad funcional; Se trata de garantizar que cuando un sistema falla (un sensor se rompe, un software falla) no conduzca a una situación peligrosa.
En el centro de este estándar se encuentra ASIL (Nivel de integridad de seguridad automotriz). Un peligro se evalúa en tres dimensiones:
- Gravedad: ¿Qué tan malo sería si sucediera? (lesiones leves o muerte)
- Exposición: ¿Con qué frecuencia ocurre esto?
- Controlabilidad: ¿Hasta qué punto puede el conductor controlar la situación?
Estos tres combinados dan como resultado un nivel desde ASIL A (el más bajo) hasta ASIL D (el más alto, por ejemplo, frenado, dirección). A medida que aumenta el nivel, los requisitos de desarrollo, pruebas y documentación se vuelven más estrictos.
PRINCIPAL
sistema de muestra
Intensidad de requerimiento
A.
Mal funcionamiento de la iluminación interior
bajo
b.
luz trasera
medio
c.
Algunas funciones ADAS
alto
D.
Freno, dirección, airbag
más alto
Consejo: conocer el nivel PRINCIPAL de una función le indica cuánta atención requiere el uso de IA en esa función. NINGUNA decisión basada en la salida de IA en una función se puede aceptar sin una verificación de seguridad independiente.
ISO 21448 (SOTIF): seguridad de la función prevista
La seguridad funcional clásica (ISO 26262) se centra en la pregunta "¿qué pasa si falla el sistema?" Pero hay un nuevo problema en los sistemas de detección de inteligencia artificial: incluso si el sistema nunca falla, puede ser inadecuado. La cámara funciona bien pero no puede reconocer una losa nevada; El radar es sólido, pero ignora un vehículo parado como una señal fantasma. Aquí no hay ningún fallo de hardware/software; El problema está en el límite del alcance previsto de la función.
ISO 21448 - SOTIF (Seguridad de la funcionalidad prevista) aborda exactamente esta brecha: gestionar los riesgos que surgen de escenarios no reconocidos, límites de detección y situaciones imprevistas, incluso si el sistema funciona según lo diseñado. En la conducción autónoma/ADAS basada en IA, SOTIF es tan crítico como ISO 26262.
marco
Enfoque
ejemplo
ISO 26262
Riesgo por falla
El sensor se rompe, la señal desaparece
ISO 21448 (SOTIF)
Riesgo de insuficiencia/no reconocimiento
La cámara robusta no reconoce la losa nevada
ISO/SAE 21434
seguridad cibernética
Ataque al sistema, manipulación de datos.
Precaución: los modelos de IA son estadísticos; No pueden garantizar que "verán cada situación correctamente". SOTIF tiene como objetivo limitar los escenarios peligrosos desconocidos en estos sistemas inherentemente limitados y reducir el riesgo restante a un nivel aceptable. “El modelo tiene una precisión del 99,9%” no es una prueba de seguridad.
ISO/SAE 21434: ciberseguridad
Los vehículos conectados y definidos por software son vulnerables a los ciberataques. Un atacante remoto puede alterar el comando de freno, robar telemetría o engañar al modelo de detección (ataque adversario: hacer que el modelo lo reconozca mal colocando una pequeña pegatina en una placa). ISO/SAE 21434 es el marco de ingeniería para la ciberseguridad de los vehículos. En el contexto de la inteligencia artificial se destacan dos riesgos: engañar al modelo (adversario) y envenenar los datos de entrenamiento (datos envenenados). Los sistemas de IA críticos para la seguridad deben probarse contra estos ataques.
Privacidad y datos personales
El vehículo moderno es un “centro de datos sobre ruedas”: ubicación, comportamiento de conducción, audio e incluso cámara en la cabina. La mayor parte son datos personales y están cubiertos por KVKK (Türkiye) y GDPR (Europa). VIN (número de chasis) puede identificar un vehículo e indirectamente a su propietario. Principios básicos:
- Minimización de datos: recopile solo lo que se necesita.
- Limitación de finalidad: No utilizar los datos para fines distintos a aquel para el que fueron recopilados.
- Anonimización/seudonimización: eliminar o codificar información de identificación personal.
- Consentimiento explícito y transparencia: El conductor debe saber qué se recoge.
- Almacenamiento y transferencia seguros.
Precaución: Enviar VIN sin procesar, historial de ubicación o comportamiento de conducción a una herramienta de inteligencia artificial en la nube pública puede ser tanto una violación de la privacidad como un riesgo contractual. Cuando trabaje con estos datos, anonimícelos y utilice un entorno institucional protegido de datos.
Ética y responsabilidad del ingeniero.
La inteligencia artificial trae consigo algunos riesgos éticos:
- Sesgo: si en los datos de entrenamiento predominan ciertas condiciones (por ejemplo, durante el día, piel clara, ciertas carreteras regionales), el modelo puede funcionar mal en condiciones subrepresentadas (noche, condiciones diferentes). Esta es una vulnerabilidad.
- Exceso de confianza (sesgo de automatización): las personas confían ciegamente en la automatización y anulan su propio juicio. Si el ingeniero de pruebas deja de mirar los datos sin procesar solo porque la IA dice "aprobar", esta es una tendencia peligrosa.
- Pérdida de responsabilidad: "El modelo decidido" no es una defensa. Siempre debe haber una persona que firme detrás de la decisión.
Mini estudios de casos
Caso 1 - Límite SOTIF. El sistema de frenado automático de emergencia supera todas las pruebas de laboratorio sin fallos de funcionamiento. En el campo, bajo el sol bajo, un camión blanco confunde su remolque con el cielo y frena tarde. No se trata de un mal funcionamiento, sino de una vulnerabilidad SOTIF: el sistema está intacto pero el escenario está fuera del límite de detección. El equipo agrega este escenario a la biblioteca de pruebas y fortalece la fusión de radar. Conclusión: "Sin fallo" no es prueba de seguridad; La insuficiencia también es un riesgo.
Caso 2 - Datos sesgados. Se entrenó un modelo de detección de peatones predominantemente con datos diurnos; El recuerdo nocturno es significativamente menor. El equipo equilibra y reentrena los datos nocturnos y con poca luz e informa los escenarios nocturnos por separado. Conclusión: los datos desequilibrados crean una vulnerabilidad mortal en determinadas circunstancias.
Caso 3: Prevención de violaciones de la privacidad. Un analista está a punto de pegar datos de la flota en una herramienta pública de inteligencia artificial cuando nota que los datos contienen ubicaciones VIN y GPS sin procesar. Funciona en un entorno corporativo anonimizando los datos (vehículo_01..arac_50 en lugar de VIN, código de región en lugar de ubicación). Resultado: Un momento de atención evitó una grave violación del KVKK.
plantillas de mensajes
Plantilla 1 - PREVIA/evaluación preliminar de riesgos (borrador):
Rol: Usted es un consultor de seguridad funcional. Tarea: Prepara un borrador para ayudar en el análisis de peligros y riesgos para una función. Contexto: Función: frenado automático de emergencia; urbano e interurbano. Restricción: asignación exacta de ASIL; Dar una lista de preguntas y puntos de atención sobre las dimensiones de gravedad/exposición/controlabilidad; indique que la tarea final recae en el ingeniero de seguridad autorizado. Salida: Tamaño | pregunta de evaluación | tabla de notas de atención.
Plantilla 2 - Escaneo de escenario SOTIF:
Rol: Eres un experto en SOTIF. Tarea: enumerar escenarios en los que una función de detección podría estar "con el sistema intacto pero inadecuada". Contexto: Cámara + radar; sol bajo, nieve, salida de túnel, objetos inusuales. Salida: Escenario | por qué insuficiencia | recomendación de reducción.
Plantilla 3 - Control de privacidad:
Rol: Usted es consultor de protección de datos (KVKK/GDPR). Tarea: realizar una auditoría de privacidad antes de compartir un conjunto de datos. Contexto: telemetría de flotas; Las columnas contienen VIN, GPS y puntuación de conducción. Restricción: qué campos son datos personales, cómo deben anonimizarse, qué no debo compartir en absoluto; ordenar.Salida: Campo | riesgo | tabla de transacciones recomendada.
Plantilla 4: verificación de sesgo:
Rol: Usted es un auditor de equidad y seguridad de LD. Tarea: Dígame cómo buscar riesgo de sesgo en un modelo de detección. Contexto: Detección de peatones; datos de entrenamiento ponderados por día/ciudad. Salida: Condición a comprobar | medición | signo de riesgo.
Aviso débil / Aviso fuerte
Aviso débil:
¿Es seguro este sistema de frenado autónomo? Confirme.
Intentar obtener autorización de seguridad de IA es peligroso; La aprobación pertenece al ingeniero autorizado.
Potente mensaje:
Rol: Eres consultor de seguridad funcional y SOTIF. Tarea: Enumere qué preguntas debo hacer y qué evidencia debo recopilar en la evaluación de seguridad de mi función de frenado automático. Contexto: detección basada en IA; cámara+radar; ASIL puede ser alto. Restricción: 'Aprobar' el sistema; Proporcionar listas separadas de preguntas y evidencia en términos de ISO 26262 (defecto) y SOTIF (deficiencia); Enfatice que la aprobación final recae en el ingeniero de seguridad autorizado. Salida: Marco | pregunta | tabla de evidencia requerida.
Errores comunes
- Confundir "sin mal funcionamiento" con "seguro". La deficiencia de SOTIF puede matar sin funcionar mal.
- Obtener autorización de seguridad de IA. La aprobación y responsabilidad recae en el ingeniero autorizado.
- Confundir la precisión del modelo con prueba de seguridad. Una precisión del 99,9% no indica que se haya gestionado el riesgo restante.
- No proteger datos personales. VIN/ubicación/comportamiento de conducción está dentro del alcance de KVKK/GDPR.
- Ignorar los prejuicios y el exceso de confianza. Los datos desequilibrados y la confianza ciega en la automatización son vulnerabilidades.
En resumen
- ISO 26262 gestiona el riesgo por fallo (con ASIL), mientras que ISO 21448/SOTIF gestiona el riesgo por fallo sin fallo; Ambos son fundamentales en la detección de IA.
- Ciberseguridad ISO/SAE 21434; Los ataques adversarios y de envenenamiento de datos son amenazas específicas de la IA.
- La minimización de datos, la limitación de fines y la anonimización son obligatorias dentro del alcance de KVKK/GDPR; VIN/ubicación son datos personales.
- Los prejuicios, el exceso de confianza y la pérdida de responsabilidad son los principales riesgos éticos.
- La producción de IA no sustituye la aprobación de un ingeniero calificado; La decisión crítica para la seguridad y la firma siempre pertenecen a la persona.
Tarea de aplicación
Seleccione una función relacionada con la seguridad (p. ej., mantenerse en el carril). (1) Analice por qué el nivel de ASIL de esta función puede ser alto/bajo en las dimensiones de gravedad/exposición/controlabilidad. (2) Genere cinco escenarios de “sistema sólido pero inadecuado” con la Plantilla 2. (3) Audite la confidencialidad de un conjunto de datos relevante con la Plantilla 3. (4) Explique por qué decir “El modelo confirmado” no es una defensa.
lista de verificación
- [ ] Evalué las dimensiones REALES de la función (dejé la asignación exacta a la autoridad).
- [ ] Hice la distinción entre ISO 26262 (mal funcionamiento) y SOTIF (insuficiencia).
- [ ] He tenido en cuenta el riesgo de ciberseguridad (adversario/envenenamiento).
- [ ] Anonimicé y minimizé los datos personales.
- [] Verifiqué riesgos de sesgo y exceso de confianza.
- [ ] He confirmado que la autorización de seguridad la posee el ingeniero calificado.