*Por Ricardo Maravalhas
Um fato é inegável: a transformação digital acelerou o uso de plataformas terceirizadas em praticamente todas as empresas. Hoje, poucos negócios operam com sistemas totalmente próprios. A regra virou outra: aplicativos de CRM, automação de marketing, gateways de pagamento, ferramentas de atendimento, analytics, plugins, SDKs, ERPs e integrações em nuvem.
Essa dependência criou um ecossistema eficiente, escalável e rápido de implementar. Mas também criou um problema cada vez mais comum e perigoso: o vazamento de dados por terceiros. E quando isso acontece, surge uma pergunta inevitável e desconfortável:
Quem é o responsável quando um aplicativo terceirizado sofre vazamento?
A resposta que muitas empresas gostariam de dar é simples: “a culpa é do fornecedor”. Mas a realidade jurídica, técnica e reputacional é bem mais complexa.
A primeira verdade que precisa ser dita é direta: contratar uma solução externa não significa transferir responsabilidade. O erro mais comum no mercado é tratar segurança como um item do contrato, e não como parte da estratégia do negócio.
Quando uma empresa integra um aplicativo terceirizado ao seu ecossistema, ela está, na prática, abrindo uma porta dentro da própria operação. Essa porta pode acessar dados sensíveis, processos críticos e fluxos de informação que impactam diretamente clientes e usuários. Ou seja: o risco é compartilhado, mas o dano raramente é.
Outro dado relevante é que do ponto de vista do consumidor, não existe essa separação entre fornecedor e empresa. Se um banco usa uma plataforma de atendimento terceirizada e ocorre um vazamento, o cliente não vai procurar o nome da empresa de software responsável. Ele vai culpar o banco. Se um e-commerce usa um gateway de pagamento externo e os dados vazam, o consumidor não diz “foi culpa do provedor”. Ele diz: “a loja vazou meus dados”. Ou seja, a reputação sempre recai sobre quem está na linha de frente, e isso significa que, mesmo quando o incidente ocorre fora da infraestrutura direta da empresa, o impacto público é interno.
Nesse sentido, na LGPD, existem dois papéis principais:
- Controlador: quem decide por que e como os dados serão tratados.
- Operador: quem trata os dados em nome do controlador.
Na maioria dos casos, a empresa que contrata um aplicativo terceirizado é o controlador, e o fornecedor é o operador. Isso significa que a empresa contratante continua sendo responsável por garantir que aquele tratamento seja legítimo, seguro e compatível com as exigências da lei. Em outras palavras: a LGPD não permite que empresas usem terceiros como escudo. E mesmo que o operador seja responsabilizado, o controlador pode sofrer consequências severas, inclusive sanções, ações judiciais e danos reputacionais.
“A resposta que muitas empresas gostariam de dar é simples: “a culpa é do fornecedor”. Mas a realidade jurídica, técnica e reputacional é bem mais complexa”, comenta Maravalhas
Nesse novo ecossistema que atuamos, devemos lembrar que há o risco invisível das integrações e permissões excessivas. Por isso, o vazamento nem sempre acontece por ataque direto ao fornecedor. Muitas vezes, o problema está na forma como o aplicativo é integrado.
Alguns cenários comuns:
- aplicativos com permissões amplas demais para acessar dados;
- integrações via API sem autenticação robusta;
- chaves e tokens expostos em ambientes de desenvolvimento;
- ausência de controle granular de acesso;
- logs registrando informações sensíveis;
- uso de bibliotecas ou SDKs que coletam mais do que deveriam.
Ou seja, mesmo que o fornecedor seja “bom”, a implementação feita pelo contratante pode abrir brechas críticas. Nesse contexto, a pergunta muda de “quem vazou?” para “quem permitiu que isso fosse possível?”.
É mais do que preciso manter em mente que responsabilidade é também governança. Se o negócio coleta dados pessoais, ele precisa tratar a segurança como um processo contínuo, e não como um “evento de auditoria anual”.
Isso inclui práticas como:
- auditoria de fornecedores (vendor risk management);
- avaliação de compliance e segurança antes da contratação;
- exigência de certificações (como ISO 27001, SOC 2, etc.);
- revisão periódica de permissões e acessos;
- criptografia e segregação de dados;
- testes de vulnerabilidade e pentests em integrações;
- plano de resposta a incidentes incluindo terceiros.
Ou seja: terceirizar tecnologia não pode significar terceirizar a vigilância.
Aqui ressalto que o uso de aplicativos terceirizados não é o problema. Ele é inevitável. O problema é que muitas empresas ainda escolhem fornecedores com base em preço e rapidez de implementação, e deixam segurança para depois (só que esse “depois” costuma ser tarde demais e pode custar caro).
No final, a responsabilidade é de quem escolheu o “terceiro”. Afinal, quando um aplicativo terceirizado sofre vazamento, a culpa técnica pode ser do fornecedor, mas a responsabilidade estratégica continua sendo de quem decidiu integrar aquela tecnologia ao negócio.
No fim, não importa quem causou o vazamento. O mercado, os usuários e a reputação vão cobrar de quem permitiu que ele acontecesse e a lição é clara: Na economia digital, terceirizar tecnologia não significa terceirizar responsabilidade.
Ricardo Maravalhas é fundador e CEO da DPOnet, empresa com mais de 5.000 clientes, que nasceu com o propósito de democratizar, automatizar e simplificar a jornada de conformidade com a LGPD (Lei Geral de Proteção de Dados) por meio de uma plataforma SaaS completa de Gestão de Privacidade, Segurança e Governança de Dados, com serviço de DPO embarcado, atendimento de titulares, que utiliza o conceito de Business Process Outsourcing (BPO) e IA integrada (DPO Artificial Intelligence).
