De Modelos Estocásticos à Garantia Determinística: Um Framework Estratégico para Inteligência Artificial de Segurança Crítica

O panorama contemporâneo da inteligência artificial está atualmente bipartido por um mal-entendido fundamental sobre profundidade técnica. De um lado dessa divisão encontra-se a rápida proliferação de camadas de interface generativa—frequentemente caracterizadas como "wrappers" de Large Language Model (LLM)—que priorizam a implantação rápida e a fluidez conversacional. Do lado oposto está a disciplina rigorosa da engenharia de Deep AI, um campo definido pela integração de verificação formal, resiliência de fusão de sensores e arquiteturas de segurança determinísticas. Para líderes empresariais que navegam essa transição, a distinção não é mais meramente acadêmica. À medida que sistemas autônomos passam de ambientes digitais para implantações físicas de alto risco, as limitações das abordagens probabilísticas baseadas em "wrappers" foram expostas por uma série de falhas de alto perfil.

Os incidentes envolvendo o Uber Advanced Technologies Group (ATG), a GM Cruise, a Tesla e a Waymo servem como dados empíricos críticos para esta análise. Esses eventos representam mais do que acidentes isolados; são indicadores sistêmicos de fragilidade arquitetural. O acordo de $8.5 million envolvendo a Uber ATG após a fatalidade de Tempe em 2018, a revogação da permissão de operação da GM Cruise na Califórnia em 2023 e as investigações em andamento da National Highway Traffic Safety Administration (NHTSA) sobre o sistema Full Self-Driving (FSD) da Tesla são todos sintomas de uma "Lacuna Percepção-Lógica".¹ Este relatório analisa essas falhas para estabelecer um novo paradigma para IA de segurança crítica—um que posiciona a Veriprajna não como facilitadora de interfaces estocásticas, mas como provedora de autonomia profunda e verificável.

A Fragilidade Arquitetural da Percepção Estocástica: Lições da Uber ATG

A colisão de março de 2018 em Tempe, Arizona, envolvendo um veículo de teste da Uber ATG, permanece o estudo de caso fundacional sobre a fragilidade da classificação. Embora a narrativa da época tenha se concentrado fortemente na distração do operador humano de segurança, as conclusões da National Transportation Safety Board (NTSB) revelaram uma falha muito mais profunda na capacidade do software de manter uma representação estável do mundo físico.³

Oscilação de Classificação e a Falha da Permanência do Objeto

O sistema da Uber ATG registrou pela primeira vez a pedestre, Elaine Herzberg, aproximadamente 5.6 segundos antes do impacto.⁵ A uma velocidade de 43 mph, o veículo estava a quase 378 pés de distância, proporcionando uma janela ampla para que um sistema padrão de Automatic Emergency Braking (AEB) interviesse.⁷ Contudo, a lógica de percepção do sistema era caracterizada por "oscilação de classificação". Nos segundos que antecederam o choque, o software reclassificou repetidamente a pedestre—primeiro como um "objeto desconhecido", depois como um "veículo" e, finalmente, como uma "bicicleta".⁶

Cada reclassificação não era meramente uma mudança de rótulo; era um reinício da trajetória prevista do objeto. Em sistemas probabilísticos sem consistência temporal, a IA trata cada quadro ou agrupamento de quadros como um evento quase independente. Como o sistema não conseguia estabelecer uma identidade persistente para o objeto, não podia calcular uma predição de trajetória confiável até que fosse tarde demais. O sistema determinou que a frenagem de emergência era necessária apenas 1.3 segundos antes do impacto—um ponto em que as leis da física tornavam a colisão inevitável.³

Dívida Técnica e a Remoção da Redundância de Segurança

Um elemento crítico da falha da Uber ATG foi a desativação intencional dos sistemas nativos de segurança do veículo. Para prevenir "comportamento errático do veículo" e proporcionar uma condução mais suave para o sistema autônomo, a Uber havia desabilitado os recursos de prevenção de colisão e AEB instalados de fábrica no Volvo XC90.⁴ A equipe de engenharia optou por depender inteiramente de um sistema proprietário, em desenvolvimento, que ainda não estava verificado para intervenção de alta confiança.

Componente da Falha	Mecanismo Técnico	Implicação Estratégica
Pipeline de Percepção	Oscilação de classificação (Desconhecido -> Veículo -> Bicicleta)	A perda da permanência do objeto desabilita a predição de trajetória.6
Supressão de Lógica	Desativação manual do AEB de fábrica da Volvo	Remoção de camadas de segurança rigidamente codificadas em favor de código experimental.4
Interface HMI	Dependência excessiva de um monitor humano distraído	Falha em considerar a "complacência da automação".3
Motor de Predição	Premissa de trajetória estática para atores dinâmicos	Incapacidade de modelar travessias de pedestres não padronizadas.5

Esse processo de tomada de decisão ilustra uma tendência perigosa no desenvolvimento de IA: o sacrifício de camadas de segurança determinísticas em nome de um desempenho "suave" em um modelo estocástico. O acordo de $8.5 million pelo acidente de 2018 reflete não apenas uma responsabilidade legal, mas uma falha em gerenciar as "limitações funcionais" do sistema de condução automatizada.⁴ A engenharia de Deep AI, conforme defendida pela Veriprajna, argumenta contra essa hierarquia, advogando por uma arquitetura "Segurança em Primeiro Lugar" em que a camada de percepção está vinculada a restrições formais que não podem ser sobrescritas por uma política experimental.

Diagnóstico Equivocado e a Falha da Lógica Pós-Impacto: A Crise da Cruise em 2023

Em outubro de 2023, um robotáxi da GM Cruise em São Francisco atropelou e arrastou uma pedestre por 20 pés, levando à suspensão total das operações sem motorista da empresa na Califórnia.⁹ Esse incidente avançou além do problema da prevenção inicial de colisão para o território do "raciocínio pós-impacto"—um domínio em que wrappers de LLM típicos e APIs simples de percepção falham por completo.

A Falácia do Atropelamento Frontal vs. Impacto Lateral

O incidente da Cruise foi iniciado por um terceiro: um Nissan conduzido por um humano atingiu uma pedestre, lançando-a na trajetória do veículo da Cruise.⁹ O carro da Cruise atingiu a pedestre e inicialmente parou. Contudo, como a lógica de "detecção de impacto" do sistema era insuficientemente granular, diagnosticou equivocadamente a colisão. Apesar de a pedestre estar presa sob o veículo, os sensores do sistema falharam em reconhecer um atropelamento frontal e, em vez disso, categorizaram o evento como uma colisão de impacto lateral.¹

Esse diagnóstico equivocado disparou uma manobra pré-programada de "Minimal Risk Condition" (MRC). O sistema foi projetado para se deslocar para o lado da via após um impacto lateral a fim de evitar o bloqueio do trânsito.¹¹ Como a camada de percepção havia "esquecido" a pedestre após o impacto, o veículo começou a se deslocar para o lado, arrastando a vítima 20 pés a aproximadamente 7 mph.⁹ O arrastamento cessou somente quando o veículo detectou "patinagem excessiva das rodas", que interpretou como uma falha mecânica em vez de uma obstrução humana.¹¹

Transparência como Requisito Técnico

A falha da Cruise foi tanto uma falha organizacional quanto técnica. Investigações revelaram que a alta liderança estava "obcecada em corrigir a narrativa imprecisa da mídia" e falhou em ser transparente com os reguladores em relação ao arrastamento.⁹ Funcionários da Cruise admitiram "deixar o vídeo falar por si" durante reuniões com o DMV, sabendo que problemas de conectividade com a internet frequentemente impediam que a porção de "arrastamento" do vídeo fosse reproduzida.⁹

Isso evidencia uma lição crítica para a consultoria de Deep AI: a segurança de um sistema autônomo é inseparável de sua transparência. A abordagem da Veriprajna enfatiza o desenvolvimento de "Auditorias de Segurança Explicáveis", em que cada decisão tomada pela IA, especialmente pós-impacto, é registrada em um formato determinístico à prova de adulteração que pode ser auditado por reguladores em tempo real. A multa criminal subsequente de $500,000 por apresentar relatórios falsos à NHTSA sublinha o alto custo de tratar a segurança da IA como um problema de marketing em vez de um problema de engenharia.¹

O Dilema "Vision-Only" e os Limites do Sensoriamento Probabilístico: Tesla FSD

O sistema Full Self-Driving (FSD) da Tesla tornou-se o centro de uma investigação regulatória massiva, com a NHTSA abrindo mais de 40 inquéritos sobre acidentes entre 2024 e 2025.² Essas investigações, particularmente as identificadas como PE24-031 e PE25-012, concentram-se na falha do sistema em "Teatro de Capacidade"—desempenho ótimo em condições claras que entra em colapso diante de "casos extremos" ambientais.¹³

Sensibilidade Ambiental e Não Conformidade com Sinais

As investigações da NHTSA identificaram padrões específicos em que o sistema vision-only da Tesla falha em cumprir leis básicas de segurança no trânsito:

1. Falha de Sinal de Trânsito: Em 18 reclamações distintas, veículos habilitados com FSD falharam em permanecer parados em semáforos vermelhos ou falharam em detectar o estado do sinal por completo.¹²
2. Manobras no Sentido Contrário: O sistema foi observado entrando em faixas de tráfego oposto ou executando conversões a partir de faixas exclusivas de seguimento, desconsiderando marcações viárias e sinalização claras.²
3. Saturação em Baixa Visibilidade: Uma colisão fatal significativa em 2023 ocorreu durante um estado de "ofuscamento solar em asfalto molhado", em que o sistema falhou em detectar um pedestre.¹⁴

A dependência da Tesla de uma arquitetura "Vision-Only"—dispensando LiDAR e radar—cria uma vulnerabilidade fundamental à "saturação de sensores". Em condições de neblina, poeira ou detritos suspensos, a relação sinal-ruído óptica cai abaixo do limiar exigido para navegação segura.¹³ Embora a Tesla utilize "Redes de Ocupação" para prever a geometria 3D do mundo a partir de imagens 2D, os relatórios da NHTSA sugerem que essas previsões ainda são demasiado probabilísticas para serem usadas como camada primária de segurança.¹⁵

Formalizando o Ambiente de Condução

Para ir além do modelo de falha da Tesla, a engenharia de Deep AI utiliza "Envelopes Orientados a Perigos". Em vez de "recursos" vagos, o sistema deve definir Operational Design Domains (ODD) explícitos. Se o "percentual de saturação por ofuscamento" ou o "índice de retroespalhamento de neblina" exceder um limiar verificado, o sistema deve iniciar uma transição à prova de falhas.¹⁴

Modo de Falha Investigado	Frequência/Impacto	Causa Técnica
Não Conformidade com Semáforo Vermelho	18+ Reclamações	Falha de detecção do estado do sinal na pilha de visão.12
Violação de Marcação de Faixa	4+ Relatórios SGO	Incapacidade de distinguir faixas exclusivas de conversão vs. faixas de seguimento.12
Acidente em Baixa Visibilidade	Fatalidades (2023-2024)	Saturação de sensor óptico (ofuscamento/neblina/poeira).13
Entrada em Faixa Oposta	2 Relatórios SGO	Falha na reconstrução 3D da geometria da faixa.12

A filosofia da Veriprajna é que a autonomia não pode ser construída sobre software de "melhor esforço". Os 2.9 milhões de veículos impactados pela investigação da NHTSA de 2025 representam um risco em toda a frota que só pode ser mitigado pela implementação de "Travas de Garantia"—bloqueios de software que impedem a IA de tomar decisões de alto risco quando o nível de confiança de seu sistema de percepção cai abaixo de um ponto determinístico.²

Impasse Multiagente e Resiliência Sociotécnica: A Experiência da Waymo

A Waymo é frequentemente considerada o referencial de segurança, tendo registrado mais de 56 milhões de milhas com taxas de lesão significativamente menores do que motoristas humanos.¹⁷ Contudo, à medida que o sistema escala, encontrou uma nova classe de falha: "atrito sociotécnico". Isso envolve não apenas como a IA dirige, mas como ela interage com o ambiente social humano complexo e, frequentemente, hostil.

Bloqueios em Interseções e Falhas de Comunicação

Durante um apagão em 2025 em Los Angeles, dezenas de robotáxis da Waymo ficaram presos em uma série de interseções sem iluminação. O "Waymo Driver", programado para tratar sinais apagados como paradas de quatro vias, ficou sobrecarregado pelo pico concentrado de solicitações de "Assistência Remota".¹⁸ Como os veículos não conseguiam se comunicar uns com os outros de forma eficaz, entraram em um estado de "impasse multiagente", em que robotáxis bloqueavam outros robotáxis, criando um congestionamento que o centro de comando central não conseguia resolver.¹⁸

Essa falha evidencia a "Armadilha da Independência"—a premissa de que um veículo autônomo pode operar com segurança como um agente solitário sem um sistema mais amplo e coordenado.¹⁸ A engenharia de Deep AI deve considerar a perda de comunicação sem fio e a necessidade de protocolos "V2V" (Vehicle-to-Vehicle) e "V2I" (Vehicle-to-Infrastructure) que permitam à frota resolver impasses de forma autônoma.²⁰

A Necessidade do "Modo de Fuga de Perigo"

Talvez a ameaça emergente mais significativa às operações autônomas seja a agressão pública. No início de 2025, vários veículos da Waymo foram atacados por multidões durante distúrbios civis em Los Angeles, com manifestantes cortando pneus e incendiando veículos.²¹ Os veículos, programados para "segurança passiva", simplesmente pararam quando cercados por pessoas.

Isso levou à proposta de desenvolvimento de um "Modo de Fuga de Perigo". Tal sistema usaria o conjunto de sensores de 360 graus para detectar "agressão humana maliciosa" e deslocar a diretriz do veículo de "conformidade passiva" para "fuga ativa".²¹ Embora o veículo nunca deva ser programado para causar dano, provedores de Deep AI argumentam que ele deveria ser capaz de cometer infrações de trânsito menores (como subir na calçada ou atravessar um sinal vermelho) para proteger seus passageiros e escapar de uma situação volátil.²¹ Isso exige uma reformulação radical do "Motor de Ética" da IA—uma tarefa que vai muito além das capacidades de um wrapper de LLM.

A Solução Técnica: Bird's-Eye-View (BEV) e Redes de Ocupação

Para abordar as falhas de rastreamento observadas nos casos da Uber e da Cruise, a indústria está migrando para a percepção Bird's-Eye-View (BEV). Sistemas padrão por câmera processam imagens individuais, o que leva à perda de dados durante o "stitching". Em contraste, a percepção BEV transforma dados de câmeras em múltiplas vistas e de LiDAR em uma grade 3D unificada, de cima para baixo.²²

Redes de Ocupação vs. Fusão de Sensores Padrão

A fusão de sensores tradicional tenta "associar" pixels 2D a pontos 3D, um processo computacionalmente caro e propenso a erros de projeção. A Veriprajna defende as "Redes de Ocupação"—uma arquitetura que prediz a "probabilidade de ocupação" de cada voxel em um volume 3D.¹⁶

1. Permanência do Objeto: Como as redes de ocupação rastreiam volume em vez de apenas "rótulos", o sistema sabe que um espaço está ocupado mesmo que não consiga decidir se o objeto é um pedestre ou uma bicicleta. Isso teria prevenido a inversão de classificação da Uber ATG.¹⁶
2. Fidelidade Geométrica: As redes de ocupação capturam estruturas verticais e detritos na via que frequentemente são ignorados por mapas BEV 2D. Isso teria permitido ao veículo da Cruise "ver" a pedestre sob seu chassi durante a manobra pós-impacto.¹⁶
3. Consistência Espaciotemporal: Usando arquiteturas "BEVFormer", o sistema pode usar "autoatenção temporal" para lembrar onde um objeto estava mesmo durante oclusões temporárias (p. ex., um pedestre caminhando atrás de um caminhão estacionado).²⁴

$$X_{BEV} = f_{transformer}(I_1, I_2, ..., I_n, L_{cloud})$$

Nesse modelo, a arquitetura Transformer serve não como ferramenta conversacional, mas como um motor de raciocínio espacial que funde dados heterogêneos em uma "Tela Compartilhada" singular.²³ Isto é engenharia de Deep AI: o uso de arquiteturas de fronteira para resolver problemas fundamentais de física na navegação.

Verificação Formal: O Padrão Veriprajna para IA de Alta Garantia

O diferenciador mais significativo entre um "wrapper" e uma "solução" é a aplicação de métodos formais. Os testes de software tradicionais dependem de cenários de "caixa-preta"; se o sistema passa em N testes, presume-se que seja seguro. Em sistemas de segurança crítica, contudo, exigimos uma prova matemática de correção.

Solvers SMT e Raciocínio em Nível de Rede

Ferramentas como Marabou e α,β-CROWN permitem que engenheiros verifiquem as propriedades de redes neurais profundas. Ao representar a rede como um conjunto de restrições lineares por partes, podemos determinar se existe qualquer entrada que possa levar a uma saída insegura.²⁵

Uma "Propriedade de Segurança" pode ser definida da seguinte forma:

Para todas as entradas x dentro da faixa de "Baixa Visibilidade", a saída y (Comando de Frenagem) nunca deve ser menor que k.

$$\forall x \in X_{fog} \Rightarrow f(x) \geq Braking_{min}$$

Se um solver SMT como o Marabou retornar um "contraexemplo", ele identificou uma perturbação específica, frequentemente imperceptível, que faria a IA falhar. Isso permite à Veriprajna "endurecer" o modelo durante a fase de treinamento, um processo conhecido como "treinamento ciente de verificação".²⁸

Poda para Verificabilidade

Um desafio importante na verificação formal é a "Maldição da Dimensionalidade". Redes grandes são demasiado complexas para que os solvers atuais as analisem de forma exaustiva. A Veriprajna aborda isso por meio da "Poda de Neurônios". Ao remover neurônios redundantes e não linearidades que não contribuem para a acurácia do modelo, produzimos um "Modelo Podado" que é matematicamente mais fácil de verificar sem sacrificar o desempenho.²⁹

Técnica de Verificação	Metodologia	Benefício
Aperto de Limites	Análise simbólica das faixas de ativação dos neurônios	Reduz o espaço de busca para solvers SMT.25
Análise de Alcançabilidade	Computação do conjunto de todas as saídas alcançáveis para um conjunto de entradas	Garante que a IA permanecerá dentro de um "Politopo Seguro".28
Aproximação Linear por Partes	Substituição de ativações complexas por segmentos baseados em ReLU	Viabiliza provas de verificação corretas e completas.27
Filtro Formal de Segurança	Monitoramento em tempo de execução dos comandos da IA contra uma linha de base verificada	Fornece uma "Recuperação Segura" se a IA principal se comportar de forma irracional.31

O Horizonte Regulatório: SOTIF e ISO/PAS 8800

Para empresas, a conformidade com padrões internacionais emergentes não é mais opcional. O panorama passou da "autoavaliação voluntária" para a adesão obrigatória a um framework de segurança em camadas.⁵

ISO 26262 vs. ISO 21448 (SOTIF)

Embora a ISO 26262 trate da "Segurança Funcional" (p. ex., um sensor falhando ou um chip em curto-circuito), ela não consegue dar conta das limitações inerentes da IA.³⁴ Essa lacuna é preenchida pela ISO 21448, o padrão para "Segurança da Funcionalidade Pretendida" (SOTIF). A SOTIF é especificamente projetada para abordar perigos que ocorrem quando o sistema está funcionando exatamente como programado, mas encontra um ambiente "Desconhecido/Inseguro".³⁴

O objetivo de um engajamento Veriprajna é maximizar o quadrante "Conhecido/Seguro" do sistema de IA de um cliente. Isso envolve:

1. Análise de Perigos e Riscos (HARA): Identificação de riscos que não são falhas, como a interpretação equivocada de sensores em chuva intensa.³⁶
2. Identificação de Condições Disparadoras: Mapeamento sistemático dos estados ambientais que levam a erros de percepção.³⁶
3. V&V (Verificação e Validação): Uso de simulações de alta fidelidade para "injetar" casos extremos que seriam demasiado perigosos para testar em vias públicas.³⁶

ISO/PAS 8800: O Futuro da Integração de IA

A partir do final de 2024, a ISO/PAS 8800 tornou-se o padrão primário para "Segurança Funcional para IA em Veículos Rodoviários".³⁷ Ela fornece as primeiras diretrizes globais para gerenciar o ciclo de vida da IA, desde a "Aquisição de Dados" até o "Monitoramento Pós-Implantação".³³ A Veriprajna garante que as arquiteturas de nossos clientes não sejam apenas conformes, mas "preparadas para o futuro" contra o rigor crescente dos padrões globais de governança de IA, como o EU AI Act e o NIST AI Risk Management Framework.³³

O Caminho Estratégico à Frente: O Mandato de Deep AI da Veriprajna

A transição de uma cultura de "Wrapper" para uma cultura de "Deep AI" é uma jornada da esperança probabilística à garantia determinística. O acordo de $8.5 million da Uber, a suspensão da Cruise e as 40+ investigações da Tesla não são razões para abandonar a IA; são razões para projetá-la corretamente.

O modelo de consultoria da Veriprajna é construído sobre três pilares que abordam os modos de falha específicos identificados neste relatório:

1. Resiliência de Percepção: Migrar clientes da percepção 2D por câmera para Redes de Ocupação BEV baseadas em Transformer, a fim de assegurar permanência do objeto e estabilidade de rastreamento.¹⁶
2. Tomada de Decisão Verificada: Implementar verificação formal baseada em SMT para provar que arquiteturas de controle impulsionadas por IA nunca violarão propriedades centrais de segurança.²⁵
3. Endurecimento Sociotécnico: Desenvolver "Modos de Fuga" sofisticados e frameworks de comunicação V2X para gerenciar a realidade de distúrbios civis e impasses multiagente.¹⁸

À medida que o custo global de uma única violação de dados atinge $4.44 million e o custo de uma fatalidade autônoma entra na casa das dezenas de milhões em danos legais e operacionais, o wrapper "barato" torna-se o erro mais caro que uma empresa pode cometer.¹⁴ A Veriprajna fornece a expertise profunda de engenharia necessária para construir IA que não apenas funciona no laboratório—ela perdura no mundo.

A escolha para a empresa moderna é clara: continuar a encapsular caixas-pretas probabilísticas e gerenciar o inevitável impacto, ou fazer parceria com a Veriprajna para arquitetar um futuro de autonomia verificável e de alta garantia. A era da IA estocástica está terminando; a era da Engenharia de Deep AI começou.

Obras citadas

1. Cruise Admits To Submitting A False Report To Influence A Federal Investigation And Agrees To Pay $500000 - Department of Justice, acessado em 9 de fevereiro de 2026, https://www.justice.gov/usao-ndca/pr/cruise-admits-submitting-false-report-influence-federal-investigation-and-agrees-pay
2. NHTSA Opens Probe into 2.9M Teslas Over FSD Violations - Autobody News, acessado em 9 de fevereiro de 2026, https://www.autobodynews.com/news/nhtsa-opens-probe-into-2-9m-teslas-over-fsd-violations
3. HWY18MH010.aspx - NTSB, acessado em 9 de fevereiro de 2026, https://www.ntsb.gov/investigations/Pages/HWY18MH010.aspx
4. NTSB Shares Investigation Findings and Recommendations Regarding March 2018 Uber ATG Fatality | Eckert Seamans, acessado em 9 de fevereiro de 2026, https://www.eckertseamans.com/legal-updates/ntsb-shares-investigation-findings-and-recommendations-regarding-march-2018-uber-atg-fatality
5. H-19-047 - Accident Data - NTSB, acessado em 9 de fevereiro de 2026, https://data.ntsb.gov/carol-main-public/sr-details/H-19-047
6. NTSB releases preliminary report on fatal Uber self-driving car crash - Metro Magazine, acessado em 9 de fevereiro de 2026, https://www.metro-magazine.com/news/ntsb-releases-preliminary-report-on-fatal-uber-self-driving-car-crash
7. Death of Elaine Herzberg - Wikipedia, acessado em 9 de fevereiro de 2026, https://en.wikipedia.org/wiki/Death_of_Elaine_Herzberg
8. New Details Emerge Regarding Uber Self-Driving Vehicle Accident in Tempe, Arizona, acessado em 9 de fevereiro de 2026, https://schwedlawfirm.com/blog/new-details-emerge-regarding-uber-self-driving-vehicle-accident/
9. A Root Cause Analysis of a Self-Driving Car Dragging a Pedestrian, acessado em 9 de fevereiro de 2026, https://www.computer.org/csdl/magazine/co/2024/11/10720344/215PD0vqgTe
10. Notes on Cruise's pedestrian accident - Dan Luu, acessado em 9 de fevereiro de 2026, https://danluu.com/cruise-report/
11. Lessons from the Cruise Robotaxi Pedestrian Dragging Mishap, acessado em 9 de fevereiro de 2026, http://users.ece.cmu.edu/~koopman/pubs/Koopman2024_CruiseMishap_IEEEReliabilityMagazine.pdf
12. Office of Defects Investigation (ODI) Resume - nhtsa, acessado em 9 de fevereiro de 2026, https://static.nhtsa.gov/odi/inv/2025/INOA-PE25012-19171.pdf
13. US regulators launch investigation into self-driving Teslas after series of crashes, acessado em 9 de fevereiro de 2026, https://www.theguardian.com/technology/2025/oct/09/tesla-cars-self-driving-us-regulators-investigation
14. Tesla FSD Safety Issues: NHTSA Probes & AI Driving Future (Part 6) - PRIZ Guru, acessado em 9 de fevereiro de 2026, https://www.priz.guru/tesla-fsd-safety-issues-nhtsa-probes-ai-driving-future-part-6/
15. AI & Robotics | Tesla, acessado em 9 de fevereiro de 2026, https://www.tesla.com/AI
16. A Survey on Occupancy Perception for Autonomous Driving: The Information Fusion Perspective - arXiv, acessado em 9 de fevereiro de 2026, https://arxiv.org/html/2405.05173v2
17. New Study: Waymo is reducing serious crashes and making streets safer for those most at risk, acessado em 9 de fevereiro de 2026, https://waymo.com/blog/2025/05/waymo-making-streets-safer-for-vru
18. On Waymo's Traffic Jams - Stanford Center for Internet and Society, acessado em 9 de fevereiro de 2026, https://cyberlaw.stanford.edu/blog/2025/12/on-waymos-traffic-jams/
19. Self-driving cars may create more traffic congestion than they solve, expert says - KJZZ, acessado em 9 de fevereiro de 2026, https://www.kjzz.org/the-show/2026-01-07/self-driving-cars-may-create-more-traffic-congestion-than-they-solve-expert-says
20. A Systematic Literature Review on Vehicular Collaborative Perception – A Computer Vision Perspective - arXiv, acessado em 9 de fevereiro de 2026, https://arxiv.org/html/2504.04631v2
21. When Robotaxis Get Attacked: Do Waymo Cars Need a 'Danger Escape Mode'?, acessado em 9 de fevereiro de 2026, https://aragonresearch.com/robotaxis-attack-waymo-cars-danger-escape-mode/
22. MIC-BEV: Multi-Infrastructure Camera Bird's-Eye-View Transformer with Relation-Aware Fusion for 3D Object Detection - arXiv, acessado em 9 de fevereiro de 2026, https://arxiv.org/html/2510.24688v1
23. [AV Vol.3] BEVFusion: Unifying Vision in Autonomous Driving Systems - Medium, acessado em 9 de fevereiro de 2026, https://medium.com/demistify/av-vol-3-bevfusion-unifying-vision-in-autonomous-driving-systems-b2190f877c9b
24. A Transformer-based Temporal Feature Fusion Approach for Autonomous Driving BEV Perception | Request PDF - ResearchGate, acessado em 9 de fevereiro de 2026, https://www.researchgate.net/publication/395804054_A_Transformer-based_Temporal_Feature_Fusion_Approach_for_Autonomous_Driving_BEV_Perception
25. The Marabou Framework for Verification and Analysis of Deep Neural Networks - Stanford Center for AI Safety, acessado em 9 de fevereiro de 2026, https://aisafety.stanford.edu/marabou/MarabouCAV2019.pdf
26. Marabou 2.0: A Versatile Formal Analyzer of Neural Networks - arXiv, acessado em 9 de fevereiro de 2026, https://arxiv.org/html/2401.14461v1
27. Marabou 2.0: A Versatile Formal Analyzer of Neural Networks - Stanford CS Theory, acessado em 9 de fevereiro de 2026, https://theory.stanford.edu/~barrett/pubs/WIZ+24.pdf
28. Creating a Formally Verified Neural Network for Autonomous Navigation: An Experience Report - CSE CGI Server, acessado em 9 de fevereiro de 2026, https://cgi.cse.unsw.edu.au/~eptcs/paper.cgi?FMAS2024.12.pdf
29. Verification of Neural Networks for Safety and Security-critical Domains - CEUR-WS.org, acessado em 9 de fevereiro de 2026, https://ceur-ws.org/Vol-3345/paper10_RiCeRCa3.pdf
30. Formal Verification of Neural Networks for Safety-Critical Tasks in Deep Reinforcement Learning, acessado em 9 de fevereiro de 2026, https://proceedings.mlr.press/v161/corsi21a/corsi21a.pdf
31. Formal Methods for Trustworthy AI-based Autonomous Systems - NII Shonan Meeting, acessado em 9 de fevereiro de 2026, https://shonan.nii.ac.jp/docs/No.178.pdf
32. Formal Verification of Neural Networks-Based Control Architecture for Safety-Critical Autonomous Systems - Frontiers, acessado em 9 de fevereiro de 2026, https://www.frontiersin.org/research-topics/74336/formal-verification-of-neural-networks-based-control-architecture-for-safety-critical-autonomous-systems
33. Implementing Responsible AI for Automotive Vehicle Safety - LHP Engineering Solutions, acessado em 9 de fevereiro de 2026, https://www.lhpes.com/blog/implementing-responsible-ai-for-automotive-vehicle-safety
34. Functional Safety vs. SOTIF: What Is the Difference and Where Do They Overlap? - MES, acessado em 9 de fevereiro de 2026, https://model-engineers.com/en/blog/functional-safety-vs-sotif-differences-overlaps/
35. The Necessity of a Holistic Safety Evaluation Framework for AI-Based Automation Features, acessado em 9 de fevereiro de 2026, https://arxiv.org/html/2602.05157v1
36. What is SOTIF? (ISO 21448) - Visure Solutions, acessado em 9 de fevereiro de 2026, https://visuresolutions.com/automotive/iso-21448/
37. Safety-Related Systems in Road Vehicles with Artificial Intelligence Are Addressed in ISO/PAS 8800:2024 | UL Solutions, acessado em 9 de fevereiro de 2026, https://www.ul.com/sis/blog/safety-related-systems-road-vehicles-artificial-intelligence-are-addressed-isopas-88002024
38. ISO 26262, SOTIF and simulation | Applied Intuition, acessado em 9 de fevereiro de 2026, https://www.appliedintuition.com/blog/iso26262-sotif-simulation
39. Introducing ISO/PAS 8800 – Functional Safety for AI in Road Vehicles | SGS Georgia, acessado em 9 de fevereiro de 2026, https://www.sgs.com/en-ge/news/2025/04/safeguards-04625-introducing-iso-pas-8800-functional-safety-for-ai-in-road-vehicles
40. NIST vs ISO - Compare AI Frameworks - ModelOp, acessado em 9 de fevereiro de 2026, https://www.modelop.com/ai-governance/ai-regulations-standards/nist-vs-iso
41. AI Safety vs AI Security in LLM Applications: What Teams Must Know - Promptfoo, acessado em 9 de fevereiro de 2026, https://www.promptfoo.dev/blog/ai-safety-vs-security/