Quem vende infraestrutura hospeda dado pessoal de terceiros por definição — a base de clientes do seu cliente, o cadastro dos usuários dele, os arquivos que ele armazena. Isso coloca o provedor dentro do alcance da LGPD com um papel específico e obrigações próprias, que não desaparecem porque "o dado é do cliente". Entender esse papel é proteção jurídica e, cada vez mais, argumento de venda. Este texto é uma orientação prática de infraestrutura, não parecer jurídico — a redação final dos seus contratos pede advogado.

Controlador e operador: o papel define a obrigação

A LGPD separa dois papéis, e o provedor normalmente ocupa os dois ao mesmo tempo, em relações diferentes.

Em relação ao dado dos usuários do seu cliente, você é operador: trata o dado em nome de outro, seguindo as instruções dele. Quem decide por que aquele dado existe e o que se faz com ele é o seu cliente — o controlador.

Em relação ao cadastro do seu próprio cliente — nome, CNPJ, contato, dado de cobrança, registros de acesso ao painel —, você é controlador. A decisão é sua, e as obrigações de controlador se aplicam integralmente.

A distinção tem consequência prática imediata: como operador, você não pode usar o dado do cliente para finalidade própria. Treinar um modelo, gerar estatística comercial ou enriquecer base a partir do dado hospedado exige autorização expressa do controlador — e sem ela é tratamento irregular.

Responsabilidade não é transferível

A ideia de que "o dado é do cliente, então o problema é dele" é confortável e errada. A lei prevê situações em que o operador responde solidariamente pelo dano, especialmente quando descumpre as instruções recebidas ou deixa de adotar medidas de segurança adequadas.

Traduzindo para a operação: se houver vazamento porque o seu isolamento entre clientes falhou, porque o backup estava sem cifragem ou porque uma credencial administrativa sua foi comprometida, a responsabilidade é sua. Contrato bem escrito distribui e limita risco; ele não elimina a obrigação de fazer a parte técnica corretamente.

O contrato de tratamento de dados

Todo contrato com cliente que hospeda dado pessoal deve ter uma seção — ou anexo — que trate especificamente disso. O que precisa estar lá:

1. A definição dos papéis, deixando claro que o cliente é controlador e você é operador, e qual é o objeto do tratamento.
2. A finalidade e os limites: você trata o dado exclusivamente para prestar o serviço contratado, e para nada mais.
3. As medidas de segurança que você adota, descritas de forma verificável — cifragem, isolamento, controle de acesso, backup.
4. A regra de subcontratação, que a próxima seção detalha.
5. O procedimento de incidente, com prazo e canal de comunicação ao cliente.
6. A cooperação no atendimento a direitos do titular: o cliente vai receber pedidos de exclusão e de acesso, e vai precisar da sua ajuda para cumpri-los. Defina o mecanismo.
7. A retenção e a destruição ao fim do contrato, com prazos.
8. O direito de auditoria do cliente, ainda que na forma de relatório e certificação em vez de acesso direto ao ambiente.

Ter esse anexo pronto e bem escrito acelera venda para cliente corporativo, que vai pedir de qualquer forma. Não tê-lo trava negócio no jurídico.

Subcontratação precisa ser transparente

Você provavelmente usa terceiros: o datacenter, um serviço de backup externo, uma ferramenta de monitoramento, um provedor de e-mail transacional. Cada um deles é suboperador, e a regra é que a subcontratação depende de autorização do controlador.

O modo prático de resolver: mantenha uma lista de subcontratados com nome, finalidade e localização, referenciada no contrato, com autorização geral e obrigação de comunicar alterações com antecedência. Isso é bem mais operável que pedir autorização caso a caso, e é o padrão de mercado.

E vale a consequência técnica: cada subcontratado precisa ter, com você, um compromisso equivalente ao que você tem com o seu cliente. A corrente não pode ter elo mais fraco no fim.

Transferência internacional: o seu diferencial competitivo

Aqui está o ponto em que provedor nacional tem vantagem estrutural, e ela merece ser explorada comercialmente.

Enviar dado pessoal para fora do país é transferência internacional, e exige fundamento legal específico. Isso não é proibido, mas adiciona exigências, documentação e risco. E o alcance é maior do que a maioria imagina: se o seu backup vai para um provedor de armazenamento estrangeiro, ou se a sua ferramenta de suporte armazena conversas fora do país, há transferência internacional acontecendo — mesmo que o servidor principal seja nacional.

Duas ações concretas. Primeiro, mapeie para onde o dado vai de verdade, incluindo ferramentas auxiliares — é comum descobrir três ou quatro fluxos não considerados. Segundo, quando o dado permanece integralmente em território nacional, diga isso de forma explícita no material comercial. Para cliente de saúde, jurídico, financeiro e setor público, isso frequentemente decide a compra, e é algo que o provedor global não consegue oferecer com a mesma simplicidade.

Incidente de segurança: prepare antes

A obrigação de comunicar existe, e o prazo é curto — a regulamentação da ANPD estabelece prazo específico para a comunicação, que vale conferir na versão vigente, porque esse é um ponto que tem evoluído. O que importa operacionalmente é que não há tempo para improvisar o processo durante o incidente.

Como operador, a sua obrigação primária é comunicar o controlador — o seu cliente — para que ele avalie e cumpra os deveres dele perante a ANPD e os titulares. Isso precisa estar pronto antes:

• Quem detecta e quem decide que houve incidente com dado pessoal.
• Canal e prazo de aviso ao cliente, definidos no contrato.
• Modelo de comunicação já redigido, com o que se sabe, o que não se sabe, o que foi feito e o que o cliente deve considerar.
• Capacidade de determinar o escopo: quais clientes, quais dados, qual período. Sem log adequado, essa pergunta não tem resposta — e "não sabemos a extensão" é a pior posição possível.
• Registro de tudo, porque a demonstração de diligência é o que separa um incidente bem conduzido de uma sanção.

Retenção e destruição no encerramento

Quando o contrato termina, o dado não deve ficar. Isso é obrigação legal e é também redução de risco: dado que você não tem mais não pode vazar.

O procedimento precisa cobrir volume da VM, snapshots, backups — inclusive as cópias externas — e os registros no painel, respeitando o prazo de retenção contratado e eventuais obrigações legais de guarda. Cifragem com chave por cliente resolve isso de forma elegante e demonstrável: destruir a chave inutiliza todas as cópias, inclusive as que já saíram do seu perímetro.

Defina o prazo no contrato, execute e registre a execução. Provedor que não consegue provar que apagou está na mesma posição de quem não apagou.

Encarregado e o mínimo de governança

A lei prevê a figura do encarregado — o ponto de contato para titulares e para a autoridade. Para provedor de qualquer tamanho, vale ter esse papel nomeado e publicado, mesmo que acumulado por alguém.

Um mínimo de governança que cabe em pequenas equipes: nomeie e publique o encarregado com canal de contato; mantenha um inventário do que você trata e para quê; mantenha a lista de subcontratados atualizada; tenha a política de privacidade coerente com o que você faz de fato; e registre as decisões relevantes. O objetivo não é papelada: é conseguir demonstrar diligência quando for perguntado — pelo cliente na due diligence ou pela autoridade depois de um incidente.

As medidas técnicas que sustentam o discurso

Conformidade sem base técnica é texto. As medidas que efetivamente reduzem risco e que você vai precisar descrever:

• Isolamento entre clientes verificado, não presumido.
• Cifragem em repouso e em trânsito, com chave por cliente onde possível.
• Controle de acesso administrativo com dois fatores, privilégio mínimo e registro de auditoria.
• Backup cifrado e testado, com restauração validada.
• Registro de operações com retenção suficiente para determinar escopo de incidente.
• Gestão de correções, porque vulnerabilidade conhecida e não corrigida é o oposto de diligência.

Erros comuns

• Presumir que a responsabilidade é toda do cliente porque o dado é dele.
• Nenhum anexo de tratamento de dados no contrato.
• Usar dado hospedado para finalidade própria sem autorização.
• Lista de subcontratados inexistente ou desatualizada.
• Backup em provedor estrangeiro sem tratar a transferência internacional.
• Ferramentas auxiliares levando dado para fora sem ninguém mapear.
• Nenhum processo de incidente definido antes do incidente.
• Log insuficiente para determinar o escopo de um vazamento.
• Dado mantido após o fim do contrato, sem prazo nem registro de destruição.
• Encarregado não nomeado.
• Não usar a permanência do dado em território nacional como argumento comercial.

Onde a Solvefy/Cloud entra

Ajudamos provedores a construir a base técnica que sustenta a conformidade — isolamento verificado, cifragem com chave por cliente, auditoria com retenção adequada, backup testado e procedimento de destruição demonstrável — e a organizar o inventário de tratamento e a lista de subcontratados. Na plataforma E-CLOUD, a operação nasce com o dado, o fluxo e a marca na sua própria infraestrutura, o que simplifica bastante a questão da transferência internacional. Para a redação contratual, trabalhamos junto com o seu jurídico.

Quer avaliar a base técnica da sua conformidade? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.