Keynote — Plenária de Abertura — Water Loss 2026
Keynote sobre como utilities podem separar o hype da realidade ao adotar Inteligência Artificial em operações de água — o que funciona, o que é exagero, e onde IA gera impacto mensurável em redução de perdas.
Sobre o palestrante
Keynote Speaker — Plenária de Abertura IWA Water Loss 2026. Engenheiro elétrico, de computação e sistemas, com background em IA e machine learning, atuando há anos em sistemas wireless aplicados a water utilities, baseado em Cyprus (EUROCY). Posiciona-se publicamente como "technical expert, não de domínio" — alguém que constrói as ferramentas, mas precisa do operador para entender onde aplicá-las.
Formação em três áreas convergentes — engenharia elétrica, ciência da computação e systems engineering — com especialização em IA e aprendizado de máquina. Trabalha há anos em sistemas wireless para utilities de água, integrando sensores, modelos hidráulicos e algoritmos. Posição privilegiada para julgar onde IA agrega valor real e onde é apenas marketing.
AI/MLWireless SystemsNo keynote "Demystifying AI: Cutting through hype and myths to achieve real impact" George defendeu uma reformulação radical: parar de começar pela tecnologia, começar pelo problema. Critica utilities europeias que pedem "to use AI" antes de definir a dor que pretendem resolver. Posicionamento incomum em um setor saturado de promessas tecnológicas.
Pain FirstHype vs Reality"If we start with technology — 'we want to use AI' — we are missing the goal."
Tese da palestra
A indústria de água precisa parar de começar pela tecnologia e começar pelo problema. Utilities chegam pedindo IA quando o problema real é redução de perdas, gerenciamento de pressão, infraestrutura envelhecida. George defende inverter a sequência: identificar a dor, formular o caso de uso, definir métricas mensuráveis — e SÓ ENTÃO escolher a ferramenta, que pode ou não ser IA.
A sequência correta começa fora da tecnologia. Identificar a dor operacional concreta (perdas, pressão, falhas), formular um caso de uso isolável, definir um outcome mensurável. A ferramenta — regra, ML, LLM, planilha, modelo hidráulico — vem depois, decidida pela natureza do problema, não pela moda.
Use Case FirstAI StrategyDispositivos rotulados como "smart" são, em sua maioria, apenas coletores de dados. Inteligência verdadeira exige raciocínio sobre dados novos e capacidade de agir no ambiente. O valor não está no sensor — está no que se faz com a informação que ele entrega. Cuidado com vocabulário inflacionado.
VocabularyReasoning"Combining water domain with whatever technology, always to make the world a better place to live for people." O ponto não é a tecnologia em si — é o resultado para o operador, o cliente final e o sistema hídrico. IA é meio, não fim. Decisão técnica precede sempre a decisão de tool.
OutcomeTool Agnostic"It doesn't matter if you call it AI or not. The important thing is focusing on the problem."
Dados apresentados
"We should not trust LLMs for critical decisions because they don't have knowledge of what's happening in real time and they're not accountable."
Abordagem / Metodologia
George traçou três famílias de ferramentas sob o "guarda-chuva da IA". Cada uma tem domínio próprio; misturá-las sem critério é o erro mais comum em projetos de utilities. A metodologia é simples: a natureza do problema escolhe a família, não o oposto.
"If pressure < threshold then activate" — a expertise do operador codificada em regras explícitas. Funciona em situações conhecidas, falha quando aparece algo não-modelado. Domínio: quando a expertise é codificável e o sistema é tratável. Cálculo de NRW, night flow, projeção de pressões — tudo isso é matemática hidráulica clássica, não precisa de IA.
RulesDeterminísticoAlimentar o sistema com dados e deixar um modelo aprender as relações — de uma reta y=ax+b a redes neurais com milhões de parâmetros. Domínio: quando o sistema é complexo demais para regras explícitas mas há dados em volume suficiente. Sensor placement ótimo, classificação de signatures de falha, otimização em alta dimensão.
MLData-DrivenCodificação estatística de como humanos comunicam — "language is just a codification of our thoughts". Não conhecem o sistema em tempo real, não são accountable. Domínio: camada de interação e orquestração — entender intenção do operador, dialogar, escolher a tool certa entre os clássicos verificados.
LLMsOrchestrationCasos / Aplicações
George ilustrou a decisão regra-vs-ML com casos clássicos do setor de água. A escolha não é técnica abstrata — é prática, ditada pela complexidade do sistema e pela disponibilidade de dados.
Abordagem rule-based: "se a variância de pressão na área supera um limiar, coloque um sensor". Funciona em situações conhecidas, falha quando aparece algo não-modelado. Abordagem ML: alimentar o sistema com diversas combinações de vazamentos, posições candidatas e dados de operação, deixar o modelo aprender as relações e devolver as posições ótimas. ML vence quando o sistema é complexo demais para regras explícitas — desde que haja dados em volume.
Sensor PlacementML vs RulesCálculo de água não faturada, estimativas de night flow, projeção de pressões e vazões em pontos não-medidos — tudo isso é matemática hidráulica clássica. Aplicar IA aqui é ruído. Usar IA onde realmente vale: detecção de signatures de vazamento, classificação de falhas, otimização em alta dimensão. Decisão técnica precede sempre escolha de tool.
NRWHydraulic MathA arquitetura recomendada: LLM entende a intenção do operador via diálogo natural, mas decisões são tomadas pelas ferramentas tradicionais — modelos hidráulicos, detectores de vazamento, otimizadores. "The LLM decides what tools to use and orchestrates them." Combina a usabilidade conversacional com a confiabilidade dos clássicos. Para utilities querendo entrar agora em IA, é a porta de entrada com menor risco.
LLM OrchestrationSafe ArchitecturePontos-chave
A maior ineficiência das utilities europeias hoje, segundo Milis, é querer IA antes de definir o problema. Antes de qualquer projeto, isolar o caso de uso, métricas mensuráveis e contexto operacional — depois decidir se IA agrega ou se basta cálculo determinístico.
Dispositivos de última geração rotulados como "smart" são, em sua maioria, apenas coletores de dados. Inteligência verdadeira exige raciocínio sobre dados novos e capacidade de agir no ambiente. Sem isso, o valor não está no sensor — está no que se faz com a informação que ele entrega.
Quando a expertise é codificável e o sistema é tratável, regras explícitas são melhores. Quando o sistema é complexo demais para escrever regras mas há dados em volume, ML é a escolha. A decisão técnica deve sempre vir antes da escolha de tool — nunca o contrário.
Cálculo de água não faturada, estimativas de night flow, projeção de pressões e vazões em pontos não-medidos — tudo isso é matemática hidráulica clássica. Aplicar IA aqui é ruído. Usar IA onde realmente vale: detecção de signatures de vazamento, classificação de falhas, otimização em alta dimensão.
LLMs aprendem como humanos comunicam, não o que acontece em tempo real no sistema. Não devem ser usados como decisores em problemas críticos como segurança da água potável ou posicionamento de sensores. A camada certa é orquestração: LLM entende a intenção, ferramenta tradicional decide.
Frase de encerramento: "combining water domain with whatever technology, always to make the world a better place to live for people". O ponto não é a tecnologia em si — é o resultado para o operador, o cliente final e o sistema hídrico. IA é meio, não fim.
A analogia pessoal: um humano levou décadas para integrar contexto, intuição e accountability — capacidades que um modelo ML treinado em meses não tem. Não significa que ML seja inferior — significa que cada um cabe em uso diferente, e que humanos continuam sendo o último responsável pelo sistema.
A sequência operacional. Inverter qualquer etapa quebra o projeto. Utilities que pulam direto para "tool" produzem dashboards bonitos sem outcome. Utilities que param na "métrica" sem definir tool não escalam. As quatro etapas formam um pipeline indispensável.
Filosofia / Conclusão
A síntese de Milis é honesta e desconfortável para quem vende tecnologia: o setor de água não precisa de mais IA — precisa de mais clareza sobre que problema está resolvendo. A engenharia funciona. As ferramentas existem. O gargalo é institucional: utilities que adotam tecnologia antes de definir o problema produzem aparência de modernização sem outcome. A filosofia é a inversão: tool é consequência, nunca premissa.
Em um setor onde "AI-powered" virou commodity de marketing, posicionar-se como técnico que aponta os limites é raro e valioso. Milis recusa o role de profeta da IA — assume o de operador que escolhe a tool certa para o problema certo. É a postura que utilities sérias precisam adotar antes de comprar mais sensores.
Technical HonestyAnti-Hype"To make the world a better place to live for people." O encerramento não é decoração — é a métrica final. Toda decisão de tool, arquitetura, sensor, modelo hidráulico precisa retornar a essa pergunta: melhora a vida do operador, do cliente final, do sistema hídrico? Se não, é commodity técnica disfarçada de progresso.
Outcome-DrivenPeople First"Combining water domain with whatever technology, always to make the world a better place to live for people."
Water Loss 2026 — Resumo gerado por IA
Transcrição e tradução ao vivo por Nobox Live Translate
