> ## Content Index > Fetch the complete content index at: https://www.abnerballardo.com/llms.txt > Use this file to discover other available public pages before exploring further. # Como CIO, puse mis criterios de comunicación en un agente de IA - URL: https://www.abnerballardo.com/es/post/como-cio-puse-mis-criterios-de-comunicacion-en-un-agente-de-ia/ - Published: 2026-10-26T12:00:00.000Z - Updated: 2026-10-26T12:00:00.000Z - Description: Puse mis criterios de comunicación al alcance del equipo con un agente de IA para que pudiera seguir preparando mensajes mientras yo estaba ocupado. - Author: Abner Ballardo - Tags: #es [Read in English](https://www.abnerballardo.com/en/post/as-a-cio-i-used-an-ai-agent-to-make-my-communication-guidance-reusable/) Cuando era CIO de un banco, muchos de los mensajes que mi equipo escribía para otros directivos pasaban primero por mí. A algunos borradores les habría venido bien algo más de contexto o una explicación más clara de por qué el tema le importaba a quien lo iba a leer. Por mi propio trabajo con esos directivos, había aprendido qué necesitaba entender cada uno, qué antecedentes ya tenía y qué le ayudaba a evaluar un pedido. Buena parte de eso le llegaba a mi equipo revisión tras revisión. Eso hacía que el equipo dependiera de mi disponibilidad. Tenía otras responsabilidades y mi feedback no siempre llegaba rápido. Mientras tanto, la gente podía quedarse dándole vueltas a si se le había escapado algo, si lo había explicado mal o si el mensaje iba a generar confusión. Construí entonces un asistente de IA que pusiera esos criterios al alcance del equipo mientras el mensaje todavía se estaba escribiendo. Podían usarlo para poner a prueba un borrador y seguir avanzando mientras yo estaba ocupado en otra cosa. Hoy comparto una reconstrucción pública, **Executive Communication Preparation**, en [Agentic Work Patterns](https://github.com/AbnerBallardo/agentic-work-patterns?ref=abnerballardo.com), mi colección de patrones para aplicar IA al trabajo recurrente de las organizaciones. ## Los criterios detrás de mi feedback Corregir un dato sirve para un caso. Saber cuánto contexto necesita un destinatario sirve para muchos. Así que puse por escrito esos criterios en perfiles de destinatario: qué sabía ya cada persona, qué había que explicarle y qué evidencia o nivel de detalle le servía. Con esos perfiles, el agente tenía una base concreta desde la cual trabajar. Los perfiles recogían lo que había aprendido trabajando con esas personas. Un cargo, por sí solo, no le habría dicho al agente cómo ayudar. En un [artículo anterior](https://www.abnerballardo.com/es/post/como-cio-use-un-agente-de-ia-para-preparar-decisiones-no-tomarlas/), conté cómo un agente ayudaba a mi equipo a ordenar un asunto antes de traérmelo. Este segundo agente cubría otra parte del trabajo: una vez que yo había evaluado la situación y dado mis indicaciones, ¿cómo podía el equipo escribirle a otra persona con lo que yo había aprendido sobre ella? **La respuesta era reutilizar lo que servía de un caso a otro: saber qué necesitaba entender cada destinatario.** ## El agente necesitaba más que un borrador Para ayudar con un mensaje, el agente tenía que saber quién lo iba a leer y qué necesitaba entender esa persona. También necesitaba la explicación del equipo sobre la situación y las indicaciones que yo había dado. El patrón mantiene separadas esas tres cosas. El perfil del destinatario describe cómo explicar el tema. El equipo aporta lo que sabe hoy: hechos, evidencia, opciones y preguntas abiertas. Y quien dio las indicaciones (en mi caso, yo) define qué debe lograr el mensaje, qué se decidió realmente y si el borrador tiene que volver para revisión. Con ese contexto, el agente puede cuestionar una explicación antes de pulirla. Puede preguntar por qué algo importa, qué respalda una afirmación o qué se le está pidiendo exactamente a quien lo lee. Verificar los hechos sigue siendo tarea del equipo: un perfil no puede decirle al agente qué es cierto hoy. ## Un requerimiento regulatorio ficticio Veamos un **ejemplo bancario ficticio, inspirado en mi experiencia**. Un banco recibe un requerimiento regulatorio con una fecha límite fija. Los equipos de negocio y tecnología evalúan el trabajo. Su propuesta exige inversión adicional y personas que ya están asignadas a otros compromisos. Para cumplir el plazo, hay que decidir sobre financiamiento y prioridades. Primero, el equipo usa Decision-Ready Escalations, el patrón del artículo anterior, para ordenarle el asunto al CIO del banco: opciones, recomendación y consecuencias. El CIO lo revisa y concluye que la inversión y el cambio de prioridades exceden sus facultades. Le pide al equipo que escriba al CEO del banco y al CIO regional, y que le devuelva ambos borradores antes de enviarlos. Sus criterios sobre esos dos destinatarios ya existían antes de que surgiera este encargo. Mientras trabaja en cada mensaje, el equipo le lleva al agente el perfil que corresponde, su evaluación y las instrucciones del CIO. Un primer borrador podría decir: > Necesitamos inversión adicional y un ajuste de prioridades para cumplir el plazo regulatorio. Para el CEO del banco, los criterios del CIO piden vincular cualquier solicitud de inversión con los planes de negocio existentes. La frase no hace esa conexión. ¿Qué compromisos tendrían que moverse? ¿Qué significaría eso para los planes que ya están a cargo del CEO? ¿Para cuándo se necesita la decisión? Esas preguntas le dan al equipo algo concreto con qué trabajar. La siguiente versión tiene que decir qué compromisos se ven afectados y qué consecuencias trae eso, además de lo que se pide: la inversión y una decisión sobre prioridades. La misma frase deja al CIO regional con otra pregunta: ¿qué se necesita de la región? Aquí los criterios piden explicar la exposición regulatoria y las dependencias tecnológicas. El agente puede preguntar qué dependencia requiere apoyo regional, qué intervención se está pidiendo y qué sigue dependiendo de lo que decida el CEO. Con esas respuestas, el equipo puede precisar la solicitud. Si su evaluación se queda corta, tiene que conseguir la respuesta o dejar la incertidumbre a la vista. El agente no debería inventar una estimación, un compromiso o una aprobación solo para terminar el mensaje. El CIO igual tiene que revisar ambos borradores. Pero, mientras está ocupado, el equipo sigue avanzando con criterios que él ya dejó por escrito, sin que él tenga que volver a explicarlos. El siguiente caso puede reutilizar esos mismos criterios, con sus propios hechos y nuevas indicaciones. Ningún mensaje puede perder lo esencial: el requerimiento y su plazo, los recursos necesarios, los compromisos que se mueven y lo que sigue siendo incierto. El CEO necesita entender la exposición regulatoria; el CIO regional, qué compromisos de negocio quedarían relegados. En este ejemplo, cumplir no es opcional. Lo que está en discusión es el financiamiento y las prioridades, y cada directivo decide dentro de sus facultades. ## ¿Bastaría con una guía escrita? Poner los criterios por escrito ya ayudaría. Una guía o una plantilla puede bastar cuando la tarea es conocida y quien escribe tiene toda la información. La razón para probar un agente es el ida y vuelta. En el ejemplo, alguien podría llenar un campo llamado «business impact» con una frase vaga sobre cambios de prioridades. Una plantilla la aceptaría. El agente puede preguntar si eso le basta a quien lo va a leer y ayudar a resolver lo que sigue sin estar claro. No puedo afirmar que este diseño funcione mejor que la capacitación, las plantillas u otra forma de revisión. También puede pasar por alto un vacío o sugerir una explicación que la evidencia no respalda. Su valor está en la reflexión que provoca. ## Lo que todavía dependía de mí La independencia que buscaba para el equipo era práctica: que pudiera seguir trabajando en un mensaje sin esperarme. Podía dejar parte de mis criterios en manos del agente y reservarme los temas que de verdad requerían mi juicio. Sí noté que la gente se iba familiarizando con la forma en que el agente abordaba la comunicación. No evalué formalmente si ese aprendizaje se mantenía ni cómo reaccionaban otras personas, y tampoco medí ahorros de tiempo ni efectos en la productividad. Si yo había pedido ver un borrador de nuevo, volvía a mí. Si cambiaban la situación o el compromiso propuesto, el equipo podía necesitar nuevas indicaciones. Y responder las preguntas del agente nunca daba permiso para enviar nada. Quien escribía el mensaje seguía siendo responsable de los hechos y de la redacción, y era una persona, no el agente, quien elegía el canal y lo enviaba. El patrón que comparto deja explícita, además, una salvaguarda para los propios perfiles: el agente no puede cambiar el perfil de un destinatario por su cuenta por algo que se dijo en una conversación. Cualquier cambio necesita la aprobación del owner del perfil. ## Empieza por el feedback que más repites Si estás pensando en probar este enfoque, yo empezaría por el feedback que repites con más frecuencia. Escribe qué necesidad hay detrás y a quién se aplica. Luego prueba ese criterio con un caso ficticio en el que dejes fuera parte de la información a propósito. No tienes que empezar de cero. El patrón [Executive Communication Preparation](https://github.com/AbnerBallardo/agentic-work-patterns/blob/main/patterns/executive-communication-preparation/README.md?ref=abnerballardo.com) incluye las instrucciones del agente, una plantilla de perfil y ejemplos ficticios. Es una reconstrucción basada en mi experiencia, separada de la versión privada que usé, y su [resumen de evaluación](https://github.com/AbnerBallardo/agentic-work-patterns/blob/main/patterns/executive-communication-preparation/evaluations/README.md?ref=abnerballardo.com) deja claro qué se ha probado y qué no. Fíjate en lo que el agente pregunta antes de escribir. La verdadera prueba es si sus preguntas muestran lo que todavía falta explicar, sin esconder la incertidumbre ni saltarse una revisión que corresponda. **¿Qué parte del feedback que repites podría aplicar tu equipo con ayuda de un agente, y en qué temas sigue haciendo falta tu propio juicio?**