IA en la captura de pedidos: comprobar artículo, unidad y precio por separado
Un correo de pedido puede ser comprensible y, aun así, no poder registrarse. Un ejemplo desarrollado muestra qué datos deben venir de sus sistemas.
«Envíenos dos cajas de A al precio de la última vez». La intención se entiende. Para registrar un pedido fiable faltan datos. ¿Qué presentación quiere el cliente? ¿Qué condiciones se acordaron? ¿Sigue siendo aplicable aquel precio?
Recomendamos utilizar el modelo de lenguaje para interpretar el mensaje. La identificación del artículo, la conversión de unidades y el precio aplicable deben basarse en datos y reglas de negocio aprobados. Un texto plausible no sustituye un acuerdo comercial que falta.
Qué permite saber realmente el mensaje
El catálogo hipotético contiene A-6, con seis unidades por caja, y A-12, con doce. En el uso cotidiano ambos se llaman «producto A». El cliente pidió A-6 la última vez. Ese historial es una pista, pero no demuestra que ahora quiera la misma presentación.
Dato | Deducible del mensaje | Información pendiente para el pedido |
|---|---|---|
Cantidad | Dos cajas | Presentación inequívoca |
Artículo | El nombre A | Correspondencia con A-6 o A-12 |
Precio solicitado | Como la última vez | Condiciones anteriores y vigencia actual |
Cliente | El remitente como posible pista | Confirmación de la cuenta correcta |
Doce y veinticuatro unidades son pedidos diferentes en este ejemplo. La automatización debe mantener visible esa incertidumbre. Puede preparar una pregunta concreta o remitir la operación a revisión.
Separe la propuesta del registro
Un borrador útil conserva el mensaje original junto a la correspondencia propuesta. En cada línea debe distinguirse qué procede del mensaje, qué viene del catálogo y qué decisión sigue pendiente.
El precio se comprueba en la fuente de precios que la empresa considera válida. Una factura anterior puede reflejar una promoción, otra cantidad o un acuerdo distinto. El modelo no debe deducir de ese importe un derecho actual al mismo precio.
Cuando el cliente, el artículo, la unidad y el precio estén establecidos, el borrador podrá aprobarse según las reglas acordadas. La recepción repetida del mismo mensaje también debe tratarse sin generar un segundo pedido involuntario.
¿Hace falta un agente?
Anthropic distingue los flujos predefinidos de los sistemas en los que el modelo elige los pasos siguientes. Aquí puede bastar una secuencia fija de lectura, comparación y comprobación. Introducir un modelo no justifica automáticamente un agente con libertad para elegir acciones.
Un mayor margen puede ayudar si cada caso exige investigaciones diferentes. Los datos accesibles y las acciones permitidas siguen estando delimitados. El nombre del producto no resuelve esa decisión de diseño.
Cuándo puede ser adecuado aceptar automáticamente
Un catálogo limitado y códigos de cliente explícitos pueden cambiar las condiciones. Si por acuerdo «A» designa únicamente A-6, la regla de precios está definida y las demás comprobaciones se cumplen, el registro automático puede formar parte del proceso aprobado. No toda línea necesita por principio una aprobación humana.
Pruebe por separado los casos difíciles: otra presentación, condiciones vencidas, remitente incierto y mensaje repetido. Defina el resultado correcto de cada uno. Un porcentaje global alto informa poco si se acepta automáticamente un precio ambiguo.
El avance esperado de un primer proyecto debe ser concreto: menos transcripción manual, con artículo inequívoco, cantidad trazable y condiciones bien aplicadas. Evalúe la operación completa, incluidas consultas y correcciones, para comprobarlo.
Fuentes
Anthropic: Building effective agents, para la distinción conceptual entre flujo y agente. La recomendación y el pedido son análisis editorial.
Seguir leyendo
Todos los artículos
IA y automatización con ASES
Asistentes de IA y procesos automatizados