Segurança, redundância e regulamentação

Segurança é uma alegação estruturada sobre uma função, um veículo, um domínio operacional e uma versão definidos, apoiada por evidências antes da implantação e por dados monitorados depois. Ela abrange segurança funcional, limitações dos sensores, fatores humanos, segurança cibernética, operações e regulamentação; nenhuma demonstração, teste ou quilometragem cobre tudo.

Comece por um caso de segurança

Um caso de segurança é um argumento fundamentado, apoiado por evidências, de que um sistema é aceitavelmente seguro para um uso e ambiente específicos. Ele conecta alegações de alto nível a perigos, requisitos, testes, resultados e controles operacionais.

O escopo deve ser exato. Evidências de um serviço em baixa velocidade e condições secas não estabelecem segurança em uma rodovia com neve. Evidências de uma plataforma de veículo ou versão de software não são transferidas automaticamente para outra.

Os desenvolvedores usam estruturas diferentes, mas um caso de segurança confiável deve abordar pelo menos:

comportamento competente durante a operação normal;
detecção e gestão de falhas;
limites da funcionalidade pretendida e da percepção;
interação segura com usuários e outros usuários da via;
práticas operacionais, manutenção e resposta a incidentes;
segurança cibernética e atualizações de software controladas; e
evidências de que o risco em serviço continua aceitável.

Os resumos públicos são úteis para análise, mas não constituem o caso completo nem substituem a avaliação regulatória.

Várias disciplinas de segurança se sobrepõem

A segurança funcional aborda perigos causados pelo mau funcionamento de sistemas elétricos e eletrônicos. A ISO 26262 fornece a estrutura do ciclo de vida automotivo para esse trabalho.

A segurança da funcionalidade pretendida, coberta pela ISO 21448, aborda perigos quando um sistema funciona conforme projetado, mas a especificação, o desempenho dos sensores ou o algoritmo são insuficientes para a situação.

A segurança da IA em veículos rodoviários, abordada pela ISO/PAS 8800, cobre riscos de resultados insuficientes da IA, erros sistemáticos e erros aleatórios do hardware.

A engenharia de segurança cibernética, coberta pela ISO/SAE 21434, gerencia o risco de segurança cibernética do veículo durante todo o ciclo de vida.

Essas disciplinas se complementam, em vez de se substituírem. Uma câmera perfeitamente confiável ainda pode ser incapaz de classificar uma situação inédita. Um modelo de percepção capaz ainda pode ser inseguro se uma atualização comprometida o alterar.

A redundância deve responder à falha

A redundância só é útil quando o caminho alternativo sobrevive à falha considerada. Dois computadores em uma única fonte de alimentação não protegem contra a perda dessa fonte. Duas câmeras atrás da mesma obstrução não protegem contra a visão bloqueada.

As arquiteturas de maior automação podem separar:

caminhos de alimentação elétrica e comunicação;
modalidades de detecção e campos de visão;
computação principal e monitoramento de segurança independente;
caminhos de acionamento da direção e da frenagem;
fontes de localização; e
controle normal e controle de risco mínimo.

A análise de segurança determina onde são necessárias diversidade ou separação. Mais componentes também podem criar mais interfaces e modos de falha, portanto a quantidade de hardware não é uma medida de segurança.

O objetivo é a degradação controlada. O veículo deve detectar a falha, conservar a capacidade necessária para a situação imediata e alcançar a condição de risco mínimo definida.

A dependência humana muda conforme o nível

No nível 2, o ser humano faz parte do circuito de controle e deve monitorar continuamente a via. A segurança depende dos limites de capacidade, de instruções claras, do monitoramento do motorista, de alertas oportunos e da proteção contra uso indevido previsível. Isso continua verdadeiro quando um sistema de ponto a ponto segue uma rota até o destino, faz conversões em cruzamentos e para diante de controles de tráfego.

No nível 3, o usuário pode desviar a atenção, mas deve continuar disponível. O sistema precisa de uma transição administrada que considere o tempo necessário para recuperar a consciência da situação.

No nível 4, pode não haver motorista. O sistema e seu suporte operacional devem administrar a contingência. A assistência remota pode fornecer contexto, mas não deve ser apresentada como autonomia se uma pessoa remota estiver realmente executando a tarefa de condução.

A confusão de modo é um perigo. A interface deve deixar claro se o ser humano ou o sistema está dirigindo, o que o sistema pode fazer no momento e qual resposta espera.

A validação precisa de evidências complementares

Nenhum teste prático em vias públicas consegue encontrar todos os cenários importantes com frequência estatística útil. Nenhuma simulação representa perfeitamente a realidade.

Um programa maduro combina:

análise de requisitos e projeto;
testes de componentes e integração;
testes de software e hardware no circuito;
simulação de cenários e reprodução de dados gravados;
testes em pista fechada;
testes supervisionados em vias públicas;
análise independente e testes regulatórios; e
desempenho monitorado em serviço.

Os testes de cenário respondem se o veículo lida com perigos definidos. Os dados de exposição mostram como o sistema implantado funciona na operação real. Ambos precisam de denominadores e escopo.

Um milhão de quilômetros em rodovias não pode validar uma alegação sobre cruzamentos urbanos. Uma baixa quantidade de acidentes não é informativa sem distância, tipo de via, gravidade, limite de notificação e uma referência humana comparável. Os resultados divulgados por empresas devem ser lidos com a metodologia publicada e sua incerteza.

O painel público Safety Impact da Waymo é um bom exemplo de relatório baseado em exposição, pois fornece distância percorrida somente com passageiros, definições de resultados, métodos de referência humana e dados para download. Ainda é evidência para os domínios de serviço da Waymo, não uma prova de que todo projeto de condução automatizada seja seguro.

Segurança cibernética e atualizações são questões de segurança

Os veículos conectados expõem interfaces por meio de diagnósticos, aplicativos, redes sem fio, serviços em nuvem e software da cadeia de fornecedores. Um invasor ou uma atualização corrompida pode afetar a confidencialidade, a disponibilidade ou o comportamento físico.

Por isso, a segurança abrange arquitetura, autenticação, inicialização segura, gestão de chaves, controle de acesso, monitoramento, resposta a vulnerabilidades e processos dos fornecedores. A privacidade está relacionada, mas é distinta: o sistema pode ser seguro e coletar mais dados sobre ocupantes ou ruas do que os usuários esperam.

Os Regulamentos da ONU 155 e 156 estabelecem estruturas para os sistemas de gestão de segurança cibernética e de atualizações de software dos fabricantes nos mercados que os aplicam. Uma atualização remota de uma função de condução deve ser rastreável, autenticada, validada e monitorada. A expansão do domínio operacional é uma mudança de produto relevante para a segurança, não uma manutenção rotineira do sistema de informação e entretenimento.

A aprovação acompanha a função e a jurisdição

“Aprovado” pode se referir a diferentes etapas legais:

homologação de tipo de um veículo ou componente;
permissão para testar em vias públicas;
autorização para operar um serviço comercial sem motorista;
reconhecimento de uma homologação de outro país; ou
cumprimento das regras de trânsito que determinam o que o ser humano pode fazer.

Essas etapas não são intercambiáveis. Um nível SAE descreve a divisão da tarefa de condução e da contingência; não é um certificado de homologação.

Para assistência controlada pelo motorista, o Regulamento da ONU 171 estabelece requisitos para Driver Control Assistance Systems nos mercados que o aplicam. O WP.29 adotou uma segunda série de emendas em junho de 2026, como parte do desenvolvimento contínuo dessas regras. Como o motorista continua responsável, um sistema aprovado por uma via de nível 2 ou de controle pelo motorista não se torna um Automated Driving System apenas por seguir uma rota ou lidar com cruzamentos urbanos.

O Regulamento da ONU 157 abrange Automated Lane Keeping Systems e proporcionou uma via para funções rodoviárias de nível 3 aprovadas nos mercados que o aplicam. O Regulamento de Execução 2022/1426 da União Europeia estabelece regras de homologação para veículos totalmente automatizados em casos de uso definidos, incluindo áreas predefinidas, rotas entre centros e estacionamento automatizado com manobrista.

Tesla FSD (Supervised) na Europa

Em 10 de abril de 2026, a autoridade neerlandesa de veículos RDW concedeu ao Tesla FSD (Supervised) uma homologação europeia com validade provisória nos Países Baixos. A RDW o descreve como um sistema de assistência controlado pelo motorista, não como autônomo: o motorista continua responsável, deve monitorar o tráfego e ser capaz de assumir o controle imediatamente.

A RDW também afirma que as versões europeia e norte-americana não são diretamente comparáveis. Portanto, a avaliação europeia não aprova todos os recursos FSD ou versões de software vendidos em outros lugares.

A decisão neerlandesa não foi uma aprovação geral em toda a UE. A RDW declarou que uma validade mais ampla exige apresentação à Comissão Europeia, votação pelos Estados-Membros e apoio majoritário no comitê responsável. Até que esse processo seja concluído, a autorização ou o reconhecimento nacional deve ser verificado país por país.

A estrutura da ONU de junho de 2026 para ADS sem motorista

Em 24 de junho de 2026, o Fórum Mundial da UNECE para Harmonização dos Regulamentos de Veículos, WP.29, adotou a primeira estrutura regulatória mundial para Automated Driving Systems totalmente sem motorista. A decisão incluiu um novo Regulamento da ONU nos termos do Acordo de 1958 e um Regulamento Técnico Mundial paralelo nos termos do Acordo de 1998, acompanhados de alterações em cerca de noventa regulamentos existentes da ONU para veículos.

A estrutura aborda sistemas que executam toda a tarefa dinâmica de condução, não a assistência supervisionada de nível 2. Seus requisitos principais incluem:

um sistema de gestão da segurança auditado durante todo o ciclo de vida;
um caso de segurança estruturado que demonstre ausência de risco injustificável;
validação confiável por simulação, em pista e no mundo real;
desempenho igual ou superior ao de um motorista humano competente;
monitoramento e relatórios contínuos em serviço; e
armazenamento de dados de condução automatizada relevantes para a segurança.

A estrutura pode abranger domínios operacionais rodoviários e urbanos e acomodar veículos sem controles convencionais. É um passo importante de harmonização, pois fabricantes e autoridades agora dispõem de uma estrutura comum de segurança, orientada por resultados, para a aprovação de ADS.

Não é uma única autorização mundial. As partes contratantes ainda devem implementar os instrumentos aplicáveis, aprovar sistemas específicos e determinar onde a operação sem motorista é legal. As leis de trânsito locais, as licenças de operação e as condições do serviço continuam relevantes. A decisão também não reclassifica FSD (Supervised), City NOA ou outras funções supervisionadas continuamente como condução autônoma.

Os Estados Unidos seguem um caminho diferente

Nos Estados Unidos, interagem a supervisão federal da segurança dos veículos, a legislação operacional dos estados e as regras locais de implantação. Em geral, os fabricantes autocertificam o cumprimento das normas federais de segurança dos veículos, enquanto os reguladores investigam defeitos e aplicam os requisitos durante o uso.

A Standing General Order da NHTSA exige a notificação de determinados acidentes envolvendo sistemas de nível 2 e sistemas de condução automatizada. As autoridades estaduais e locais podem regular separadamente os testes e a operação comercial sem motorista. Uma isenção federal, uma licença estadual de testes e a permissão para transportar passageiros pagantes são decisões diferentes.

Como é uma comunicação confiável sobre segurança

Uma alegação pública sólida informa:

o nível exato de automação e o papel do ser humano;
o veículo, o hardware, a versão do software e o domínio operacional;
o comportamento de contingência e de risco mínimo;
a homologação ou licença efetivamente obtida;
o território onde ela é válida;
as evidências de testes e operação, com denominadores;
exclusões conhecidas e limitações não resolvidas; e
como incidentes e atualizações são monitorados.

Afirmações vagas como “mais seguro que os humanos” são incompletas sem domínio comparável, definição dos resultados, exposição e incerteza. A segurança não é uma linha de chegada atingida uma única vez. O caso deve ser mantido conforme software, hardware, vias e operações mudam.