Atlassian Rovo se entrena desde hoy con sus datos de Jira y Confluence

Sophie Laurent Legal & Compliance Lead, YuSMP Group · Marcos regulatorios de la UE, cumplimiento del RGPD, DORA, NIS2 y el Reglamento de IA para equipos de software

La respuesta corta

Qué datos recopila Atlassian

Atlassian divide la recopilación en dos categorías con derechos de exclusión distintos.

Los metadatos abarcan señales derivadas: puntuaciones de legibilidad, clasificaciones del tipo de tarea, story points, fechas de fin de sprint, valores de SLA y puntuaciones de similitud semántica generadas por el Teamwork Graph. Atlassian afirma que estos datos se desidentifican antes de su uso y que existen salvaguardas para impedir la reidentificación. La empresa sostiene que los metadatos ya están agregados y anonimizados, por lo que trata la exclusión como una función de Premium/Enterprise y no como un derecho básico.

Los datos dentro de la aplicación (in-app) son más sensibles: títulos y texto de las páginas de Confluence, títulos, descripciones y comentarios de los work items de Jira, nombres de estados personalizados y nombres de flujos de trabajo. Esta categoría incluye contenido que puede contener nombres de clientes, hojas de ruta de producto, hallazgos de seguridad y otra información confidencial de proyectos, según cómo usen Jira y Confluence sus equipos.

Los datos se conservan como máximo siete años. Tras una exclusión, los datos in-app se eliminan en un plazo de 30 días y los metadatos en 90 días.

Derechos de exclusión según el nivel de plan

La estructura por niveles significa que las organizaciones con más probabilidades de manejar datos regulados, las de los planes Free o Standard, a menudo empresas pequeñas, startups o equipos de FinTech y HealthTech atentos al coste, son las que menos control tienen. Los clientes del nivel Enterprise, que suelen contar con equipos de cumplimiento y revisión jurídica dedicados, reciben el control completo por defecto. Conviene señalar esta asimetría en su proceso de gestión de proveedores: una herramienta usada para planificar la hoja de ruta o para seguir el backlog de seguridad puede estar en un plan que no se corresponde con la sensibilidad de su contenido.

Qué significa para los equipos de software de EE. UU. y la UE

Por qué la cuestión del RGPD no es trivial

El art. 6, apdo. 4, del RGPD establece una prueba de compatibilidad: cuando un responsable del tratamiento quiere tratar datos con una nueva finalidad no cubierta por el consentimiento o la base jurídica originales, debe evaluar si esa reutilización es compatible. Entrenar un asistente de IA comercial con datos de gestión de proyectos es una finalidad sustancialmente distinta del uso operativo para el que se crearon los datos. Los equipos de software de la UE, y sus clientes cuyos datos fluyen a los tickets de Jira, pueden tener que revisar si su base jurídica actual alcanza a esta reutilización o si hace falta actualizar la evaluación de impacto relativa a la protección de datos (DPIA).

Los equipos que busquen orientación estructurada para este análisis deberían considerar una revisión formal de cumplimiento del Reglamento de IA de la UE y del RGPD, en particular si Jira o Confluence tratan datos personales de interesados de la UE.

Implicaciones para DORA y NIS2

En virtud del art. 28 de DORA, las entidades financieras de la UE deben mantener un registro de todos los acuerdos con terceros proveedores de servicios de TIC. El cambio de política de Atlassian constituye una actualización sustancial de la naturaleza del tratamiento de datos en el marco de ese acuerdo. La entrada del registro correspondiente a Atlassian debería recoger ahora el estado actual de la contribución al entrenamiento de IA, la fecha en que se revisó la configuración y quién aprobó la decisión. Una cláusula de estrategia de salida que contemple los datos utilizados para entrenar modelos, y no solo la extracción de datos al terminar el contrato, es ahora una adición recomendada en cualquier contrato con Atlassian.

Para los equipos sujetos a las obligaciones de seguridad de NIS2, el cambio amplía la dimensión de riesgo de la cadena de suministro: sus datos de incidentes operativos, registros de incumplimiento de SLA y definiciones de flujos de trabajo alimentan ahora un modelo de IA del proveedor. Documentarlo en su mapa de proveedores es el paso mínimo exigible; los equipos que operan infraestructuras críticas pueden necesitar escalarlo a su CISO antes de que entre en vigor el valor por defecto de hoy.

Equipos de EE. UU.: consideraciones de propiedad intelectual y confidencialidad

Los equipos de software de EE. UU. sujetos a SOC 2 o a obligaciones contractuales de confidencialidad deberían auditar si sus instancias de Jira y Confluence contienen datos amparados por NDA de clientes, hallazgos de auditorías de seguridad o especificaciones de producto sin publicar. Atlassian afirma que los datos se desidentifican, pero la definición de desidentificación no elimina el riesgo de exposición de propiedad intelectual en contenido técnico muy específico. Los equipos que desarrollan software para sectores regulados (FinTech, HealthTech, defensa) deberían revisar sus contratos con clientes en busca de cláusulas que restrinjan el entrenamiento de IA por terceros con datos de proyecto antes de que se cierre la ventana de exclusión.

Qué hacer ahora

• Acceda hoy a Atlassian Administration. Vaya a Security → Data contribution y anote su configuración actual. Es la comprobación más rápida, lleva menos de dos minutos y es la base de cualquier acción de cumplimiento posterior.
• Identifique su nivel de plan y la brecha. Si su organización está en Free o Standard y guarda en Jira o Confluence datos regulados, confidenciales o propiedad de clientes, la recopilación de metadatos no es negociable sin mejorar de plan. Decida si esa contrapartida es aceptable o si procede pasar a un nivel superior.
• Clasifique la sensibilidad del contenido. Los proyectos de Jira y los espacios de Confluence varían enormemente en sensibilidad. Un backlog de producto de cara al público no es lo mismo que un seguimiento de vulnerabilidades de seguridad. Clasifique qué espacios y proyectos contienen datos regulados y téngalo en cuenta en su decisión de exclusión.
• Realice la comprobación de compatibilidad del art. 6, apdo. 4, del RGPD. Documente si su base jurídica actual alcanza al entrenamiento de modelos de IA. Si tiene una DPIA anterior a 2024, casi con seguridad no cubre la reutilización para IA. Actualícela o encargue un anexo.
• Actualice los registros de proveedores de DORA y NIS2. Registre el cambio en su registro de terceros proveedores de TIC. Anote la fecha, la configuración elegida, el nivel de plan y el administrador responsable. Este registro le protege en una revisión supervisora.
• Revise los contratos con clientes. Si desarrolla software para clientes y usa Jira para gestionar ese trabajo, compruebe si algún contrato restringe introducir datos de proyecto en sistemas de IA de terceros. Adopte medidas correctoras (exclusión o renegociación) antes de que la obligación contractual y el valor por defecto del proveedor diverjan.

Preguntas frecuentes