O relato de uma vítima que condiciona a própria retomada da vida à continuidade da prisão de seu agressor expõe uma ferida social profunda, mas também levanta uma questão que raramente associamos a dashboards, microsserviços ou pipelines de dados: até onde a tecnologia pode — e deve — intervir em dinâmicas de violência doméstica? Como engenheiro de software, passei anos projetando sistemas para escalar negócios, otimizar latências e garantir disponibilidade. Recentemente, porém, tenho me debruçado sobre um problema diferente: como arquitetar soluções que protejam pessoas em situação de vulnerabilidade sem criar novas formas de controle ou vigilância indevida.
Casos como o de Giullia Falcão não são apenas notícias de página policial; são sintomas de um ecossistema onde a tecnologia frequentemente falha em oferecer segurança real. Aplicativos de denúncia, dispositivos de alerta, plataformas de monitoramento de medidas protetivas — tudo isso existe, mas muitas vezes opera de forma fragmentada, com UX pobre, baixa adoção e, pior, brechas de segurança que podem expor ainda mais a vítima. A engenharia de software tem uma dívida técnica com esse campo, e pagá-la exige mais do que boa vontade: exige decisões arquiteturais conscientes.
O ciclo vicioso entre usabilidade e segurança
Um dos maiores gargalos em sistemas voltados à proteção de vítimas é o trade-off entre facilidade de uso e confidencialidade. Imagine uma mulher que precisa acionar um botão de pânico no celular enquanto o agressor está ao lado. Se o app exigir autenticação biométrica ou senha, o tempo de resposta pode ser fatal. Por outro lado, se o acesso for demasiado simples, o agressor pode usar o mesmo dispositivo para desativar alertas ou rastrear a vítima. Já vi equipes de produto ignorarem esse problema por acharem que "o usuário sempre terá o celular em mãos" — uma suposição ingênua em contextos de violência doméstica, onde o controle do aparelho muitas vezes não está com a vítima.
Uma abordagem mais robusta envolve o uso de canais secundários de comunicação: um smartwatch, um fone Bluetooth emparelhado discretamente, ou até mesmo um comando de voz ativado por uma palavra-chave que o agressor desconhece. Do ponto de vista de infraestrutura, isso implica projetar sistemas com baixa latência (menos de 500 ms entre ativação e envio do alerta), tolerância a falhas de rede e, principalmente, criptografia de ponta a ponta nos dados de localização e áudio. Não é trivial, mas é tecnicamente factível — desde que a prioridade de produto esteja alinhada com a realidade do usuário.
Evidências digitais e a cadeia de custódia
Outro ponto sensível é a coleta de provas. Em muitos casos, a vítima só consegue denunciar depois de agressões repetidas, e as evidências digitais — mensagens, fotos, logs de localização — são cruciais para a responsabilização do agressor. Contudo, se o sistema não garantir a integridade e a imutabilidade desses registros, a defesa pode questionar a autenticidade. Aqui, tecnologias como blockchain ou hashes encadeados podem ser interessantes, mas trazem um custo computacional e de complexidade que muitas vezes inviabiliza a adoção por órgãos públicos com orçamento apertado.
Minha experiência com sistemas distribuídos me mostrou que a simplicidade vence na maioria dos cenários. Em vez de blockchain, uma solução prática é armazenar logs em um banco imutável (como um append-only store) com assinatura digital gerada no dispositivo da vítima antes do envio. Combinado com um timestamp de um NTP confiável e a geolocalização, isso cria uma trilha de auditoria sólida o suficiente para sustentar um processo judicial. O desafio real não é técnico, mas de governança: quem mantém as chaves? Como garantir que a vítima não perca o acesso? Tudo isso precisa ser documentado em um plano de recuperação de desastres tão rigoroso quanto o de qualquer sistema financeiro.
Inteligência artificial: ferramenta ou risco?
A tentação de usar IA para prever riscos de reincidência ou detectar padrões de violência em mensagens é grande, mas precisa vir acompanhada de uma análise ética rigorosa. Modelos de machine learning treinados com dados históricos de boletins de ocorrência tendem a reproduzir vieses institucionais — por exemplo, subnotificação em comunidades periféricas ou maior escrutínio sobre grupos raciais específicos. Já vi times de dados celebrarem acurácia de 90% sem perceber que o modelo estava, na prática, criminalizando comportamentos que não deveriam ser considerados suspeitos.
Uma alternativa que tenho defendido em conversas com colegas é o uso de sistemas baseados em regras explícitas, desenhadas em conjunto com psicólogos e assistentes sociais, em vez de caixas-pretas estatísticas. O custo de um falso positivo — uma intervenção policial desnecessária que coloca a vítima em risco — é muito alto para justificar um modelo preditivo não interpretável. Se formos usar IA, que seja para tarefas mais seguras, como transcrição de áudios de denúncia com privacidade garantida (processamento local no dispositivo, nunca na nuvem) ou sumarização automatizada de relatos para agilizar o atendimento.
Privacidade como requisito não funcional
Projetar um sistema para vítimas de violência doméstica significa tratar a privacidade como um requisito não funcional de primeira classe — ao lado de desempenho e escalabilidade. Isso inclui desde a escolha do provedor de nuvem (preferencialmente com certificações como SOC 2 e ISO 27001) até a segmentação de dados: o histórico de localização da vítima não deve ficar no mesmo banco que suas mensagens pessoais, e o acesso a esses dados precisa ser registrado em um log de auditoria imutável. Mais importante ainda: a vítima deve poder exportar e deletar seus dados a qualquer momento, sem depender de solicitação judicial. Isso não é apenas uma exigência da LGPD; é um direito existencial.
Na prática, isso significa implementar controles de acesso baseados em atributos (ABAC) e criptografia em repouso e em trânsito com chaves gerenciadas pela própria vítima — algo que muitos sistemas comerciais ainda tratam como "nice to have". Engenheiros que trabalham com produtos digitais precisam internalizar que, nesse contexto, um vazamento de dados não é apenas uma multa: pode ser a diferença entre a vida e a morte de uma pessoa.
Integração com o ecossistema de justiça
De nada adianta um app perfeito se a delegacia não recebe o alerta ou se o juiz não consegue acessar as evidências. A interoperabilidade entre sistemas é um dos maiores calcanhares de Aquiles das iniciativas de tecnologia social no Brasil. Cada estado tem sua própria plataforma de segurança pública, muitas vezes legada, com APIs precárias ou inexistentes. Projetar uma camada de integração que normalize esses dados e os torne consumíveis por sistemas modernos é um trabalho de engenharia que demanda paciência e diplomacia — mais do que código.
Já atuei em projetos de interoperabilidade governamental e posso afirmar: o maior desafio não é técnico, é político e organizacional. Mas há um caminho viável: adotar padrões abertos como OpenAPI e JSON Schema desde o início, criar contratos de serviço versionados e oferecer client libraries em linguagens populares para facilitar a adoção. Sem isso, qualquer solução digital para violência doméstica será uma ilha — bonita, mas inútil.
Onde a indústria de tecnologia pode — e deve — agir
Não estou sugerindo que todo engenheiro de software largue seu projeto atual para construir um app de denúncia. Mas acredito que podemos aplicar as mesmas práticas de engenharia que usamos em sistemas financeiros ou de e-commerce para resolver problemas sociais complexos. Isso começa com a escolha consciente de onde alocar tempo e recursos. Se você trabalha em uma plataforma de mensagens, por exemplo, pode defender a implementação de criptografia de ponta a ponta — não apenas porque é um bom negócio, mas porque vítimas de violência dependem da confidencialidade da comunicação para buscar ajuda.
Se atua com IA, questione os dados de treino e exija métricas de equidade antes de colocar um modelo em produção. Se lidera produto, inclua personas de vítimas em suas pesquisas e testes de usabilidade. A tecnologia nunca será neutra; ela amplifica as intenções de quem a projeta. Cabe a nós, engenheiros, garantir que essas intenções incluam proteção, não apenas lucro.
A engenharia de software não vai acabar com a violência doméstica. Mas pode, sim, reduzir barreiras para que vítimas como Giullia Falcão tenham canais seguros de denúncia, evidências robustas para a justiça e, acima de tudo, a certeza de que a tecnologia está do lado certo. O resto é uma questão de prioridade.