Especialistas federais pedem testes rigorosos de IA antes da implantação

O Google News trouxe novamente à tona um alerta federal marcado por um conflito claro: as agências estão implantando mais IA enquanto testes confiáveis continuam caros, lentos e incompletos.

O relatório de origem descreve especialistas federais em tecnologia pedindo que as agências testem a IA repetidamente antes de usá-la em ambientes de alto impacto. A preocupação não se limita às questões conhecidas sobre dados de treinamento enviesados. Eles também querem que as agências examinem como os modelos se comportam com usuários reais, informações sensíveis, pressão operacional e condições que os desenvolvedores não previram.

Essa posição desafia o esforço paralelo do governo federal por uma adoção mais rápida. As agências foram orientadas a remover barreiras desnecessárias, modernizar serviços e usar IA comercial com mais eficiência. Ainda assim, as mesmas instituições seguem responsáveis quando uma recomendação automatizada, verificação de identidade, resumo ou ação de software prejudica o público.

A manchete do Google News aponta para uma lacuna mais ampla de testes

O avanço importante não é uma nova proibição federal, mas uma demanda crescente por evidências antes que a IA chegue a fluxos de trabalho de alto impacto.

A discussão sobre testes federais reuniu autoridades e especialistas do Department of Homeland Security, Idaho National Laboratory e HP Federal. Seus comentários se concentraram em vieses, supervisão humana e no valor de testes contínuos.

Arun Vemury, assessor sênior da Science and Technology Directorate do DHS, descreveu os testes como uma despesa essencial, mas frequentemente negligenciada. As organizações muitas vezes os evitam porque uma avaliação significativa exige tempo, dados adequados, especialistas técnicos e ambientes semelhantes às operações reais.

Essa evasão cria um atalho perigoso. Um modelo pode ter bom desempenho em uma demonstração controlada e ainda falhar quando implantado entre diferentes populações, dispositivos, locais ou condições de trabalho.

Um sistema de reconhecimento facial oferece um exemplo claro. Sua precisão média diz pouco aos tomadores de decisão sobre o desempenho em condições de pouca iluminação, com credenciais danificadas ou entre grupos demográficos. Uma pontuação geral impressionante pode ocultar erros concentrados que afetam pessoas específicas.

Modelos de linguagem criam um problema de medição diferente. Suas respostas variam conforme os prompts, documentos recuperados, versões do modelo e instruções de sistema. Uma equipe não pode comprovar confiabilidade enviando várias perguntas favoráveis e registrando as melhores respostas.

Por isso, os especialistas federais tratam o viés como algo que deve ser gerenciado durante toda a vida útil de um sistema. Esse enquadramento importa porque rejeita a ideia de que os desenvolvedores podem eliminar toda tendência indesejável durante o treinamento.

O comportamento de um modelo surge da seleção de dados, do design do sistema, da interação dos usuários e do contexto de implantação. Mesmo um modelo tecnicamente competente pode produzir um resultado prejudicial quando a tarefa atribuída a ele é mal definida.

A apresentação no Google News reduz esse argumento a um apelo direto por testes rigorosos. A questão completa é mais difícil: as agências precisam de programas de teste que reflitam cada missão, população afetada e nível aceitável de falha.

Essa exigência muda quem participa de um projeto de IA. Responsáveis por compras precisam solicitar evidências, gestores de programas precisam definir a tarefa pretendida e especialistas do domínio precisam identificar resultados inaceitáveis. Equipes de segurança devem testar os limites de acesso, enquanto os usuários precisam avaliar se as saídas são úteis na prática.

Os desenvolvedores, sozinhos, não podem responder a essas perguntas. Eles entendem o sistema, mas não representam todas as pessoas afetadas por suas decisões.

A distinção entre uma demonstração e uma implantação é especialmente importante. Uma demonstração pergunta se uma ferramenta de IA consegue produzir o resultado desejado. Os testes de implantação perguntam com que frequência ela falha, quais usuários enfrentam essas falhas e se os controles existentes as detectam.

As agências federais também operam sob restrições que empresas de software voltadas ao consumidor nem sempre compartilham. Seus sistemas podem processar registros de saúde, informações sobre benefícios, dados de aplicação da lei, arquivos de pessoal e material de segurança nacional.

Um erro inofensivo em um assistente de redação não é equivalente a um erro em um fluxo de trabalho de identidade, saúde ou elegibilidade. Os testes devem seguir as consequências, não o entusiasmo em torno do modelo.

É por isso que a manchete merece atenção mesmo sem uma nova regra. Ela captura uma mudança prática: sair da discussão sobre princípios de IA para exigir desempenho observável em condições reais.

A adoção federal mais rápida eleva os riscos

As agências federais enfrentam pressão em ambas as direções: avançar lentamente demais e perder capacidade útil, ou avançar rápido demais e expor o público a sistemas pouco compreendidos.

A escala da adoção explica por que os testes se tornaram urgentes. Uma análise federal de IA do Government Accountability Office examinou inventários de 11 agências.

Esses inventários continham 571 casos de uso de IA relatados em 2023 e 1.110 em 2024. Os casos de uso relatados de IA generativa passaram de 32 para 282 no mesmo período, um aumento de cerca de nove vezes.

Esses números não comprovam que todos os sistemas listados chegaram à produção. Os inventários podem incluir usos planejados, exploratórios e operacionais. Ainda assim, mostram que equipes federais estão avaliando a IA em muito mais tarefas do que antes.

Os casos de uso vão além de chatbots públicos. O GAO identificou possíveis aplicações em comunicação escrita, acesso à informação, acompanhamento de programas, imagens médicas e extração de informações de saúde pública a partir de documentos.

Cada categoria cria uma definição diferente de desempenho aceitável. Um assistente de redação pode tolerar uma frase estranha se uma pessoa a revisar. Um sistema que apoia trabalho médico ou de segurança pública precisa de evidências muito mais robustas.

Assim, os líderes das agências precisam classificar o risco antes de escolher um plano de avaliação. A questão central não é se um modelo usa IA generativa. É o que acontece quando o modelo erra.

Considere uma ferramenta que resume políticas internas. Seu risco mais evidente é um resumo impreciso. No entanto, ela também pode omitir uma exceção, expor texto restrito, citar uma regra substituída ou produzir respostas diferentes para usuários semelhantes.

Um piloto pode deixar de identificar essas falhas porque os participantes já entendem o material de origem. Novos funcionários poderiam confiar na mesma saída sem perceber o que foi omitido.

As compras acrescentam outra camada. As agências muitas vezes adquirem modelos, serviços de nuvem e aplicações de fornecedores, em vez de desenvolver tudo internamente. Os compradores passam então a depender de documentação e evidências de avaliação que podem não corresponder ao ambiente do governo.

O benchmark de um fornecedor pode demonstrar que um modelo tem bom desempenho em um teste padrão. Ele não pode demonstrar que o sistema completo da agência se comportará com segurança com dados locais, ferramentas de recuperação, permissões e usuários.

A distinção se torna mais séria com IA agêntica. Um agente de IA é um sistema que pode escolher e executar ações por meio de software conectado, em vez de apenas retornar texto.

Um chatbot comum pode gerar uma recomendação falsa. Um agente conectado pode agir com base nela alterando um registro, enviando uma mensagem, chamando um serviço externo ou iniciando outro fluxo de trabalho.

Os testes precisam então abranger tanto o modelo quanto sua autoridade. Os avaliadores precisam determinar quais ações são permitidas, como as aprovações funcionam e se o sistema para quando as instruções entram em conflito.

Tamara Lilly, assistente de inspetora-geral no Department of Health and Human Services, alertou que sistemas automatizados podem operar mais rápido do que os controles tradicionais. Sua orientação sobre governança operacional enfatizou limites claros, regras de acesso e evidências contínuas de que os controles funcionam.

Essa é a pressão por trás da história do Google News. Diretores de informação e diretores de IA precisam gerar resultados úteis ao mesmo tempo que impedem que a experimentação se transforme em implantação descontrolada.

A tensão orçamentária é inevitável. Ambientes de avaliação, conjuntos de dados representativos, red teams, revisões de acessibilidade, testes de segurança e monitoramento pós-implantação consomem recursos.

Essas despesas podem parecer atrasar os benefícios para a missão. No entanto, testes insuficientes não eliminam o custo. Eles transferem esse custo para usuários, equipes de resposta a incidentes, auditores e futuros trabalhos de remediação.

O governo também enfrenta um problema de confiança do qual organizações privadas às vezes conseguem escapar. As pessoas nem sempre podem escolher outro sistema de benefícios, processo de fronteira ou agência pública após uma falha automatizada.

Essa falta de escolha eleva o padrão. As agências precisam de evidências de que uma ferramenta funciona para a finalidade definida, não de uma alegação ampla de que o modelo subjacente é avançado.

Portanto, um programa útil de adoção separará a assistência de baixo risco do suporte a decisões de alto impacto. Ele pode avançar rapidamente em tarefas de redação reversíveis, enquanto aplica barreiras mais rigorosas a sistemas que afetam direitos, acesso, segurança ou serviços essenciais.

Essa abordagem não exige tratar todos os recursos de IA como igualmente perigosos. Ela exige adequar as evidências e a intensidade dos controles às consequências de uma falha.

Velocidade versus garantia é o verdadeiro conflito da IA federal

O conflito central não é inovação versus regulação; é implantação rápida versus garantia específica para cada missão.

A Casa Branca reforçou a adoção federal mais rápida em abril de 2025, por meio de políticas revisadas sobre o uso e as compras de IA pelas agências. A política federal de IA enfatizou a redução de barreiras desnecessárias, mantendo ao mesmo tempo proteções para privacidade, direitos civis e liberdades civis.

Essa combinação parece compatível no papel. Na prática, velocidade e garantia disputam a mesma equipe, o mesmo orçamento e a mesma atenção da liderança.

Uma equipe pode adquirir rapidamente um assistente comercial. Ela não pode determinar instantaneamente como esse assistente lida com todos os documentos restritos, instruções enganosas, alegações sem respaldo ou solicitações incomuns de usuários.

A escolha resultante costuma ser apresentada de forma incorreta. Pergunta-se aos líderes se apoiam a adoção de IA ou se preferem cautela. Esse enquadramento transforma trabalho essencial de engenharia em uma preferência política.

Os testes fazem parte da implantação, não são um argumento contra ela. Aviação, tecnologia médica, cibersegurança e outros campos de alto impacto dependem de avaliação porque sistemas úteis ainda podem falhar.

A IA complica esse princípio porque seu comportamento é probabilístico. Um sistema probabilístico pode produzir saídas diferentes a partir de entradas semelhantes, especialmente após um fornecedor atualizar o modelo.

Os testes tradicionais de software continuam necessários, mas não são suficientes. Um desenvolvedor pode verificar que uma API retorna uma resposta sem comprovar que ela é precisa, justa, segura ou útil.

As equipes federais precisam de várias camadas de garantia. Os testes de capacidade perguntam se o sistema conclui a tarefa atribuída. Os testes adversariais perguntam como ele responde a tentativas de manipulação.

Os testes de campo examinam o desempenho com usuários reais e condições operacionais realistas. O monitoramento verifica se os resultados mudam após a implantação, novos dados ou uma atualização do modelo.

A supervisão humana conecta essas camadas. Uma pessoa não pode supervisionar de forma significativa um sistema de IA sem tempo, autoridade e conhecimento do domínio suficientes para questionar suas saídas.

Um botão de aprovação meramente formal não cria supervisão. Se os funcionários processam centenas de recomendações sob pressão de prazos, podem aceitar os resultados automaticamente.

As agências devem testar o fluxo de trabalho humano junto com o modelo. Elas devem medir se os revisores identificam erros, compreendem a incerteza e sabem quando escalar um resultado.

Isso cria uma inversão desconfortável. A IA costuma ser adquirida para reduzir trabalho, mas a implementação segura pode, inicialmente, exigir trabalho mais especializado.

As equipes de programa precisam de especialistas no assunto para criar casos de teste. Especialistas em segurança devem examinar os fluxos de dados, advogados devem avaliar as obrigações legais e especialistas em acessibilidade devem avaliar o impacto sobre os usuários.

O investimento ainda pode compensar. Um sistema testado pode reduzir tarefas repetitivas, mantendo as pessoas focadas em exceções e julgamento. No entanto, os líderes não devem fingir que a supervisão surge automaticamente.

O mesmo conflito afeta os fornecedores. Compradores governamentais querem acesso rápido a modelos mais novos, mas atualizações frequentes podem invalidar resultados de avaliações anteriores.

Um fornecedor pode melhorar o raciocínio geral enquanto altera o comportamento de recusa, a formatação ou o desempenho em uma tarefa especializada. As agências precisam de controles de versão e gatilhos de revalidação antes de aceitar essas atualizações.

Os provedores de modelos também não conseguem testar sozinhos todos os contextos federais. Um sistema de uso geral enfrenta riscos diferentes quando conectado a registros de imigração, dados científicos, documentos de compras públicas ou fluxos de trabalho clínicos.

A responsabilidade, portanto, é compartilhada, mas não intercambiável. Os fornecedores devem divulgar limitações e mudanças relevantes. As agências ainda precisam testar o sistema montado no ambiente a que se destina.

O Google News oferece um caminho simples para descobrir o tema, mas o conflito de políticas vai muito além de uma única manchete. Líderes federais estão sendo pressionados a acelerar a adoção sem reduzir os padrões associados à autoridade pública.

A resposta viável é a implantação em etapas. As equipes começam com uma tarefa restrita, dados limitados, permissões controladas e critérios mensuráveis de sucesso.

Em seguida, expandem apenas quando as evidências sustentam a expansão. Esse método preserva o ritmo enquanto cria um registro que auditores, gestores e usuários afetados podem examinar.

A implantação em etapas também torna as falhas mais informativas. Um piloto controlado pode revelar que um modelo é inadequado sem criar um problema de serviço em escala nacional.

A alternativa é a implantação movida por entusiasmo. Esse caminho trata a fluência inicial como prova, confunde benchmarks de fornecedores com desempenho na missão e descobre limitações por meio de incidentes públicos.

Testes Rigorosos de IA Devem Acompanhar o Sistema Até a Produção

Um teste pré-implantação é um ponto de partida, porque o comportamento da IA pode mudar quando modelos, dados, usuários e ferramentas conectadas mudam.

O National Institute of Standards and Technology descreve os testes por meio do processo mais amplo de testes, avaliação, verificação e validação. Esse processo costuma ser abreviado como TEVV.

A estrutura de risco do NIST afirma que sistemas de IA devem ser testados antes da implantação e regularmente durante a operação. Ela também exige métodos documentados, critérios mensuráveis, condições realistas e a participação de especialistas independentes ou internos que não façam parte da equipe de desenvolvimento.

Essa orientação revela por que a palavra “rigorosos” importa. Submeter um modelo a uma lista fixa de prompts uma única vez não estabelece um desempenho confiável.

Uma avaliação significativa começa com uma tarefa definida. As agências devem especificar os usuários pretendidos, os dados disponíveis, as condições operacionais, as ações proibidas e as consequências de uma falha.

Os avaliadores podem então elaborar testes em torno de casos realistas. Devem incluir exemplos comuns, casos raros, entradas adversariais, informações incompletas e situações em que o sistema deve se recusar a agir.

As métricas também devem refletir a missão. A precisão pode ser importante, mas talvez não revele se os erros estão concentrados em determinados grupos.

Uma equipe que avalia resumos pode medir alegações sem suporte, requisitos ausentes, citações incorretas e divulgação de informações restritas. Uma equipe que avalia tecnologia de identidade precisaria de medidas diferentes.

Os limites devem ser definidos antes que os líderes vejam resultados favoráveis. Caso contrário, as equipes de projeto podem redefinir o sucesso após observar as fraquezas do sistema.

A avaliação independente ajuda a enfrentar esse risco. Os desenvolvedores naturalmente entendem como obter bons resultados de seu sistema. Usuários e avaliadores externos têm maior probabilidade de descobrir instruções confusas e comportamentos inesperados.

O red teaming acrescenta outra perspectiva. Red teaming é um teste adversarial estruturado que busca fraquezas, resultados prejudiciais ou formas de contornar controles.

Isso não deve se transformar em encenação. Alguns poucos prompts dramáticos podem gerar publicidade sem medir os riscos que importam para uma agência específica.

Boas equipes de red teaming trabalham a partir de um modelo de ameaças, que identifica possíveis atacantes, ativos protegidos, métodos prováveis e consequências operacionais. Suas conclusões devem levar a correções, novos testes e decisões documentadas.

Os testes em campo são igualmente importantes porque os laboratórios não conseguem reproduzir todos os comportamentos humanos. Funcionários podem copiar documentos maiores do que o esperado, fazer perguntas ambíguas ou combinar resultados com informações não oficiais.

Um sistema também pode mudar o ambiente de trabalho ao seu redor. A equipe pode deixar de verificar fontes primárias, alterar a forma como documenta decisões ou recorrer a linguagem gerada que obscurece a responsabilização.

Esses efeitos raramente aparecem em um benchmark. Eles surgem por meio de observação, entrevistas com usuários, relatórios de incidentes e medições repetidas.

O monitoramento em produção deve então detectar desvios. Desvio significa que a relação entre entradas, comportamento do modelo e resultados esperados muda ao longo do tempo.

A causa pode ser uma nova versão do modelo, uma população de usuários diferente, uma coleção de recuperação alterada ou mudanças nas condições do mundo real. Qualquer um desses fatores pode enfraquecer uma avaliação anterior.

O monitoramento deve registrar mais do que a disponibilidade do sistema. As equipes precisam de sinais sobre resultados incomuns, controles que falharam, intervenções dos usuários, reclamações e qualidade específica da tarefa.

Também precisam de um processo de incidentes. Os funcionários devem saber onde relatar um resultado suspeito, e os responsáveis pelo programa devem ter autoridade para restringir ou suspender o sistema.

Essa capacidade é mais importante para agentes conectados. O acesso de menor privilégio significa conceder a um sistema apenas as permissões necessárias para sua tarefa atribuída.

Um assistente de redação não precisa de autoridade para publicar. Um agente de agendamento não precisa de acesso irrestrito aos registros de pessoal.

As equipes devem testar o que acontece quando o modelo solicita uma ação fora de suas permissões. O resultado esperado deve ser uma falha controlada, e não uma solução improvisada.

A avaliação de dados merece a mesma atenção. As agências precisam entender quais informações entram em um modelo, onde são processadas, o que é retido e quem pode recuperá-las.

A geração aumentada por recuperação, um método que fornece documentos selecionados a um modelo, pode melhorar a relevância. Também pode reproduzir material desatualizado, não autorizado ou contraditório.

A governança de documentos, portanto, torna-se parte dos testes de IA. Uma base de conhecimento pesquisável confiável precisa de responsabilidade definida, controles de acesso, material-fonte atualizado e atualizações rastreáveis.

O ponto cético é que nenhum programa de avaliação pode provar que um modelo geral é seguro em todas as condições. As possíveis entradas e interações são amplas demais.

As agências devem evitar alegações absolutas, como imparcial, seguro ou livre de alucinações. Essas descrições vão além do que um teste delimitado pode estabelecer.

Uma conclusão defensável é mais restrita. As evidências podem mostrar que um sistema específico atingiu limites definidos para uma tarefa, versão, população e ambiente específicos.

Essa qualificação não é uma fraqueza. É a base de uma garantia honesta.

As equipes federais também precisam publicar informações suficientes para a supervisão sem expor sistemas sensíveis. Elas podem descrever o uso pretendido, as categorias de avaliação, as limitações e os processos de monitoramento, ao mesmo tempo que protegem detalhes operacionais.

A transparência fortalece a responsabilização porque permite ao público distinguir entre um assistente controlado e um tomador de decisões automatizado. Também dá a inspetores e legisladores uma base para fazer perguntas precisas.

O maior risco de implementação é transformar os testes em uma lista de verificação. Um formulário preenchido não pode substituir evidências realistas.

Os documentos de conformidade importam, mas devem apontar para resultados de testes, registros de incidentes, versões de modelos e responsáveis definidos. Caso contrário, as agências correm o risco de produzir ampla documentação em torno de um sistema incerto.

O Que os Compradores Federais de IA Devem Observar a Seguir

A próxima fase será medida pela capacidade das agências federais de converter princípios de teste em barreiras de implantação aplicáveis e evidências contínuas.

O primeiro sinal é como as agências implementam a aprovação baseada em risco para IA com consequências relevantes. Inventários, por si só, não conseguem mostrar se os líderes interromperam, restringiram ou redesenharam sistemas que falharam na avaliação.

Observe a documentação pública que distingue assistência de baixo risco de IA que afeta direitos, segurança, acesso ou serviços essenciais. Categorias claras reforçariam o argumento de que uma adoção mais rápida pode coexistir com garantias mais rigorosas.

A ausência dessas categorias o enfraqueceria. As agências poderiam alegar conformidade enquanto aplicam revisões semelhantes a riscos fundamentalmente diferentes.

O segundo sinal é se os contratos de aquisição preservam os direitos de avaliação após a compra. Compradores governamentais precisam de acesso a avisos sobre mudanças de modelo, documentação relevante, suporte a testes e controles sobre atualizações.

A linguagem contratual também deve esclarecer as responsabilidades por incidentes e o tratamento de dados. Sem esses termos, as agências podem se tornar dependentes de garantias de fornecedores que não refletem seu ambiente implantado.

Evidências de requisitos contratuais repetíveis mostrariam que os testes avançaram para etapas iniciais da aquisição. A dependência contínua de alegações genéricas de desempenho sugeriria que a lacuna de implantação permanece.

O terceiro sinal é o que as agências relatam após os sistemas entrarem em produção. Evidências úteis incluiriam práticas de monitoramento, incidentes relevantes, ações corretivas e exemplos de usos restringidos ou descontinuados.

A ausência de incidentes relatados não estabelece necessariamente segurança. Pode indicar que os funcionários não têm canais de denúncia ou que as agências definem incidentes de forma excessivamente restrita.

Os leitores devem prestar atenção especial aos sistemas que recebem permissão para agir. A passagem de texto gerado para ação autônoma aumenta tanto o benefício potencial quanto o custo de um erro.

É aqui que o Google News e plataformas de descoberta semelhantes têm um papel útil. Elas podem revelar audiências de agências, entrevistas com especialistas, relatórios de órgãos de fiscalização e mudanças de políticas que, de outra forma, permaneceriam dispersos.

Agregação não é verificação, porém. Os leitores devem seguir uma manchete até a reportagem original e então comparar suas alegações com políticas, auditorias e orientações técnicas.

As evidências atuais sustentam uma conclusão cautelosa. A implantação federal de IA está se expandindo, enquanto especialistas ainda desenvolvem os métodos necessários para avaliar sistemas em condições realistas.

Isso não justifica congelar todos os projetos. Sustenta casos de uso restritos, limites mensuráveis, autoridade humana, permissões limitadas e monitoramento após o lançamento.

A questão decisiva já não é se as agências federais usarão IA. Elas já usam, e seus casos de uso relatados cresceram substancialmente.

A questão é se cada agência consegue demonstrar por que um sistema específico merece a autoridade atribuída. Essa prova deve incluir a tarefa, as condições testadas, os limites de falha, o responsável e a resposta quando o comportamento muda.

Quando a próxima manchete do Google News anunciar a implementação federal de IA, vá além do nome do modelo. Pergunte o que foi testado, quem o avaliou, quais falhas permanecem e se a agência consegue interromper o sistema com segurança.