Scottish Water gestiona uno de los programas de inversión de capital más grandes del Reino Unido. Sus equipos de proyecto enfrentaban un problema de acceso a datos que los dashboards no podían resolver. Los datos existían — estado del proyecto, desempeño financiero, hitos de entrega, registros de riesgos — pero recuperarlos significaba navegar por docenas de informes, buscar en SharePoint o esperar a un especialista en datos. La empresa construyó SPARK, una interfaz conversacional sobre Databricks Genie dentro de Microsoft Teams. Los equipos de proyecto ahora hacen preguntas en inglés simple y obtienen respuestas gobernadas en segundos.

La arquitectura abarca cuatro capas. Un usuario hace una pregunta en Teams a través de Copilot. Un agente supervisor de Copilot enruta la solicitud a un Databricks Genie Space sobre el Model Context Protocol (MCP) — una integración MCP en producción entre dos proveedores empresariales, no una demostración. Genie traduce la pregunta a SQL, la ejecuta contra Unity Catalog y devuelve el resultado. La respuesta regresa a Teams sin que el usuario abandone la ventana de chat.

MCP mantiene la orquestración en Copilot mientras preserva la gobernanza de datos en Databricks. Ningún proveedor posee la pila completa; MCP es el punto de transición. Este es un patrón reutilizable para organizaciones que ejecutan Microsoft 365 Copilot y un Databricks lakehouse.

Scottish Water construyó la arquitectura de gobernanza antes de la capa conversacional. No expuso tablas brutas de Unity Catalog a Genie. En su lugar, el equipo curó una capa dorada con solo datos necesarios para el caso de uso de inversión de capital, luego construyó una capa semántica encima usando Databricks metric views. Las metric views estandarizan medidas, dimensiones y terminología comercial — "exposición al riesgo" y "puntuación de riesgo activo" tienen la misma definición en cada consulta. Esta consistencia es lo que permite al sistema devolver respuestas en las que los usuarios confían en lugar de alucinaciones que suenan plausibles.

Una búsqueda típica de datos de proyecto anteriormente requería ocho clics más tiempo de carga del dashboard. Con SPARK, comienza con una sola pregunta escrita. La recuperación de informes que requería navegar por SharePoint, el Hub de Informes, categorías de informes y enlaces individuales de informes — un proceso de 4 a 5 pasos — se reduce a pregunta y respuesta directas. Con 100 usuarios haciendo 3 preguntas por semana (300 solicitudes semanales), el equipo proyecta 2 a 5 minutos ahorrados por solicitud. Eso suma 520–1.300 horas anualmente.

Los dashboards estáticos responden las preguntas que sus diseñadores anticiparon. Las interfaces conversacionales responden lo que alguien necesita en este momento: "Enumere todos los riesgos de proyecto abiertos que vencen en agosto, incluido el propietario del riesgo y la fecha de vencimiento" o "¿Cuál es el riesgo con la mayor exposición actual para el proyecto X?" Esas consultas no encajan perfectamente en informes pregenerados. Encajan en un Databricks Genie Space bien ajustado respaldado por una capa semántica.

La parte difícil, que la mayoría de los equipos omiten, es la capa semántica. Genie genera SQL contra tablas brutas. No puede resolver la ambigüedad incorporada en convenciones de nomenclatura inconsistentes o lógica comercial conflictiva en dominios de informes. La implementación de Scottish Water funcionó porque la curación de la capa dorada y las definiciones de metric views sucedieron primero. La interfaz conversacional fue la última milla, no la base.

Conclusión para arquitectos: si está conectando una capa de Q+A de LLM a un almacén de datos, el trabajo crítico es una capa dorada gobernada y una capa semántica con definiciones de métricas estandarizadas. La interfaz LLM es directa una vez que existen.