SaneIA Água

A SaneIA se conecta às fontes de dados que o operador já possui — planilhas, sistemas corporativos, bancos, APIs ou data lakes — e cruza informações operacionais, históricas, hidráulicas e territoriais para apoiar previsibilidade, identificar padrões e priorizar onde investigar e agir primeiro. A redução de perdas é o primeiro domínio de aplicação; o dashboard é apenas uma das formas possíveis de consumir esses resultados.

Proposta em pré-incubação pelo Programa Startup UFT (INOVATO 2026). O MVP demonstrativo e o protótipo interativo usam dados 100% sintéticos. Nenhum dado exibido representa clientes, municípios ou concessionárias reais.

O problema não é só medir perdas

39,53% da água tratada no Brasil é perdida antes de chegar ao consumidor, segundo o Estudo de Perdas de Água 2026, publicado pelo Instituto Trata Brasil em parceria com a GO Associados, com dados do SINISA (ano-base 2024). O indicador é nacional e não representa nenhum município, concessionária ou organização específica.

As perdas decorrem de vazamentos e extravasamentos, falhas operacionais, erros de medição, consumos não autorizados, inconsistências cadastrais e informações ausentes ou incompletas. Na operação, os sinais estão espalhados em fontes diferentes: ordens de serviço, cadastro de rede e ativos, pressão e telemetria, histórico de vazamentos e registros de campo.

O resultado típico: as equipes sabem que há problemas, mas nem sempre sabem onde agir primeiro, por qual motivo e com qual serviço. O desafio também não é o mesmo para todos os operadores:

O gargalo pode estar tanto na organização dos dados quanto na capacidade de extrair inteligência deles.

O que aprendemos com o setor

Em 2026, o conceito foi discutido com profissionais das áreas de operação, eletromecânica, analytics e inteligência de dados de uma concessionária de saneamento. O principal aprendizado: antes da gestão de perdas, existe a gestão de serviços. Ordens de serviço, histórico de intervenções, características da rede e condições hidráulicas formam a base para análises mais inteligentes — e passaram a orientar as variáveis do protótipo.

Com isso, a pergunta central mudou de "Onde há perda?" — uma visão próxima de dashboard, com indicadores, alertas e mapas — para "Onde atuar primeiro?": priorização explicável baseada em serviços, recorrências, rede, pressão, telemetria e contexto de campo.

Uma segunda rodada de questionamentos técnicos mostrou que organizações maduras podem já ter bons painéis. A oportunidade da SaneIA está principalmente na camada de tratamento, correlação e inteligência que antecede os dashboards, e não na visualização em si.

Há interesse em continuar a validação em nova reunião técnica. Isso ainda não configura parceria, endosso, cliente ou piloto contratado.

Para quem

• SAAEs e autarquias municipais, muitas vezes com maturidade digital inicial.
• Prefeituras e departamentos municipais responsáveis pelo abastecimento.
• Companhias estaduais e regionais, com múltiplos sistemas corporativos e grande volume de dados.
• Concessionárias privadas, com data lakes, lakehouses e plataformas corporativas.
• Equipes de perdas e eficiência operacional, responsáveis por indicadores, metas e priorização de investimentos.
• Equipes de manutenção e campo, que executam inspeções, reparos e registram resultados.
• Equipes de analytics e gestão de serviços, que tratam dados e acompanham ordens de serviço.

A forma de integração varia conforme a maturidade de cada operador — de planilhas exportadas a conectores com bancos, APIs e plataformas corporativas.

A solução: seis capacidades integradas

A SaneIA não é definida por um único algoritmo ou fonte de dados: é uma arquitetura que conecta, trata e transforma dados operacionais em sinais de decisão.

1. Conexão com fontes de dados — arquivos, bancos, APIs, data lakes/lakehouses e sistemas corporativos do operador.
2. Qualidade e preparação — validação, padronização e score de confiabilidade das informações antes da análise.
3. Engenharia e correlação de atributos — cruzamento de sinais operacionais, históricos, hidráulicos, geográficos e de serviços.
4. Inteligência operacional — modelos estatísticos e de Machine Learning escolhidos conforme o caso de uso, para detectar padrões, anomalias e prioridades.
5. Entrega e integração dos resultados — para os sistemas, BI ou dashboards que o operador já usa, ou pela interface própria da SaneIA.
6. Feedback operacional e aprendizado — os resultados de campo retornam ao histórico e apoiam a recalibração dos modelos.

Fluxo: Fontes (OS, rede, ativos, pressão, telemetria, GIS/KMZ, registros de campo) → Análise (recorrência, risco e anomalias) → Priorização (score com fatores explicáveis e confiança dos dados) → Ação (serviço sugerido: geofone, validação cadastral, pressão ou inspeção de campo).

Casos de uso em validação

Três hipóteses de valor, ainda sem resultados comprovados em produção:

• Previsibilidade operacional — identificar regiões, trechos, ativos ou contextos com maior risco de recorrência ou ocorrência futura, quando os dados históricos permitirem.
• Perdas e comportamentos anormais — identificar combinações de sinais que merecem investigação por possível anomalia ou perda acima do esperado.
• Potencial de produtividade — priorizar atividades, regiões ou ocorrências em que a atuação da equipe gere maior impacto.

Arquitetura de integração

A SaneIA é independente das fontes e dos sistemas de saída (source-agnostic e output-agnostic): conecta-se às fontes disponíveis e entrega resultados para o que o operador já utiliza.

• Fontes: arquivos, APIs, bancos, lakehouse/data lake, telemetria, GIS e ordens de serviço.
• Camada de integração: conectores, credenciais controladas, validação de esquema e sincronização.
• SaneIA Intelligence Engine: preparação dos dados, engenharia de atributos, modelos analíticos, explicabilidade e priorização.
• Resultados: scores, alertas, previsões, criticidade e produtividade operacional.
• Consumo: BI, API, GIS, sistemas corporativos ou o dashboard próprio da SaneIA.

Nenhum dos caminhos é comercialmente superior ao outro: a integração é escolhida conforme a realidade de cada operador e validada em cada piloto.

Pipeline de dados e Machine Learning

1. Fontes de dados — leituras de hidrômetros, histórico de consumo, cadastro de ligações, setores e regiões, ordens de serviço, vazamentos confirmados, idade e material da rede, pressão hidráulica e dispositivos de controle, tipo de solo, obras externas próximas e telemetria, quando disponível.
2. Ingestão e integração — CSV/XLSX, APIs, bancos relacionais, data lakes, sistemas de ordens de serviço e geodados, com sincronização batch ou incremental.
3. Qualidade e preparação — checagem de campos, dados ausentes, duplicidades, inconsistências, normalização de unidades e score de confiabilidade.
4. Transformação — consolidação entre fontes, janelas temporais, correlação de sinais e engenharia de atributos por setor, ativo, trecho ou serviço.
5. Inteligência operacional — modelos estatísticos e de ML, análise temporal e de recorrência, detecção de anomalias, modelos preditivos quando houver dados adequados e priorização explicável.
6. Resultados — scores, alertas, previsões, anomalias, rankings e recomendações explicáveis.

Os modelos não substituem a análise humana: atuam como triagem, indicando o que merece investigação e explicando os fatores que influenciaram cada prioridade.

A frequência de processamento é orientada pelo SLA e pela natureza de cada dado. Tempo real não é pré-requisito:

Integração, segurança e implantação

Requisitos arquiteturais previstos para produção — não são funcionalidades já implementadas nem certificações obtidas.

Princípios de integração: mínimo privilégio de acesso, preferencialmente somente leitura, credenciais técnicas dedicadas, contratos e esquemas de dados definidos previamente, sincronização controlada, segregação por cliente e rastreabilidade.

Segurança esperada: TLS em trânsito, criptografia em repouso, gestão segura de segredos, controle de acesso, segregação lógica entre clientes, logs e auditoria, minimização de dados, anonimização/pseudonimização quando aplicável, política de retenção e observância à LGPD.

Opções de implantação em avaliação:

• SaaS gerenciado pela SaneIA, com integração controlada às fontes do operador.
• Ambiente isolado ou dedicado, com infraestrutura segregada conforme requisitos de segurança e volume.
• Ambiente controlado do cliente, quando técnica e comercialmente viável.

Primeiro piloto (MVP)

O piloto será incremental, a partir de um recorte operacional delimitado e de um conjunto mínimo de fontes confiáveis, para testar se o modelo consegue distinguir regiões, trechos ou casos com diferentes níveis de prioridade:

1. Recorte operacional definido junto ao operador.
2. Conjunto mínimo de fontes — por exemplo, OS, pressão, idade/material e geografia.
3. Integração controlada com as fontes selecionadas.
4. Tratamento e qualidade — checagem, padronização e confiabilidade dos dados.
5. Engenharia de atributos a partir dos dados brutos.
6. Modelo analítico — estatística e/ou Machine Learning, conforme o caso de uso.
7. Validação com campo — resultados avaliados por especialistas e confrontados com ocorrências reais.

Fatores conceituais do radar operacional: idade da rede e dos ativos, material da tubulação, pressão hidráulica, histórico de ordens de serviço, recorrência de ocorrências, vazamentos confirmados, tipo de solo, obras externas próximas, possíveis danos mecânicos, dispositivos de controle de pressão, telemetria e qualidade dos dados. Nem todos estão implementados no protótipo atual, e nem todos serão exigidos em cada piloto.

Camada geográfica (opcional): camadas existentes, incluindo KML/KMZ, podem relacionar trechos da rede a atributos operacionais. Formatos propostos: CSV, XLSX, KML, KMZ e GeoJSON.

Em produção, a integração não deve depender de importações manuais recorrentes: a arquitetura prevê sincronização controlada com as fontes corporativas, sem substituir os sistemas operacionais existentes.

Confiabilidade e explicabilidade

A priorização considera não apenas o risco operacional, mas também a qualidade das informações que sustentam a análise. A SaneIA pode identificar registros duplicados, campos obrigatórios ausentes, coordenadas ausentes, leituras zeradas ou muito discrepantes, dados antigos e cobertura territorial incompleta.

Cada alerta deve trazer justificativas compreensíveis para que a equipe avalie a recomendação antes de agir. Exemplo demonstrativo, com dados sintéticos — Ligação 004821, score de anomalia 96:

A IA da SaneIA não é um único modelo. Ela pode combinar estatística, regras de domínio e Machine Learning, escolhidos conforme o caso de uso e os dados disponíveis. O valor próprio está na arquitetura, no pipeline de saneamento de dados, na engenharia de atributos, na calibração, na explicabilidade e no ciclo de feedback. Modelos de linguagem (LLMs), se usados, têm papel auxiliar — não são o núcleo da inteligência operacional.

Formas de consumo

O motor analítico é desacoplado da visualização. Os resultados — scores, alertas, previsões, anomalias, rankings, prioridades, indicadores derivados e recomendações explicáveis — podem ser consumidos por:

• API, JSON ou arquivos estruturados;
• webhooks e eventos (arquitetura possível);
• BI já utilizado pelo operador;
• GIS e mapas;
• sistemas de gestão e de ordens de serviço;
• dashboard próprio da SaneIA (opcional).

Protótipo interativo

O protótipo interativo mostra como diferentes fontes podem ser consolidadas, avaliadas quanto à qualidade e transformadas em prioridades explicáveis:

• Qualidade e consolidação dos dados;
• Radar de prioridades, que ranqueia setores e compara alertas;
• Explicabilidade por setor, com os fatores do score e a ação sugerida;
• Simulador de critérios, que mostra como os pesos de prioridade mudam a fila operacional;
• Ordens de serviço simplificadas, vinculadas aos alertas.

Indicadores, ocorrências, scores e ações do protótipo são ilustrativos e não representam operações reais.

Um ciclo, não um retrato único

Dados → Inteligência → Priorização → Ação → Resultado → Aprendizado → Dados.

Sistemas de BI organizam e apresentam informações. A SaneIA adiciona uma camada analítica que transforma esses dados em sinais de decisão — onde investigar primeiro e quais fatores contribuem para a criticidade. Ela complementa o ecossistema existente, sem exigir substituí-lo, e seus pesos e modelos evoluem conforme a realidade de cada rede e os resultados das intervenções.

Perfis de uso previstos: gestor (indicadores e regiões críticas), analista (qualidade dos dados e revisão de alertas), equipe de campo (ordens de serviço e registro de resultados) e administrador (usuários, parâmetros e integrações).

Escopo do MVP

Faz parte do escopo demonstrado:

• ingestão de arquivos CSV/XLSX como uma das formas de entrada;
• validação, padronização e score de confiabilidade dos dados;
• indicadores operacionais consolidados;
• modelos estatísticos e de ML para anomalias e priorização;
• ranking por ligação, trecho ou setor, com explicação dos fatores;
• dashboard demonstrativo e ordens de serviço simplificadas;
• arquitetura conceitual de integração;
• uso exclusivo de dados públicos e sintéticos nas demonstrações.

Não faz parte, por ora: esgotamento sanitário no primeiro ciclo, conectores universais prontos para qualquer sistema legado, substituição de sistemas ou BI do operador, decisões autônomas sem validação humana, garantia de previsão de rompimentos, streaming obrigatório, sensores/IoT próprios, aplicativo móvel nativo, faturamento de usuários finais, dados pessoais não anonimizados, resultados comprovados antes de um piloto e certificações de segurança ainda não obtidas.

Validação e próximos passos

Hipóteses a validar: quais dados os operadores possuem e em quais sistemas; formatos e granularidade; como perdas são classificadas e inspeções priorizadas hoje; requisitos de integração, segurança e proteção de dados; indicadores que geram valor percebido; e interesse em um piloto controlado.

Próxima validação: selecionar, com profissionais do setor, um problema operacional delimitado e um conjunto mínimo de dados reais. A hipótese inicial é priorizar trechos ou regiões com maior risco de recorrência de vazamentos, combinando histórico de serviços, idade/material da rede e pressão hidráulica.

Plano para a pré-incubação

Entrega esperada: MVP com uso demonstrável, proposta de valor validada, arquitetura de integração e plano comercial para piloto.

Roadmap

1. Problema e hipóteses iniciais — entrevistas exploratórias com potenciais operadores.
2. Protótipo sintético e validação setorial — duas rodadas técnicas com profissionais do setor.
3. Caso de uso e contrato mínimo de dados — problema delimitado definido com o operador.
4. Integração controlada e baseline analítico — dados reais em ambiente controlado e comparação com o histórico operacional.
5. Ciclo de feedback e expansão — retorno dos resultados de campo, novos conectores e casos de uso.
6. Novos domínios (futuro) — incluindo esgotamento sanitário, conforme os aprendizados.

Modelo de negócio preliminar

Entrada B2B com implantação enxuta, começando por piloto operacional. Clientes iniciais: concessionárias, SAAEs, autarquias e prestadores municipais de abastecimento.

Hipóteses comerciais em avaliação:

• SaaS com licença mensal por operação ou município e implantação assistida;
• assinatura do SaneIA Intelligence Engine, proporcional a porte, volume de dados ou escopo;
• implantação, configuração inicial e conectores específicos sob demanda;
• dashboard próprio como camada opcional;
• suporte e capacitação das equipes;
• projeto piloto com escopo e prazo definidos;
• execução em ambiente dedicado ou do cliente, quando viável;
• possibilidade futura de contratação pública.

Impacto esperado

Direções esperadas, ainda sem números validados em campo:

• Econômico: melhor alocação das equipes, priorização de inspeções, menos retrabalho e deslocamentos improdutivos, identificação mais rápida de regiões críticas e melhor uso do orçamento operacional.
• Ambiental: redução potencial do desperdício de água tratada e melhor uso de energia e recursos na produção e distribuição.
• Social: maior confiabilidade do abastecimento, potencial redução de interrupções e melhor uso de recursos destinados à infraestrutura essencial.

A SaneIA está em fase de estruturação e busca validar suas hipóteses com profissionais, municípios, SAAEs, autarquias e prestadores de abastecimento. Todo o conteúdo tem caráter demonstrativo e não representa clientes, contratos ou resultados já obtidos. Fonte setorial: Instituto Trata Brasil e GO Associados, Estudo de Perdas de Água 2026, com dados do SINISA 2024.