Un ejemplo de reembolsos explica aprobación exacta, límites compartidos, protección contra duplicados y conciliación del resultado.
Autor
Anichur Rahaman
Parte 3 de 3
IA en la operación, 2026Durante la noche se ejecutaron 37 reembolsos por 8.400. Todos estaban por debajo del límite de 300 por acción del asistente. Nadie fijó un límite conjunto. Es un fallo ficticio, con importes en una misma moneda sin especificar, pero muestra una brecha común: comprobar una solicitud no controla toda la ejecución.
Finanzas necesita saber qué ocurrió y detener nueva exposición, sin dejar de atender a tiempo los casos legítimos. «Dile al modelo que tenga cuidado» no basta. Permisos, aprobaciones y reglas transaccionales deben funcionar aunque el asistente malinterprete un mensaje.
Cerramos la serie: la parte 1 elige el trabajo del agente y la parte 2 sigue una conexión MCP. Ahora sometemos una propuesta a un proceso comprobable.
Para cada tarea, define responsable, registros/campos permitidos, operación, impacto financiero o en clientes y recuperación. Un agente interactivo respeta la intersección de derechos del usuario, alcance delegado y política vigente. Un servicio desatendido necesita identidad limitada, responsable y revisión. Ninguno usa un administrador compartido.
Los controles viven en la aplicación y servicios posteriores. Ocultar menús o pedir obediencia al modelo no basta. Comprueba acceso en llamadas, contexto recuperado, cachés, salidas y logs. Notas internas y mensajes externos pueden contener instrucciones hostiles; ninguno concede autoridad nueva.
Fija límites según pérdidas plausibles y obligaciones legales/comerciales, no copiando números bonitos de un blog. Incluye importe individual y acumulado, cantidad, concurrencia, exportación, duración y gasto del modelo. La reversibilidad técnica es solo un factor: cancelar una reserva después no recupera una venta perdida.
En este ejemplo el agente prepara una propuesta de reembolso, sin liberar dinero. Una persona autorizada de finanzas ve pago original, saldo elegible, moneda, remedio, destino, motivo, evidencia y cambio. Se aplica la separación de funciones exigida; otro agente no aporta la aprobación humana requerida.
Vincula la aprobación a acción, objetivo, importe, moneda, destino y versión exactos, con condiciones de vigencia. Un cambio relevante la invalida. Al ejecutar, revisa de nuevo acceso, elegibilidad, saldo reembolsable y política, incluidos otros reembolsos pendientes. Otro borrador no puede reutilizarla.
Previsualizaciones y simulaciones ayudan, pero no son resultados de pago ni bloquean el estado futuro. Muestra evidencia accesible al revisor e incertidumbre pendiente. Asigna responsables, plazos, escalamiento y personal a la cola. El límite debe derivar un reembolso debido a atención autorizada rápida, no negar derechos en silencio.
Observa calidad de revisión, exactitud muestreada y demora. Mucha aceptación no prueba buen juicio; cero rechazos tampoco demuestra por sí solo aprobación mecánica. Reduce aprobaciones innecesarias si la política lo permite, pero no sustituyas una exigida por un muestreo posterior.
Supón un tope ilustrativo de 500 para un período y moneda declarados. La exposición comprometida o reservada es 340. Dos propuestas aprobadas por separado, A y B, solicitan 100 cada una. Si ambas leen «quedan 160» antes de actualizar, podrían pasar y elevar la exposición a 540.
El sistema debe comprobar y reservar el cupo de forma atómica. Si A reserva primero, la exposición sube a 440 y quedan 60; B llevaría a 540, supera el tope y pasa a una cola de excepción autorizada. Tener aprobación no anula esa regla de ejecución.
Define qué operaciones confirmadas, en curso e inciertas cuentan, período/zona horaria, conversión de moneda si procede y quién cambia límites. Mantén reservada la exposición incierta hasta conciliarla; libera solo tras fallo/cancelación verificados según política. Reintentar A reutiliza su reserva, sin consumir otros 100. Un límite de frecuencia no implementa por sí solo este tope financiero.
El proveedor puede aceptar el reembolso antes de perderse la respuesta. Guarda la referencia y consulta el resultado existente antes de crear otra petición. Concilia estado, importe y registro local; enviado, pendiente, exitoso, fallido o desconocido son resultados distintos.
Una clave de idempotencia identifica reintentos de una operación lógica con la misma carga prevista. Necesita seguimiento local duradero, protección atómica y soporte correcto del proveedor. No detecta la misma solicitud comercial enviada con otra clave; la retención del proveedor no siempre es permanente. La documentación de Stripe es un ejemplo, no contrato universal.
Reintenta solo fallos transitorios aptos, con backoff exponencial limitado, jitter, presupuesto de intentos/tiempo y responsable del estado incierto. Denegaciones, entradas inválidas y propuestas modificadas necesitan corrección o aprobación nueva. No inventes otra referencia porque la respuesta tarde.
Un reembolso completado no tiene deshacer de un clic. Cancelar depende del proveedor, método y estado; revertir un asiento no recupera dinero del cliente. La guía de reembolsos de Stripe explica casos limitados. Un reembolso erróneo completado necesita resolución autorizada, no un nuevo cargo sin permiso.
Registra solicitante e identidad actuante, alcance, fuentes/fechas, propuesta/versión, decisión, aprobador, operación, referencia del proveedor, transiciones y correcciones. Cuando existan, guarda versiones de modelo, herramienta, prompt y política; un alias del modelo no siempre reproduce una respuesta antigua. Pide explicación breve con evidencia, no razonamiento interno oculto.
Crea registro del intento antes de ejecutar y añade resultados confirmados, incluidos rechazos y fallos. Diseña qué sucede si la auditoría no está disponible antes de una acción importante. Impide ediciones no autorizadas, audita cambios privilegiados y prueba controles de integridad/retención requeridos. La etiqueta append-only no prueba que nadie pueda alterar almacenamiento.
Limita lectura/exportación, oculta datos sensibles y acuerda retención/borrado. Referencias con evidencia necesaria pueden ser más seguras que copiar mensajes completos. Más logs no siempre es mejor. Más intentos bloqueados pueden ser pruebas o mala configuración, no necesariamente clientes maliciosos.
El interruptor de parada impide trabajo nuevo en un alcance definido; no recupera una operación bancaria aceptada. Prueba detener, vaciar o cancelar colas, revocar accesos e identificar resultados en curso. Un circuit breaker necesita señales explícitas, responsable y recuperación controlada; la alerta no se investiga sola.
Incluye casos representativos y adversos: ID de otra tienda, instrucción en archivo, aprobación vencida, destino cambiado, presupuestos concurrentes, duplicados, timeout y auditoría inaccesible. Usa datos sintéticos o protegidos autorizados. Superar una prueba de inyección no demuestra inmunidad.
Compara permisos y resultados esperados, no solo lenguaje fluido. Incluye idiomas, reembolsos parciales, abstención, falsos bloqueos y plazos. Ajusta muestras al riesgo y rareza; «50 casos» no es estándar universal. Repite tras cambios de modelo, herramienta, prompt, política o datos relevantes. Una media mejor no debe ocultar regresión crítica.
Empieza con un equipo, revisores definidos y parada/recuperación probadas. Mide errores verificados, revelaciones no autorizadas, estados inciertos, tiempos, exposición acumulada y costo total. Mantén alternativa humana si falla el proveedor. Volver de versión restaura comportamiento donde sea posible; compensar una acción comercial es otra decisión.
El NIST AI RMF es referencia voluntaria. ISO/IEC 42001 trata un sistema organizativo de gestión de IA. Citar un marco o una insignia no demuestra seguridad de cada respuesta; examina alcance y evidencia.
Las obligaciones dependen del uso, jurisdicción y rol. El artículo 50 de la Ley de IA europea contiene transparencia y excepciones definidas; empleo y crédito requieren clasificación propia. No supongas idéntica obligación legal de log/divulgación para toda acción del ERP. Consulta el texto vigente antes de depender de una fecha.
La política siguiente es estructura inicial, no autoridad legal o de gasto lista para usar. Finanzas, operaciones y seguridad deben acordar límites, revisores, plazos y recuperación reales.
| Tarea | Antes de ejecutar | Responsabilidad de recuperación |
|---|---|---|
| Respuesta de stock | Registros/campos permitidos y fecha | Corregir respuesta; investigar revelación si ocurrió |
| Borrador de compra | Sin envíos/reservas ocultos; revisión de versión exacta | Retirar según política; gestionar efectos reales |
| Propuesta de reembolso | Elegibilidad, aprobación y límites compartidos | Finanzas concilia al proveedor; sin deshacer supuesto |
| Etiqueta o reserva interna | Evaluar efectos, alcance, volumen y reversión permitida | El responsable confirma recuperación, sin promesa de un clic |
| Nómina, banco o corrección contable | Proceso aprobado separado; sin autoridad abierta del agente | Responsable identificado y corrección controlada |
El objetivo es una cola explicable: qué se propuso, aprobó, retuvo, ejecutó o quedó incierto; exposición restante y responsable de cada paso. El tope puede retener B mientras se concilia A. Depende de controles bien implementados y probados, no de garantizar que mensajes parecidos activen una alarma.
El agente sigue preparando trabajo útil. La empresa conserva una forma acotada de aprobarlo, observar lo que pasó y atender excepciones sin perder al cliente ni la evidencia.
Revisado el 5 de noviembre de 2026. Anichur Rahaman es el creador de StoreConsole. Empresa, importes y cupos son escenarios didácticos ficticios.
Series
IA en la operación, 2026Sobre el autor
Anichur Rahaman
Seguir Leyendo
