Dónde introducir revisión humana

Define la decisión que necesita una persona

«Con revisión humana» no describe un control suficiente. Hay que saber qué revisa la persona, con qué información, en qué momento y qué puede hacer al detectar un fallo. Una pantalla que solo muestra la propuesta del modelo puede inducir a aprobar algo que parece coherente sin permitir contrastarlo.

En las alternativas del Atlas, preparar un registro, generar un informe de campaña y sintetizar procedimientos son acciones que producen borradores. La escritura en CRM, el envío de campañas y las decisiones que siguen a una consulta están fuera de las configuraciones propuestas. Esa separación permite colocar el punto de control antes de una acción con consecuencias externas.

La distinción entre recorridos predeterminados y autonomía del modelo de Anthropic sirve para localizar dónde reside cada decisión. Nuestra propuesta de controles es editorial y deberá contrastarse con las personas que operen el piloto.

Revisa en el punto donde todavía puedes corregir

Para un registro comercial, muestra el mensaje original junto a los campos extraídos. Resalta qué fragmento sustenta cada valor y cuáles faltan. Permite aprobar, corregir, rechazar o pedir información. No presentes la confianza del modelo como sustituto de la evidencia.

En una campaña, organiza los hallazgos por requisito del briefing. La persona debe ver el texto requerido, la pieza observada y el motivo del posible incumplimiento. «No se ha detectado un problema» y «este requisito no se pudo evaluar» necesitan estados diferentes.

Para procedimientos, presenta la respuesta y las citas con documento, sección y versión. Un fragmento existente puede no sostener la conclusión. La revisión debe comprobar esa relación, además de la existencia de la fuente.

Una cola de revisión también es un proceso

Asigna un responsable y define qué ocurre si nadie revisa a tiempo. Un borrador pendiente no debería convertirse automáticamente en aprobado por antigüedad. Para el piloto, una política sencilla es mantenerlo pendiente y avisar al operador dentro de su herramienta habitual; configura esos avisos como parte de tu piloto.

Evita revisiones repetidas sin identidad de tarea. Si aparece otro intento de la misma solicitud, conserva el historial y presenta qué cambió. Cuando una persona corrige un campo, registra el valor anterior, el nuevo y el motivo. No reutilices automáticamente una aprobación si la salida ha cambiado después.

Ejemplo sintético de registro de revisión:

{
  "task_id": "SYN-CRM-001",
  "proposal_version": "v1",
  "decision": "corrected",
  "changed_fields": ["servicio"],
  "reason": "El texto solicita una revisión, no una implantación",
  "review_seconds": 90
}

El tiempo y la decisión del ejemplo son inventados para ilustrar el esquema. No representan una revisión realizada. En una ejecución real, añade identidad autorizada del revisor y timestamp sin publicar información personal innecesaria.

Qué ocurre si cambia el borrador aprobado

Imagina que revisas una propuesta para una empresa y la apruebas. Antes de ejecutarse, otra etapa cambia el destinatario o el contenido. La aprobación anterior describe una decisión sobre otra versión: conservar un simple campo approved: true puede ocultar esa diferencia.

El laboratorio de aprobación por versión permite observar ese caso. Descomprime el ZIP y ejecuta desde su directorio, con Python 3.10 o posterior:

python3 aprobacion_versionada.py --output salida.json
python3 -m unittest -v test_agentic_lab.HarnessTests

El programa utiliza el mismo ejecutor SQLite de la práctica de reintentos. Crea una operación, simula una aprobación de la revisión uno y modifica el texto. El intento sobre la revisión dos queda en awaiting_approval, sin escrituras en el destino. Después de una nueva aprobación simulada, termina con un único efecto.

La huella de aprobación del ejemplo combina identidad de operación, revisión, contenido y versión de política. Al cambiar el contenido, el ejecutor elimina la aprobación previa. Es un mecanismo de vinculación dentro de la práctica: la huella no identifica a una persona ni constituye una firma digital.

En resultado.json puedes comprobar los estados y los eventos de creación, aprobación y cambio. Los valores del reloj son sintéticos. El ejemplo no incorpora usuarios autenticados, CRM ni procesos concurrentes, y no ejecuta un modelo.

Para una implementación con varios trabajadores, comprueba la versión autorizada en el punto de ejecución y define qué ocurre si cambia mientras se prepara la acción. Una pantalla que mostraba la revisión correcta hace unos segundos no acredita por sí sola qué terminó ejecutándose.

La interfaz de revisión debería mostrar qué ha cambiado, permitir contrastar la versión anterior y ofrecer aprobar, corregir o rechazar la nueva propuesta. La resolución debe quedar asociada a esa revisión, con responsable y motivo. Este diseño de interfaz es una propuesta para el piloto; el laboratorio comprueba únicamente el mecanismo local de vinculación.

Decide la cobertura de revisión con evidencia

Durante un piloto sin resultados propios, revisar todas las salidas es una elección conservadora de aprendizaje, no una garantía de seguridad. Una persona puede equivocarse, perder atención o no tener el contexto necesario. Prepara ejemplos de discrepancias y comprueba si distintos revisores aplican la misma rúbrica.

Si más adelante reduces la cobertura, combina un muestreo definido con rutas obligatorias para excepciones conocidas. No revises únicamente los casos que el modelo califica como difíciles: podrías dejar fuera errores que expresa con seguridad. Conserva una muestra de casos aparentemente normales para buscar fallos silenciosos.

La documentación de evaluaciones de Anthropic describe distintos tipos de verificadores y la necesidad de diseñar la evaluación del sistema. Un juez automático puede ayudar a priorizar, pero la propuesta de revisión debe evaluarse también por sus errores y acuerdos con la rúbrica humana.

Mide la carga y los fallos del control

Registra cuántas tareas se revisan, cuánto tiempo total requieren y cuántas terminan corregidas, rechazadas o escaladas. Incluye las segundas revisiones en el tiempo por tarea revisada. La calculadora ya multiplica ese tiempo por el porcentaje revisado; no vuelvas a multiplicarlo por los reintentos.

Observa el estado final del trabajo: un campo corregido no sirve si otra etapa vuelve a escribir el valor anterior. Prueba qué ocurre cuando se revisa una propuesta antigua mientras llega una nueva. Una aprobación debe pertenecer a una versión concreta de la salida.

Prepara la primera revisión del piloto

Empieza con los casos sintéticos del protocolo de campañas o de respuestas con fuentes. Entrega a la persona una rúbrica, las fuentes y las acciones disponibles. Conserva las discrepancias y revisa las instrucciones antes de ampliar volumen.

El resultado esperado de ese trabajo es saber qué control aporta información útil y cuál solo añade un clic. Hasta ejecutarlo, las fichas describen puntos de intervención propuestos; no afirman que esas revisiones hayan detectado errores ni que permitan operar sin supervisión.