Modelo operativo de gobernanza de IA: cinco partes, en funcionamiento

Qué hace nuestro modelo operativo de gobernanza de IA

Un modelo operativo de gobernanza de IA es un sistema de derechos de decisión, responsables, escalado, puntos de aprobación en el flujo de trabajo y revisiones que decide qué hacen los agentes de IA por su cuenta y qué espera a una persona. El nuestro gobierna agentes que actúan: clasifican solicitudes, escriben código, redactan guías y despachan trabajo a otros agentes. No es una política de uso de chatbots para la plantilla ni una lista de herramientas aprobadas.

La gobernanza de agentes no es un comité. Son cinco cosas escritas donde el agente las lee antes de actuar, y cada una es un artefacto que puedes abrir:

Ejecutamos las cinco en ConvOps(se abre en una pestaña nueva), que guarda las tareas, los responsables, los puntos de aprobación, las notas y las programaciones. Esta guía forma parte de Loops We Run; la guía principal muestra quién decide qué en toda la empresa.

Los ejemplos usan Copperfern, una tienda online ficticia de artículos para el hogar, y a Maya, que dirige sus operaciones. Los nombres y las cifras son inventados; los nombres de campos, los formatos de nota, las reglas y los umbrales son los reales.

Cinco partes, cinco artefactos: los derechos de decisión son una lista de descartes, el responsable es un solo nombre en la tarea, el escalado es una nota tipada, un punto de aprobación es una aprobación dentro del flujo de trabajo y la revisión es una programación.

Por qué las reglas viven dentro del flujo de trabajo

Un documento de políticas gobierna a las personas que lo leen. Un agente solo obedece lo que está dentro de su flujo de trabajo, así que ahí es donde tiene que vivir cada regla.

Nuestros agentes empezaron a hacer trabajo real: enrutar, construir, publicar, despachar. Las reglas vivían en un hilo de chat y en la cabeza de una persona. Un agente en mitad de una ejecución no vuelve a leer una página de políticas. Cuando un trabajo se torcía, nadie sabía decir qué agente había tomado la decisión, con qué motivo ni dónde debería haberse detenido.

Así que llevamos cada regla al punto donde actúa el agente. La lista de lo que un agente nunca puede asumir pasó al paso que elige el trabajo. Cada aprobación se convirtió en un punto de aprobación que la ejecución no puede superar sin un sí. Cada decisión de un agente deja ahora un motivo de una línea en la tarea. La gobernanza es una capa del recorrido hacia un modelo operativo de IA más amplio.

Descubre cómo ConvOps pone el punto de aprobación dentro del flujo de trabajo, no en un archivo de políticas(se abre en una pestaña nueva).

Cómo funciona

El trabajo entre puntos de aprobación funciona sin nosotros. Los puntos de aprobación son donde ponemos la atención, y en ningún otro sitio.

Cada regla tiene un motivo. El agente de clasificación nunca convierte un trabajo en iniciativa, ni una iniciativa en otra cosa, sin el sí del operador, porque el alcance lo decide una persona. Un lote de despacho tiene de 1 a 10 tareas, 5 por defecto, porque un lote pequeño hace que cada revisión sea real. La reserva de candidatos se consulta con el triple de ese máximo, para que después de los descartes la lista siga llena.

Un agente se detiene y pregunta solo cuando hace falta criterio de verdad: acceso o datos de producción, valores secretos o rotación de credenciales, gasto, publicar contenido, cambios de alcance y la elección entre opciones de corrección. Todo lo demás lo decide él, con el motivo por escrito. Cuando el operador concede autonomía para una ejecución, el orquestador decide como delegado del operador solo para esa ejecución, y las notas lo dicen.

Las revisiones van con reloj, no de memoria. En Copperfern: «Search check» (revisión de búsqueda) a diario a las 05:00 UTC, «Product photo ideas» (ideas de fotos de producto) a diario a las 06:00, «Social post» (publicación en redes) a diario a las 16:00, «Weekly planning» (planificación semanal) cada lunes a las 06:00 y «Monthly research» (investigación mensual) el día 2 de cada mes a las 07:00.

La clasificación, el enrutado, la redacción y las pasadas de revisión funcionan por su cuenta; los requisitos, la fusión, la publicación y la lista de candidatos esperan a una persona; los datos de producción, los secretos, el gasto y las comprobaciones en el sitio en producción nunca se entregan a un agente.

La publicación espera a una persona salvo que una persona ya haya decidido otra cosa para ese trabajo. El contenido rutinario, como las noticias y las traducciones, se publica tras la revisión de otro agente, porque alguien eligió esa columna para el trabajo antes de que se ejecutara por primera vez (qué trabajos esperan un sí).

Algunas reglas no necesitan ningún punto de aprobación, porque un hook bloquea la acción directamente: mira cómo evitamos que Claude Code borre archivos. Los puntos de aprobación son para las decisiones que necesitan a una persona, que es el núcleo de los sistemas de IA con una persona en el bucle.

Un responsable por trabajo, no una matriz RACI

Una matriz RACI reparte un trabajo entre cuatro roles. Para un trabajo de un agente registramos dos nombres: el responsable que hace el trabajo, registrado como el único ejecutor de la tarea, y la persona que aprueba en el punto de aprobación. Un trabajo rechazado sigue rechazado: nunca lo reintentamos con otro ejecutor y nunca lo volvemos a despachar mientras una ejecución anterior pueda seguir viva. Pasear un trabajo de un ejecutor a otro oculta por qué se rechazó. Cada agente tiene además una fila en nuestro inventario de agentes de IA, donde la columna del responsable está junto al interruptor de apagado que lo detiene.

Una ejecución, paso a paso: un cambio, dos síes

Lo útil de un cambio gobernado no es el código. Son los dos momentos en que una persona dice sí y la línea de razonamiento que deja el agente.

Maya pide «una opción de envoltorio de regalo en el pago». Esta es esa solicitud desde el disparador hasta el veredicto:

La congelación del paso 5 es estricta. Los pasos posteriores nunca añaden, quitan ni reinterpretan un requisito. Un cambio de alcance vuelve al paso de requisitos para una nueva aprobación, así que la meta nunca se mueve después del sí.

La comprobación en rojo del paso 7 nunca le llega a Maya como pregunta. Se ejecuta el flujo de corrección y se vuelve a vigilar el veredicto en el nuevo pipeline. Un agente nunca certifica su propia corrección, y un pipeline en rojo bloquea el punto de aprobación de la fusión.

En el paso 9 la fusión necesita un pipeline en verde y una aprobación explícita. La aprobación viene de Maya, o de su delegación por escrito cuando concedió autonomía para esa ejecución. Sin ella, la tarea se queda bloqueada en el punto de aprobación y el tablero la muestra esperando a una persona. Los veredictos de aceptación que lee salen de una ejecución de tests en navegador, descrita en nuestra guía de pruebas de aceptación.

La tarea conserva el motivo de la ruta, los dos puntos de aprobación superados y el historial de CI.

Un cambio, dos síes: el agente enruta la tarea del envoltorio de regalo, Maya aprueba los requisitos congelados, una comprobación en rojo pasa por una corrección y luego Maya o su delegación por escrito aprueba la fusión.

La lista de descartes y el registro del trabajo

Escribe la lista de lo que un agente nunca debe asumir antes que la lista de lo que puede hacer. La lista de descartes es donde vive de verdad la gobernanza.

La lista de despacho

Una ejecución de despacho empieza con una línea de criterios:

criteria: horizon=now; complexity=S; executor=coding-agent; max=5; project=shop; type=task,bug

Después, el agente construye dos tablas. Las tareas que se quedan llevan el motivo por el que encaja cada una. Las descartadas llevan la regla que las descartó. Una tarea se descarta cuando:

• ya existe una ejecución viva o despachada para ella
• está esperando un punto de aprobación del operador
• necesita al operador o acceso en vivo a producción
• tiene la etiqueta manual-qa, production-release, mr-review o ui-review
• no tiene un criterio de terminado concreto
• está bloqueada, o es hija de una tarea bloqueada
• el ejecutor no puede llegar a lo que necesita

En Copperfern, «Rotate the payment provider key» (rotar la clave del proveedor de pagos) se descarta por valores secretos, y «Check the Spanish checkout on the live site» (revisar el pago en español en el sitio en producción) se descarta como QA manual. El mensaje del punto de aprobación dice «Approve the candidate list (or trim it) before anything is dispatched» (aprueba la lista de candidatos, o recórtala, antes de despachar nada). Un rechazo devuelve la ejecución a los criterios.

La lista de despacho conserva tres trabajos con el motivo por el que encaja cada uno y descarta dos con sus motivos; Maya aprueba la lista antes de que empiece ningún agente.

El registro del trabajo

Cada evento gobernado es una línea tipada en el trabajo:

Lee el registro de arriba abajo. El revisor lee el artefacto, no el resumen del ejecutor: cada fragmento del diff, y vuelve a ejecutar los tests afectados. Una línea changes requested (cambios solicitados) detiene la ejecución, y la misma sesión se reanuda con el hallazgo. Un rechazo cuyo motivo no es conocido, como un error desconocido, se convierte en una tarea de bug, así que el escalado termina en un trabajo con seguimiento y no en un mensaje de chat.

Cuatro líneas de nota en un mismo trabajo: despachado, cambios solicitados, aprobado y completado con la solicitud de fusión 14.

Qué sale mal

Los fallos que merece la pena contar son los silenciosos. Un trabajo que deja de ejecutarse y un filtro que no devuelve nada parecen, los dos, «todo bien».

Un trabajo diario que dejó de lanzarse

Uno de nuestros trabajos diarios dejó de lanzarse. Su historial de ejecuciones solo mostraba éxitos, porque una ejecución que nunca empieza no puede fallar.

La capa de programaciones lo detectó. Una programación se marca como missed, con el motivo «No run for too long» (sin ejecutarse desde hace demasiado), cuando el tiempo desde su última ejecución supera 1,5 veces el intervalo normal más largo de su regla. En un trabajo diario son 36 horas. Un lanzamiento omitido no cuenta como ejecución. La marca lleva la fecha en que empezó el silencio y un enlace «Open schedule» (abrir programación) para arreglarlo. La cadencia de revisión informa de su propio hueco en lugar de quedarse callada.

La página de programaciones de ConvOps marca «Product photo ideas» (ideas de fotos de producto) con «No run for too long» (sin ejecutarse desde hace demasiado) mientras «Up next» (a continuación) todavía la muestra para hoy.

Un filtro que no devolvía nada

En nuestra primera ejecución de despacho, la consulta de candidatos pedía las tareas que aún no se habían despachado negando un campo de estado. Ese campo está vacío en todas las tareas que nunca se han despachado. Un filtro negado sobre un campo vacío descarta la fila, así que la consulta devolvía una lista vacía mientras las tareas que encajaban seguían en el backlog. No saltó ningún error, y una lista vacía se lee exactamente como «no hay nada que hacer».

La regla que salió de ahí: nunca niegues un campo que pueda estar vacío; filtra por lo que quieres, no por lo que no quieres. Está escrita en el paso que elige los candidatos: «Nunca filtres por execution_status, executor ni ningún otro campo que admita nulos con ne / nin / NOT». El defecto en sí entró como tarea de bug. La regla vive en el paso, así que se cumple haga lo que haga el motor de consultas. Así es como un fallo se convierte en una regla en todos nuestros bucles.

Crea el tuyo

La gobernanza de agentes de IA en una empresa pequeña empieza con una página y un punto de aprobación. Una empresa pequeña no necesita un consejo de gobernanza. Necesita un responsable en cada trabajo.

La versión de una página para copiar:

AI governance operating model: <company>
Reviewed: <date>    Page owner: <name>

1. Decision rights
   Runs alone:          triage, routing with a one-line reason, drafting, review passes
   Waits for a person:  frozen requirements, merge, publish, the dispatch list
   Never delegated:     production data, secret values, spend, live-site checks
   Stop and ask:        production, secrets, spend, publishing, scope, a choice of fixes

2. Owners
   <job>   owner: <one agent or person>   approver: <person>

3. Escalation
   refused: <job>: <message, verbatim>    unknown reason: open a bug task
   stalled: <job>: <reason>               tell <person>; never dispatch again while alive

4. Gates
   Requirements: <person> approves, list frozen
   Merge or publish: green check AND <person> or their written delegation

5. Reviews
   <job>   <cadence>   missed after 1.5 times the longest normal gap

Rellénala con los trabajos que ya hacen tus agentes. El primer punto de aprobación que debes añadir es el que va antes de que algo salga a producción.

Pon tu primer punto de aprobación dentro de un flujo de trabajo con una cuenta gratuita de ConvOps(se abre en una pestaña nueva). ¿Quieres que lo montemos dentro de tu empresa? Reserva una Discovery Session gratuita.