Lista de verificación de traspaso

En esta página

  1. Por qué el producto no puede derivarlo hoy
  2. 1. Los cuatro rótulos de evidencia
  3. 2. Los siete roles
  4. 3. La lista de verificación completa
  5. 4. Plantilla para registrar la evidencia de cada rol
  6. 5. Lo que esta lista no puede probar
  7. 6. Cuándo deja de hacer falta el rótulo «hoy nadie lo registra»
  8. 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 recibe el producto al cerrar una implantación, y para quien lo entrega.

Qué resuelve. Qué hace falta para poder decir que el traspaso está hecho, ítem por ítem, y —en cada uno— si el producto ayuda a comprobarlo o si lo tiene que firmar una persona.

Qué dice el modelo. El traspaso consiste en que el cliente ocupe los roles de gobernanza con personas nombradas, con suplentes, y que esas personas hayan ejercido el rol al menos una vez con acompañamiento antes de la firma. «Un rol que nunca se ejerció no está transferido: está asignado en un documento.»

Qué hace el producto con eso: nada. La app no deriva el ejercicio de ningún rol. Esta lista se llena a mano, con evidencia, y cada rol dice qué parte puede mirar una persona en Jira, qué parte podría derivarse del producto pero hoy no se deriva, y qué parte nadie puede verificar por código. Pintar un verde que nadie midió es justo lo que esta página existe para no hacer.

Por qué el producto no puede derivarlo hoy

La bitácora registra lo que hizo la app: buscar, crear, actualizar, omitir, especificar, verificar, autorizar, denegar y borrar. Y el actor es quien operó la consola —una persona administradora—, no quien aprobó un cambio. Ni siquiera los roles que actúan dentro de Jira dejan rastro ahí: la bitácora y el sello son del aprovisionamiento, no de las decisiones de gobernanza.

La compuerta de despliegue ya lee las aprobaciones de una solicitud para decidir, lo cual habilitaría derivar el ejercicio de un rol. Pero leer para autorizar un despliegue y registrar que una persona ejerció su rol son dos cosas distintas, y sólo la primera existe.

1. Los cuatro rótulos de evidencia

Rótulo Qué significa Quién lo verifica
Se ve en Jira Una persona puede abrir el ticket y ver la prueba: el panel de aprobaciones, el historial de transiciones Una persona, mirando Jira
Hoy nadie lo registra El producto ya lee las aprobaciones de una solicitud, así que podría contar el ejercicio. Hoy no lo hace, y nadie lo tiene encargado Hoy, nadie por código
Parcial Jira muestra en qué estado quedó algo y quién hizo la transición, pero la acción real ocurrió fuera de Jira Una persona, y la acción se confirma afuera
Fuera de Jira Ocurre en una sala, un documento o un sistema ajeno. No se pinta de verde: se firma por una persona Una persona, por escrito

Un rol puede llevar más de un rótulo, porque su ejercicio tiene partes distintas.

2. Los siete roles

Una persona puede ocupar roles en los dos modelos —el de gobernanza y el operativo—, con la segregación que el modelo exige.

Rol Qué prueba el ejercicio Rótulo Cómo se comprueba hoy
Propietario de negocio Aprobó al menos un cambio real Se ve en Jira · Hoy nadie lo registra En el panel de aprobaciones de una solicitud, ver el paso del propietario aprobado por la persona nominada. Ojo: no todo cambio ejerce el rol. El propietario aprueba en algunas combinaciones de nivel y tipo de cambio, y por acumulación en ciertas categorías y cuando el cambio amplía la población alcanzada o toca la autonomía. Un cambio de riesgo bajo y tipo normal lo aprueba sólo el custodio
Custodio técnico Ejecutó una reversión real Parcial El ticket muestra el estado Revertido y quién hizo la transición. La reversión misma ocurre en la cadena de despliegue del cliente: ahí se confirma que se ejecutó. El ticket evidencia el estado, no la acción
Aprobador de datos Rechazó al menos una solicitud Se ve en Jira · Hoy nadie lo registra Una solicitud en estado Rechazado por el paso de aprobación del aprobador de datos. Se ve en el panel quién rechazó. Un rechazo de otro rol no cuenta
Revisor de riesgo Validó una ficha de riesgo alto Se ve en Jira · Hoy nadie lo registra · Fuera de Jira para la independencia La aprobación de su paso en una solicitud de un despliegue de nivel alto. Su independencia respecto del equipo que construyó el despliegue no la verifica ningún código: la app no sabe quién construyó qué, y la comparación entre solicitante y aprobador —que es lo que haría la pieza de segregación cuando se ejecute— es otra cosa
Comité de cambios de IA Sesionó una vez Fuera de Jira para la sesión · Se ve en Jira para sus decisiones El criterio del modelo es una reunión: ocurre fuera de Jira. Pero el comité también decide dentro de Jira: aprueba los cambios de riesgo alto. Las aprobaciones de sus miembros son evidencia de decisiones, no de que haya sesionado
Comité de gobierno de IA Aprobó la política y los techos por dirección Fuera de Jira para la política · Parcial para los techos · Se ve en Jira para sus aprobaciones La política es un documento firmado, fuera de Jira. Los techos son un atributo de cada dirección en Assets: el valor es visible, pero no quién lo fijó ni cuándo (si Assets lo conserva en el historial del objeto no está comprobado). Dentro de Jira, el comité aprueba por unanimidad los cambios de riesgo crítico y tramita las excepciones al techo, con su vencimiento
Auditor Ejerció el acceso y produjo un hallazgo Fuera de Jira El rol de auditor es de lectura total y cero transición: no puede dejar una marca de decisión en los tickets. Si Atlassian conserva el registro de accesos depende del plan del cliente y no está comprobado. El hallazgo es un documento fuera de Jira

Dos precisiones que conviene tener a mano al planear el acompañamiento:

  1. El comité de cambios y el comité de gobierno no actúan sólo fuera de Jira. El criterio del modelo sí es externo, pero sus aprobaciones sobre cambios reales quedan en Jira y se pueden mirar a mano.
  2. El propietario y el aprobador de datos sólo se ejercen si el cambio cae en una combinación que los incluye. Un cambio de riesgo bajo y tipo normal no ejercita al propietario. Quien planee el acompañamiento tiene que elegir los cambios con la matriz de aprobaciones en la mano: está en el manual de gobernanza.

Lo que hay que resolver antes de verificar cualquier rol

  • ¿Es la persona nominada la que aprobó? La ficha nombra a los responsables con un objeto de persona en Assets: propietario, custodio, aprobador de datos, revisor de riesgo y firmante sectorial. Ese objeto trae un atributo usuario_atlassian que es la cuenta de Atlassian. El producto no crea objetos de persona y tampoco sabe escribir ese tipo de atributo: sale como pendiente manual. El vínculo persona ↔ cuenta se llena a mano en Assets. Sin él, comparar «la persona nominada» con «la cuenta que aprobó» es una comparación de nombres a ojo.
  • Los objetos de persona no los crea nadie: son datos del cliente.
  • Suplentes. El objeto de persona tiene un atributo de suplente. El traspaso exige personas con suplentes; si el suplente no existe, el rol no está transferido.

3. La lista de verificación completa

Cada ítem dice si el producto de hoy lo puede ayudar a comprobar. Un ítem que el producto no cubre no se marca «hecho»: se marca con lo que de verdad pasa —«no cableado», «no lo mide el producto», «sin comprobar»— y se deja constancia firmada.

# Ítem Qué hace el producto hoy Cómo se comprueba
1 Política de gobernanza aprobada y publicada, con versión y fecha Fuera del producto Documento firmado por el comité de gobierno de IA
2 Perfiles sectoriales y funcionales firmados por el experto de dominio El producto registra los perfiles, no su firma Firma del experto de dominio en cada perfil que use el cliente (guía de perfiles)
3 Cobertura del inventario al cien por ciento de los despliegues en producción No lo mide el producto. Las fichas sí se cargan, pero nada compara lo cargado contra lo que de verdad corre Trabajo de campo: el inventario del cliente contra los objetos de despliegue en Assets, a mano
4 Niveles de riesgo calculados y validados por el revisor independiente El motor calcula el nivel. La validación es humana Aprobación del revisor de riesgo y confirmación de su independencia, firmada
5 Responsables nominales con suplentes, confirmados por cada persona El producto no los verifica Cada persona confirma por escrito; el atributo de suplente completo en Assets
6 Sello revisado, con cada pendiente nombrado y asumido por una persona El sello de esta versión es amarillo permanente por diseño; no hay un verde que alcanzar Abrir el sello, recorrer los criterios «pendiente manual» y «no verificable», y firmar quién se hace cargo de cada uno
7 Segregación de funciones verificada con un intento real de autoaprobación La pieza que atiende una autoaprobación existe en el producto y todavía no se ejecuta sola: nadie comenta ni atiende la autoaprobación. Lo que sí ocurre: con riesgo alto o crítico, la compuerta de despliegue no cuenta la aprobación de quien pidió el cambio y no autoriza un despliegue cuya única aprobación es la suya; con riesgo bajo o medio la autoaprobación sí cuenta. Y la segregación del día a día es la de los permisos del proyecto Un intento real de aprobar el propio cambio, con la cuenta que corresponda, pedir la autorización a la compuerta y registrar que denegó. Cuando esa pieza se ejecute, atenderá la aprobación después de registrada: no la impide, y no puede retirarla
8 Compuerta de autorización integrada en la cadena de despliegue del cliente Construida y en funcionamiento, con seis salidas. Todavía no se comprobó contra una instalación real Se puede cerrar, y la evidencia es una corrida real de la cadena del cliente: un 200 cuando corresponde y un 409 cuando no. La cadena debe tratar cualquier respuesta distinta de 200 como no autorizada. Registrar esa primera corrida como medición
9 Detección de desvío probada: se modificó una configuración sin ticket y se generó el incidente Detectar, sí: los verificadores releen, degradan el sello y la pestaña «Panorama» lo muestra. Generar el incidente, no: abrir una solicitud en Jira Service Management no se ejecuta solo Dividir el ítem. La detección se comprueba: cambiar una cola a mano, esperar la corrida del día siguiente y ver el criterio degradado en el tablero. La apertura del incidente se marca no cableada, no «hecha»
10 Interruptor de apagado probado en un despliegue real, con tiempo medido Fuera del producto. La ficha guarda la fecha de la prueba como declaración Prueba real en el despliegue, con el tiempo medido, por el custodio y la guardia del cliente
11 Vigilancia activa con umbrales de deriva definidos por despliegue La ficha declara los umbrales y la app no los lee. La vigilancia diaria existe, pero mira revisiones vencidas, excepciones vencidas y la combinación prohibida — no la deriva del modelo Los umbrales los define el cliente en la ficha; vigilarlos es del tablero de observabilidad del cliente, no de esta app. Decirlo así evita la peor expectativa rota de esta lista
12 Capacitación por rol ejecutada, con asistencia registrada Fuera del producto Registro de asistencia del cliente
13 Documentación entregada y ubicada donde el equipo la encuentra Esta sección de documentación Entregar el enlace y confirmar quién la custodia
14 Primera revisión trimestral del comité realizada Fuera del producto. Lo que sí hace la app: identifica a diario los despliegues con la revisión vencida y los que ya corresponde suspender. Pero el efecto no se ejecuta: escribir el estado del despliegue, abrir la solicitud y avisar al comité no se ejecutan solos, el lote queda incompleto y lo dice Acta del comité. El tablero sirve para saber a quién convocar, no reemplaza la sesión
15 Plan de cambios predeterminado redactado con datos reales de dos meses Fuera del producto. La ficha puede citar el plan; no lo redacta Documento del cliente, con dos meses de datos

Los ítems 1, 2, 5, 10, 12, 14 y 15 son fuera de Jira y se firman. El ítem 9 se cierra a medias y así se escribe: la detección se comprueba, la apertura del incidente no está cableada. Los ítems 3 y 11 no los mide el producto y no deben figurar como suyos en ninguna acta de traspaso.

4. Plantilla para registrar la evidencia de cada rol

Cópiela por cliente. Un rol sin evidencia no se marca: queda «asignado, no ejercido».

Rol Persona nominada Suplente Rótulo Evidencia (clave del ticket, fecha, panel o documento) Quién la verificó y cuándo Estado
Propietario de negocio Se ve en Jira Ejercido / Asignado, no ejercido
Custodio técnico Parcial Ejercido / Asignado, no ejercido
Aprobador de datos Se ve en Jira Ejercido / Asignado, no ejercido
Revisor de riesgo Se ve en Jira · Fuera de Jira Ejercido, independencia firmada por … / Asignado, no ejercido
Comité de cambios de IA Fuera de Jira · Se ve en Jira Sesión firmada por … · decisiones: …
Comité de gobierno de IA Fuera de Jira · Parcial · Se ve en Jira Política firmada por … · techos: …
Auditor Fuera de Jira Hallazgo firmado por …

5. Lo que esta lista no puede probar

  • Que el control funcione cuando haga falta. Un rol ejercido una vez con acompañamiento prueba que la persona sabe hacerlo, no que lo hará bajo presión.
  • Que la independencia del revisor de riesgo exista. La declara y la firma una persona.
  • Que la vigilancia haya actuado. Vigila y lo deja escrito; pero abrir una solicitud, escribir el estado del despliegue y avisar al comité no se ejecutan solos, así que lo que queda es el hallazgo, no la acción. Un lote incompleto en el tablero es eso, dicho en voz alta.
  • Que el cliente cumpla una norma. El producto produce evidencia y estructura decisiones; la determinación jurídica es del cliente y su asesoría.

6. Cuándo deja de hacer falta el rótulo «hoy nadie lo registra»

Ese rótulo pasa a «vigente» sólo si alguien se hace cargo de registrar el ejercicio de un rol. Hoy la compuerta de despliegue lee las aprobaciones de una solicitud para decidir, y la pieza que escribiría los aprobadores derivados existe sin ejecutarse: ninguna de las dos deja un registro de que una persona ejerció su rol, que es otra cosa. Mientras eso no tenga dueño, el rótulo no se mueve.

Dónde seguir

Si quiere… Lea
La matriz de quién aprueba según el riesgo Manual de gobernanza
Leer el sello y la bitácora en pantalla Manual del administrador
Qué impone cada perfil y quién lo firma Guía de perfiles
Los límites completos, para evaluar la compra Qué hace y qué no hace

GobernIA 2.4.0 · 9 de noviembre de 2026