Es fácil añadir IA a un proceso. Lo difícil es decidir qué debe ocurrir cuando produce una respuesta plausible pero incorrecta.
Imagine un buzón compartido que recibe facturas, avisos de entrega y consultas normales. Clasificar esos mensajes puede requerir interpretación. Comprobar un número de factura frente a registros conocidos o enviar un aviso después de una aprobación no la requiere. Estas tareas suelen ser más fáciles de probar y operar con software convencional. Un modelo puede ayudar a clasificar o extraer información, pero su resultado sigue siendo incierto.
Defina el paso exacto
Describa el paso que quiere automatizar y la consecuencia de equivocarse. «Usar IA para procesar correos» es demasiado general para evaluarlo. «Leer los mensajes entrantes, identificar las solicitudes de facturas y enviar las relevantes a la cola de contabilidad» es lo bastante concreto para analizarlo.
Después, pregúntese qué necesita realmente ese paso:
- copiar datos de un sistema a otro;
- aplicar una regla empresarial fija;
- buscar un registro;
- calcular un valor;
- interpretar texto, imágenes o voz; o
- recomendar una acción a una persona.
Las cuatro primeras tareas suelen resolverse con código normal, una consulta a la base de datos o una integración. Las dos últimas pueden justificar un modelo, pero solo si el proceso puede manejar un resultado incierto.
Una regla fija puede bastar
Un modelo es un mal sustituto de una condición que se puede expresar directamente. Utilice automatización convencional cuando la tarea consista en:
- copiar un número de cliente desde un campo aprobado;
- rechazar una importación cuando falta un dato obligatorio;
- dirigir un pedido según el país o el tipo de pedido;
- calcular un total a partir de valores definidos; o
- crear un documento a partir de una plantilla fija.
Las reglas tienen una propiedad útil en estos casos: la misma entrada produce el mismo resultado y una condición fallida puede explicar por qué el proceso se detuvo. La implementación puede necesitar gestión de errores, permisos y registros, pero la decisión es comprobable.
Añadir un modelo a un paso determinista introduce otra dependencia sin eliminar la regla subyacente. También puede hacer que un fallo sencillo sea más difícil de diagnosticar.
Cuando la entrada es irregular
La IA puede ser adecuada cuando la entrada es difícil de tratar con una lista corta de reglas. Algunos ejemplos son clasificar un correo que no sigue un formato fijo, extraer información de documentos enviados por distintas organizaciones o preparar un primer resumen para que lo revise una persona.
Eso no hace que el resultado sea fiable por defecto. El modelo puede interpretar mal una frase, omitir un detalle o devolver un dato plausible que nunca aparecía en el documento original. El resto del proceso debe hacer visibles esos casos.
Un límite práctico es el siguiente:
- conserve la entrada original;
- pida al modelo una respuesta limitada a un formato definido;
- valide el resultado en el código de la aplicación;
- envíe los resultados inciertos o inválidos a una persona; y
- registre lo ocurrido para poder revisarlo después.
El modelo puede ayudar a interpretar la entrada. No debe modificar silenciosamente el sistema que contiene los datos oficiales.
Ponga límites al resultado
Antes de conectar un modelo a un proceso real, describa su salida como un contrato. Defina las categorías, los campos, los formatos y los valores permitidos. Rechace cualquier resultado que no cumpla ese contrato.
En un paso para extraer datos de facturas, el contrato podría exigir el nombre del proveedor, el número de factura, la fecha, la moneda y el total. La aplicación puede comprobar que la fecha tiene un formato válido, que la moneda está admitida y que el total se puede interpretar como número. También puede comparar el proveedor extraído con los registros conocidos.
Estas comprobaciones no demuestran que el modelo haya leído bien el documento. Sí evitan que una respuesta mal formada avance por el proceso.
Los niveles de confianza requieren la misma cautela. Una puntuación proporcionada por un modelo no es automáticamente una probabilidad calibrada. Utilícela como una señal más, junto con las reglas de validación, la comprobación de registros conocidos y un umbral de revisión. Establezca ese umbral a partir de resultados observados, no de un número que simplemente parezca tranquilizador.
Reúna pruebas antes de ponerlo en producción
Una demostración del prompt no es un plan de pruebas. Reúna ejemplos representativos antes de poner el sistema en producción. Incluya casos normales, entradas incompletas, formatos poco habituales y situaciones en las que la respuesta correcta sea «no puedo decidir». Elimine o proteja los datos personales según corresponda y conserve las hipótesis utilizadas para preparar el conjunto de pruebas.
Para cada ejemplo, registre:
- la categoría o los campos esperados;
- el resultado del modelo;
- si el resultado pasó la validación;
- si una persona lo aceptó o corrigió; y
- qué ocurrió cuando la entrada era ambigua.
Analice por separado los falsos positivos y los falsos negativos. Enviar una consulta normal a la cola de facturas puede resultar incómodo. No detectar un documento que requiere atención urgente puede tener otra consecuencia. El patrón de error aceptable depende del proceso, por lo que una única cifra de precisión rara vez basta.
Repita las pruebas cuando cambien el prompt, el modelo, el proveedor, el formato de los documentos o una regla empresarial. Un flujo que funciona con los ejemplos del mes pasado puede comportarse de otra manera cuando cambian sus entradas.
Una cola de revisión necesita responsable
«Alguien puede comprobarlo» no es un diseño de revisión. La persona que revisa necesita una cola, la fuente original, el resultado extraído o clasificado, el motivo de la escalada y una forma clara de aceptarlo o corregirlo.
La corrección debe servir para algo. Si alguien cambia el nombre de un proveedor o rechaza una clasificación, registre esa decisión en un lugar que permita investigar el problema y evaluar el sistema más adelante. No obligue a los revisores a aprobar un resultado que no pueden inspeccionar.
La revisión también necesita una persona responsable y un plazo de respuesta adecuado al proceso. Si nadie atiende la cola, el modelo solo ha trasladado el trabajo manual a un lugar menos visible.
Decida qué ocurre cuando falla
Un proveedor puede no estar disponible, un documento puede superar los límites de entrada, la respuesta puede no pasar la validación o un modelo puede devolver una respuesta sin evidencia útil. Cada caso necesita un resultado definido.
Según el proceso, la respuesta segura puede ser:
- dejar el elemento en un estado que permita reintentarlo;
- enviarlo al procesamiento manual;
- pedir una entrada corregida;
- registrar el fallo y avisar a la persona responsable; o
- continuar con una acción limitada que no modifique datos importantes.
El recurso de emergencia no debe ser «continuar como si el modelo tuviera razón». Conserve el elemento y su estado para que una persona pueda ver qué queda pendiente.
Incluya mantenimiento y revisión
Compare la opción con IA con una regla, una función de un producto existente, una integración API o una herramienta interna pequeña. Incluya el trabajo que rodea al modelo, no solo la llamada:
- preparar y proteger la entrada;
- validar y guardar el resultado;
- revisar los casos inciertos;
- vigilar los fallos y los cambios del proveedor;
- comprobar los resultados cuando cambien las entradas; y
- mantener una alternativa para los fallos.
Documente esa decisión, incluida la persona que gestiona las excepciones, antes de la primera ejecución real.