Scottish Water opera um dos maiores programas de investimento de capital do Reino Unido. Suas equipes de projeto enfrentavam um problema de acesso a dados que os dashboards não conseguiam resolver. Os dados existiam — status do projeto, desempenho financeiro, marcos de entrega, registros de risco — mas recuperá-los significava navegar por dezenas de relatórios, procurar no SharePoint ou aguardar um especialista em dados. A concessionária construiu SPARK, uma interface conversacional sobre Databricks Genie dentro do Microsoft Teams. As equipes de projeto agora fazem perguntas em português simples e obtêm respostas governadas em segundos.
A arquitetura abrange quatro camadas. Um usuário faz uma pergunta no Teams via Copilot. Um agente supervisor do Copilot roteia a solicitação para um Databricks Genie Space sobre o Model Context Protocol (MCP) — uma integração MCP em produção entre dois fornecedores enterprise, não uma demonstração. Genie traduz a pergunta em SQL, a executa contra o Unity Catalog e retorna o resultado. A resposta volta ao Teams sem o usuário sair da janela de chat.
MCP mantém a orquestração no Copilot enquanto preserva a governança de dados no Databricks. Nenhum fornecedor possui a stack completa; MCP é o ponto de transferência. Esse é um padrão reutilizável para organizações executando Microsoft 365 Copilot e um Databricks lakehouse.
Scottish Water construiu a arquitetura de governança antes da camada conversacional. Não expôs tabelas brutas do Unity Catalog ao Genie. Em vez disso, a equipe curou uma camada ouro com apenas dados necessários para o caso de uso de investimento de capital, depois construiu uma camada semântica em cima usando Databricks metric views. Metric views padronizam medidas, dimensões e terminologia comercial — "exposição ao risco" e "escore de risco ativo" carregam a mesma definição em toda consulta. Essa consistência é o que permite ao sistema retornar respostas em que os usuários confiam em vez de alucinações que soam plausíveis.
Uma busca típica de dados de projeto anteriormente exigia oito cliques mais tempo de carregamento do dashboard. Com SPARK, começa com uma única pergunta digitada. Recuperação de relatório que exigia navegar por SharePoint, o Reporting Hub, categorias de relatório e links de relatórios individuais — um processo de 4 a 5 etapas — reduz-se a pergunta e resposta direta. Com 100 usuários fazendo 3 perguntas por semana (300 solicitações semanais), a equipe projeta 2 a 5 minutos economizados por solicitação. Isso se acumula em 520–1.300 horas anualmente.
Dashboards estáticos respondem as perguntas que seus designers anteciparam. Interfaces conversacionais respondem o que alguém precisa neste exato momento: "Liste todos os riscos de projeto abertos vencendo em agosto, incluindo proprietário do risco e data de vencimento" ou "Qual é o risco com a maior exposição atual para o projeto X?" Essas consultas não se encaixam perfeitamente em relatórios pré-construídos. Elas se encaixam em um Genie Space bem ajustado apoiado por uma camada semântica.
A parte difícil, que a maioria das equipes ignora, é a camada semântica. Genie gera SQL contra tabelas brutas. Não consegue resolver ambiguidade incorporada em convenções de nomenclatura inconsistentes ou lógica comercial conflitante entre domínios de relatório. A implementação da Scottish Water funcionou porque a curação da camada ouro e definições de metric views aconteceram primeiro. A interface conversacional foi a última milha, não a fundação.
Conclusão para arquitetos: se você está conectando uma camada Q&A de LLM a um data warehouse, o trabalho essencial é uma camada ouro governada e uma camada semântica com definições de métricas padronizadas. A interface LLM é direta uma vez que essas existem.