Dónde ubicar la revisión humana en un flujo con IA

La revisión humana debe ocurrir antes de que un flujo con IA haga un cambio importante, cuando una persona todavía puede detenerlo o corregirlo. La revisión tiene que mostrar la acción propuesta y su evidencia. Aprobar un párrafo convincente sirve de poco si el sistema ejecuta otros parámetros después.

La pregunta práctica es dónde el criterio humano cambia el resultado lo suficiente como para justificar la interrupción.

Usá consecuencias y reversibilidad para ubicar la revisión

Separá borradores de acciones. Una etiqueta interna que se corrige fácilmente podría revisarse por muestreo. Enviar un mensaje a un cliente o modificar un registro operativo compartido exige otra evaluación: alguien puede actuar con esa información antes de que llegue una corrección.

La guía de OWASP sobre inyección de instrucciones recomienda aprobar acciones importantes antes de ejecutarlas y verificar la acción exacta aprobada. La revisión complementa la autorización del servidor; no concede permisos que la persona no tiene.

Conducta propuesta	Política inicial de revisión
Borrador privado sin efectos externos	Revisión durante la edición
Clasificación interna reversible	Muestreo y cola de excepciones
Mensaje externo	Revisar destinatario, contenido y adjuntos antes del envío
Operación destructiva o difícil de revertir	Aprobación explícita autorizada o exclusión de la automatización

Son puntos de partida para diseñar, no categorías universales de riesgo. Cambiar un campo puede ser inocuo en pruebas y relevante en un sistema de despacho.

Mostrá algo que valga la pena verificar

Presentá la fuente junto al cambio propuesto. Identificá información ausente, contradicciones, registro afectado y consecuencias de aprobar. Para modificar datos existentes, mostrá una comparación legible entre el valor actual y el nuevo.

Permití corregir, rechazar y escalar. Una pantalla que solo permite aprobar presiona a aceptar trabajo que la persona no puede reparar. Registrá motivos de corrección para distinguir errores de extracción de reglas de negocio poco claras.

No usés la confianza declarada por el modelo como único criterio de envío a revisión. La ausencia de evidencia obligatoria y las contradicciones deben activar revisión aunque la respuesta suene segura. Cualquier umbral numérico necesita contrastarse con casos etiquetados de la tarea real.

Ejemplo hipotético: responder a un cliente

Un asistente redacta una respuesta sobre una entrega atrasada. La persona revisora ve destinatario, pedido, estado de origen y mensaje. Aprueba esa versión exacta.

Antes del envío, otro proceso cambia el estado de la entrega. El producto necesita decidir si eso invalida la aprobación. En este ejemplo, la invalida porque cambió el hecho central de la respuesta. El mensaje vuelve a revisión, en lugar de enviar una promesa desactualizada.

Vinculá la aprobación con la versión de la propuesta y las fuentes relevantes. Volvé a comprobar permisos al ejecutar y hacé idempotente el envío. Una aprobación no debe convertirse en permiso reutilizable para mensajes futuros.

Planificá la cola y las ausencias

La revisión genera trabajo. Asigná un rol, una ventana de respuesta y una persona sustituta. Mostrá la antigüedad de los pendientes y conservá un estado seguro cuando nadie esté disponible. Vencer un plazo no debe equivaler silenciosamente a aprobar.

Medí correcciones y errores que escaparon, además del volumen aprobado. Si se acepta todo, investigá si las propuestas son buenas o si verificar resulta impráctico.

Elegí una acción importante y prototipá sus estados de evidencia, corrección y aprobación vencida mediante diseño UX/UI. Pedile a quien revisará el trabajo que rechace una propuesta con un error deliberado. Comprobá si puede detectarlo y justificar su decisión con lo que muestra la pantalla.