Segurança Funcional, SOTIF, Ética e Privacidade — Inteligência Artificial em Engenharia Automotiva

Ganhos:

Capacidade de explicar a segurança funcional ISO 26262 e as estruturas ISO 21448 (SOTIF) e seus efeitos em sistemas que contêm inteligência artificial
Capacidade de gerenciar privacidade de dados, dados de motoristas, segurança cibernética (ISO/SAE 21434) e riscos éticos no contexto automotivo
Capacidade de manter a responsabilidade humana por decisões críticas de segurança, compreendendo que o resultado da IA não substitui a aprovação de um engenheiro competente

Você está na unidade mais crítica deste módulo. Até agora, vimos a IA como um acelerador desde a concepção até ao fabrico, desde os testes até à cadeia de abastecimento. Mas a questão decisiva no setor automotivo é: esse sistema prejudicará alguém e quem será o responsável? Esta unidade aborda, em linguagem simples, as estruturas para o uso responsável da IA em um setor onde a segurança é crítica: segurança funcional, SOTIF, segurança cibernética, privacidade e ética. O princípio fundamental permanece constante: os resultados da IA nunca substituem a aprovação de um engenheiro competente; A decisão e a responsabilidade críticas para a segurança pertencem ao ser humano.

ISO 26262: segurança funcional

ISO 26262 é a norma de segurança funcional para sistemas elétricos/eletrônicos de veículos rodoviários. Segurança funcional; Preocupa-se em garantir que quando um sistema falha (um sensor quebra, um software falha) não conduza a uma situação perigosa.

No centro desta norma está o ASIL (Nível de Integridade de Segurança Automotiva). Um perigo é avaliado em três dimensões:

Gravidade: quão ruim seria se isso acontecesse? (lesões leves ou morte)
Exposição: Com que frequência isso ocorre?
Controlabilidade: Quanto o motorista consegue controlar a situação?

Esses três combinados resultam em um nível de ASIL A (mais baixo) a ASIL D (mais alto, por exemplo, frenagem, direção). À medida que o nível aumenta, os requisitos de desenvolvimento, testes e documentação tornam-se mais rigorosos.

PRINCIPAL

sistema de amostra

Intensidade do requisito

Mau funcionamento da iluminação interna

baixo

luz traseira

médio

Algumas funções ADAS

alto

Freio, direção, airbag

mais alto

Dica: conhecer o nível PRINCIPAL de uma função informa quanta atenção o uso da IA nessa função requer. NENHUMA decisão baseada na saída de IA em uma função pode ser aceita sem verificação de segurança independente.

ISO 21448 (SOTIF): segurança da função pretendida

A segurança funcional clássica (ISO 26262) concentra-se na questão “o que acontece se o sistema falhar?” Mas há um novo problema nos sistemas de detecção de inteligência artificial: mesmo que o sistema nunca funcione mal, pode ser inadequado. A câmera funciona bem, mas não consegue reconhecer uma laje nevada; O radar é sólido, mas ignora um veículo parado como um sinal fantasma. Não há falha de hardware/software aqui; O problema está no limite do escopo pretendido da função.

A ISO 21448 – STIF (Safety Of The Intended Functionality) aborda exatamente esta lacuna: gerenciar riscos decorrentes de cenários não reconhecidos, limites de detecção e situações imprevistas, mesmo que o sistema funcione como projetado. Na direção autônoma/ADAS baseada em IA, o STIF é tão crítico quanto a ISO 26262.

Quadro

Foco

exemplo

ISO 26262

Risco devido a falha

Sensor quebra, sinal desaparece

ISO 21448 (SOTIF)

Risco de inadequação/não reconhecimento

Câmera robusta não reconhece laje nevada

ISO/SAE 21434

segurança cibernética

Ataque ao sistema, manipulação de dados

Cuidado: os modelos de IA são estatísticos; Eles não podem garantir que “verão todas as situações corretamente”. O STIF visa restringir cenários perigosos desconhecidos nestes sistemas inerentemente limitados e reduzir o risco remanescente a um nível aceitável. “O modelo é 99,9% preciso” não é uma prova de segurança.

ISO/SAE 21434: segurança cibernética

Veículos conectados e definidos por software são vulneráveis a ataques cibernéticos. Um atacante remoto pode alterar o comando do freio, roubar a telemetria ou enganar o modelo de detecção (ataque adversário: fazer com que o modelo o reconheça incorretamente, colocando um pequeno adesivo em uma placa). ISO/SAE 21434 é a estrutura de engenharia para segurança cibernética de veículos. No contexto da inteligência artificial, dois riscos se destacam: enganar o modelo (adversário) e envenenar os dados de treinamento (envenenamento de dados). Os sistemas de IA críticos para a segurança devem ser testados contra estes ataques.

Privacidade e dados pessoais

O veículo moderno é um “data center sobre rodas”: localização, comportamento de direção, áudio e até câmera na cabine. A maior parte são dados pessoais e são cobertos pela KVKK (Türkiye) e pelo GDPR (Europa). VIN (número do chassi) pode identificar um veículo e indiretamente seu proprietário. Princípios básicos:

Minimização de dados: Colete apenas o que é necessário.
Limitação da finalidade: Não utilize os dados para fins diferentes daquele para o qual foram recolhidos.
Anonimização/pseudonimização: Remova ou codifique informações de identificação pessoal.
Consentimento explícito e transparência: O motorista deve saber o que está sendo coletado.
Armazenamento e transferência seguros.

Cuidado: enviar VIN bruto, histórico de localização ou comportamento de direção para uma ferramenta de IA em nuvem pública pode ser uma violação de privacidade e um risco contratual. Ao trabalhar com esses dados, torne-os anônimos e utilize um ambiente institucional e protegido de dados.

Ética e responsabilidade do engenheiro

A inteligência artificial traz consigo alguns riscos éticos:

Viés: Se os dados de treinamento predominarem em determinadas condições (por exemplo, durante o dia, pele clara, certas estradas regionais), o modelo poderá ter um desempenho insatisfatório em condições sub-representadas (noite, condições diferentes). Esta é uma vulnerabilidade.
Excesso de confiança (viés de automação): as pessoas confiam cegamente na automação e ignoram seu próprio julgamento. Se o engenheiro de teste parar de olhar os dados brutos só porque a IA diz “aprovado”, esta é uma tendência perigosa.
Perda de responsabilidade: “O modelo decidiu” não é uma defesa. Sempre deve haver uma pessoa assinando por trás da decisão.

Miniestudos de caso

Caso 1 – Limite SOTIF. Um sistema automático de travagem de emergência passa em todos os testes laboratoriais, sem avarias. No campo, sob o sol baixo, um caminhão branco confunde seu trailer com o céu e freia tarde. Isto não é um mau funcionamento, mas uma vulnerabilidade STIF: o sistema está intacto, mas o cenário está fora do limite de detecção. A equipe adiciona este cenário à biblioteca de testes e fortalece a fusão de radares. Conclusão: “Sem falha” não é prova de segurança; A insuficiência também é um risco.

Caso 2 – Dados tendenciosos. Um modelo de detecção de pedestres foi treinado predominantemente com dados diurnos; A recordação noturna é significativamente menor. A equipe equilibra e treina novamente os dados noturnos e de pouca luz e relata os cenários noturnos separadamente. Conclusão: Dados desequilibrados criam uma vulnerabilidade mortal em determinadas circunstâncias.

Caso 3 – Prevenção de violação de privacidade. Um analista está prestes a colar dados da frota em uma ferramenta pública de IA quando percebe que os dados contêm VIN bruto e localizações GPS. Funciona em ambiente corporativo anonimizando os dados (veículo_01..arac_50 em vez de VIN, código de região em vez de localização). Resultado: Um momento de atenção evitou uma violação grave do KVKK.

modelos de prompt

Modelo 1 - Avaliação PRÉVIA/preliminar de risco (rascunho):

Função: Você é um consultor de segurança funcional. Tarefa: Prepara um rascunho para auxiliar na análise de perigos e riscos para uma função. Contexto: Função: frenagem automática de emergência; urbano e intermunicipal. Restrição: atribuição exata de ASIL; Forneça uma lista de dúvidas e pontos de atenção sobre as dimensões gravidade/exposição/controlabilidade; indicam que a atribuição final cabe ao engenheiro de segurança autorizado.Saída: Tamanho | questão de avaliação | tabela de notas de atenção.

Modelo 2 – Verificação do cenário STIF:

Função: Você é um especialista STIF. Tarefa: Listar cenários onde uma função de detecção pode estar “sistema intacto mas inadequado”. Contexto: Câmera + radar; sol baixo, neve, saída do túnel, objetos incomuns. Resultado: Cenário | por que inadequação | recomendação de redução.

Modelo 3 – Controle de privacidade:

Função: Você é um consultor de proteção de dados (KVKK/GDPR). Tarefa: Conduza uma auditoria de privacidade antes de compartilhar um conjunto de dados. Contexto: Telemetria de frota; As colunas contêm VIN, GPS e pontuação de direção. Restrição: quais campos são dados pessoais, como devem ser anonimizados, o que não devo compartilhar; sort.Saída: Campo | risco | gráfico de transações recomendado.

Modelo 4 - Verificação de polarização:

Função: você é um auditor de segurança e justiça de ML. Tarefa: Diga-me como procurar risco de viés em um modelo de detecção. Contexto: Detecção de peões; dados de treinamento ponderados por dia/cidade. Saída: Condição a ser verificada | medição | sinal de risco.

Alerta fraco / Alerta forte

Alerta fraco:

Este sistema de travagem autónomo é seguro, confirme.

Tentar obter autorização de segurança de IA é perigoso; A aprovação pertence ao engenheiro autorizado.

Alerta poderoso:

Função: Você é consultor de segurança funcional e STIF. Tarefa: Liste quais perguntas devo fazer e quais evidências devo coletar na avaliação de segurança da minha função de frenagem automática. Contexto: detecção baseada em IA; câmera+radar; ASIL pode ser alto. Restrição: 'Aprovar' o sistema; Fornecer listas separadas de perguntas e evidências em termos de ISO 26262 (defeito) e SOTIF (deficiência); Enfatize que a aprovação final cabe ao engenheiro de segurança autorizado.Resultado: Estrutura | pergunta | tabela de evidências exigidas.

Erros comuns

Confundir “sem mau funcionamento” com “seguro”. A deficiência de STIF pode matar sem funcionar mal.
Obtendo autorização de segurança de IA. A aprovação e a responsabilidade são do engenheiro autorizado.
Confundir a precisão do modelo com prova de segurança. Uma precisão de 99,9% não indica que o risco restante tenha sido gerido.
Não proteger dados pessoais. VIN/localização/comportamento de direção está dentro do escopo do KVKK/GDPR.
Ignorando preconceitos e excesso de confiança. Dados desequilibrados e confiança cega na automação são vulnerabilidades.

Em resumo

A ISO 26262 gerencia o risco devido a falha (com ASIL), enquanto a ISO 21448/SOTIF gerencia o risco de falha sem falha; Ambos são críticos na detecção de IA.
Segurança cibernética ISO/SAE 21434; ataques adversários e de envenenamento de dados são ameaças específicas da IA.
A minimização de dados, a limitação da finalidade e a anonimização são obrigatórias no âmbito do KVKK/GDPR; VIN/localização são dados pessoais.
Preconceito, excesso de confiança e perda de responsabilidade são os principais riscos éticos.
A produção de IA não substitui a aprovação de um engenheiro qualificado; A decisão e a assinatura críticas para a segurança sempre pertencem à pessoa.

Tarefa de aplicativo

Selecione uma função relacionada à segurança (por exemplo, manutenção de faixa). (1) Discuta por que o nível ASIL desta função pode ser alto/baixo ao longo das dimensões gravidade/exposição/controlabilidade. (2) Gere 5 cenários de “sistema sólido, mas inadequado” com o Modelo 2. (3) Audite a confidencialidade de um conjunto de dados relevante com o Modelo 3. (4) Explique por que dizer “O modelo confirmado” não é uma defesa.

lista de verificação

[ ] Avaliei as dimensões REAIS da função (deixei a atribuição exata para a autoridade).
[ ] Fiz a distinção entre ISO 26262 (mau funcionamento) e STIF (insuficiência).
[ ] Levei em consideração o risco de segurança cibernética (adversário/envenenamento).
[ ] Anonimizei e minimizei os dados pessoais.
[ ] Verifiquei riscos de preconceito e excesso de confiança.
[ ] Confirmei que a autorização de segurança está com o engenheiro qualificado.