Cómo construir una matriz de gobernanza para agentes con datos, memoria, herramientas y acciones

1. Lista habilidades, no agentes abstractos. Empieza por acciones concretas: leer una bandeja, buscar un archivo, crear un borrador, publicar una pieza o modificar una campaña. Un “agente de marketing” puede esconder demasiada autoridad dentro de una sola etiqueta. Microsoft destaca que el riesgo agentic depende de acceso, permisos, memoria y uso a lo largo del tiempo; por eso la unidad de revisión debe ser suficientemente pequeña. Cada fila de la matriz representa una habilidad observable con una entrada, una salida y un efecto. Esa granularidad permite aprobar unas capacidades mientras otras permanecen bloqueadas.

2. Mapea datos y procedencia. Añade columnas para cada fuente: pública, interna, confidencial o regulada. Registra qué campos se leen, si se copian a otro sistema y cuánto tiempo permanecen en memoria o logs. No uses “acceso a Drive” como descripción completa si la habilidad solo necesita una carpeta. Si el conector soporta scopes más estrechos, documenta el mínimo requerido. También marca si la salida debe conservar citas, IDs o versiones. La matriz debe permitir responder rápidamente qué información pudo influir en una decisión y qué datos nunca deberían entrar en esa habilidad.

3. Clasifica las acciones por impacto. Separa lectura, creación reversible, modificación y acción irreversible o externa. Leer una campaña no tiene el mismo riesgo que aumentar presupuesto; generar un borrador no equivale a enviarlo. Define niveles como bajo, medio, alto y crítico según consecuencias reales del negocio. Después asigna controles: ejecución automática, confirmación del usuario, doble aprobación o prohibición. Esta clasificación evita reglas globales demasiado rígidas. Un agente puede ser muy autónomo en tareas de bajo impacto y deliberadamente lento en una acción que compromete dinero, reputación o datos sensibles.

4. Añade memoria y duración. Documenta qué estado conserva el agente entre pasos y entre sesiones. Una memoria útil puede evitar repetir preguntas, pero también puede mantener información que ya no debería influir. Define fecha de expiración, fuente de verdad y mecanismo de corrección. Para workflows largos, registra runKey o identificador de ejecución para que la memoria no mezcle dos trabajos. También conviene anotar límites de costo, tiempo y cantidad de acciones. Microsoft señala que el riesgo cambia con el uso a lo largo del tiempo; esta columna transforma esa idea en una restricción comprobable.

5. Especifica evidencia de cierre. Para cada habilidad, escribe qué demuestra que terminó correctamente. Puede ser una descarga con hash, un messageId, una revisión de estado, un ID de campaña o una captura estructurada del resultado. Si una acción externa no puede verificarse, la matriz debe mostrarlo como riesgo residual. Añade comportamiento de recuperación: reintentar, escalar, reutilizar un artefacto o detenerse. El objetivo es que “éxito” sea una condición técnica y no una frase del agente. Esta evidencia también simplifica auditorías y soporte porque permite reconstruir el resultado sin revisar toda la conversación.

6. Revisa la matriz como parte del release. Cada nueva herramienta, modelo o permiso puede cambiar la superficie de autoridad, aunque la interfaz del agente se vea igual. Incluye la matriz en el checklist de cambios y exige actualización cuando se añada una habilidad. Producto puede revisar utilidad; seguridad, límites; operaciones, recuperación; negocio, impacto. No hace falta convertirlo en burocracia enorme: una tabla breve y versionada puede ser suficiente. El valor está en hacer visible la autonomía. Cuando todos pueden ver qué lee, qué recuerda, qué ejecuta y cómo se verifica, la discusión sobre “IA responsable” se convierte en decisiones de ingeniería concretas.