Evolución hacia soluciones operacionales con IA Generativa

De la generación de contenido al componente operacional

La IA generativa se masificó primero como una capacidad avanzada de lenguaje: redactar, resumir, traducir y asistir en programación. En este contexto, el LLM (modelo de lenguaje) es el componente específico de la IA generativa encargado de producir y transformar texto (incluido código), pero su alcance queda limitado si no puede operar sobre el entorno real. El salto relevante ocurre cuando el LLM deja de ser solo “un generador” y pasa a ser un componente operacional dentro del flujo de QA, capaz de leer contexto vigente, proponer cambios, ejecutar acciones y verificar resultados de forma controlada.

En una hipotética solución orientada al mundo QA, este cambio se traduce en pasar de “generar casos de prueba” a generar + mantener + ejecutar + evidenciar pruebas en integración con el ecosistema habitual: repositorios (GitHub/GitLab/Bitbucket), gestión de pruebas (Xray/Zephyr), Gatilladores (Jenkins/GitHub Actions), y fuentes de requisitos (Confluence/Jira).

Herramientas: Ejecutar acciones sobre sistemas reales (sin perder control)

El primer requisitito  para que este componente  IA pueda transformarse en un proceso como tal, es permitir/habilitar integración con herramientas y artefactos que conecten con el entorno. Ya no basta con describir/proponer las acciones a realizar, ahora se trata de poder ejecutar dichas acciones de manera confiable y controlada mediante el uso de conectores seguros y auditables.   En el caso de QA poder integrarse con los siguientes componentes:

• Código (GitHub / Bitbucket / GitLab): leer cambios (Diff), analizar Pull Request, crear ramas, proponer commits, actualizar archivos de pruebas (BDD/Gherkin, Playwright, Selenium, Postman, etc.).
• Requisitos (Confluence / Jira): leer historias de usuario, criterios de aceptación, definiciones de listo (DoD), riesgos; proponer aclaraciones; generar trazabilidad HU ↔ pruebas.
• Gestión de Pruebas (Xray / Zephyr): crear/actualizar casos, planes de prueba, ejecuciones, evidencias, cobertura por requisito, y reportes.
• CI/CD (Jenkins / GitHub Actions): gatillar pipelines, parametrizar ejecuciones, recuperar logs y artefactos, clasificar fallas y abrir issues/tickets.
• Ambientes y artefactos: consultar resultados (JUnit/Allure), logs, métricas de ejecución, y evidencias.

En este esquema, el LLM actúa como motor de orquestación y decisión, mientras la ejecución efectiva se delega en componentes especializados.

RAG: Toma de decisiones basadas en evidencia vigente

Un segundo requisito clave es mover la decisión desde el conocimiento paramétrico del modelo (LLM) hacia evidencia verificable del estado actual del entorno. Con RAG (Retrieval-Augmented Generation), el LLM se alimenta de contexto recuperado desde fuentes controladas (documentación, código, logs, políticas y resultados de ejecución) para generar y decidir.

En el caso de una solución para QA, el riesgo no es que la IA se equivoque en su razonamiento, sino que genere pruebas que no reflejan el sistema en su estado real y actual.    Por eso, la solución a implementar necesariamente debe incorporar un enfoque RAG, donde la Solución IA genera y decide usando contexto recuperado y verificable desde fuentes controladas, por ejemplo:

• Historias y criterios de aceptación (Confluence/Jira)
• Código y contratos (OpenAPI/Swagger, schemas, feature flags)
• Estándares internos (DoR/DoD, Convenciones, Patrones de automatización)
• Casos de Prueba y trazabilidad existente en Xray/Zephyr
• Resultados de ejecuciones (logs, reportes, fallas recurrentes)
• Código de Automatización en GitHub/Bitbucket

AGENTES: Ciclo de trabajo iterativo y verificable

Cuando un LLM dispone de los elementos necesarios para ejecutar acciones sobre sistemas reales y de evidencia para decidir con información de entorno vigente, es natural implementarlo bajo el patrón de agente. Un agente no es una herramienta adicional ni un modelo “más inteligente”, sino una forma de integrar el LLM dentro de un ciclo de trabajo con un objetivo y especialización especifico. En este esquema, el LLM opera con acceso a un conjunto acotado y específico de herramientas y puede iterar (planificar → ejecutar → validar → corregir → reintentar).

En una hipotética plataforma de QA, un agente puede ejecutar un flujo tipo:

1. Entender el cambio: Leer HU en Confluence/Jira + Pull Request/Diff en GitHub.
2. Proponer cobertura: Mapear criterios de aceptación → escenarios Gherkin / casos Xray/Zephyr.
3. Generar automatización: Crear/actualizar tests (API/UI/BDD) alineados a estándares del repo.
4. Ejecutar: Disparar Jenkins/GitHub Actions con la suite adecuada.
5. Validar: Interpretar reportes, adjuntar evidencias, clasificar fallas (test vs bug vs ambiente).
6. Cerrar trazabilidad: Actualizar Xray/Zephyr (ejecución + evidencia) y comentar en la HU/PR.

Este enfoque necesariamente requiere de controles operacionales tales como: permisos, políticas, trazabilidad y según criticidad e impacto, revisión y aprobación humana en puntos específicos del flujo ((por ejemplo, antes de mergear o antes de crear/modificar artefactos “oficiales” en Xray).

MCP e Integración: Estandarizar el acceso a herramientas y reducir acoplamiento

Para que la solución sea confiable, mantenible y escalable, la integración debe abordarse en dos niveles. El primero es la integración agente ↔ herramientas (repositorios, CI/CD, Confluence/Jira, Xray): A medida que crecen los sistemas involucrados y evolucionan sus APIs, una integración ad-hoc por cada agente se vuelve un problema estructural, porque incrementa el acoplamiento y encarece la mantención.

El segundo nivel es la integración de la plataforma con los agentes: Cómo se incorporan uno o varios agentes a la solución, cómo se exponen a distintos clientes (Bot, Servicios internos) y cómo se estandarizan aspectos operacionales como configuración, permisos, trazabilidad y despliegue.

En este esquema, MCP (Model Context Protocol) aplica principalmente al primer nivel: estandariza cómo se exponen herramientas y recursos a procesos y agentes mediante un contrato común. MCP no agrega “inteligencia” al LLM; reduce la complejidad de la integración y permite que múltiples agentes consuman las mismas capacidades sin implementar conectores específicos para cada API. Así, cambiar un backend (por ejemplo, Jenkins vs GitHub Actions) o integrar una nueva herramienta suele resolverse agregando o ajustando el servidor MCP correspondiente, sin reescribir la lógica del agente.

Componentes productivos: Evaluación, Observabilidad y Gobernanza

Finalmente, como en cualquier plataforma productiva, para que esto sea operable en entornos corporativos, la Solución IA debe funcionar como cualquier plataforma crítica:

• Evaluación automática, que comprueba que lo generado y ejecutado sea correcto y cumpla estándares y criterios definidos.
• Observabilidad, que permite ver qué está ocurriendo; trazas de acciones del agente, auditoría de cambios, métricas de éxito, latencia, costos, tasa de reintentos, y degradaciones.
• Gobernanza, considera los controles necesarios para que el sistema sea seguro y controlable (control de acceso, segregación de funciones/roles, auditoría y aprobaciones).

La evolución efectiva de la IA generativa no se explica o sustenta solo por modelos más grandes e “inteligentes”, sino por la estructuración y consolidación de una arquitectura de componentes que transforma una capacidad lingüística en una capacidad operacional, efectiva, confiable, medible y gestionable.

Equipo I+D AKZIO

——————————————————————————————————————————————————

Glosario

IA Generativa: categoría de sistemas de IA diseñados para generar contenido como texto/código (LLM), imágenes, audio o video) a partir de una instrucción (prompt) y contexto. Sus salidas se producen combinando patrones y representaciones aprendidas durante el entrenamiento con la información entregada en la interacción.

LLM (Large Language Model / Modelo de Lenguaje): modelo entrenado para comprensión y generación de lenguaje (incluido código). En una solución actúa como motor de generación/razonamiento, pero no ejecuta acciones sobre sistemas externos por sí mismo; requiere herramientas e integraciones.

RAG (Retrieval-Augmented Generation): enfoque donde la solución recupera información vigente y verificable desde fuentes controladas (documentación, repositorios, registros, políticas, evidencias) y la incorpora como contexto al modelo para mejorar precisión y consistencia, reduciendo la dependencia del conocimiento paramétrico o pre-entrenado.

Agente (IA): Componente/patrón de arquitectura en el que la IA opera con un objetivo específico y un ciclo de control (planificar → actuar → validar → corregir), utilizando herramientas para ejecutar acciones y cerrando con resultados verificables. Su especialización se define principalmente por el dominio de tarea, el conjunto de herramientas disponibles, y sus políticas y criterios de validación; opcionalmente puede reforzarse con ajuste del modelo (fine-tuning) cuando se requiere mayor consistencia.

MCP (Model Context Protocol): protocolo/capa de integración que estandariza la exposición y consumo de herramientas y recursos por parte de modelos/agentes, con el fin de reducir acoplamiento, simplificar mantenimiento y habilitar reutilización de capacidades entre distintos clientes.