Montar un servidor MCP hoy es sencillo. Con el SDK oficial y una tarde tienes un par de herramientas lanzando consultas contra tus datos, y Claude ya te está diciendo cuánto facturaste en agosto. Para una prueba de concepto sobra. Llevar un MCP corporativo a producción, con cientos de personas preguntando a los mismos modelos y cada una viendo solo lo que le toca, es otra conversación.
La demo funciona, y ese es el problema
Casi todas las pruebas de concepto que vemos tienen la misma forma. Una clave o un service principal metido en un fichero de configuración. Todas las herramientas visibles para quien se conecte. Todos los datos al alcance de todos, porque en la demo solo estaba quien la montó. Y ningún registro de quién preguntó qué.
Nadie se da cuenta mientras la usan tres personas del equipo de datos. El día que se abre al director comercial, al de operaciones y a un socio externo, aparecen las preguntas que la demo no tenía que contestar. ¿Por qué el de marketing ve la cuenta de resultados? ¿Y por qué el asistente le dijo a alguien que «no hubo ventas» cuando en realidad la consulta había fallado?
Si prefieres verlo antes de entrar en lo técnico, en este vídeo conectamos los datos y empezamos a preguntarles con IA, de principio a fin:
Quién pregunta en un MCP corporativo: identidad con Entra ID
Lo primero que tiene que resolver un MCP corporativo es que cada llamada sea de alguien. De una persona concreta de tu tenant, no de una clave compartida que usan veinte.
En Reporbia la vía principal es el inicio de sesión con Microsoft Entra ID. El usuario pega la dirección del servidor en Claude, en ChatGPT o en VS Code, entra con su cuenta de empresa y ya está, sin identificadores ni secretos que repartir. El servidor solo actúa en nombre de alguien que ha iniciado sesión. Y como la autenticación es la de tu tenant, tus políticas de acceso condicional y tu MFA siguen mandando.
En las instalaciones nuevas la conexión con Entra ID funciona sin contraseñas de aplicación guardadas: no hay un secreto que robar ni que caduque un viernes por la tarde. Todo el recorrido sigue la especificación de autorización de MCP, así que cualquier cliente que la respete se conecta sin configuraciones a medida.
Cada persona decide qué asistente conecta a tu MCP corporativo
En la próxima versión, la primera vez que alguien conecte un asistente, sea Claude, ChatGPT u otro, Reporbia le enseñará una pantalla propia, dentro de la aplicación que ya conoce. Verá qué asistente pide acceso y a dónde se entregará, y elegirá entre Permitir y No permitir. Si no lo permite, el asistente recibe una negativa limpia y no se guarda nada.
Se preguntará una sola vez por asistente.
La idea de fondo es sencilla. La conexión no es un trámite invisible: cada persona ve y decide quién lee sus datos en su nombre.
Qué herramientas y qué datos: perfiles MCP por grupos de seguridad
Saber quién pregunta no basta. Hay que decidir qué puede tocar. Para eso están los perfiles de servidor MCP, y es la pieza que más echamos en falta cuando revisamos otros montajes.
Un perfil junta dos decisiones. Qué herramientas puede usar quien entra con él, permitidas o bloqueadas una a una. Y a qué conectores de datos llega. Aquí conviene quitarse una idea de la cabeza: un MCP corporativo no es solo Power BI. Cada conector que creas en Reporbia se publica por el mismo servidor y con las mismas reglas, sea un modelo semántico de Power BI, un lakehouse o un warehouse de Fabric consultado por SQL, una base de datos de Azure SQL, Business Central o Holded. Ese perfil se concede a grupos de seguridad de Entra ID, los mismos que ya usas para todo lo demás. El grupo de dirección financiera recibe un perfil con el modelo de finanzas; el de operaciones, otro con el de producción. Quien está en los dos suma ambos.
Lo que queda fuera de tu perfil no se puede consultar, aunque se pida directamente. Vale para los conectores y vale también para las tablas y columnas que un conector no publica: no aparecen en los listados, ni en las relaciones, ni en los errores de una consulta DAX.
Tampoco se cuenta nada de la infraestructura. El asistente no recibe direcciones de servidores ni identificadores de conexión, y los mensajes de error le dicen qué hacer para corregir la consulta, no cómo está montada la seguridad por dentro.
Y activarlo no deja a nadie sin servicio por sorpresa.
Qué filas: la seguridad del modelo sigue mandando
Los perfiles deciden a qué modelos llegas. Dentro de cada modelo, las filas las decide la seguridad a nivel de fila (RLS) que ya tenga definida, y se aplica a todas las consultas que entran por MCP. Si un modelo declara RLS y no se puede resolver un rol para quien pregunta, la consulta se rechaza. Nunca se lee el modelo entero por defecto.
Solo lectura, preguntas de negocio y respuestas que no mienten
Las herramientas del MCP corporativo de Reporbia son de lectura. Todas. No hay escritura por MCP hacia tus datos, y es a propósito. Cada herramienta lo declara para que el cliente lo sepa antes de llamarla.
Leer no es quedarse en listados. El asistente puede consultar una tabla, pero también desglosar una medida por dimensiones de tablas relacionadas, del tipo ventas por región y mes, o escribir su propia consulta DAX cuando la pregunta lo pide. Las dos cosas respetan la misma selección de tablas del conector y la misma RLS, y las relaciones solo se enseñan entre tablas que el usuario puede ver.
Lo que sí nos parece imprescindible es que un error diga que es un error. En muchos servidores un fallo y un resultado vacío llegan al modelo de IA con la misma forma, y el asistente le cuenta tan tranquilo a un director que el trimestre salió a cero. Aquí un error vuelve marcado como error, y el asistente sabe que no debe rellenar el hueco. Lo que queda fuera de tu perfil, en cambio, simplemente no existe para el asistente.
Auditoría de un MCP corporativo: qué se ha preguntado
En un MCP corporativo cada consulta deja un registro, sea servida, denegada o fallida. El registro guarda quién, con qué perfil, sobre qué tabla, cuántas filas y con qué resultado. Nunca las filas ni el texto del filtro: la auditoría no puede convertirse en otra copia de los datos.
Asistentes conectados: revisar y retirar
En la próxima versión, el administrador tendrá en el AI Hub la lista de asistentes autorizados, con quién los autorizó, a dónde se entrega el acceso y cuándo se usaron por última vez. Cualquier autorización se retira con un clic, y las retiradas siguen a la vista, porque después la pregunta suele ser quién tuvo acceso, no solo quién lo tiene.
Conviene decir exactamente qué hace retirar una autorización: impide el siguiente inicio de sesión de ese asistente. Una sesión que ya está abierta dura hasta que caduca. Si hace falta cortarla en el momento, se revocan las sesiones de esa persona en Microsoft Entra ID.
Cuando el cliente no sabe iniciar sesión
Un script, un orquestador o una herramienta interna a veces no puede iniciar sesión con Entra ID. Para eso hay claves API. Una clave la emite un administrador del dominio, va atada a un perfil y tiene caducidad obligatoria y límite de uso.
Y si prefieres que todo pase por Entra ID, cada dominio puede cerrar esa puerta con un interruptor: las claves emitidas dejan de entrar sin tener que revocarlas una a una, y los clientes que saben iniciar sesión con Entra ID siguen funcionando sin tocar nada.
Un MCP corporativo que también habla hacia fuera
Tu empresa probablemente ya tiene, o va a tener, servidores MCP propios o de proveedores. Reporbia también sabe registrarlos: guarda sus credenciales dentro de tu propia instalación, aplica una política de qué herramientas del servidor remoto se permiten y deja rastro de cada conexión. Servidor y cliente del mismo protocolo, gobernados desde el mismo sitio.
¿Y el MCP de Power BI de Microsoft?
Es una buena opción y conviene conocerla. El servidor MCP remoto de Power BI, en vista previa, deja a una persona con permiso de compilación sobre un modelo preguntarle desde VS Code o Copilot, con su propia identidad y con RLS aplicado. Para un analista que ya trabaja dentro del workspace encaja muy bien.
Un MCP corporativo como el de Reporbia resuelve un caso distinto: servir los mismos modelos a mucha gente sin dar a cada persona acceso al workspace, gobernar por grupos qué herramientas y qué fuentes ve cada uno, poner detrás de un mismo servidor modelos semánticos, datos de Fabric, Azure SQL, Business Central y Holded, y tenerlo todo auditado dentro de tu Azure. Microsoft advierte en su documentación de que su servidor no aplica RLS cuando se autentica con service principal; en Reporbia la conexión usa los roles que decides, y un modelo protegido sin rol no responde.
Si quieres el contexto de por qué hablar con los datos cambia tanto, lo contamos en IA conversacional sobre Power BI, y lo básico del protocolo está en servidor MCP para Power BI. Y si tienes una prueba de concepto que funciona y no sabes cómo abrirla al resto de la empresa, cuéntanos qué tienes.
Seguir leyendo
- Servidor MCP: conecta tu Power BI a Claude y ChatGPT
- Soberanía del dato: tu analítica y tu IA, en Europa
- Elegir el modelo de IA para tus datos
Fuentes oficiales: Remote Power BI MCP server (Microsoft Learn) y Secure an MCP server with Microsoft Entra ID (Microsoft Learn).