Microsoft apuesta por una plataforma de IA: cómo evaluar el cambio

En su publicación, Microsoft asigna a Copilot el papel de punto de interacción con la IA, a Microsoft IQ la función de ampliar la inteligencia de la organización y a Agent 365 la de facilitar gobierno, seguridad y observabilidad. La compañía acompaña este planteamiento con casos empresariales y resultados que atribuye a sus clientes. Ese es el contenido informativo que tomamos como punto de partida. A continuación desarrollamos un análisis propio: qué preguntas convendría formular antes de convertir una propuesta de plataforma en una decisión de inversión, y qué evidencias permitirían comprobar su utilidad en un entorno concreto.

Nuestra lectura es que el interés de esta propuesta reside en la relación entre sus piezas. Una interfaz cómoda puede resultar insuficiente si consulta información inadecuada; disponer de buenos documentos tampoco resuelve quién está autorizado a ejecutar una acción. Para evaluar el conjunto proponemos empezar por un proceso reconocible, como preparar una respuesta de soporte o revisar una solicitud de compra. Habría que identificar dónde entra la información, qué decisiones se toman y quién responde por ellas. Ese recorrido permitiría discutir necesidades concretas sin confundir la amplitud del catálogo con la adecuación de cada herramienta al trabajo que se pretende mejorar.

Como criterio de evaluación, empezaríamos por describir una dificultad con suficiente precisión para poder observarla. Decir que un departamento necesita ser más productivo deja demasiadas interpretaciones abiertas. Una formulación útil sería investigar por qué una petición pasa varias veces entre equipos antes de recibir respuesta. Quizá falte información al principio, quizá haya instrucciones contradictorias o quizá nadie tenga asignada la decisión final. En ese ejemplo hipotético, un asistente podría ayudar a reunir antecedentes, pero la organización tendría que resolver previamente las responsabilidades. Automatizar un recorrido confuso podría acelerar algunos pasos y mantener intacta la causa de las devoluciones.

El siguiente paso sería fijar qué resultado justificaría el cambio. Para una consulta interna, podríamos valorar la proporción de respuestas aceptadas sin correcciones, el tiempo completo hasta resolver la petición y el esfuerzo que exige revisarla. Conviene incluir también los casos que se abandonan o terminan en otra vía, porque excluirlos haría demasiado favorable la comparación. Nuestra recomendación es documentar el funcionamiento inicial con ejemplos representativos y repetir la observación bajo condiciones comparables. Así, una mejora tendría un significado concreto para el equipo y sería posible discutir si compensa el trabajo adicional de configuración, formación y supervisión.

Desde nuestro análisis, conectar información exige decidir primero cuál merece orientar una respuesta. Pensemos en una empresa ficticia que conserva un procedimiento vigente, una versión anterior y varias notas de reuniones sobre posibles cambios. Si una consulta pregunta cómo tramitar una devolución, sería razonable dar prioridad al documento aprobado y distinguirlo de una propuesta pendiente. Antes de evaluar cualquier asistente, pediríamos un inventario de fuentes con responsables, fechas de revisión y criterios de autoridad. Este trabajo permitiría detectar discrepancias que ya afectan a las personas y definir cómo deberían tratarse cuando interviene un sistema automatizado.

También propondríamos separar la posibilidad de encontrar un documento de la autorización para utilizarlo en cada contexto. Un expediente podría contener información pertinente para resolver una incidencia y, al mismo tiempo, detalles que el destinatario de la respuesta no necesita conocer. La evaluación debería incluir preguntas sobre la selección de fragmentos, la actualización de permisos y la retirada de contenidos obsoletos. Si una política cambia, ¿cómo se comprobaría que las respuestas dejan de apoyarse en la versión anterior? Esta es una pregunta de diseño y verificación, no una afirmación sobre capacidades específicas de las herramientas mencionadas por Microsoft.

Para valorar una plataforma de agentes, proponemos distinguir entre consultar, redactar y actuar. Localizar una instrucción, preparar un correo y modificar un pedido tienen consecuencias diferentes, aunque puedan aparecer en una misma conversación. En un ejemplo hipotético de compras, el sistema podría reunir presupuestos y elaborar una comparación para que una persona la revise. Autorizar el gasto requeriría otra decisión, con criterios explícitos sobre importes, proveedores y responsables. Definir estos límites antes del despliegue permitiría probar cada etapa por separado y evitar que una petición ambigua termine interpretándose como permiso suficiente para completar una operación.

Una revisión humana solo tendría sentido si ofrece información útil para decidir. Si la persona recibe una petición de aprobación sin antecedentes, tendría que reconstruir el caso o aceptar una conclusión que no puede comprobar. Por eso evaluaríamos qué datos acompañan a cada acción propuesta: origen de la solicitud, información utilizada, cambios previstos y posibles alternativas. También convendría determinar qué ocurre cuando nadie responde, cuando aparecen datos contradictorios o cuando el solicitante modifica su petición. En nuestro criterio, esas situaciones deberían tener una salida definida, como detener el proceso o devolverlo al responsable, en lugar de quedar sujetas a improvisaciones.

La observabilidad resulta relevante para este análisis porque una respuesta final explica poco sobre cómo se ha producido. Para evaluar un proceso automatizado, pediríamos poder reconstruir qué se solicitó, qué información estuvo disponible y qué acciones se intentaron. Esto permitiría distinguir, por ejemplo, una fuente desactualizada de una interpretación incorrecta o de una autorización mal configurada. Se trata de un requisito que proponemos comprobar, no de una prestación que demos por garantizada. Además, el registro tendría que ser comprensible para quienes investigan incidencias; acumular detalles técnicos sin un propósito concreto podría dificultar la revisión que se pretendía facilitar.

Registrar actividad también obliga a elegir qué conservar y quién puede consultarlo. En un supuesto de atención al cliente, copiar íntegramente cada documento en todos los registros podría multiplicar la presencia de información que solo necesitaba utilizarse en un paso. Nuestra recomendación sería vincular cada dato conservado con una necesidad de diagnóstico o responsabilidad. Habría que acordar plazos, accesos y procedimientos para investigar fallos sin convertir la supervisión en una colección indiscriminada de contenido. Una prueba útil consistiría en entregar una incidencia simulada al equipo responsable y comprobar si consigue explicar lo ocurrido con los registros previstos para ese proceso.

Desde una perspectiva económica, proponemos calcular cuánto cuesta terminar correctamente el trabajo. El precio de acceso a una herramienta sería solo una parte de esa evaluación, junto al tiempo de preparación de datos, integración, revisión y mantenimiento. Pensemos en un asistente hipotético que redacta respuestas rápidamente, pero obliga a comprobar muchas referencias. Para saber si ayuda, habría que observar el tiempo total de resolución y la calidad obtenida después de corregirlo. Este enfoque permitiría identificar una mejora real aunque sea modesta y descartar una aparente ganancia que solo haya desplazado esfuerzo hacia otra persona o hacia una etapa menos visible.

La comparación debería considerar igualmente qué uso se hace del tiempo liberado. Si una tarea se acorta, convendría comprobar si el equipo puede atender más peticiones, reducir una espera o dedicar mayor atención a casos difíciles. No atribuiríamos automáticamente un ahorro económico a cada minuto estimado. También prepararíamos escenarios de utilización baja, habitual y elevada, sin asignar cifras que no estén documentadas. El propósito sería descubrir qué partidas varían con la actividad y cuáles permanecen. Antes de ampliar el despliegue, la organización debería poder explicar qué resultado espera, cuánto esfuerzo necesita sostenerlo y en qué condiciones dejaría de compensar.

Nuestra lectura de una estrategia de plataforma incluye una pregunta sobre la capacidad de cambiar de rumbo. Antes de concentrar procesos en un mismo entorno, evaluaríamos cómo se recuperan documentos, instrucciones, configuraciones y registros relevantes. También preguntaríamos qué conocimientos quedarían documentados fuera de las conversaciones individuales con asistentes. En un escenario hipotético, un departamento podría querer sustituir una pieza sin reconstruir todo su procedimiento. La facilidad para hacerlo debería comprobarse mediante una prueba acotada de exportación o sustitución, cuando sea posible, y mediante documentación verificable para aquello que no pueda ensayarse todavía. Una promesa general de flexibilidad dejaría demasiados detalles pendientes.

La continuidad merece una evaluación independiente. Propondríamos escoger una tarea esencial y describir cómo se completaría si el componente de IA no estuviera disponible o produjera resultados que requieren investigación. El procedimiento alternativo debería señalar dónde están las instrucciones, quién decide y cómo se reconcilian después los cambios. Este ejercicio serviría también para delimitar qué tareas pueden esperar y cuáles necesitan atención inmediata. No implica anticipar un fallo concreto de los productos citados; es una forma razonada de evaluar cualquier dependencia operativa. Una organización estaría mejor preparada para decidir si conoce tanto el recorrido habitual como el esfuerzo necesario para mantener una vía alternativa.

Como propuesta práctica, comenzaríamos con un proceso limitado, un responsable identificable y un conjunto variado de casos. La prueba debería incluir solicitudes habituales, información incompleta, documentos contradictorios y peticiones que excedan los permisos previstos. En cada caso habría que acordar de antemano qué respuesta sería aceptable: resolver, pedir aclaraciones, rechazar una acción o trasladarla a otra persona. Así se podría valorar también la capacidad de reconocer límites. Elegir únicamente ejemplos sencillos ofrecería poca información sobre el trabajo de supervisión posterior. La finalidad del piloto sería descubrir condiciones de uso útiles y fallos corregibles antes de extender su alcance.

Durante esa prueba, daríamos espacio a quienes realizan el trabajo para registrar dificultades concretas. Interesaría saber qué sugerencias revisan con facilidad, cuáles generan dudas y qué pasos les obligan a salir del proceso habitual. La formación debería centrarse en decisiones: cuándo confiar en una fuente, cómo verificar una propuesta y dónde comunicar un error. También fijaríamos criterios para continuar, modificar o detener la prueba. Si no se cumplen los objetivos, el resultado seguiría aportando información sobre el proceso y sus requisitos. Evitaríamos interpretar el mero uso frecuente como demostración suficiente de calidad, utilidad o preparación para una ampliación.

Para decidir una ampliación, pediríamos un balance que conecte resultados y límites. Ese documento debería describir qué tareas se han evaluado, en qué condiciones, con qué revisión y qué problemas siguen abiertos. También convendría identificar quién mantendrá las fuentes, actualizará instrucciones y atenderá incidencias cuando termine el piloto. Nuestra recomendación es incorporar el mantenimiento a la decisión inicial, porque una prueba puede contar con una atención excepcional difícil de sostener. El paso siguiente tendría sentido si existe capacidad para conservar la calidad observada y si los responsables entienden qué partes del proceso continúan dependiendo de su criterio y de su intervención.

Quedan además preguntas que esta comunicación corporativa no resuelve para una compra concreta: qué componentes necesita cada escenario, qué condiciones contractuales corresponden y qué disponibilidad aplica al entorno elegido. Esos puntos exigirían documentación específica antes de presupuestar o planificar una implantación. Desde el análisis editorial, el movimiento de Microsoft merece atención porque invita a examinar conjuntamente interacción, información y control. Para una organización que esté valorando la IA, el ejercicio útil sería recorrer una tarea de principio a fin y exigir evidencias en cada transición. El alcance del despliegue debería seguir a esas comprobaciones y a los resultados obtenidos en su propio contexto.