O Carro Autônomo a Viu 5,6 Segundos Antes do Impacto — E Mesmo Assim Não Conseguiu Decidir o Que Ela Era

Eu estava sentado em uma sala de reuniões no fim de 2023, assistindo a um vídeo que mudaria para sempre a forma como penso sobre segurança em IA. As imagens eram de um robotáxi da Cruise em São Francisco. Uma pedestre havia sido atingida por um carro dirigido por um humano, arremessada para a trajetória do veículo autônomo, e ficara presa embaixo dele. O robotáxi parou — brevemente — e então começou a encostar na lateral da via, arrastando a mulher 20 pés (6 metros) pelo asfalto.

A sala ficou em silêncio. Alguém da minha equipe disse: "O carro achou que tinha sofrido uma colisão lateral." E essa frase — o carro achou — virou a semente de tudo o que viemos construindo na Veriprajna desde então.

Porque o carro não "achou" nada. Ele executou uma sub-rotina de classificação, obteve a resposta errada e executou uma manobra pré-programada que transformou um acidente sobrevivível em algo muito pior. Não houve raciocínio. Nenhuma consciência. Nenhuma arquitetura de segurança capaz de interceptar um diagnóstico catastroficamente errado antes que ele virasse uma catástrofe.

Essa é a lacuna que insisto em tentar explicar a investidores, clientes e colegas engenheiros: a distância entre uma IA que se sai bem em demonstrações e uma IA que se comporta com segurança quando o mundo deixa de cooperar. Comecei a chamá-la de Lacuna Percepção-Lógica — o espaço entre o que um sistema autônomo vê e o que ele de fato entende. E, neste momento, essa lacuna está matando pessoas.

O Que Aconteceu Quando a IA Teve Quase Seis Segundos e Ainda Assim Falhou?

O acidente da Uber ATG em Tempe, Arizona, em março de 2018 é o caso ao qual mais retorno, porque é a ilustração mais pura de como um sistema probabilístico pode ter todos os dados de que precisa e ainda assim cometer um erro fatal.

Os sensores do veículo registraram Elaine Herzberg pela primeira vez — uma pedestre empurrando uma bicicleta ao atravessar uma via escura — aproximadamente 5,6 segundos antes do impacto. A 43 mph (cerca de 69 km/h), isso equivale a cerca de 378 pés (115 metros) de distância. Mais do que suficiente para qualquer sistema de frenagem competente parar o carro.

Mas a IA não conseguia decidir o que estava vendo. Ao longo daqueles 5,6 segundos, o sistema de percepção reclassificou Herzberg repetidamente: primeiro como um "objeto desconhecido", depois como um "veículo", depois como uma "bicicleta". Cada reclassificação não era apenas uma troca de rótulo — era uma reinicialização completa da trajetória prevista do objeto. Na prática, o sistema desenvolvia amnésia toda vez que mudava de ideia.

Lembro de ler o relatório do NTSB pela primeira vez e passar mal fisicamente. Não por causa do desfecho — embora ele fosse devastador — mas por causa do mecanismo. A IA determinou que a frenagem de emergência era necessária apenas 1,3 segundo antes do impacto. A física tornou o resto inevitável.

Uma IA que consegue ver um obstáculo por quase seis segundos e ainda assim não consegue decidir o que ele é não tem um problema de sensor. Tem um problema de arquitetura.

O que tornou tudo pior — o que me deixou com raiva, honestamente — foi descobrir que a Uber havia desativado deliberadamente o sistema de prevenção de colisão instalado de fábrica no Volvo XC90. O carro vinha com Frenagem Automática de Emergência do fabricante. A Uber a desligou para evitar o que chamavam de "comportamento errático do veículo". Queriam uma condução mais suave para o software experimental deles e, para isso, removeram a única camada determinística de segurança que talvez tivesse salvado uma vida.

Essa decisão assombra esta indústria. É o pecado original de tratar a segurança em IA como um problema de ajuste em vez de uma disciplina de engenharia.

Por Que a Mesma Falha Continua Acontecendo em Carros Diferentes?

Depois do acidente da Uber, eu esperava que a indústria aprendesse. Especificamente, esperava que as empresas construíssem arquiteturas nas quais uma falha de percepção não pudesse se propagar até virar uma falha de decisão. Nas quais existissem fronteiras rígidas de segurança que nenhum software experimental pudesse sobrepor.

Em vez disso, tivemos a Cruise.

O incidente de outubro de 2023 em São Francisco foi diferente do da Uber nos detalhes, mas idêntico na arquitetura. Um Nissan dirigido por um humano atingiu uma pedestre, arremessando-a para a trajetória de um robotáxi da Cruise. O veículo da Cruise a atingiu e parou. Até ali, o sistema estava funcionando — de forma imperfeita, mas dentro dos parâmetros.

Então entrou em ação a lógica pós-impacto. A detecção de impacto do sistema não era granular o suficiente para distinguir entre um atropelamento frontal e uma colisão lateral. Ele classificou o evento como um impacto lateral. E a resposta pré-programada para um impacto lateral era: encostar na lateral da via para não bloquear o trânsito.

O carro encostou. Com um ser humano preso embaixo dele. Arrastou-a por 20 pés (6 metros) a cerca de 7 mph (11 km/h) antes de detectar "escorregamento excessivo das rodas" — que interpretou como uma falha mecânica, não como uma pessoa.

Passei uma semana depois daquele incidente discutindo com minha equipe sobre qual deveria ter sido a arquitetura de resposta correta. Um dos nossos engenheiros — sujeito brilhante, muito voltado a métodos formais — insistia que o problema era solucionável com uma fusão de sensores melhor. "Se o sistema tivesse detecção de ocupação sob o chassi", ele disse, "ele teria sabido."

Ele tinha razão. Mas também não estava entendendo o essencial. A falha mais profunda era que o sistema não tinha nenhum conceito de incerteza sobre o próprio diagnóstico. Ele classificou o impacto e então agiu com base nessa classificação com plena confiança. Não havia um estado intermediário de "não tenho certeza do que acabou de acontecer, então não devo fazer nada até ter". A arquitetura não permitia a dúvida.

É disso que falo quando menciono a Lacuna Percepção-Lógica. Não se trata apenas de enxergar melhor. Trata-se de saber quando você não sabe.

O Encobrimento Também Era a Arquitetura

O que aconteceu depois do incidente do arrastamento da Cruise foi quase tão revelador quanto o próprio incidente. Investigações concluíram que a alta liderança estava "fixada em corrigir a narrativa imprecisa da mídia" em vez de ser transparente com os reguladores. Funcionários admitiram ter mostrado aos reguladores um vídeo do acidente sabendo que problemas de conectividade com a internet frequentemente impediam que o trecho do arrastamento fosse reproduzido.

A Cruise acabou pagando uma multa criminal de US$ 500.000 por apresentar relatórios falsos à NHTSA. Sua licença de operação na Califórnia foi revogada.

Trago isso à tona não para atacar a Cruise, mas porque revela algo estrutural sobre como a indústria trata a segurança. Quando o seu sistema de IA é uma caixa-preta — quando nem os seus próprios engenheiros conseguem explicar plenamente por que ele tomou determinada decisão em determinado momento — a tentação de controlar a narrativa em vez de consertar a arquitetura se torna avassaladora.

Transparência não é uma estratégia de RP para veículos autônomos. É um requisito técnico. Se você não consegue auditar cada decisão que sua IA tomou em uma crise, você não tem um sistema de segurança — você tem um passivo.

Na Veriprajna, tornamos as auditorias de segurança explicáveis uma parte central do nosso trabalho de arquitetura. Cada decisão que a IA toma, especialmente após um impacto, é registrada em um formato determinístico e à prova de adulteração que os reguladores podem auditar em tempo real. Não porque sejamos mais virtuosos que a Cruise — mas porque vimos o que acontece quando a alternativa é "deixar o vídeo falar por si".

Escrevi sobre o framework técnico completo por trás dessa abordagem em nosso whitepaper interativo, incluindo os modos de falha específicos que catalogamos a partir da Uber, da Cruise, da Tesla e da Waymo.

O Que a Aposta "Só Visão" da Tesla Realmente Significa para a Segurança?

A abordagem da Tesla para a direção autônoma é filosoficamente diferente da Uber ou da Cruise, e as falhas também são diferentes. Mas elas rimam.

O sistema Full Self-Driving da Tesla depende inteiramente de câmeras — sem LiDAR, sem radar. Elon Musk já chamou o LiDAR de "muleta". A aposta é que redes neurais suficientemente avançadas consigam reconstruir uma compreensão 3D completa do mundo apenas a partir de imagens 2D, como faz a visão humana.

É uma ideia elegante. Eu até a acho intelectualmente convincente. Mas a NHTSA abriu mais de 40 investigações sobre acidentes relacionados ao FSD entre 2024 e 2025, cobrindo 2,9 milhões de veículos, e o padrão é condenatório.

Dezoito queixas distintas envolvem veículos avançando sinais vermelhos ou falhando em detectar o estado do semáforo. Vários relatos descrevem carros entrando na contramão. Uma colisão fatal em 2023 ocorreu sob reflexo do sol em asfalto molhado — condições em que a relação sinal-ruído óptica cai abaixo do que qualquer sistema de câmeras consegue interpretar de forma confiável.

Chamo isso de Teatro de Capacidade: o sistema tem um desempenho lindo em condições ideais, criando uma ilusão de competência que desmorona nas bordas. Dia ensolarado, via limpa, cruzamento padrão? Impecável. Sol baixo, pavimento molhado, travessia de pedestre incomum? O sistema não se degrada graciosamente. Ele falha abruptamente.

O problema não é que a abordagem só com visão não possa funcionar na teoria. É que a Tesla está implantando-a em escala sem o que eu chamaria de Portões de Garantia — fronteiras rígidas que impedem a IA de tomar decisões de alto risco quando sua confiança cai abaixo de um limiar verificado. Se a saturação por reflexo ultrapassar certa porcentagem, o sistema deveria se recusar a dirigir, não chutar com mais convicção.

Como Você Prova Que uma IA Não Vai Matar Alguém?

Essa é a pergunta que me tira o sono. Não metaforicamente — literalmente. Houve um período no ano passado em que eu rodava experimentos de verificação formal até as 2 da manhã, tentando encontrar a fronteira entre "testado o suficiente" e "comprovadamente seguro".

O teste tradicional de software é caixa-preta: você submete o sistema a N cenários e, se ele passar em todos, você o lança. Mas veículos autônomos não encontram N cenários. Eles encontram o mundo físico inteiro, com todo o seu caos, seus casos extremos e seres humanos fazendo coisas inexplicáveis. Nenhuma quantidade de testes de cenários consegue cobrir esse espaço.

A verificação formal adota uma abordagem diferente. Em vez de perguntar "o sistema passou nestes testes?", ela pergunta "existe alguma entrada capaz de produzir uma saída insegura?" Ferramentas como Marabou e α,β-CROWN conseguem representar uma rede neural como um conjunto de restrições matemáticas e então buscar — exaustivamente — por violações.

Uma propriedade de segurança poderia ser assim: para toda entrada possível dentro de uma faixa de "baixa visibilidade", o comando de frenagem nunca deve ficar abaixo de um limiar mínimo. Se o solver encontrar um contraexemplo — uma entrada específica que viola a propriedade — você identificou uma vulnerabilidade antes que ela mate alguém.

Uma noite, estávamos rodando a verificação em um modelo de percepção e o solver retornou um contraexemplo que nenhum de nós havia antecipado. Uma combinação muito específica de ângulo de iluminação e distância do objeto que fazia a confiança da frenagem cair para quase zero. Não era um cenário que qualquer um de nós teria pensado em testar. O solver o encontrou porque não estava chutando — estava provando.

Aquele momento cristalizou algo para mim. O teste pergunta "isso funciona?". A verificação pergunta "isso pode falhar?". São perguntas fundamentalmente diferentes, e a IA crítica para a segurança exige a segunda.

O teste diz o que sua IA faz. A verificação diz o que ela nunca pode fazer. Para sistemas críticos de segurança, só a segunda pergunta importa.

O problema é que as redes neurais atuais são enormes — milhões de parâmetros — e a verificação exaustiva de redes grandes é computacionalmente intratável. Lidamos com isso por meio da poda de neurônios: a remoção sistemática de neurônios redundantes que não contribuem para a acurácia, mas tornam a rede complexa demais para ser verificada. O resultado é um modelo mais enxuto que é ao mesmo tempo performático e matematicamente demonstrável.

Para o detalhamento técnico completo do nosso pipeline de verificação — incluindo a metodologia do solver SMT e a abordagem de poda — veja nosso artigo de pesquisa detalhado.

Quando o Problema Não É a IA — É o Mundo

A Waymo já registrou mais de 56 milhões de milhas (90 milhões de quilômetros) e tem taxas de lesão significativamente menores que as de motoristas humanos. Pela maioria das métricas, é a líder do setor. E, ainda assim, a Waymo revelou um modo de falha para o qual ninguém na indústria de veículos autônomos estava preparado: o próprio mundo se recusando a cooperar.

Durante um apagão em Los Angeles em 2025, dezenas de robotáxis da Waymo ficaram presos em cruzamentos às escuras. Os veículos estavam programados para tratar semáforos apagados como cruzamentos com parada obrigatória nas quatro vias — a resposta legalmente correta. Mas quando dezenas de veículos autônomos chegam todos ao mesmo cruzamento morto, cada um esperando educadamente pela sua vez e cada um solicitando assistência humana remota simultaneamente, você obtém algo que comecei a chamar de Armadilha da Independência: cada veículo se comportando corretamente isoladamente enquanto, coletivamente, criam um travamento total do trânsito que nenhum veículo individual consegue resolver.

A central de assistência remota ficou sobrecarregada. Robotáxis bloqueavam outros robotáxis. O sistema que funcionava perfeitamente com um carro em um cruzamento entrou em colapso quando escalado para uma frota em uma emergência que atingia a cidade inteira.

E então há o problema do qual ninguém quer falar publicamente. Durante a agitação civil em Los Angeles no início de 2025, multidões atacaram veículos da Waymo — cortando pneus, quebrando vidros, ateando fogo aos carros. Os veículos, programados para "segurança passiva", simplesmente pararam ao serem cercados por pessoas. O que é exatamente a resposta errada quando as pessoas que cercam você estão tentando destruir o veículo com passageiros dentro.

Isso levou a discussões sérias sobre o que alguns pesquisadores chamam de "Modo de Escape de Perigo" — a capacidade de um veículo autônomo cometer infrações de trânsito menores (subir na calçada, avançar um sinal vermelho) para proteger seus passageiros da violência. Isso exige repensar fundamentalmente a hierarquia ética da IA, e é um problema que nenhuma quantidade de sensores melhores ou processadores mais rápidos consegue resolver.

Levantei isso em uma reunião com um cliente em potencial e alguém disse: "Você não pode simplesmente usar o GPT para lidar com casos extremos assim?" Acho que minha expressão disse mais que minhas palavras. Este é um problema de arquitetura de decisão que exige raciocínio ético formal, não um chatbot.

Por Que Não Podemos Simplesmente Testar Até Chegar à Segurança?

As pessoas me perguntam isso constantemente. "Se a Waymo tem 56 milhões de milhas (90 milhões de quilômetros) de dados, isso não é teste suficiente?"

Não. E o motivo é matemático, não filosófico.

O espaço de cenários de direção possíveis é efetivamente infinito. Você pode dirigir 56 milhões de milhas e nunca encontrar a combinação específica de reflexo do sol, asfalto molhado e um pedestre vestido de forma incomum que faz seu sistema de percepção falhar. Casos extremos não são versões raras de cenários comuns — são cenários que existem nas lacunas entre tudo o que você já viu.

É por isso que o cenário regulatório está migrando de "mostre-nos seus resultados de teste" para "mostre-nos suas provas de segurança". A ISO 21448, conhecida como SOTIF — Safety of the Intended Functionality — foi projetada especificamente para tratar de perigos que ocorrem quando a IA está funcionando exatamente como programada, mas encontra um ambiente com o qual não sabe lidar. Não se trata de falha de hardware. Trata-se das limitações inerentes da IA encontrando o mundo real.

E a ISO/PAS 8800, que se tornou a principal norma para IA em veículos rodoviários no fim de 2024, vai além: exige a gestão de todo o ciclo de vida da IA, da aquisição de dados ao monitoramento pós-implantação. A era do "lança e vê o que acontece" está acabando, ao menos para empresas que querem operar legalmente na UE, nos EUA e nos principais mercados asiáticos.

Na Veriprajna, estruturamos nosso trabalho em torno de levar os clientes para aquilo que a SOTIF chama de quadrante "Conhecido/Seguro" — identificando sistematicamente condições desencadeadoras, mapeando estados ambientais que causam erros de percepção e usando simulação de alta fidelidade para injetar casos extremos que seriam perigosos demais para testar em vias reais.

A Verdadeira Diferença Entre um Wrapper e uma Solução

Passei os últimos anos vendo a indústria de IA se dividir em dois campos, e a divisão está ficando maior.

De um lado, há a economia dos wrappers — empresas construindo interfaces conversacionais em cima de grandes modelos de linguagem, otimizando para velocidade de implantação e experiência do usuário. Parte desse trabalho é genuinamente útil. A maior parte dele é irrelevante para aplicações críticas de segurança.

Do outro lado, há o que eu chamo de engenharia profunda de IA: a integração de verificação formal, resiliência de fusão de sensores e arquiteturas determinísticas de segurança. É mais lento. É mais difícil. É menos impressionante em demonstrações. E é a única abordagem capaz de sobreviver ao contato com o mundo físico.

A peça técnica central dessa mudança é a percepção Bird's-Eye-View com Redes de Ocupação. Em vez de processar feeds de câmeras individuais e tentar costurá-los — um processo que perde dados em cada emenda —, a percepção BEV transforma dados de câmeras multivisão e de LiDAR em uma grade 3D unificada vista de cima. E, em vez de perguntar "que objeto é este?", as redes de ocupação perguntam "este espaço está ocupado?".

Essa distinção importa enormemente. Se o sistema da Uber ATG estivesse rastreando espaço ocupado em vez de tentar classificar objetos, não teria importado se o sistema achava que Herzberg era uma pedestre, uma bicicleta ou um objeto desconhecido. O espaço estava ocupado. O espaço estava na trajetória do veículo. Freie.

De forma semelhante, se o veículo da Cruise estivesse rodando detecção de ocupação sob o chassi, ele teria sabido que havia algo debaixo do carro, independentemente de como classificasse o impacto. O espaço ocupado teria sobreposto a manobra de encostar.

A pergunta não é "que objeto é este?" — é "este espaço está ocupado?". Esse único reenquadramento poderia ter evitado os dois desastres mais notórios de veículos autônomos da última década.

Usamos arquiteturas Transformer — a mesma tecnologia fundamental por trás do GPT — mas não para conversação. Nós as usamos como motores de raciocínio espacial que fundem dados heterogêneos de sensores naquilo que chamamos de Tela Compartilhada. A autoatenção temporal permite que o sistema lembre onde um objeto estava mesmo durante oclusões temporárias — uma pedestre caminhando atrás de um caminhão estacionado não desaparece da consciência do modelo só porque as câmeras não conseguem vê-la por dois segundos.

A Lição de US$ 8,5 Milhões

O acordo da Uber ATG foi de US$ 8,5 milhões. A multa criminal da Cruise foi de US$ 500.000 — um número que nem começa a contabilizar a paralisação operacional, o dano reputacional ou o sofrimento humano. A investigação da NHTSA sobre a Tesla abrange 2,9 milhões de veículos. O custo médio global de uma única violação de dados é hoje de US$ 4,44 milhões.

Quando somo esses números, a conclusão é desconfortável para a turma do "mova-se rápido e quebre coisas": o wrapper de IA barato é o erro mais caro que uma empresa pode cometer. Não porque não funcione — funciona bem em ambientes controlados. Mas no momento em que ele encontra o mundo não controlado — a via escura, a confusão pós-impacto, o reflexo do sol no asfalto molhado, a multidão enfurecida — a ausência de uma arquitetura determinística de segurança transforma uma limitação de software em uma catástrofe humana.

Às vezes as pessoas contestam nossa abordagem dizendo que a verificação formal é lenta demais, cara demais, acadêmica demais para prazos de implantação do mundo real. Entendo a objeção. A verificação é computacionalmente cara. Podar redes para torná-las verificáveis leva tempo. Construir arquiteturas de segurança com portões de garantia rígidos dá mais trabalho do que embrulhar uma API.

Mas eu pediria a essas pessoas que assistissem ao vídeo do arrastamento da Cruise. Que lessem o relatório do NTSB sobre a morte de Elaine Herzberg. Que olhassem as 18 queixas de sinal vermelho na investigação sobre o FSD da Tesla. E então me dissessem que "lento demais" é uma crítica válida a uma abordagem projetada para evitar exatamente esses desfechos.

A era de construir sistemas autônomos sobre esperança probabilística está acabando. Não porque os reguladores estejam forçando isso — embora estejam — mas porque a física do mundo real exige. Um sistema de IA que navega mil cruzamentos perfeitamente e então avança um sinal vermelho no milésimo primeiro não é 99,9% seguro. Ele é inseguro, ponto. Segurança não é uma porcentagem. É uma propriedade — que ou vale sob todas as condições verificadas ou não vale de forma alguma.

É essa a mudança em torno da qual estou construindo a Veriprajna. Não wrappers melhores. Não demonstrações mais rápidas. Garantia determinística para sistemas em que a falha não é um relatório de bug — é uma contagem de corpos.