5.4Acciones: hacer que Copilot actúe en tus sistemas
Lo esencial en 30 segundos
- El salto: con las acciones (conectores, flujos), el agente pasa de responder a actuar — ticket, correo electrónico, escritura en sistema.
- Leer vs escribir: leer es benigno, escribir/enviar es arriesgado e irreversible — cada acción de escritura se enmarca.
- La autonomía se merece: confirmación humana, permisos mínimos, registros y botón de parada antes de delegar.
Minicaso hilado — Hicham hace que su agente cree tickets
El agente de Hicham responde bien sobre políticas — pero cuando un colega señala una avería de material, solo aconseja. Hicham, asistente administrativo en Argel, le añade una primera acción vía conector: crear un ticket al soporte con descripción y prioridad — con resumen mostrado y confirmación humana antes de cada escritura, registro y posibilidad de detener al agente. Continuación del caso 5.3 — Hicham pasa del consejo a la ejecución, sin perder el control.
Continuación del caso 5.3 — Hicham añade una única acción de escritura, confirmada y registrada.
1. El salto: de responder a actuar
Hasta aquí el agente responde. Con las acciones, actúa: crear un ticket, enviar un correo electrónico, escribir en un CRM, lanzar un flujo Power Automate. Es el salto más potente… y el más delicado. El agente pasa del consejo a la ejecución. Hicham elige el caso más útil: convertir un aviso de avería en ticket, sin reintroducción.
Técnicamente, las acciones se apoyan en conectores: se enlaza al agente con un sistema y se describe cuándo y cómo puede actuar sobre él. «Si el usuario señala una avería, crea un ticket en el sistema de soporte».
2. Cada acción es un riesgo enmarcado
Principio cardinal: una acción que escribe en un sistema es irreversible o costosa de anular. Cada acción debe estar enmarcada: condiciones de activación claras, perímetro limitado y, a ser posible, una confirmación humana antes de las acciones sensibles. Hicham impone: el agente muestra el resumen del ticket y espera el «sí» del colega antes de crear.
Buena práctica: distinguir leer (poco arriesgado) y escribir/enviar (arriesgado). Un agente que consulta un estado es benigno; un agente que envía correos o modifica datos debe diseñarse con máxima prudencia y cortafuegos.
3. Supervisar a escala
Cortafuegos de escala: un agente que actúa lo hace rápido y en número. Un error de asistente queda local; un error de agente autónomo se repite en cada activación. De ahí la necesidad de probar intensamente, de registrar las acciones y de poder detener al agente. Hicham revisa el registro de tickets creados cada semana.
El principio que lo resume todo: la autonomía se merece con supervisión. Cuanto más se delegan acciones a un agente, más se invierte en su control — permisos mínimos, confirmaciones, registros, capacidad de corte. La potencia sin supervisión es un peligro.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Hicham automatiza la creación de tickets de soporte
Una única acción de escritura, confirmada y registrada.
Acción (conector de soporte): «Si el usuario describe una avería de material, crea un ticket con descripción y prioridad. »
Cortafuegos: mostrar un resumen y pedir «¿Confirmar la creación del ticket?» antes de escribir.Lectura: el agente pasa del consejo a la ejecución — actúa en el sistema de soporte.
Lección: confirmación humana antes de la escritura, registro y botón de parada disponible.
Vocabulario de la sección
- Acciones
- La capacidad del agente de ejecutar: crear un ticket, enviar un correo electrónico, escribir en un sistema.
Ejemplo sencillo: El agente de Hicham crea un ticket de soporte tras confirmación.
Lo que no es: una respuesta que aconseja sin ejecutar nada.
Reflejo: ¿esta ejecución es de verdad necesaria?
- Conectores
- Los enlaces que unen al agente con un sistema, con las reglas de uso.
Ejemplo sencillo: Hicham enlaza su agente al sistema de soporte del servicio.
Lo que no es: un acceso total sin regla ni perímetro.
Reflejo: ¿están escritos el cuándo y el cómo?
- Leer vs escribir
- Leer un estado es benigno; escribir o enviar es arriesgado y a menudo irreversible.
Ejemplo sencillo: Hicham deja leer libremente, hace confirmar cada escritura.
Lo que no es: tratar un envío de correo como una simple lectura.
Reflejo: ¿esta acción escribe en algún sitio?
- Confirmación humana
- El «sí» explícito pedido antes de toda acción sensible.
Ejemplo sencillo: El colega valida el resumen antes de crear el ticket.
Lo que no es: una escritura automática sin validación.
Reflejo: ¿quién dijo sí antes de la escritura?
- Supervisión
- Pruebas, registro de acciones y capacidad de parada de un agente que actúa.
Ejemplo sencillo: Hicham relee el registro de tickets cada semana.
Lo que no es: un agente que actúa sin rastro ni corte.
Reflejo: ¿puedo ver — y detener — lo que hizo?
En la práctica — En práctica — Enmarcar una primera acción de riesgo dominado
- Elige una acción sencilla y útil (crear un ticket, enviar una notificación interna).
- Distingue leer y escribir: empieza con una única acción de escritura, bien delimitada.
- Añade una confirmación humana antes de la ejecución y limita el perímetro al estricto necesario.
- Prevé la supervisión: registro de acciones, pruebas intensivas y un medio para detener al agente.
Script listo para decir — proponer una acción enmarcada
«Nuestro agente responde bien; propongo una primera acción: crear un ticket de soporte cuando un colega señale una avería. El agente mostrará un resumen y esperará la confirmación antes de escribir, con permisos mínimos y registro revisado cada semana. Antes de conectar nada más, hago validar el perímetro y las habilitaciones por la DSI. »
Dilo al responsable para que valide una primera escritura confirmada y registrada.
Modelo copiar-pegar — ficha de encuadre de una acción
FICHA DE ACCIÓN — una por acción de escritura
ACCIÓN: ___ (p. ej., crear un ticket de soporte)
ACTIVADOR: ¿cuándo exactamente? ___ · PERÍMETRO: ___ (sistema, campos)
LECTURA / ESCRITURA: ___ · ¿Confirmación humana? SÍ / NO (texto: ___)
PERMISOS: mínimos = ___ · REGISTRO: revisado por ___ cada ___
PARADA: ¿cómo cortar al agente? ___ · VALIDACIÓN DSI el ___: OK / KOSolo / presupuesto reducido
Hicham solo: una sola acción de escritura confirmada a mano — el registro revisado cada semana basta como supervisión.
TPE / equipo reducido
Confirmación sistemática mostrada al usuario: cada uno valida lo que el agente escribe en su nombre.
Pyme en Argel
Hicham hace validar en Argel conector, permisos y registro por la DSI antes de activar la acción.
Equipo que empieza
En pareja: uno diseña la acción, el otro intenta tenderle trampas (casos límite, duplicados) antes de activarla.
✓ Buenas prácticas
- Empieza con las acciones que leen, e introduce luego la escritura con una confirmación humana.
- Da al agente los permisos mínimos necesarios: nunca más de lo que exige la acción.
- Registra todas las acciones y guarda un botón de parada: a escala, un error se repite rápido.
✗ Errores frecuentes
- Dejar que un agente escriba o envíe sin confirmación ni cortafuegos: los errores se propagan en cada activación.
- Confundir el riesgo de leer y el de escribir: la escritura es irreversible o costosa de anular.
- Delegar acciones sin registro ni capacidad de parada: la potencia sin supervisión es un peligro.
Puntos clave
- Las acciones hacen pasar al agente de responder a actuar: ticket, correo, CRM, flujo — el salto más potente y delicado.
- Distingue leer (benigno) y escribir/enviar (arriesgado, irreversible): enmarca cada acción.
- Confirmación humana antes de las acciones sensibles, permisos mínimos, perímetro limitado.
- La autonomía se merece con supervisión: pruebas, registro, botón de parada.
Reto 48h — aplícalo mañana
Rellena la ficha de acción para 1 escritura real (modelo de arriba): ¿figuran en ella la confirmación y la parada?
- Puedo explicar leer vs escribir en una frase.
- Mi ficha de acción enmarca activador, confirmación y parada.
- Sé por qué la escritura exige un registro revisado.
Preguntas frecuentes
¿Puede un agente actuar de verdad solo en nuestros sistemas?
Sí, vía conectores. Pero cada acción de escritura debe enmarcarse: condiciones claras, confirmación humana en lo sensible, y supervisión.
¿Cómo limitar el riesgo de un agente que actúa?
Permisos mínimos, distinción leer/escribir, confirmación antes de la escritura, registro de acciones y un botón de parada. La autonomía se merece con supervisión.
¿Qué principio enmarca a un agente capaz de actuar en tus sistemas?