Por Ignacio Muñoz
La IA no arregla un Jira roto; solo amplifica lo que ya está pasando en tu instancia.
Escribí este blog con el objetivo de poner orden en una conversación que se está volviendo peligrosa: muchas organizaciones quieren “activar IA en Jira” sin hacerse primero la pregunta incómoda:
¿mi Jira está en condiciones de alimentar bien a esa IA?En la práctica, lo que vemos es que Jira suele crecer a punta de urgencias y buena voluntad, pero sin un estándar claro. Como resume Miguel Fuenzalida, líder de célula Banca, Logística y Salud en ACL, “cada cliente utiliza la plataforma bajo su campo de visión, sin tener en consideración las mejores prácticas”. El resultado: configuraciones obsoletas, workflows imposibles de mantener, permisos mal diseñados y formularios eternos donde, en la práctica, solo se usan entre 5 y 8 campos.
Y desde ahí aparecen las frases conocidas en cualquier comité o daily:
“Jira está muy lento.”
“Los QA no me dejan la evidencia en las historias, al final no sé si realmente hicieron la pega.”
“No se entienden las HU porque cada Product Owner las escribe de manera diferente, y las mueven en el flujo como quieren.”La idea central es simple: antes de hablar de IA en Jira, vale la pena hacerse cargo de algo menos glamoroso pero mucho más determinante: estandarizar y gobernar la herramienta para que los datos tengan sentido y la IA pueda jugar a favor, no en contra.
Qué está pasando realmente con Jira e IA
Jira dejó hace rato de ser “el tablero del equipo de TI”. Según la página corporativa de Atlassian, hoy soportan a 300.000+ clientes en más de 200 países, incluyendo a buena parte de las empresas Fortune 500. Es decir, Jira se ha transformado en el sistema donde se coordina el trabajo de TI, producto y operaciones en organizaciones de todos los tamaños.
En esa misma línea, DataArt se presenta como una firma global de ingeniería de software con foco fuerte en datos, analítica e IA aplicada a industrias reguladas, algo que se refleja en sus prácticas de Data & Analytics y en su experiencia en servicios financieros. Desde esa mirada, la discusión sobre Jira e IA no es solo de features, sino de arquitectura, calidad de datos y modelo operativo.
En paralelo, Atlassian está empujando fuerte sus capacidades de IA. En su documentación sobre Atlassian Intelligence features in Jira Software y en la guía general Understand Atlassian Intelligence features in products, la compañía describe funciones como:
- buscar issues usando lenguaje natural,
- crear reglas de automatización a partir de descripciones en texto,
- generar y transformar contenido (por ejemplo, descripciones de issues),
- resumir comentarios e historial de tickets.
El contexto externo también presiona. Según el informe The state of AI in 2024 de McKinsey, 65% de las organizaciones ya usa IA generativa de forma regular, casi el doble que diez meses antes. Y el estudio The state of AI: How organizations are rewiring to capture value destaca que prácticas como rediseñar workflows y asignar roles claros de gobernanza de IA correlacionan fuertemente con mayor impacto en EBIT.
Traducido al mundo Jira: el hype por la IA está creciendo, pero el valor real aparece cuando los procesos y sistemas donde vive la IA (como Jira) están bien diseñados.
El error de fondo: querer IA encima de un Jira fragmentado
Lo que vemos en terreno se repite en bancos, retail y servicios B2B:
- Cada equipo configuró Jira “a su pinta”, sin una visión global.
- Hay workflows con estados muy parecidos (“En espera”, “En proceso”, “En pausa”) usados de formas distintas según el equipo.
- Se acumulan campos personalizados que nadie se atreve a borrar, muchos sin uso real.
- Los formularios para crear issues tienen más de 20 campos, pero en la práctica todos llenan siempre los mismos 5–8.
- Los reportes se discuten en cada reunión: “estos números no calzan con lo que vemos en la realidad”.
En ese contexto, empiezan a aparecer ideas como usar IA para clasificar mejor los tickets, apoyarse en IA para priorizar lo más crítico o activar Atlassian Intelligence “y ver qué pasa”.
El problema es que ningún modelo puede resolver por sí solo estados mal definidos, campos redundantes y flujos que nadie respeta. La IA puede ayudar a leer, resumir, sugerir, pero no puede inventar gobernanza donde no la hay.
Lo más efectivo suele ser menos glamoroso y más honesto: Ordenar primero cómo funciona Jira, asegurar que los datos tienen sentido y recién ahí sacar provecho de la IA.
Qué significa realmente estandarizar y gobernar Jira
Cuando hablamos de estandarizar Jira, no se trata de quitarle flexibilidad a los equipos, sino de tomar decisiones claras en algunos puntos estructurales.
Workflows que reflejan procesos reales
- Definir workflows estándar por tipo de trabajo (desarrollo de producto, soporte, incidentes, cambios, proyectos internos).
- Eliminar estados redundantes y dejar solo aquellos que representen un cambio real en el proceso.
- Acordar qué implica cada estado y quién puede mover un issue entre etapas.
Un flujo con menos estados, pero bien definidos, entrega mucha más información que un diagrama gigante que nadie respeta.
Campos personalizados bajo control
- Levantar todos los campos personalizados que existen hoy.
- Identificar cuáles se usan de verdad y cuáles son relleno histórico.
- Unificar nombres y significados: que “Tipo de requerimiento” no tenga cinco variantes distintas según el proyecto.
Como plantea Miguel Fuenzalida, formularios con más de 20 campos donde solo se usan entre 5 y 8 no solo cansan a los usuarios, también enturbian cualquier análisis o modelo de IA.
Proyectos, permisos y visibilidad
- Definir tipos de proyectos estándar (producto, equipo, servicio, iniciativa).
- Alinear permisos para lograr equilibrio entre autonomía y control: ni todo abierto para todos, ni cajas negras.
- Asegurar que los líderes puedan ver el portafolio completo sin armar Excel a mano.
Reporting que sí se puede creer
Una de las grandes ventajas de Jira es JQL, su lenguaje de consultas. En la documentación de Atlassian sobre Atlassian Intelligence features in Jira Software y en guías de partners se muestra cómo, a partir de consultas bien diseñadas, se pueden construir tableros que filtran por tipo de trabajo, estado, prioridad o equipo, respondiendo preguntas muy específicas.
Eso solo tiene sentido cuando los datos están ordenados. Si cada equipo usa estados y campos de manera distinta, el gráfico puede verse bonito, pero sostiene decisiones frágiles.
Un rol responsable de la salud de Jira
“El ideal sería contar con un administrador que regule, controle y otorgue los ajustes cuando sea necesario a través de la estandarización, manejo de costes y optimización constante de flujos”, plantea Fuenzalida.
Ese rol —interno o apoyado por un partner— es la diferencia entre un Jira que entra en modo “selva” y uno que evoluciona con criterio.
Dónde entra la IA (y dónde no)
Hoy Jira puede apoyarse en IA para:
- buscar issues en lenguaje natural,
- generar o mejorar descripciones,
- resumir comentarios extensos,
- ayudar a escribir reglas o automatizaciones,
- encontrar similitudes entre tickets o sugerir enlaces automáticos.
Estas capacidades están documentadas tanto en Atlassian Intelligence features in Jira Software como en la guía de Tsoft Guide to Atlassian Intelligence and Jira Service Management.
Bien usada, la IA puede:
- acelerar la triage,
- reducir tiempo de lectura,
- mejorar coherencia en la forma de documentar,
- ayudar a automatizar pasos repetitivos.
Pero todo esto comparte un requisito que rara vez se dice en grande:
“Los modelos de IA y cualquier tipo de funcionalidad asociada a la IA en Jira necesitan de datos coherentes para ofrecer valor. Dale basura a la IA y te entregará basura; dale datos de valor y te entregará resultados de alto impacto", asegura Miguel Fuenzalida líder de célula Banca, Logística y Salud en ACL.
Es decir, si tu Jira está desordenado, la IA va a aprender ese desorden y a trabajar con él.
Por eso, la pregunta no es “¿activamos IA o no?”, sino:
“¿Nuestra instancia de Jira está lo suficientemente ordenada como para que la IA genere valor y no solo más ruido?”
Antes y después típico: de Jira caótico a plataforma lista para IA
Un escenario que se repite:
Antes
- Múltiples workflows para trabajos similares.
- Campos duplicados y poco usados.
- Formularios exagerados que nadie llena bien.
- Reportes que no calzan con la percepción de los equipos.
- Discusiones eternas sobre “qué significa cada estado”.
Después de ordenar
- Menos workflows, alineados con procesos reales.
- Campos consolidados y con uso explícito.
- Formularios ajustados a lo que de verdad se ocupa.
- Reportes que responden preguntas concretas:
- ¿Dónde se atascó el flujo este mes?
- ¿Qué tipo de incidentes consumen más capacidad?
- ¿Qué compromisos se están cumpliendo y cuáles no?
Con esa base, recién tiene sentido probar IA para priorizar tickets, sugerir categorizaciones, resumir conversaciones o ayudar a escribir HU más claras.
La diferencia no es solo tecnológica; es de calidad de decisiones.
Cómo saber si tu Jira está listo para IA
Si estás en un rol ejecutivo (TI, transformación, producto, operaciones), un marco simple para ordenar la conversación es este:
Diagnóstico honesto
- ¿Cuántos workflows distintos tenemos hoy y cuántos necesitamos realmente?
- ¿Cuántos campos personalizados existen y cuáles están en uso real?
- ¿Confiamos en los reportes de Jira como base de decisiones, o siempre hay un “pero”?
Definir un estándar y una gobernanza mínima
- Acordar un set de workflows oficiales.
- Definir qué campos son obligatorios, cuáles opcionales y cuáles se van.
- Establecer quién aprueba cambios estructurales (flujos, campos, tipos de proyecto, automatizaciones).
No se trata de montar una “policía de Jira”, sino de cuidar la calidad del dato que después queremos explotar con IA.
Ordenar por etapas, no en modo “big bang”
- Partir por una unidad de negocio o dominio crítico.
- Ajustar ahí workflows, campos y reporting.
- Validar que la visibilidad y la operación mejoran.
- Luego extender el modelo al resto.
Elegir bien los primeros casos de IA
Con la base ordenada, la IA tiene más sentido en casos como:
- priorización de tickets,
- sugerencias de categorización,
- resúmenes de issues muy comentados,
- apoyo para redactar historias más claras.
No es partir por la feature más vistosa, sino por aquellas que refuercen el estándar que definiste.
IA como acelerador (y un siguiente paso concreto)
La IA va a seguir avanzando en Jira y en todo el ecosistema Atlassian. Un buen ejemplo es el anuncio conjunto Atlassian and Google Cloud Partner to Bring AI-Powered Productivity to Millions of Users Worldwide, donde se refuerza la idea de una nube Atlassian preparada para IA y agentes como Rovo integrados en el día a día.
La pregunta no es si vas a usar esas capacidades, sino en qué condiciones las va a encontrar tu organización.
Desde ACL powered by DataArt, lo que vemos en terreno es claro:
- Cuando Jira está ordenado y gobernado, la IA se convierte en un acelerador real.
- Cuando Jira es un mosaico de configuraciones, la IA tiende a amplificar la confusión.
Si al leer esto reconoces tu realidad —workflows duplicados, campos infinitos, reportes discutidos en cada reunión— el siguiente paso razonable no es “activar IA y ver qué pasa”, sino mirar tu instancia con lupa.
En ACL acompañamos a organizaciones que ya usan Jira a:
- diagnosticar el estado real de su instancia,
- diseñar un estándar viable de workflows, campos y reporting,
- y definir dónde tiene sentido aplicar IA para generar valor medible.
Si quieres explorar cómo se vería un assessment de salud de Jira y preparación para IA en tu organización, conversemos. Muchas veces, el primer avance no es un gran proyecto, sino una revisión honesta del Jira que ya concentra gran parte de tu operación.
.webp)
