Qual o verdadeiro custo de economizar milhões em despesas de viagem? A notícia de que uma empresa cortou R$ 75 milhões aplicando inteligência artificial na gestão de viagens corporativas circulou como exemplo de sucesso operacional. Mas, por trás dos números, existe uma camada que raramente aparece nos comunicados de imprensa: a coleta, o processamento e o armazenamento de dados pessoais altamente sensíveis. Cada reserva de voo, cada noite de hotel, cada deslocamento gera um rastro digital que, mal gerenciado, transforma-se em um passivo de privacidade.
Não estou aqui para minimizar o feito financeiro — ele é real e admirável. O que quero discutir é o dilema que todo engenheiro de produto enfrenta ao projetar sistemas baseados em inferência comportamental: como extrair valor sem expor indivíduos? Como calibrar modelos preditivos sem criar perfis que violem a LGPD ou, pior, sem gerar desconforto e desconfiança nos próprios colaboradores? A resposta não está apenas em compliance, mas em uma reengenharia da arquitetura de dados desde o primeiro commit.
A gestão de viagens corporativas é um terreno fértil para a inteligência artificial porque envolve variáveis voláteis — tarifas aéreas, hospedagem, logística — e um volume enorme de transações. No entanto, diferente de outros problemas de otimização, aqui o dado carrega identificadores diretos: CPF do viajante, departamento, motivo da viagem, datas, locais. Qualquer modelo treinado nesses dados pode, sem querer, aprender a associar padrões de gasto a indivíduos específicos, criando um risco real de reidentificação.
O Dilema dos Dados de Viagem: Eficiência vs. Privacidade
Viagens corporativas são, por natureza, um gerador massivo de dados pessoais. Cada solicitação de aprovação contém não só o valor, mas a justificativa textual (“reunião com cliente X em São Paulo”), o que revela relações comerciais e estratégias de negócio. Quando um sistema de IA sugere a tarifa mais econômica, ele precisa cruzar dados históricos do viajante — antecedência de compra, preferência de horário, classe — com dados de mercado. Esse cruzamento é o ponto crítico.
O problema técnico central é que a otimização de custos exige granularidade. Quanto mais individualizado o modelo, melhor a recomendação. Porém, quanto mais individualizado, maior a exposição. Em um projeto que liderei para uma empresa de médio porte, a equipe de engenharia propôs usar embeddings de colaboradores como features. Só depois de uma revisão de privacidade percebemos que isso criava um vetor de ataque: com acesso ao modelo, um adversário poderia inferir hábitos de viagem de executivos. Abandonamos a abordagem e migramos para features agregadas por cargo e região, sacrificando 7% de acurácia, mas eliminando o risco de perfilamento.
Esse trade-off entre precisão e privacidade raramente é discutido nos artigos de case de sucesso. A narrativa dominante é “IA corta custos”. A realidade operacional é que cada feature precisa ser questionada: “Esse dado é essencial para a recomendação ou posso substituí-lo por um indicador anonimizado?”.
Arquitetura de Dados com Privacidade desde a Concepção
A fundação de qualquer iniciativa de IA em despesas é um repositório de dados unificado. Mas a forma como esse repositório é projetado define os limites da privacidade. Em vez de um data lake onde todos os dados brutos ficam disponíveis, adotei em projetos recentes uma arquitetura em camadas: uma camada de ingestão com pseudonimização imediata (substituição de CPF por hash não reversível), uma camada de agregação para treinamento de modelos (apenas médias, percentis e contagens) e uma camada de serviço que só consulta dados identificáveis sob autorização explícita e com logging de auditoria.
Na prática, isso significa que o motor de recomendação nunca vê o nome do colaborador. Ele opera sobre um identificador anônimo e features derivadas como “senioridade”, “unidade de negócio” e “histórico de antecedência de compra” — nunca o dado bruto. Para a aprovação automática, sim, é necessário saber quem está viajando e para onde, mas esse fluxo é isolado em um microsserviço com controles de acesso granulares. [INSERIR DIAGRAMA DE ARQUITETURA COM CAMADAS]
Essa separação não é apenas boa prática de engenharia; é uma exigência da LGPD para finalidades distintas. A finalidade “otimizar custos agregados” não requer dados pessoais. A finalidade “aprovar viagem” requer. Misturar as finalidades no mesmo pipeline é a receita para um vazamento ou para uma autuação.
Engenharia de Features sem Expor o Indivíduo
A tentação de usar dados ricos é enorme. Quanto mais features, melhor o modelo. Mas features como “frequência de viagens do colaborador nos últimos 12 meses” ou “valor médio gasto por mês” são identificadoras quando combinadas com outras variáveis. Em um experimento com dados públicos de despesas, um colega demonstrou que com apenas três atributos (cargo, departamento e mês de viagem mais caro) era possível reidentificar 40% dos registros.
Para evitar isso, adotamos duas estratégias complementares. A primeira é a anonimização estatística: em vez de armazenar o valor exato da despesa, usamos faixas (R$ 500-1000, R$ 1000-2000) e aplicamos ruído laplaciano nos totais antes de alimentar o modelo. Isso preserva a correlação sem expor o valor real. A segunda é a diferenciação entre treinamento e inferência: o modelo é treinado com dados agregados por grupo (ex: média do departamento), mas na hora da recomendação, features individuais são acessadas sob um contrato de uso restrito que registra cada consulta.
Essa abordagem não é trivial de implementar. Exige uma camada de governança de features (feature store) que armazena metadados de privacidade — tipo de dado, finalidade permitida, nível de agregação. No projeto que mencionei, criamos um sistema de tags: “agregado”, “pseudonimizado”, “identificável”. Qualquer modelo que tentasse usar uma feature “identificável” sem autorização explícita disparava um alerta no pipeline de CI/CD. Foi um trabalho extra de três sprints, mas evitou que um modelo de recomendação fosse treinado com dados pessoais sem o devido consentimento.
Governança e Transparência Algorítmica como Diferencial de Produto
Muitas equipes tratam privacidade como um empecilho, algo que freia a inovação. Eu vejo como um diferencial competitivo, especialmente em um produto B2B que precisa ser auditado pelos clientes. Quando um diretor financeiro pergunta “como o sistema recomenda essa tarifa?”, a resposta não pode ser um black box. É preciso mostrar que a recomendação se baseia em dados agregados de mercado e na política da empresa, não no perfil individual do viajante. Essa transparência gera confiança e acelera a adoção.
Em um sistema de aprovação automatizada, a lógica híbrida (regras explícitas + IA) oferece um caminho natural para a transparência. Regras de negócio são compreensíveis: “viagens abaixo de R$ 1.000 são aprovadas automaticamente”. Já a decisão da IA precisa ser explicável. Em vez de um score opaco, implementamos uma interface que informa: “Essa viagem foi aprovada automaticamente porque o custo está 15% abaixo da média da rota no período e o viajante tem histórico de compras econômicas.” O usuário entende o porquê, e o gestor de compliance pode auditar.
Essa transparência também serve para corrigir vieses. Se o modelo sistematicamente negar viagens de mulheres para determinada região (devido a dados históricos enviesados), a equipe de produto precisa detectar e ajustar. A privacidade não é apenas sobre não vazar dados; é sobre não perpetuar discriminações baseadas em padrões extraídos de dados sensíveis.
Os Riscos Reais que Encontrei na Prática
O maior erro que cometi em um projeto similar foi subestimar o lag de dados combinado com a volatilidade de contexto. Treinamos um modelo com dados de 2022, mas em 2023 os preços dos hotéis em uma capital dispararam devido a um evento. O modelo continuou recomendando tarifas antigas, e como essas recomendações eram personalizadas (baseadas no histórico de gasto do colaborador), geraram comparações injustas: um gerente que viajava para a mesma cidade há dois anos recebia uma sugestão muito abaixo do preço real, criando frustração e desconfiança no sistema. O problema não era só operacional – era de privacidade, porque o modelo expunha indiretamente o quanto cada colaborador “costumava gastar”.
Outro risco é a “otimização excessiva” em detrimento da experiência. Se o sistema sempre sugerir o voo mais barato, mesmo que com conexão longa, o viajante pode burlar o sistema e comprar fora da plataforma. Isso gera dados fora do radar, quebram a acurácia dos modelos futuros e, pior, criam um rastro de despesas não gerenciadas. A solução que encontramos foi incorporar uma métrica de “custo de fricção” no modelo: quando a economia projetada é inferior a um limiar (ex: R$ 50), a recomendação prioriza a conveniência. Isso manteve a adesão alta sem comprometer o controle de privacidade, pois a decisão não se baseava em dados pessoais, mas em regras parametrizáveis.
Por fim, não posso deixar de mencionar o risco de violação da LGPD em caso de vazamento. Dados de viagem revelam muito sobre a vida pessoal: onde o colaborador esteve, com quem se encontrou (se houver integração com agenda), qual o padrão de deslocamento. Um incidente de segurança nesse contexto pode gerar multas de até 2% do faturamento e danos reputacionais severos. Por isso, a arquitetura deve incluir criptografia em repouso e em trânsito, controles de acesso baseados em função (RBAC) e um plano de resposta a incidentes específico para dados de viagem.
Lições para Quem Constrói Produtos de IA com Dados Sensíveis
A primeira lição é: comece pela privacidade, não a coloque no final. Em vez de fazer um MVP que coleta tudo e depois tentar anonimizar, defina desde o início quais variáveis são estritamente necessárias e como serão tratadas. Em um projeto que consultoria, a equipe de produto queria armazenar motivo de viagem em campo livre (texto). Isso abria uma porteira enorme para dados sensíveis (ex: “tratamento médico”, “visita a cliente confidencial”). Sugerimos substituir por uma lista fechada de categorias pré-aprovadas pelo RH, reduzindo drasticamente o risco.
A segunda lição é envolver o DPO (Data Protection Officer) ou o time jurídico no processo de engenharia de features. Eles podem ajudar a identificar quais combinações de dados criam riscos de reidentificação. Em uma reunião, o jurídico apontou que guardar o IP do colaborador no momento da solicitação de viagem poderia revelar sua localização geográfica precisa, algo desnecessário para a aprovação. Removemos esse campo do pipeline de IA e mantivemos apenas no log de auditoria com retenção limitada.
A terceira lição é monitorar não só a acurácia do modelo, mas também a equidade. Se a taxa de aprovação automática for muito diferente entre departamentos ou cargos, pode ser um sinal de viés ou de uso indevido de dados pessoais. Implementar dashboards de privacidade (quantas consultas a dados identificáveis foram feitas, por quem, para qual finalidade) é tão importante quanto medir o ROI em custos.
Para equipes de produto e engenharia, a mensagem final é clara: é possível cortar custos com IA sem violar a privacidade, desde que você projete o sistema com essa premissa desde o primeiro commit. O caso dos R$ 75 milhões não precisa ser um exemplo de trade-off – pode ser um exemplo de como fazer certo, com arquitetura em camadas, pseudonimização rigorosa e transparência algorítmica. O futuro da gestão de despesas inteligente não está em coletar mais dados, mas em extrair mais valor dos dados que você já tem, com responsabilidade.