Gateway de IA: DLP e controle de saída de dados

*Artigo da nossa série de engenharia sobre IA corporativa, integração com sistemas legados e governança de informação.*

Onde vai parar o que seus funcionários escrevem na IA

Todo executivo já se fez essa pergunta em algum momento de desconforto: um analista cola um trecho de contrato num chatbot público para "resumir rapidinho", um vendedor pede ajuda para responder um cliente colando o histórico inteiro de e-mails, um desenvolvedor manda um pedaço de código com uma chave de API embutida. Nada disso passa por aprovação, nada disso fica registrado, e nada disso é reversível depois que o texto sai da rede da empresa.

A resposta de engenharia para esse problema não é uma política de uso aceitável impressa e assinada — é um ponto único de saída. Um gateway de IA é a peça que intercepta toda chamada a modelos de linguagem, aplica identidade, redação de dados sensíveis, limites de custo e log antes que qualquer coisa saia da rede corporativa. Sem esse componente, "governança de IA" é uma frase em um documento; com ele, é uma propriedade verificável do sistema.

Por que não basta bloquear domínios no proxy

A tentação inicial é resolver isso no firewall: bloquear chatgpt.com, gemini.google.com e afins na saída de internet. Isso não funciona por três motivos. Primeiro, a lista de serviços de IA cresce mais rápido do que qualquer lista de bloqueio consegue acompanhar. Segundo, times legítimos precisam de acesso a modelos para automações internas — bloquear tudo paralisa o negócio. Terceiro, e mais importante: bloqueio de rede não decide nada sobre o conteúdo da requisição. Ele impede o destino errado, mas não trata o problema real, que é dado sensível saindo de qualquer forma.

O gateway resolve isso invertendo a lógica: em vez de proibir destinos, a empresa oferece um único caminho aprovado, com controles embutidos, e torna esse caminho mais fácil de usar do que qualquer alternativa. Shadow AI se combate com conveniência, não só com regra.

Anatomia do gateway

Aplicação/Usuário
      |
      v
[ Gateway de IA ]
   |  |  |  |
   |  |  |  +--> Log e retenção (auditoria)
   |  |  +-----> Rate limit / cota de custo por time
   |  +--------> DLP (requisição e resposta)
   +-----------> Roteamento por caso de uso / modelo
      |
      v
Provedores de modelo (interno, OpenAI, Anthropic, Azure, etc.)

O gateway fica no caminho de toda chamada, seja ela feita por um chatbot interno, uma automação de RPA ou uma extensão de IDE. Nenhum sistema chama um provedor de modelo diretamente — todos chamam o gateway, e o gateway decide o resto.

Autenticação e propagação de identidade

Cada requisição chega ao gateway com um token de identidade do usuário ou serviço chamador — normalmente um JWT emitido pelo provedor de identidade corporativo (Azure AD, Okta). O gateway valida esse token, extrai claims relevantes (time, cargo, nível de acesso a dados) e propaga essa identidade adiante, tanto para decisões de política quanto para o log de auditoria. Isso é o que permite responder, com evidência, à pergunta "quem pediu isso e com que perfil de acesso".

{
  "sub": "user:ana.silva",
  "team": "financeiro",
  "data_clearance": "confidencial",
  "cost_center": "CC-4021"
}

Sem propagação de identidade, todo log de gateway vira uma lista de chamadas anônimas — auditável em volume, inútil em responsabilização individual.

Roteamento por caso de uso e por modelo

Nem toda requisição deve ir para o mesmo modelo. Um resumo de documento interno pode ir para um modelo mais barato; uma análise jurídica sensível pode exigir um modelo hospedado em ambiente que não retém dados para treinamento; um caso de uso classificado como alto risco pode exigir aprovação humana antes de sair.

O roteamento é configuração, não código espalhado pelas aplicações. Isso permite trocar de provedor, ajustar política de risco ou reagir a um incidente de segurança em um único lugar.

DLP e redação na requisição e na resposta

Este é o núcleo do controle de saída. O gateway aplica dois pontos de inspeção:

1. 1.Na requisição (antes de sair para o provedor): detecta e redige padrões sensíveis — CPF, número de cartão, chaves de API, e-mails de clientes, termos de um dicionário de dados confidenciais do negócio (nomes de projetos M&A, números de contrato). Dados redigidos podem ser substituídos por tokens reversíveis apenas dentro do perímetro da empresa.
2. 2.Na resposta (antes de devolver ao usuário): verifica se o modelo "vazou" algo que não deveria — por exemplo, repetindo de volta um dado sensível que estava no contexto, ou gerando conteúdo que corresponde a padrões proibidos (código malicioso, dados de outro cliente por contaminação de contexto).

def process_request(payload, policy):
    redacted, matches = dlp.redact(payload.text, policy.patterns)
    if matches and policy.action == "block":
        raise BlockedRequest(matches)
    response = model_provider.call(redacted)
    return dlp.redact(response.text, policy.patterns)

A redação bidirecional é o que diferencia um gateway de segurança de um simples proxy de custo. Sem ela, o problema original — dado sensível saindo da empresa — continua existindo, só que agora passa por um lugar bonito e logado.

Limites de taxa e de custo por time

Cada time ou aplicação recebe uma cota de requisições e de gasto em tokens. Isso evita dois problemas distintos: um bug em loop que gera milhares de chamadas em minutos, e um time que consome o orçamento de IA do trimestre inteiro em uma semana sem ninguém perceber. O gateway expõe esse consumo em tempo real, por centro de custo, o que também resolve a dor de FinOps de "quem está gastando o quê" sem depender de fatura mensal do provedor.

Bloqueio de shadow AI

Na borda de rede, o gateway pode ser combinado com uma política que nega, por padrão, qualquer tráfego de saída para domínios de IA que não sejam o gateway. Ferramentas de proxy corporativo (CASB) ajudam a identificar tentativas de uso de serviços não aprovados, mas o efeito prático só se sustenta se o caminho aprovado for rápido e não burocrático — se pedir acesso ao gateway demora semanas, o funcionário volta a usar o navegador pessoal.

Logging e retenção

Todo evento — requisição, resposta, decisão de DLP, identidade do chamador, modelo usado, custo — é logado de forma estruturada e retido conforme a política de dados da empresa (tipicamente 1 a 7 anos, dependendo do setor regulatório). Esse log é o que transforma "confiamos que ninguém vazou dado" em "temos evidência do que saiu, quando e para onde".

O que fazer na segunda-feira

1. 1.Levante quantos pontos de acesso a modelos de IA existem hoje na empresa — chatbots, extensões de IDE, automações, integrações diretas via API — e liste quantos passam por um controle central.
2. 2.Escolha um gateway de IA (comercial ou open source como LiteLLM, Portkey, ou uma camada própria) e coloque pelo menos um caso de uso de alto risco atrás dele esta semana.
3. 3.Defina, com segurança da informação, os três a cinco padrões de dado mais críticos para redação (CPF, cartão, chaves de API, nomes de clientes) e implemente a regra de DLP na requisição antes de tratar a resposta.
4. 4.Configure alertas de custo por time com limite diário, não apenas mensal — o dano de um loop descontrolado se mede em horas.
5. 5.Publique o caminho aprovado de forma visível e rápida de usar, para que a alternativa mais fácil seja a controlada, não a shadow.

Leitura complementar

Trilha executiva:

• Onde vai parar o que seus funcionários escrevem na IA — a leitura de negócio deste mesmo tema.