Agente de IA com arquitetura para reduzir risco LGPD.

Toda média empresa LATAM hoje vive a mesma cena: a diretoria quer IA, o jurídico trava em LGPD, e o projeto morre antes de virar piloto.

A boa notícia: dá pra estruturar IA enterprise com governança — com agente em produção, em dado real, em operação crítica — reduzindo muito a exposição regulatória. A má notícia: muitos vendedores de IA não constroem assim.

Este artigo mostra a arquitetura padrão que a Odyssey aplica em todo projeto de IA no atendimento. Não é teoria. É o que está em produção em clientes com dado sensível (jurídico, saúde, financeiro).

As 7 camadas de um agente IA enterprise com governança

Camada 1 · Modelo enterprise (não modelo público)

Primeira decisão técnica. Você precisa de um modelo que não treine sobre o seu dado. Modelos enterprise dos grandes (OpenAI Enterprise, Azure OpenAI, Anthropic Claude for Enterprise, AWS Bedrock) têm cláusula contratual explícita de não-retenção e não-treinamento.

ChatGPT consumer? Não. API direta sem tier enterprise? Risco. Self-hosted (Llama, Mistral)? Excelente para dado ultra-sensível mas dobra a complexidade operacional.

Camada 2 · Data residency e isolamento

Para clientes brasileiros sensíveis, o dado precisa permanecer em região controlada — Azure São Paulo, AWS São Paulo, GCP São Paulo. Para clientes LATAM, pode ser regional. Nunca compartilhe ambiente entre clientes. Tenancy isolada é não-negociável.

Camada 3 · RAG privado (Retrieval-Augmented Generation)

Aqui está a virada técnica: o modelo de linguagem genérico vira útil quando você dá contexto privado relevante. RAG significa que toda pergunta primeiro busca em uma base de conhecimento privada, e só os trechos relevantes vão para o LLM.

Isso muda tudo:

• O modelo nunca "alucina" sobre dado do cliente — ele só responde com base no que recebeu
• Você controla exatamente que dado o agente acessa
• Auditoria é simples: cada resposta tem trail explícito de fontes

"Sem RAG, o agente de IA é um chute educado. Com RAG bem feito, é um analista júnior que cita as fontes."

Camada 4 · Regras e revisão operacionais

Regras e revisão são limites explícitos que definem o que o agente pode ou não fazer. Em produção:

• Regras de tema: o agente recusa responder sobre temas fora do escopo (ex: agente jurídico não opina sobre política)
• Regras de dado pessoal: dados pessoais identificados são mascarados antes de qualquer registro ou retorno externo
• Regras de ação: ações irreversíveis (deletar, enviar, aprovar) sempre exigem confirmação humana
• Regras de resposta: respostas passam por validador antes de chegar ao usuário (formato, tom, conteúdo proibido)

Camada 5 · Citação obrigatória

Toda resposta do agente precisa ter citação verificável da fonte. Não é "achei isso aqui", é "isso está no documento X, página 12, atualizado em data Y".

Sem citação:

• Não há como auditar
• Não há como o usuário verificar
• Não há defesa em caso de erro

Implementação técnica: retornar metadados de cada chunk retrievado, renderizar como link ou referência clicável na UI.

Camada 6 · Registro auditável

Cada interação precisa gerar registro completo: quem perguntou, o que perguntou, quais documentos foram consultados, o que o agente respondeu, se a resposta foi aprovada ou corrigida.

Para LGPD, esse registro precisa ter:

• Retenção definida (ex: 90 dias) e descarte automático após
• Anonimização de PII no registro de longo prazo
• Acesso restrito (não todo mundo da empresa pode ver)
• Exportabilidade para responder a direito de titular (LGPD Art. 18)

Camada 7 · Revisão humana obrigatória em decisão crítica

Última camada e mais importante: nenhuma decisão crítica passa sem humano. Crítica = irreversível, regulatória, financeira acima de threshold, jurídica, médica.

Padrão técnico: workflow de aprovação. O agente sugere, o humano aprova/edita/rejeita. Decisão final é humana. Agente acelera, não substitui.

O que o DPO vai te perguntar (e como responder)

"Onde meu dado está hospedado?"

Resposta: nome do provedor + região específica + contrato DPA disponível para inspeção.

"O modelo treina com meu dado?"

Resposta: não. Cláusula contratual explícita de não-treinamento e não-retenção do provedor enterprise.

"Quem pode acessar o agente?"

Resposta: lista nominal de usuários autorizados + RBAC (role-based access control) + registro de acessos disponível.

"E se um usuário pedir direito de exclusão (LGPD Art. 18)?"

Resposta: workflow de identificação → exclusão da base RAG → anonimização do registro → confirmação ao titular. Documentado em playbook interno.

"E se a IA responder algo errado e gerar dano?"

Resposta: revisão humana obrigatória em decisão crítica + registro completo de cada interação + processo de incident response definido.

3 anti-padrões que matam projetos de IA enterprise

1. "Vamos começar com ChatGPT mesmo, depois a gente vê." ChatGPT consumer + dado de cliente aumenta muito a exposição e o risco de vazamento. Comece certo ou não comece.
2. "O agente decide e a gente confia." Sem revisão humana em decisão crítica, qualquer erro vira ação irreversível. E vai ter erro.
3. "O registro ocupa muito espaço, vamos pular." Sem registro, você não tem como auditar, não tem como melhorar e não tem como se defender. Registro não é opcional.

Como saber se sua arquitetura está pronta para produção

Checklist mínimo antes de qualquer agente entrar em produção real:

• Contrato + DPA assinado com provedor de LLM
• Tenancy isolada e data residency confirmada
• RAG privado funcionando, com fontes versionadas
• Pelo menos 3 regras ativas (tema, dado pessoal, ação)
• Citação obrigatória renderizada na UI
• Registro completo por 90 dias, descarte automático após
• Workflow de revisão humana em decisão crítica
• Documento de incident response definido
• DPO interno informado e alinhado
• Piloto com 5-10 usuários antes de rollout amplo