O problema não é simplesmente decidir se a equipe pode usar IA. É saber quais dados estão sendo enviados, para quais serviços e com que permissões — e, ao mesmo tempo, impedir que os próprios modelos e agentes se tornem uma nova porta de entrada. Para quem desenvolve software, isso muda decisões de arquitetura, revisão de código e gestão de credenciais.
Segundo o Sapo.pt, esse foi um dos temas do Security Day Portugal 2026, evento da Fortinet realizado na FIL. A discussão incluiu Shadow AI, automação de segurança e proteção dos sistemas de IA. Filippo Cassini, executivo da Fortinet, chamou atenção para outro problema conhecido por quem administra ambientes complexos: ferramentas que não compartilham informações nem coordenam respostas com eficiência.
Proteger com IA e proteger a IA são problemas diferentes
Usar IA para segurança pode significar analisar alertas, resumir incidentes, correlacionar eventos ou automatizar tarefas de resposta. Proteger a IA, por outro lado, envolve controlar o que entra no modelo, limitar o que ele pode fazer e verificar o que sai. São frentes relacionadas, mas não intercambiáveis.
Um assistente pode ajudar a classificar alertas e ainda assim expor dados internos se a equipe colar logs com tokens em um serviço público. Da mesma forma, um modelo hospedado dentro da rede pode estar vulnerável a injeção de prompt ou conectado a uma ferramenta com permissões excessivas. A localização do modelo, sozinha, não resolve o problema.
Shadow AI: quando a ferramenta chega antes da política
Shadow AI é o uso de serviços ou modelos de IA sem aprovação, inventário ou controles da organização. Às vezes começa com uma decisão banal: alguém cola um trecho de código em um chatbot para entender um erro. O risco cresce quando o trecho contém uma chave, dados de cliente, uma consulta SQL real ou detalhes de uma falha ainda não corrigida.
Bloquear todo acesso a ferramentas de IA pode parecer uma solução simples, mas costuma empurrar o uso para canais menos visíveis. Uma abordagem mais útil é oferecer alternativas aprovadas, explicar o que pode ser compartilhado e aplicar controles proporcionais ao risco. O objetivo é tornar o caminho seguro mais fácil do que contornar a política.
Por que integrar ferramentas de segurança importa
Uma organização pode ter proteção de endpoint, firewall, gestão de identidades, monitoramento de cloud e ferramentas de análise de código. Se cada sistema trabalha isolado, um alerta relevante pode ficar preso em um painel que ninguém consulta. A quantidade de produtos não garante uma resposta coordenada.
Para desenvolvedores, isso aparece como uma sequência de tarefas manuais: copiar um identificador de incidente para outro sistema, verificar permissões em um terceiro e abrir um chamado para revogar uma credencial. Essa demora importa quando um atacante automatiza reconhecimento, exploração e tentativas de acesso em alta velocidade.
Integração não significa conectar tudo sem critério. Significa definir quais eventos precisam circular, qual sistema é a fonte confiável de cada dado e que ações podem ser executadas automaticamente. Uma automação que revoga uma sessão suspeita pode ser adequada; uma que apaga recursos de produção com base em um alerta incerto precisa de validações adicionais.
A superfície de ataque inclui aplicações e agentes de IA
A expansão mencionada na cobertura do Sapo.pt não se limita a servidores locais e serviços em cloud. Aplicações SaaS, trabalhadores remotos e sistemas de tecnologia operacional (OT) também fazem parte do ambiente. Com IA, entram ainda APIs de modelos, bases vetoriais, plugins, agentes e integrações com ferramentas internas.
Um agente que consulta documentos e cria tickets tem mais risco do que um chatbot que apenas responde perguntas gerais. Se puder executar comandos, enviar mensagens ou alterar registros, precisa de uma identidade própria, permissões mínimas e limites explícitos. Tratar um agente como se fosse apenas uma interface de conversa é uma armadilha de arquitetura.
Controles técnicos para aplicações com modelos de linguagem
Na minha avaliação, um desenho seguro começa antes da escolha do modelo. Primeiro, defino quais dados a aplicação pode processar. Depois, decido quais provedores e destinos são aprovados, como os prompts e respostas serão registrados e quais ações o modelo poderá solicitar.
- Classifique os dados: diferencie conteúdo público, interno, confidencial e dados pessoais. Não dependa de avisos genéricos para impedir o envio de informação sensível.
- Reduza as permissões: use credenciais específicas para cada integração, com acesso apenas ao necessário.
- Trate a saída como entrada não confiável: valide respostas antes de usá-las em SQL, HTML, comandos ou chamadas de ferramentas.
- Separe instruções de dados: conteúdo recuperado de documentos não deve ganhar autoridade para alterar as regras do sistema.
- Registre o suficiente para investigar: mantenha metadados e identificadores de requisição, mas evite gravar segredos e prompts sensíveis sem justificativa.
Esses controles se relacionam com riscos conhecidos em aplicações de modelos de linguagem, como injeção de prompt, exposição de informações, uso inseguro de saídas e permissões excessivas em agentes. A mitigação não é um filtro mágico: depende de camadas, testes e limites no código que controla a aplicação.
Na Prática: bloqueando segredos antes de enviar um prompt
O exemplo abaixo mostra uma verificação local simples antes de encaminhar texto a um provedor. Ele procura padrões comuns de credenciais e bloqueia a requisição quando encontra uma correspondência. É um ponto de partida para ilustrar onde aplicar uma política, não um mecanismo completo de DLP: formatos variam, e regex não identifica todo dado confidencial.
import re
PATTERNS = {
"aws_access_key": re.compile(r"\bAKIA[0-9A-Z]{16}\b"),
"private_key": re.compile(
r"-----BEGIN (?:RSA |EC |OPENSSH )?PRIVATE KEY-----"
),
"generic_token": re.compile(
r"(?i)\b(?:api[_-]?key|access[_-]?token)\s*[:=]\s*['\"]?[A-Za-z0-9_\-]{16,}"
),
}
def inspect_prompt(text: str) -> list[str]:
"""Retorna os tipos de segredo detectados, sem devolver o valor."""
findings = [
name
for name, pattern in PATTERNS.items()
if pattern.search(text)
]
return findings
def prepare_for_model(text: str) -> str:
findings = inspect_prompt(text)
if findings:
raise ValueError(
"Envio bloqueado: possível dado sensível "
+ ", ".join(findings)
)
return text
if __name__ == "__main__":
prompt = "Investigue este erro. API_KEY=abc1234567890abcdef"
try:
print(prepare_for_model(prompt))
except ValueError as error:
print(error)Em produção, eu colocaria essa checagem em um gateway ou serviço compartilhado, para evitar que cada equipe implemente uma versão diferente. Também adicionaria testes para falsos positivos e negativos, regras específicas para os formatos usados pela empresa e um caminho claro para revisão humana. Se a aplicação aceitar anexos, eles precisam passar por controles próprios; verificar apenas o campo de texto não protege arquivos enviados.
- Inventarie os usos: identifique aplicações, provedores, modelos, dados processados e responsáveis.
- Defina destinos aprovados: documente quais serviços podem receber cada classificação de dado.
- Coloque controles no caminho da requisição: faça validação no backend ou gateway, não apenas no navegador.
- Limite as ferramentas do agente: exponha operações pequenas e específicas, em vez de credenciais amplas ou acesso genérico à rede.
- Teste abuso e falhas: simule prompt injection, indisponibilidade do modelo, respostas malformadas e tentativas de extrair dados.
- Revise incidentes e exceções: atualize políticas conforme surgem novos fluxos e necessidades reais.
Erros comuns ao adotar IA na segurança
- Confiar apenas em bloqueios de rede: usuários podem acessar ferramentas por outros dispositivos ou redes. Sem uma alternativa aprovada, o uso tende a ficar menos visível.
- Tratar o prompt do sistema como uma barreira de segurança: instruções ajudam a orientar o modelo, mas não substituem validação de permissões e controles no servidor.
- Dar ao agente acesso amplo “para facilitar”: uma integração com permissão de leitura e escrita em todo o ambiente amplia o impacto de uma falha ou manipulação.
- Enviar logs completos para análise: logs podem conter tokens, dados pessoais, endereços internos e conteúdo de clientes. Redija e minimize antes do envio.
- Automatizar ações irreversíveis sem confirmação: use níveis de confiança, limites de impacto e aprovação humana para operações destrutivas ou de alto risco.
- Confundir integração com segurança: conectar ferramentas não garante que os alertas sejam corretos, que as identidades estejam bem configuradas ou que uma resposta automática seja segura.
Como avaliar uma estratégia de proteção
Eu começaria medindo coisas verificáveis: quanto tempo leva para detectar e responder a um incidente, quantas aplicações de IA estão inventariadas, quais dados podem sair da organização e quantos agentes têm permissões além do necessário. Essas métricas ajudam mais do que contar modelos ou produtos implantados.
Também separaria os controles por camada. A rede e a identidade limitam acesso; o gateway aplica políticas de uso; a aplicação valida entradas, saídas e chamadas de ferramentas; e o monitoramento registra comportamentos relevantes. Nenhuma camada substitui as demais. Essa é a implicação prática do desafio discutido no Security Day Portugal: a resposta depende tanto de coordenação entre tecnologias quanto de decisões corretas dentro do software.
Perguntas frequentes
O que é Shadow AI?
É o uso de ferramentas ou modelos de IA sem aprovação, inventário ou controles formais da organização. Pode expor código, credenciais e dados internos quando usuários enviam conteúdo a serviços não autorizados.
É seguro usar IA para revisar código?
Depende do serviço, dos dados enviados e das condições de tratamento. Antes de compartilhar código, verifique a política do provedor, remova segredos e confirme se o repositório permite esse uso. Prefira ferramentas aprovadas pela organização.
Um modelo local elimina os riscos de segurança?
Não. Um modelo local pode reduzir a exposição a provedores externos, mas ainda está sujeito a prompt injection, vazamento por logs, permissões excessivas, falhas de aplicação e acesso indevido à infraestrutura.
Como proteger um agente de IA com acesso a ferramentas?
Use identidade própria, permissões mínimas, operações delimitadas e validação no servidor. Exija aprovação para ações de alto impacto e trate tanto as instruções do usuário quanto o conteúdo recuperado de documentos como dados não confiáveis.
Preciso bloquear todas as ferramentas públicas de IA?
Nem sempre. Uma política proporcional, acompanhada de ferramentas aprovadas e controles de dados, costuma ser mais sustentável do que um bloqueio sem alternativa. O essencial é saber quais serviços são usados e reduzir os riscos associados.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.