About this documentation (English summary)
GobernIA is an Atlassian Forge app by Prodeo Innovation that implements the AIGOV governance model for AI agents inside Jira Service Management Cloud. It provisions the model’s structure on the site (project, fields, workflows, request types and the Assets schema), validates each agent deployment card and calculates its risk, gives the customer’s CI pipeline a deployment gate, and runs a daily governance check with a read-only dashboard. It does not approve anything: people approve in Jira.
The manuals are written in Spanish, the language of the app’s interface:
- Empezar acá (Getting started): from installation to the first agent registered in Assets.
- Manual del administrador (Administrator manual): operating the console, the seal, the audit log, the deployment gate and error codes.
- Manual de gobernanza (Governance manual): risk calculation, ceilings per business unit, approvals and the change lifecycle.
- Guía de perfiles (Profiles guide): the sector and functional profiles and what the product enforces today.
- Lista de verificación de traspaso (Handover checklist): verifying governance roles when an implementation is handed over.
- Qué hace y qué no hace el producto (Scope): what the product does and does not do today, for anyone evaluating it.
- Qué es un agente, y qué son los perfiles (What an agent is): the vocabulary of the model — agent, version, deployment and the thirteen profiles.
Support: soporte@prodeoinnovation.com
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 la persona que acaba de instalar la app y todavía no conoce la metodología AIGOV. No hace falta leer nada antes que esto.
Qué va a lograr. Un proyecto de Jira Service Management con la estructura del modelo, y un primer agente dado de alta en Assets con su riesgo calculado y su techo comprobado.
Qué no le va a pasar. No va a descubrir un requisito a mitad de camino: todo lo que depende de usted está más abajo, por adelantado. Y no va a creer que algo se rompió cuando el sello salga amarillo: eso tiene su propia sección.
La solución en una página
Lea esto aunque tenga prisa. El camino sale mejor cuando se sabe para qué es cada paso.
Qué problema resuelve
El control de cambios clásico supone que un artefacto cambia sólo cuando alguien lo despliega. Un agente de IA rompe ese supuesto, y por eso no alcanza con tratarlo como un servicio más.
| Lo que supone el control de cambios clásico | Lo que pasa con un agente |
|---|---|
| El comportamiento vive en el código | Vive en el prompt, el modelo, el adaptador, el corpus y las herramientas: cinco superficies de cambio, no una |
| El cambio es discreto y lo origina usted | El proveedor actualiza el modelo y el corpus se reindexa: hay que gobernar cambios que no originó |
| El sistema es determinista | Es probabilístico: la misma entrada da salidas distintas |
| El sistema espera órdenes | El agente actúa: llama herramientas, escribe en bases, manda mensajes |
| El impacto es técnico | El impacto es sobre personas |
De ahí que el modelo tenga tres piezas y no una, y que cada una conteste una pregunta que, sin esto, nadie puede contestar con evidencia:
| La pieza | La pregunta que contesta | Cómo la contesta el producto |
|---|---|---|
| Registro | ¿Qué agentes hay, y quién responde por cada uno? | Un inventario en Assets: el agente, su versión y cada despliegue, que es este agente, en esta dirección, para esta entidad, en este caso de uso |
| Clasificación | ¿Cuánto riesgo tiene? | El riesgo se calcula de la ficha, no se declara, y el nivel que sale decide todo lo demás |
| Control de cambios | ¿Quién autoriza qué, y sigue valiendo lo que se autorizó? | El flujo de Jira Service Management con los aprobadores que ese nivel exige, y la huella de la configuración: si el comportamiento cambia, cambia la huella y la autorización anterior deja de valer |
El principio que ordena las tres: ningún agente entra, cambia o sale de producción sin ficha completa en el registro y sin cambio aprobado en Jira Service Management.
AIGOV es esa metodología. GobernIA es la app que la pone a funcionar adentro de Jira Service Management.
Por qué vive dentro de Jira Service Management, y no en una herramienta aparte
Porque la tercera pieza —el control de cambios— ya tiene motor: estados, aprobaciones, colas, acuerdos de nivel de servicio y un registro de quién hizo qué. Jira Service Management es el motor de esa pieza y el espejo auditable del registro. Llevarse la gobernanza de IA a otra herramienta obliga a tener un segundo inventario, un segundo flujo de aprobación y un segundo lugar donde buscar la evidencia — y, sobre todo, crea un control que se puede esquivar, porque no está en el camino por el que el cambio ya pasa.
Tres consecuencias concretas de esa decisión:
- No hay egreso de datos. La app no declara un solo dominio externo, y una prueba del propio producto falla si alguien agrega uno. Todo su estado vive en el almacenamiento de la propia app, en Assets y en Jira. No hay un segundo sistema al que mandarle los datos del cliente.
- El control está donde está el cambio. La compuerta que consulta su cadena de despliegue mira la solicitud de Jira: no hay una lista aparte que alguien tenga que acordarse de mantener.
- Y el precio, dicho de frente: lo que Atlassian no ofrece por API, el producto no lo inventa. Lo emite como especificación para hacer a mano, y después lo relee para comprobar que quedó.
El flujo de punta a punta
La app es una sola página de administración con cinco pestañas: Panorama, Agentes, Dar de alta, Aprovisionamiento y Configuración. Tiene una sola entrada en Jira, en Configuración de Jira → Aplicaciones; las demás pestañas están adentro.
Seis momentos. El primero ocurre una vez; los demás son un ciclo.
| # | Qué pasa | Quién lo hace | Dónde | Qué queda |
|---|---|---|---|---|
| 1 | Se aprovisiona la estructura: proyecto, campos, pantallas, estados, dos flujos de trabajo, tipos de solicitud y el esquema de Assets | La persona administradora de Jira, una vez | Pestaña Aprovisionamiento | El proyecto listo, y un sello firmado de lo que se creó, se adoptó y falta a mano |
| 2 | Se declara el agente: se completa la ficha del despliegue en un formulario por pasos y se revisa | Quien conoce el agente, con la consultora | Pestaña Dar de alta | El agente, su versión y el despliegue en Assets, con su huella |
| 3 | Se calcula el riesgo y se contrasta con lo autorizado | La app, sola: mientras completa la ficha, y otra vez al revisarla | Pestaña Dar de alta | Un nivel con su traza: siete factores y seis elevadores → puntaje → uno de cuatro niveles; más el riesgo heredado del agente (el máximo de sus despliegues activos) y el techo de la dirección. Si el nivel supera el techo, no se crea |
| 4 | Se aprueba el cambio, con los aprobadores que ese nivel exige | Las personas: custodio, propietario, revisor de riesgo, aprobador de datos, comité de cambios de IA o comité de gobierno de IA, según el nivel | El proyecto de gobernanza en Jira Service Management (no una pantalla de la app) | Una solicitud aprobada, anclada a la huella de esa configuración |
| 5 | Se despliega, previa consulta a la compuerta | La cadena de integración continua del cliente | La compuerta de despliegue, por su URL | 200 autorizado, o una denegación con su causa. La autorización se consume una sola vez y queda en la bitácora |
| 6 | Se vigila, y vuelve al principio | La app, todos los días | Pestañas Panorama y Agentes | Qué revisiones vencen, qué excepciones vencieron, si alguna configuración dejó de coincidir con el modelo — y el sello degradado cuando algo ya no se puede afirmar |
Y el ciclo se cierra, que es lo que lo distingue de un alta y listo. El mismo nivel de riesgo que decide quién aprueba decide también cada cuánto hay que revisar ese despliegue (anual, semestral o trimestral, según el nivel). Cuando un cambio se completa, el producto recalcula la fecha de la próxima revisión con esa periodicidad; y la vigilancia diaria, llegado el día, nombra el despliegue vencido y lo pone a la vista en «Panorama». De ahí vuelve al paso 2 o al 4, según lo que haya cambiado.
Dónde el ciclo informa en vez de actuar
Esto hay que decirlo cada vez que se describe el ciclo, porque es la diferencia entre un control y un aviso.
La vigilancia detecta y lo deja escrito; actuar sigue siendo de una persona. En concreto, hoy estos efectos no se ejecutan solos:
- No suspende un despliegue con la revisión vencida.
- No abre la solicitud de revisión ni la de remediación.
- No abre el incidente de gobernanza cuando relee una combinación prohibida.
- No avisa al comité de gobierno de IA.
- No escribe la fecha de la próxima revisión: la calcula y la entrega como pendiente para completar a mano.
Cuando uno de esos efectos corresponde, el lote del día queda incompleto y lo dice en la pestaña «Panorama», con el motivo. Un producto que fingiera lo contrario daría por vigilado lo que nadie miró.
El camino, en orden
Son nueve pasos. Los seis primeros son el día 1; el séptimo es el objetivo; los dos últimos son opcionales y se hacen cuando quiera.
| # | Qué hace | Dónde | Cómo sabe que salió bien | Si no sale |
|---|---|---|---|---|
| 1 | Instalar la app y aceptar los permisos | Marketplace o enlace de distribución | La app aparece en Configuración de Jira → Aplicaciones con una sola entrada, y al abrirla ve las cinco pestañas | Falta Assets, o falta el permiso: ver «Del sitio de Atlassian», más abajo |
| 2 | Mirar el plan: Simular (sin escribir) |
Pestaña «Aprovisionamiento» | Aparece la tabla del plan con una fila por paso, y el aviso que suma cuántos se ejecutan, cuántos no y cuántos se completan a mano | Si hay bloqueos, no se puede aplicar: resuélvalos y simule de nuevo (manual del administrador) |
| 3 | Elegir el ícono de Assets | Pestaña «Aprovisionamiento», panel «Ícono de los tipos de objeto (Assets)» | El panel dice «Ícono en uso: …» | Sin ícono, todo lo de Assets sale como especificación y el alta de agentes no tiene dónde escribir. Es el paso que más trabajo ahorra |
| 4 | Aplicar y esperar | Botón Aplicar → Confirmar y aplicar |
La corrida llega a «Completada» y emite un sello | La corrida avanza sola aunque cierres la página. Si se detiene, el motivo está en la bitácora. Nada se borra y no hay reversión |
| 5 | Leer el sello | Panel «Sello de la corrida» | Va a salir amarillo. Es lo correcto: lea «El sello sale amarillo» antes de alarmarse | Rojo sí es un problema: hay un paso fallido o algo que difiere del modelo |
| 6 | Cargar en Assets lo que es suyo: las direcciones con su techo y los objetos a los que la ficha va a apuntar | Assets, a mano | La pestaña «Dar de alta» deja de nombrarlos como faltantes | Es el trabajo que la app no puede hacer por usted, y conviene tenerlo listo antes del paso 7 |
| 7 | Dar de alta el primer agente: completar la ficha en el formulario → revisarla → crear en Assets | Pestaña «Dar de alta» | El veredicto pasa a «Creada» y la tabla «Lo que se crearía» muestra el agente, su versión y el despliegue con su clave de Assets | Si dice «No se puede crear», el detalle nombra la etapa y todos los motivos, completos. Casi siempre falta algo en Assets |
| 8 | (opcional) Enganchar la compuerta de despliegue en su cadena de integración continua | Pestaña «Aprovisionamiento» (sección «Compuerta de despliegue») y su cadena de despliegue | Su cadena recibe 200 con {"veredicto":"autorizado"} cuando corresponde |
Hay tres actos de operación que ninguna prueba reemplaza: ver «Si va a usar la compuerta» |
| 9 | (ya corre sola) La vigilancia diaria y su tablero | Pestañas «Panorama» y «Agentes» | «Panorama» muestra cada lote con su estado y su última corrida completa | Algunos lotes quedan incompletos a propósito: ver qué hace y qué no hace |
Entre el paso 4 y el 7 no hay prisa. Aplicar deja el sitio listo; dar de alta un agente se puede hacer meses después, y cuantas veces quiera.
Lo que tiene que tener listo antes
Esta sección existe para que no descubras un requisito a mitad de camino.
Del sitio de Atlassian
| Requisito | Por qué | Si falta |
|---|---|---|
| Jira Service Management Cloud con Assets | El modelo guarda los agentes, sus versiones y sus despliegues como objetos de Assets | No hay dónde escribir. Qué plan de Jira Service Management incluye Assets conviene confirmarlo con Atlassian: no lo damos por sentado |
| Una cuenta con el permiso global Administrar Jira | En producción, Aplicar y Crear en Assets lo exigen, y se comprueba contra Jira en el momento |
Puede simular y revisar; no puede escribir. Ante la duda, se deniega |
| Un ícono de Assets que el sitio ya tenga | Assets exige un ícono por cada tipo de objeto y su API no permite subir uno | Los tipos de objeto de Assets, sus atributos y sus objetos salen como especificación. Elija uno en el panel del paso 3 y vuelva a simular |
| La variable de ambientes declarados, antes del primer despliegue a producción | La app distingue desarrollo, preproducción y producción, y no adivina en cuál corre | Aplicar se rehúsa nombrando la variable |
| Confluence en el mismo sitio — sólo si quiere el testigo diario del sello | El testigo publica la cabeza de la bitácora y la firma del sello fuera del almacén de la app, y la relee al día siguiente | Está comprobado: en un sitio sin Confluence el testigo no tiene dónde escribir y esa pieza no funciona. La app instala y funciona en Jira igual; lo que pierde es ese refuerzo del sello |
De su organización: lo que la app no puede crear
Son dos cosas, y las dos son decisiones de su organización, no datos del producto.
a) Las direcciones y su techo de riesgo.
Fijar hasta qué nivel de riesgo puede llegar una dirección es una decisión del comité de gobierno de IA. La app no crea ni cambia una dirección ni un techo, por diseño — no es una funcionalidad que falte: es una decisión que no le toca.
Para cada dirección que vayan a nombrar las fichas, cree en Assets un objeto del tipo DIR cuyo nombre sea exactamente el que la ficha trae en el campo de dirección, con estos atributos obligatorios:
nombre · codigo · director_responsable · champion_ia · apetito_riesgo · nivel_riesgo_maximo_autorizado
El techo es ese último atributo, y su valor es uno de los cuatro niveles de riesgo del modelo. Sin dirección, o con una dirección sin techo, la ficha no se crea. La pestaña «Dar de alta» lee las direcciones de todas las fichas antes de revisar una por una, así que se entera de golpe y no de a una.
b) Los objetos a los que la ficha apunta.
Una ficha no se guarda sola: apunta a objetos que ya tienen que existir en Assets. La pestaña «Dar de alta» los nombra y no los crea. Si falta uno, la ficha se rehúsa y el detalle nombra todos los que faltan, no el primero.
| Tipo | Qué es | De dónde sale |
|---|---|---|
MOD |
El modelo de lenguaje | Suyo |
PRM |
El prompt | Suyo |
ADP |
Los adaptadores | Suyo |
TLA |
Las herramientas | Suyo |
DSR |
Las fuentes de datos | Suyo |
CHN |
Los canales | Suyo |
ENT |
La entidad legal | Suyo |
PRC |
El proceso de negocio | Suyo |
PRS |
Las personas responsables | Suyo |
DIR |
La dirección con su techo | Suyo — es el punto (a) |
UCA |
El caso de uso | Los casos de uso del modelo sí los crea Aplicar; uno propio lo crea usted |
Sobre las personas (PRS). El objeto de persona tiene un atributo usuario_atlassian que vincula a la persona con su cuenta de Atlassian. La app no sabe escribir ese tipo de atributo: sale como pendiente para completar a mano. Sin ese vínculo, comparar «la persona nominada» con «la cuenta que aprobó» es una comparación de nombres a ojo. Está en la lista de verificación de traspaso.
Si va a usar la compuerta de despliegue
Tres actos de operación que ninguna prueba reemplaza:
- Obtener la URL de la compuerta para su instalación. Se crea una sola vez.
- Emitir la credencial desde la sección «Compuerta de despliegue (Gate 3)» de la pestaña «Aprovisionamiento». Se entrega una sola vez; rotarla es emitir otra, y la anterior muere en el acto.
- Guardarla como secreto de su cadena de despliegue.
Y una decisión de su organización: el firmante sectorial. El modelo lo describe en prosa, y ningún código saca personas de una frase. Mientras nadie lo fije en la pestaña «Configuración», todo despliegue de un sector que lo exija sale no autorizado, con el perfil nombrado. No es un error: es el fallo cerrado funcionando.
Lo que no se delega en la app, nunca
La política de gobernanza aprobada, los techos por dirección, las personas responsables y los contenidos de cada ficha son del cliente. El producto no los inventa, no los sugiere y no los completa con un valor por defecto. Cuando falta uno, lo dice nombrándolo.
Las palabras del producto, traducidas una vez
Son las que va a ver en pantalla. Están acá para que no tenga que deducirlas.
| Palabra | Qué quiere decir, en una línea |
|---|---|
| Ficha | La descripción de un despliegue de un agente: qué hace, con qué datos, con cuánta autonomía y quién responde |
| Lote | Varias fichas juntas, que se traen con «Importar lote (JSON)» en la pestaña «Dar de alta». Se revisan de a una y se crean de a una |
| Plan | La comparación entre su sitio y el modelo, paso por paso, antes de escribir nada |
| Huella de configuración | El resumen calculado de una configuración. Si la configuración cambia, cambia la huella, y lo que se había autorizado deja de valer |
| Se completa a mano (no se escribe) | La acción de un paso del plan que nunca se escribe: es una instrucción para hacer a mano. No es un error |
| Adoptar | Ya existía, coincide con el modelo y no se toca. No degrada el sello |
| Sello | El registro firmado de lo que una corrida creó, adoptó y encontró. Es un registro, no una certificación |
| Pendiente manual | Resultado del sello: hay una especificación esperando que una persona la complete |
| No verificable | Resultado del sello: todavía no hay cómo comprobarlo, o la corrida no llegó a comprobarlo. Nunca cuenta como verde |
| Criterios que no están en verde | En la pestaña «Panorama», los criterios del sello que no son «creado» ni «adoptado»: su lista de trabajo pendiente |
| Techo de la dirección | El nivel de riesgo máximo que una dirección tiene autorizado. Lo fija el comité, no la app |
| Bitácora | El registro encadenado de cada operación y de cada rechazo, con quién, cuándo y con qué resultado |
| Parámetro | Un valor de operación del producto. Cada uno tiene dueño y motivo; si falta, la app se detiene nombrándolo en vez de inventar uno. Los que decide su organización se editan en la pestaña «Configuración» |
El sello sale amarillo, y está bien
El sello de esta versión es amarillo, siempre, por diseño. No es una falla ni una instalación a medias: es el producto negándose a afirmar lo que no comprobó.
Un sello se agrega así:
- Rojo si algo falló o difiere del modelo.
- Amarillo si hay algo pendiente manual o no verificable.
- Verde sólo si todo está creado o adoptado.
Y siempre hay pendientes manuales, porque hay partes del modelo que Atlassian no deja configurar por API y porque hay criterios que el propio modelo declara sin con qué compararlos. Mientras eso sea así, verde no es alcanzable, y un verde sería mentira.
Qué hacer con el amarillo, que es lo que de verdad importa: abra el sello, recorra los criterios «pendiente manual» y «no verificable», complete a mano lo que corresponda y deje por escrito quién se hace cargo de cada uno de los que quedan. Eso es el trabajo real de implantación, y está en la lista de verificación de traspaso.
Si alguien le pide «dejarlo en verde», es un pedido que el producto no puede cumplir y no debe cumplir.
Cuando la pantalla le dice algo que no esperabas
Ninguna pantalla se queda callada: cada rechazo trae su código y su motivo completo. La tabla de códigos está en el manual del administrador. Tres que va a ver seguro:
- «Se completa a mano (no se escribe)» en el plan. No es un error. Es un paso que se completa a mano, a propósito.
- «Falta un parámetro». La app nunca cae a un valor escondido. El mensaje nombra cuál falta; si es decisión de su organización, está en la pestaña «Configuración».
- «No se puede crear» en el alta. El detalle dice en qué etapa se detuvo y todos los motivos. Nada se escribió.
Una regla que vale para todo el producto: si algo no se pudo comprobar, se deniega. No hay un camino en el que una duda termine en «autorizado».
Dónde seguir
| Si quiere… | Lea |
|---|---|
| Operar la consola a fondo, con la tabla de errores | Manual del administrador |
| Entender el método: riesgo, techos, ciclo de un cambio | Manual de gobernanza |
| Saber qué impone cada perfil sectorial o funcional | Guía de perfiles |
| Cerrar el traspaso al cliente | Lista de verificación de traspaso |
| Saber exactamente qué hace y qué no hace el producto | Qué hace y qué no hace |
La regla de redacción de estas páginas: ante la duda entre una frase vendedora y una exacta, vale la exacta.
GobernIA 2.4.0 · 9 de noviembre de 2026
Comentarios recientes