Dependências invisíveis: A parte do conjunto de análise que deixámos de questionar

Onur Alp Soner é cofundador e CEO da Countly.

FinTech move-se rapidamente. As notícias estão por toda parte, a clareza nem sempre.

FinTech Weekly traz as principais histórias e eventos num só lugar.

Clique aqui para subscrever a newsletter do FinTech Weekly

Lido por executivos do JP Morgan, Coinbase, BlackRock, Klarna e mais.

Quando uma violação de dados vira notícia, geralmente é apresentada como uma exceção – uma má configuração, uma permissão negligenciada, um erro humano que poderia acontecer a qualquer um. A discussão muitas vezes termina aí, como se o incidente em si fosse a causa. Na realidade, as violações são mais frequentemente sinais do que falhas. Elas expõem dependências que se tornaram demasiado centrais e opacas muito antes de algo dar errado. Quando os dados são vazados, o risco normalmente já vinha crescendo silenciosamente há anos.

Por muito tempo, a análise de dados foi vista como uma categoria segura. Era considerada observacional, algo que monitorava o sistema em vez de moldá-lo. Diferente de pagamentos, identidade ou infraestrutura central, a análise raramente era tratada como uma camada que pudesse afetar materialmente os resultados.

No fintech, especialmente, a análise agora influencia como os sistemas evoluem e como as decisões são tomadas, moldando o comportamento do produto, os controles de risco e até a automação. Ainda assim, a infraestrutura por trás dela costuma ser externa, operando em plataformas de terceiros fora do controle direto da organização.

Essa é a dependência invisível que deixámos de questionar.

Por que “sem PII” deixou de ser uma definição suficiente de segurança

Quando as equipes justificam terceirizar a análise de dados, o argumento geralmente centra-se nos dados pessoais. Os eventos são anonimizados. Nenhum nome ou email é coletado. Sem PII, presume-se que o risco seja baixo.

Embora essa lógica fosse válida quando a análise se limitava a contar usuários e sessões, ela se desmorona quando a análise começa a capturar como os sistemas se comportam.

Os dados de eventos modernos fazem muito mais do que descrever usuários individuais. Exponham a estrutura interna. Nomes de funcionalidades, URLs internas, variantes de experimentos, estados de erro, padrões de tempo e respostas do backend revelam como um produto é projetado e como as decisões fluem através dele. Nada disso identifica diretamente uma pessoa, mas, juntos, podem reconstruir grande parte da lógica interna de uma organização.

É aqui que o efeito mosaico se torna relevante na prática. Eventos isolados parecem inofensivos. Quando agregados ao longo do tempo, por funcionalidades e fluxos, revelam como um produto realmente funciona. No fintech, isso tem consequências reais. Mesmo eventos anonimizados podem indicar limites de aprovação, regras de pontuação de risco ou caminhos de escalonamento. A sensibilidade dos dados de análise hoje reside menos em quem eles rastreiam e mais no que revelam.

Os limites de “Nós cuidamos da segurança para você.”

Os fornecedores de análise destacam-se em escala, desempenho e velocidade de integração. Essas qualidades são importantes. O que eles não otimizam é a segurança a longo prazo, a defensabilidade regulatória ou a capacidade de uma organização explicar sua própria arquitetura sob escrutínio.

Quando os fornecedores dizem que “cuidam da segurança”, geralmente querem dizer que a complexidade está oculta. Você não consegue ver como os dados são combinados, retidos ou quais sinais secundários são derivados. A invisibilidade é vendida como simplicidade, mas o controle é substituído pela confiança. Normas como SOC2 validam controles, não escolhas arquitetônicas. Um sistema pode estar totalmente certificado e ainda concentrar dados sensíveis de análise de formas difíceis de justificar sob análise.

Essa troca pode ser aceitável em outros contextos. Para análises que moldam decisões, ela cria risco estrutural ao substituir segurança verificável por sistemas ocultos e confiança presumida.

As contas financeiras já operam sob essa lógica: rastreabilidade, auditabilidade e propriedade são inegociáveis. A análise agora influencia decisões igualmente importantes, mas ainda não foi tratada com a mesma disciplina.

Como o risco estrutural se acumula em sistemas de análise

A maioria dos incidentes de análise de dados não decorre de uma única má escolha. Eles surgem gradualmente, à medida que os sistemas assumem responsabilidades que nunca foram projetados para suportar.

As equipes adicionam mais eventos, depois mais contexto, depois mais metadados. Flags de funcionalidades, IDs de experimentos, códigos de erro internos, estados do backend e classificações de usuários lentamente entram nos fluxos de eventos. Com o tempo, a análise torna-se um espelho detalhado de como o produto realmente funciona. Nesse ponto, ela deixa de ser uma camada passiva de relatórios e passa a ser uma forma de memória institucional.

Quando os dados são expostos, o que vaza raramente são apenas números crus. É a estrutura: como as funcionalidades são implementadas, como as decisões são encenadas, como os serviços interagem e como os casos extremos são tratados. Incidentes recentes mostraram isso claramente, com logs antes considerados inofensivos revelando lógica de roteamento interno, configurações de experimentos, caminhos de administração e padrões comportamentais que nunca deveriam ter saído do controle organizacional.

A IA não introduz esse risco, mas o amplifica. A análise comportamental alimenta cada vez mais sistemas de decisão automatizados, o que significa que a exposição estrutural pode influenciar o comportamento do modelo, o viés e a lógica de decisão. Um único incidente pode afetar não apenas a transparência, mas também como os sistemas agem daqui para frente.

No fintech, o impacto é ainda maior. Os dados de análise frequentemente estão próximos de sistemas que avaliam confiança, detectam fraudes ou automatizam aprovações. Mesmo quando a análise não toma decisões por si só, ela influencia cada vez mais os sistemas que o fazem.

Conveniência como substituto de fiscalização

Para equipes sob pressão para avançar rapidamente, dashboards bem elaborados, integrações rápidas e insights instantâneos são difíceis de resistir. Com o tempo, porém, a conveniência tende a substituir a fiscalização. Poucas organizações mapeiam detalhadamente seus fluxos de dados de análise, avaliam quão difícil seria sair de uma plataforma ou consideram quanto do conhecimento institucional foi efetivamente terceirizado. Isso raramente é uma escolha deliberada. É o resultado de tratar a análise como ferramenta, e não como infraestrutura.

Isso não é um argumento contra serviços de terceiros em geral. Na verdade, algumas camadas são bem adequadas para serem alugadas, especialmente quando a falha é contida e a saída é simples. A distinção importante é se um sistema molda resultados.

Para ser claro, qualquer sistema que influencie acesso, confiança, elegibilidade ou experiência central do usuário deve ser visível, auditável e totalmente compreendido pela organização que dele depende. Sistemas fáceis de substituir e que não codificam lógica institucional podem viver com segurança fora da organização.

Um teste simples esclarece o limite: se esse sistema desaparecesse amanhã, você ainda conseguiria explicar como seu produto funciona e por que as decisões são tomadas do jeito que são?

A questão mais ampla de responsabilidade

Os sistemas de fintech cada vez mais funcionam como infraestrutura de uso público. Eles moldam quem pode abrir contas, acessar crédito ou participar na economia. Essa realidade altera o modelo de responsabilidade. Decisões arquitetônicas deixam de ser apenas escolhas técnicas internas; elas têm consequências sociais.

Quando camadas críticas como plataformas de nuvem, sistemas de análise ou modelos de IA estão concentrados em poucos sistemas opacos, falhas e decisões não explicadas podem reverberar muito além de uma única empresa. Dependências invisíveis não apenas aumentam o risco de segurança, mas também enfraquecem a responsabilização.

No final, se um sistema não pode ser visto, não pode ser governado. E sistemas que não podem ser governados não devem ser confiados para tomar decisões que afetam materialmente a vida das pessoas. A análise de dados deixou de ser apenas observacional há algum tempo. Nossa arquitetura, padrões e suposições ainda precisam acompanhar esse avanço.