O paradoxo da segurança em sistemas de IA

Quanto mais os modelos de IA evoluem, mais aparece um paradoxo de segurança curioso.

Quanto mais a IA avança, mais ela pode ser usada como uma arma de invasão em escala. Mas quanto mais a IA avança, mais segura elas se tornam também.

Modelos mais avançados tendem a ser mais difíceis de “invadir” diretamente. Mais camadas de mitigação, mais detecção, mais limites.

Ao mesmo tempo, esses modelos viram um multiplicador do outro lado. Mais capacidade de persuasão, mais automação, mais escala.

O ataque não precisa mais “quebrar o modelo”. Basta explorar o sistema ao redor: integrações, contexto, usuários, dados.

A IA fica mais resistente por dentro, mas amplifica golpes e ataques por fora. Ou seja, o risco não some, ele muda de lugar.

Onde mora o risco hoje: três pontos-chave

Então onde estão, na prática, os maiores riscos de segurança com IA em aplicações com LLM hoje? Eu começaria por três pontos: prompt injection, context poisoning e stale data.

1) Prompt injection

Prompt injection é a versão moderna de “input malicioso”. Só que o input agora é linguagem natural.

OWASP já coloca prompt injection como um dos riscos centrais em aplicações com LLM (LLM01).

O que mais preocupa não é “fazer o modelo falar besteira”, mas fazer o sistema agir errado:

• chamar uma ferramenta indevida;
• buscar algo que não deveria;
• vazar uma informação;
• disparar um processo sensível.

E isso não é teoria. Já existem explorações em copilotos corporativos que, a partir de uma simples mensagem ou conteúdo embutido, conseguem exfiltrar dados ou burlar controles — uma espécie de “zeroclick prompt injection”.

2) Context poisoning

Se você usa RAG, memória, wiki ou base interna, você criou uma supply chain de contexto. E toda cadeia de suprimento é atacável — tanto por malícia (conteúdo envenenado) quanto por acidente (conteúdo ruim, duplicado, contraditório).

A ideia de context poisoning é simples: o modelo não precisa ser hackeado. Portanto, basta alguém conseguir influenciar o contexto que ele consome: documentos, notas, tickets, páginas internas.

Resultado: respostas “certinhas” em cima de premissas erradas.

3) Stale data

Stale data é o risco menos glamouroso e, provavelmente, o mais frequente. Isso porque dados desatualizados geram decisões erradas com confiança: política antiga, preço antigo, contato antigo, SLA antigo, processo antigo.

Stale data não parece ataque, parece “só um bug”.

Até virar prejuízo: uma decisão errada automatizada, uma autorização fora da política, uma comunicação que já não vale mais.

O que isso muda na engenharia de software?

A engenharia sempre lidou com componentes incertos: rede, concorrência, sistemas distribuídos.

Mas LLMs introduzem um tipo diferente de incerteza.

Então isso muda a mentalidade de projeto:

• Antes, a gente protegia rotas. Agora, a gente protege intenções.
• Antes, a gente validava input. Agora, input + contexto + ação.
• Antes, falha era exceção. Agora, falha pode ser uma resposta coerente, porém completamente errada.

Ciclo de Vida de Desenvolvimento de Software Seguro continua essencial, mas não basta se não enxergar IA como um sistema sociotécnico: a sua aplicação não é “um chat”, é um operador com acesso a dados e ferramentas.

Mas qual é a zona de alcance do meu agente? O que acontece se ele errar no pior cenário?

O impacto humano: crise de confiança

O efeito colateral nas sociedade é uma crise de confiança.

Deepfakes em videochamada, clonagem de voz, phishing hiperpersonalizado: o golpe é cada vez mais convincente, tecnológico e rápido.

O caso da Arup, em que criminosos usaram deepfakes em videoconferência para induzir uma transferência milionária, é um exemplo de como “parecer real” virou vetor de ataque, não só prova de autenticidade.

Checklist prático (Definition of Done para sistemas de IA)

Se eu tivesse que transformar tudo isso em critérios práticos de engenharia, eu começaria com este checklist.

1. Escopo, permissões e ação

• Classifique o sistema: só responde? consulta (RAG)? executa (agente)?
• Permissão mínima real por ferramenta: tokens curtos, escopo mínimo, identidades segregadas.
• Gating por risco: ações sensíveis exigem confirmação, “dryrun” ou aprovação humana.
• Limites de Alcance: quantos emails, quanto dinheiro, quantos registros por execução.

2. Isolamento e execução segura

• Sandbox para ferramentas perigosas: rede restrita, egress em allowlist, rate limit, quotas de custo.
• Kill switch: capacidade de desligar ações em minutos e cair para modo somente leitura.

3. Proteção contra prompt injection e contexto malicioso

• Separar instruções do sistema de conteúdo não confiável (documentos, emails, páginas).
• Tratar contexto como supply chain: origem, autoria, versionamento, trilha e política de escrita.
• Regras imutáveis: documentos não podem reprogramar políticas ou pedir segredos (alinhado a OWASP LLM01).

4. Stale data e qualidade operacional

• Definir expiração(TTL) dos dados por tipo de informação e exibir timestamp + fonte nas respostas críticas.
• Se está fora do TTL: alertar, pedir confirmação ou buscar atualização.

5. Observabilidade, auditoria e testes adversariais

• Logs estruturados (com redaction): fontes RAG, decisões, tools chamadas, outputs.
• Detecção de anomalia: spikes de custo, tentativas de exfiltração, padrões de injection.
• Red teaming contínuo: testes com documentos, links e cenários de abuso realistas.

Possíveis futuros (e o que isso exige da engenharia)

Vejo pelo menos três movimentos acontecendo em paralelo:

• IA como infraestrutura crítica: Copilotos e agentes vão virar camada padrão de produtos. Segurança então deixa de ser adendo e passa a ser parte do design.
• Context engineering como firewall: O contexto passa a ser tratado como algo que precisa de governança, proveniência e validação — como hoje fazemos com dependências e pacotes.A discussão sobre context poisoning está acelerando justamente por isso.
• Era da verificação: Vamos depender mais de sinais verificáveis: assinaturas, trilhas de auditoria, confirmações explícitas. Não por paranoia, mas porque ficou barato demais falsificar.

Três perguntas para quem está indo para produção

Então esse paradoxo da IA é um lembrete de humildade pra engenharia: não existe sistema 100% seguro.

O que existe é sistema com falha segura, rastreabilidade e limites claros, mas assumindo que o mundo é hostil.

Na minha opinião, a gente ainda vai ver um super ataque envolvendo IA. Por excesso de permissão, falta de governança do contexto e automação sem freio.

Se você está colocando IA em produção, eu deixo três perguntas:

1. Você deu permissão mínima de verdade?
2. Você consegue explicar “por que” o sistema fez algo olhando para os logs?
3. Você consegue desligar ações em minutos e cair para modo somente leitura?

Se a resposta é “não” para alguma delas, fique atento. Porque a conta desse paradoxo da segurança em IA vai chegar.

Rafael Dourado é BR Operations Manager da Programmers. Sua principal atuação é garantir a satisfação de ponta a ponta dos clientes para abraçar essa revolução tecnológica. Com 15 anos de experiência atuando no universo de software e analytics, ele é apaixonado por IA por acreditar no seu poder transformador. Nos momentos de lazer, Rafael gosta de praticar xadrez com sua filha.