LGPD em APIs e Integrações entre Sistemas: Como Estruturar Cláusulas de Proteção de Dados entre Parceiros Técnicos?

O contrato comercial genérico não cobre a integração técnica

Toda integração entre sistemas de empresas diferentes carrega, por trás da documentação técnica e dos endpoints, uma pergunta que raramente aparece nas reuniões de arquitetura: quem é responsável pelos dados pessoais que passam por ali? Nós observamos, na prática de compliance, que essa pergunta costuma surgir tarde demais — geralmente depois que a integração já está em produção.

É comum que duas empresas fechem uma parceria comercial, assinem um contrato com cláusula padrão de confidencialidade, e só então o time técnico avance para construir a integração via API. O problema é que essa cláusula padrão, pensada para proteger informações comerciais e segredos de negócio, raramente detalha o que realmente importa do ponto de vista da LGPD: qual dado pessoal trafega, com qual finalidade, por quanto tempo o parceiro pode retê-lo e o que acontece se um dos lados sofrer um incidente de segurança.

Apesar disso, muitas integrações entram em produção amparadas apenas nesse contrato genérico. Uma plataforma do setor de logística, por exemplo, pode integrar sua API de rastreamento com o sistema de um parceiro de e-commerce, expondo dados como endereço, telefone e histórico de entregas — tudo isso sem que nenhum documento específico defina o papel de cada empresa na relação ou o volume exato de dados compartilhado.

Integração sem cláusula específica versus integração com proteção adequada

Essa distinção parece óbvia quando descrita em abstrato, mas se perde facilmente na pressão de entregar uma integração dentro do prazo combinado com o parceiro comercial.

Quem é controlador e quem é operador na integração

Antes de qualquer cláusula técnica, a relação entre as partes precisa ser definida em termos de papéis da LGPD. Se uma empresa envia dados de seus clientes para que um parceiro execute uma tarefa específica em nome dela — como envio de notificações ou processamento de pagamento —, o parceiro normalmente assume o papel de operador, seguindo instruções documentadas. Porém, se cada empresa usa os dados recebidos para suas próprias finalidades, ambas podem ser tratadas como controladoras independentes, cada uma respondendo por seu próprio tratamento.

Essa definição não é apenas formalidade jurídica: ela determina quem responde perante a ANPD em caso de fiscalização e quem tem o dever de atender solicitações do titular relacionadas àquele dado específico. Uma integradora de pagamentos que recebe dados de cartão via API para processar uma transação atua como operadora, enquanto uma plataforma de análise de crédito que recebe os mesmos dados para gerar seu próprio scoring provavelmente atua como controladora.

As cláusulas que um DPA de integração técnica precisa ter

Um Data Processing Agreement (DPA) bem estruturado para integrações via API costuma reunir um conjunto específico de cláusulas, cada uma cobrindo um risco distinto da relação técnica entre os sistemas:

Vale destacar que essas cláusulas não substituem os controles técnicos da integração — elas formalizam o que já deveria estar refletido na arquitetura, criando um documento capaz de sustentar a empresa em caso de questionamento.

Escopo mínimo de dados: o princípio que a API costuma ignorar

Um dos erros mais recorrentes em integrações técnicas é expor, via API, mais dados do que o parceiro efetivamente precisa para a finalidade combinada. Isso acontece com frequência quando a equipe de engenharia reutiliza um endpoint já existente, criado originalmente para outro propósito, em vez de desenhar uma resposta específica para a nova integração.

Um sistema de RH que integra seu cadastro de colaboradores com uma plataforma de benefícios, por exemplo, pode acabar enviando todo o registro do funcionário — incluindo dados sensíveis como informações de saúde declaradas em formulários internos — quando a plataforma de benefícios só precisaria de nome, cargo e e-mail corporativo para operar. Esse excesso de dados amplia desnecessariamente a superfície de risco da integração, senão a exposição em caso de incidente do lado do parceiro ficaria restrita ao mínimo necessário.

Segurança na troca de dados: além do “HTTPS por padrão”

Do ponto de vista técnico, muitas equipes consideram que usar HTTPS já resolve a questão de segurança da integração. Isso cobre a criptografia em trânsito, mas deixa de lado outros controles igualmente relevantes: autenticação forte entre os sistemas, rotação periódica de chaves de API, limitação de taxa de requisições e registro de logs de acesso que permitam auditar quem consultou quais dados e quando.

Ainda assim, controles técnicos avançados não substituem a formalização contratual desses requisitos. Uma cláusula de segurança bem redigida no DPA obriga o parceiro a manter esses controles ao longo de toda a vigência da integração, e não apenas no momento da homologação inicial — período em que a maioria das equipes técnicas presta mais atenção a esses detalhes.

Notificação de incidentes: o ponto mais negligenciado

Quando um incidente de segurança afeta dados pessoais trafegados entre dois sistemas integrados, o tempo de resposta é determinante para conter o dano e cumprir as obrigações da LGPD perante a ANPD e os titulares afetados. Contudo, é comum que contratos de integração técnica sequer mencionem um prazo específico para que o parceiro comunique um incidente identificado do seu lado.

Sem essa cláusula, a empresa pode descobrir um vazamento envolvendo dados que ela mesma controla apenas quando já é tarde demais para agir dentro do prazo legal de comunicação à autoridade. Por isso, o DPA deve estabelecer um prazo curto e objetivo — geralmente medido em horas, não em dias — para que o parceiro notifique qualquer incidente relevante identificado na integração.

Subcontratação: quando o dado passa por um terceiro sem que ninguém perceba

Outro ponto frequentemente esquecido é a possibilidade de o parceiro técnico repassar os dados recebidos a outros fornecedores — provedores de nuvem, ferramentas de monitoramento, serviços de análise. Sem uma cláusula específica sobre subcontratação, a empresa perde visibilidade sobre por quantas mãos seus dados pessoais efetivamente passam depois de saírem de sua própria infraestrutura.

Uma cláusula bem estruturada exige que o parceiro informe previamente qualquer subcontratado que terá acesso aos dados, mantendo o mesmo nível de proteção contratual em toda a cadeia. Todavia, essa exigência só funciona na prática se a empresa também acompanhar, periodicamente, se o parceiro está de fato cumprindo esse compromisso, e não apenas confiar na cláusula assinada.

O que muda quando a integração já está em produção

Formalizar essas cláusulas antes de uma integração entrar em produção é o cenário ideal, mas boa parte das empresas se depara com integrações antigas, construídas antes de qualquer preocupação formal com proteção de dados. Nesses casos, o caminho costuma envolver um mapeamento retroativo: identificar quais integrações existentes trafegam dados pessoais, avaliar se há contrato específico cobrindo essa troca e, quando necessário, negociar um aditivo com o parceiro para formalizar o que já acontece tecnicamente.

Esse processo de regularização tende a ser mais trabalhoso do que estruturar uma integração nova do zero, já que exige negociação com parceiros que talvez não vejam urgência imediata em assinar um novo documento para algo que “já está funcionando há anos sem problema”.

Conclusão

Uma integração técnica segura, do ponto de vista de proteção de dados, não se resume a criptografar a conexão entre dois sistemas. Ela exige que o contrato entre as partes reflita, com a mesma precisão da documentação técnica da API, quem é responsável por cada dado, com qual finalidade ele é tratado e o que acontece quando algo sai do combinado. Empresas que tratam essas cláusulas como parte do processo de integração — e não como um documento assinado à parte, sem relação com o que o código realmente faz — reduzem de forma significativa o risco de uma parceria técnica se transformar em um passivo regulatório.

Para aprofundar temas relacionados, vale consultar os artigos Operador e controlador na LGPD: entenda as diferenças e responsabilidades e Como estruturar contratos de tratamento de dados com fornecedores e parceiros no blog da DPOnet.