¿Está Atlassian entrenando IA con los datos de su Jira? Esto es lo que cambia el 17 de agosto
Si administra un sitio de Jira, Confluence o Jira Service Management, es probable que Atlassian ya le haya enviado un correo sobre los nuevos ajustes de «contribución de datos» ("data contribution"). Esto es lo que realmente significa, y qué hacer al respecto antes del 17 de agosto de 2026.
Qué está cambiando: Atlassian está desplegando controles a nivel de organización en Atlassian Administration (Security → Data contribution) que rigen si sus metadatos y el contenido dentro de las aplicaciones se utilizan para entrenar los modelos de IA de Atlassian y mejorar sus funciones basadas en IA en Jira, Confluence, JSM y las aplicaciones de Platform conectadas. A partir del 17 de agosto de 2026, Atlassian comenzará a usar sus datos según estén configurados esos ajustes, ya sea por usted o dejados en su valor predeterminado.
Lo que la mayoría de los administradores pasa por alto: su nivel de control sobre esto depende enteramente de su plan. Solo los clientes de Cloud Enterprise pueden desactivar por completo la contribución de metadatos. Todos los demás niveles —Free, Standard, Premium— contribuyen metadatos automáticamente, sin posibilidad de desactivarlo. Lo que normalmente sí puede controlar, independientemente del plan, es el contenido dentro de la aplicación: puede excluir espacios específicos de Confluence, proyectos de Jira o conectores de Teamwork Graph de la contribución, aunque no pueda desactivar el ajuste por completo.
Qué hacer en la práctica: vaya a Atlassian Administration → Security → Data contribution y revise qué está ya configurado. Confirme el plan más alto activo de su organización (este determina sus valores predeterminados; incluso una sola licencia Enterprise en cualquier parte de su organización cambia el cálculo para todo lo que hay dentro de ella). Si su organización maneja datos de clientes, información regulada o cualquier elemento cubierto por un acuerdo de procesamiento de datos, decida deliberadamente si determinados proyectos o espacios deben excluirse, en lugar de heredar lo que resulte ser el valor predeterminado.
Esto es un solo ajuste, en una sola plataforma. Si su organización también utiliza Slack, Notion, GitHub, Salesforce o media docena de otras herramientas SaaS conectadas, cada una está tomando silenciosamente su propia versión de esta misma decisión en su nombre; algunas con un interruptor visible, otras (como el entrenamiento de aprendizaje automático no generativo de Slack) sin ningún interruptor en absoluto, con exclusión únicamente por correo electrónico. Ese patrón —ajustes reales, plazos reales, consecuencias reales, enterrados en un panel de administración que nadie tiene asignado revisar— es exactamente lo que los conectores de 8200.dev están diseñados para sacar a la luz automáticamente, en cada plataforma que haya conectado, no solo en la que esta semana decidió enviarle un correo.
La decisión que nadie tenía asignada
Aléjese por un momento de Atlassian y observe la forma del problema, porque se repite en todas partes.
Cada proveedor de SaaS que construye funciones de IA se enfrenta a la misma pregunta: ¿de qué datos de clientes pueden aprender los modelos? Cada proveedor la responde de forma distinta, publica la respuesta en un lugar diferente y otorga a los clientes un grado de control distinto:
- Slack utiliza mensajes y contenido de clientes para entrenar modelos de aprendizaje automático no generativos a nivel de plataforma (clasificación de búsquedas, recomendaciones) de forma predeterminada. No existe ningún interruptor de administrador en ninguna parte de los ajustes del espacio de trabajo; excluirse significa que el propietario del espacio de trabajo envíe un correo a la dirección de comentarios de Slack y lo solicite.
- Dropbox expone un ajuste de «IA de terceros» cuyo valor predeterminado depende de dónde reside su cuenta: activado de forma predeterminada para cuentas de EE. UU., desactivado de forma predeterminada en la UE, el Reino Unido y Canadá. Dos organizaciones con planes idénticos de Dropbox pueden tener posturas opuestas y nunca enterarse.
- GitHub traza la línea según el plan: los datos de clientes de Business y Enterprise quedan contractualmente excluidos del entrenamiento de modelos, mientras que los niveles inferiores están cubiertos por términos de producto más amplios. La misma organización puede migrar de nivel y cambiar silenciosamente su postura.
- Salesforce, Zendesk e Intercom tienen cada uno sus propios valores predeterminados y sus propias rutas de exclusión: una página de Configuración, un ticket de soporte, un ajuste del espacio de trabajo.
- Google Workspace, Microsoft 365, Notion y Box se sitúan en el lado opuesto: sus términos comprometen contractualmente que el contenido de los clientes no se utiliza para entrenar modelos, por lo que no hay interruptor porque no se necesita ninguno. Esa es una postura genuinamente distinta, pero aun así necesita conocerla y poder señalársela a un auditor.
Observe lo que tienen en común todos estos casos: ninguno de ellos expone una API que se pueda consultar para preguntar «¿está mi organización contribuyendo datos de entrenamiento en este momento?». La postura reside en contratos, en correos electrónicos, en valores predeterminados regionales, en niveles de plan. Es real, tiene consecuencias, y es invisible para cualquier panel de control que revise su equipo de seguridad.
Por eso «alguien debería revisar esto» falla como control. No hay ningún lugar donde revisarlo. La decisión queda por defecto en lo que el proveedor haya elegido, y el proveedor eligió con sus propios incentivos.
Qué significa esto para el cumplimiento normativo
Si su organización posee un informe SOC 2, está trabajando hacia ISO 27001, o procesa datos personales bajo el RGPD, la cuestión de la contribución de datos no es una trivialidad opcional: aterriza directamente dentro de sus obligaciones existentes.
Los acuerdos de procesamiento de datos describen los fines para los que un procesador puede usar sus datos. Un proveedor que entrena modelos de IA con su contenido constituye un *fin*. Si su DPA con un cliente indica que sus datos se usan para prestar el servicio, y una de sus plataformas conectadas está alimentando silenciosamente esos mismos datos al entrenamiento de modelos, la brecha entre lo que prometió aguas abajo y lo que permite aguas arriba es suya que cerrar, no del proveedor.
Los auditores han empezado a preguntar sobre esto directamente. La pregunta aparece en los cuestionarios de riesgo de proveedores en alguna variante de «¿alguno de sus subprocesadores utiliza sus datos para entrenar modelos de IA, y cómo lo sabe?». Una respuesta defendible tiene dos partes: la *postura* (qué plataformas contribuyen, cuáles están contractualmente excluidas) y el *registro de la decisión* (quién la revisó, cuándo y qué eligió). «Nunca lo revisamos» es la única respuesta incorrecta. Tratamos lo que los auditores exigen actualmente en materia de gobernanza de IA de forma más amplia en qué exigen realmente los auditores sobre gobernanza de IA en 2026; la contribución de datos se está convirtiendo en una línea estándar de esa misma revisión.
La buena noticia: este es uno de esos raros elementos de cumplimiento en los que la solución es genuinamente económica. No hace falta rediseñar nada. Necesita *encontrar* los ajustes, *decidir* con intención y *dejar constancia por escrito* de la decisión.
Una lista de verificación para administradores antes del 17 de agosto
Esta es la revisión concreta que debe hacer antes del plazo de Atlassian, generalizada para que pueda aplicarla a cada plataforma que opere:
- Haga un inventario de la superficie. Enumere las plataformas SaaS donde realmente reside el contenido o los metadatos de su organización, no solo Atlassian. Si contiene datos de clientes, datos regulados o cualquier cosa bajo un NDA, está dentro del alcance.
- Averigüe la postura de contribución de datos de cada plataforma. Para Atlassian: Administration → Security → Data contribution. Para otras, el control puede ser una página de ajustes, un ticket de soporte, una exclusión por correo electrónico, o una cláusula contractual sin ningún control en absoluto.
- Confirme su nivel de plan en cada plataforma donde la postura dependa del nivel. En Atlassian, el plan más alto activo de su organización establece los valores predeterminados para todo lo que hay dentro de ella. En GitHub, el nivel decide si la exclusión contractual le cubre.
- Decida con intención. Aceptar la contribución es una elección legítima: mejores funciones de IA son un beneficio real. El modo de fallo no es la contribución en sí; es la contribución que *nadie decidió*. Excluya los proyectos y espacios que contengan material sensible, y deje que el resto siga su curso si esa es su decisión.
- Registre la decisión. Una nota con fecha —quién la revisó, qué se configuró, por qué— convierte un valor predeterminado silencioso en evidencia de gobernanza que puede entregar a un auditor.
- Vuelva a revisarlo periódicamente. Los proveedores cambian los valores predeterminados, añaden funciones de IA y mueven los ajustes de lugar. Una postura revisada una sola vez en 2026 no es una postura gestionada en 2027.
Si esta lista parece un trabajo que alguien tiene que asumir, es porque lo es. La versión honesta de este problema es que es *recurrente, multiplataforma y tedioso*, que es exactamente el tipo de control que se degrada silenciosamente cuando depende de que un humano lo recuerde.
Cómo 8200.dev pone esto de manifiesto automáticamente
8200.dev ahora genera un hallazgo de postura de entrenamiento de IA para cada plataforma que conecte. Conecte Jira, Slack, Dropbox, GitHub, Salesforce o cualquiera de las demás plataformas admitidas, y el análisis le indica —junto a sus hallazgos de compartición y permisos— si ese proveedor utiliza sus datos para el entrenamiento de IA de forma predeterminada, dónde reside la exclusión o la garantía contractual, y cuándo se verificó por última vez esa postura. Las plataformas con contribución activada por defecto aparecen como hallazgos que exigen una decisión; las plataformas contractualmente seguras aparecen como certificaciones que puede mostrar a los auditores.
Cuando una plataforma *sí* expone una política de IA legible por API en un eje relacionado, la comprobamos en vivo: el conector de GitHub lee la política de coincidencia de código público de Copilot de su organización, y el conector de GCP comprueba si Vertex AI se está ejecutando sin ninguna política de organización que lo restrinja. Cada hallazgo incluye un plan de remediación paso a paso, y el catálogo completo de comprobaciones está en la página de funciones.
El punto no es que las funciones de IA sean peligrosas. El punto es que *la contribución de datos debería ser una decisión, no un valor predeterminado*: en Atlassian antes del 17 de agosto, y en cada otra plataforma que su organización ya utiliza. Si quiere que esa decisión se ponga de manifiesto automáticamente en lugar de tener que recordarla manualmente, consulte planes y precios y conecte su primera plataforma en minutos.
Artículos relacionados
- La opción de exclusión de IA que no existe: lo que descubrimos al revisar 17 plataformas SaaS
Revisamos las 17 plataformas de la biblioteca de conectores de 8200.dev para ver quién entrena IA con su contenido por defecto, y dónde vive realmente cada opción de exclusión.
- Vea cada herramienta de IA que toca su organización — autorizada o en la sombra
Presentamos AI Governance en 8200.dev: un panel único para shadow AI, plataformas agénticas como Manus, postura de entrenamiento de proveedores e higiene de claves.
- Lo que el incidente entre OpenAI y Hugging Face realmente significa para las empresas
Modelos de OpenAI escaparon de un entorno de pruebas aislado y alcanzaron sistemas de producción de Hugging Face. Qué pasó, qué no, y qué implica para sus agentes de IA.