Inteligência artificial e responsabilidade na infraestrutura

O uso de inteligência artificial na operação de serviços essenciais exige contratos, supervisão e registros capazes de permitir a apuração de falhas. A divisão de tarefas entre empresas de tecnologia e operadores precisa preservar a proteção de quem depende do serviço.

Imagine um sistema que analisa imagens de uma rodovia e identifica um obstáculo na pista. O alerta permite mobilizar uma equipe antes de um acidente. Agora imagine que o sistema não reconheça o obstáculo, que a comunicação falhe ou que o aviso chegue a um centro de controle sem profissionais disponíveis para agir. O resultado pode ser semelhante, mas as causas e as responsabilidades serão diferentes.

Esse exemplo hipotético revela uma questão que acompanhará a adoção de inteligência artificial na infraestrutura. Quando uma decisão passa por sensores, modelos computacionais, plataformas contratadas e equipes operacionais, como identificar quem deveria ter evitado o dano?

A resposta exige compreender a função da tecnologia dentro do serviço. Defendo que a adoção de IA em atividades críticas seja acompanhada de uma arquitetura de responsabilidade verificável: atribuições claras, condições reais de intervenção e evidências que permitam reconstruir o ocorrido. Essa estrutura deve começar na contratação e acompanhar as mudanças do sistema durante sua operação.

A tecnologia já participa da operação

Em dezembro de 2025, a ANTT apresentou iniciativas de digitalização das concessões rodoviárias e destacou sistemas de Detecção Automática de Incidentes com uso de inteligência artificial. A agência descreveu aplicações para identificar veículos parados na pista, tráfego na contramão e objetos soltos, com envio de alertas aos centros de controle. Trata-se de uma aplicação concreta na qual o benefício esperado depende da conexão entre identificação do risco e resposta operacional. ^[1]

Há muitas possibilidades de utilização. Um modelo pode auxiliar a priorização da manutenção de equipamentos, estimar demanda ou organizar o atendimento ao usuário. São exemplos de funções distintas, que precisam ser avaliadas segundo o contexto e as consequências de uma falha.

Também é necessário distinguir inteligência artificial de automação em geral. Uma rotina que executa uma regra previamente definida pode produzir efeitos importantes sem utilizar um modelo de aprendizado de máquina. O nome comercial da ferramenta oferece pouca informação sobre o risco que ela introduz.

Para a análise jurídica, interessa saber quais dados entram no sistema, que resultado ele produz, quem utiliza esse resultado e o que acontece em seguida. A recomendação de um software pode influenciar a decisão de uma pessoa ou desencadear diretamente uma ação operacional. Essas situações exigem controles diferentes.

Um experimento brasileiro com regras de acompanhamento

O tema já tem uma experiência regulatória diretamente relacionada às concessões brasileiras. A ANTT organizou um sandbox para inovação na inspeção de tráfego: um ambiente de experimentação supervisionada. A página institucional prevê apresentação de propostas com descrição da inovação, benefícios esperados e análise de riscos, avaliação por comissão e acompanhamento dos projetos, com possibilidade de ajustes durante os testes. ^[2]

A Deliberação ANTT nº 444, de 14 de novembro de 2025, homologou a seleção de três concessionárias: Catarinense de Rodovias, Ecovias do Araguaia e Nova Rota do Oeste. Determinou providências para formalização dos termos aditivos, observadas as salvaguardas da Resolução nº 5.999/2022 e do Edital nº 1/2025, além de comissão para acompanhar, monitorar e avaliar os experimentos. ^[3]

O ato comprova a seleção e a organização institucional da experiência. A homologação, por si só, não comprova o desempenho das soluções nem a conclusão dos testes. Sua contribuição para o debate é mostrar que a inovação pode entrar no contrato com um procedimento de avaliação e acompanhamento.

A partir desse exemplo, proponho que a expansão de uma aplicação seja condicionada à demonstração de resultados no contexto em que será utilizada. O plano de teste deve indicar quais situações se pretende observar, quais resultados justificam ampliar o uso e quais sinais exigem correção ou interrupção. Esses critérios precisam ser definidos antes de a operação criar dependência da ferramenta.

A responsabilidade perante o usuário

A discussão legislativa específica sobre IA convive com normas já aplicáveis aos serviços. Na consulta realizada em 19 de outubro de 2026, a ficha do PL nº 2.338/2023 na Câmara indicava que a proposição aguardava parecer do relator na comissão especial. A análise a seguir parte do direito vigente e distingue suas obrigações das propostas de governança defendidas neste artigo. ^[4]

A utilização de IA deve ser examinada dentro dos regimes jurídicos aplicáveis ao serviço e ao dano. A Constituição, no artigo 37, § 6º, estabelece a responsabilidade das pessoas jurídicas de direito público e das pessoas jurídicas de direito privado prestadoras de serviços públicos pelos danos que seus agentes, nessa qualidade, causarem a terceiros. A apuração exige considerar os pressupostos desse regime, o nexo causal e as circunstâncias do caso. ^[5]

Na Lei de Concessões, o artigo 25 atribui à concessionária a execução do serviço concedido e a responsabilidade pelos prejuízos causados ao poder concedente, aos usuários e a terceiros, sem que a fiscalização exclua ou atenue essa responsabilidade. O dispositivo admite a contratação de terceiros, preservando a responsabilidade da concessionária. O artigo 6º relaciona a adequação do serviço, entre outros requisitos, à continuidade, à eficiência e à segurança. ^[6]

Disso decorre uma consequência importante para a contratação tecnológica: a prestadora não se exonera simplesmente afirmando que o sistema utilizado pertence a outra empresa. A presença de um fornecedor deve ser examinada na cadeia causal e nas relações contratuais, sem presumir que transfira ao usuário o risco da organização interna do serviço.

Nas relações de consumo, o artigo 14 do Código de Defesa do Consumidor prevê responsabilidade do fornecedor por danos decorrentes de defeitos do serviço, independentemente de culpa, observadas as hipóteses legais de exclusão. A responsabilidade pessoal dos profissionais liberais tem tratamento próprio no § 4º. A incidência do CDC depende da configuração da relação jurídica; não se pode pressupor que todo contrato entre empresas de infraestrutura seja uma relação de consumo. ^[7]

O Código Civil, por sua vez, disciplina a reparação por ato ilícito e, no artigo 927, parágrafo único, contempla responsabilidade independente de culpa nos casos legais e nas atividades que, por sua natureza, impliquem risco para direitos de terceiros. O emprego de IA, isoladamente, não permite concluir que todas as pessoas envolvidas respondam pelo mesmo fundamento. ^[8]

Na responsabilidade objetiva, a vítima é dispensada de provar culpa, mas permanecem os demais pressupostos do regime aplicável, como dano e nexo causal, além do exame das causas de exclusão. Quando incide o artigo 14 do CDC, importa verificar o defeito do serviço. Uma previsão incorreta de um modelo probabilístico precisa ser examinada à luz da segurança esperada e das circunstâncias da prestação; a constatação do erro técnico, isoladamente, não encerra a análise jurídica. ^[7]

A vítima também pode ter pretensão direta contra outro participante, conforme a conduta, o dano e o regime aplicável. A solidariedade, que permite exigir de um devedor a totalidade da obrigação, tem fundamento legal ou convencional: o artigo 265 do Código Civil afasta sua presunção, enquanto o artigo 942 a prevê para os coautores da ofensa. O enquadramento de cada fornecedor precisa ser demonstrado. A apuração interna entre as empresas é uma relação distinta, que não deve se transformar em obstáculo à reparação juridicamente devida. ^[8]

A falha precisa ser localizada

Retomemos a situação hipotética da rodovia. O obstáculo pode não ter sido detectado porque a câmera estava sem manutenção. Pode ter sido identificado corretamente, mas o alerta se perdeu na integração entre plataformas. Pode ainda ter chegado ao centro de controle, sem que houvesse uma regra clara sobre quem deveria mobilizar a equipe.

Em cada hipótese, a investigação percorre um caminho. Será necessário examinar as condições do equipamento, o funcionamento do modelo, a transmissão da informação e a atuação da organização. Uma descrição genérica de falha da inteligência artificial esconderia justamente os elementos necessários à atribuição de responsabilidade.

A empresa que desenvolveu o modelo pode ter descumprido uma obrigação de desempenho ou omitido uma limitação conhecida. A integradora pode ter configurado incorretamente a solução. A operadora pode ter utilizado a ferramenta fora das condições previstas ou deixado de responder a alertas. A contribuição de cada participante precisa ser demonstrada, inclusive quando houver causas concorrentes.

Defendo, por isso, que a contratação documente a finalidade autorizada da ferramenta e as situações nas quais seu resultado não deve ser utilizado sem verificação adicional. Se determinada solução não foi validada para chuva intensa, baixa visibilidade ou uma categoria específica de equipamento, essa limitação precisa chegar a quem decide sobre sua implantação e seu uso.

O contrato também deve tratar da diferença entre indisponibilidade, erro de identificação e demora na resposta. Um sistema pode permanecer conectado e cumprir sua meta de disponibilidade, embora apresente desempenho insuficiente na função que justificou a contratação. A aferição de qualidade deve alcançar o resultado relevante para o serviço.

O que um caso real de controle industrial ensina

O uso de IA para controlar o resfriamento de data centers do Google oferece um exemplo documentado. Em 2016, a DeepMind informou redução de até 40% na energia utilizada para resfriamento. O percentual se refere a essa função específica, segundo relato da própria empresa; não corresponde a uma redução de 40% no consumo total dos data centers nem a uma economia que possa ser projetada automaticamente para outros empreendimentos. ^[9]

Em 2018, a empresa descreveu a passagem de recomendações executadas por pessoas para controle direto, sob supervisão especializada. O sistema coletava informações a cada cinco minutos, selecionava ações dentro de restrições de segurança e submetia os comandos a uma verificação local. Os operadores podiam sair do modo de controle por IA. A publicação relatou oito mecanismos de segurança, incluindo verificação em duas camadas e soluções de contingência. ^[10]

O interesse jurídico do caso está na relação entre autonomia e limites operacionais. O controle direto veio acompanhado de restrições, validações e capacidade de intervenção. A fonte é um relato técnico empresarial, não uma perícia independente nem demonstração de ausência de falhas.

A lição que extraio é contratual e organizacional: o ganho de eficiência prometido deve ser examinado junto das condições que o tornam aceitável. A pergunta sobre quanto o sistema economiza precisa vir acompanhada de outra: que decisões ele pode executar e quais proteções permanecem fora de seu controle?

Por que uma taxa de acerto pode esconder o problema

Considere uma simulação didática, sem correspondência com dados de uma concessionária. Em 100.000 situações observadas, existem 100 incidentes reais e 99.900 situações normais. O sistema identifica 99 dos 100 incidentes, o que representa sensibilidade de 99%. Entre as situações normais, emite alerta indevido em 1% dos casos.

O resultado é de 99 alertas corretos e 999 falsos alertas. Dos 1.098 avisos recebidos pela equipe, aproximadamente 9% correspondem a incidentes reais. A acurácia global continua sendo 99%, pois o sistema classificou corretamente 99.000 das 100.000 situações. Mesmo assim, a equipe precisa lidar com cerca de dez falsos alertas para cada alerta correto.

Se, mantendo a mesma sensibilidade, a taxa de falsos positivos cair para 0,1%, o número esperado de falsos alertas será de 99,9, aproximadamente 100. A proporção esperada de alertas corretos sobe para cerca de 49,8%. A simulação não demonstra que seja tecnicamente possível obter essa melhora sem outro custo. Ela mostra o que uma apresentação comercial pode omitir ao informar apenas uma porcentagem de acerto.

Sensibilidade é a proporção de incidentes reais identificados. A taxa de falsos positivos mede os alertas indevidos entre as situações normais. A precisão dos alertas indica quantos dos avisos emitidos correspondem a incidentes reais. A acurácia mede o total de classificações corretas. Cada indicador responde a uma pergunta diferente.

Na contratação, proponho avaliar também os incidentes não detectados, o atraso até o alerta e o tempo necessário para agir. Esses indicadores devem ser separados por condições relevantes, como horário, iluminação e condições ambientais. O desempenho médio de um teste pode esconder uma deficiência justamente no cenário em que o serviço mais precisa funcionar.

Em operações críticas, dois erros podem ter consequências muito diferentes. Um falso alerta pode mobilizar uma equipe desnecessariamente; um incidente não identificado pode impedir uma resposta urgente. A escolha do ponto de operação exige explicitar esse custo, a capacidade de atendimento e as proteções complementares. A conclusão depende de engenharia, experiência operacional e avaliação jurídica conjunta.

Um acidente que expôs a fragilidade da supervisão

Em 18 de março de 2018, um veículo de testes da Uber ATG, operado por sistema de direção automatizada, atropelou e matou uma pedestre em Tempe, no Arizona. Segundo o National Transportation Safety Board (NTSB), órgão norte-americano de investigação de acidentes de transporte, o sistema detectou a pessoa 5,6 segundos antes do impacto, mas não a classificou corretamente nem previu sua trajetória. O desenho do sistema impedia a frenagem de emergência para mitigar a colisão, contando com a intervenção da operadora. ^[11]

O NTSB apontou como causa provável a falha de monitoramento da operadora, distraída pelo celular. Entre os fatores contribuintes, identificou deficiências na avaliação de riscos e na supervisão pela empresa, além de medidas inadequadas contra a complacência com a automação. Recomendou relatórios de autoavaliação de segurança e avaliação continuada das salvaguardas. Trata-se de investigação de segurança, não de decisão judicial sobre indenização. ^[11]

O caso envolve um veículo experimental, e não a operação de uma concessão. Sua utilidade comparativa está na dependência de intervenção humana como barreira de segurança. A presença de uma pessoa precisa ser acompanhada de condições para perceber o risco e agir a tempo. Para a infraestrutura, essa análise deve integrar a validação da solução, o dimensionamento das equipes e os procedimentos de emergência.

Supervisão humana com condições de funcionar

A previsão de supervisão humana tem valor quando corresponde a uma capacidade efetiva de atuação. É preciso definir que informações o supervisor recebe, quanto tempo possui para decidir, qual formação necessita e que autoridade tem para contrariar a recomendação ou interromper uma operação.

Uma pessoa diante de centenas de alertas, sem meios de identificar os prioritários, pode representar apenas uma etapa formal. A organização precisa avaliar se a carga de trabalho, a interface e os procedimentos permitem reconhecer uma situação perigosa e reagir a ela.

Também há operações nas quais a velocidade necessária impede aguardar autorização humana para cada comando. Nesses casos, proponho que a análise de segurança delimite previamente o espaço de autonomia, as condições de acionamento de proteções e os procedimentos para assumir o controle ou conduzir o sistema a uma condição segura. A solução adequada depende da engenharia e dos requisitos regulatórios do setor.

A supervisão deve ser dimensionada conforme o risco e concretizada nos procedimentos e contratos aplicáveis. Validar previamente cada comando pode ser inviável em uma operação rápida; definir os limites de atuação e testar a resposta à falha continuam sendo questões essenciais de segurança.

O mesmo cuidado vale para a responsabilidade do profissional. A participação humana deve ser examinada com base nas informações, nos deveres e nos meios de atuação existentes. A assinatura de uma autorização, sozinha, não esclarece se havia possibilidade real de detectar e impedir a falha.

A prova precisa sobreviver ao incidente

Um problema adicional surge quando o sistema é atualizado antes da investigação. Os parâmetros podem mudar, os registros podem ser sobrescritos e o fornecedor pode deixar de disponibilizar a versão utilizada. A empresa continuará com uma ferramenta em funcionamento, mas poderá perder a capacidade de explicar o evento anterior.

Proponho que aplicações críticas tenham uma política de preservação de evidências definida antes da operação. Conforme a função do sistema, ela pode abranger a identificação da versão, as configurações relevantes, os dados de entrada necessários à apuração, as saídas produzidas, os alertas, os horários e as intervenções humanas. A extensão e o prazo de guarda devem ser justificados e compatíveis com as obrigações aplicáveis.

O objetivo é permitir verificar a integridade dos registros e reconstruir a sequência dos fatos. Nem sempre será possível reproduzir exatamente o resultado de um modelo. Nessa situação, a investigação deverá explicitar as limitações e recorrer a outros elementos, em vez de apresentar uma simulação posterior como reprodução fiel do ocorrido.

No processo judicial, o artigo 373, § 1º, do CPC permite a distribuição dinâmica do ônus da prova, mediante decisão fundamentada e oportunidade de cumprimento, nas condições previstas em lei. O artigo 381 admite a produção antecipada da prova, inclusive diante do risco de futura impossibilidade ou dificuldade de verificação dos fatos. São instrumentos relevantes para situações de assimetria informacional, cuja utilização depende dos requisitos de cada caso. ^[12]

Para a empresa, preservar evidências também é uma forma de demonstrar atuação diligente, identificar defeitos externos e sustentar pretensões contra fornecedores. A falta de registros prejudica tanto quem sofreu o dano quanto quem precisa comprovar o correto funcionamento de sua parte da operação.

Dados pessoais e direito de contestação

A dimensão operacional não esgota o problema. Sistemas podem analisar imagens, identificar pessoas ou classificar solicitações de usuários. Quando existe tratamento de dados pessoais, a LGPD integra a análise. Seu artigo 20 assegura ao titular a possibilidade de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais que afetem seus interesses. O § 1º prevê informações claras e adequadas sobre critérios e procedimentos, observados os segredos comercial e industrial. ^[13]

A redação vigente desse artigo não exige expressamente revisão por pessoa natural. Defendo, como medida de governança para situações sensíveis, uma revisão com capacidade efetiva de avaliar o caso e corrigir o resultado, dimensionada conforme os riscos e os direitos envolvidos.

Também é necessário delimitar a incidência da norma: nem toda decisão operacional utiliza dados pessoais. A LGPD não substitui a análise da segurança de um equipamento ou da continuidade de um serviço. Quando aplicável, a preservação de evidências deve observar finalidade, necessidade e segurança, evitando retenção indiscriminada. ^[13]

Na prática, recomendo que o usuário encontre um caminho para contestar a decisão que o afeta, com identificação do responsável pela resposta e acesso a informação compreensível. Repetir automaticamente o resultado inicial pode perpetuar o erro. O procedimento precisa permitir que a situação concreta seja efetivamente examinada.

O que o modelo europeu exige para aplicações críticas

O AI Act europeu oferece uma referência específica. O item 2 do Anexo III contempla sistemas destinados a atuar como componentes de segurança na gestão e operação de infraestrutura digital crítica, tráfego rodoviário e fornecimento de água, gás, aquecimento ou eletricidade. O enquadramento exige examinar a finalidade e as regras de classificação aplicáveis; o simples pertencimento de uma empresa ao setor de infraestrutura não resolve a questão. ^[14]

O artigo 14 relaciona a supervisão à capacidade de compreender limitações, reconhecer a tendência de confiar excessivamente no resultado automatizado, interpretar as saídas e, conforme apropriado, desconsiderar ou reverter o resultado e intervir ou interromper o sistema em condição segura. A intensidade das medidas deve corresponder ao risco, à autonomia e ao contexto de uso. ^[15]

O artigo 12 prevê capacidade técnica de registro automático de eventos durante a vida útil dos sistemas de alto risco, com rastreabilidade adequada à finalidade. Essa disposição oferece um parâmetro concreto para discutir a preservação de evidências. ^[16]

É necessário observar o âmbito territorial e o calendário de aplicação. A página oficial da Comissão Europeia consultada em 19 de outubro de 2026 informa 2 de dezembro de 2027 para a aplicação das regras de alto risco em áreas do Anexo III, incluindo infraestrutura crítica, após as alterações do AI Omnibus. O texto europeu é utilizado aqui como referência comparativa; sua incidência sobre determinada empresa depende dos critérios de aplicação do regulamento. ^[17]

O ponto que considero mais útil é transformar supervisão em capacidades verificáveis. Na contratação brasileira, essas capacidades podem orientar exigências de interface, formação, acesso aos registros e intervenção, adaptadas ao setor e às normas nacionais. Isso permite negociar obrigações concretas em vez de depender de expressões genéricas como uso responsável ou controle humano.

O contrato deve acompanhar as mudanças do sistema

A contratação de uma solução de IA envolve uma relação que pode se alterar durante a execução. Uma atualização pode modificar o desempenho, uma integração pode introduzir dependências e uma mudança na operação pode tornar inadequado um modelo anteriormente validado.

Por isso, proponho que o contrato estabeleça critérios de aceitação ligados ao uso concreto, testes proporcionais ao risco e um procedimento para aprovar mudanças relevantes. A possibilidade de retornar à configuração anterior ou utilizar uma solução alternativa deve ser avaliada segundo a criticidade da função e a viabilidade técnica.

O instrumento também deve assegurar acesso aos registros necessários à apuração de incidentes, inclusive quando armazenados por subcontratados. A obrigação de cooperar precisa alcançar a preservação e a entrega de informações em prazo compatível com a urgência da investigação. Confidencialidade, proteção de dados e segurança podem exigir restrições de acesso e atuação de especialistas, a serem previamente organizadas.

Esse acesso pode ser organizado por níveis: informação operacional para a prestadora, documentação técnica para especialistas e divulgação controlada para a investigação. A extensão deve corresponder ao que é necessário apurar. Exigir indiscriminadamente a abertura de todo o código-fonte pode ser desproporcional e ainda assim não explicar a decisão, que também depende de dados, parâmetros e integrações. A cláusula deve definir documentos, responsáveis e condições de acesso, com tratamento específico para os segredos protegidos.

Limites de indenização e exclusões de responsabilidade entre empresas merecem negociação específica. Seu alcance e sua validade dependem do regime aplicável. Uma cláusula entre operadora e fornecedor não vincula automaticamente a vítima nem afasta obrigações legais perante terceiros.

Também recomendo verificar se as garantias e os seguros contratados correspondem aos riscos assumidos. Uma cobertura descrita como tecnológica ou cibernética pode ter exclusões importantes para danos materiais, falhas operacionais ou interrupção de serviços. A correspondência deve ser examinada nas condições efetivas da apólice.

Referências técnicas ajudam a estruturar essa gestão. O AI Risk Management Framework do NIST foi concebido para uso voluntário e para apoiar a consideração da confiabilidade no desenvolvimento, uso e avaliação de sistemas de IA. Pode servir como referência de governança, sem ser tratado como legislação brasileira ou garantia automática de conformidade. ^[18]

Quatro decisões para tornar a responsabilidade verificável

A proposta que apresento pode ser aplicada a cada função crítica por meio de quatro decisões documentadas. Não se trata de uma classificação legal de risco nem de uma certificação. É um método de trabalho para aproximar as responsabilidades contratuais das condições concretas da operação.

A primeira decisão é delimitar a autoridade do sistema. Deve ficar claro se ele apenas informa, recomenda, decide dentro de parâmetros ou executa uma ação. Um mesmo produto pode reunir funções com níveis de autonomia distintos. Uma autorização genérica para utilizar IA não descreve adequadamente essa diferença.

A segunda é definir como o desempenho será observado. Isso envolve selecionar indicadores relevantes, fixar condições de teste e estabelecer quem recebe os sinais de degradação. A alteração do contexto de uso deve provocar uma reavaliação quando comprometer a validade da avaliação anterior.

A terceira é definir como interromper ou substituir a atuação da ferramenta. A alternativa pode envolver controle manual, regras convencionais, redundância ou outra solução tecnicamente adequada. É preciso testar essa transição e conhecer suas limitações: retirar a IA sem uma alternativa segura pode produzir um risco adicional.

A quarta é assegurar a possibilidade de explicar e investigar. A organização precisa identificar quem conserva os registros, quem pode acessá-los e como os participantes cooperam. Essa decisão deve ser compatível com a segurança da infraestrutura e os direitos relativos às informações envolvidas.

Método proposto pelo autor. Sua aplicação deve considerar a criticidade da função e as regras do setor.

O método também ajuda a organizar a resposta a um incidente. Primeiro, protege-se a operação e as pessoas, acionando os responsáveis competentes. Paralelamente, preservam-se os registros relevantes e documentam-se as intervenções necessárias. A investigação deve registrar hipóteses concorrentes, ouvir os participantes e distinguir o que está comprovado do que ainda precisa ser testado. As comunicações obrigatórias devem seguir os requisitos e os prazos aplicáveis ao caso.

Uma atualização necessária à segurança não deve ser adiada apenas para manter o sistema intacto como objeto de prova. A preservação precisa acompanhar a intervenção urgente, na extensão tecnicamente possível. A recuperação do serviço e a investigação devem ser coordenadas desde o início.

Inovar com capacidade de responder

A avaliação de uma solução deve considerar o benefício que ela oferece em comparação com as alternativas disponíveis. Uma ferramenta bem integrada pode ampliar a capacidade de identificar riscos e reduzir a exposição de pessoas a atividades perigosas. Também é necessário avaliar o custo da supervisão, da manutenção dos registros e da contingência: a exigência de controles deve ser proporcional à função e ao dano potencial.

O risco da implantação precisa ser comparado ao da operação existente. Uma exigência de erro zero pode impedir a adoção de uma solução que reduza acidentes ou falhas. O critério que defendo é demonstrar melhoria nas condições concretas de uso, sem ocultar riscos residuais e mantendo capacidade de correção. Essa avaliação deve considerar a qualidade do serviço entregue, além da economia obtida pela empresa.

O critério que proponho para aplicações críticas é concreto: antes de colocar o sistema em operação, a organização deve conseguir explicar quem acompanha seu desempenho, como reage à falha e quais elementos estarão disponíveis para apurar um incidente. Se essas respostas dependem exclusivamente de uma promessa genérica do fornecedor, a contratação ainda precisa amadurecer.

Na infraestrutura, o valor da inteligência artificial será medido também pelo serviço que chega ao usuário. Essa entrega exige que a inovação venha acompanhada da capacidade de corrigir falhas, prestar contas e responder por suas consequências.

Fontes e referências

[1] ANTT. Rodovias inteligentes e transformação digital das concessões. Publicação de 3 de dezembro de 2025, especialmente a descrição de sistemas de Detecção Automática de Incidentes. Acessar fonte

[2] ANTT. Inovação na inspeção de tráfego com benefício da descarbonização e segurança. Página institucional do sandbox. Acessar fonte

[3] ANTT. Deliberação nº 444, de 14 de novembro de 2025, artigos 1º a 3º. Acessar fonte

[4] Câmara dos Deputados. PL nº 2.338/2023. Ficha de tramitação consultada em 19 de outubro de 2026. Acessar fonte

[5] Constituição da República Federativa do Brasil, artigo 37, § 6º. Acessar fonte

[6] Lei nº 8.987/1995, artigos 6º e 25. Acessar fonte

[7] Lei nº 8.078/1990, Código de Defesa do Consumidor, artigo 14. Acessar fonte

[8] Lei nº 10.406/2002, Código Civil, artigos 264, 265, 927 e 942. Acessar fonte

[9] Google DeepMind. DeepMind AI Reduces Google Data Centre Cooling Bill by 40%. Publicação de 20 de julho de 2016. Resultado declarado pela empresa sobre energia utilizada para resfriamento. Acessar fonte

[10] Google DeepMind. Safety-first AI for autonomous data centre cooling and industrial control. Publicação de 17 de agosto de 2018. Descrição empresarial do controle direto e dos mecanismos de segurança. Acessar fonte

[11] NTSB. Investigação HWY18MH010 e relatório HAR-19-03. Collision Between Vehicle Controlled by Developmental Automated Driving System and Pedestrian. Acidente de 18 de março de 2018, Tempe, Arizona. Síntese dos fatos, causa provável e recomendações de segurança. Acessar fonte

[12] Lei nº 13.105/2015, Código de Processo Civil, artigos 373, §§ 1º e 2º, e 381. Acessar fonte

[13] Lei nº 13.709/2018, Lei Geral de Proteção de Dados Pessoais, artigos 6º e 20. Acessar fonte

[14] Comissão Europeia. AI Act Service Desk. Anexo III, item 2. Acessar fonte

[15] Comissão Europeia. AI Act Service Desk. Artigo 14, especialmente parágrafos 3º e 4º. Acessar fonte

[16] Comissão Europeia. AI Act Service Desk. Artigo 12, registro de eventos. Acessar fonte

[17] Comissão Europeia. AI Act. Calendário de aplicação e alterações do AI Omnibus, conforme informação institucional consultada em 19 de outubro de 2026. Acessar fonte

[18] NIST. AI Risk Management Framework. Referência técnica de uso voluntário. Acessar fonte

Referências consultadas em 19 de outubro de 2026. Os casos documentados estão identificados com suas fontes. A simulação numérica e o cenário inicial da rodovia são exemplos didáticos hipotéticos.