Quando uma empresa decide implementar IA, existe um momento em que alguém inevitavelmente pergunta: “Mas os dados da nossa empresa vão para onde? Quem tem acesso? Isso é seguro?”
São as perguntas certas. E elas merecem respostas detalhadas, não tranquilizações genéricas.
Projetos de IA corporativa envolvem dados sensíveis: informações de clientes, dados financeiros, contratos, propriedade intelectual, dados de colaboradores. Como esses dados são tratados — onde ficam, quem pode acessar, como são processados — tem implicações legais, regulatórias e competitivas significativas.
Este artigo apresenta o que você precisa verificar e garantir antes de colocar dados corporativos em qualquer sistema de IA.
As três categorias de risco
Risco 1: Dados enviados a provedores de LLM externos
Quando você usa a API da OpenAI, Anthropic, Google ou qualquer outro provedor externo, os dados que você envia no prompt saem da sua infraestrutura e vão para os servidores desses provedores.
A pergunta crítica: Esses dados são usados para treinar modelos futuros?
A resposta depende do contrato e do plano que você usa:
- OpenAI API (plano padrão): Por padrão, dados enviados via API não são usados para treinamento. Mas isso muda dependendo dos termos que você aceitou.
- OpenAI Enterprise / Azure OpenAI: Garantia contratual de que os dados não são usados para treinamento.
- Anthropic Claude API: Política padrão é não usar dados de API para treinamento, com opções enterprise para garantias adicionais.
- Google Vertex AI: Oferece garantias enterprise com residência de dados configurável.
O que fazer: Antes de assinar qualquer coisa, revise os termos de serviço de dados com alguém da sua equipe jurídica. Para dados sensíveis, exija um Data Processing Agreement (DPA) que deixe claro como os dados são tratados.
Risco 2: Dados armazenados em infraestrutura de terceiros
Vector databases, sistemas de memória de agentes, logs de conversas — esses dados ficam onde?
Se você usa serviços gerenciados (Pinecone, Weaviate Cloud, etc.), os dados ficam nos servidores desses provedores. Para dados não-sensíveis, isso geralmente é aceitável. Para dados altamente sensíveis, pode não ser.
O que verificar:
- Onde fisicamente os dados são armazenados? (País importa para LGPD e regulações setoriais)
- Criptografia em repouso e em trânsito está ativa?
- Quem do provedor pode acessar seus dados?
- Qual é a política de retenção de dados?
- O que acontece com seus dados se você cancelar o serviço?
Risco 3: Acesso não autorizado dentro da empresa
Sistemas de IA frequentemente têm acesso amplo a dados da empresa para funcionar bem. Um agente que precisa acessar contratos, CRM, e e-mail tem acesso a uma quantidade imensa de informação.
O risco: Se qualquer funcionário pode usar o sistema sem restrições, e o sistema tem acesso a tudo, então qualquer funcionário tem acesso a tudo — incluindo informações que normalmente estariam restritas ao nível de permissão deles.
Framework de segurança para projetos de IA
Camada 1: Classificação de dados
Antes de qualquer implementação técnica, classifique os dados que o sistema vai processar:
| Nível | Descrição | Exemplos |
|---|---|---|
| Público | Pode ser conhecido externamente | Site, catálogo de produtos, press releases |
| Interno | Apenas colaboradores | Procedimentos internos, comunicados gerais |
| Confidencial | Acesso restrito por função | Dados de clientes, contratos, financeiros |
| Altamente sigiloso | Acesso mínimo, controlado | Segredos comerciais, dados M&A, dados pessoais sensíveis |
Para cada nível, defina: qual infraestrutura pode processar esses dados? Quais provedores externos são aceitáveis? Qual nível de monitoramento é necessário?
Camada 2: Princípio do menor privilégio
O sistema de IA deve ter acesso apenas ao que precisa para executar as tarefas definidas. Não mais.
Na prática:
- Crie usuários de serviço com permissões mínimas para os sistemas que a IA acessa
- Segmente o acesso por caso de uso (o agente de RH não precisa acessar dados financeiros)
- Revise e audite permissões periodicamente
Agentes de IA com acesso irrestrito são um risco de segurança — não porque o modelo é malicioso, mas porque erros e comportamentos inesperados podem ter consequências maiores com mais acesso.
Camada 3: Auditoria e observabilidade
Toda ação do sistema deve ser registrada:
O que logar:
- Qual usuário iniciou a sessão
- Quais documentos ou registros foram acessados
- Quais ações foram executadas (em sistemas externos)
- O conteúdo dos prompts e respostas (para sistemas com dados confidenciais)
- Erros e comportamentos inesperados
Por quanto tempo manter: Depende da regulação do seu setor. Para dados financeiros e de saúde, regulações brasileiras (e setoriais) podem exigir retenção por anos.
Quem pode acessar os logs: Defina explicitamente. Logs de conversas podem conter dados sensíveis — não deixe acessível para qualquer pessoa.
Camada 4: Controles de saída (guardrails)
Implemente controles que limitam o que o sistema pode fazer:
Controles de ação:
- Lista de ações que o agente pode executar autonomamente
- Lista de ações que requerem aprovação humana
- Limite de valores financeiros para operações automáticas
- Proibição de deletar ou modificar dados sem confirmação
Controles de conteúdo:
- O sistema não deve repetir dados sensíveis desnecessariamente nas respostas
- O sistema não deve tentar acessar sistemas para os quais não tem autorização
- O sistema deve recusar solicitações que violam políticas de segurança
Camada 5: Autenticação e controle de acesso
O sistema de IA deve ter autenticação tão rigorosa quanto qualquer outro sistema crítico:
- Autenticação integrada com o diretório corporativo (Active Directory, Okta, etc.)
- MFA para acesso a sistemas com dados confidenciais
- Sessões com timeout adequado
- Controle de acesso baseado em função (RBAC) — o que cada função pode fazer e ver no sistema
LGPD e IA: o que você precisa saber
A Lei Geral de Proteção de Dados (LGPD) se aplica a qualquer processamento de dados pessoais de brasileiros — e sistemas de IA corporativa frequentemente processam dados pessoais: dados de clientes, dados de colaboradores, dados de leads.
Pontos de atenção específicos para IA:
Base legal para processamento: Você precisa de uma base legal para processar dados pessoais em sistemas de IA. Consentimento, legítimo interesse, ou execução de contrato são as bases mais comuns. Documente qual base legal você usa para cada tipo de processamento.
Decisões automatizadas: O artigo 20 da LGPD garante ao titular o direito de revisão de decisões automatizadas que afetem seus interesses. Se seu sistema de IA toma decisões que impactam pessoas (aprovação de crédito, seleção de candidatos), você deve ter um processo de revisão humana disponível.
Transferência internacional de dados: Quando você usa APIs de provedores americanos ou europeus, há transferência internacional de dados. A LGPD tem requisitos específicos para isso — verifique se o provedor oferece cláusulas contratuais adequadas.
Resposta a direitos dos titulares: Quando um cliente solicita exclusão dos seus dados, isso inclui os dados que estão no vector database, nos logs do sistema de IA, e em qualquer outro armazenamento associado ao sistema.
Considerando modelos on-premise para dados ultra-sensíveis
Para dados onde nenhuma opção de nuvem é aceitável (dados de saúde, dados bancários, segredos comerciais críticos), modelos de linguagem open-source rodando na sua própria infraestrutura são uma alternativa válida.
Modelos adequados para on-premise:
- Llama 3 70B (Meta) — excelente qualidade, pode ser rodado em servidores com GPUs
- Mistral Large — boa performance para tarefas em português
- Qwen 72B — boa performance multilingual
O que isso significa na prática:
- Os dados nunca saem da sua infraestrutura
- Você controla completamente o ambiente
- Custo de API zero (mas custo de infraestrutura GPU significativo)
- Responsabilidade de manutenção e atualização do modelo
Trade-off: Modelos on-premise de qualidade similar ao GPT-4o requerem hardware significativo (múltiplas GPUs de alta memória) e conhecimento técnico para operar. Para a maioria das empresas, os provedores cloud com garantias enterprise são mais práticos.
Checklist de segurança antes de ir para produção
Antes de lançar qualquer sistema de IA com dados corporativos, verifique:
Contratos e compliance:
- DPA assinado com todos os provedores externos que processam seus dados
- Termos de uso revisados pela equipe jurídica
- Base legal para processamento de dados pessoais documentada
- Processo de resposta a direitos de titulares definido
Controle de acesso:
- Autenticação corporativa integrada
- Permissões seguindo princípio do menor privilégio
- RBAC configurado por função
- Revisão de permissões agendada (mínimo semestral)
Auditoria:
- Todos os acessos e ações logados
- Retenção de logs definida e configurada
- Processo de revisão de logs definido
- Alertas para comportamentos anômalos configurados
Guardrails:
- Lista de ações permitidas e proibidas documentada e implementada
- Aprovações humanas configuradas para ações críticas
- Testes de tentativas de injeção de prompt realizados
Resposta a incidentes:
- Plano de resposta a incidente de segurança que inclui o sistema de IA
- Processo de notificação em caso de vazamento de dados definido
- Responsável por segurança do sistema identificado
Segurança não é um obstáculo para implementar IA — é o que permite implementar IA com confiança. Projetos construídos sobre bases sólidas de segurança escalam sem surpresas desagradáveis.
Se você está planejando um projeto de IA e quer revisar a arquitetura de segurança, fale com a gente. Trabalhamos com empresas em setores regulados e entendemos as exigências de compliance do mercado brasileiro.
Segurança em IA não é diferente de segurança em qualquer sistema crítico: princípio do menor privilégio, auditoria completa, controles de acesso rigorosos, e plano de resposta a incidentes. A diferença é que sistemas de IA têm acesso amplo por natureza — o que torna esses controles ainda mais importantes.