Una historia de compras explica dónde ayudan los agentes, cómo limitar datos y acciones y cómo probar aprobaciones, fallos y valor operativo real.
Autor
Anichur Rahaman
Parte 1 de 3
IA en la operación, 2026En la reunión de compras del lunes hay catorce pedidos propuestos por revisar. Una línea dice «12 cajas»; la compradora esperaba 12 piezas. Cada caja contiene 12 piezas, así que la propuesta compraría 144. La escena es ficticia, pero la decisión es real: ¿el software hará una sugerencia útil o podrá convertirla en un compromiso con el proveedor?
La compradora quiere ayuda para detectar faltantes y preparar documentos. No quiere supervisar cada pulsación, pero tampoco puede descubrir un error después del despacho. Un despliegue sensato empieza por definir ese límite, antes de admirar una demostración que completa una tarea llamativa.
Esta es la primera entrega sobre IA en operaciones. La segunda aborda las conexiones MCP; la tercera, aprobaciones y auditoría. Aquí decidimos qué trabajo conviene delegar y cómo demostrar el resultado.
Un agente de IA puede elegir y llamar herramientas para alcanzar un objetivo: consultar un pedido, revisar una recepción, crear un borrador o solicitar otro paso. «Copiloto» y «agente» son etiquetas comerciales que se solapan. Examina las herramientas y los derechos de ejecución, sin asumir que uno solo conversa y el otro actúa.
Usa reglas deterministas para cálculos, validaciones y transacciones repetibles. Un modelo de lenguaje puede interpretar un mensaje confuso o explicar una excepción; no debería ser el único calculador ni decidir qué puede comprar una persona. Si un flujo fijo ya resuelve bien el problema, añadir un agente puede aumentar el costo sin aportar flexibilidad útil.
Una respuesta incorrecta también puede causar pérdidas o revelar datos. Un asistente de solo lectura que expone precios privados de otra sucursal o inventa un estado de pago no es inocuo. Escribir añade consecuencias, pero leer también exige controles.
Clasifica la tarea concreta por sensibilidad de datos, impacto, compromisos externos, volumen y recuperación, no solo por tener un botón «deshacer». Reservar la última unidad puede ser reversible técnicamente y aun así impedir una compra legítima. Miles de acciones pequeñas también acumulan una exposición grande.
Los siguientes modos son una política que debe acordarse con los responsables, no categorías legales ni una escalera automática. Hacer buenos borradores no autoriza a enviarlos.
| Modo | Trabajo útil | Límite necesario |
|---|---|---|
| Leer y explicar | Evidencia permitida de stock o factura | Alcance por registro/campo, vigencia, privacidad de salida |
| Preparar | Borrador de compra, aviso o excepción | Sin efectos ocultos; revisión humana |
| Ejecutar según política | Una acción explícitamente permitida y acotada | Autorización vigente, aprobación exacta cuando corresponda, sin duplicados |
| Retener y escalar | Ambigüedad, acceso denegado o compromiso sin aprobar | Detener esa acción; asignarla a una persona responsable |
Para nuestra compradora ficticia, empieza por un proveedor y una familia de productos. Comprueba SKU/variantes, proveedores aprobados, unidades de compra, moneda, plazos, stock utilizable, compromisos existentes y recepciones previstas. Un producto puede tener varios proveedores y tamaños de envase; no impongas un único proveedor a todos.
La herramienta devuelve evidencia fechada y cantidades explícitas: 12 piezas = 1 caja, no 12 cajas. La lógica del negocio valida cálculos y límites. Una conversión ambigua, stock desactualizado o un proveedor sin resolver genera una excepción para la compradora; el modelo no inventa el dato faltante.
El borrador debe ser realmente inerte. Prueba si guardarlo reserva presupuesto, envía un correo o dispara otro flujo. La revisión muestra proveedor, destino, artículos, cantidades/unidades, precios, moneda, impuestos, total y fechas de la evidencia. Una persona autorizada aprueba esa versión exacta. Cambios relevantes o evidencia vencida exigen nueva comprobación y, cuando corresponda, nueva aprobación.
La ejecución vuelve a comprobar permisos y restricciones vigentes. La orden existe cuando el sistema confirma el resultado registrado. Si enviarla al proveedor es otro paso, registra ese resultado aparte. Crear el documento, enviarlo y obtener aceptación del proveedor no son estados equivalentes.
En una petición interactiva, el acceso efectivo es la intersección de los derechos del usuario, el alcance del agente/herramienta y la política vigente. Aplícalo por registro y campo, no solo al menú, y compruébalo en cada llamada. Una consulta de una tienda no debe buscar documentos privados ni respuestas almacenadas de otra.
Una tarea desatendida necesita una identidad de servicio acotada, responsable y vencimiento/revisión; no un administrador compartido ni permisos heredados de una sesión humana sin explicación. Prompts, archivos recuperados, salidas, logs y acceso del proveedor del modelo deben respetar la misma política de datos. Revisa retención, región, subencargados y condiciones de entrenamiento: alojar el ERP tú mismo no vuelve local una llamada a un modelo externo.
PDF del proveedor, mensajes de clientes y páginas web son evidencia, no autorizaciones nuevas. Una frase en una factura no permite cambiar datos bancarios. OWASP describe herramientas, permisos y autonomía excesivos como agencia excesiva. Impón los límites en la aplicación, no solo en el prompt.
Consultas de stock: devuelve cantidades permitidas por ubicación/estado y fecha de la evidencia. Separa disponibilidad para prometer, existencia física, estimación y asignación.
Propuestas de compra: prepara un borrador acotado y explica los datos. Conserva cantidades, compromisos con proveedores y liberación en el flujo aprobado.
Excepciones de facturas: compara factura, orden y recepción con tolerancias acordadas, incluidas recepciones parciales, moneda e impuestos. Marca coincidencias dudosas; no las pagues ni contabilices silenciosamente.
Recordatorios vencidos: verifica vencimiento, disputa y pagos recientes. Redacta para el destinatario correcto y autorizado. Que se aceptaran borradores anteriores no justifica el envío desatendido: siguen vigentes reglas de contacto y límites de escalamiento.
Textos de producto: parte de atributos verificados. El editor revisa idioma, ingredientes/seguridad, tallas y garantías. Traducir debe preservar la afirmación, no reforzarla.
Liberar nómina, cambiar bancos de proveedores, reembolsar, modificar todo el catálogo, borrar o corregir contabilidad requiere controles explícitos. Algunas empresas ya automatizan asientos rutinarios con reglas deterministas, aprobaciones y evidencia. El problema no es prohibir toda automatización, sino dar a un agente probabilístico autoridad abierta sobre trabajo con consecuencias.
Pide al proveedor demostrar una consulta entre tiendas denegada, instrucciones maliciosas dentro de un documento, cambios posteriores a aprobación y permisos caducados. Un rechazo convincente no basta si los datos o la acción ya salieron.
Simula un timeout después de crear la orden y antes de recibir confirmación. Consulta la operación/referencia existente antes de reintentar. Usa protección contra duplicados, backoff exponencial acotado con jitter para fallos reintentables, un presupuesto de reintentos y responsable de estados inciertos. No repitas a ciegas una compra, pago o devolución inciertos. Peticiones inválidas y denegaciones requieren corrección, no repetición.
Limita por operación y de forma acumulada importes, registros, llamadas, duración y gasto del proveedor. Prueba la parada: debe impedir trabajo nuevo y conservar resultados en curso para conciliarlos. Registra actor, alcance delegado, fuentes, cambio propuesto, aprobación/versión, resultado y referencia. Restringe el log y oculta datos sensibles; no copies todos los archivos de clientes.
Pide una explicación breve basada en evidencia, no el razonamiento interno oculto del modelo. Verifica quién puede ver/exportar evidencias, su retención y la investigación de incidentes. El AI Risk Management Framework de NIST es una referencia organizativa voluntaria, no un certificado del producto.
Usa 30/60/90 días como ventanas de revisión si ayudan, no como ascensos automáticos de permisos. Empieza con consultas acotadas y después borradores supervisados. Una escritura limitada exige otra decisión, pruebas de fallo y responsable. Mantener solo borradores puede ser la mejor opción económica.
En un ejemplo de 200 casos, el equipo acepta 160 borradores sin cambiar, edita 30 y rechaza 10: aceptación sin cambios del 80%. Una muestra independiente de 40 aceptados encuentra dos errores materiales, el 5% de esa muestra. No estima con precisión todos los casos y demuestra que aceptación no es corrección. Incluye casos difíciles, idiomas, abstenciones y fallos raros de alto impacto.
El modelo de tiempo siguiente usa mediciones inventadas para esos mismos 200 casos. Compara trabajo equivalente; revisión, excepciones y soporte continuo también cuentan.
| Los mismos 200 casos | Minutos |
|---|---|
| Base: 200 × 6 | 1.200 |
| Revisión con IA: 200 × 3 | 600 |
| Gestión adicional de excepciones | 120 |
| Preparación/soporte asignados al piloto | 90 |
| Esfuerzo total con asistencia | 810 |
| Capacidad liberada neta | 390 (6,5 horas) |
Con valor laboral supuesto de 24/hora, 6,5 horas representan 156 de capacidad. Resta cargos supuestos de modelo/herramientas de 40: beneficio asignado 116 antes de otros costos. Son unidades didácticas sin moneda específica, no rentabilidad garantizada ni ahorro de efectivo; el salario puede mantenerse. Mide también plazos, errores verificados, incidentes de datos y resultados para clientes/proveedores. Cero incidentes en un piloto pequeño no demuestra riesgo cero.
La compradora recibe catorce propuestas revisables. La discrepancia caja/pieza es una excepción, no una orden enviada mientras todos duermen. Corrige la conversión de origen, vuelve a generar la propuesta afectada y comprueba el resultado. Mejorar el dato maestro reduce una clase de fallo; no demuestra que la próxima ejecución sea infalible.
Antes de elegir un producto, pide una demostración con tus permisos y casos difíciles. El recorrido de StoreConsole Intelligence permite examinarlo, no prueba que todos los conectores o flujos estén habilitados. Confirma borrador, aprobación, ejecución y recuperación reales en tu instalación.
Para IA que interactúa con clientes, planifica una divulgación clara y revisa las normas aplicables. El artículo 50 de la Ley de IA de la UE contiene obligaciones de transparencia en interacción directa con alcance y excepciones definidos; no es una regla universal para toda acción interna del ERP. Empleo, crédito y otras decisiones sensibles necesitan evaluación propia.
El resultado útil es concreto: menos búsquedas rutinarias y decisiones mejor preparadas, con evidencia comprobable y autoridad que la compradora sigue controlando.
Revisado el 5 de noviembre de 2026. Anichur Rahaman es el creador de StoreConsole. La escena de compras, los recuentos y los costos son ilustrativos.
Series
IA en la operación, 2026Sobre el autor
Anichur Rahaman
Seguir Leyendo
