Contrato de operador IA: O que falta no seu contrato
Por que contratos padrão não cobrem infraestrutura de IA empresarial. Com checklist de requisitos para RH e compliance.
Um contrato de operador de dados para infraestrutura de IA deve cobrir dez áreas que contratos SaaS padrão não regulam: políticas de registro de prompts, separação de ambientes (dev/staging/prod), cadeias de provedores de modelos, processamento in-flight vs. at-rest, proteção de dados de embeddings RAG, acesso de terceiros países a dados de produção, conformidade com sigilo profissional, tokenização PII, trilhas de auditoria do Decision Layer e verificabilidade de medidas técnicas.
Por que os contratos padrão de operador de dados não cobrem a infraestrutura de IA
Um contrato padrão de operador de dados regula como um prestador de serviços trata dados pessoais em nome do controlador. Define a finalidade, as categorias de dados, as medidas técnicas e organizacionais, os sub-operadores e os prazos de retenção. Para um sistema CRM ou um software de RH, isso é suficiente.
A infraestrutura de IA empresarial cria situações que nenhum contrato padrão prevê. Um modelo de linguagem processa prompts - entradas de texto livre que podem conter qualquer coisa: dados de pessoal, informações de clientes, segredos comerciais, até categorias especiais de dados sensíveis quando um colaborador faz uma pergunta relacionada à saúde. Os dados fluem através de uma cadeia de sistemas: do frontend, passando por uma camada de orquestração, até o provedor do modelo, de volta a um banco de dados, possivelmente através de um pipeline RAG com vetores de embedding. Em cada ponto surgem questões diferentes sobre armazenamento, acesso e exclusão.
Quando você solicita ao seu provedor de IA o contrato de operador de dados e recebe um documento padrão, isso deve acender um alerta. Não porque o provedor não seja confiável, mas porque os riscos específicos da infraestrutura IA exigem disposições diferentes de uma aplicação SaaS convencional.
Dez lacunas entre o contrato padrão e a realidade da IA
1. Conteúdo de prompts como nova categoria de dados
Contratos padrão listam categorias de dados: nome, email, número do colaborador. Com agentes de IA surge uma categoria que não pode ser predefinida - o prompt. Um prompt pode ser uma pergunta inofensiva sobre política de férias ou uma carta completa de cliente com dados pessoais. O contrato deve estabelecer que a responsabilidade pela classificação do conteúdo recai sobre a organização, não sobre o provedor de IA, enquanto o provedor deve demonstrar medidas técnicas que protejam todo o conteúdo inserido independentemente da sua sensibilidade.
2. Política de registro: O que pode aparecer nos logs?
Com software convencional, registra-se o tecnicamente necessário. Com infraestrutura de IA, o registro adquire outra dimensão: Os conteúdos dos prompts são registrados? As respostas do modelo são armazenadas? Os documentos carregados aparecem em logs de erros?
Um contrato robusto para infraestrutura de IA deve estabelecer explicitamente que no ambiente de produção o registro de corpos de requisição/resposta está desativado, que apenas metadados técnicos são registrados (códigos de status, latências, IDs de requisição), que o registro de depuração em produção está desativado e que rastreamentos de pilha não contêm conteúdo de prompts nem documentos.
3. Separação de ambientes: Dev, Staging, Produção
Todo ambiente enterprise possui ambientes de desenvolvimento, testes e produção. Com infraestrutura de IA, a separação é crítica para a segurança porque dados reais podem ser utilizados como dados de teste durante o desenvolvimento. Um contrato específico para IA deve estabelecer que dev e staging utilizam exclusivamente dados sintéticos ou anonimizados, que o acesso à produção está restrito a funções definidas e que os casos de suporte são tratados apenas com dados de teste aprovados pela organização.
4. Cadeia de provedores de modelos em vez de sub-operadores clássicos
Com software convencional, um provedor tem sub-operadores: um provedor de hosting, talvez um serviço de email. Com infraestrutura de IA surge uma cadeia de três níveis: o provedor de infraestrutura de IA opera a plataforma, os provedores de modelos (Azure OpenAI, Google Vertex AI, Anthropic) processam os prompts e os provedores de plataforma (Supabase, Vercel) hospedam banco de dados e frontend.
O ponto crítico: Quem é o parceiro contratual dos provedores de modelos? Os modelos operam no tenant do provedor de IA ou no tenant da organização? Essa distinção determina se o provedor do modelo é sub-operador do provedor ou se a organização gerencia diretamente os relacionamentos com fornecedores.
| Componente | No tenant do cliente | No tenant do provedor |
|---|---|---|
| Azure Entra ID (SSO) | ✓ Cliente | - |
| Azure OpenAI / Vertex AI | ✓ Cliente | - |
| Supabase (Banco de dados) | ✓ Cliente | - |
| Vercel (Hosting) | ✓ Cliente | - |
| Plane (Sistema de tickets) | - | ✓ Provedor |
| GitHub (Hosting de código) | - | ✓ Provedor |
| Google Workspace (Comunicação) | - | ✓ Provedor |
Componentes no tenant do cliente são gerenciados pelo cliente em seu próprio registro de fornecedores. Componentes no tenant do provedor estão sujeitos à lista de sub-operadores no contrato.
5. In-flight vs. at-rest: Onde os dados permanecem?
Com software convencional, a pergunta é simples: os dados residem em um banco de dados. Com infraestrutura de IA existem dois modos de processamento. Processamento in-flight: o prompt é enviado ao provedor do modelo, processado e a resposta retornada - sem armazenamento persistente no provedor. Armazenamento at-rest: chats, uploads e embeddings são armazenados em um banco de dados - de forma persistente e associada ao usuário.
O contrato deve estabelecer disposições separadas para ambos os modos.
6. RAG e embeddings: Dados vetoriais como novo desafio
RAG (Retrieval Augmented Generation) torna documentos empresariais pesquisáveis por IA. Os documentos são convertidos em vetores de embedding e armazenados em um banco de dados vetorial. Esses vetores são uma nova categoria de dados: não contêm texto legível, mas em determinadas circunstâncias podem permitir inferências sobre o conteúdo original. O contrato deve tratar embeddings como dados pessoais quando gerados a partir de documentos com dados pessoais.
7. Acesso de terceiros países a dados de produção
Muitos provedores de IA trabalham com equipes distribuídas. Quando um desenvolvedor de um terceiro país tem acesso ao ambiente de produção, isso constitui uma transferência internacional de dados. O contrato deve definir que o acesso à produção está restrito a jurisdições adequadas, que o acesso a dev/staging de terceiros países é admissível (porque contêm apenas dados sintéticos), que RBAC prevê grupos de administradores separados para produção e dev/staging e que existe um procedimento de exceção que requer autorização escrita do controlador.
Para organizações brasileiras, a conformidade com a LGPD exige atenção especial à transferência internacional de dados (Arts. 33-36) e ao papel do Encarregado de Proteção de Dados (DPO) na supervisão do tratamento por agentes de IA.
8. Sigilo profissional na plataforma de IA
Para setores regulados - escritórios de advocacia, consultorias tributárias, auditorias, organizações de saúde e empresas com processos sujeitos a sigilo profissional - o processamento em plataformas de IA requer disposições contratuais explícitas. A legislação brasileira prevê a proteção do sigilo profissional conforme legislação setorial brasileira. O provedor deve comprometer todas as pessoas com acesso mediante declarações escritas de confidencialidade. Cláusulas padrão de confidencialidade não são suficientes.
9. Tokenização PII como módulo opcional
Filtros de entrada e saída que detectam dados pessoais e os pseudonimizam antes de enviar ao provedor do modelo adicionam uma camada adicional de proteção. A tokenização PII não é necessária em todo ambiente, mas o contrato deve contemplá-la como módulo opcional. Importante: se a re-identificação reversível for possível, o contrato deve regular quem tem acesso à tabela de mapeamento, como as chaves de mapeamento são armazenadas e criptografadas e que a re-identificação ocorre apenas com finalidade definida após autorização documentada.
10. Trilha de auditoria e Decision Layer
Agentes de IA tomam ou preparam decisões. Cada uma dessas decisões deve ser rastreável - não apenas para proteção de dados, mas também para auditoria interna, auditores externos e compliance. O Decision Layer decompõe cada processo em etapas de decisão individuais e define para cada etapa: humano, motor de regras ou IA. O contrato deve ancorar a trilha de auditoria como componente contratual: Quais dados são registrados por decisão? Por quanto tempo são retidos? Quem tem acesso?
O checklist: 25 perguntas para seu provedor de IA
O checklist a seguir traduz as dez lacunas em perguntas de verificação concretas.
Checklist de requisitos: 25 perguntas de verificação para contratos IA →
A - Categorias de dados e finalidades de tratamento
- Os conteúdos de prompts e respostas do modelo estão listados como categorias de dados independentes no contrato?
- Está estabelecido que a responsabilidade pela classificação do conteúdo recai sobre a organização, não sobre o provedor?
- Os embeddings/vetores estão classificados como dados potencialmente pessoais?
- O contrato contempla categorias especiais de dados sensíveis que podem surgir por entradas de usuários?
B - Registro e monitoramento
- O registro de corpos de requisição/resposta no ambiente de produção está desativado?
- Quais metadados são registrados (códigos de status, latências, IDs de requisição)?
- O registro de depuração em produção está verificavelmente desativado?
- Os rastreamentos de pilha e mensagens de erro estão configurados para excluir dados de conteúdo dos logs?
- A verificação das configurações de registro é parte do processo de lançamento?
C - Separação de ambientes e acesso
- Existem ambientes separados (dev, staging, produção) com políticas de dados distintas?
- Os ambientes dev/staging contêm exclusivamente dados sintéticos ou anonimizados?
- O acesso à produção está restrito a funções autorizadas em jurisdições adequadas?
- Existe um procedimento de exceção documentado para casos de suporte com acesso a dados?
D - Provedores de modelos e sub-operadores
- A delimitação está clara: Quais provedores são sub-operadores do provedor e quais operam no tenant da organização?
- A retenção de conteúdo nos provedores de modelos está desativada?
- A exclusão do uso para treinamento está documentada contratualmente?
- Onde estão localizados os endpoints dos modelos (região UE, US, outros)?
E - Armazenamento e exclusão de dados
- Está estabelecido onde os dados de conteúdo persistentes são armazenados (banco de dados, região, provedor)?
- Qual retenção de backup se aplica e como os dados excluídos são tratados nos backups?
- O usuário individual pode excluir seus próprios dados dentro da aplicação?
F - Setores regulados
- O contrato contém disposições de conformidade com sigilo profissional (legislação setorial brasileira ou equivalente)?
- Existem compromissos de confidencialidade para todas as pessoas com acesso?
- A tokenização PII está disponível como módulo opcional?
G - Governança e verificabilidade
- Uma trilha de auditoria para decisões de agentes está ancorada como componente contratual?
- As medidas técnicas e organizacionais podem ser evidenciadas sob solicitação (documentação de configuração, extratos de logs anonimizados)?
Do checklist à arquitetura
Essas 25 perguntas não são uma ferramenta jurídica. São uma bússola arquitetônica. Cada pergunta que seu provedor de IA não consegue responder revela uma lacuna em sua infraestrutura - não apenas em seu contrato.
Na Gosign, incorporamos esses requisitos na arquitetura: separação de ambientes com bloqueio de produção, registro sem dados de conteúdo, provedores de modelos no tenant do cliente, Decision Layer com trilha de auditoria completa. Não porque um cliente exigiu, mas porque IA empresarial sem essas bases não é auditável.
Se você deseja avaliar como sua infraestrutura de IA atual se compara com esses 25 pontos - ou se está avaliando uma nova plataforma - teremos prazer em conversar.