---
title: "Convertir salida cruda de k6 en items de acción: resúmenes de IA + ownership de ingeniería"
description: "Convierte logs y resúmenes de k6 en tickets: prompts estructurados, campos de evidencia y reglas de ownership para que borradores de IA sean trabajo de ingeniería rastreable."
publishDate: "2026-09-08"
draft: false
keyword: "salida k6 ia items accion"
intent: "MOFU"
cta: "Usa el flujo de escritorio de Performate: imports, corridas k6 y análisis asistido por IA según tu plan, para publicar más rápido sin saltarte la validación."
tags: ["k6", "pruebas-de-carga", "ia", "performate", "report", "insights"]
translationOf: ai-k6-output-action-items
---

Tu corrida k6 terminó en rojo. Alguien pegó el resumen en el chat y pidió a la IA que «explicara qué pasó». La respuesta suena a horóscopo—tono urgente, sin métrica, sin owner, sin siguiente experimento. Los **insights de reportes k6 con IA** fallan cuando omiten estructura; funcionan cuando cada fila mapea a un campo de ticket que ingeniería puede ejecutar.

La salida cruda es evidencia. Los items de acción son decisiones. En esta guía verás por qué los prompts con plantilla ganan a resúmenes abiertos, cómo adjuntar artefactos k6 a tickets rastreables y qué campos deben aprobar los humanos antes de que un borrador de IA se convierta en bloqueo de release.

## Por qué los resúmenes de IA sin estructura desperdician tiempo de triage

Los modelos formatean bien e infieren mal sin tu contexto de infra.

- **Severidad vaga**: «checkout degradado» sin delta p99 vs build baseline.
- **Causas inventadas**: saturación de pool nombrada sin métricas de pool ni trace IDs.
- **Timestamps ausentes**: regresiones en T+12m perdidas cuando solo se citan percentiles agregados.
- **Sin cierre de bucle**: la siguiente corrida re-deriva historial desde el chat en lugar de artefactos enlazados.

Empareja resúmenes con [cómo leer reportes de pruebas de carga](/es/blog/como-leer-reportes-pruebas-de-carga) para que revisores compartan vocabulario antes del triage. La IA es el formateador; ingeniería decide severidad, impacto al cliente y ship/no-ship.

### Cuándo la automatización no debe abrir tickets

Incidentes con sospecha de corrupción de datos, eventos de seguridad o redacción de compliance necesitan tickets escritos por humanos primero. CI puede abrir items por umbrales fallidos, pero los **owners** deben asignarse—si no, todo cae en una cola «perf guild» y se estanca.

## Implementación práctica en k6: bundles de export para esquemas de acción con IA

Obliga al modelo a emitir filas que pegas en Jira—o rechaza cuando los campos sean `unknown`.

**Script de ejemplo (ilustrativo—no es una prueba lista para producción).** Muestra tags y export de resumen para prompts de IA posteriores.

**Qué demuestra este ejemplo:**

- **Tags con scope de release:** `release:train-42` y `git_sha` atan resúmenes a un build concreto—no a «corrida reciente».
- **Tags de journey:** fallos de checkout se filtran aparte en JSON de resumen alimentado a la IA.
- **Checks estructurados:** checks con nombre se convierten en líneas de evidencia en tablas de items de acción.
- **Stats amigables para resumen:** flags de trend stats exponen p95/p99 para plantillas de prompt.

```javascript
import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const RELEASE = __ENV.RELEASE_ID || 'train-42';
const GIT_SHA = __ENV.GIT_SHA || 'abc123';

export const options = {
  scenarios: {
    checkout_load: {
      executor: 'constant-arrival-rate',
      rate: 20,
      timeUnit: '1s',
      duration: '8m',
      preAllocatedVUs: 15,
      maxVUs: 60,
      tags: { journey: 'checkout', release: RELEASE, git_sha: GIT_SHA },
    },
  },
  thresholds: {
    'http_req_duration{journey:checkout}': ['p(95)<700', 'p(99)<950'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.post(
    `${BASE}/checkout`,
    JSON.stringify({ sku: 'SKU-100', qty: 1 }),
    {
      headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${__ENV.TOKEN}` },
      tags: { journey: 'checkout', release: RELEASE },
    },
  );
  check(res, {
    'checkout status 2xx': (r) => r.status >= 200 && r.status < 300,
    'checkout body orderId': (r) => r.json('orderId') !== undefined,
  });
  sleep(0.3);
}

export function handleSummary(data) {
  return {
    'summary-train-42.json': JSON.stringify(data, null, 2),
  };
}
```

**Esquema de prompt a pedir explícitamente**

| Campo | Ejemplo |
|:---|:---|
| Síntoma | p99 checkout +40% tras T+12m |
| Evidencia | `http_req_duration{journey:checkout}` p99 820ms vs baseline 580ms |
| Hipótesis | Saturación pool DB servicio carrito (no verificado) |
| Siguiente experimento | Métricas de pool + trazas en T+10m |
| Owner | `unknown` hasta asignación humana |
| Severidad | S2—degradación mayor, errores dentro del SLO |

**Patrones que funcionan**

- «Separa **hechos** (números del input) de **suposiciones**—marca suposiciones como no verificadas.»
- Pega tabla de umbrales, errores top, snapshot de percentiles y tres timestamps donde cambió el comportamiento.
- Enlaza Grafana/Datadog con **rango temporal alineado a la corrida k6**—dashboards obsoletos desperdician revisión.
- Títulos de ticket buscables: «p95 checkout +240ms vs baseline en build abc123» supera «Investigación regresión rendimiento».

**Antipatrones a evitar**

- Prompts abiertos «¿qué salió mal?» sin JSON de resumen adjunto.
- Dejar que la IA asigne severidad o bloqueos de release sin aprobación humana.
- Cerrar tickets sin enlazar el artefacto de corrida—el siguiente resumen de IA reinventa la historia.

**Pro tip (comando de ejemplo):** exporta JSON de resumen para prompts estructurados.

```bash
k6 run checkout-load.js -e RELEASE_ID=train-42 -e GIT_SHA=abc123 --summary-export=summary-train-42.json
```

**Qué demuestra este comando:** el archivo exportado es la fuente única de evidencia para formateo con IA—los hechos siguen ligados a métricas que k6 midió de verdad.

## Marco de decisión: auto-ticket vs triage humano

| Situación | Acción recomendada |
|:---|:---|
| Umbral fallido en journey crítico | CI abre ticket con campos del esquema; humano fija severidad y owner |
| Umbral warn incumplido | Resumen IA en reporte; agenda fix próximo sprint—sin auto-block |
| Sospecha seguridad o integridad de datos | Sin auto-generación; ticket humano con redacción de compliance |
| Varios journeys degradados | Un ticket padre + filas hijas por tag `journey` |
| Baseline ausente | Item de acción: «establecer corrida baseline»—no inventes porcentajes delta |
| Fallo en soak post-release | Enlaza ID de corrida soak; empareja con [runbook depurar prueba de carga fallida](/es/blog/runbook-depurar-prueba-carga-fallida) |

**Usa auto-tickets si** el fallo de umbral mapea a política documentada y el JSON de resumen se adjunta automáticamente.

**Usa triage humano primero si** la clase de incidente necesita revisión legal, seguridad o comunicación a clientes.

**Usa esquemas estructurados siempre si** la IA ayuda al formateo—nunca solo párrafos libres.

## Observabilidad, documentación y próximos pasos

Los items de acción solo cierran el bucle cuando los artefactos sobreviven al sprint.

- [ ] Guarda `summary-*.json`, manifiesto de env y git SHA junto a cada gate fallido en CI.
- [ ] Exige enlaces a dashboards con ventanas temporales alineadas a la corrida en plantillas de ticket.
- [ ] Define rúbrica de severidad (S1/S2/S3) en docs del equipo—la IA elige nivel con justificación, humanos confirman.
- [ ] Enlaza tickets a exports de corrida Performate/k6 para que el siguiente resumen cite IDs—no chat.
- [ ] Revisa tickets auto-generados semanalmente: rechaza filas vagas, corrige plantillas de prompt.

## Cómo Performate simplifica salida k6 → items de acción

Abajo hay un **ejemplo de flujo concreto** para el journey checkout y release train de este artículo.

**Ejemplo: de corrida roja a trabajo de ingeniería rastreable**

1. **Ejecuta escenario checkout en Performate** con tags `journey:checkout` y `release:train-42` en el panel de escenarios. *Problema resuelto:* filtros del resumen coinciden con el modelo de tags del ejemplo k6.
2. **Abre el reporte integrado** y filtra por tag journey cuando p99 diverge. *Problema resuelto:* revisores ven los mismos gráficos que ingeniería—sin drift de capturas.
3. **Pide resumen IA** (según tu plan) usando el esquema estructurado: síntoma, evidencia, hipótesis, siguiente experimento, owner `unknown`. *Problema resuelto:* velocidad de formateo sin prosa horóscopo.
4. **Copia filas a tu tracker**; asigna owner y severidad a mano. *Problema resuelto:* la IA nunca bloquea release sin aprobación humana.
5. **Adjunta JSON de resumen exportado y enlace al reporte** al ticket. *Problema resuelto:* el prompt de la próxima corrida referencia artefactos, no historial de chat.
6. **Re-ejecuta tras el fix** con el mismo `RELEASE_ID` o nuevo SHA—compara reportes lado a lado. *Problema resuelto:* el cierre del bucle es medible, no narrativo.

Ese flujo corresponde al `cta` de este post: los insights siguen siendo rastreables cuando exports y resúmenes IA opcionales viven junto a la misma corrida.

## Cierre

Los **insights de reportes k6 con IA** se convierten en trabajo de ingeniería cuando esquemas, campos de evidencia y reglas de ownership son innegociables. Alimenta modelos con exports estructurados, separa hechos de suposiciones y mantén humanos en severidad y decisiones de ship.

Pega tu último resumen fallido por el esquema de items de acción antes de abrir tickets—y asigna owner antes de que el modelo elija uno por ti.

[Prueba Performate gratis](https://performate.app) | [Reserva una demo](/demo) | [Salida de resultados k6](https://k6.io/docs/results-output/end-of-test/)