Sempre que assisto a mais uma apresentação sobre “os riscos da Inteligência Artificial”, há um padrão que me deixa desconfortável: o mesmo slide com prompt injection (injeção de instruções), alucinações e mais uns quantos acrónimos em inglês. O problema não é esses riscos não existirem. O problema é a sensação de que estamos obcecados com os sintomas e quase não falamos da doença.
Nunca, em toda a minha carreira, confiei no frontend, a camada com que o utilizador interage. Um formulário web pode validar o que quiser em JavaScript, pode ter as melhores mensagens de erro do mundo, mas, se o backend (a parte que processa os dados e executa a lógica do sistema) não validar tudo de novo, essa validação não vale nada. Qualquer pessoa com o browser aberto e um bocadinho de curiosidade consegue contornar o frontend. É uma regra básica de segurança.
Um dos usos da Inteligência Artificial (IA) generativa é exatamente isso. Um frontend extremamente sofisticado, capaz de conversar, argumentar e parecer que percebe o que está a fazer. Mas continua a poder ser manipulada ou enganada. E, no entanto, muitas empresas tratam as respostas de um modelo como se fossem uma decisão de autorização legítima. Há quatro questões que me preocupam verdadeiramente.
A primeira: não sabemos, ao certo, o que comemos
Compramos um modelo, fazemos download de um repositório qualquer ou simplesmente usamos uma API (Application Programming Interface) e confiamos, porque o modelo responde bem e passa nos nossos testes. Mas já há casos documentados de modelos treinados com comportamentos escondidos, que só se manifestam sob determinadas condições.
A pergunta que ainda não fazemos vezes suficientes é: quem treinou este modelo, com que dados e com que objetivo? Há anos que fazemos este tipo de avaliação sobre componentes de software. Ainda não conseguimos fazê-la da mesma forma sobre um modelo de linguagem, e isso deve preocupar-nos.
A segunda: parem de enviar tudo para a cloud
Isto é capaz de ser o ponto mais impopular do artigo, mas vou dizê-lo na mesma: uma parte significativa dos dados que as organizações enviam todos os dias para API de terceiros não precisava de sair da empresa. Há modelos open source, validados, com qualidade mais do que suficiente para muitos casos de uso reais, que podem correr em infraestrutura própria. Não é a mesma coisa que ter o modelo fechado mais badalado do momento, admito. Mas, para dados sensíveis e processos internos, faz muito mais sentido manter o processamento dentro de portas.
Não é só uma questão de custo. É uma questão de quem tem acesso aos meus dados e por quantas mãos passam antes de eu sequer saber.
A terceira: a autorização não pode viver dentro do modelo
Chegamos ao ponto central e que dá título a este artigo. A IA pode ser enganada. Pode ser convencida a fazer algo que não deve. Chama-se prompt injection, mas o nome interessa menos do que a consequência: se uma aplicação confiar que o modelo só vai pedir aquilo que o utilizador tem permissão para pedir, está a construir a tua segurança em cima de areia movediça.
A regra deve ser simples: cada serviço que recebe um pedido, seja ele originado por um humano ou por um agente de IA, tem de validar, de forma independente, se quem está do outro lado tem autorização para aquela ação específica. Nunca assumir. Nunca confiar que “a camada anterior já tratou disso”. É a lógica de Zero Trust, que já aplicamos em rede há anos, só que agora aplicada a quem, ou ao que, está a pedir a ação.
Descobri que este problema já tem nome próprio e uma história com quase quatro décadas: chama-se “confused deputy problem” ou, em português, problema do representante confuso, e foi descrito ainda nos anos 80, muito antes dos atuais agentes baseados em grandes modelos de linguagem. Descreve exatamente isto: um programa com mais privilégios do que quem o está a usar acaba enganado e age em nome de alguém sem autorização para tal.
A quarta: precisamos de saber do que é feito aquilo que usamos
Se a origem dos modelos importa, precisamos de a documentar e monitorizar, não apenas preocupar-nos em abstrato. O mundo do software já resolveu, em boa parte, este problema com o SBOM (Software Bill of Materials), o inventário de tudo o que compõe uma aplicação. Está agora a nascer o equivalente para IA, chamado AIBOM (Artificial Intelligence Bill of Materials): um inventário que não cobre só bibliotecas e dependências, mas também a informação dos dados de treino, as origens dos modelos, os fine-tunes aplicados e as ligações a serviços externos e agentes. Sem isto, estamos a gerir um risco que nem sequer conseguimos ver por inteiro.
O toque final, e o que mais me faz pensar
Há ainda uma ironia difícil de ignorar: a mesma tecnologia que pode ser treinada de forma maliciosa é, também, cada vez melhor a encontrar vulnerabilidades e a testar sistemas por nós. Modelos capazes de explorar falhas com uma velocidade que nenhuma equipa humana consegue replicar. É a faca de dois gumes mais literal que alguma vez vi em segurança. A ferramenta que reforça a defesa e a ferramenta que pode comprometer o teu sistema são, no limite, a mesma coisa. Tudo depende de quem a controla, com que autorização e com que supervisão.
É por isto que me parece redutor falar dos “riscos da IA” como se fossem uma lista de bugs a corrigir. O problema não é técnico, é de confiança mal colocada. Continuamos a tratar como oráculo aquilo que devíamos tratar como intermediário não fiável. A origem importa. Onde corre importa. Quem autoriza importa, sempre, em cada ponto da cadeia. E se não conseguirmos responder a estas perguntas com factos, então estamos só a construir mais um sistema bonito por fora e vazio por dentro, à espera do dia em que alguém descobre que nunca ninguém validou nada a sério do outro lado.
A IA não é mágica. É a interface mais convincente que a nossa indústria alguma vez construiu. E nenhum frontend, por muito “bem vestido” que esteja, deveria ter as chaves do backend na mão.
Este artigo faz parte do Caderno Especial “Cibersegurança”, publicado na edição de Outubro (n.º 247) da Executive Digest.
