Tempo de leitura: 11 min · Atualizado em 03/09/2026
Em geral, sim: a empresa dona do aplicativo responde primeiro perante os usuários cujos dados vazaram, mesmo que a falha tenha sido criada pela empresa de tecnologia contratada para desenvolver o sistema. É ela quem tem a relação direta com quem usa o app. Depois de resolver a situação com os usuários, a empresa pode cobrar da desenvolvedora o prejuízo, se o contrato e as provas técnicas sustentarem isso.
Por que a empresa dona do aplicativo responde primeiro
Quando alguém cadastra nome, CPF, endereço ou dados de pagamento num aplicativo, essa confiança vai para a marca que oferece o serviço — não para a empresa de tecnologia que escreveu o código nos bastidores. Para o usuário, o aplicativo é da empresa que ele conhece e usa. Por isso, quando uma falha de segurança expõe esses dados, é a dona do produto quem precisa dar satisfação primeiro e reparar o dano, mesmo que o problema técnico tenha nascido no que foi entregue por outra empresa.
Essa lógica existe porque a Lei Geral de Proteção de Dados separa dois papéis: quem decide para que os dados serão usados e se beneficia deles (a empresa que lançou o aplicativo) e quem apenas executa o tratamento técnico por conta dela (a desenvolvedora contratada). Essa distinção organiza a relação interna entre as duas empresas, mas não serve de escudo perante o usuário lesado.
O papel da empresa de tecnologia que entregou o aplicativo
Isso não tira a desenvolvedora da história. Se ela foi contratada para construir o aplicativo com rotinas de segurança, criptografia e proteção contra acessos indevidos, e entregou um produto com falha grave nesse ponto, descumpriu o que prometeu. A diferença é a ordem da cobrança: primeiro a contratante resolve com os usuários, porque é ela quem responde por eles; depois, vira credora da desenvolvedora pelo prejuízo que teve.
Esse caminho de duas camadas lembra o que acontece quando uma empresa terceirizada de TI vaza dados de clientes durante um serviço em andamento. A diferença é que aqui o problema não está numa operação de infraestrutura contínua, mas num produto já entregue e publicado, usado por milhares de pessoas, quando a falha aparece.
Falha de segurança grave é diferente de bug comum
Um aplicativo que trava ou demora para carregar é problema de qualidade — chateia, pode gerar pedido de reembolso, mas não expõe ninguém a risco. Falha de segurança grave é outra categoria: senha salva sem proteção, banco de dados aberto na internet sem exigir login, informação sensível trafegando sem criptografia, ou brecha que permitiu a terceiros capturar dados de outros usuários.
Existe outro conteúdo sobre quem contratou um software cheio de falhas e quer o dinheiro de volta: ali a discussão é o produto não funcionar como prometido. Aqui a discussão é maior, porque a falha não afeta só quem pagou pelo aplicativo — afeta terceiros que nunca contrataram nada com a desenvolvedora e tiveram dados expostos por causa dela.
O que fazer assim que a falha é descoberta
A velocidade da reação pesa tanto quanto a correção técnica. Diante de uma falha que expõe dados de usuários, a sequência recomendada é:
- Isolar e corrigir o ponto vulnerável imediatamente, mesmo tirando uma funcionalidade do ar por algumas horas.
- Levantar com precisão quais dados foram expostos, de quantos usuários e por quanto tempo.
- Avisar os usuários afetados de forma clara, explicando o que aconteceu e o que está sendo feito.
- Registrar toda a comunicação técnica com a desenvolvedora sobre a origem da falha — prova decisiva na cobrança de regresso depois.
- Reforçar monitoramento e barreiras de acesso até a correção ser validada por teste independente.
Pular etapas, em especial deixar de avisar os usuários, costuma transformar um incidente administrável numa crise de reputação e numa indenização bem mais alta.
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
Como funciona a cobrança contra a desenvolvedora depois
Depois de responder pelos usuários, a empresa contratante pode buscar de volta o que gastou, desde que mostre três coisas: que a falha veio do código ou da configuração entregue pela desenvolvedora, que havia exigência contratual de segurança, e que o prejuízo teve relação direta com aquela falha específica.
Um laudo técnico independente, analisando código-fonte e registros do momento da exploração da falha, costuma ser a peça central dessa cobrança. Sem prova técnica, vira “palavra contra palavra”. A mesma lógica de comprovação aparece quando um fornecedor de software se recusa a entregar o código-fonte ao fim do contrato: sem acesso ao que foi produzido, fica bem mais difícil auditar o que deu errado.
O que o contrato de desenvolvimento precisa prever
Boa parte dessa dor de cabeça nasce de contratos assinados sem cláusulas claras de segurança:
| Ponto do contrato | Por que evita conflito depois |
|---|---|
| Padrão mínimo de segurança exigido | Define o que é “aplicativo pronto” e o que é falha inaceitável |
| Teste de segurança obrigatório antes da entrega | Cria registro formal de checagem, útil como prova |
| Prazo de correção de falhas críticas pós-lançamento | Evita discussão sobre “quanto tempo era razoável” |
| Quem paga a notificação de usuários em caso de falha | Deixa combinado antes do problema acontecer |
| Direito de auditar código e registros técnicos | Permite provar a origem da falha depois |
Quem já passou pela experiência de uma desenvolvedora abandonando o projeto no meio do caminho sabe como a falta desses pontos complica tudo — o mesmo vale quando o problema não é abandono, mas entrega com brecha de segurança.
Os direitos de quem teve os dados expostos
Do lado do usuário final, pouco importa qual empresa escreveu o código com a falha — é justamente para proteger essa posição que existe a Lei Geral de Proteção de Dados. Ele tem direito a ser informado, a saber quais dados foram expostos, a pedir explicações sobre as medidas tomadas e, dependendo da gravidade, a buscar reparação. Uma senha exposta e corrigida em minutos, sem uso indevido comprovado, tende a gerar resposta bem diferente de um vazamento de dados financeiros exposto por semanas.
Esse recorte — o que o usuário pode exigir da empresa que ele usa, não da desenvolvedora que ele nem conhece — é tratado com mais detalhe em outro conteúdo sobre o que fazer quando uma empresa vaza os dados de um cliente, útil para quem está do lado de quem teve informações expostas.
O que agrava a responsabilidade da empresa contratante
Alguns comportamentos, depois de descoberta a falha, pioram bastante a posição da empresa: demorar dias ou semanas para corrigir uma vulnerabilidade já reportada; manter o aplicativo coletando novos dados mesmo sabendo da falha ativa; minimizar o incidente publicamente ou negar exposição já conhecida internamente; e não ter nenhum registro de que exigiu segurança da desenvolvedora, o que enfraquece o próprio direito de cobrar dela depois. Uma resposta rápida, transparente e documentada, mesmo diante de falha grave, reduz tanto o risco de indenização quanto o desgaste de imagem.
Como reduzir esse risco em novos projetos
Prevenção custa muito menos do que remediar um vazamento em curso. Antes de lançar um aplicativo que vai lidar com dados de clientes, vale exigir da desenvolvedora um teste de segurança feito por equipe independente, revisar o que o contrato diz sobre padrão de segurança e correção de falhas, manter canal simples para reportar problemas, e guardar toda a documentação da entrega — telas de aceite, relatórios de teste, trocas sobre pendências. É esse material que sustenta uma cobrança de regresso caso algo dê errado. O mesmo cuidado vale para plataformas de terceiros usadas pela empresa, no espírito do que se discute quando um gateway de pagamento sofre vazamento e expõe dados de clientes por consequência.
Perguntas frequentes
A empresa pode se livrar da responsabilidade dizendo que contratou uma empresa de tecnologia confiável?
Não. Ter contratado uma empresa de boa reputação mostra cuidado na escolha, mas não transfere a responsabilidade perante os usuários. Quem lançou o produto responde primeiro, e depois discute com a desenvolvedora quem paga o quê.
É preciso provar má-fé da desenvolvedora para cobrar dela depois?
Não. Basta mostrar que a falha veio do trabalho entregue por ela e que havia expectativa contratual de segurança. Erro ou descuido técnico já costumam bastar para sustentar a cobrança.
O usuário final pode processar diretamente a empresa de tecnologia que fez o aplicativo?
Em regra, não é a via mais direta, já que o usuário não tem relação com a desenvolvedora — ele conhece o produto da empresa contratante. É contra ela que normalmente busca explicações e reparação.
Um vazamento pequeno, corrigido rápido, ainda gera responsabilidade?
Gera, mas o tamanho da reparação varia conforme a gravidade: quantidade de dados expostos, tipo de informação, tempo de exposição e uso indevido comprovado. Falha corrigida em minutos, sem dano concreto, tende a ter consequência bem menor do que exposição prolongada de dados sensíveis.
Vale colocar no contrato uma cláusula limitando o valor que a desenvolvedora pagaria em caso de falha?
É comum encontrar esse tipo de cláusula, e ela pode valer dentro de certos limites. Mas cláusulas que tentam afastar por completo qualquer responsabilidade da desenvolvedora por falha grave de segurança tendem a ser vistas com desconfiança, principalmente se deixam a contratante sozinha com prejuízo desproporcional ao que pagou pelo serviço.
Conclusão: segurança do aplicativo é de quem o lança, com direito de cobrar de quem o construiu
Quem coloca um aplicativo no mercado assume, perante seus usuários, o papel de cuidar dos dados recebidos — independentemente de ter sido a própria empresa ou um fornecedor externo quem escreveu o código. Isso não tira a responsabilidade da empresa de tecnologia contratada: ela pode e deve responder pelo prejuízo, desde que a falha tenha realmente partido do que entregou e isso esteja bem documentado.
Na prática, o melhor caminho é agir em duas frentes ao mesmo tempo: resolver rápido e com transparência a situação dos usuários afetados, e reunir, desde o primeiro momento, as provas técnicas e contratuais que vão sustentar a cobrança contra quem desenvolveu o aplicativo com a falha.
Fontes oficiais consultadas
Artigos relacionados
- Uma loja ou aplicativo coletou meus dados biométricos por reconhecimento facial sem meu consentimento explícito: quais os riscos para a empresa perante a LGPD?
- Empresa terceirizada de TI vazou dados de clientes: quem responde?
- Empresa vazou meus dados: quais direitos a LGPD garante além da indenização?
- Um aplicativo de geração de imagens por inteligência artificial criou conteúdo usando a logomarca da minha empresa sem autorização: cabe ação por uso indevido de marca?
Veja também nosso conteúdo completo sobre direito digital.
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
