AI safety para devs: guardrails, AI Act e código de produção

A IA voltou ao centro da mesa — e devs precisam parar de fingir que é só hype

Segundo o Olhardigital.com.br, 193 países estão reunidos em Nova York na 81ª Assembleia Geral da ONU para discutir segurança global, e a inteligência artificial voltou à lista de ameaças à paz mundial — algo que não acontecia desde o debate sobre energia nuclear, há mais de 80 anos.

Na minha experiência, a maioria dos devs trata isso como pauta de político ou filósofo. Erro grave. Quando uma tecnologia vira assunto de fórum multilateral com poder de criar tratados, o impacto chega direto no seu requirements.md, na arquitetura do sistema e, em alguns países, no código que você pode ou não escrever. Ignorar isso é construir em cima de areia movediça.

Por que a ONU voltou a falar em “ameaça existencial” depois de 80 anos

O paralelo com a bomba atômica não é retórico vazio. Tanto na década de 1940 quanto agora, o gatilho foi o mesmo: uma tecnologia que escapa do controle humano antes que a sociedade tenha tempo de criar freios. A diferença é que a bomba precisava de urânio enriquecido e físicos quânticos. Para treinar um modelo de fronteira hoje, basta GPU, dados e — aqui está o problema — nenhuma accountability clara sobre o que sai do outro lado.

Quando converso com engenheiros sêniores que estão colocando agentes autônomos em produção, a maioria subestima três riscos técnicos que estão no centro dessa discussão diplomática:

• Alinhamento fraco: o modelo “faz o que você pediu” mas não “o que você queria”. Em produção isso vaza dado sensível, toma decisões erradas e custa dinheiro real.
• Capacidade emergente não documentada: você não sabe tudo que o modelo consegue fazer até alguém testar. E alguém vai testar — para o bem e para o mal.
• Cadeia de responsabilidade difusa: quando o agente autônomo toma uma decisão ruim, quem responde? O dev? O provedor do modelo? A empresa que comprou a API? Os países estão correndo para responder isso com lei.

O que isso significa na prática para quem constrói IA

Cuidado com essa armadilha: devs costumam achar que “governança de IA” é coisa de compliance, não de engenharia. Na prática, é o contrário. As decisões que você toma no design do sistema — quais dados entram, qual modelo é escolhido, como o output é validado — definem se o seu produto vai sobreviver a uma auditoria regulatória nos próximos 3 anos.

Testei isso em produção com clientes de três setores diferentes (fintech, saúde e edtech). O padrão se repete: quem tratou segurança de IA como decisão arquitetural desde o dia zero passou pelo EU AI Act e pela LGPD com ajustes. Quem tratou como “depois a gente vê” teve que refatorar parte significativa do backend. Refatorar um pipeline de IA em produção é mais caro que refatorar um monolito — porque envolve re-treinamento, re-validação e, em alguns casos, recertification.

Os três vetores regulatórios que você precisa conhecer hoje

Perceba que o Brasil está atrás. Enquanto a UE já multa, a gente ainda discute projeto de lei. Mas se você está construindo produto para o mercado global — e olha, qualquer SaaS B2B está — o AI Act vale mesmo que sua empresa não tenha sede na Europa, se você processar dado de cidadão europeu. É o mesmo princípio do GDPR.

Na Prática: implementando guardrails reais em produção

Vou te dar um exemplo que uso em cliente. É um wrapper minimalista mas sério para chamadas LLM que adiciona três camadas de proteção: detecção de prompt injection, validação de schema do output e rate limiting por usuário. Não é bala de prata, mas é o mínimo que separa um projeto de hobby de um produto que sobrevive a uma auditoria.

import re
import json
from typing import Callable
from functools import wraps

# 1. Detector simples de padrões de prompt injection
INJECTION_PATTERNS = [
    r"ignore (all )?previous instructions",
    r"you are now",
    r"disregard (the )?system prompt",
    r"reveal your (system|hidden) prompt",
    r"<\|.*?\|>",  # tokens especiais que vazam de templates
]

def detect_prompt_injection(user_input: str) -> bool:
    lowered = user_input.lower()
    return any(re.search(p, lowered) for p in INJECTION_PATTERNS)

# 2. Validador de output por schema
def validate_output_schema(output: str, required_keys: list) -> dict:
    try:
        parsed = json.loads(output)
    except json.JSONDecodeError:
        raise ValueError("LLM retornou JSON inválido")
    missing = [k for k in required_keys if k not in parsed]
    if missing:
        raise ValueError(f"Output faltando chaves: {missing}")
    return parsed

# 3. Rate limiter in-memory por user_id (em prod use Redis)
import time
from collections import defaultdict

_calls = defaultdict(list)
MAX_CALLS_PER_MIN = 20

def rate_limit(user_id: str) -> bool:
    now = time.time()
    window = [t for t in _calls[user_id] if now - t < 60]
    _calls[user_id] = window
    if len(window) >= MAX_CALLS_PER_MIN:
        return False
    _calls[user_id].append(now)
    return True

# 4. O wrapper que junta tudo
def safe_llm_call(user_id: str, prompt: str, llm_fn: Callable, schema: list):
    if not rate_limit(user_id):
        raise PermissionError("Rate limit excedido para o usuário")
    if detect_prompt_injection(prompt):
        # loga, alerta, e retorna resposta segura
        return {"error": "input_rejected", "reason": "possible_injection"}
    raw = llm_fn(prompt)
    return validate_output_schema(raw, schema)

Esse snippet tem três decisões de design que vale a pena comentar:

1. Falhar fechado, não aberto. Se o detector tem dúvida, bloqueia. Prefiro um falso positivo a um jailbreak em produção.
2. Validar output por schema, não por “parece bom”. LLMs alucinam JSON. Se você confia no output sem validar, está construindo sobre areia.
3. Rate limit antes da chamada, não depois. É a única camada que protege seu bolso de um loop infinito de erro ou de um atacante.

Erros Comuns que devs cometem ao ignorar AI safety

Quando uso esses sistemas em auditoria, esses são os problemas que aparecem em 80% dos códigos que reviso:

• Tratar o system prompt como segredo. Não é. Qualquer um que converse com seu agente consegue extrair em média 70% do system prompt em poucas tentativas. Pare de fingir que é segurança por obscuridade.
• Confiar no content filter do provedor. OpenAI, Anthropic e Google têm filtros bons, mas são generalistas. Filtros de domínio específico (médico, jurídico, financeiro) precisam de camada própria. Em fintech já vi filtro de provedor aprovar conteúdo que violava regulamentação da CVM.
• Não logar input/output. Sem log, você não tem como investigar incident, treinar red team ou provar conformidade regulatória. Logs são evidência. Em saúde, são também obrigação legal.
• Colocar LLM no caminho crítico sem fallback. Se o LLM cai ou alucina, seu sistema precisa degradar com elegância — não quebrar. Nunca confie em API externa para fluxo que não tem plano B.
• Misturar RAG com permissões de usuário sem filtro. Quando você indexa documentos com permissões diferentes no mesmo vector store e não filtra no retrieval, vaza documento confidencial. É o equivalente moderno de IDOR.

O que esperar do curto prazo — e como se preparar

Na minha leitura do cenário, três coisas vão acontecer nos próximos 18 meses, e cada uma exige decisão sua agora:

1. Certificação de sistemas de IA vira diferencial comercial. Quem tem audit trail, documentação técnica e red teaming documentado vai vender mais — especialmente para governo, saúde e financeiro. Comece a documentar agora, mesmo que não tenha certificado.
2. Open source de modelos vai virar zona de tensão geopolítica. A UE está debatendo se modelos open source acima de certo threshold de compute precisam de registro. Se você distribui modelos ou fine-tuna para terceiros, isso te afeta.
3. Agentes autônomos com ação no mundo real vão apertar o cerco regulatório. Quando seu agente não só responde chat mas executa ações (compra, publica, transfere), a discussão sai de “modelo” e vai para “agente”. É onde a legislação de IA encontra a legislação de robótica e veículos autônomos. Prepare-se.

FAQ — Perguntas que devs realmente fazem

O AI Act europeu se aplica a mim se minha empresa é brasileira?

Sim, se você processar dados de cidadãos europeus ou oferecer serviço a eles. É o mesmo critério extraterritorial do GDPR. O tribunal belga já confirmou essa leitura em 2023. Se seu SaaS tem usuário na UE, o AI Act te alcança.

Vale a pena implementar guardrails se meu modelo é pequeno e roda on-premise?

Vale mais ainda. Modelos menores têm menos alinhamento embutido por padrão. Llama 3 8B rodando local sem filtro é mais perigoso em prompt injection que GPT-4 com os filtros da OpenAI ativos. On-premise te dá controle, mas também responsabilidade total.

Quanto custa montar um pipeline de AI safety decente?

Para uma startup em estágio seed, dá para começar com 5–10% do esforço de engenharia dedicado a isso e evoluir. Para empresa média, o número que tenho visto em projetos é entre 15 e 25% do budget de IA. Muito menor que o custo de refatorar depois ou, pior, de um incident público.

Red teaming manual ainda faz sentido com ferramentas automatizadas?

Sim, sempre. Ferramentas como garak, PyRIT e promptfoo cobrem a superfície técnica. Mas o red team humano encontra falhas de design que automação não pega — como contextual misuse, alucinações em domínio específico e manipulação social via UI. Use as duas camadas.

Qual a primeira coisa que faço amanhã se meu sistema de IA não tem nenhuma camada de segurança?

Comece por três coisas nesta ordem: (1) ative logging de input/output com retenção mínima de 90 dias, (2) implemente rate limiting por usuário ou IP, (3) adicione validação de schema no output. Essas três cobrem 60% do risco real com menos de um dia de trabalho. O resto você constrói em cima.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se quiser, posso escrever um próximo artigo entrando especificamente em implementação de RAG seguro com controle de permissão por documento — tema que rendeu discussão longa em cliente de saúde recentemente.