Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / ¿De verdad necesitas un agente de Copilot Studio? Cómo deciden las personas y los casos de uso reales (Doblaje IA)

Transcript

¿De verdad necesitas un agente de Copilot Studio? Cómo deciden las personas y los casos de uso reales (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

• 0:00
  Speaker 2: Estás listo para 10 días de Microsoft 365, Copilot y
• 0:04
  Speaker 2: Azure y las personas que están dando forma al futuro
• 0:06
  Speaker 2: del trabajo? Este enero, regresa MM365 contado. Únete a nosotros
• 0:13
  Speaker 2: para sesiones en vivo. Demostraciones reales y conocimientos prácticos de
• 0:16
  Speaker 2: MVP y expertos de la industria de todo el mundo.
• 0:18
  Speaker 2: Nada de diapositivas en Eric. Nada de tecnicismo sin terminar.
• 0:22
  Speaker 2: Estamos abordando los desafíos reales Copilot Studio, agentes de IA, Fabric, Seguridad,
• 0:27
  Speaker 2: Gobernanza y Automatización. Ya seas profesional de TI, desarrollador o
• 0:31
  Speaker 2: líder empresarial, hay sesiones diseñadas para ti. Con 10 días completos,
• 0:36
  Speaker 2: puedes explorar múltiples tecnologías y conectar con una comunidad global.
• 0:40
  Speaker 2: Mira en vivo y das prácticas de vuelta a tu organización.
• 0:45
  Speaker 2: Enero de 2027. 10 días. Una comunidad de Microsoft. Las
• 0:49
  Speaker 2: inscripciones ya están abiertas. Aparta tu lugar hoy mismo. Eso
• 0:55
  Speaker 2: es m365.net. Únete ahora en m365.com.net y te veremos. En
• 1:04
  Speaker 2: vivo en enero.¿ Realmente necesitas tu propio agente de Copilot
• 1:07
  Speaker 2: Studio o es solo entusiasmo por la idea hablando? Esta
• 1:09
  Speaker 2: es la decisión que casi todas las empresas se enfrentan
• 1:11
  Speaker 2: en este momento. Si empiezas muy rápido con un copilot equivocado,
• 1:14
  Speaker 2: pierdes meses. Si empiezas muy lento, te quedas atrás de
• 1:16
  Speaker 2: competidores que ya automatizan de forma más inteligente. En esta
• 1:19
  Speaker 2: sesión te explicaré exactamente cómo probamos esa pregunta en un
• 1:22
  Speaker 2: proyecto real y el giro sorprendente que encontramos al comparar
• 1:25
  Speaker 2: una solución genérica rápida con una versión dedicada de Copilot Studio.
• 1:30
  Speaker 2: La solución de la falsa promesa.¿ Qué pasa si la
• 1:32
  Speaker 2: forma más rápida de añadir IA es también la forma
• 1:34
  Speaker 2: más rápida de estancarse? Esa es la trampa a la
• 1:36
  Speaker 2: que caen muchas organizaciones cuando optan por el primer copilot
• 1:38
  Speaker 2: que les ofrecen.¿ En papel parece eficiente? Hay una demostración pulida,
• 1:42
  Speaker 2: un discurso claro, y la promesa de que puedes incluir
• 1:44
  Speaker 2: IA en tus flujos de trabajo sin pensar demasiado en
• 1:46
  Speaker 2: el diseño. Pero la velocidad no siempre es la ventaja
• 1:49
  Speaker 2: que parece. El problema es que estas implementaciones rápidas rara
• 1:52
  Speaker 2: vez descubren las necesidades más profundas del negocio. Por lo tanto,
• 1:55
  Speaker 2: lo que comienza como un atajo prometedor a menudo termina
• 1:57
  Speaker 2: en un callejón sin salida. Piensen cómo empiezan la mayoría
• 1:59
  Speaker 2: de los equipos. Alguien ve un copilot para resumir correos
• 2:01
  Speaker 2: o buscar documentos, y se ve increíble de forma aislada.
• 2:04
  Speaker 2: Los tomadores de decisiones no siempre se detienen a preguntar
• 2:07
  Speaker 2: si se ajusta al trabajo diario de sus empleados o
• 2:08
  Speaker 2: si se conecta a los sistemas con sus datos críticos.
• 2:10
  Speaker 2: En lugar de mapear tareas reales, toman lo que ya
• 2:13
  Speaker 2: viene empaquetado. En la semana siguiente la idea recibe algo
• 2:16
  Speaker 2: de atención, quizás incluso entusiasmo, pero luego la adopción se estanca.
• 2:19
  Speaker 2: La gente se da cuenta de que en realidad no
• 2:20
  Speaker 2: está ayudando con los problemas que consumen horas cada semana.
• 2:23
  Speaker 2: Puedes ver esto claramente con los equipos de venta. Imagina
• 2:25
  Speaker 2: un grupo que pasa la mayor parte de su tiempo
• 2:27
  Speaker 2: persiguiendo leads, preparando cotizaciones y respondiendo preguntas de clientes. Si
• 2:30
  Speaker 2: la dirección les da un copiloto genérico diseñado para redactar
• 2:33
  Speaker 2: correos o resumir notas de reuniones, puede generar momentos sorprendentes
• 2:36
  Speaker 2: en una demostración. Pero cuando el equipo comienza a pedirle
• 2:40
  Speaker 2: excepciones de precios, o si un cliente cumple con cierto
• 2:42
  Speaker 2: requisito de cumplimiento, el copiloto parece superficial. No ha sido
• 2:46
  Speaker 2: conectado a tablas de precios, datos de CRM ni manuales
• 2:48
  Speaker 2: de ventas específicos. Sin esa base, las respuestas pueden sonar bien,
• 2:52
  Speaker 2: pero siguen siendo inútiles en la práctica. Aquí es donde
• 2:55
  Speaker 2: aparecen los límites naturales de las herramientas de IA genéricas.
• 2:58
  Speaker 2: Sin conocimiento de dominio específico funcionan como generalistas brillantes, competentes
• 3:02
  Speaker 2: en comunicación superficial pero incapaces de dar profundidad cuando importa.
• 3:06
  Speaker 2: Los usuarios hacen preguntas detalladas y el copiloto adivina mal
• 3:09
  Speaker 2: o recurre a frases vagas e inútiles. Ahí es cuando
• 3:12
  Speaker 2: la confianza es erosión. Una vez que los empleados dejan
• 3:15
  Speaker 2: de confiar en lo que dice la gente, rápidamente dejan
• 3:16
  Speaker 2: de usarlo por completo. En ese punto, toda la implementación
• 3:20
  Speaker 2: corre el riesgo de ser etiquetada como otro juguete de
• 3:21
  Speaker 2: IA en lugar de una capacidad seria. Los datos sobre
• 3:24
  Speaker 2: la adopción de ella respaldan esto. Estudios que rastrean implementaciones
• 3:27
  Speaker 2: empresariales han mostrado que los proyectos sin personalización y ajustes
• 3:30
  Speaker 2: según el rol tienen un uso mucho menor seis meses
• 3:32
  Speaker 2: después del lanzamiento. No es porque la tecnología deje de funcionar,
• 3:35
  Speaker 2: sino porque la ausencia de contexto la vuelve irrelevante. Las
• 3:39
  Speaker 2: empresas a menudo confunden la calidad de la demostración con
• 3:41
  Speaker 2: el valor de implementación real. Una buena demostración se basa
• 3:43
  Speaker 2: en ejemplos pequeños y seleccionados. Las operaciones diarias, en cambio,
• 3:47
  Speaker 2: traen datos más confusos y requieren conocimiento de fondo estructurado.
• 3:50
  Speaker 2: Cuando el copiloto no puede adaptarse, la falta de coincidencia
• 3:52
  Speaker 2: se vuelve obvia. Entonces,¿ por qué las empresas siguen cometiendo
• 3:54
  Speaker 2: este error? Parte de ello es exagerado. La IA se
• 3:56
  Speaker 2: comercializa como una capacidad plug and play, algo que puedes
• 3:59
  Speaker 2: activar igual que una nueva licencia en Microsoft 365. Los
• 4:03
  Speaker 2: líderes bajo presión por mostrar progreso en IA, a menudo,
• 4:06
  Speaker 2: priorizan la visibilidad rápida sobre el impacto sostenible. Implementan algo rápido,
• 4:10
  Speaker 2: lo señalan en presentaciones y cumplen con requisitos. La velocidad
• 4:13
  Speaker 2: impulsada por exageración no equivale a resultados medibles. Los empleados
• 4:15
  Speaker 2: que realmente deben usar la herramienta sienten esa brecha al instante,
• 4:18
  Speaker 2: incluso si los tableros reportan una implementación exitosa. Esta diferencia
• 4:21
  Speaker 2: entre velocidad y progreso crea la verdadera bifurcación en el camino.
• 4:24
  Speaker 2: Más rápido no siempre significa más lejos. Sí, puedes tener
• 4:27
  Speaker 2: un agente funcionando mañana si solo se trata de que
• 4:28
  Speaker 2: aparezca en Teams o Outlook, pero si se vuelve indispensable
• 4:31
  Speaker 2: depende totalmente de si se adaptó a roles y flujos
• 4:33
  Speaker 2: de trabajo reales. Eficiencia no proviene de presionar habilitar. Proviene
• 4:38
  Speaker 2: de hacer la pregunta más difícil desde el principio.¿ Necesitamos
• 4:41
  Speaker 2: un agente de Copilot Studio que refleje nuestros procesos, nuestro
• 4:43
  Speaker 2: lenguaje y nuestros datos? Ese es el punto de giro
• 4:46
  Speaker 2: donde los proyectos se estancan o escalan. Los equipos que
• 4:49
  Speaker 2: se detienen a preguntarlo pueden diseñar agentes que los empleados
• 4:51
  Speaker 2: realmente quieran usar porque reconocen su relevancia inmediata. Los equipos
• 4:54
  Speaker 2: que se saltan este paso siguen añadiendo herramientas que parecen
• 4:57
  Speaker 2: familiares pero que no dan resultado. La ironía es que
• 4:59
  Speaker 2: un comienzo más lento y deliberado suele ser el camino
• 5:01
  Speaker 2: más rápido hacia la adopción porque evita desperdiciar ciclos en
• 5:04
  Speaker 2: soluciones que no encajan. El siguiente paso es descubrir cómo
• 5:08
  Speaker 2: plantear esa pregunta difícil de forma estructurada. Y el punto
• 5:10
  Speaker 2: de partida para ello no es la tecnología sino las personas.
• 5:14
  Speaker 2: debemos decidir para quién es exactamente este agente. Persona. Para
• 5:18
  Speaker 2: quién es realmente el agente. Es fácil caer en la
• 5:20
  Speaker 2: trampa de diseñar algo para todo el mundo. Parece inclusivo,
• 5:24
  Speaker 2: quizás hasta eficiente, pero lo que suele producir es algo
• 5:27
  Speaker 2: tan diluido que nadie obtiene un valor real. En los
• 5:30
  Speaker 2: proyectos de IA, esa mentalidad de todo para todos casi
• 5:32
  Speaker 2: garantiza la decepción. La primera pregunta real que debe responder
• 5:35
  Speaker 2: es a quién se supone que debe ayudar exactamente este agente.
• 5:38
  Speaker 2: Sin saber eso, no está construyendo un copilot, solo está
• 5:40
  Speaker 2: creando un bot capaz de mantener una charla trivial, trivial.
• 5:43
  Speaker 2: Definir personas no es un ejercicio superficial, es la base
• 5:45
  Speaker 2: que hace posible el resto del proyecto. Cuando oiga hablar
• 5:48
  Speaker 2: de persona, no se trata de perfiles de marketing o
• 5:50
  Speaker 2: personajes ficticios con aficiones y bebidas favoritas. En este contexto,
• 5:54
  Speaker 2: una persona trata de identificar el rol, las responsabilidades y
• 5:57
  Speaker 2: el entorno de la persona a la que sirve su agente.
• 5:59
  Speaker 2: Define lo que la gente necesita saber, cómo responde a
• 6:01
  Speaker 2: las preguntas e incluso el tono que debe utilizar. Un
• 6:04
  Speaker 2: empleado genérico no ayuda a su guía a determinar si
• 6:06
  Speaker 2: debe extraer datos de cumplimiento en tiempo real o dar
• 6:08
  Speaker 2: instrucciones de reparación paso a paso. Esa vaguedad es la
• 6:12
  Speaker 2: razón por la que tantos proyectos iniciales terminaron con la
• 6:14
  Speaker 2: gente que sabían saludar de cinco formas distintas pero no
• 6:16
  Speaker 2: podían resolver el problema real por el que venían los usuarios.
• 6:18
  Speaker 2: Y aquí la diferencia que marca la práctica. Se imagina
• 6:21
  Speaker 2: al empleado como su persona podría decidir que la gente
• 6:23
  Speaker 2: debe ayudar con políticas de RRR, de soporte técnico y
• 6:27
  Speaker 2: consultas de documentos, todo a la vez. Entonces la gente
• 6:30
  Speaker 2: debe dividirse entre múltiples ámbitos sin destacar en ninguno de ellos...
• 6:34
  Speaker 2: Compare esto con definir a una persona como un ingeniero
• 6:36
  Speaker 2: de campo que necesita respuestas sobre cumplimiento en instante en
• 6:38
  Speaker 2: las instalaciones del cliente. Inmediatamente el diseño cambia. Usted sabe
• 6:42
  Speaker 2: que esta persona suele estar en movimiento, tiene poco tiempo
• 6:44
  Speaker 2: y necesita orientación clara y autoritaria. Esa persona le lleva
• 6:47
  Speaker 2: a conectar el copiloto a bases de datos de cumplimiento,
• 6:50
  Speaker 2: fórmula respuestas de manera inequívoca y priorizar la rapidez de
• 6:52
  Speaker 2: entrega sobre las explicaciones largas. Puede ver como uno es
• 6:55
  Speaker 2: vago y desenfocado, mientras que el otro es lo suficientemente
• 6:58
  Speaker 2: preciso para guiar la construcción real. La diferencia en el
• 7:00
  Speaker 2: mundo real se vuelve aún más clara cuando observa funciones contrastantes.
• 7:03
  Speaker 2: Tomemos la persona de un agente de soporte técnico. Este
• 7:05
  Speaker 2: grupo necesita pasos de resolución rápidos, actualizaciones de fallas del
• 7:08
  Speaker 2: sistema y la capacidad de escalar tickets de servicio. El
• 7:11
  Speaker 2: lenguaje es técnico, los datos provienen de herramientas como ServiceNow
• 7:13
  Speaker 2: o Intune y los usuarios esperan instrucciones precisas que puedan
• 7:16
  Speaker 2: seguir bajo presión. Ahora comparemos eso con el perfil de
• 7:19
  Speaker 2: una lista financiera. A este usuario le preocupa más acceder
• 7:22
  Speaker 2: a modelos financieros, comprender el cumplimiento de las aprobaciones de
• 7:25
  Speaker 2: gastos o generar informes. Trabajan con números, cadenas de aprobación
• 7:29
  Speaker 2: y terminología financiera. necesitan confiar en que el copiloto no
• 7:32
  Speaker 2: expondrá información sensible a la audiencia incorrecta. Si diseñas para
• 7:36
  Speaker 2: el empleado en general, no se disfrazan ninguno de los.
• 7:38
  Speaker 2: Si diseñas para cada perfil específico, la gente se vuelve
• 7:40
  Speaker 2: no solo útil, sino confiable. Otro beneficio ignorado al definir
• 7:44
  Speaker 2: perfiles es la alineación dentro de la organización. Pero cuando
• 7:47
  Speaker 2: pones un perfil claro sobre la mesa, los equipos DRR, DI,
• 7:51
  Speaker 2: cumplimiento de operaciones, pueden acordar rápidamente cuál es el alcance real.
• 7:54
  Speaker 2: El lugar de debate es interminable sobre lo que el
• 7:56
  Speaker 2: copiloto podría hacer. Todos tienen ahora un punto de referencia
• 7:58
  Speaker 2: de lo que debería hacer. Se convierte en una brújula
• 8:01
  Speaker 2: para la toma de decisión. Si estás debatiendo si agregar
• 8:03
  Speaker 2: una función, puedes verificarla contra el perfil.¿ Ayuda esto al
• 8:06
  Speaker 2: ingeniero de campo a obtener respuestas de cumplimiento más rápido?
• 8:10
  Speaker 2: Si es no, entonces probablemente no pertenezca a la primera versión.¿
• 8:12
  Speaker 2: Ese tipo de disciplina evita que el proyecto se convierta
• 8:14
  Speaker 2: en una lista de deseos sin enfoque? Los perfiles también
• 8:17
  Speaker 2: van más allá de guiar el alcance. Impulsan los requisitos
• 8:19
  Speaker 2: de conocimiento. Para cada perfil debes preguntar qué información necesitan
• 8:22
  Speaker 2: a diario, qué...¿ Dónde reside actualmente esa información?¿ Con qué rapidez...
• 8:27
  Speaker 2: Ese análisis determina cómo integras las fuentes de conocimiento en
• 8:30
  Speaker 2: el copiloto y cómo lo mantienes actualizado. Si ignoras los perfiles,
• 8:33
  Speaker 2: sobrecargarás a la gente con datos irrelevantes o, peor aún,
• 8:36
  Speaker 2: lo privarás del contenido que realmente necesita. De cualquier manera,
• 8:40
  Speaker 2: la confianza de los usuarios finales se erosiona y una
• 8:42
  Speaker 2: vez que se pierde la confianza, la adopción no se
• 8:43
  Speaker 2: recupera fácilmente. Un perfil bien definido no se trata de
• 8:46
  Speaker 2: limitar posibilidades, se trata de dar dirección. Sin él, los
• 8:49
  Speaker 2: proyectos de IA deambulan persiguiendo cada función novedosa hasta que
• 8:51
  Speaker 2: colapsan bajo su propia ambición. Con él tienes una guía constante.
• 8:55
  Speaker 2: El perfil se convierte en la brújula que mantiene el
• 8:57
  Speaker 2: proyecto en curso, asegurando que el copiloto se construya para
• 9:00
  Speaker 2: personas reales con tareas reales, no para una idea abstracta
• 9:02
  Speaker 2: de empleado. Y esa es la diferencia entre un agente
• 9:06
  Speaker 2: que es ignorado tras su lanzamiento y uno en el
• 9:07
  Speaker 2: que la gente confía activamente. Con los perfiles establecidos, el
• 9:11
  Speaker 2: panorama finalmente se vuelve más nido.¿ Sabes para quién estás construyendo?
• 9:14
  Speaker 2: Siguiente pregunta natural es¿ qué es exactamente lo que deberíamos
• 9:16
  Speaker 2: ayudarles a hacer? Casos de uso que realmente importan. No
• 9:20
  Speaker 2: todas las tareas merecen un copiloto, incluso si técnicamente pueden
• 9:22
  Speaker 2: tener uno. Aquí es donde muchas organizaciones se dejan llevar.
• 9:25
  Speaker 2: Una vez que comienza la lluvia de ideas, parece que
• 9:27
  Speaker 2: cada pequeña frustración podría convertirse en una función de ella.
• 9:29
  Speaker 2: Alguien propone,¿ y si pudiera recordarnos enviar nuestras hojas de horas?
• 9:33
  Speaker 2: Otro añade, quizás podría redactar notas de agradecimiento después de
• 9:36
  Speaker 2: las reuniones con Glenn. En poco tiempo, la lista es
• 9:39
  Speaker 2: tan larga que nadie recuerda qué problema intentaban resolver realmente.
• 9:42
  Speaker 2: El peligro no es tener demasiadas ideas, sino intentar que
• 9:44
  Speaker 2: un solo agente sea responsable de todas ellas. En ese punto,
• 9:47
  Speaker 2: el copiloto deja de sentirse como un especialista y se
• 9:49
  Speaker 2: vuelve más como un pasante abrumado. La realidad es que
• 9:51
  Speaker 2: las sesiones de lluvia de ideas casi siempre generan docenas
• 9:54
  Speaker 2: de posibles direcciones. Gracias. Gracias. Gracias. automatizadas. Tay sueña con
• 10:01
  Speaker 2: una clasificación de tickets más rápido. Por sí solas, ninguna
• 10:03
  Speaker 2: de estas es mala, pero la pregunta no es,¿ puede
• 10:05
  Speaker 2: la EA hacer esto?¿ Les importa si la EA hace esto?
• 10:12
  Speaker 2: Ese pequeño cambio expone cuántas ideas suenan inteligentes, pero no
• 10:15
  Speaker 2: ofrecen casi ningún retorno una vez implementadas. El hecho de
• 10:18
  Speaker 2: que puedas automatizar preguntas menores no significa que valga la
• 10:20
  Speaker 2: pena el esfuerzo de construir, entrenar y mantener esa automatización.
• 10:24
  Speaker 2: Si alguna vez has visto el resultado de proyectos con
• 10:26
  Speaker 2: demasiado alcance, el patrón es predecible. El agente termina cargado
• 10:29
  Speaker 2: con docenas de tareas desconectadas, haciendo cada una a un
• 10:32
  Speaker 2: nivel mediocre. Toma algo simple como responder si una sala
• 10:36
  Speaker 2: de reuniones tiene un proyector. Claro, un copiloto puede manejar
• 10:39
  Speaker 2: este tipo de preguntas frecuentes con facilidad, pero el impacto
• 10:41
  Speaker 2: es mínimo. Compare eso con un agente que valida si
• 10:44
  Speaker 2: una propuesta de ventas cumple con criterios regulatorios estrictos antes
• 10:47
  Speaker 2: de ser enviada. Uno ahorra un poco de molestia, el
• 10:50
  Speaker 2: otro previene riesgos legales y acelera los ingresos. El contraste
• 10:53
  Speaker 2: muestra por qué la priorización es importante. Una forma útil
• 10:56
  Speaker 2: de filtrar el ruido es aplicar tres criterios al principio, valor,
• 11:00
  Speaker 2: frecuencia y viabilidad. Valor significa preguntar cuánto ayuda realmente la
• 11:04
  Speaker 2: tarea del negocio cuando se automatiza. La frecuencia analiza con
• 11:07
  Speaker 2: qué frecuencia ocurre. Resolver un pequeño punto de dolor que
• 11:10
  Speaker 2: sucede 50 veces al día puede superar un desafío mayor
• 11:12
  Speaker 2: que solo ocurre una vez por trimestre. La viabilidad mantiene
• 11:15
  Speaker 2: a los dos primeros bajo control. Si los datos requeridos
• 11:18
  Speaker 2: no existen en formato digital o no pueden ser accedidos
• 11:19
  Speaker 2: de forma segura, entonces no es un buen candidato para
• 11:21
  Speaker 2: la primera fase. Cuando los equipos evalúan cada caso de
• 11:24
  Speaker 2: uso a través de esa lente, las listas de deseos
• 11:26
  Speaker 2: sobrecargadas se reducen repentinamente en plan enfocado. También hay evidencia
• 11:29
  Speaker 2: de que los pilotos más pequeños con alcance limitado funcionan mejor.
• 11:32
  Speaker 2: Las organizaciones que se comprometen con solo dos o tres
• 11:34
  Speaker 2: casos de uso al principio tienden a aumentar la adopción
• 11:37
  Speaker 2: interna a un ritmo más rápido. Todo ocurre de esta manera.
• 11:39
  Speaker 2: El copiloto se lanza con un valor claro en una
• 11:41
  Speaker 2: o dos áreas. Los empleados ganan confianza y el impulso aumenta.
• 11:45
  Speaker 2: Compárenlo con agentes que intentan cubrir 10 escenarios distintos a
• 11:48
  Speaker 2: la vez. Esos proyectos suelen colapsar por el peso de
• 11:51
  Speaker 2: una calidad inconsistente y comentarios frustrados. Resulta que un comienzo
• 11:54
  Speaker 2: más acotado crea una base más sólida para expandirse después.
• 11:58
  Speaker 2: Consideremos dos equipos ficticios como ejemplo. El primero decidió diseñar
• 12:01
  Speaker 2: un copiloto que apoyara a RR, TI, finanzas y atención
• 12:05
  Speaker 2: al cliente todo en uno. Pasaron meses mapeando fuentes de datos,
• 12:08
  Speaker 2: creando flujos de trabajo complejos y prometiendo que sería la
• 12:10
  Speaker 2: solución única para toda la organización. Cuando llegó el día
• 12:13
  Speaker 2: del lanzamiento, los primeros usuarios descubrieron que no podía manejar
• 12:15
  Speaker 2: las necesidades de ningún departamento correctamente. La abandonó en cuestión
• 12:17
  Speaker 2: de semana. El segundo equipo, por el contrario, se centró
• 12:20
  Speaker 2: solo en ayudar a los ingenieros de campo a confirmar
• 12:22
  Speaker 2: reglas de cumplimiento antes de las instalaciones. Lanzaron en una
• 12:25
  Speaker 2: fracción del tiempo, la adopción fue inmediata y los ingenieros
• 12:28
  Speaker 2: comenzaron a pedir nuevos escenarios basados en su experiencia positiva.
• 12:32
  Speaker 2: Misma tecnología y resultados muy diferentes. Entonces el desafío no
• 12:35
  Speaker 2: es encontrar suficientes casos de uso, es resistirse e intentar
• 12:37
  Speaker 2: cubrirlos todos a la vez. La pregunta que importa es,¿
• 12:40
  Speaker 2: en qué escenarios vale la pena apostar? cuáles si se
• 12:42
  Speaker 2: automatizaran se convertirían en una herramienta cotidiana en la que
• 12:44
  Speaker 2: la gente realmente confíe. Así es como se separa el
• 12:47
  Speaker 2: ruido de la señal. Esos casos de uso elegidos suelen
• 12:50
  Speaker 2: ser aquellos donde los empleados sienten una mejora visible en
• 12:52
  Speaker 2: cómo trabajan, no solo en cuántos pasos se automatizan, hacen
• 12:55
  Speaker 2: que las tareas sean menos frustrantes y más confiables. La
• 12:58
  Speaker 2: conclusión aquí es que los mejores casos de uso no
• 13:00
  Speaker 2: solo automatizan el trabajo, sino que cambian cómo se siente
• 13:02
  Speaker 2: el trabajo para el usuario final. Cuando alguien puede decir finalmente,
• 13:05
  Speaker 2: este copiloto hizo que mi trabajo fuera menos estresante, has
• 13:08
  Speaker 2: encontrado el ajuste correcto. Ahora que sabemos para quién diseñamos
• 13:10
  Speaker 2: y qué necesitan realmente, el siguiente paso es determinar qué
• 13:13
  Speaker 2: habilidades y conocimientos debemos enseñar a la gente para que
• 13:16
  Speaker 2: pueda cumplir. Enseñar a la gente habilidades y conocimientos. Una
• 13:20
  Speaker 2: gente no es inteligente hasta que le enseñas lo que
• 13:22
  Speaker 2: tu equipo ya sabe. Y esa es la parte que
• 13:24
  Speaker 2: muchos proyectos subestiman. Instalar un copiloto de fábrica puede darte
• 13:27
  Speaker 2: algo que parece funcional, pero si no has entrenado con
• 13:30
  Speaker 2: el mismo conocimiento del que dependen tus empleados, no llegará lejos.
• 13:33
  Speaker 2: En el mejor de los casos, llena vacíos superficiales con
• 13:35
  Speaker 2: respuestas pulidas pero vagas. En el peor da a los
• 13:38
  Speaker 2: usuarios una guía poco confiable y socava la confianza por completo.
• 13:41
  Speaker 2: Lo que marca la diferencia es la fundamentación del conocimiento.
• 13:43
  Speaker 2: Alimentar a la gente con los datos correctos y conectarlo
• 13:46
  Speaker 2: con los flujos de trabajo donde realmente ocurre el trabajo.
• 13:48
  Speaker 2: Piensa en el contraste. Un copilot sin contexto puede decirte
• 13:52
  Speaker 2: cómo escribir un correo electrónico profesional porque ha visto millones
• 13:54
  Speaker 2: de ejemplos. Pero si alguien pregunta sobre los términos específicos
• 13:57
  Speaker 2: de la política de reembolso de tu empresa o qué
• 13:59
  Speaker 2: cuenta como gasto de capital en tu sistema financiero, el
• 14:01
  Speaker 2: mismo copilot de repente parece vacío. Puede hilar algo que
• 14:05
  Speaker 2: suena razonable, pero ser razonable no es suficiente cuando una
• 14:08
  Speaker 2: redacción incorrecta queda detrás de sus problemas de cumplimiento o
• 14:10
  Speaker 2: pérdida de ingresos. Ahora, imagina un agente que se ha
• 14:14
  Speaker 2: conectado directamente a las bases de conocimiento aprobadas, procesos documentados
• 14:17
  Speaker 2: y sistemas actualizados de tu empresa. No solo responde con generalidades.
• 14:21
  Speaker 2: Puede extraer reglas precisas de tu carpeta de contratos, citar
• 14:24
  Speaker 2: la sección correcta de tu manual de cumplimiento o dirigir
• 14:26
  Speaker 2: la solicitud a través de un flujo de trabajo interno.
• 14:29
  Speaker 2: Es ahí cuando un copilot deja de ser una novedad
• 14:31
  Speaker 2: para convertirse en un colega de confianza. En Copilot Studio
• 14:35
  Speaker 2: hay dos formas principales de ajustar esta inteligencia, el fundamentado
• 14:38
  Speaker 2: en el conocimiento y las habilidades. El fundamentado en el
• 14:40
  Speaker 2: conocimiento es la parte donde conectas el Copilot a las
• 14:42
  Speaker 2: fuentes de las que tu organización ya depende. Esto podría
• 14:45
  Speaker 2: ser bibliotecas de SharePoint donde residen las políticas o wikis
• 14:47
  Speaker 2: internos que el personal consulta todos los días. Al llevar
• 14:50
  Speaker 2: esto al entorno de la gente, le das la capacidad
• 14:52
  Speaker 2: de recuperar y reutilizar contenido que coincide con tus requisitos
• 14:55
  Speaker 2: exactos en lugar de depender de modelos de lenguaje vagos
• 14:57
  Speaker 2: que adivinan sobre la marcha. Las habilidades son las que
• 15:00
  Speaker 2: hacen que el Copilot sea activo en lugar de solo informativo.
• 15:03
  Speaker 2: Son los conectores a API, flujos de trabajo y aplicaciones
• 15:05
  Speaker 2: que permiten a la gente tomar medidas en lugar de
• 15:07
  Speaker 2: simplemente hablar. Por ejemplo, vincularse a la gestión de tickets
• 15:10
  Speaker 2: de ServiceNow permite que un perfil de soporte técnico modifique
• 15:12
  Speaker 2: una fecha o cierre tickets directamente. En lugar de reescribir
• 15:16
  Speaker 2: extractos de políticas, el copilot puede guiar al usuario a
• 15:19
  Speaker 2: través de los pasos mientras completa la tarea en segundo plano.
• 15:23
  Speaker 2: Esta combinación de fundamentado en el conocimiento y habilidades integradas
• 15:26
  Speaker 2: separa a un chatbot de un asistente real. Un chatbot
• 15:28
  Speaker 2: recita y un agente actúa. Los riesgos de saltarse este
• 15:31
  Speaker 2: paso aparecen rápidamente. Si un copilot down que sea una
• 15:34
  Speaker 2: sola respuesta de alto riesgo que resulte incorrecta, los usuarios
• 15:36
  Speaker 2: lo recuerdan. Ese recuerdo perdura mucho más que cualquier buena experiencia,
• 15:39
  Speaker 2: especialmente en industrias estrictamente reguladas. Solo se necesita una garantía
• 15:44
  Speaker 2: errónea sobre el cumplimiento o un estado financiero inexacto para
• 15:46
  Speaker 2: dañar la confianza que todo un equipo tiene en la herramienta.
• 15:50
  Speaker 2: Recuperar la adopción después de este tipo de contratiempo es
• 15:52
  Speaker 2: mucho más difícil que invertir en integración de datos adecuada
• 15:54
  Speaker 2: desde el principio. Incluso cuando los cimientos son sólidos, el
• 15:57
  Speaker 2: desafío no termina. Las reglas de negocio cambian, los flujos
• 15:59
  Speaker 2: de trabajo evolucionan y las políticas se actualizan. Eso significa
• 16:02
  Speaker 2: que entrenar a una gente no es una tarea de
• 16:03
  Speaker 2: una sola vez. Es un proceso iterativo que requiere ajustes
• 16:06
  Speaker 2: con el tiempo. Un nuevo marco de cumplimiento puede requerir
• 16:09
  Speaker 2: un nuevo fundamental. Una migración de sistema podría significar actualizar
• 16:12
  Speaker 2: la seguridad. No solo los cambios en el lenguaje, como
• 16:14
  Speaker 2: la forma en que los equipos hablan de productos o procesos,
• 16:16
  Speaker 2: pueden afectar el rendimiento si se ignoran. Este ciclo de
• 16:19
  Speaker 2: perfeccionamiento continuo es lo que separa a los equipos que
• 16:21
  Speaker 2: ven un valor creciente de aquellos cuyo copiloto pierde relevancia
• 16:23
  Speaker 2: tras su lanzamiento. La recompensa por perseverar es que su
• 16:26
  Speaker 2: copiloto empiece a trabajar en tiempo real con la misma
• 16:28
  Speaker 2: profundidad que sus expertos aportan a sus funciones. Un copiloto
• 16:31
  Speaker 2: de recursos humanos puede proporcionar detalles sobre políticas sin necesidad
• 16:34
  Speaker 2: de involucrar al personal de red. En cada pequenado. Un
• 16:37
  Speaker 2: copiloto financiero puede guiar a un analista a través de
• 16:39
  Speaker 2: las cadenas de aprobación mientras extrae las cifras correctas de
• 16:41
  Speaker 2: los sistemas actuales. No se trata solo de ganancias en eficiencia,
• 16:44
  Speaker 2: sino de cambiar la percepción que tienen las personas a
• 16:45
  Speaker 2: luz del herramienta. En lugar de ser un sistema más
• 16:47
  Speaker 2: con el que lidiar, se convierte en la vía más
• 16:49
  Speaker 2: rápida para obtener respuestas fiables y completar tareas. Por esto
• 16:52
  Speaker 2: es importante la distinción entre un chatbot y un copiloto.
• 16:55
  Speaker 2: Un chatbot mantiene conversaciones, mientras que un copiloto toma el contexto,
• 16:58
  Speaker 2: lo combina con acciones y lo transforma en un apoyo
• 17:00
  Speaker 2: en el que la gente confía. Los agentes más sólidos
• 17:03
  Speaker 2: son aquellos que reflejan lo que su equipo ya sabe
• 17:05
  Speaker 2: y pueden actuar sobre ese conocimiento de inmediato. Y una
• 17:08
  Speaker 2: vez que el diseño y la capacitación están listos, el
• 17:10
  Speaker 2: desafío final es cómo gestionar el despliegue. Porque un copiloto
• 17:13
  Speaker 2: técnicamente sólido aún puede fracasar si nunca logra ser adoptado.
• 17:18
  Speaker 2: Evitar los obstáculos en camino hacia la implementación. La forma
• 17:21
  Speaker 2: más común en que los proyectos de copilotos fallan no
• 17:23
  Speaker 2: es en el desarrollo, sino en el despliegue. Los equipos
• 17:25
  Speaker 2: a menudo pasan semanas ajustando personalidades, creando casos de uso
• 17:29
  Speaker 2: y conectando fuentes de datos solo para ver cómo la
• 17:31
  Speaker 2: iniciativa se estanca al momento de entregar la gente a
• 17:33
  Speaker 2: los empleados. Esto no sucede porque la tecnología falle, sino
• 17:37
  Speaker 2: porque el lado humano del despliegue suele descuidarse. La gobernanza
• 17:40
  Speaker 2: no se define, las expectativas no se gestionan o los
• 17:42
  Speaker 2: planes de adopción se consideran una ocurrencia tardía. Lo que
• 17:45
  Speaker 2: comienza con energía en el lanzamiento a menudo se devanece
• 17:47
  Speaker 2: ante que aparezcan resultados reales. Si alguna vez ha visto
• 17:49
  Speaker 2: la emoción de una reunión de inicio de proyecto, conoce
• 17:51
  Speaker 2: esa sensación. Hay una hoja de ruta en la pared,
• 17:53
  Speaker 2: se acuerdan los hitos y todos están ansiosos por la
• 17:55
  Speaker 2: primera demostración. Simplemente el primer flujo de trabajo, el copiloto
• 17:58
  Speaker 2: responde a consultas de prueba y todo parece prometedor. Pero
• 18:01
  Speaker 2: entre esa demostración y el lanzamiento real, el terreno cambia.
• 18:04
  Speaker 2: Los líderes piden funciones adicionales a mitad del proyecto, los
• 18:06
  Speaker 2: usuarios finales no saben cómo o cuándo usarla. Nueva herramienta
• 18:09
  Speaker 2: y los equipos de proyecto descubren que nunca establecieron procedimientos
• 18:11
  Speaker 2: sobre quien revisa los cambios o aprueba los datos de entrenamiento.
• 18:14
  Speaker 2: El vacío entre la construcción y el despliegue es donde
• 18:16
  Speaker 2: el impulso muere silenciosamente. Piensa en un agente que funcionaba
• 18:19
  Speaker 2: perfectamente durante las pruebas internas, pero que tropezó al ser lanzado.
• 18:22
  Speaker 2: Sus empleados lo abrieron una o dos veces, no entendieron
• 18:25
  Speaker 2: qué problema resolvía y se retiraron sin quedar impresionados. En
• 18:27
  Speaker 2: algunos casos, el equipo de desarrollo se centró tanto en
• 18:30
  Speaker 2: la precisión técnica que nunca preparó el plan de comunicación.
• 18:32
  Speaker 2: Sus usuarios finales asumieron que el copiloto podía responder a
• 18:35
  Speaker 2: todo relacionado con su puesto. En cambio, cuando hicieron la
• 18:38
  Speaker 2: primera pregunta no admitida, el agente respondió de forma vaga.
• 18:41
  Speaker 2: Ese solo momento fue suficiente para erosionar la confianza. La
• 18:43
  Speaker 2: adopción nunca se recuperó porque el lanzamiento no fue diseñado
• 18:46
  Speaker 2: para gestionar la percepción y los comentarios de los usuarios.
• 18:49
  Speaker 2: El aumento del alcance añade problemas. Supongamos que un proyecto
• 18:52
  Speaker 2: apuntaba originalmente a dos escenarios de alto valor para analistas financieros.
• 18:55
  Speaker 2: A mitad del proceso comienzan a llegar solicitudes por todo.
• 18:58
  Speaker 2: Va también a ayudar a R&D, a incorporar nuevos empleados
• 19:01
  Speaker 2: o quizás ofrecer pasos para solucionar problemas. La dirección quiere
• 19:04
  Speaker 2: mostrar impacto en varios departamentos, por lo que esas solicitudes
• 19:06
  Speaker 2: se añaden. Ahora, el equipo del proyecto está sobrecargado, los
• 19:09
  Speaker 2: plazos se incumplen y los casos de uso iniciales de
• 19:11
  Speaker 2: alto valor terminan retrasados. Para cuando terminan las pruebas, el
• 19:14
  Speaker 2: copiloto intenta atender cinco direcciones a la vez y no
• 19:16
  Speaker 2: satisface ninguna. El lanzamiento se pospone de nuevo, la confianza
• 19:20
  Speaker 2: en el proyecto disminuye y la promesa original nunca se materializa.¿
• 19:23
  Speaker 2: Evitar esa espiral requiere estructura? Un método probado son los
• 19:26
  Speaker 2: lanzamientos por fase. En lugar de imponerle agente a toda
• 19:29
  Speaker 2: la empresa a la vez... Comience con un pequeño grupo
• 19:32
  Speaker 2: piloto que represente la personalidad principal, recopile sus comentarios, monitoree
• 19:35
  Speaker 2: sus comentarios, monitoree los tipos de preguntas que hacen y
• 19:37
  Speaker 2: mide las tasas de adopción en un entorno controlado. Si
• 19:39
  Speaker 2: aparecen problemas, se pueden realizar ajustes discretamente ante el reto.
• 19:42
  Speaker 2: Junto a esto, establecerme desde éxito transparente se ayuda a
• 19:45
  Speaker 2: mantener el entusiasmo con los pies en la tierra. Si
• 19:47
  Speaker 2: el éxito se define como el 50% de los tickets
• 19:50
  Speaker 2: resueltos sin ayuda humana o comprobaciones de cumplimiento completadas en
• 19:53
  Speaker 2: menos de dos minutos, entonces todos pueden ver el progreso
• 19:55
  Speaker 2: en términos claros en lugar de afirmaciones vagas. Los buenos
• 19:58
  Speaker 2: proyectos de IA también tienen defensores, personas que sirven como
• 20:01
  Speaker 2: traductores internos entre el equipo técnico y la base de
• 20:03
  Speaker 2: usuarios habitual. Estos defensores ayudan a establecer las expectativas correctas,
• 20:07
  Speaker 2: mostrando a los colegas dónde destaca el copiloto y dónde no.
• 20:10
  Speaker 2: En lugar de prometer que la IA lo resolverá todo,
• 20:12
  Speaker 2: explican qué tareas específicas apoya y por qué se eligieron
• 20:14
  Speaker 2: como prioridades. Ese tipo de defensa tiene más peso viniendo
• 20:18
  Speaker 2: de compañeros que de anuncios de TI que aparecen en
• 20:20
  Speaker 2: un boletín de la empresa. Construye credibilidad persona a persona,
• 20:24
  Speaker 2: lo que escala la adopción de una manera que ningún
• 20:25
  Speaker 2: anuncio por sí solo logra. El impulso tras la primera
• 20:28
  Speaker 2: demostración proviene de gestionar este equilibrio entre ambición y realidad.
• 20:31
  Speaker 2: El agente no debería estar oculto en un laboratorio de
• 20:33
  Speaker 2: innovación sin visibilidad, pero tampoco puede lanzarse a toda la
• 20:36
  Speaker 2: fuerza laboral sin probarlo. Los lanzamientos que tienen éxito suelen
• 20:39
  Speaker 2: tener una secuencia paciente. probar, expandir y luego integrar en
• 20:41
  Speaker 2: el flujo de trabajo diario.