Bienvenidos todos al podcast M65FM. Hoy vamos a ir más allá de una de las conversaciones más comunes sobre la ingeniería de prompts de Microsoft 365 Copilot. Porque una vez que las organizaciones empiezan a usar Copilot en serio, la pregunta cambia rápidamente de cómo escribimos mejores prompts a cómo conectamos Copilot a las aplicaciones, datos, procesos de negocio y conocimientos que realmente usamos en nuestra empresa. Y ahí es donde la extensibilidad de Copilot se vuelve interesante. Probando. Mi invitada de hoy es Evas Harvest, MVP de Microsoft, consultora de aplicaciones de negocio y del grupo de IA en Suiza. Evas trabaja con Microsoft 365 Azure, Dynamics 365 y Power Platform con un enfoque particular en extender Microsoft 365 Copilot mediante agentes y desarrollo personalizado. Vamos a explorar la extensibilidad de Microsoft 365 Copilot, Copilot Studio, Microsoft Azure Foundry, no sé, le cambiaré el nombre, NRA, Microsoft Graph, desarrollo personalizado, MPS y demás.

Desarrollo personalizado, MCPS y demás. Evas, bienvenida al podcast M65. Hola a todos, gracias por invitarme. Es una muy buena oportunidad para mí estar aquí, estar aquí. Así que gracias por tenerme. Sí, te agradezco. Antes de ponernos técnicos, podrías contarnos un poco sobre tu trayectoria y cómo llegaste al ecosistema de Microsoft.

Por supuesto, porque para ser honesta, no comencé mi carrera en el mundo de Microsoft. Empecé mi carrera en el mundo de Apple. Fui ingeniera de software en la plataforma Mac y luego pasé a iOS, ese tipo de cosas. Y bueno, hace mucho tiempo, quizás unos 15 o 20 años, me pasé al mundo de Microsoft, para ser sincera. Comencé mi carrera en SharePoint.

Luego pasé a la nube Azure M365. Empecé con SharePoint local, así comencé. Y luego pasé a todos los servicios en la nube. Y finalmente a Power Platform y más recientemente a todo lo relacionado con la IA. Para ser honesta, porque ahora es una gran parte de M365. Estamos viviendo una transición hacia agentes y básicamente eso es, en pocas palabras, mi trayectoria.

Pero comencé mi carrera en el mundo de la ingeniería de software, que quizás sea una palabra que mucha gente está olvidando. Porque tenemos todo este tema de la IA ahora y básicamente este tipo de actividades o empleos se han trasladado a la IA. Así que es bastante diferente a lo que era hace 20 años comparado con ahora.

Sí, dices que trabajas con SharePoint y también veo que trabajas con Graphspeak, Dynamic, Power Platform. ¿Cómo te preparó esa trayectoria para la generación actual de desarrollo de IA? Básicamente mi perfil es realmente transversal porque en mi carrera solía trabajar con muchísimos productos. Estos podrían ser productos de Microsoft y de otras marcas. Así que básicamente tengo un amplio alcance de habilidades en muchas tecnologías y herramientas diferentes. Entonces todos mis trabajos me dieron una buena base porque ahora con la IA es un tema muy amplio, ya que tienes diferentes enfoques y diferentes tipos de tecnologías para implementar IA actualmente. Puede ser algo agente, puede ser más de flujo de trabajo, este tipo de cosas. Entonces básicamente todos mis trabajos anteriores me dieron muchas habilidades para estar listo para esta transición a la IA ahora, siendo sincero. Así que pasé a herramientas de bajo código, herramientas sin código y a código profesional.

Así que sí, todas estas oportunidades y actividades en mis trabajos me dieron buenas habilidades para sacar provecho en el mundo de la IA. Honestamente. ¿Y ahora eres un líder de pruebas de IA? ¿Qué hace un líder de pruebas de IA?

Es una pregunta muy buena porque mucha gente me la hace. Mi trabajo es simplemente hacer coincidir las especificaciones funcionales con la pila técnica TILAS. Así que tomo el liderazgo cuando ya se ha realizado el análisis de negocio-negocio. Hemos definido casos de uso para lo relacionado con la IA. Hemos definido escenarios y casos de uso. Ya hemos realizado el análisis de negocio completo. Y mi trabajo es tomar esas necesidades y hacer que coincidan con la pila técnica detrás de escena. Y después, lidero toda la implementación de las herramientas y la solución cuando estamos listos para comenzar a desarrollar.

Sí, interesante. De hecho, muchas empresas compran capacitaciones para sus empleados, especialmente para la ingeniería de proms. ¿Por qué dirías que eso no es suficiente?

¿Te refieres solo a la ingeniería de proms hoy en día? ¿Por qué, por qué, por qué? Ellos, ellos. ¿Por qué eso lo... ¿Sabes por qué? Para las empresas no basta con solo enseñar a la gente la ingeniería de proms. Ah, siguiente. Ya veo, ya. Vale. Sí. Básicamente, para ser honesto, hoy en día tienes, como dije antes, muchas herramientas y tecnologías diferentes. Así que, básicamente, en algún punto la IA puede entender qué hacer y quizás guiarte un poco. Pero para mí, el rol de, por ejemplo, arquitecto o diseñador de software, ¿necesitas tener a un humano detrás de escena porque necesitas entender al cliente?

Básicamente, la IA a veces no puede entender el contexto del cliente. ¿Ves ahí el panorama completo? Pero detrás de escena, enfocarse solo en la ingeniería de proms podría estar bien en cierto punto. Pero necesitas más porque necesitas tener detrás de escena algunas personas que sean arquitectos, ingenieros de software y, básicamente, mucha gente con habilidades en tecnologías, tecnologías de la información como SharePoint, OneDrive o, no sé, Salesforce, ese tipo de cosas. Necesitas especialistas en esas tecnologías porque la IA puede entender muchas cosas. Puede guiarte. Puedes generar excelentes documentos técnicos o funcionales, pero necesitas humanos detrás de escena que se encarguen de, bueno, ¿es esto correcto? Está respondiendo a la necesidad del cliente y esas cosas, ya ves, para validar todo y centrarse. Solo en la ingeniería de proms, para mí ahora, sí, podría ser, podría ser una opción si no tienes tiempo para formarte o para invertir en adquirir algunas habilidades.

Pero para mí necesitas tener buenas habilidades en las tecnologías fundamentales donde quieres construir tus soluciones para ser honesto.

Y tú eres experto en extensibilidad de Copilot.

¿Dónde se detiene el Copilot estándar de Microsoft 365 y dónde comienza la extensibilidad de Copilot? Ah, sí, es una buena pregunta. Porque, para ser honesto, hace dos años, cuando se lanzó Copilot y quizás la primera versión, básicamente el chat era, para ser honesto, realmente muy minimalista. Básicamente, pues, bueno, era como un chat GPT, pero Microsoft ha evolucionado mucho. Microsoft 365 Copilot.

Básicamente, ahora tienes con portes, tienes diferentes tipos de funciones, así que ahora la extensibilidad es menor que antes, porque en el pasado yo desarrollaba algunos complementos, ese tipo de cosas, pero hoy en día, para ser honesto en este momento, la extensibilidad es cuando quieres construir algo y quieres personalizar, básicamente, el orquestador o quieres personalizar un poco más. Por ejemplo, la interfaz de usuario, si quieres integrar tu agente, no solo en el chat de Microsoft 365, sino, por ejemplo, en tu sitio web, ese tipo de... Así que la extensibilidad comienza. Cuando quieres, básicamente, personalizar más lo que ocurre tras bambalinas, quieres personalizar un poco más. Podrías ser el orquestador, si quieres personalizar el orquestador, si quieres personalizar tu interfaz, si quieres personalizar diferentes aspectos, donde, básicamente, Copilot Chat no puede hacerlo, no puede responder a la...

Y creo que mucha gente habla sobre los agentes.

¿Son?

¿Qué, por qué, por qué pensamos tanto ahora en los agentes de Copilot? Y un por qué, por qué, por qué no construimos, no sé, un gran Copilot para todo. Sí, es realmente interesante porque, ahora, para ser honesto, Microsoft, como dije antes, ha evolucionado mucho. Y tal vez, si estuviéramos seis meses atrás, vale, un agente era un tema. Ahora, Microsoft ha introducido Copilot Cowork. Y, para ser honesto, hoy en día, Copilot Cowork puede reemplazar a muchos agentes. Y, cuando pensamos en un agente, es solo para separar las cosas. Porque, ahora, estamos más en un modelo multiagente, donde cada agente tiene su alcance y sus responsabilidades. Y no hacemos un gran Copilot porque, básicamente, es simple debido al rendimiento. Primero, porque cuando tienes un gran conjunto de instrucciones y herramientas en términos de rendimiento, sería un desastre. Y la arquitectura ahora es más multiagente.

Podría ser en Copilot Studio, podría ser en agentes desarrollados a medida en términos de código o desarrollo personalizado. Pero, hoy en día, es mejor tener un enfoque multiagente, donde cada agente tenga su alcance y su responsabilidad en términos de rendimiento. Y tener una arquitectura clara para los agentes.

Y, cuando analizamos esto, creo que en una arquitectura básica de agente de IA, tenemos, diría yo, algunas contraseñas. Nosotros, contraseñas. Pero, tenemos que pensar en razonamiento, herramientas, conocimiento e instrucciones. ¿Cómo encaja esto en una arquitectura de agente de IA? Lo primero, en lo que hay que pensar, una de las primeras preguntas que hay que responder es, ¿cuál es el objetivo? El primer objetivo de este agente, básicamente, después de la arquitectura de la gente, realmente depende de si estás en un enfoque de código bajo o si estás en un enfoque de desarrollo personalizado. porque el planteamiento es totalmente diferente, ya que, en un desarrollo personalizado, lo gestionas todo. Así que, gestionas la seguridad, el alojamiento y muchas otras cosas diferentes. En el enfoque de código bajo, es muy distinto porque piensas en dar las instrucciones y seleccionar algunas herramientas.

Básicamente, la arquitectura en un enfoque de código bajo no es tan sencilla como dije, pero puede ser muy rápida porque puedes definir las instrucciones, seleccionar tus herramientas y elegir otros agentes si quieres conectarlos. Pero es muy simple. Cuando tratas con desarrollo personalizado o cuando desarrollas tu propio agente, podría ser, por ejemplo, Semantic Kernel, Agent Framework, ese tipo de cosas, la arquitectura podría ser mucho más compleja porque necesitas lidiar con conceptos realmente avanzados, como mencioné, la seguridad.

En términos de autenticación, si tienes, por ejemplo, múltiples herramientas, si quieres integrar algún API o conectarte a herramientas internas protegidas por proxy inversos, ese tipo de cosas. Básicamente, necesitas reflexionar más sobre la arquitectura cuando trabajas con agentes personalizados. Por ejemplo, en Copilot Studio, en cuanto a arquitectura, es muy rápido definirla. En un enfoque de desarrollo personalizado, tienes que lidiar con conceptos avanzados. Y para muchas personas podría ser difícil porque son aspectos fundamentales. Y en mi trabajo, para ser sincero, tengo que lidiar con muchas necesidades diferentes. Puede ser desarrollo a medida, Copilot Studio, o un agente sencillo, un Agent Builder, con una necesidad básica. Así que, básicamente, definir una arquitectura depende realmente del enfoque que quieras adoptar. Básicamente, tiene una arquitectura general que puedes crear, pero después realmente depende del enfoque.

Low code o pro code, ¿entiendes?

Pero podemos, puedes describir la anatomía de un agente de IA empresarial típico. Así pues, básicamente, para hablar de la forma más sencilla posible, cuando tienes una necesidad, por ejemplo, un agente de soporte técnico, básicamente, tienes un conjunto de cosas.

Pero hoy en día, como dije, tienes este enfoque multiagente. Y, básicamente, pongo al primer agente, como un friend, es un agente frontal. Y este agente frontal enrutará todas las solicitudes a través de, por ejemplo, diferentes agentes. Por ejemplo, si el usuario pregunta algo sobre Salesforce, el agente enrutará toda la solicitud al agente de soporte técnico de Salesforce. Ya ves, básicamente, para algunos clientes hemos creado este tipo de arquitectura porque cada agente se encarga de un ámbito. Puede ser para productos como Salesforce, puede ser para M365, ese tipo de cosas. Y tras bambalinas, cada agente tiene un conjunto de instrucciones y herramientas. Y, hoy en día, es mejor usar servidores MCP porque el servidor MCP es un conector universal para integrar múltiples servicios con la IA, DIA. Así que, tengo un conjunto de servidores MCP y también algunas fuentes de conocimiento internas.

Pueden ser como Jira, la base de conocimientos de ServiceNow, ese tipo de cosas. Así que, tienes un conjunto de instrucciones por agente. Esas instrucciones definen el alcance del agente y su rol. Y, luego, tienes los servidores MCP y, quizás, fuentes de conocimiento como archivos PDF. Así que, pueden ser varios tipos de fuentes de datos. Y, después, disculpa, cuando un usuario solicita, por ejemplo, al agente principal, después definirá, está bien. Necesito delegar esta tarea al agente respectivo.

Analicemos un poco las posibilidades.

En Copilot Studio, ¿dónde encaja en la arquitectura general?

Copilot Studio, para ser honesto, es una herramienta low-code de Microsoft. Así que, primero, en términos de arquitectura, Copilot Studio está realmente diseñado para creadores, básicamente, para personas que no son desarrolladores, principalmente.

Y, en términos de la arquitectura, básicamente, por ejemplo, si tomamos el ejemplo que usé antes, el soporte de TI, o, por ejemplo, Copilot Studio encajará. Porque, en términos de arquitectura, Copilot Studio hará el trabajo, porque puedes definirlo. Puedes definir un servidor en MCP. Puedes integrar fácilmente algunas fuentes de conocimiento externas o internas, si lo deseas.

O, después, como dije antes, si, por ejemplo, tienes un caso de uso donde quieres personalizar un poco el orquestador, porque detrás de Copilot Studio no puedes personalizar el orquestador, así que activas el orquestador de IA. Y eso es todo. No puedes, por ejemplo, personalizar la prioridad de, por ejemplo, la tarea que quieres lograr. Porque detrás de escena Copilot Studio definirá, está bien, tu plan, y después lo ejecutará.

Pero, si quieres tener un poco más de personalización, en este caso, necesitas usar desarrollo personalizado con, por ejemplo, Semantic Kernel, LandChain, un framework más reciente, porque Microsoft ha lanzado este framework y en esta fase puedes personalizar fácilmente la orquestación o puedes definir algunos flujos de trabajo. Puedes personalizar lo que quieras.

Ese es Copilot Studio como arquitectura que está realmente diseñada para constructores y creadores porque es realmente simple tener un agente funcionando. El único problema con Copilot Studio, y debes tener cuidado con esto, porque cuando defines, cuando eliges tu camino y tal vez defines tu arquitectura, necesitas ocuparte de la licencia porque es una gran parte de, de cada solución ahora U. Hoy en día, Copilot Studio ha evolucionado un poco hacia un modelo de pago por uso y hay que tener cuidado con la estimación de costos porque dependiendo de lo que quieras lograr, a veces es mejor optar por un desarrollo a medida ya que lo alojas donde quieres, controlas todos los costos y puedes estimar más fácilmente. Porque con el enfoque de créditos de Copilot a veces es difícil predecir cuánto costará durante uno o dos meses y ese tipo de cosas. ¿Y cuáles son las limitaciones de Copilot Studio?

Estudio, ¿cuándo debería elegirlo? Pienso en Microsoft Foundry, Azure Foundry, no estoy seguro de cuál es el nombre real. Y cuando debo decir, bien, debo hacer un desarrollo completamente a medida.

La pregunta que hay que responder es,

necesito personalizar. ¿La orquestación? Esa es mi primera pregunta porque te dirá, bien, si no quieres personalizar la orquestación, si no quieres profundizar en cómo se hace toda la orquestación o cómo se genera el plan, puedes usar un enfoque de código bajo con Copilot Studio. Por ejemplo, un constructor. Además, a veces, cuando tienes casos de uso sencillos, puedes usar este tipo de herramientas. Pero si quieres personalizar la orquestación, necesitas recurrir a un desarrollo específico y en ese caso, necesitas usar Foundry para el modelo o si tienes tu propia plataforma, porque la ventaja del desarrollo, a medida que puedes integrar modelos que no están alojados en Microsoft Foundry. Si quieres, puedes usar los modelos de Foundry, pero si usas AWS o la plataforma de Google y tienes, por ejemplo, Keminine o has implementado un modelo externamente, tienes la capacidad de integrar esos modelos directamente en tu agente cuando usas un enfoque personalizado.

Esta también es una ventaja y además puedes personalizar la orquestación, cómo se genera el plan y todo lo que ocurre dentro de Agent Foundry. El problema de Foundry hoy en día es que al principio Foundry era solo una plataforma de alojamiento de modelos. Si miras hacia atrás, hace unos años, era solo un catálogo de modelo sencillo que implementabas. Hoy en día, Microsoft ha hecho evolucionar este producto para que, bueno, puedas crear agentes con una interfaz de usuario tipo Copilot Studio, básicamente sin código, básicamente sin código. Puedes gestionar la gobernanza, puedes gestionar muchas cosas. Buir se convirtió en una plataforma realmente agéntica como Copilot Studio para soluciones de bajo código y cosas así. Y hoy en día, Foundry, es muy difícil de ubicar en el ecosistema porque está evolucionando rápido.

Básicamente, Microsoft ha introducido funciones que son, no sé, no diferentes, pero tienen similitudes. Con Copilot Studio, en cuanto a la integración de MCP y cosas así, pero la principal limitación de Copilot Studio tiene que ver con los modelos. Así que tienes la capacidad de integrar código o visualizar este tipo de cosas, pero si quieres integrar, por ejemplo, tu propio modelo porque tienes una versión específica, no puedes hacerlo y básicamente necesitas usar un desarrollo personalizado para integrar tu propia plataforma de LM si la tienes. Tengo clientes que tienen su propia plataforma de AWS. En este caso, puedes integrar ese modelo con precios gestionados externamente.

Vale, vale. Y creo que cuando construimos un agente, un tema importante es todo este revuelo. Hola.

Schopenhauer.

La mayoría de la gente habla de MCP, el Model Context Protocol, porque se ha convertido en uno de los temas más importantes en el desarrollo de agentes y para alguien que aún no ha trabajado con él, que es el Model Context Protocol. Es. Sí, es un término importante. Básicamente, mucha gente habla de esto porque resuelve un problema importante. Es como unificar la integración de herramientas, habilidades. Tal vez, no sé, herramientas externas a la guía y resuelve este problema porque en el pasado sin MSP era un lío porque muchos servicios se comunicaban de forma diferente. Tienes diferentes protocolos tecnológicos, diferentes enfoques de arquitectura y básicamente MSP unifica cómo integras servicios a tu agente de IA o solución de IA si soy más genérico, pero MSP ahora es realmente la forma de integrar herramientas externas o internas pueden ser ambas. pero MSP ahora es una gran parte de la arquitectura de IA porque tienes esta unidad en términos de tecnología y hoy en día es un punto importante porque en el pasado era la integración mediante API y ahora es MSP.

Esto no es la evolución pero en el pasado integrabas tu agente con una API tenías que gestionar ¿cómo autenticar? ¿o cómo gestionar eso? ¿o cómo llamar a la herramienta? Ahora la IA puede decir vale tengo esta herramienta disponible puedo seleccionar lo que necesito para lograr el objetivo ¿qué es lo que realmente ha cambiado del MSP respecto a la conexión API?

Básicamente en el pasado de integración las API no son inteligentes si se puede decir así las API son solo ¿vale? llamas a una herramienta y te da datos la diferencia con MSP es MSP es más inteligente en términos de arquitectura porque detrás de escena no solo tienes herramientas que te dan datos o información sino que también tienes habilidades instrucciones y diferentes tipos de cosas que hacen que MSP sea realmente inteligente y básicamente MSP puede decirle a la IA ¿vale? ¿quieres lograr eso? puedo darte las herramientas exactas que coinciden con tu solicitud y no solo puedes llamar a una herramienta sino que necesitas llamar a estas herramientas para lograr lo que quieres este es el rol de MSP le da a la IA ¿vale? tengo estas herramientas y después puedes llamar a esta o a esta otra o a múltiples herramientas para alcanzar tus objetivos le da a la IA el contexto el contexto real de todo y la API es solo ¿vale?

tienes herramientas tienes descripciones y eso es casi todo sí que es es el protocolo de contexto de modelo creo es similar a a los metadatos ¿o cómo funciona?

no MSP detrás de escena es es un protocolo es básicamente es un es un protocolo tecnológico y detrás de escena tienes sí tienes metadatos tienes descripciones tienes habilidades de IA descritas más está realmente enfocado en la IA básicamente tienes habilidades tienes instrucciones y básicamente la IA puede entender mejor ¿vale? estas herramientas hacen eso esta herramienta hace aquello ¿vale? puedo llamar a estas habilidades puedo solicitar esta información al servidor MSP para lograr mi tarea pero tienes sí tienes una parte de metadatos porque necesitas definir bueno el nombre de la herramienta y qué es lo que hace tras bambalinas mira podemos decir que el futuro es MSP así que tenemos que empezar a pensar no sé las empresas tienen cientos de APIs REST en su organización deberían empezar a crear servidores MSP para ellas sí básicamente el servidor MSP trabaja con APIs tras bambalinas esto no es un reemplazo básicamente si lo resumo el servidor MSP es solo ¿está bien?

probé el contexto de tras bambalinas el MSP puede llamar a las APIs tras bambalinas pero el servidor MCP es una interfaz la herramienta frontal que necesitas llamar porque detrás se encargarán de distribuir tu solicitud tras bambalinas puede ser una API una base de datos o múltiples herramientas pero si quieres tener tu propio servidor MCP por ejemplo si tienes internamente en tu empresa APIs y diferentes tipos de servicios no sé financieros o de recursos humanos si quieres crear tu propio MCP necesitas gestionar tras bambalinas todas esas APIs y el servidor MSP tendrá que exponer las cuales son los servicios las herramientas disponibles las habilidades y ese tipo de cosas luego necesitas gestionar la autenticación tras bambalinas porque las APIs no funcionan igual puedes tener autenticación por clave o por otros métodos así que debes manejar eso pero el MSP expondrá las herramientas disponibles y tras bambalinas todas esas herramientas pueden consultar múltiples APIs una API o podrías tener diferentes tipos de arquitectura tras bambalinas de acuerdo y cómo hace el MSP cómo elige la herramienta correcta cuando tengo no sé 100 o 500 agentes de ahí te basará primero que nada en algo básicamente cuando recibes una solicitud en un agente descubrirás todas las herramientas disponibles el servidor MSP verificará muy bien tengo todas estas herramientas disponibles básicamente el orquestador de la gente entenderá de acuerdo tengo esto tengo un LM disponible después crearás el plan si resumo un poco crearás un plan con alguna acción por hacer y después en esta acción que quieres ejecutar puedes llamar a una dos tres o más herramientas para lograr la tarea que el usuario ha solicitado así que básicamente el orquestador de la gente entenderá las herramientas MSP y seleccionará la mejor para la solicitud ya ves y este es realmente el papel del orquestador seleccionar herramientas y este tipo de cosas con la ayuda del LM por supuesto porque el LM es parte del cerebro y el orquestador se comunicará con el LLM y también con las herramientas para tomar la mejor decisión y hacer el mejor plan para lograr la tarea sí creo que durante un tiempo muchas empresas empezaron con PowerShell y ahora usan Microsoft Graph API ¿Graph y MSP vienen?

¿O como?

Sí y creo que en realidad siendo honesto no no hay un MCB para Graph si lo nombras sabes ahora en el mundo de Microsoft 365 Microsoft ha introducido muchos servidores MCP y esos servidores MCP se basan en segundo plano en Microsoft Graph por ejemplo si quieres usar no sé el servidor MCP de Teams detrás de escena se está llamando a la AP de Graph cuando usas un servidor MCP así que Graph API en el mundo de Microsoft 365 es central porque detrás de escena el MCP se comunicará con Graph para que la solicitud funcione correctamente pero sí hoy en día Graph también es central en Copilot en general porque el índice semántico de Copilot se basa en datos sin procesar pero en realidad consumes Graph a través de servidores MCP hoy en día es así Microsoft 365 contiene un valor increíble con texto organizacional documentos reuniones correos electrónicos personas equipos conversaciones y contenido compartido ¿cómo exponemos ese contexto sin crear una pesadilla de seguridad?

¿te refieres a términos de gobernanza este tipo de cosas? Sí siempre es un problema porque mucha gente está creando agentes sin una gobernanza adecuada detrás de escena así que quiero construir un agente bien vamos allá construimos y desplegamos y después ah pero este agente manejará muchos datos ¿cómo gestionamos eso? la primera pregunta es bien ¿cómo implemento la gobernanza de la gente? antes podría ser como dijiste un desastre porque mucha gente dice quiero construir un agente otro o quiero construir una solución de ya pero detrás de escena en un contexto de Microsoft 13 C65 por ejemplo una de las primeras cosas es entender tus datos porque sin entender tus datos estás perdido necesitas entender tus datos porque es importante saber si estoy tratando con datos confidenciales o no estoy tratando con datos altamente confidenciales de acuerdo necesitas entender tus datos después si estás en un entorno Microsoft necesitas implementar por ejemplo funciones de LP etiquetado de sensibilidad y cosas así porque sin esto podría ser un problema y después necesitas limpiar un poco tus datos porque la IA con datos deficientes no funcionará como quieres si tienes un desorden en SharePoint o en un canal de Teams será difícil que funcione correctamente con un enfoque de agentes pero si necesitas entender tus datos necesitas implementar una seguridad básica como la autenticación y las funciones de Purview que se ha convertido en la solución central para establecer toda esta seguridad y gobernanza y después cuando ya hayas limpiado tus datos y establecido cierta seguridad básica también debes entender las licencias porque antes de empezar a crear agentes necesitas saber si los desarrolladores están capacitados si tenemos las licencias correctas para empezar a trabajar o si necesitamos suscripciones ese tipo de cosas un gran problema son las herramientas como integro correctamente todas las herramientas en mi desarrollo y en mis agentes necesito restringir algo para ser sincero es una gran pregunta hay muchas actividades que considerar pero para mí lo más importante es entender tus datos si una empresa no entiende sus datos tendrá problemas desde el principio siendo honesto vale y cuando nosotros lo hicimos lo preguntamos el tema de la seguridad creo que hay dos dos sí dos tipos de personas unos dicen que necesitan permisos de usuario y otros dicen que necesitan permisos de aplicación ¿cómo deberían operar los agentes generalmente y en general mi mejor recomendación es que cuando necesites tratar con soluciones de agentes siempre lo hagas con permisos delegados de usuario porque en términos de seguridad es mejor ya que el usuario sólo tratará con los datos y herramientas a los que tiene acceso ese es el principio fundamental después si necesitas permisos de aplicación para algo específico no sé una API concreta o un contexto específico puedes hacerlo pero no uses directamente permisos de aplicación hazlo en el contexto de un envoltorio wrapper creas no sé podría ser un servidor MSP por ejemplo integras este MSP con permisos de aplicación en segundo plano así el MCP llamará por ejemplo a tu API en segundo plano con permisos de aplicación y te dará la información necesaria pero el usuario no interactúa directamente con los permisos de aplicación llamamos al servidor MCP con permisos de usuario por ejemplo y el servidor MCP llamará en segundo plano a las aplicaciones o servicios con permisos de aplicación dedicados con iCray ¿Ves la diferencia?

Vale de acuerdo interesante creo que cuando pensamos en arquitectura también debemos profundizar un poco más creo que hay tres grandes temas en arquitectura tenemos la generación de argumentos de recuperación tenemos el tema del conocimiento y tenemos lo que yo llamo búsqueda empresarial con puerta trasera ¿Dónde comencemos con RAG? ¿Dónde encaja RAG en la arquitectura?

A RAG para ser honesto RAG es en realidad lo más importante en cuanto a rendimiento porque la IA necesita entender diferentes tipos de datos y básicamente RAG está aquí para responder una pregunta porque en el pasado cuando no tenías RAG básicamente tenías que lidiar con enfoques diferentes no somos de la vieja escuela pero era complicado pero RAG es central porque entenderá diferentes tipos de datos y básicamente recuperarás la información que la IA necesita pueden ser documentos pueden ser múltiples tipos de datos así que si RAG es central hoy en día en la arquitectura de IA sí pero es cierto que para muchos usuarios cuando hablas de RAG detrás de escena no saben qué es porque Microsoft hoy en día o muchas empresas de software no hablan de esto ya que detrás de escena tienes RAG pero por ejemplo en Copilot Studio el usuario no entiende que detrás está RAG ¿ves? y hoy en día cuando quieres profundizar tienes este tipo de concepto pero para muchos usuarios RAG es algo que desconocen totalmente porque sólo usan la herramienta y detrás de escena están esos conceptos y luego tenemos el siguiente tema que es el conocimiento cómo obtenemos esto de dónde obtienen su conocimiento los sistemas de IA es que recopilo paneles o cómo funciona esto en realidad tienes que ser honesto el conocimiento es podría estar alojado en muchos sistemas diferentes podría ser un archivo de texto plano podría ser un archivo markdown podría ser una base de conocimientos podría ser cualquier cosa podría ser cualquier pero en realidad si tienes un servidor MSP puedes acceder a ese conocimiento o si tienes por ejemplo no sé conectores a SharePoint tienes conectores a muchos servicios hoy en día así que acceder al conocimiento es más fácil que antes seamos honestos porque en el pasado necesitabas crear tu plugin y visitar todo hoy en día usted tiene un conector directo a cualquier sistema puede integrar su conocimiento sin tener que lidiar con un gran equipo de desarrollo yo creo a menudo tenemos no sé me conecto con mi digo a mi no sé alguien un y cómo entiende la IA que documentos no están listos o están desactualizados o no sé duplicados cómo cómo entiende esto un sistema de IA que deberíamos usar y que no básicamente usted está usando RAC porque detrás de escena necesita entender ok cuáles son sus datos pero para ser honesto si resumen un poco usted comienza del prompt ok el usuario quiere ok quiere por ejemplo buscar a través de no sé una base de conocimientos y por ejemplo OneDrive detrás de escena cuando el orquestador con la ayuda de un modelo de lenguaje entiende el prompt y la intención del usuario detrás de escena usted tiene el índice básicamente porque por ejemplo en Copilot usted tiene el índice semántico y este índice semántico le da básicamente ok tengo todo este conocimiento y usted puede con una consulta al índice semántico la IA puede consultar directamente el índice semántico para realizar RAGE por ejemplo y puede seleccionar directamente los documentos correctos según sus necesidades pero en Copilot usted tiene este índice semántico y la IA puede consultar directamente este índice con lenguaje natural detrás de escena así que preguntaré ok quiero entender no sé cómo configurar la AVPN de mi empresa y detrás de escena usted realizará RAC en el índice semántico y básicamente recuperará el documento que contiene por ejemplo toda la configuración de la VPN de la empresa por ejemplo en el chat de Microsoft 365 Copilot detrás de escena es Graph AP ¿por qué?

porque como dije antes usted tiene el índice semántico construido sobre Graph AP es una función de Graph detrás de escena pero cuando usted tiene un desarrollo personalizado tiene por ejemplo Foundry AI detrás de escena era un servicio de Azure con un nombre diferente pero ahora usted puede tener su propio sistema RAC si lo desea y básicamente puedes cuando tienes un agente personalizado puedes preguntarle directamente a esta instancia de Foundry AIQ vale quiero usar quiero obtener la configuración de mi empresa de VPN y la IA puede recuperar lo que necesites en términos de documentos podrían ser PDFs Word Excel ese tipo de cosas y así es como funciona la búsqueda ¿verdad?

¿detrás de escena te refieres? a detrás de escena tienes la búsqueda pero básicamente hoy en día tienes detrás de escena de Copilot Chat tres capacidades tienes la búsqueda estándar que es básicamente una búsqueda donde simplemente pones algunas palabras clave y buscará en tus documentos y cosas así esta es una búsqueda simple todos conocemos la búsqueda por palabras clave como en Google después tienes dos capacidades diferentes primero tienes el RAC detrás de escena tienes la capacidad de RAC en graph y también la búsqueda del índice semántico de Copilot que es un poco diferente porque RAC es realmente más avanzado que la búsqueda del índice semántico de Copilot pero tienes estas tres capacidades detrás de escena para que no tú sino la IA pueda invocar estas tres capacidades diferentes para recuperar datos en OneDrive Teams y M365 en general el índice semántico de Copilot también incluye los conectores de Copilot entonces por ejemplo si has conectado Salesforce con el conector de Copilot también puede buscar en todos tus datos en Salesforce en ServiceNow y en múltiples herramientas porque con el conector de Copilot al haber integrado todos los datos en el índice de graph y el índice semántico puedes consultar directamente tus sistemas externos vale y creo que cuando creamos agentes tenemos la parte de gobernanza y para mí una de las partes es la gestión del ciclo de vida de la gente ¿cómo se ve esto en realidad?

¿cómo es en realidad? para ser honesto en el ecosistema de Microsoft es bastante sencillo si puedo decirlo así porque cuando trabajas con código bajo por ejemplo Copilot Studio trabajas con Power Platform concepto IAM y nada ha cambiado así que tienes soluciones tienes ALM implementado y tienes pipelines entonces cuando trabajas con Copilot Studio para ser honesto es igual que antes porque tienes todo lo que invertiste en términos de gobernanza ciclo de vida y ALM de Power Platform es estrictamente lo mismo esto es algo bueno porque mucha gente me pregunta Copilot Studio ¿cómo se gestiona? ¿es diferente? no es realmente simple como la gestión del ciclo de vida de aplicaciones en Power Apps o Power Automate así que en este caso es gestión del ciclo de vida de agentes pero tras bambalinas es el mismo concepto que en Power Platform y cuando lidias por ejemplo con desarrollo personalizado básicamente es como cuando construyes aplicaciones aplicaciones.net ese tipo de cosas porque gestionas todo como código entonces tienes marcos de trabajo tienes aspectos de seguridad y ese tipo de cosas y así que todo para ser honesto en términos de gestión del ciclo de vida aplicaciones y agentes es realmente el mismo concepto que antes y este es un buen punto para mí porque no tienes que invertir mucho en términos de procesos de ciclo de vida ese tipo de cosas pero el único tienes algunos cambios pero uno de los grandes cambios es bien debes encargarte del LM este tipo de cosas el despliegue ese tipo de temas pero tras bambalinas se ve como el enfoque DevOps del pasado con tuberías pipelines y ese tipo de cosas así que en mi opinión nada ha cambiado porque gestionamos agentes podría ser desarrollo personalizado Copilot usas el mismo enfoque que antes para ser honesto hoy en día y esto significa o cuando una empresa no ha usado IA antes en la compañía pero tiene la configuración perfecta para Purview para Defender y todas las herramientas ¿hay algún cambio que hacer?

o esto significa preparación para la IA es una gran pregunta porque la preparación para la IA para Microsoft está bien o estás compartiendo permisos gestionando este tipo de cosas pero ok la preparación para mí no es solo un enfoque técnico porque vale técnicamente sabemos qué hacer bien necesitamos gestionar permisos a través de muchos servicios ¿sabes? para mí la preparación para la IA debe incluir también los datos los datos ¿entiendes? porque cuando no entiendes tus datos como dije antes no puedes tomar no puedes gestionar la parte técnica porque cuando no sabes qué es confidencial o no por ejemplo es difícil implementar algunas algunas medidas de seguridad algunas cosas de seguridad pero si si seguimos a Microsoft la preparación para la IA está bien tienes que gestionar permisos quieres implementar etiquetas de confidencialidad tienes que cumplir con el RGPD ese tipo de cosas pero también tienes un aspecto de más alto nivel y para mí la preparación para la IA no es solo técnica también tienes un aspecto funcional o de alto nivel que considerar para ser honesto hoy en día sí eso es muy interesante creo que muchas empresas que empezaron con esto de la IA pero ahora con los agentes muchas empresas dicen oh borró todos mis no sé correos electrónicos o está haciendo cosas malvadas ¿qué piensas que dirán las empresas temen a la IA a IA?

es una buena pregunta porque vivo en Suiza y básicamente tenemos muchos bancos privados y tenemos muchos para ser honesto clientes realmente sensibles para ser honesto y básicamente la parte más crítica es dónde se procesan los datos para básicamente y sí también está la IA buscando en mis correos electrónicos ese tipo así que detrás de la escena ellos siempre preguntan esto pero sabes la parte más crítica para ellos es vale necesito entender dónde se procesan los datos y también vale yo soy el

propietario de la IA así que yo yo le doy la instrucción a la IA y la IA detrás de escena hará el trabajo y tiene miedo por ejemplo del aspecto autónomo porque hoy en día vale puedes hacer eso y detrás de escena la IA buscará algo una consulta algo detrás de escena y tienen miedo de vale cuando le pido a la IA que haga algo ¿qué está realizando detrás de escena? y si hay muchas dudas como esta vale ¿cómo puedo tomar el control de todo el proceso detrás de algo ya sea un agente de IA o un servicio de IA? sí existen preguntas como esta pero es realmente una cuestión de adopción y también de capacitación para implementar formación sobre cómo entender la IA cómo entender lo que se realiza exactamente detrás de escena y la transparencia es también un punto importante porque la transparencia debe implementarse en cada solución de IA ya que para mí es un tema clave necesitas implementar todo porque tu solución de IA debe ser transparente necesitas entender qué se realiza detrás de escena qué datos se consultan necesitas rastrear y necesitas registrar todo así que todo debe ser transparente hoy en día cuando tienes una solución porque necesitas entender exactamente qué se ejecuta detrás qué datos se procesan y cuál es el razonamiento detrás de escena ¿cómo has generado este plan basado en qué hechos y ese tipo de cosas?

Increíble Oh, veo que nos estamos quedando sin tiempo Lo siento Sabes, esto fue realmente increíble pero en cada podcast tengo una ronda de preguntas rápidas así que yo digo una frase corta y tú das una respuesta corta y entonces ¿estás listo? Copilot Studio o código personalizado Copilot Studio Microsoft Foundry o Copilot Studio Copilot Studio TypeScript o Cypscript GitHub o Azure DevOps Git Drag o ajuste fino Fine Tuning Está bien ¿Cuál es la API de Microsoft 365 más subestimada?

La API de Rack Una tecnología que todo desarrollador de Microsoft debería aprender en 2026 GitHub Copilot un cuando Satan viene a ti y te dice que tienes todo el dinero y los recursos que quieras para mejorar nuestra plataforma de EAE puede desarrollar una función ¿Cuál sería? Todas las herramientas de gobernanza que necesitamos IAM ¿A quién debería invitar al próximo podcast y qué pregunta debería hacer?

Buena pregunta Tengo muchos amigos pero sí tal vez puedas preguntarle a mi co-conferencista en muchas conferencias puedes preguntarle por ejemplo a Chloe Moro ella era consultora funcional antes de dedicarse al lado técnico ahora y tiene una historia realmente buena sobre temas funcionales menos técnicos en el mundo de Dynamics así que tal vez puedas invitarle preguntarle bien cuéntame dime hoy en día cómo lidiar entre el trabajo funcional y técnico porque ahí tienes algunos desafíos muy muy grandes Sí y mi pregunta final es que debería la gente cuando puedan llevarse una una lección de esta sesión ¿Qué deberían llevarse?

De esta sesión ¿Te refieres a?

Básicamente la EAE está evolucionando rápido y si quieres estar al día hoy en día tienes que seguir todo porque hoy en día la EAE está realmente en todo el stack de Microsoft para ser honesto y hoy en día una de las que necesitas entender es que la evolución es rápida y necesitas estar al día realmente en todo momento porque te perderás algo en algún punto si no si no aprendes si no entiendes la evolución en este tipo de cosas sí así que gracias por acompañarme creo que la lección importante de esta conversación es que la extensibilidad de Microsoft 305 Copilot no se trata simplemente de escribir prompts cada vez más sofisticados creo que nos dirigimos hacia una arquitectura donde Copilot y los agentes pueden conectar el conocimiento organizacional Microsoft Graph aplicaciones de negocio AP y demás sí creo que Copilot Studio Microsoft Foundry el desarrollo personalizado y tecnologías como MCP les dan a los desarrolladores una caja de herramientas increíble y potente y sí pero cuanto más sí capaces se vuelven los agentes más importantes se vuelven también los fundamentos de identidad permisos seguridad gobernanza pruebas observabilidad gestión del ciclo de vida de las aplicaciones y demás así que sí creo que has dado un resumen realmente realmente bueno de todos estos temas así que gracias por acompañarme y para los oyentes toda la información sobre si la encuentran en las notas del programa en la página del podcast M365 FM y sí donde pueden conectar y ver el trabajo de ES y sí gracias por estar aquí gracias por invitarme fue un momento realmente bueno contigo gracias por ver el video y gracias por ver el video