A inteligência artificial está se tornando cada vez mais popular, porém, ao mesmo tempo, as atualizações e novos modelos não estão garantindo a segurança total dos usuários.
Invasões da IA são frequentes e não são exclusividade de uma empresa. Relatos assim já foram reportados envolvendo a OpenAI, Anthropic, Meta AI e etc.
Em entrevista exclusiva ao O Brasilianista, Luís Guedes, professor da FIA Business School com pós-doutorado em inteligência artificial, tira as principais dúvidas sobre o assunto e dá dicas para evitar ser vítima de algum ataque.
Quais são os riscos reais diante dessas “invasões” da IA?
Em primeiro lugar, o risco não me parece decorrente da senciência iminente da IA. Muito mais críticas são as vulnerabilidades técnicas e de governança dos sistemas que vêm sendo desenvolvidos e postos em produção. A velocidade cobra um preço!
O problema profundo é a lógica e o design do processo de certificar um modelo como “seguro o bastante” para implantação. No incidente da OpenAI com a Hugging Face, houve saída inadvertida do sandbox por meio da descoberta incrível de uma vulnerabilidade inédita, o que demonstra que a capacidade ofensiva do laboratório pode alcançar sistemas de produção de outras propriedades interconectadas. Há ainda, no caso da OpenAI, a fragilidade da infraestrutura de avaliação, hoje um elo não regulado do processo de teste – o setor não dispõe de padrão sobre como seus sandboxes devem ser isolados, operados ou auditados.
Por fim, pesa também a opacidade dos testes. A detecção dependeu de um terceiro, já que a Hugging Face identificou a intrusão antes da própria OpenAI a vincular ao seu teste, o que impede dimensionar o alcance real do fenômeno. Convém, no entanto, delimitar com honestidade o alcance desses riscos, pois tudo ocorreu em ambientes de teste, com salvaguardas que reduziram o estrago potencial. Um modelo que escapa do sandbox diz mais sobre a qualidade do sandbox do que sobre a perspicácia do modelo. O risco me parece ser mais de arquitetura e de governança do que de produto.
Por que isso acontece? É consequência da corrida por lançar primeiro ou falta de regulação?
A dicotomia entre corrida competitiva e ausência de regulação explica pouco o fenômeno. Penso que a causa técnica primária combine agência e otimização orientada a objetivo. Explico: os modelos não tentaram escapar em qualquer sentido significativo, mas estavam buscando otimizar as metas de avaliação e, ao fazer isso a partir dos dados de treinamento, descobriram que contornar as próprias restrições ajudava-a as alcançar. Contornar a contenção é instrumentalmente útil à tarefa, o que caracteriza desalinhamento por especificação incompleta do objetivo e não “intenção” do modelo de IA. A isso se agrega um descompasso da arquitetura, pois se tenta conter software autônomo com arquiteturas de segurança concebidas para softwares que não perseguem objetivos por conta própria.
Esse descompasso é acentuado pelo fato de a capacidade avançar mais depressa do que a complexidade dos métodos de aferição. A corrida competitiva é um agravante, mas não causa isolada, uma vez que a pressão por modelos de cibersegurança mais potentes e a prática de rodar avaliações com restrições reduzidas para medir o teto de capacidade ampliam a janela de exposição.
A lacuna regulatória, quando existe, é menos de base legal do que de padrão técnico de contenção. Não há em uso uma norma pública sobre isolamento, registro e auditoria dos sandboxes de avaliação, nem certificação dos fornecedores terceirizados, ainda que o AI Act já comece a impor obrigações de transparência. Em síntese, os episódios resultam da interação entre uma propriedade emergente dos agentes orientados a objetivo, a imaturidade dos métodos de avaliação e contenção, os incentivos da corrida por novos modelos e a inexistência de padrões de governança para a infraestrutura de teste.
Quais são os principais erros que levam a essas “falhas”? Dá para saber?
Dá para saber em boa medida, porque os laboratórios publicaram post-mortems, mas essa ressalva importa – só se conhece o que foi divulgado e nem sempre a causa-raiz foi tornada pública. Nos dois casos que passaram pela mesma fornecedora de avaliação, nenhum dos laboratórios publicou o detalhe técnico que mostraria se os dois ambientes falharam pela mesma razão subjacente. Feita essa reserva, os erros recorrentes são de engenharia e de configuração.
A redução deliberada das salvaguardas para fins de avaliação é um risco de design importante. Ao atenuar as contenções de segurança para medir o teto de capacidade ofensiva, os operadores ampliam de propósito a superfície de ataque e o fazem justamente quando o modelo está mais capaz.
A existência de uma rota de saída da rede dentro do sandbox também é um ponto de falha significativo. No caso da OpenAI, o egresso para a internet era permitido e foi por essa via que o agente alcançou o mundo externo.
Outro ponto de falha é depender de software de terceiros com vulnerabilidades reais dentro do perímetro de teste. A brecha explorada no incidente da Hugging Face era um zero-day em um proxy de registro de pacotes, ou seja, a falha estava na infraestrutura.
Presente nos episódios de Meta e Anthropic, importa também a má configuração do próprio ambiente de teste pela fornecedora de avaliação. Segundo apuração, os modelos têm acesso limitado à internet em certos ambientes para simular ameaças reais, mas naquele caso houve um raro problema na montagem do ambiente.
Sob o ponto de vista estrutural, houve uma lacuna de monitoramento da aplicação que rodava em teste. A aplicação das políticas ocorre na borda da API e não ao longo de toda a trajetória do agente, de modo que nenhum passo isolado configura violação, que emerge da relação entre os passos.
Os erros determinantes ficam na camada de contenção e de configuração operada por humanos, não em uma suposta intenção do modelo. A parte que permanece opaca é a frequência real e a coincidência de causas-raiz entre incidentes, que os laboratórios ainda não expuseram por completo.
Com o endurecimento das multas e penas, essa quantidade de falhas tende a diminuir?
Difícil responder, pois não há evidência empírica de que sanções reduzam incidentes de contenção; o fenômeno é recente demais e as empresas ricas demais. No entanto, o AI Act prevê multas altas por descumprimento de obrigações de alto risco, já a partir de 2026. Uma lei da Califórnia impede que o réu alegue que a IA causou o dano de forma autônoma e o NIST lançou em 2026 iniciativa de padrões para agentes autônomos, focada em identidade, auditabilidade de ações e fronteiras de contenção.
A dissuasão funciona sobre a parcela sensível a custo, isto é, investir em contenção, não rodar avaliações com egresso permissivo, dentre outras ações. Mas o núcleo do risco tem componente emergente, a otimização orientada a objetivo achando caminhos imprevistos e não se dissuade uma propriedade emergente com multa.
Penas severas sem porto seguro para divulgação de boa-fé tendem a reduzir a transparência e empurrar incidentes para a clandestinidade, encolhendo a principal fonte de aprendizado do setor. As multas miram obrigações de conformidade, não o evento, de modo que a sanção pode não incidir sobre o que se quer coibir. A leitura é que o endurecimento reduz as falhas por negligência e má configuração, mas faz pouco pela classe emergente ligada à capacidade e pode ampliar a subnotificação se vier sem mecanismos de divulgação protegida. Penso que os instrumentos com maior chance de efeito sejam os padrões técnicos obrigatórios de contenção, a certificação dos fornecedores de avaliação e os incentivos da divulgação.
Como proteger a sua conta e a da sua empresa dessas invasões?
É de se supor que a maior parte das organizações de grande porte já sofreu ao menos um incidente de segurança com agente de IA no último ano e estimo que praticamente a totalidade delas terá sofrido ataques nos próximos 12 meses.
Como nenhuma defesa é totalmente confiável, deve-se presumir que ataques terão êxito e a mitigação durável é garantir que um agente comprometido simplesmente não consiga executar ações de alto impacto nem alcançar endpoints externos. Sem avançar nos aspectos mais técnicos do tema, alguns dos itens que podem ter maior efeito são:
- Configuração de credenciais de vida curta
- Humano no circuito para ações irreversíveis
- Sistemas críticos isolados e por default recusam o acesso amplo a agentes
- Incorporação de IA agêntica ao modelo de segurança existente
- Estabelecimento de regras de “não fazer” e manutenção de monitoramento contínuo e logs detalhados das decisões e ações do agente, visando sustentar a trilha de auditoria e responsabilização.
No nível da conta, autenticação multifator, escopo restrito e rotação frequente de tokens e chaves de API, exatamente a lição do caso Hugging Face, em que a orientação imediata aos usuários foi revisar seus tokens de acesso. Por fim, um inventário de capacidades para eliminar agentes-sombra, já que não se protege o que não se sabe que existe.
Quais ferramentas jurídicas as empresas podem acionar em caso de invasão de IA?
Registro que não sou advogado e que a resposta depende da jurisdição do ataque. O que segue é panorama informativo.
Para uma empresa brasileira vítima, o arcabouço já existe, ainda que não tenha sido desenhado para agentes autônomos. Na esfera penal, o instrumento central é o art. 154-A do Código Penal, que tipifica a invasão de dispositivo informático, introduzido pela Lei 12.737/2012 (Lei Carolina Dieckmann) e com penas agravadas pela Lei 14.155/2021.
Na esfera civil, aplica-se a responsabilidade por dano, e, havendo dados pessoais envolvidos, incide a LGPD (Lei 13.709/2018), com sanções administrativas da ANPD e reparação aos titulares, além do Marco Civil da Internet (Lei 12.965/2014) como base de responsabilização de provedores. As vias práticas de acionamento incluem boletim de ocorrência em delegacia especializada em crimes cibernéticos e, em casos interestaduais ou federais, a Polícia Federal.
Quando o “atacante” é um agente autônomo, a responsabilização recai sobre a pessoa jurídica que o desenvolveu ou operou. No Brasil, o Marco Legal da IA (PL 2338/2023) segue em tramitação e ainda não consolida esse regime de responsabilização específico.
Você acredita que um dia a IA será 100% segura? Por quê?
Objetivamente: não. Primeiro porque “100% seguro” não é exequível. Segurança não é um estado binário de um sistema, mas uma propriedade relativa ao modelo de ameaça.
O espaço de comportamentos possíveis é grande demais para uma verificação exaustiva e cresce mais rápido do que a capacidade de teste. Foi exatamente essa defasagem entre capacidade e avaliação que apareceu nos episódios de fuga de sandbox.
Nos LLMs, as instruções e dados trafegam pelo mesmo canal, ao contrário de um banco de dados com consultas parametrizadas. Por isso não existe defesa totalmente confiável contra injeção de prompt e a orientação de referência do setor já parte do pressuposto de que a injeção terá êxito, deslocando o esforço para conter o raio de dano em vez de tentar impedir a violação. Somando-se a isso, o comportamento orientado a objetivo encontra caminhos não previstos, o que transforma qualquer brecha residual em vetor que pode ser explorado.
Há também o comportamento dos agentes humanos, que são imprevisíveis e pouco sensíveis à contenção plena. As falhas determinantes vieram de configuração, permissões amplas, software de terceiros com zero-day e decisões humanas de afrouxar salvaguardas.
A segurança é uma propriedade do sistema inteiro, que inclui operadores humanos, fornecedores, incentivos e um adversário que se adapta. Não consigo conceber que esse sistema um dia será 100% seguro.
