- Cómo leer esta página
- 1. Qué hace
- 2. Qué no hace, dicho antes y no después
- 3. Lo que Atlassian no deja hacer por API, y el producto no inventa
- 4. Lo que la vigilancia detecta pero no ejecuta
- 5. Lo que existe en el producto pero todavía no se ejecuta solo
- 6. Lo que no hemos comprobado todavía, y por eso no lo prometemos
- 7. Lo que sí está medido, para no quedarse corto tampoco
- 8. Qué necesita su sitio, y qué necesita su organización
- 9. Por qué el sello es amarillo, y por qué eso es la prueba de que esto funciona
- Dónde seguir
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 quien evalúa la compra y necesita saber los límites antes de firmar, no después.
Qué resuelve. El alcance completo: qué hace el producto, qué no hace y no va a hacer en esta versión, qué existe en el producto pero todavía no se ejecuta solo, qué depende de su organización, y qué todavía no hemos comprobado.
Por qué esta página existe. Este producto se vende por no exagerar. Su propio sello sale amarillo mientras quede algo pendiente, y eso es una característica, no una falla. Esta página es la misma idea aplicada a la documentación.
Cómo leer esta página
Todo lo que sigue cae en una de cuatro categorías, y cada afirmación dice en cuál está:
| Categoría | Qué quiere decir |
|---|---|
| Funciona hoy | Está construido, se ejecuta y hay una prueba que lo ejercita. Puede ser una capacidad o una limitación deliberada |
| Existe, pero todavía no se ejecuta solo | El código existe y se prueba, y nada lo llama todavía. No lo prometemos como funcionalidad |
| No lo hemos comprobado todavía | Lo esperamos así, pero nadie lo midió contra Atlassian ni contra una corrida real. Por eso no lo prometemos |
| Fuera de esta versión por decisión | No se va a construir en esta versión, y el porqué está escrito. No es un pendiente |
1. Qué hace
| Capacidad | Estado |
|---|---|
| Aprovisiona la estructura del modelo en Jira Service Management: proyecto, campos, pantallas, estados, dos flujos de trabajo, tipos de solicitud y un esquema de Assets con dieciocho tipos de objeto | Funciona hoy |
| Trae el contenido del modelo: trece perfiles, cuarenta obligaciones normativas y treinta y un casos de uso preclasificados | Funciona hoy |
| Simula antes de escribir. Siempre se simula primero; la simulación sólo lee | Funciona hoy |
| Aplica por etapas, avanzando sola aunque cierres la página, y emite un sello firmado de lo que creó, adoptó y encontró | Funciona hoy |
| Guarda una bitácora encadenada de cada operación y de cada rechazo | Funciona hoy |
| Valida la ficha de un agente contra su estructura y contra la combinación prohibida, con la huella de configuración recalculada | Funciona hoy |
| Calcula el riesgo con siete factores, seis elevadores y cuatro niveles, leyendo todo del modelo: si el modelo cambia un peso, el cálculo cambia con él | Funciona hoy |
| Resuelve los perfiles con traza: qué restricciones gobiernan ese despliegue y quién las impone | Funciona hoy |
| Hace cumplir el techo de riesgo de la dirección, con fallo cerrado: sin techo declarado, no se crea | Funciona hoy |
| Crea en Assets el agente, su versión y el despliegue, y los relee para comprobarlos | Funciona hoy |
| Autoriza o deniega un despliegue por HTTP, contra la huella del cambio, con seis salidas declaradas | Funciona hoy, sin comprobar contra una instalación real |
| Vigila a diario: revisiones vencidas, excepciones vencidas, combinación prohibida, y el cierre del día que degrada el sello | Funciona hoy, con efectos que no se ejecutan solos (§4) |
| Publica un testigo diario del sello en Confluence, fuera del almacén de la app, y lo relee al día siguiente | Funciona hoy, sólo si configura el espacio de Confluence |
| Muestra un tablero de gobernanza de sólo lectura con lo que dejó la vigilancia | Funciona hoy |
Dónde corre. Es una app Forge sobre Jira Service Management Cloud, elegible para Runs on Atlassian. 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.
Qué datos personales guarda. Uno solo: el identificador de cuenta de Atlassian de quien opera la consola. Todo lo demás guarda un alias opaco. Un disparador diario reporta esas cuentas a Atlassian y borra el registro cuando la cuenta se cierra. Eso está implementado y probado contra dobles; todavía no se comprobó contra la API real de Atlassian, y por eso no lo prometemos como medido.
Idioma. Todo el texto del producto está en español. No hay versión en otro idioma.
2. Qué no hace, dicho antes y no después
| No hace | Con todas las letras |
|---|---|
| No aprueba nada | Deriva, calcula, bloquea y registra. Ninguna operación del producto aprueba, responde una aprobación ni transiciona una solicitud a «Aprobado», y hay pruebas que fallan si alguien lo intenta. Quien aprueba es una persona, en Jira |
| No certifica cumplimiento de ninguna norma | Ni del Reglamento Europeo de IA, ni de ninguna otra. Produce evidencia y estructura decisiones; la determinación jurídica es del cliente y su asesoría |
| No borra nada | Retirar es un estado, no un borrado. El catálogo de servicios de Atlassian que la app usa no tiene una sola operación de borrado. La única excepción de todo el producto es el registro de la cuenta de quien opera la consola, que se borra cuando Atlassian informa que esa cuenta se cerró |
| No revierte una corrida | Si un paso falla, la corrida se detiene en la frontera de su etapa. Lo escrito queda escrito, y la bitácora y el sello dicen qué quedó |
| No cambia lo que ya existe y difiere | Lo nombra en «Lo que ya existe y difiere de la ficha» y lo deja como está. Corregir se corrige en Assets |
| No actualiza un agente ya cargado | Crea; no actualiza. Y no escribe el estado de aprobación de un despliegue: ese dato sale como pendiente manual |
| No crea los objetos a los que una ficha apunta | El modelo, el prompt, los adaptadores, las herramientas, las fuentes, los canales, la entidad, la dirección, el proceso y las personas tienen que existir antes en Assets. Si falta uno, la ficha se rehúsa nombrando todos los que faltan. Los casos de uso del modelo sí los crea Aplicar; uno propio lo crea usted |
| No crea direcciones ni fija su techo de riesgo | Es una decisión del comité de gobierno de IA. No es una funcionalidad que falte: es una decisión que no le toca al producto |
| No escribe atributos que vinculan a una persona con su cuenta de Atlassian | La app no sabe escribir ese tipo de atributo: sale como pendiente manual y se llena a mano. Sin él, comparar «la persona nominada» con «la cuenta que aprobó» es una comparación de nombres a ojo |
| No impide una autoaprobación en el momento | Jira Service Management no tiene un evento de «aprobación añadida». Lo que sí hace la compuerta de despliegue es no contar la autoaprobación de quien pidió el cambio, y sólo cuando el riesgo del agente es alto o crítico, porque así lo declara el modelo. Con riesgo bajo o medio la autoaprobación sí cuenta y la compuerta autoriza |
| No dice quién ejerció un rol de gobernanza | La bitácora registra lo que hizo la app, y el actor es quien operó la consola. El traspaso se llena a mano: lista de verificación de traspaso |
| No mide la cobertura del inventario | Nada en el producto compara lo cargado contra lo que de verdad corre en la organización. Es trabajo de campo |
| No 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 |
| No ejecuta la evaluación técnica del agente | Esa evaluación 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 |
| No es el interruptor de apagado | Apagar un agente siempre está permitido y no requiere aprobación previa, pero el interruptor es del agente y del cliente |
| No tiene integración con Slack | Fuera de esta versión por decisión: la notificación es el comentario y la notificación nativos de Jira. Un solo dominio externo costaría la elegibilidad para Runs on Atlassian |
| No tiene un servicio central propio de licencias ni de metodología versionada | Fuera de esta versión por decisión: el licenciamiento es el nativo de Atlassian |
3. Lo que Atlassian no deja hacer por API, y el producto no inventa
Esto no es una carencia del producto: es el límite de la plataforma, dicho y comprobado. Lo que no se puede escribir sale como especificación para hacer a mano, con su motivo escrito, y después la vigilancia lo relee y lo compara con el modelo.
| Qué no se puede crear | Por qué |
|---|---|
| Los filtros de consulta sobre los campos de Assets | Se comprobó, y el resultado fue negativo: no hay API pública; la ruta interna exige atributos que el modelo no declara y, una vez escrita, no se puede releer |
| Las aprobaciones, las colas, los permisos de los roles y los acuerdos de nivel de servicio | Atlassian no ofrece API pública de configuración para eso. De las colas, la app sólo puede leer |
| Un grupo de tipos de solicitud | No tienen API de creación |
| El contenido de las pantallas | La API crea el contenedor vacío; qué campo va en qué pestaña se arma a mano |
| El ícono de los tipos de objeto de Assets | Assets exige un ícono por tipo de objeto y su API no permite subir uno. El producto usa uno que su sitio ya tenga. Si no hay ícono resuelto, toda la parte de Assets sale como especificación y el alta de agentes no tiene dónde escribir |
Algunos atributos de los perfiles tampoco se pueden llenar: si el perfil es sectorial o funcional, su código, y dónde aplica un perfil funcional. El objeto queda con un obligatorio vacío y el sello lo nombra. Rellenarlos por inferencia dejaría la prueba en verde y rompería producción: es una decisión de contenido, y el producto no elige contenido en nombre del cliente.
4. Lo que la vigilancia detecta pero no ejecuta
Ésta es la limitación más importante de esta página, porque es la diferencia entre un control y un aviso.
La vigilancia detecta y lo deja escrito; actuar sigue siendo de una persona. Hoy estos efectos no se ejecutan solos:
- No suspende un despliegue con la revisión vencida.
- No abre la solicitud de revisión periódica.
- No abre la solicitud de remediación de una excepción vencida.
- 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, porque el formato de escritura de ese tipo de dato todavía no está comprobado.
Cuando uno de esos efectos corresponde, el lote del día queda incompleto y lo dice en la pestaña «Panorama», con el motivo. No se simulan ni se aplican a medias.
Y hay un lote que falla todos los días, a propósito: el de las emergencias. Leer la ratificación posterior de una emergencia exige servicios cuya forma todavía no está comprobada, así que ese lote queda fallido cada día, nombrando qué falta. Un lote que dijera «cero emergencias» porque no puede mirar sería peor: daría por vigilada la única ruta cuya defensa es que alguien la mire.
Lo que falta para cablear esos efectos es una comprobación autorizada contra un sitio real, no código.
5. Lo que existe en el producto pero todavía no se ejecuta solo
Dos piezas están construidas y probadas, y nada fuera de las pruebas las llama. No las prometemos como funcionalidad:
- Escribir en la solicitud de Jira los aprobadores que corresponden a ese nivel de riesgo y esa categoría de cambio. Hoy ese campo no se escribe en el ticket.
- Atender una autoaprobación cuando el riesgo es alto o crítico. Hoy nadie comenta ni atiende una autoaprobación desde la app.
Y aunque la segunda se ejecutara, llegaría después de la aprobación, no en el momento: Jira Service Management no ofrece un evento de «aprobación añadida», así que se escucha la actualización de la incidencia y se releen las aprobaciones, con hasta tres minutos de retraso. Además no podría retirar la aprobación: la API de Jira Service Management no ofrece quitar una decisión.
Lo que sí detiene el despliegue es la compuerta, que descarta la autoaprobación por su cuenta cuando el riesgo es alto o crítico.
6. Lo que no hemos comprobado todavía, y por eso no lo prometemos
| Qué | Por qué no está comprobado |
|---|---|
| La compuerta de despliegue contra una instalación real | El esquema de Assets, las personas y las solicitudes de cambio no existen en el sitio de desarrollo: el enlace se probó contra un sitio simulado con formas medidas en otros esquemas y proyectos. Tampoco está comprobado qué trae exactamente el contexto de la llamada, ni si un campo vacío llega como nulo o ausente — ausente se lee como «no se pudo leer» y no autoriza. Trate la primera instalación real como una medición |
| La instalación por un tercero desde el enlace del Marketplace | Todavía no ocurrió |
| El caso negativo de la comprobación de permiso de administrador, desde la app desplegada | El caso positivo sí está comprobado. El negativo se rechaza por diseño y por prueba contra dobles, no por observación |
| El modo restringido con una licencia real de Marketplace | Está probado contra dobles y contra una licencia simulada |
| El reporte y borrado del dato personal contra la API real de Atlassian | Está implementado y probado contra dobles |
| Qué plan de Jira Service Management incluye Assets | Conviene confirmarlo con Atlassian antes de prometérselo a nadie. No lo damos por sentado |
| Que Assets conserve en el historial del objeto quién fijó el techo de una dirección, y cuándo | El valor es visible; el autor y la fecha, no están comprobados |
| Que Atlassian conserve el registro de accesos del rol de auditor | Depende del plan del cliente |
| Qué ocurre con escrituras simultáneas en la bitácora | Que la bitácora sea «sólo de agregar» es disciplina de diseño más la cadena de huellas; el almacenamiento no lo garantiza |
| El servicio de Atlassian de algunos pasos del plan | Cuando el plan marca «Media» en la columna de confianza, quiere decir exactamente eso: ese servicio no se comprobó contra un sitio real |
Y una que es una limitación de la firma, no una medición pendiente: la firma del sello detecta una alteración accidental; no protege contra una persona con acceso al almacenamiento de la app, ni es no repudio. Lo que la refuerza es el testigo diario en Confluence, que publica la cabeza de la bitácora y la firma fuera del almacén.
7. Lo que sí está medido, para no quedarse corto tampoco
Aplicar corrió completo contra dos sitios reales —uno con datos vivos y uno limpio—, terminó Completada con firma válida, cero pasos fallidos y cero que difieran del modelo, y en la segunda pasada no volvió a crear nada: el plan releyó la instancia entera y reconoció lo ya escrito en vez de duplicarlo.
Eso está registrado como corrida, con su identificador. Lo que todavía no ocurrió es que un tercero la instale desde el enlace del Marketplace.
8. Qué necesita su sitio, y qué necesita su organización
Del sitio de Atlassian:
- Jira Service Management Cloud con Assets. Sin Assets no hay dónde escribir.
- Una cuenta con el permiso global Administrar Jira para escribir en producción.
- Un ícono de Assets que el sitio ya tenga.
- La variable de ambientes declarados, antes del primer despliegue a producción.
- Confluence en el mismo sitio, sólo si quiere el testigo diario del sello. Está comprobado que sin Confluence esa pieza no funciona: el testigo no tiene dónde escribir. La app instala y funciona en Jira igual; lo que pierde es ese refuerzo del sello.
De su organización, y el producto no los inventa ni los completa con un valor por defecto:
- La política de gobernanza aprobada.
- Las direcciones y su techo de riesgo.
- Los objetos a los que la ficha apunta, en Assets.
- Las personas responsables, con suplentes, y su vínculo con la cuenta de Atlassian.
- El firmante sectorial. Mientras no esté definido, todo despliegue de un sector que lo exija sale no autorizado, con el perfil nombrado. No es un error: es el fallo cerrado funcionando.
- La determinación jurídica de la categoría regulatoria, del rol y de la base legal.
- La lectura de las poblaciones sin escalón de exposición. Sin ella, el riesgo de esa ficha queda incompleto, y con el riesgo incompleto no se crea nada.
Cuando falta uno de estos, el producto se detiene nombrándolo. Nunca cae a un valor escondido.
9. Por qué el sello es amarillo, y por qué eso es la prueba de que esto funciona
El sello es rojo si algo falló o difiere del modelo, amarillo si hay algo pendiente manual o no verificable, y verde sólo si todo está creado o adoptado.
El sello de esta versión es amarillo, siempre, por diseño. Y seguirá amarillo, porque:
- Hay partes del modelo que Atlassian no deja configurar por API (§3), y salen como especificación manual.
- Hay criterios que el propio modelo declara sin con qué compararlos — por ejemplo la cola «Por aprobar — mías», que queda no verificable mientras el modelo no le dé un criterio comprobable.
Verde no es alcanzable en esta versión, y un verde sería mentira. El sello es un registro firmado de lo que la herramienta creó, adoptó y encontró; no es una certificación.
Si alguien pide «dejarlo en verde», es un pedido que el producto no puede cumplir y no debe cumplir. Lo que sí se hace con el amarillo es trabajarlo: abrir el sello, recorrer los criterios pendientes y dejar por escrito quién se hace cargo de cada uno.
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 |
|---|---|
| Entender el producto desde cero y llegar a su primer agente | Empezar acá |
| Operar la consola, con la tabla de errores | Manual del administrador |
| El método: riesgo, techos, quién aprueba | Manual de gobernanza |
| Qué impone cada perfil y qué parte se hace cumplir | Guía de perfiles |
| Cerrar el traspaso con evidencia | Lista de verificación de traspaso |
GobernIA 2.4.0 · 9 de noviembre de 2026
Comentarios recientes