🗄️ Copilot Studio conecta Azure SQL como conocimiento nativo

Copilot Studio ya documenta cómo añadir tablas de Azure SQL Database o Azure SQL Managed Instance directamente como fuente de conocimiento. El agente puede responder preguntas sobre los datos estructurados de las tablas seleccionadas mediante una conexión SQL de Power Platform, sin que tengamos que convertir cada consulta en una acción o envolver primero la base de datos con una API propia.

La novedad es técnicamente relevante, pero su disponibilidad requiere precisión. El roadmap 568930 continúa marcado como In development, con preview prevista para agosto de 2026 y disponibilidad general estimada para septiembre de 2026. La guía de implementación, actualizada el 13 de agosto de 2026, ya describe la configuración. Por tanto, a 8 de septiembre de 2026 debemos tratarla como una capacidad en despliegue, no como GA confirmada para todos los tenants.

Qué cambia realmente

Hasta ahora, el patrón habitual para consultar SQL desde un agente era exponer acciones concretas: un flujo, un conector, una API o una herramienta MCP recibía parámetros y devolvía un resultado. Azure SQL como knowledge incorpora otro patrón:

PatrónCuándo se seleccionaContratoUso recomendado
Knowledge de Azure SQLEl orquestador decide si la fuente puede responderTablas seleccionadas, esquema y descripción semánticaPreguntas de lectura y exploración sobre datos estructurados
Acción o herramientaEl orquestador elige una operación explícitaEntradas y salidas definidasEscrituras, procesos y consultas con comportamiento determinista
API o MCP propioLa lógica necesita control especializadoContrato diseñado por el equipoReglas complejas, auditoría, agregaciones controladas o integración multi-sistema

Knowledge no sustituye a una herramienta transaccional. La documentación define esta capacidad para leer tablas y fundamentar respuestas. Si la conversación debe aprobar, contabilizar o modificar un registro, mantén esa operación en una acción gobernada.

Arquitectura de Azure SQL como fuente de conocimiento de Copilot Studio.

Diagrama original. La ruta privada es opcional y requiere Power Platform VNet support; el límite efectivo de datos lo establece la conexión configurada y sus permisos SQL.

Arquitectura de ejecución

El flujo confirmado tiene cinco piezas:

  1. El usuario pregunta al agente publicado.
  2. El orquestador utiliza el nombre y la descripción de la fuente para decidir si Azure SQL es pertinente.
  3. Copilot Studio accede a las tablas seleccionadas mediante la conexión SQL de Power Platform.
  4. Azure SQL autoriza la lectura con los permisos asociados a esa ruta de conexión.
  5. El agente compone una respuesta fundamentada en los resultados disponibles.

Microsoft indica simultáneamente que el runtime depende de la autenticación Microsoft del usuario del agente y que los usuarios solo reciben respuestas basadas en los datos que el maker puede consultar mediante la conexión configurada. Esa redacción no demuestra por sí sola que la identidad del usuario final se propague a Azure SQL ni que las políticas de Row-Level Security se evalúen con su identidad.

La regla segura es diseñar la conexión como el perímetro máximo de datos y validar el comportamiento real en el tenant antes de confiar en seguridad por usuario. No uses el prompt ni las instrucciones del agente como control de acceso.

Requisitos y disponibilidad

Necesitas:

  • una base de datos Azure SQL Database o Azure SQL Managed Instance alcanzable desde Power Platform;
  • credenciales con permiso para conectarse, enumerar y leer las tablas elegidas;
  • acceso a Copilot Studio y permiso para editar el agente;
  • conectividad mediante reglas de firewall o una ruta privada compatible;
  • tablas con clave primaria y nombres de tablas y columnas comprensibles.

La interfaz puede mostrar Azure SQL o SQL Server, según el entorno. La documentación también menciona SQL Server al preparar las tablas, pero los prerrequisitos de esta guía identifican Azure SQL Database y Managed Instance. Para SQL Server on-premises, no des por soportado el mismo recorrido sin verificarlo expresamente en el tenant.

El conector SQL Server está clasificado como Premium en Copilot Studio. La página de esta característica no publica una tarifa específica adicional por tabla o consulta. En agentes construidos sobre el GitHub Copilot harness, el uso de knowledge forma parte del consumo de Copilot Credits; dimensiona y mide el escenario real en lugar de asumir un coste fijo por conversación.

Preparar una superficie de datos segura

No conectes automáticamente las tablas operativas completas. Crea una superficie de lectura dedicada con solo las filas y columnas que el agente necesita. Como la característica exige clave primaria y las vistas SQL no tienen una clave primaria declarada, una tabla de serving materializada suele encajar mejor que una vista convencional.

Un patrón sencillo es un esquema agent_knowledge alimentado mediante ETL, Fabric, Data Factory o un job controlado:

CREATE SCHEMA agent_knowledge AUTHORIZATION dbo;
GO

CREATE TABLE agent_knowledge.OrderStatus (
    OrderId           nvarchar(30)  NOT NULL,
    CustomerName      nvarchar(160) NOT NULL,
    OrderDate         date          NOT NULL,
    StatusDescription nvarchar(80)  NOT NULL,
    TotalAmount       decimal(18,2) NOT NULL,
    CurrencyCode      char(3)       NOT NULL,
    LastUpdatedUtc    datetime2(0)  NOT NULL,
    CONSTRAINT PK_agent_knowledge_OrderStatus PRIMARY KEY (OrderId)
);
GO

CREATE ROLE copilot_knowledge_reader;
GRANT SELECT ON SCHEMA::agent_knowledge TO copilot_knowledge_reader;
GO

-- Sustituye el nombre por el principal de base de datos que use la conexión.
ALTER ROLE copilot_knowledge_reader ADD MEMBER [copilot-sql-reader];
GO

Este diseño aporta cuatro controles:

  • una clave estable para identificar cada fila;
  • nombres que el orquestador puede interpretar;
  • ausencia de campos sensibles innecesarios;
  • un principal con SELECT limitado al esquema de knowledge.

Evita conceder db_datareader sobre toda la base si basta con un esquema. Documenta también la latencia del proceso que actualiza la tabla: el agente no puede informar sobre datos más recientes que su superficie SQL.

Configuración paso a paso

1. Verificar la conexión fuera del agente

Con la misma identidad o credencial prevista para la conexión:

  1. Comprueba que el servidor y la base de datos son accesibles.
  2. Enumera las tablas del esquema permitido.
  3. Ejecuta un SELECT sobre una tabla de diagnóstico con pocos registros conocidos.
  4. Confirma que no puede leer otros esquemas ni escribir datos.

Si las tablas no aparecen en Copilot Studio, Microsoft recomienda validar primero la conexión fuera del producto y los permisos para enumerar y leer esas tablas.

2. Añadir Azure SQL como knowledge

  1. Abre el agente en Copilot Studio.
  2. Ve a Build.
  3. En el panel de componentes, selecciona Knowledge.
  4. Pulsa Add knowledge y elige Azure SQL o SQL Server.
  5. Crea o selecciona la conexión.
  6. Indica servidor, base de datos y el tipo de autenticación aprobado.
  7. Busca y selecciona únicamente las tablas necesarias.
  8. Revisa el nombre y escribe una descripción detallada.
  9. Selecciona Add to agent.
  10. Publica el agente y prueba el canal publicado.

Una descripción útil delimita tanto el uso correcto como el incorrecto:

Estado de pedidos de Contoso en Azure SQL. Usa esta fuente para consultar
pedidos, fecha, cliente, importe, moneda y estado operativo. Los datos se
actualizan cada 15 minutos. No la uses para stock disponible, pagos, datos
bancarios ni seguimiento del transportista.

La descripción participa en la selección del orquestador. “Base de datos SQL” no aporta suficiente semántica.

3. Elegir la ruta de red

Con endpoint público, restringe el firewall al mínimo compatible con Power Platform y evita reglas amplias por comodidad. Para una base expuesta solo mediante private endpoint, Microsoft documenta la ruta mediante Power Platform Virtual Network support.

Esa opción requiere:

  • un Managed Environment;
  • VNet support habilitado en el entorno Power Platform;
  • rol Power Platform tenant admin o Environment Admin para configurarlo;
  • un conector con soporte nativo para VNet, como SQL Server.

El conector SQL tiene limitaciones específicas bajo VNet: por ejemplo, el gateway on-premises no está soportado en esa ruta y, con autenticación Microsoft Entra integrada, la base de datos debe introducirse manualmente como valor personalizado.

Seguridad y gobierno

Identidad

  • Prefiere una identidad dedicada a reutilizar la cuenta personal de un maker.
  • Concede solo lectura sobre el esquema o tablas aprobadas.
  • Rota secretos y prueba el estado de la conexión después de cada cambio.
  • Los usuarios guest de Entra no están soportados para conexiones Entra del conector SQL; valida alternativas antes de diseñar un acceso B2B.

Datos

  • Materializa únicamente atributos necesarios para responder.
  • Excluye secretos, identificadores personales y columnas de alta sensibilidad salvo justificación explícita.
  • Aplica en SQL los límites que deban cumplirse incluso si el agente ignora una instrucción.
  • Registra propietario, finalidad, frecuencia de actualización y periodo de retención de cada tabla expuesta.

Power Platform

Las conexiones son credenciales guardadas en el entorno. Revisa las data policies de Power Platform: bloquear un conector puede afectar tanto al diseño como al runtime y dejar la conexión deshabilitada. Incluye SQL en la clasificación de datos corporativos adecuada y separa conectores que no deban combinarse con él.

Plan mínimo de pruebas

PruebaResultado esperado
Pregunta conocida sobre la tabla de diagnósticoDevuelve los valores exactos
Pregunta fuera del dominio descritoNo elige Azure SQL o reconoce que la fuente no aplica
Consulta sobre una columna no expuestaNo revela ni infiere el dato
Usuario con perfil diferenteRespeta el comportamiento de autorización validado en el tenant
Credencial caducada o revocadaFalla de forma visible y monitorizable
Tabla grande o pregunta agregadaResponde dentro de la latencia y precisión aceptadas
Cambio de esquemaSe detecta en DEV antes de promover a producción

Compara cada respuesta con SQL ejecutado sobre el mismo snapshot. Para cifras financieras o regulatorias, no aceptes una respuesta plausible: valida totales, moneda, fechas y filtros.

Límites que no debemos ocultar

  • El roadmap sigue “In development”; la fecha de GA es una estimación, no una confirmación.
  • La documentación no garantiza el despliegue simultáneo en todos los tenants.
  • Cada tabla necesita clave primaria; un modelo legado puede requerir una capa de serving.
  • Añadir tablas irrelevantes empeora la selección y la calidad de las respuestas.
  • El límite general publicado es de 500 fuentes de conocimiento por agente, pero no equivale a un objetivo de diseño.
  • La navegación del conector SQL está limitada a 10.000 tablas.
  • Microsoft no documenta en esta guía un SLA de latencia, límites específicos de filas ni semántica completa de autorización por usuario para Azure SQL knowledge.
  • Las limitaciones de acciones SQL —como timeouts o throttling— no deben trasladarse automáticamente a knowledge sin una prueba; Microsoft no describe aquí la implementación interna con ese nivel de detalle.

Recomendación práctica

Empieza con un único dominio, una tabla materializada pequeña y una identidad de solo lectura. Define preguntas válidas e inválidas, mide exactitud y consumo, y prueba dos perfiles de usuario antes de ampliar el alcance.

El valor de Azure SQL como knowledge no consiste en dar al LLM acceso a la base corporativa. Consiste en crear una superficie SQL deliberada, legible y gobernada que el orquestador pueda elegir con seguridad. Si no podemos describir exactamente qué datos expone una tabla, todavía no está lista para un agente.

Referencias