Frit Ravich opera con Power BI Premium (Capacity P-SKU) y Snowflake como fuentes de datos principales. El objetivo es que los analistas —empezando por los 3-5 del equipo de Revenue— puedan obtener insights conversacionalmente: hacer preguntas en lenguaje natural y recibir datos, gráficos o presentaciones sin tocar una herramienta de BI.

La pieza clave de esta propuesta es que Power BI y Snowflake se presentan como UNA SOLA plataforma de datos conversacional. En la misma conversación, el analista puede preguntar por un KPI de Power BI y cruzarlo con una tabla de Snowflake, sin cambiar de herramienta ni de contexto.

• Cada analista se autentica con su PROPIA identidad Microsoft (OAuth) — Power BI RLS y Snowflake Row Access Policies se aplican de forma nativa, sin bypass posible.
• Sin coste de licencias adicionales en Fase 1: cada usuario emplea la licencia Power BI que ya tiene.
• Claude API con Zero Data Retention — los datos no se almacenan ni se usan para entrenar modelos.
• Infraestructura Microsoft por defecto — Azure-native cuando se requiere hosting (Fase 2).
• Equipo ya formado en Claude — punto de partida inmediato para la Fase 1.

Hay dos formas de llevar la plataforma conversacional a Frit Ravich. No son excluyentes: recomendamos empezar por la Opción A (Fase 1) y crecer hacia la Opción B (Fase 2) cuando el volumen de usuarios y la necesidad de automatización lo justifiquen.

Fase 1 (semanas 1-2): Opción A para los 3-5 analistas del equipo de Revenue. Aprovecha la formación recibida, da valor inmediato y valida el plumbing de datos con coste de build casi nulo y sin infraestructura que mantener.

Fase 2 (mes 3+): Opción B en Azure cuando el rollout crezca y la organización necesite reporting programado, branding propio y embebido en Teams.

En la Fase 1 no hay infraestructura propia. Cada analista trabaja desde Claude Desktop configurado con dos conectores MCP. La autenticación es con la identidad Microsoft del propio analista, de modo que la visibilidad de datos la imponen Power BI y Snowflake de forma nativa.

Analista → Claude Desktop / Claude Team
  → Power BI MCP  (dos perfiles, según usuario)
      ├─ Remote MCP   (api.fabric.microsoft.com/v1/mcp/powerbi) — consulta
      └─ Modeling MCP (@microsoft/powerbi-modeling-mcp)          — modelo
      [token del usuario → RLS nativa de Power BI]
  → Snowflake MCP (local o remoto)
      [credenciales del usuario → Row Access Policies]

Ambos MCP viven dentro de la MISMA conversación. El analista puede pedir "compárame las ventas del dashboard de Power BI con el detalle de pedidos en Snowflake" y Claude orquesta ambas consultas y cruza los resultados.

• Power BI MCP: acceso al modelo semántico en dos modalidades (Remote MCP y Modeling MCP), según el perfil del usuario.
• Snowflake MCP: servidor oficial de Snowflake Labs (Python, MIT). En Fase 1 puede correr en local o como endpoint remoto.
• Autenticación: OAuth con la identidad Microsoft del analista para Power BI; credenciales del usuario para Snowflake.
• Cliente: Claude Desktop / Claude Team. La configuración de ambos MCP se distribuye una sola vez por el administrador (no hay setup máquina a máquina).
• PPTX: capacidad nativa de Claude. El analista pide "genera la presentación de ventas de esta semana" y Claude la produce desde la conversación.

El Modeling MCP expone tools completas: dax_query_operations, measure_operations, table_operations, column_operations, relationship_operations, security_role_operations (RLS), partition_operations, database_operations (TMDL, deploy a Fabric) y operaciones en bloque (bulk).

Configuración del Modeling MCP para Claude Desktop / Claude Team (la distribuye el administrador):

{
  "powerbi-modeling-mcp": {
    "type": "stdio",
    "command": "npx",
    "args": ["-y", "@microsoft/powerbi-modeling-mcp@latest", "--start"]
  }
}

Esta arquitectura NO usa Service Principal ni un mecanismo de impersonación. Cada petición viaja con el token del propio analista, de modo que Power BI aplica su RLS y Snowflake sus Row Access Policies exactamente como lo harían si el usuario consultara directamente. No existe ninguna cuenta con permisos elevados que pueda saltarse esos límites.

La Fase 2 traslada la misma plataforma conversacional a una app web a medida, embebida en el ecosistema Microsoft 365 de Frit Ravich, con reporting programado y rollout amplio. La identidad del usuario sigue siendo la base de la seguridad.

Analista → Navegador → App Web (Azure)
  → Entra ID SSO (identidad del usuario)
  → Orquestador (Azure Container Apps)
      → Power BI MCP (ACA) → RLS por identidad
      → Snowflake MCP (ACA) → RAP por identidad
  → Respuesta + PPTX opcional

• Frontend: app web con SSO Entra ID (Azure Static Web Apps). La identidad del usuario se propaga al backend.
• Orquestador y MCP: Power BI MCP + Snowflake MCP corriendo en Azure Container Apps como instancias compartidas para varios usuarios.
• Free tier de ACA: 180.000 vCPU-seg/mes + 360.000 GiB-seg/mes — coste mínimo para cargas de analistas.
• Cuentas de servicio: una por fuente (1 licencia Power BI Pro/PPU, 1 usuario de servicio Snowflake), con impersonación por usuario para preservar RLS/RAP.
• PPTX automatizado: Azure Function + python-pptx rellena plantillas con datos de PBI/Snowflake, se dispara con Power Automate y se distribuye por Outlook/Teams.

Power BI y Snowflake no son dos productos separados: forman una única capa de datos conversacional. El analista no decide "voy a consultar Power BI" o "voy a consultar Snowflake" — simplemente pregunta, y Claude decide qué fuente (o ambas) responde mejor.

Ejemplo: "Las ventas del dashboard de Power BI de la semana pasada no cuadran con lo que veo en pedidos; enséñame el detalle por cliente desde Snowflake y dime dónde está la diferencia." Claude consulta Power BI, consulta Snowflake, cruza ambos resultados y responde — todo dentro del mismo hilo, respetando los permisos del analista en cada fuente.

No se crea ningún data warehouse intermedio. No se extraen datos al tenant de AI Mate. La capa de datos permanece 100% en la infraestructura existente de Frit Ravich: Talk to Data es una capa de interacción, no de almacenamiento.

El principio de diseño es uno solo: la identidad del usuario es la frontera de seguridad. En ninguna de las dos fases existe una cuenta privilegiada que pueda ver datos que el usuario no podría ver por sí mismo.

El token de cada usuario se usa directamente contra Power BI y Snowflake. Cada fuente aplica sus permisos nativos (RLS y Row Access Policies). No hay bypass de administrador porque no hay cuenta de administrador en el camino del dato.

La identidad de Entra ID SSO se propaga a través del stack hasta las fuentes de datos. Las mismas garantías que en la Fase 1 se mantienen en la capa de datos: cada consulta se ejecuta bajo la identidad del usuario real.

Claude como motor de IA en ambas fases. La Fase 1 no necesita infraestructura propia; la Fase 2 añade hosting Azure-native solo donde se requiere.

Frit Ravich opera sobre Microsoft 365, Entra ID y Power BI. Anclar la Fase 2 a ese stack reduce la superficie de gobernanza, elimina vendors externos del tenant de datos y permite que IT gestione los accesos con las herramientas que ya conoce. (En la Fase 1 no hay hosting que gobernar: todo corre en Claude Desktop y en el MCP de Microsoft.)

• Frit Ravich ya recibió formación específica en Claude — curva de cambio cero.
• Claude API ofrece Zero Data Retention (ZDR).
• Copilot Studio fue evaluado y descartado por el cliente como "poco user friendly".
• Precisión NL→DAX/SQL superior en razonamiento sobre esquemas de datos complejos.

Dos bloques de pricing — uno por fase. La Fase 1 no añade coste de licencias de datos; la Fase 2 añade infraestructura y una cuenta de servicio por fuente.

El desarrollo inicial se amortiza cuando el volumen de usuarios y la necesidad de reporting programado justifican la plataforma a medida. El free tier de Azure Container Apps cubre buena parte del hosting de los MCP para cargas de analistas.