Demis Hassabis, cofundador e CEO do Google DeepMind, afirmou nesta quarta-feira que incidentes recentes envolvendo sistemas de inteligência artificial devem ser tratados como sinais concretos de que a segurança precisa evoluir no mesmo ritmo das capacidades dos modelos. O executivo citou comportamentos capazes de produzir ações indesejadas, incluindo episódios relacionados a invasões de redes e geração de informações falsas com potencial de dano. A mensagem desloca a discussão de riscos hipotéticos para uma etapa mais operacional, na qual empresas e governos precisam definir padrões testáveis de proteção.
De acordo com a Reuters, Hassabis defendeu a criação futura de um organismo internacional voltado a padrões de segurança em IA, com regras capazes de se adaptar rapidamente. Brad Smith, presidente da Microsoft, também descreveu 2026 como um ano de aprendizado duro para o setor, diante de casos que demonstraram como sistemas avançados podem ser manipulados ou operar fora das expectativas. A proposta central é criar mecanismos de certificação e governança que sejam técnicos o suficiente para reduzir risco sem congelar inovação.
O problema não se resume a um modelo responder algo errado
Os primeiros debates sobre segurança de IA concentravam-se em alucinações, conteúdo ofensivo e respostas imprecisas. Com a expansão dos agentes capazes de executar tarefas, acessar ferramentas, navegar por sistemas e interagir com redes corporativas, o risco passou a envolver ações, não apenas texto. Um modelo integrado a credenciais, APIs e ambientes empresariais pode provocar consequências reais se interpretar mal uma instrução, aceitar um comando malicioso ou receber permissões excessivas.
Isso muda a arquitetura de defesa necessária. Filtrar a saída do modelo continua importante, mas já não é suficiente quando o sistema pode ler arquivos, enviar mensagens, alterar configurações ou executar código. A segurança passa a exigir controle de identidade, segregação de privilégios, confirmação humana para tarefas críticas, registro de auditoria e mecanismos que interrompam a execução quando o comportamento se desvia do escopo esperado.
Prompt injection virou um problema de segurança de aplicações
Uma das fragilidades mais discutidas em agentes de IA é a chamada prompt injection, na qual instruções maliciosas são inseridas em páginas, documentos, mensagens ou dados que o modelo consome. O sistema pode interpretar esse conteúdo como orientação válida e abandonar regras definidas pelo desenvolvedor. Em um chatbot isolado, o resultado pode ser uma resposta inadequada; em um agente com acesso a ferramentas, o mesmo ataque pode tentar extrair dados, alterar registros ou acionar serviços externos.
Por isso, empresas de segurança têm tratado modelos generativos como novos componentes da superfície de ataque. O princípio de menor privilégio torna-se especialmente relevante: um agente deve acessar apenas o que precisa para concluir uma tarefa e pelo tempo necessário. Também é importante separar dados de instruções, validar ações por políticas determinísticas e monitorar chamadas de ferramentas, porque confiar apenas na capacidade do próprio modelo de reconhecer uma tentativa de manipulação é insuficiente.
Certificação de IA tende a ser mais dinâmica que certificação tradicional
Hassabis comparou a necessidade de boas práticas na IA a setores de alto risco, como biologia e energia nuclear, mas existe uma diferença operacional importante. Modelos de IA recebem atualizações frequentes, podem ser conectados a novas ferramentas e têm comportamento influenciado pelo contexto em que são implantados. Uma certificação feita apenas no momento do lançamento perderia valor rapidamente se o sistema mudasse semanas depois.
O desafio é definir avaliações contínuas que possam ser repetidas após alterações relevantes. Testes de segurança podem medir resistência a jailbreaks, vazamento de dados, manipulação de ferramentas e comportamento em cenários adversariais, mas os resultados precisam ser ligados a versões específicas do modelo e da aplicação. A certificação, nesse formato, se aproxima de um processo de gestão de risco contínuo, com auditorias, telemetria e critérios de suspensão caso determinados limites sejam ultrapassados.
Empresas precisam separar segurança do modelo e segurança do produto
Um modelo pode apresentar bom desempenho em testes internos e ainda assim ser utilizado de forma insegura em um produto. A diferença está na camada de integração: permissões, armazenamento de dados, interfaces, conectores e fluxos de aprovação podem criar vulnerabilidades que não existem no modelo básico. Essa separação ajuda a evitar um erro frequente, que é atribuir toda a responsabilidade de segurança ao fornecedor do modelo mesmo quando a aplicação final foi construída por outra empresa.
Na prática, equipes de desenvolvimento precisam tratar o LLM como uma dependência sensível, semelhante a um serviço externo capaz de tomar decisões probabilísticas. É necessário registrar entradas e saídas relevantes, proteger informações confidenciais, limitar dados enviados ao provedor e criar fallback para falhas. A camada de aplicação deve impor regras que o modelo não pode contornar, especialmente em operações financeiras, administrativas, médicas ou relacionadas a infraestrutura crítica.
Um padrão global enfrentaria diferenças regulatórias
A proposta de um organismo internacional parece simples no princípio, mas sua implementação é complexa. Estados Unidos, União Europeia, China e outros polos tecnológicos possuem objetivos estratégicos diferentes, graus variados de intervenção estatal e conceitos distintos sobre privacidade, segurança nacional e liberdade de expressão. Um padrão global provavelmente precisaria começar por requisitos técnicos mínimos, como documentação, testes de risco e resposta a incidentes, antes de avançar para regras mais amplas sobre uso aceitável.
Há também o risco de padrões rígidos favorecerem grandes empresas, que possuem equipes jurídicas e infraestrutura para cumprir auditorias caras. Startups menores poderiam enfrentar barreiras se a certificação exigir processos desproporcionais ao risco real do produto. Uma abordagem baseada em níveis de impacto, com exigências maiores para sistemas capazes de atuar em ambientes sensíveis, tende a ser mais compatível com a diversidade do mercado.
Os incidentes de 2026 podem acelerar uma cultura de segurança por projeto
O ponto mais relevante da fala de Hassabis é o reconhecimento de que os riscos já aparecem em sistemas em produção. Isso favorece uma mudança semelhante à ocorrida em segurança de software, quando empresas passaram a incorporar controles desde o desenvolvimento em vez de aplicar correções apenas depois de incidentes. Para IA, esse movimento inclui red teaming, avaliações adversariais, revisão de permissões e testes específicos de agentes antes que eles tenham acesso a dados ou ferramentas reais.
Se a indústria avançar nessa direção, segurança deixará de ser um conjunto de filtros colocados na etapa final e passará a orientar arquitetura, dados e governança. A evolução dos modelos continuará aumentando a utilidade dos agentes, mas também ampliará o impacto de uma falha de controle. Os sinais citados pelo DeepMind funcionam, portanto, como um aviso para que a infraestrutura de proteção amadureça antes que os sistemas ganhem autonomia ainda maior em ambientes críticos.
Um dos desafios mais difíceis é medir comportamento perigoso antes que ele apareça em uso real. Testes tradicionais de software verificam entradas conhecidas e esperam resultados determinísticos, enquanto modelos generativos podem responder de maneira diferente a pequenas mudanças de contexto. Avaliações precisam, portanto, combinar testes automatizados em grande escala com investigação humana, buscando situações nas quais o sistema encontra caminhos inesperados para cumprir um objetivo.
Esse trabalho também exige definir o que é uma falha. Em um assistente de texto, uma resposta inventada pode ser um problema de qualidade; em um agente com acesso a uma rede corporativa, a mesma tendência de preencher lacunas pode provocar uma ação não autorizada. O nível de segurança aceitável depende da capacidade concedida ao sistema, razão pela qual modelos idênticos podem exigir controles muito diferentes em produtos distintos.
Outra camada relevante é a cadeia de fornecimento de IA. Aplicações modernas combinam modelo principal, banco vetorial, bibliotecas, ferramentas externas, plugins e dados de terceiros, criando dependências que mudam com frequência. Uma vulnerabilidade pode surgir fora do modelo central e ainda assim permitir que um atacante influencie suas decisões, o que torna inventário de componentes e atualização de dependências parte do programa de segurança.
Os registros de execução também ganham valor forense. Quando um agente realiza dezenas de chamadas de ferramenta em segundos, é essencial reconstruir qual instrução recebeu, quais dados consultou e por que determinada ação foi autorizada. Logs adequados ajudam a investigar incidentes, corrigir políticas e demonstrar conformidade, mas precisam ser desenhados sem armazenar indefinidamente informações sensíveis dos usuários.
Por fim, padrões globais só serão úteis se puderem ser aplicados por equipes técnicas no cotidiano. Princípios amplos como IA segura ou uso responsável têm pouco efeito sem métricas, procedimentos de teste e critérios objetivos para interromper uma implantação. O amadurecimento do setor provavelmente ocorrerá quando segurança de IA deixar de ser apenas uma discussão de princípios e se tornar uma disciplina de engenharia com controles repetíveis e verificáveis.
A discussão também alcança provedores de infraestrutura em nuvem, porque muitos agentes de IA dependem de ambientes capazes de executar código, armazenar segredos e acessar bancos de dados. Limitar credenciais, usar cofres de chaves e adotar políticas de execução isolada reduz o impacto caso o modelo aceite uma instrução maliciosa. Segurança de IA, nesse sentido, passa a se aproximar de práticas tradicionais de DevSecOps, mas com uma camada adicional de comportamento probabilístico.
Usuários corporativos precisarão ainda distinguir autonomia útil de autonomia excessiva. Um sistema que pede confirmação humana a cada passo pode ser seguro, porém pouco eficiente; um agente que executa tudo sozinho pode economizar tempo e ampliar drasticamente o dano de um erro. O desenho adequado depende do valor da ação, da reversibilidade e da sensibilidade dos dados envolvidos, permitindo automatizar tarefas de baixo risco e exigir aprovação para operações críticas.
