← Todos los articulos

Los paquetes de revisión de agentes de IA son la nueva respuesta final

La publicación de lanzamiento de Codex de OpenAI dice que Codex ofrece evidencia verificable mediante citas de registros de terminal y resultados de pruebas, de modo que los usuarios puedan seguir los pasos realizados durante la finalización de una tarea.1 Esa frase nombra el cambio de producto. La respuesta final ya no alcanza.

Los paquetes de revisión son la nueva respuesta final para el trabajo de agentes. Un agente serio debería terminar con un conjunto estructurado de afirmaciones, trazas, aprobaciones, diferencias, pruebas, verificaciones de fuentes, evidencia de despliegue y brechas sin resolver. La prosa fluida puede resumir el trabajo. El paquete es lo que genera confianza.

Resumen rápido

El trabajo de agentes ahora abarca planificación, llamadas a herramientas, ediciones de archivos, aprobaciones, pruebas, rutas en vivo, traducciones y visto bueno humano. La documentación de Codex cloud de OpenAI describe tareas en segundo plano dentro de entornos aislados en la nube, mientras que Agents SDK expone trazas de generaciones del modelo, llamadas a herramientas, traspasos, barreras de control y eventos personalizados.23 La documentación de OpenAI sobre intervención humana pausa la ejecución para tomar decisiones de aprobación, y los hooks de Claude Code de Anthropic exponen eventos del ciclo de vida como PreToolUse, PostToolUse, PermissionRequest y Stop.45

Todas esas piezas apuntan al mismo artefacto: un paquete de revisión. El paquete convierte la afirmación final de un agente en algo que una persona puede inspeccionar, rechazar, aprobar o entregar a otro revisor.

Ideas clave

Para quienes construyen agentes: - Trata la respuesta final como la portada. El paquete de revisión debe contener la evidencia. - Vincula cada afirmación importante con un archivo, salida de comando, evento de traza, fuente, verificación de ruta, decisión de aprobación o brecha sin resolver.

Para diseñadores de producto: - Diseña el paquete como un objeto fácil de revisar, no como una exportación de la transcripción. Agrupa la evidencia según la decisión que debe tomar el usuario. - Incluye el estado de revisión humana en el paquete. “Verificado por máquina” y “aprobado por una persona” son estados distintos.

Para equipos que adoptan agentes: - Exige paquetes de revisión para lanzamientos públicos, cambios en producción, trabajos de traducción, cambios sensibles para la seguridad y trabajos con impacto económico. - No aceptes un “listo” si el paquete no nombra lo que sigue sin verificar.

¿Qué es un paquete de revisión de agentes de IA?

Un paquete de revisión es un conjunto estructurado de evidencia para el trabajo de agentes.

Responde 7 preguntas:

Pregunta Campo del paquete
¿Qué pidió el usuario? Objetivo y alcance
¿Qué cambió el agente? Archivos, diferencias, artefactos, estado externo
¿Qué ejecutó el agente? Comandos, llamadas a herramientas, argumentos, estados de salida
¿Qué aprobó una persona? Decisiones de aprobación y notas de riesgo
¿Qué prueba el resultado? Pruebas, verificaciones de fuentes, rutas renderizadas, telemetría, capturas de pantalla
¿Qué todavía requiere criterio? Tareas de revisión, matriz de visto bueno, afirmaciones sin resolver
¿Qué debería pasar después? Fusionar, publicar, rechazar, reintentar o escalar

El paquete puede vivir como Markdown, JSON, una fila de base de datos, una plantilla de pull request o un objeto dedicado de UI. El formato importa menos que la estructura. El objeto debe separar la evidencia de la narración.

Una respuesta final dice: “Traduje el artículo y lo desplegué”. Un paquete de revisión dice qué configuraciones regionales cambiaron, qué control de calidad pasó, qué filas de D1 existen, qué commit se desplegó, qué purga de CDN se ejecutó, qué rutas en vivo devolvieron el artículo modificado y qué revisiones de hablantes nativos siguen pendientes. La segunda versión le da a la persona una superficie real para decidir.

¿Por qué dejaron de funcionar las respuestas finales?

Las respuestas finales dejaron de funcionar porque los agentes ahora actúan a lo largo del tiempo.

Una respuesta de chatbot puede evaluarse en la propia respuesta. Un agente de código o publicación produce un recorrido: lee archivos, selecciona fuentes, llama herramientas, edita contenido, ejecuta pruebas, escribe traducciones, despliega, purga caché y verifica producción. El párrafo final solo describe ese recorrido. No prueba que el recorrido haya ocurrido.

La documentación de Codex de OpenAI describe tareas en la nube que pueden leer, editar y ejecutar código en entornos aislados en la nube, incluidas muchas tareas en segundo plano en paralelo.2 El trabajo paralelo en segundo plano amplía la distancia entre lo que ocurrió y lo que cabe en la respuesta final. Cuanto más hace el agente, menos merece el resumen de la transcripción ser el objeto de prueba.

La publicación de OpenAI sobre cómo ejecutar Codex de forma segura plantea el mismo punto operativo desde el ángulo de la seguridad. Describe controles de aislamiento, aprobaciones, políticas de red, identidad, configuración administrada y telemetría nativa para agentes; también menciona la exportación de registros para eventos como prompts, decisiones de aprobación, resultados de ejecución de herramientas, uso de MCP y eventos de permiso o denegación de red.6 Esos son ingredientes del paquete. Pertenecen a la superficie de revisión.

La respuesta final debería seguir existiendo. Debería leerse como un resumen ejecutivo. El paquete de revisión debería contener el rastro de auditoría.

¿Qué debe incluir el paquete?

El paquete debería agrupar la evidencia por decisión, no por el orden interno de los eventos.

Sección Evidencia mínima
Objetivo Solicitud del usuario, criterios de aceptación, exclusiones de alcance
Resumen del trabajo Archivos modificados, artefactos generados, estado externo afectado
Traza Llamadas relevantes a herramientas, salidas de comandos, fallos, reintentos
Aprobación Acciones riesgosas, decisiones de aprobación, denegaciones, aplazamientos
Verificación Pruebas, verificaciones de fuentes, rutas renderizadas, verificaciones de esquema, capturas de pantalla
Lanzamiento Commit, estado de despliegue, purga de caché, marcadores de cambio en vivo
Revisión Estado de visto bueno humano, estado de revisión nativa, brechas sin resolver

Esa estructura mantiene legible el paquete. Una traza sin procesar puede contener cientos de eventos. Un paquete de revisión no debería volcarlos todos en el flujo principal. El paquete debe enlazar o expandirse hacia la traza completa cuando haga falta, pero mantener la vista predeterminada enfocada en las decisiones.

El estándar de evidencia cambia según el dominio:

Tipo de trabajo El paquete debe probar
Cambio de código Diferencia, pruebas, código que llama afectado, ruta de reversión
Artículo público Fuentes, alineación entre afirmaciones y fuentes, metadatos, esquema, ruta en vivo
Traducción Caché de configuración regional, control de calidad, fila de D1, ruta en vivo, estado de revisión nativa
Trabajo de seguridad Amenaza, mitigación, prueba, riesgo residual, registro de aprobación
Despliegue a producción Commit, estado de despliegue, vigencia de caché, marcador de cambio en vivo

La regla se mantiene: si una persona tiene que dar su visto bueno al trabajo, el paquete debe contener la evidencia que hace responsable esa firma.

¿Cómo alimentan el paquete las trazas y las aprobaciones?

Las trazas y las aprobaciones aportan la columna vertebral del paquete.

La documentación de trazas de Agents SDK de OpenAI define trazas y spans alrededor de una ejecución de agente, incluidas generaciones de LLM, llamadas a herramientas, traspasos, barreras de control y eventos personalizados.3 Esos datos le dicen al paquete qué ocurrió. La documentación de OpenAI sobre intervención humana muestra cómo la ejecución puede pausarse para aprobar herramientas, devolver aprobaciones pendientes como interrupciones, serializar el estado de ejecución y reanudarse después de las decisiones.4 Esos datos le dicen al paquete quién permitió la acción riesgosa.

Los hooks de Claude Code de Anthropic exponen una forma similar del ciclo de vida: pueden ejecutarse antes de las herramientas, después de las herramientas, durante solicitudes de permiso y cuando Claude se detiene.5 Esos eventos importan porque permiten que un sistema de agentes convierta comportamiento en hechos revisables. El paquete no debería depender de que el modelo recuerde la ejecución. El entorno de ejecución debería registrar los eventos relevantes a medida que ocurren.

La distinción importa:

Finalización débil Finalización con paquete
“Las pruebas pasan.” Comando, código de salida, resumen de salida, pruebas fallidas si las hay
“Se revisaron las fuentes.” URLs de fuentes, estado, alineación de afirmaciones, URLs bloqueadas
“El despliegue tuvo éxito.” ID de despliegue, estado del entorno de ejecución, purga de caché, prueba rápida de ruta en vivo
“Las traducciones están completas.” Lista de configuraciones regionales, resultado del control de calidad, filas de D1, estado de revisión nativa
“Aprobé el comando.” Objeto de aprobación, motivo, nivel de riesgo, actor, marca de tiempo

El paquete elimina ambigüedad. El agente aún puede escribir un resumen conciso, pero la evidencia vive fuera de la prosa.

¿Cómo debería funcionar el estado de revisión humana?

El estado de revisión humana debería aparecer como un campo propio, no como un adjetivo.

Los controles automáticos pueden probar estructura, salud de rutas, presencia de esquemas, disponibilidad de fuentes y muchas verificaciones de paridad. No pueden probar que un hablante nativo con fluidez revisó un artículo localizado. Un paquete debería declarar ambos hechos con claridad:

Estado Significado
Aprobación automática Los controles automatizados pasaron
Revisión humana pendiente Todavía no se realizó una revisión humana requerida
Aprobado por una persona Revisor, fecha, configuración regional o alcance y decisión registrados
Rechazado El revisor encontró un problema bloqueante
No requerido El flujo de trabajo no exige visto bueno humano para ese alcance

La misma regla aplica más allá de la traducción. Un control de seguridad puede pasar mientras la revisión legal sigue pendiente. Una suite de pruebas puede pasar mientras la revisión de producto rechaza el comportamiento. Un despliegue puede tener éxito mientras el CDN todavía sirve contenido obsoleto. El estado de revisión debe describir la decisión pendiente, no adornar la confianza del agente.

El AI Risk Management Framework de NIST plantea la confiabilidad como algo que los equipos incorporan al diseño, desarrollo, uso y evaluación de sistemas de IA.7 Los paquetes de revisión vuelven operativo ese marco. Convierten la evaluación en un artefacto visible, no en una afirmación dentro de la respuesta final.

¿Cómo se ve un paquete mínimo?

Empieza con algo pequeño:

# Review Packet: <work item>

## Decision
Status: ready for review | blocked | approved | rejected
Owner: <human or team>

## Goal
- User request:
- Acceptance criteria:
- Scope exclusions:

## Changes
- Files:
- Artifacts:
- External state:

## Evidence
| Claim | Proof | Result |
|---|---|---|
| Tests ran | `<command>` output | pass/fail |
| Public route works | `<url>` smoke | pass/fail |
| Sources support claims | source list | pass/fail |

## Approvals
| Action | Risk | Decision | Notes |
|---|---|---|---|

## Remaining Gaps
- <unverified work>

Al principio, el paquete debería ser sobrio. Las tablas, los enlaces y los campos breves de estado funcionan mejor que un artefacto vistoso que oculta la prueba. Una vez que la estructura funciona, el diseño puede facilitar la revisión: severidad, agrupación, filtros, trazas contraídas y próximas acciones explícitas.

La decisión de producto importante: el paquete se convierte en el artefacto que otros sistemas pueden leer. Un pull request puede enlazarlo. Una nota de lanzamiento puede resumirlo. Un revisor nativo puede firmarlo. Un agente futuro puede retomarlo.

¿Cómo cambia esto las interfaces de agentes?

Los paquetes de revisión conectan las superficies de supervisión con el umbral de evidencia.

La superficie de supervisión muestra qué requiere atención mientras el agente trabaja. El umbral de evidencia detiene una finalización débil al final. El paquete de revisión conserva el resultado. Juntos, crean un ciclo:

  1. El operador delega un objetivo.
  2. El agente actúa bajo controles de aprobación y traza.
  3. El sistema registra evidencia a medida que ocurren los eventos.
  4. El agente resume el trabajo.
  5. El paquete vincula cada afirmación con una prueba.
  6. La persona aprueba, rechaza o devuelve el trabajo.

Ese ciclo también cambia el estándar de escritura para los agentes. Una respuesta final no debería fingir que es la prueba. Debería decir dónde vive la prueba, qué verificaciones pasaron y qué sigue abierto. Cuando la tarea toca contenido público, datos de clientes, dinero, seguridad, producción o traducción, el paquete debería sobrevivir al chat.

Resumen breve

Los paquetes de revisión deberían reemplazar a las respuestas finales como el artefacto confiable de finalización para el trabajo serio de agentes. OpenAI Codex ya apunta hacia registros de terminal verificables, resultados de pruebas, aprobaciones, telemetría y trazas de tareas en la nube.12346 El ciclo de vida de hooks de Claude Code de Anthropic muestra la misma forma de entorno de ejecución desde otra pila de agentes.5 NIST aporta el marco de confianza: la evaluación pertenece al diseño, desarrollo, uso y evaluación de sistemas de IA, no solo al comportamiento del modelo.7

El movimiento práctico es simple: mantén breve la respuesta final y haz real el paquete.

Preguntas frecuentes

¿Qué es un paquete de revisión para el trabajo de agentes de IA?

Un paquete de revisión es un conjunto estructurado de evidencia que registra qué se le pidió al agente, qué cambió, qué comandos y herramientas se ejecutaron, qué aprobaciones ocurrieron, qué verificaciones pasaron y qué sigue sin verificar. Le da a un revisor humano un objeto de decisión, no solo una afirmación de finalización en prosa.

¿Por qué no alcanza una respuesta final?

Una respuesta final resume el trabajo, pero no prueba que el trabajo haya ocurrido. Las tareas de agentes ahora incluyen llamadas a herramientas, ediciones de archivos, pruebas, despliegues, traducciones, aprobaciones y estado de caché. Esos hechos necesitan evidencia adjunta. Una respuesta final puede apuntar al paquete; el paquete debería contener la prueba.

¿Qué debería incluir primero un paquete de revisión?

Empieza con el objetivo, los archivos modificados, evidencia de comandos y pruebas, verificaciones de fuentes, decisiones de aprobación, evidencia de despliegue o ruta y brechas sin resolver. Agrega trazas completas, capturas de pantalla, visto bueno de revisión nativa y notas de riesgo cuando el trabajo toque superficies públicas, de producción, de seguridad, de dinero o con impacto para clientes.

¿Todas las tareas de agentes necesitan un paquete de revisión?

No. Las tareas exploratorias de bajo riesgo pueden terminar con un resumen normal. Los paquetes de revisión importan cuando una persona tiene que firmar, fusionar, publicar, desplegar, gastar, aprobar o confiar en el resultado más adelante. El paquete debe escalar según el riesgo.

¿Cómo se relacionan los paquetes de revisión con las trazas?

Las trazas registran lo que ocurrió durante la ejecución de un agente. Los paquetes de revisión seleccionan los eventos de traza que importan para una decisión y los vinculan con afirmaciones. La traza es el registro bruto. El paquete es el objeto de revisión.


Referencias


  1. OpenAI, “Introducing Codex,” OpenAI, 16 de mayo de 2025. Fuente sobre Codex como agente de ingeniería de software basado en la nube y sobre la afirmación de que Codex ofrece evidencia verificable de acciones mediante citas de registros de terminal y resultados de pruebas. 

  2. OpenAI, “Codex cloud,” OpenAI Developers. Fuente sobre tareas de Codex cloud que leen, modifican y ejecutan código en contenedores aislados en la nube, incluida la ejecución de tareas en segundo plano y en paralelo. 

  3. OpenAI, “Tracing,” OpenAI Agents SDK. Fuente sobre trazas integradas de ejecuciones de agentes, spans, generaciones de LLM, llamadas a herramientas, traspasos, barreras de control y eventos personalizados. 

  4. OpenAI, “Human-in-the-loop,” OpenAI Agents SDK. Fuente sobre interrupciones de aprobación, aprobaciones pendientes, RunState serializado y ejecución reanudada después de decisiones de aprobación. 

  5. Anthropic, “Hooks reference,” Claude Code Docs. Fuente sobre eventos del ciclo de vida de Claude Code como PreToolUse, PostToolUse, PermissionRequest y Stop

  6. OpenAI, “Running Codex safely at OpenAI,” OpenAI, 8 de mayo de 2026. Fuente sobre los controles descritos por OpenAI para Codex en torno a aislamiento, aprobaciones, política de red, identidad, configuración administrada, exportación de registros de OpenTelemetry, registros de cumplimiento y telemetría nativa para agentes. 

  7. National Institute of Standards and Technology, “AI Risk Management Framework,” NIST. Fuente sobre la incorporación de consideraciones de confiabilidad en el diseño, desarrollo, uso y evaluación de productos, servicios y sistemas de IA. 

Artículos relacionados

Los agentes necesitan superficies de supervisión

Las superficies de supervisión convierten el trabajo autónomo de IA en operaciones inspeccionables: aprobaciones, trazas…

12 min de lectura

El diseño agéntico es diseño de superficies de control

El diseño agéntico no es un cuadro de chat más bonito. Es la superficie de control que vuelve al software autónomo visib…

13 min de lectura

El Bucle Ralph: Cómo ejecuto agentes de IA autónomos durante la noche

Construí un sistema de agentes autónomos con stop hooks, presupuestos de generación y memoria en el sistema de archivos.…

10 min de lectura