English version: Privacy Policy
Versión: 1.0
Vigente desde: 6 de noviembre de 2026
1. Quiénes somos
GobernIA es un producto de Prodeo Innovation (sitio web: https://prodeoinnovation.com).
- Razón social completa: Prodeo Innovation S.A.
- Domicilio: Escazú Village, Guachipelín, Escazú, San José, Costa Rica
- Jurisdicción y ley aplicable: Costa Rica
- Contacto para privacidad:
info@prodeoinnovation.com
2. Qué es GobernIA
GobernIA es una aplicación de Atlassian Forge para Jira Service Management Cloud. Instala y verifica en el sitio del cliente el andamiaje de gobernanza de agentes de IA de la metodología AIGOV: campos, pantallas, estados, workflows, un proyecto y un esquema de Assets. Diagnostica el sitio, arma un plan, lo simula sin escribir y, tras una confirmación deliberada, aplica los pasos que puede ejecutar (escribe en el sitio); cada operación queda registrada. La aplicación no aprueba nada: las decisiones las toman personas. Está pensada para administradores del sitio y vive en una página de administración dentro de Jira; en producción, aplicar exige el permiso de administrador de Jira (apartado 4).
Esta política describe cómo está diseñada la app para funcionar. Es informativa y no crea garantías ni obligaciones distintas de las establecidas en los Términos de uso.
3. Dónde corre y a dónde van los datos
- GobernIA corre en la plataforma Forge: el cómputo y el almacenamiento son de Atlassian.
- El manifiesto de la app no declara ningún destino externo (no existe
permissions.external). El código no contiene llamadas de red propias: toda comunicación pasa por las funciones de Forge hacia Jira, Jira Service Management y Assets del mismo sitio, más el reporte de la app a la API de reporte de datos personales de Atlassian, que es un servicio de Atlassian (apartado 8). - La aplicación no envía datos a Prodeo ni a terceros. No hay telemetría, analítica ni servicio remoto de Prodeo.
- Los datos que la app guarda están en el almacenamiento (KVS) de Forge de su instalación. Ese almacenamiento lo opera Atlassian; sus condiciones de cifrado, aislamiento por instalación y residencia son las de Atlassian y se rigen por sus documentos, no por una promesa nuestra. La residencia de datos la determina la ubicación que elige el administrador en el producto Atlassian anfitrión.
4. Qué datos del sitio toca la app
Para leer y escribir en el sitio la app actúa con su propia identidad (no con la de la persona que la opera). Una llamada es distinta: cuando alguien abre el diálogo de Aplicar o pulsa Aplicar en una instalación de producción, la app le pregunta a Jira, con la identidad de esa persona, si su cuenta tiene el permiso global Administer Jira (GET /rest/api/3/mypermissions?permissions=ADMINISTER). Esa llamada lee solo el permiso de quien pregunta, y la respuesta sirve para permitir o denegar: no se guarda nada de ella salvo el resultado que registra la bitácora (una autorización o un rechazo, bajo el alias de la persona). La app no pide a nadie tokens, contraseñas ni credenciales de Atlassian.
Lee, para comparar con el modelo: el catálogo de configuración del sitio — nombres e identificadores de campos personalizados y sus opciones, pantallas, esquemas, estados, workflows, tipos de incidencia, el proyecto indicado, los tipos de solicitud, y el esquema de Assets del modelo (tipos de objeto, atributos, tipos de referencia, objetos), más la lista de íconos globales del workspace de Assets del sitio (identificador y nombre), porque Assets exige un ícono por cada tipo de objeto.
Escribe, cuando una persona aplica un plan: solo después de que esa persona lo simuló, lo revisó y confirmó en un diálogo; solo elementos cuyo nombre exacto declara el modelo; y, en una instalación de producción, solo si Jira confirma que la persona tiene el permiso Administer Jira. La corrida vuelve a leer el sitio y se rechaza si ya no coincide con el plan que se revisó. Nunca borra nada de su sitio y no hay deshacer automático (el código no tiene ninguna llamada de borrado; retirar algo es un estado). En esta versión crea campos personalizados con sus contextos y opciones, pantallas, un tipo de incidencia, el esquema de Assets y los tipos de referencia y, cuando se resolvió un ícono en su sitio, tipos de objeto, atributos y objetos de Assets. No crea estados, workflows, el proyecto, los tipos de solicitud ni los filtros AQL: esos pasos se emiten como especificación para completar a mano, con el motivo en pantalla, y nunca se informan como hechos.
El ícono de Assets se elige por sitio y por cliente. Assets no puede recibir un ícono de la app, así que la app busca en su sitio el ícono cuyo nombre declaran sus parámetros y, si no hay ninguno o hay varios, un administrador elige uno de la lista del propio sitio en la consola. La elección se guarda solo para esa instalación (apartado 5).
Scopes. El manifiesto declara 24 scopes, en dos grupos. 23 los usa hoy alguna línea del código de la app: lectura de trabajo de Jira y del catálogo de configuración (que también sirve para la comprobación de administrador de arriba), administración de la configuración de Jira y del proyecto indicado, tipos de solicitud de Jira Service Management, esquema, tipos, atributos, objetos e íconos de Assets (read:cmdb-icon:jira), el almacenamiento propio de la app, y la API de reporte de datos personales de Atlassian (report:personal-data). 1 está declarado por adelantado, para la función que lo va a usar, y el código todavía no lo usa: read:jira-user (funciones previstas de aprobación de cambios: derivar aprobadores y comparar solicitante contra aprobador). Otros cuatro scopes declarados por adelantado ya están en uso: write:jira-work y write:servicedesk-request para la aprobación de cambios, y read:confluence-content.all y write:confluence-content con el testigo diario del sello de conformidad en Confluence. Un scope comprometido se declara por adelantado porque agregar un permiso después de la primera instalación obliga a una nueva versión mayor y a que cada administrador consienta; si la función a la que sirve no se publica, se quita del manifiesto. Hoy la app escribe en incidencias de Jira y lee y escribe una página de Confluence; no lee perfiles de usuario, y aun así la pantalla de permisos que ve el administrador incluye escritura en Jira, lectura de usuarios de Jira y contenido de Confluence. read:jira-work es un scope amplio de Atlassian que técnicamente permite leer incidencias, pero hoy la app no lee incidencias, comentarios ni perfiles de usuario. Cuando se publique una función que lea perfiles de usuario, esta política se actualiza antes de liberar esa versión (leer personas es tratar datos personales: el identificador de cuenta y lo que devuelve la API de usuarios de Jira).
Los nombres de los objetos de configuración son los que el cliente les puso. Si el cliente escribió datos personales en un nombre de campo, de pantalla o de workflow, la app puede leerlo para el plan; no los busca ni los separa.
5. Qué datos guarda la app
Todo en el KVS de Forge de la instalación:
| Qué | Contenido | Persona identificable |
|---|---|---|
| Bitácora (append-only, encadenada por hash) | Cada operación y cada rechazo: momento (UTC y hora de Costa Rica), ambiente, identificador del sitio (cloudId), verbo y destino de la operación, huellas (digest) de lo enviado y un resumen redactado de hasta 2.048 bytes (un parámetro de la app), resultado, versión de la app, huella del modelo, identificador de la corrida |
Seudónima: un alias opaco de quien operó, no su accountId (ver Registro de personas) |
| Estado de la corrida | Etapa alcanzada, pasos ejecutados, evidencia por paso; mientras una corrida está en curso, los pasos de su plan (elemento del modelo, acción, endpoint, huellas del estado del sitio, textos de motivo); la URL del sitio y el estado de licencia de la instalación | Seudónima: el alias de quien la lanzó |
| Cerrojo de corrida | Quién y cuándo tomó el turno de ejecución, y su vencimiento | Seudónima: el alias de quien lanzó la corrida |
| Autorización de producción | Registro de una autorización de un solo uso atada a un plan: alias de quien autorizó, identificadores del sitio y de la instalación, huella del plan, vencimiento y una prueba calculada con la clave de la instalación | Seudónima: el alias de quien autorizó |
| Ícono de Assets elegido | El identificador y el nombre del ícono que un administrador eligió para esta instalación, la fecha y el alias de quien lo eligió | Seudónima: el alias de quien lo eligió |
| Registro de personas | Un registro por persona que operó la consola: su accountId de Atlassian, el alias que se le asignó, la fecha de alta y la fecha desde la que el dato está vigente. Es el único lugar donde se guarda el accountId |
Sí: el accountId |
| Sello de conformidad | Resultado por criterio y su firma | No |
| Mapa de identificadores | Qué identificador de Jira o Assets corresponde a qué elemento del modelo | No |
| Clave de firma del sello | 32 bytes aleatorios generados por la app, guardados en el almacén de secretos de Forge | No |
| Clave de autorización de la instalación | 32 bytes aleatorios que la app genera en el primer uso, una por instalación, guardados en el almacén de secretos de Forge; firma las autorizaciones de un solo uso. Nadie la teclea ni la ve | No |
Lo que no se guarda: nombre real, correo, foto ni número de teléfono de nadie (la app no guarda un nombre visible: solo el alias y, en el registro de personas, el accountId); ninguna credencial del cliente. No hay ninguna llave de producción que guardar: la autorización es el permiso Administer Jira, comprobado contra Jira, más la clave de la instalación de arriba, que la app genera y nadie teclea. Una prueba automática comprueba que el accountId aparece en un único registro guardado y en ningún valor guardado.
Sobre el accountId y el alias. El accountId es el identificador de cuenta de Atlassian y el alias es un identificador aleatorio que la app asigna a cada persona. Mientras el registro de personas conserve el registro, la app puede resolver un alias a su accountId (la consola lo hace para que el administrador vea quién operó), así que las entradas de la bitácora son entradas de una persona identificable. Tratamos el accountId, y el alias mientras se pueda resolver, como dato personal. Para qué se guardan: registrar quién operó, quién autorizó y quién eligió el ícono (auditoría de la gobernanza del propio cliente) y evitar dos corridas simultáneas. No los usamos para ninguna otra finalidad. Base legal del tratamiento: el interés legítimo del Cliente en auditar su propia gobernanza y la ejecución del contrato de licencia con el Cliente; si la ley aplicable exige otra base (por ejemplo el consentimiento), obtenerla corresponde al Cliente como responsable.
Roles. Nuestra posición es que el cliente decide por qué registra esas operaciones (su propia auditoría) y que GobernIA las trata por cuenta del cliente. El Cliente es el responsable de estos datos. Prodeo no tiene acceso a ellos en la operación normal de la app, porque quedan en el almacenamiento de Forge de la instalación del Cliente; en la medida en que Prodeo trate alguno (por ejemplo en un caso de soporte), lo hace como encargado y solo según las instrucciones del Cliente. Los clientes que necesiten un acuerdo de tratamiento de datos (DPA) pueden pedirlo a info@prodeoinnovation.com; sus términos se acuerdan caso por caso.
6. Con quién se comparte
- Terceros desde la app: ninguno. La app no comparte datos con subencargados.
- Atlassian aloja la app y su almacenamiento y trata los datos conforme a sus propios términos y a su política de privacidad. Esta política no los sustituye.
- Los proveedores que Prodeo use para su correspondencia de soporte (apartado 10): Microsoft (servicio de correo Microsoft 365, Estados Unidos y otros centros de datos de Microsoft), usado solo para recibir y contestar la correspondencia de soporte y de privacidad.
7. Cuánto tiempo se conservan
- Mientras la app esté instalada. La app no borra nada por diseño (retirar un elemento es un estado, no un borrado), con una excepción: borra el registro de una persona del registro de personas cuando Atlassian informa que esa cuenta se cerró (apartado 8). No tiene vencimiento automático: todo lo demás que se guarda en el KVS permanece hasta que la app lo actualice, y la app no lo borra.
- Tras desinstalar rige el ciclo de vida del almacenamiento alojado de Forge, que gestiona Atlassian. No declaramos un plazo propio porque la documentación oficial de Atlassian no es uniforme sobre el número exacto de días; consulte su documentación vigente (https://developer.atlassian.com/platform/forge/storage-reference/hosted-storage-data-lifecycle/).
8. Acceso, corrección y borrado
Qué hace la app cuando una cuenta se cierra.
- La bitácora, el estado de la corrida, el cerrojo, las autorizaciones de producción y el registro del ícono elegido guardan un alias opaco, no el
accountId. ElaccountIdestá en un registro por persona (el registro de personas), que se puede consultar poraccountId, como piden las guías de Atlassian. - Una función programada corre una vez al día y reporta a la API de reporte de datos personales de Atlassian los
accountIddel registro, a lo sumo una vez por ciclo: siete días por defecto (es un parámetro de la app). - Si Atlassian responde que una cuenta está cerrada, la app borra el registro de esa persona. Desde ese momento el
accountIdya no existe en el almacenamiento de la app y el alias que quedó en la bitácora, las corridas, los cerrojos, las autorizaciones y el registro del ícono elegido deja de poder atribuirse a una persona por parte de la app; la consola muestra ese alias como cuenta cerrada. Si Atlassian responde que la cuenta fue actualizada, la app solo refresca la fecha desde la que el registro está vigente: no guarda ningún perfil que actualizar. La cuentaunknownnunca se guarda ni se reporta. - La bitácora sigue siendo verificable después de un borrado: su cadena de hash cubre el alias, no el
accountId. Es seudonimización con la llave destruida, no una reescritura de la historia: las entradas permanecen (qué se hizo, cuándo, sobre qué sitio) sin una persona asociada. - Si el reporte falla, o Atlassian responde algo inesperado, la función falla a la vista (la invocación queda registrada como fallida en los registros de la app), aplica lo que fue válido y no marca el reporte como hecho, de modo que reintenta en la siguiente ejecución. No sigue en silencio.
- El tiempo entre que una cuenta se cierra y su registro se borra depende del ciclo de reporte de arriba y de los tiempos propios de Atlassian, por lo que no nos comprometemos a una cifra exacta.
Lo que la app no hace. No tiene una función para borrar a una persona a pedido antes de que se cierre su cuenta: el único borrado es el que dispara el reporte de Atlassian de una cuenta cerrada. Para una solicitud así, escriba al contacto del apartado 1: la responderemos con lo que técnicamente podamos hacer y le diremos con claridad lo que no. Plazo de respuesta: dentro del plazo que fije la ley aplicable. Procedimiento para borrar a una persona antes de que se cierre su cuenta: el administrador del sitio del Cliente escribe a info@prodeoinnovation.com desde su correo corporativo, identificando el sitio y la persona; confirmamos la solicitud y acordamos con el administrador los pasos disponibles.
Prodeo no puede borrar directamente datos del almacenamiento de su instalación: según la documentación de Atlassian, un desarrollador no puede borrarlos directamente tras la desinstalación; durante el uso, el único borrado es el que la propia app hace como se describió arriba.
Lo que sí puede hacer:
- Desinstalar la app desde la administración de su sitio; Atlassian aplica entonces el ciclo de vida del apartado 7.
- Pedir acceso: cualquier administrador con acceso a la página de GobernIA puede ver las entradas de la bitácora en esa misma página.
- Escribir al contacto del apartado 1 para cualquier solicitud.
9. Seguridad
- El almacenamiento está protegido por las medidas de Atlassian (cifrado en disco y aislamiento por instalación, según su documentación de Forge). No hacemos una afirmación propia sobre ellas.
- La app aplica un perímetro de nombres: solo puede crear en el sitio elementos cuyo nombre exacto declara el modelo. Cada denegación queda registrada.
- En una instalación de producción, aplicar exige el permiso Administer Jira, comprobado contra Jira en el momento de aplicar; si la comprobación no se puede hacer, la respuesta es una denegación, registrada con su causa. Esto detiene a quien no es administrador; no detiene a un administrador, que puede hacer a mano todo lo que hace la app.
- La bitácora detecta si una entrada fue alterada, y el sello lleva una firma. No son prueba de no repudio: protegen contra alteración accidental o manipulación del almacén por quien no tiene la clave, no contra un administrador con acceso al almacenamiento de la app.
- Contacto de seguridad y política de seguridad: info@prodeoinnovation.com (asunto: «Seguridad»).
10. Datos que Prodeo trata por fuera de la app
Aunque la app no nos envía nada, Prodeo puede recibir datos por otras vías:
- Soporte. Quien nos escriba nos da su nombre, su correo y el contenido del caso. Canal de soporte:
soporte@prodeoinnovation.com. Conservación: el tiempo necesario para atender el caso y hasta dos años después de cerrado. - Licencias y transacciones de Marketplace. Atlassian puede darnos, como socio, información de licencias y de contacto según el Marketplace Partner Agreement. Puede incluir los datos de la licencia y los contactos técnicos y de facturación del Cliente; Prodeo los usa solo para gestionar licencias, dar soporte, facturar y enviar comunicaciones del servicio, y los conserva mientras la licencia esté vigente y después durante el tiempo que exija la ley (por ejemplo, para fines contables).
- Transferencias internacionales. Si Prodeo atiende desde fuera de su país o del Espacio Económico Europeo, la correspondencia de soporte puede cruzar fronteras. Prodeo opera desde Costa Rica y su correspondencia se almacena en Microsoft 365; las transferencias se apoyan en las garantías contractuales de Microsoft, incluidas las cláusulas contractuales tipo cuando aplican.
11. Sus derechos
Según la ley que le aplique (por ejemplo el RGPD o la ley de protección de datos de su país), usted puede tener derecho a acceder, rectificar o borrar sus datos, a oponerse o limitar su tratamiento. Para ejercerlos, escriba al contacto del apartado 1. Para los datos que guarda la app dentro de su instalación, el apartado 8 dice qué es posible hoy. Puede reclamar ante la autoridad de protección de datos de su jurisdicción: en Costa Rica, la Agencia de Protección de Datos de los Habitantes (PRODHAB); en otros países, la autoridad de su país.
12. Menores
GobernIA es una herramienta de administración de TI para organizaciones; no está dirigida a menores de edad.
13. Cambios a esta política
Publicaremos la nueva versión con su número y fecha. La nueva versión rige desde su fecha de vigencia; cuando la ley aplicable lo exija, Prodeo notificará los cambios sustanciales por medios razonables. Si una versión de la app empieza a leer o guardar datos nuevos (por ejemplo incidencias o usuarios), esta política se actualiza antes de liberar esa versión.
Comentarios recientes