Um aplicativo pode funcionar como foi programado e, ainda assim, não estar pronto para o mercado. A interface recebe cadastros, uma integração entrega resultados, a equipe comercial prepara a oferta. Mas quem consegue explicar por que cada dado é tratado, o que um terceiro faz com ele, quais limites o produto tem e quem responde quando algo falha?
Essas questões não se resolvem apenas com termos de uso e política de privacidade. Os documentos são importantes, mas dependem de escolhas anteriores sobre produto, operação e responsabilidades. Se tais escolhas não existem, uma frase no site pode prometer mais do que o software e a empresa conseguem cumprir.
Uma decisão sobre dados vira uma decisão de produto
Imagine, hipoteticamente, um app em preparação para lançamento. Para funcionar, ele pede um cadastro; para melhorar a experiência, a equipe propõe registrar interações; para medir resultados, quer conectar uma ferramenta externa. São operações diferentes, não uma autorização genérica para “usar dados”. Cada operação de tratamento precisa de finalidade específica e base legal aplicável, além de respeitar adequação e necessidade. A base não é automaticamente o consentimento, e dados sensíveis exigem análise própria. LGPD, arts. 6º, 7º e 11.
Essa análise interfere no backlog: quais campos são realmente necessários para entregar a função? A métrica precisa identificar uma pessoa ou pode ser produzida de outra forma? Quem acessa os dados, por quanto tempo e em qual etapa? Dependendo da resposta, a equipe pode precisar alterar o fluxo de cadastro, a integração, os controles de acesso e até a prioridade de uma funcionalidade. Não é um parecer colado ao fim da sprint; é uma restrição de projeto a ser considerada quando as escolhas ainda podem mudar.
A LGPD também exige transparência sobre finalidade, forma e duração do tratamento, uso compartilhado e direitos do titular. E determina que controlador e operador mantenham registro das operações que realizam. Se a política descreve um fluxo diferente daquele implementado, revisar apenas a redação não corrige o descompasso. É preciso reconciliar o que o sistema faz, o que a empresa registra e o que comunica. LGPD, arts. 9º e 37.
Uma integração externa pode mudar o desenho do negócio
Hospedagem, análise de uso, pagamentos, comunicação e suporte podem participar da jornada digital. A pergunta não é só “o fornecedor é confiável?”. É preciso entender quais dados recebe, para que os utiliza, que acesso concede, como reporta problemas e o que acontece se a integração for trocada ou encerrada. Sem essas respostas, a equipe de desenvolvimento pode assumir uma dependência que o contrato não contempla — ou o comercial pode oferecer uma funcionalidade cujo funcionamento depende de um terceiro sem plano claro de continuidade.
Nem todo fornecedor é automaticamente operador. O papel se apura por operação: quem decide finalidades e elementos essenciais atua como controlador; quem trata dados em nome dele e sob suas instruções, como operador. Uma organização pode ocupar papéis distintos em operações diferentes, e um funcionário subordinado não se torna operador separado só por acessar dados. O nome dado no contrato não substitui a análise do fluxo real. Guia da ANPD sobre agentes de tratamento; LGPD, arts. 5º, VI e VII, e 39.
Na prática, produto, tecnologia e jurídico precisam comparar três peças: o fluxo técnico, as responsabilidades efetivas e os instrumentos da relação com o terceiro. Quem recebe a solicitação de um titular? Quem fornece as informações necessárias para avaliá-la? Quem avisa a outra parte sobre um problema de segurança e em que condições? A resposta deve ser operacionalmente possível; o contrato ajuda a distribuí-la, mas não cria uma capacidade que a empresa não tem.
Uma integração aprovada pelo time técnico não é, por isso, uma relação de dados e responsabilidades já resolvida.
Direitos e segurança precisam existir também fora do texto
Se uma pessoa pede acesso ou correção de seus dados, alguém precisa localizar as informações, examinar o pedido e coordenar os sistemas envolvidos. Se pede eliminação, a equipe precisa avaliar a hipótese aplicável: a LGPD prevê, por exemplo, a eliminação de dados desnecessários, excessivos ou tratados em desconformidade com a lei, mas admite conservação em certas situações após o término do tratamento. Um canal de contato sem processo e sem capacidade técnica de resposta é apenas uma promessa incompleta. Os direitos previstos na LGPD tornam essa capacidade parte da operação do produto, não mero item da política. LGPD, arts. 18, VI, e 16.
O mesmo vale para a segurança. A LGPD exige medidas técnicas e administrativas aptas a proteger os dados e determina que sejam observadas desde a concepção do produto ou serviço até sua execução. Isso não escolhe uma arquitetura única para todos os apps. Exige que riscos e medidas sejam avaliados no contexto da operação: acesso, armazenamento, comunicação, manutenção e resposta a falhas são perguntas de projeto e de gestão. O guia de segurança da ANPD, dirigido a agentes de tratamento de pequeno porte, oferece exemplos de medidas, não um checklist universal de conformidade. LGPD, arts. 46 e 49; guia da ANPD sobre segurança.
Quando ocorre um incidente, não basta procurar uma cláusula. É preciso apurar os fatos, compreender os dados e titulares envolvidos e avaliar o risco. A LGPD atribui ao controlador a comunicação à ANPD e aos titulares de incidente que possa acarretar risco ou dano relevante. O operador e outros fornecedores precisam fornecer informações compatíveis com sua atuação para que essa avaliação e as providências sejam possíveis. LGPD, arts. 39 e 48.
Colocar no mercado é assumir o que se anuncia
Um produto não chega ao mercado apenas quando o código entra em produção. Ele chega também por uma página de vendas, uma demonstração, uma proposta comercial, um contrato e um atendimento. Se cada canal descreve limites diferentes, a empresa cria uma distância entre oferta e entrega. Em relações de consumo, informação ou publicidade suficientemente precisa pode vincular o fornecedor e integrar o contrato; a oferta deve trazer informações corretas, claras e precisas. Isso não transforma toda contratação de software em relação de consumo: o enquadramento depende da relação concreta. Código de Defesa do Consumidor, arts. 2º, 3º, 30 e 31.
Mesmo fora desse enquadramento, a coerência entre demonstração, proposta, contrato, interface e operação é uma escolha de gestão de risco. Antes de prometer disponibilidade, integração, finalidade de uso dos dados ou resposta a solicitações, vale perguntar: quem entregará isso, com qual fornecedor, em qual versão do produto e sob quais condições? Uma promessa comercial pode exigir desenvolvimento adicional; uma mudança técnica pode exigir revisão de contratos e comunicações. O mercado vê um produto único, não departamentos separados.
O Marco Civil da Internet assegura, no seu âmbito, informações claras e completas sobre contratos de prestação de serviços e sobre coleta, uso, armazenamento, tratamento e proteção de dados pessoais. A leitura deve considerar o serviço concreto, sem presumir que todo aplicativo seja um serviço de conexão. Marco Civil da Internet, art. 7º, VI e VIII.
O lançamento não encerra a governança
Uma versão nova pode acrescentar dados, alterar uma finalidade, introduzir um fornecedor ou mudar a promessa feita ao usuário. Por isso, um critério útil de liberação não pergunta apenas se a função passou nos testes. Pergunta também se as novas operações foram entendidas, se os responsáveis conseguem executá-las, se os terceiros envolvidos estão alinhados e se a comunicação ao mercado corresponde ao que será entregue.
A LGPD permite que controladores e operadores formulem regras de boas práticas e governança, consideradas a natureza, o escopo, a finalidade e os riscos do tratamento; o controlador pode implementar programa de governança com mecanismos de supervisão e atualização. Isso não impõe o mesmo ritual de lançamento a toda empresa. LGPD, art. 50, caput e §§ 1º e 2º.
Como recomendação de gestão — não como rito legal obrigatório —, a equipe pode transformar essas perguntas em decisões verificáveis ao longo do ciclo do produto:
Antes de construir: descrever a função, os dados necessários, sua finalidade, a base legal a avaliar e as dependências externas.
Antes de integrar: conferir o fluxo real, os papéis por operação, as instruções possíveis e o caminho de resposta a falhas e solicitações.
Antes de oferecer: comparar o que o produto efetivamente entrega com demonstração, proposta, contrato, termos de uso e política de privacidade.
Depois de lançar: tratar novas versões, incidentes e mudanças de fornecedor como possíveis gatilhos de revisão, não apenas de atualização textual.
Não há formulário que dispense essa análise. O ganho é outro: decisões jurídicas deixam de chegar como surpresa no fim do desenvolvimento, e decisões técnicas deixam de aparecer como surpresa depois da venda. Termos de uso e política de privacidade passam a cumprir sua função — refletir uma operação conhecida e responsabilidades assumidas — em vez de tentar substituir a governança que faltou.
Abraço,
Rogério Santos
Santos Advocacia
O seu produto conseguiria responder?
Se amanhã um usuário, um parceiro ou sua equipe perguntasse como os dados circulam, quem decide sobre eles e o que foi de fato prometido, a resposta estaria no funcionamento do negócio — ou apenas em um documento? A Santos Advocacia atua na estruturação jurídica de relações empresariais e tecnológicas, conectando documentos às decisões que os sustentam.
Deixe o seu comentário: