Copilot Studio tiene un techo. Para escenarios de complejidad media, es la opción correcta: rápida de implantar, sin código, integrada con Dynamics 365 a través de conectores nativos. Pero cuando la lógica del agente requiere razonamiento en varios pasos, acceso a APIs internas no estandarizadas o control fino sobre cómo el modelo interpreta los datos del negocio, Copilot Studio se queda corto.
Semantic Kernel es la respuesta de Microsoft para equipos de desarrollo que necesitan construir agentes IA con control total. Es un SDK de código abierto, disponible en C# y Python, que permite orquestar modelos de lenguaje de Azure OpenAI con lógica de negocio propia, memoria persistente, herramientas externas y flujos de razonamiento multi-paso. El resultado se integra directamente con Dynamics 365 a través de sus APIs REST o con el SDK de Dataverse.
Este artículo explica qué es Semantic Kernel, cómo se arquitecta un agente con él y cuándo tiene sentido optar por este enfoque en lugar de Copilot Studio o Power Automate.
Qué es Semantic Kernel y por qué le importa a los equipos de Dynamics 365
Semantic Kernel nació dentro de Microsoft como la infraestructura interna que usa Copilot. Con el tiempo se convirtió en un SDK público, mantenido activamente por el equipo de Azure AI, que actualmente es el estándar de facto para construir agentes IA en el ecosistema Microsoft.
La propuesta central es simple: Semantic Kernel actúa como el cerebro que coordina el modelo de lenguaje, las herramientas externas y la memoria. El modelo de Azure OpenAI razona y genera texto; Semantic Kernel decide qué herramientas invocar, en qué orden, y cómo combinar los resultados para dar una respuesta coherente o ejecutar una acción.
Para un equipo que ya trabaja con Dynamics 365, esto significa que puedes construir un agente que consulte órdenes de venta, calcule proyecciones de stock, llame a una API de logística externa y genere un resumen ejecutivo, todo en una sola conversación con el usuario. Nada de eso requiere que el usuario sepa qué sistemas está tocando el agente por debajo.
Arquitectura de un agente con Semantic Kernel e integración con Dynamics 365
Un agente típico construido con Semantic Kernel tiene cuatro componentes principales.
El kernel y el modelo de lenguaje
El kernel es el objeto central de la aplicación. Se configura con las credenciales del modelo de Azure OpenAI (GPT-4o o la versión que corresponda según el caso) y con la lista de herramientas disponibles para el agente. La elección del modelo importa: GPT-4o es más preciso en razonamiento complejo, pero GPT-4o mini reduce significativamente el coste por token para casos donde la lógica es más directa.
Los plugins y las herramientas
Las herramientas son funciones de código que el modelo puede invocar durante el razonamiento. En Semantic Kernel se llaman plugins, y se definen con anotaciones que el modelo entiende para saber cuándo usarlas.
Un plugin para Dynamics 365 puede encapsular, por ejemplo, la consulta de un cliente por nombre o CIF a través de la Web API de Dataverse, la creación de un pedido de venta, o la lectura del estado de un ticket de soporte desde Customer Service. El modelo decide solo cuándo llamar a cada plugin; el desarrollador solo define qué hace cada función y cuándo tiene sentido usarla, en lenguaje natural.
La memoria y el contexto
Los modelos de lenguaje son stateless por naturaleza: cada llamada a la API no recuerda la anterior. Semantic Kernel resuelve esto con un sistema de memoria que puede ser en RAM para conversaciones cortas, o persistente en Azure Cosmos DB o SQL Server para agentes que necesitan recordar interacciones anteriores con el mismo usuario o sobre el mismo expediente.
Para integraciones con Dynamics 365, la memoria persistente es clave cuando el agente debe hacer seguimiento de un proceso largo: un agente de gestión de reclamaciones que recuerda el histórico completo del cliente sin que el usuario tenga que repetir el contexto en cada sesión aporta una experiencia cualitativamente diferente.
El planificador y el bucle de razonamiento
El componente más potente de Semantic Kernel es el planificador. Dado un objetivo en lenguaje natural, el planificador descompone la tarea en pasos, identifica qué plugins usar en cada paso y ejecuta el plan de forma autónoma. Si un paso falla o devuelve datos inesperados, el planificador puede ajustar la estrategia antes de continuar.
Esto permite construir flujos que combinan datos de Dynamics 365 Finance (saldo de cliente), Dynamics 365 Supply Chain Management (disponibilidad de stock) y una API externa de transportista, y generar un plan de entrega personalizado sin que ningún usuario haya definido manualmente esa lógica de combinación.
Casos de uso donde Semantic Kernel supera a Copilot Studio
Agentes de ventas con acceso a datos financieros en tiempo real
Un agente para el equipo comercial que consulta el límite de crédito del cliente en Dynamics 365 Finance, verifica el stock disponible en SCM, y calcula automáticamente las condiciones de entrega viables antes de confirmar un pedido. La lógica de negocio que combina estas tres fuentes es demasiado específica para un conector estándar, pero es perfectamente encapsulable en tres plugins de Semantic Kernel.
Asistentes de soporte técnico con base de conocimiento interna
Los agentes de Customer Service pueden buscar en la base de conocimiento de Dynamics 365, consultar el historial de casos del cliente y proponer soluciones en función del contrato de servicio activo, todo en una sola respuesta. Semantic Kernel puede combinar la búsqueda semántica sobre documentos internos (a través de Azure AI Search) con la consulta estructurada a la API de Customer Service.
Automatización de procesos financieros con validación inteligente
Un agente que recibe una solicitud de aprobación de gasto, consulta las políticas de la empresa (desde SharePoint o Dataverse), verifica el presupuesto disponible en Dynamics 365 Finance y genera automáticamente la recomendación de aprobación o rechazo con justificación. El razonamiento que combina política, presupuesto y contexto del solicitante es exactamente lo que los modelos de lenguaje hacen bien cuando se les dan las herramientas correctas.
Copilot Studio vs. Semantic Kernel: cuándo usar cada uno
No son opciones excluyentes, pero sirven a perfiles distintos de proyecto.
Copilot Studio es la elección correcta cuando el caso de uso encaja en los conectores nativos disponibles, el equipo que lo mantiene no tiene perfil de desarrollo, y el tiempo de implantación es una restricción importante. Para el 70% de los escenarios de asistentes conversacionales en Dynamics 365, Copilot Studio llega sin necesidad de código.
Semantic Kernel tiene sentido cuando la lógica del agente requiere código, cuando necesitas integrar sistemas que no tienen conector en Power Platform, o cuando el control sobre el comportamiento del modelo es una exigencia del proyecto. También cuando el volumen de peticiones hace que el modelo de licenciamiento de Copilot Studio resulte más caro que una implementación propia sobre Azure OpenAI con pago por uso.
Otra combinación viable es usar Copilot Studio como interfaz conversacional y delegar las acciones complejas a un backend de Semantic Kernel a través de un conector personalizado. Así se mantiene la facilidad de uso de Copilot Studio para el diseño del flujo conversacional y se usa Semantic Kernel donde la lógica lo requiere.
Requisitos técnicos y punto de partida
Para arrancar un proyecto con Semantic Kernel e integración con Dynamics 365 se necesita un tenant de Azure con acceso al servicio Azure OpenAI (el acceso está disponible para cualquier suscripción de Azure activa), el SDK de Semantic Kernel instalado vía NuGet (C#) o pip (Python), y credenciales de aplicación registradas en Entra ID con los permisos necesarios sobre la API de Dataverse o Dynamics 365.
El punto de partida más práctico es construir un plugin simple que consulte un único endpoint de la API de Dynamics 365, validar que el modelo lo invoca correctamente en respuesta a preguntas en lenguaje natural, y a partir de ahí ampliar la superficie de herramientas disponibles para el agente.
Microsoft mantiene documentación actualizada y ejemplos de Semantic Kernel en GitHub, con notebooks de Python y proyectos de ejemplo en C# que cubren la integración con Azure OpenAI y los patrones de plugin más habituales. Es un punto de partida sólido antes de abordar la integración específica con Dynamics 365.
Consideraciones de coste y gobernanza
El coste de un agente basado en Semantic Kernel y Azure OpenAI se mide en tokens consumidos por el modelo. A diferencia de Copilot Studio, donde el precio es por sesión o por mensaje según la licencia, aquí el coste es directamente proporcional al uso y a la complejidad de las interacciones.
Para proyectos en producción conviene implementar desde el inicio un sistema de logging de consumo de tokens por usuario o por departamento, y definir límites de uso para evitar sorpresas en la factura de Azure. Azure Monitor y Application Insights se integran de forma nativa con Semantic Kernel para esta función de observabilidad.
En cuanto a gobernanza, los agentes de Semantic Kernel son aplicaciones de software estándar: viven en Azure App Service o Azure Container Apps, se despliegan con pipelines de CI/CD y se auditan como cualquier otra aplicación. Esto es una ventaja para organizaciones con procesos de seguridad maduros que tienen dificultades para auditar los flujos de Copilot Studio.
El escenario que lo justifica todo
La pregunta que vale la pena hacerse antes de iniciar cualquier proyecto de agente IA no es qué tecnología es mejor en abstracto, sino qué nivel de control necesitas sobre la lógica y qué perfil técnico tiene el equipo que lo va a mantener.
Si la respuesta es que necesitas control total, que el caso de uso combina múltiples sistemas con lógica específica de tu empresa, y que tienes desarrolladores con experiencia en C# o Python en el equipo, Semantic Kernel es la herramienta. No porque sea más sofisticada que Copilot Studio, sino porque resuelve una clase diferente de problemas.
Las empresas que ya tienen Dynamics 365 en producción y están empezando a explorar la IA generativa tienen una ventaja: toda la infraestructura de datos, identidad y APIs ya está en el ecosistema Microsoft. Semantic Kernel es la forma de aprovechar esa infraestructura para construir capacidades de IA que no existen en ningún producto de catálogo.
Preguntas frecuentes sobre Semantic Kernel y Dynamics 365
¿Semantic Kernel es un producto de Microsoft o un proyecto open source?
Es ambas cosas. Semantic Kernel es un proyecto open source mantenido por Microsoft, disponible en GitHub bajo licencia MIT. Microsoft lo usa internamente para construir Copilot y lo mantiene activamente con releases frecuentes. Cualquier empresa puede usarlo sin coste de licencia; el coste viene del consumo de Azure OpenAI.
¿Hace falta saber C# para usar Semantic Kernel con Dynamics 365?
No necesariamente. Semantic Kernel tiene soporte oficial para Python, que tiene una comunidad de IA más amplia y notebooks de ejemplo más accesibles. Para equipos con perfil de desarrollo .NET, C# es la opción más natural dado que la mayor parte del ecosistema Dynamics 365 on-premise y muchos proyectos de personalización están en ese lenguaje.
¿Los agentes de Semantic Kernel pueden aparecer como canales en Copilot Studio?
Sí. Una de las integraciones más habituales es exponer un agente de Semantic Kernel como un endpoint HTTP y conectarlo a Copilot Studio como acción personalizada. Así el diseño conversacional se mantiene en Copilot Studio y la lógica compleja se delega al backend de Semantic Kernel.
¿Qué modelos de Azure OpenAI son compatibles con Semantic Kernel?
Semantic Kernel es compatible con todos los modelos de chat de Azure OpenAI: GPT-4o, GPT-4o mini, GPT-4 Turbo y los modelos de la familia o1. También es compatible con modelos de embeddings como text-embedding-3-large para las funciones de búsqueda semántica en la memoria del agente.
¿Es posible usar Semantic Kernel con Dynamics 365 Business Central además de Finance y SCM?
Sí. Business Central expone una API REST estándar que se puede encapsular en un plugin de Semantic Kernel igual que cualquier otro endpoint. La autenticación se gestiona a través de Entra ID con el mismo patrón de registro de aplicación que en Finance y SCM.