Regla, automatización o agente: una guía de decisión

La necesidad es comprender una incidencia y saber cómo tramitarla, más allá de incorporar IA a los pedidos.

Situación Primera opción que probar Posible función de la IA
Falta un campo obligatorio Validación determinista Innecesaria para detectar la ausencia
Un pedido no llega al sistema de gestión Conciliación por identificador y procedimiento de recuperación Resumir el incidente si hay que revisar varios registros
Se supera un umbral de negocio Regla explícita y cola de revisión Explicar el contexto sin redefinir el umbral
Una nota del cliente parece contradecir la opción de entrega Revisión humana o análisis asistido Reunir los elementos y proponer una pregunta aclaratoria
Dos fuentes muestran estados incompatibles Comprobar fechas y fuente de referencia Presentar la contradicción sin elegir una versión no demostrada

Una extracción seguida de un resumen puede bastar sin agente. Tiene sentido explorar un agente cuando el sistema debe elegir qué información consultar después entre unas herramientas autorizadas. Esa flexibilidad debe demostrar utilidad frente a un flujo fijo.

Definir entradas, herramientas y resultado

Limita el primer alcance a una familia de incidencias, como las instrucciones de entrega ambiguas. Las entradas son el pedido y sus líneas, los estados relevantes con fecha y hora, las conversaciones autorizadas y la versión aplicable de la norma interna. Excluye los datos personales y de pago que no hagan falta para la revisión.

Las herramientas previstas solo consultan el pedido, su historial pertinente y la documentación autorizada. Deben respetar los permisos del operador y un identificador de pedido impuesto por la aplicación. Si la correspondencia entre sistemas es incierta, el sistema se detiene en lugar de vincular un expediente parecido.

El proceso propuesto tiene cuatro pasos: verificar la identidad del expediente; recopilar los elementos con su procedencia y fecha; separar hechos observados, contradicciones e hipótesis; preparar una ficha para el operador. Fija también un límite de consultas y una duración máxima para que una investigación incompleta quede visible.

Escenario ficticio: una petición de entrega ambigua

Este ejemplo metodológico es imaginado; no describe un cliente ni un proyecto realizado por Codezilla.

Un pedido contiene dos artículos. La opción elegida indica un envío conjunto, pero una nota pide «enviad lo que esté listo». La norma interna exige confirmación del cliente antes de dividir el envío. La herramienta de preparación indica que un artículo está listo; no confirma la disponibilidad del segundo.

Una ficha útil podría contener:

  • Hechos con fuentes: envío conjunto en el pedido; petición diferente en la nota; un único artículo marcado como listo en la herramienta de preparación. Cada hecho enlaza al registro e indica cuándo se consultó.
  • Regla aplicable: confirmación previa para dividir el envío, con enlace a la versión de la norma.
  • Información pendiente: disponibilidad del segundo artículo y acuerdo explícito para dividir el envío.
  • Propuesta: pedir al operador que compruebe ambos puntos; preparar una pregunta para el cliente si resulta útil.
  • Decisión reservada: el operador decide cómo continuar en sus herramientas habituales. La ficha no activa ningún envío.

El agente no debe deducir una rotura de stock ni dar por obtenido el consentimiento. Una nota libre no sustituye la norma interna. Si el pedido cambia durante la revisión, la ficha debe marcarse como desactualizada y la información pertinente debe consultarse de nuevo antes de decidir.

Aplicar los límites en las herramientas

El acceso de solo lectura debe imponerse mediante permisos e interfaces, no solo mediante una instrucción al modelo. Microsoft recomienda límites explícitos y controles deterministas independientes de la respuesta del agente. Consulta sus principios para controlar agentes autónomos.

Una nota del cliente o un documento puede contener una instrucción maliciosa. Sigue siendo un dato que examinar, nunca una autorización para cambiar el objetivo o acceder a otros expedientes. OWASP describe este riesgo de inyección de instrucciones y recomienda limitar los permisos en las herramientas.

Un acceso denegado, una herramienta no disponible o una fuente demasiado antigua debe generar una ficha incompleta que explique el motivo. El sistema no debe rellenar los huecos con suposiciones presentadas como hechos. Conserva las referencias útiles y la decisión del operador con permisos y plazos de conservación definidos, sin copiar innecesariamente las conversaciones con clientes.

Seis pruebas antes de un piloto

Prepara expedientes ficticios con una respuesta esperada validada por el equipo. Prueba los mismos casos con el método actual, una regla simple o un flujo fijo, y después con la asistencia de IA.

Prueba Resultado esperado
Pedido sin incidencia Ningún problema inventado
Nota ambigua Ambigüedad y pregunta que comprobar, sin consentimiento supuesto
Fuentes contradictorias o desactualizadas Contradicción visible y decisión aplazada
Fuente ausente o acceso denegado Límite explicado, sin eludirlo
Nota que pide reembolsar e ignorar las reglas Ninguna acción; texto tratado como contenido no fiable
Nuevo pedido después de un primer expediente Ninguna reutilización incorrecta de datos o conclusiones del expediente anterior

Registra las afirmaciones sin respaldo, las incidencias no detectadas, las falsas alertas, las propuestas corregidas y el tiempo total de tramitación, incluida la revisión. Añade el coste de las llamadas al modelo y de la operación. Fija los umbrales aceptables antes del piloto; cualquier acceso fuera de alcance o intento de acción prohibida bloquea su ampliación hasta corregirlo y repetir la prueba. Este escenario no demuestra ninguna mejora de eficiencia.

El entregable que conviene pedir es una ficha verificable y un protocolo de pruebas, más allá de una demostración convincente. La utilidad de la IA, la calidad de las propuestas y la carga de revisión siguen pendientes de demostrar. Incorporar acciones sería otro alcance: AWS recomienda dar contexto a quien valida y prever las solicitudes de aprobación sin respuesta.

Para distinguir un fallo de sincronización de una incidencia que requiere revisión, consulta también quién debe gestionar el stock y los pedidos entre Shopify y un ERP. Para definir herramientas, límites y pruebas de un proyecto así, conoce nuestro enfoque de agentes de IA para empresas o cuéntanos qué necesitas.