Manual de gobernanza

GobernIA · Gobernanza de agentes de IA dentro de Jira Service Management · metodología AIGOV · por Prodeo Innovation

Para quién es esta página. Para riesgo, cumplimiento, auditoría y para quien dirige la adopción de IA: propietario de negocio, custodio técnico, aprobador de datos, revisor de riesgo, comité de cambios de IA, comité de gobierno de IA.

Qué resuelve. Qué es exactamense lo que se gobierna, cómo se calcula el riesgo, qué decide el techo de una dirección, quién tiene que aprobar según el nivel, y qué parte de todo eso hace el producto y qué parte sigue siendo de personas.

Cómo leerla. Mezcla dos cosas que no se deben confundir, y por eso van separadas:
«El modelo dice» = la metodología AIGOV. Es lo que el cliente decide y firma.
«El producto hoy» = lo que la app hace. Es menos que el modelo, y la diferencia está dicha donde corresponde.

---

1. Lo que el producto es, en una página

GobernIA aprovisiona en Jira Service Management el andamiaje del modelo AIGOV —campos, tipos de solicitud, el esquema de Assets, perfiles, casos de uso— y emite un sello firmado de lo que hizo. No es un sistema de gobernanza completo: la mayor parte del valor son decisiones del cliente que el producto no toma ni inventa.

Qué problema resuelve y por qué vive dentro de Jira Service Management está en Empezar acá. En dos líneas: gobernar un agente es, operativamente, gestionar un cambio, y la gestión de cambio ya vive ahí — llevársela a otra herramienta obliga a un segundo inventario, un segundo flujo de aprobación y un control que se puede esquivar.

Las ocho reglas del producto

2. La ficha de un despliegue

El modelo dice: cada despliegue se describe con una ficha: organización, perfiles, propósito, responsables, datos, modelo, autonomía, cumplimiento, observabilidad y ciclo de vida.

El producto hoy valida la ficha antes de crear nada, y rehúsa con tres controles:

1. Estructura. La ficha contra el esquema que viaja con el producto.
2. Combinación prohibida. Autonomía L3 o L4 + dato sensible (personal sensible, de salud, de medio de pago, credenciales) + efecto irreversible. No es riesgo crítico: es rediseño obligatorio, y no es aprobable por nadie. El rechazo nombra cuál de las tres condiciones se cumplió y con qué valor.
3. Huella. La huella que declare la ficha se contrasta con la recalculada. Manda la recalculada; si difieren, se avisa. Un cliente que calcula su propia huella controlaría la compuerta: por eso no se le cree.

Qué entra a la huella. Lo que un auditor consideraría cambio de comportamiento o de alcance: el prompt, el modelo con su versión anclada, los adaptadores, las herramientas con su alcance, las fuentes con su modo, los canales, los parámetros de inferencia, las barreras de contención, el nivel de autonomía y los límites operativos. No entran descripciones, nombres de personas, fechas ni números de ticket: cambiar un texto no invalida una aprobación.

Dónde se cumple. Calcular la huella no autoriza nada por sí solo: la regla «cambia el comportamiento, muere la autorización» la hace cumplir la compuerta de despliegue, que busca una solicitud aprobada para esa huella y deniega si no la encuentra. Todavía no se comprobó contra una instalación real, y la autorización se consume una sola vez: pedirla de nuevo sin un cambio nuevo responde que no hay cambio.

3. El riesgo se calcula

El modelo dice que el riesgo sale de siete factores, cada uno con una escala ordenada de menor a mayor:

La suma da un puntaje, y el puntaje cae en uno de cuatro niveles. Los pesos exactos y los umbrales viven en la definición del modelo que viaja con el producto: si el modelo cambia un peso, el cálculo cambia con él sin tocar código, y cada cálculo deja su traza con qué aportó cada factor.

Esta tabla es la bisagra de todo el ciclo. El nivel no sólo dice quién aprueba: dice cada cuánto hay que volver a mirar ese despliegue, y esa periodicidad es la que la vigilancia diaria usa para saber qué vence.

Elevadores. Hay seis condiciones que suben el nivel una vez, aunque apliquen varias, sin pasar del último:

1. La población incluye personas menores de edad o adultas mayores.
2. El impacto en derechos es de decisión, no de apoyo.
3. El agente cae en la categoría de alto riesgo del Reglamento Europeo de IA.
4. Hubo un incidente grave en los últimos noventa días.
5. El agente delega en otro agente de más autonomía.
6. El alojamiento es en infraestructura del cliente con requisito de instancia dedicada.

Lo que hay que saber antes de prometer un nivel

• El riesgo puede quedar incompleto, y entonces no es un nivel. Pasa cuando falta una definición que es del humano o un dato que no está en la ficha. No se asume, y con el riesgo incompleto no se crea nada.
• Hay poblaciones sin lectura de exposición. El factor de exposición sólo lee tres escalones: interno, cliente empresa y público/paciente/ciudadano. Poblaciones como «colaborador», «tarjetahabiente», «menor», «adulto mayor» o «personal clínico» no tienen escalón asignado: salvo que otra población de la misma ficha llegue al escalón más alto, el factor queda sin resolver y el riesgo queda incompleto. La salida es declarar junto a ellas una población que sí se lea, o que una persona de la organización defina la lectura de esa población.
• Tres de los seis elevadores dependen de datos que la app no tiene por su cuenta: el incidente grave reciente, la instancia dedicada de la entidad y el nivel de los agentes a los que delega. Si nadie los informa, el elevador queda «no evaluable» y el riesgo, incompleto.
• El peso del sector sale del perfil sectorial (el más alto, si la ficha nombra varios), y no baja. Hasta noviembre de 2026 algunos sectores declaraban un peso menor colgado de una condición en prosa que nadie podía evaluar; esa condición se eliminó del modelo, porque relajar por falta de dato violaría la regla de que un perfil sólo agrega restricciones. No existe el «peso reducido» de un perfil. El único sector que pesa menos que los demás es el de servicios, comercio y consumo.
• Un perfil funcional no aporta peso al factor de sector: el motor lee el de los sectoriales y avisa si un funcional declara uno.

4. Techo por dirección y excepciones

El modelo dice: cada dirección tiene un techo de riesgo; ninguna opera por encima sin aprobación del comité de gobierno de IA. Una excepción expresa del comité es la única puerta, y debe tener vencimiento.

El producto hoy es de fallo cerrado: una dirección sin techo declarado no es «sin límite» ni «techo por defecto»: no se crea, y el rechazo dice qué dirección y por qué.

Las direcciones no vienen con el producto: el modelo trae el tipo de objeto y ninguna dirección, porque salen del organigrama del cliente. Definirlas y fijar sus techos es una decisión del comité de gobierno de IA y es lo primero que se carga al implantar. Crear algo por encima del techo con una excepción vigente nunca es silencioso: la excepción viaja con la decisión y con su vencimiento, y la vigilancia diaria nombra las excepciones vencidas.

5. Los perfiles

Trece perfiles —siete sectoriales y seis funcionales— agregan restricciones al núcleo del modelo. Su detalle, qué aporta cada uno y cuáles de esas restricciones hace cumplir el producto hoy (casi ninguna) está en la guía de perfiles. Léala antes de hablar de perfiles con un cliente.

6. El ciclo de un cambio, de punta a punta

6.1 El recorrido completo, y qué lo encadena

La versión corta está en Empezar acá. Acá va con los roles y con el artefacto que une cada paso con el siguiente, que es lo que hace que esto sea un ciclo y no una lista de funciones sueltas.

Por qué cierra. El nivel de riesgo calculado en el paso 4 es el mismo dato que decide quién aprueba en el paso 6 y cada cuánto hay que volver a revisar ese despliegue. Al completarse un cambio, la app recalcula la fecha de la próxima revisión con esa periodicidad; llegado el día, la vigilancia nombra el despliegue y la pestaña «Panorama» lo muestra. De ahí el recorrido vuelve al paso 3 (si cambió el agente) o al 5 (si sólo hay que re-aprobar). Un despliegue no «queda aprobado»: queda aprobado hasta su próxima revisión, o hasta que cambie su huella.

Dónde el ciclo informa en vez de actuar

Hay que decirlo cada vez que se describe este recorrido, porque es la diferencia entre un control y un aviso. La vigilancia detecta y lo deja escrito; actuar sigue siendo de una persona.

• La fecha de la próxima revisión se calcula y no se escribe. Ese atributo es de tipo fecha y su formato de escritura todavía no está comprobado. El valor se entrega en el comentario como pendiente para completar a mano, y el resultado del sello es «no verificable», no un verde.
• No se suspende el despliegue con la revisión vencida, no se abre la solicitud de revisión, no se abre la solicitud de remediación de una excepción vencida, no se abre el incidente de gobernanza de una combinación prohibida y no se avisa al comité de gobierno de IA. Esos efectos no se ejecutan solos: el lose los cuenta, queda incompleto y lo dice en el tablero.
• Lo que falta para cablearlos es una comprobación autorizada contra un sitio real, no código.

Y el producto no aprueba en ningún punto de este recorrido. Ninguna operación aprueba, responde una aprobación ni transiciona una solicitud a «Aprobado», y hay pruebas que fallan si alguien lo intenta. Lo que hace es derivar, calcular, bloquear y registrar; firma una persona.

6.2 Quién tiene que aprobar, según el riesgo

El modelo dice que cada cambio a un despliegue se tramita como una solicitud, se categoriza en una de diecinueve categorías de cambio, recibe un tipo (estándar, normal o mayor) y sus aprobaciones se derivan de una matriz por nivel de riesgo:

Más aprobadores acumulativos por categoría de cambio y por condición: si el cambio toca datos entra el aprobador de datos; si amplía la población alcanzada o la entidad, entran el aprobador de datos y el propietario; las categorías más graves suman al comité de gobierno de IA.

6.3 Qué parte de esto hace el producto, y qué parte no

Las aprobaciones, los permisos de los siete roles, las colas y los acuerdos de nivel de servicio no se configuran por API: el plan los emite como especificación para que una persona los configure en Jira, y después la vigilancia los relee y compara. Sobre esa configuración:

• Los cambios se tramitan en Jira, con los roles y las aprobaciones que alguien configuró a partir de esa especificación.
• La validación de la ficha la corre la pestaña «Dar de alta», al revisar y al crear. La evaluación técnica del agente vive en la cadena de integración continua del cliente y la app no la ejecuta ni está diseñada para ejecutarla en esta versión. La autorización del despliegue es la compuerta, que deriva los aprobadores de la matriz para decidir; todavía no se comprobó contra una instalación real. El control posterior al despliegue depende de las métricas del cliente.
• Dos piezas existen en el producto y todavía no se ejecutan solas: la que escribe en la solicitud los aprobadores que corresponden, y la que atiende una autoaprobación. El código existe y se prueba, y nada fuera de las pruebas lo llama. O sea: el campo de aprobadores derivados no se escribe en el ticket, y nadie comenta ni atiende una autoaprobación.
• Lo que sí ocurre es que, con riesgo alto o crítico, la compuerta de despliegue no cuenta la aprobación de quien pidió el cambio, y por eso no autoriza un despliegue cuya única aprobación es la suya. Con riesgo bajo o medio la autoaprobación sí cuenta y la compuerta autoriza: la segregación rige sólo en los niveles que el modelo declara.
• Cuando esa pieza se ejecute, atenderá una aprobación ya registrada; no impedirá registrarla, y no podrá retirarla: la API de Jira Service Management no ofrece quitar una decisión de aprobación. La segregación de funciones del día a día es la de los permisos del proyecto —el rol de revisor de riesgo y el de custodio son distintos—, que se configuran a mano.

7. Qué decide el cliente, y el producto no

Estas decisiones son del cliente, firmadas por quien corresponde:

• El apetito de riesgo y los techos por dirección.
• El catálogo de casos de uso autorizados y su preclasificación.
• Los responsables nominales por despliegue, con suplentes.
• La firma de cada perfil por el experto de dominio.
• La lectura de las poblaciones sin escalón de exposición.
• La determinación jurídica de la categoría del Reglamento Europeo de IA, del rol regulatorio y de la base legal. Las fichas de ejemplo traen estos campos como marcadores de lugar.

El revisor de riesgo debe ser independiente de quien construyó el despliegue. Esa independencia no la verifica ningún código: la app no sabe quién construyó qué. Se declara y se firma.

8. Qué no prometer

• No prometas que el modelo garantiza cumplimiento regulatorio: produce evidencia y estructura decisiones.
• No prometas cobertura automática del inventario: nada en el producto compara lo cargado contra lo que de verdad corre. Es trabajo de campo.
• No prometas que previene ataques adversariales.
• No prometas plazos de aprobación sin haber medido el flujo actual del cliente.
• Prometa la carga de fichas y la vigilancia sólo con sus límites: la carga crea, no actualiza, y no crea los objetos a los que la ficha apunta; la vigilancia corre a diario pero varios de sus efectos no se ejecutan solos y el de emergencias falla todos los días a propósito. No prometas «cargar fichas» como si corrigiera lo ya cargado, ni «la app lo vigila» como si ejecutara esos efectos.
• No prometas el sello en verde: es amarillo por diseño.
• No prometas que la app «verifica quién ejerció un rol»: no lo deriva.
• No prometas Slack: no está en esta versión.
• No prometas que la app vigila la deriva del modelo. La ficha declara umbrales de deriva y la app no los lee: vigilarlos es del tablero de observabilidad del cliente.

---

Dónde seguir

---

GobernIA 2.4.0 · 9 de noviembre de 2026