Revisión humana en IA: dónde aprobar sin frenar el flujo

La pregunta correcta no es si habrá revisión

La decisión más útil no consiste en elegir entre revisarlo todo o no revisar nada. Hay que separar las acciones de bajo impacto, que pueden avanzar con reglas claras, de las decisiones que modifican dinero, compromisos comerciales, acceso a datos o reputación. La revisión humana debe aparecer en el punto donde un error se vuelve costoso, difícil de deshacer o difícil de detectar después.

Una matriz sencilla ayuda a evitar colas artificiales. Evalúa cada etapa según su impacto potencial, reversibilidad, sensibilidad de los datos, grado de incertidumbre y alcance de la acción. Una sugerencia de asunto de correo suele tener bajo impacto y alta reversibilidad. En cambio, un descuento fuera de la política, una promesa de plazo o el envío de datos de un cliente merece una barrera más fuerte, aunque la frase parezca bien escrita.

• Bajo riesgo: generar un borrador, clasificar la intención o sugerir preguntas para completar el contexto.
• Riesgo intermedio: recomendar condiciones dentro de una política conocida, con campos obligatorios y límites verificables.
• Alto riesgo: enviar un mensaje externo con un compromiso, modificar un registro, conceder una excepción o exponer información restringida.

Fuentes y referencias: [2]

La aprobación debe activarse mediante señales concretas

Un flujo no necesita pedir aprobación porque haya utilizado IA. Necesita pedirla cuando el resultado contiene señales que cambian la naturaleza de la decisión. Entre ellas se encuentran un descuento por encima del límite, lenguaje de garantía, datos personales, conflicto con la política, ausencia de una fuente para una afirmación importante, un cliente estratégico o baja confianza en la clasificación. Estas señales pueden combinarse en reglas deterministas, en lugar de depender únicamente de una puntuación producida por el modelo.

También es útil distinguir entre preparación y ejecución. La IA puede preparar una respuesta, destacar los datos utilizados y señalar posibles problemas sin tener permiso para enviarla. El envío, la modificación del precio o la creación de una condición excepcional quedan detrás de una autorización explícita. Para las acciones con efecto externo, las herramientas con operaciones de lectura y escritura deben tener permisos diferentes y una confirmación asociada al acto relevante, no una aprobación genérica al inicio de la conversación.

• Aprueba antes de ejecutar cuando haya escritura en un sistema, compromiso financiero o excepción de política.
• Permite la publicación automática solamente cuando los campos críticos estén completos y dentro de límites probados.
• Deriva a una cola especializada cuando el problema exija criterio comercial, jurídico o de relación con el cliente.

Fuentes y referencias: [1]

Ejemplo hipotético: preparar respuestas comerciales

Imagina una empresa que recibe solicitudes de propuesta por correo electrónico. El flujo hipotético extrae el producto, la cantidad, la región, el plazo solicitado y las condiciones mencionadas por el cliente. Después, consulta una tabla autorizada, crea un borrador y clasifica el caso. La IA no envía el mensaje. Entrega al vendedor un texto con los datos utilizados, las lagunas encontradas y los motivos que determinaron el nivel de aprobación.

Una solicitud estándar, con el precio vigente, un plazo disponible y ninguna condición excepcional, puede pasar a una cola de envío rápido, siempre que el responsable confirme el borrador. Una solicitud con un descuento dentro del rango autorizado puede requerir solamente la confirmación del vendedor. Si hay un descuento por encima del límite, una promesa de entrega no confirmada, una solicitud de exclusividad o información contradictoria, el flujo debe detener la preparación comercial y derivar el caso a la persona responsable. La regla no consiste en confiar ciegamente en la clasificación, sino en hacer visible por qué se realizó.

En este diseño, la aprobación no corrige un mensaje después de enviarlo. Autoriza una acción delimitada. La pantalla podría mostrar el borrador, los campos extraídos, la política aplicada, las fuentes internas consultadas, las alertas y botones separados para editar, aprobar o rechazar. Si la persona modifica el precio o el plazo, el sistema debe recalcular las alertas antes de permitir el envío. Esto reduce las aprobaciones automáticas basadas en un contenido que ya cambió.

• El resultado debe utilizar campos estructurados para el precio, el plazo, el descuento, la moneda, el destinatario y el estado de aprobación.
• El borrador debe separar los hechos confirmados, las inferencias y la información que todavía falta.
• Un rechazo debe registrar un motivo seleccionable y permitir corregir el flujo sin reiniciar toda la tarea.

Fuentes y referencias: [1][3]

Diseña el flujo para pausar poco y explicar bien

La arquitectura más adecuada suele ser un flujo de trabajo predecible, no un agente con libertad para decidirlo todo. Primero, valida el formato y el origen de los datos. Después, extrae los campos en un esquema cerrado, aplica las reglas de negocio, genera el borrador y calcula las señales de derivación. Solo entonces presenta la aprobación necesaria. Esta secuencia facilita las pruebas, la auditoría y el mantenimiento, porque cada etapa tiene una responsabilidad observable.

Las entradas externas deben tratarse como datos, no como instrucciones confiables. Un texto recibido de un cliente puede contener solicitudes legítimas, pero también puede intentar influir en el comportamiento del sistema. Las salidas estructuradas, los límites de las herramientas y la separación entre lectura y escritura reducen los caminos inesperados. Aun así, ninguna de estas medidas elimina todos los errores. El nivel de acceso debe ser suficientemente reducido para que un fallo en una etapa no se convierta automáticamente en una acción amplia.

Para evitar que la aprobación se transforme en un cuello de botella, agrupa solamente los elementos que sean realmente equivalentes y conserva las excepciones individuales. Muestra al aprobador solo lo que cambió, el motivo de la alerta y la acción prevista. Define la caducidad de los borradores antiguos, responsables sustitutos y una ruta clara para los casos sin respuesta. Estas son recomendaciones de diseño operativo, no garantías de que el flujo será rápido con cualquier volumen.

• Utiliza estados explícitos, como borrador, pendiente de aprobación, rechazado, aprobado y enviado.
• Separa los permisos para preparar, editar, aprobar y ejecutar, siempre que la herramienta lo permita.
• Evita que el modelo elija por sí solo quién aprueba; utiliza reglas de negocio y una responsabilidad definida.

Fuentes y referencias: [1][2]

Mide lo que la aprobación realmente protege

Una revisión humana solo puede calibrarse cuando el equipo sabe qué errores encuentra y cuáles únicamente añaden demora. Registra el tipo de alerta, la decisión tomada, las ediciones realizadas, el tiempo hasta la resolución y los casos que escaparon. El objetivo no es convertir cada indicador en una meta aislada, sino descubrir si la barrera está colocada en el lugar correcto. Muchas alertas ignoradas sugieren que las reglas son demasiado amplias; pocas alertas con fallos graves sugieren una cobertura insuficiente.

Crea evaluaciones con ejemplos normales, incompletos, ambiguos y adversariales. Prueba por separado la extracción de campos, la selección de la política, la detección de excepciones y el contenido final. Las comparaciones entre dos respuestas pueden ayudar a evaluar la claridad y la adherencia, pero siguen siendo necesarios criterios objetivos. La evaluación debe crecer con los casos reales autorizados por el negocio, sin tratar una aprobación anterior como prueba de que una respuesta futura será segura.

La política de aprobación también necesita un responsable. En una revisión periódica, esa persona puede ajustar los límites, retirar alertas poco útiles, añadir ejemplos y comprobar si los permisos siguen siendo coherentes con las acciones. El resultado deseado es una cola breve de decisiones que requieren criterio, mientras el resto avanza por un camino controlado y reversible.

• Sigue por separado los errores de contenido, los errores de datos, las alertas innecesarias y las acciones bloqueadas correctamente.
• Reevalúa el flujo después de cambios en las instrucciones, las herramientas, las políticas, las fuentes o el formato de los mensajes.
• Define condiciones objetivas para ampliar o reducir la autonomía, en lugar de cambiar el proceso por impresión.

Fuentes y referencias: [3]