Los controles de gasto de agentes son mecanismos de gobernanza que restringen y supervisan cómo los agentes de software (incluidos los agentes de IA) inician pagos. En sistemas como Oobit, estos controles suelen aplicarse a instrumentos de pago (por ejemplo, tarjetas corporativas o vinculadas a agentes) y se aplican en el momento de la autorización para reducir el fraude, evitar excesos presupuestarios y alinear la actividad de los agentes con las políticas organizativas. Los controles eficaces combinan reglas predefinidas (lo que un agente puede hacer) con visibilidad continua (lo que el agente realmente hizo).
Los límites definen fronteras cuantitativas para el gasto iniciado por agentes. Las configuraciones habituales incluyen topes por transacción, máximos diarios/semanales/mensuales, presupuestos de por vida para un proyecto específico y límites de velocidad que restringen el número de autorizaciones en una ventana de tiempo determinada. Los límites también pueden incorporar reglas contextuales, como restricciones de divisa, limitaciones geográficas y requisitos de aprobación adicional cuando un cargo supera un umbral. En infraestructuras de pago basadas en tarjetas, estos límites se evalúan durante la solicitud de autorización, lo que produce una aprobación o una denegación con un código de motivo que puede registrarse y auditarse.
Los controles por categoría restringen dónde puede gastar un agente mediante esquemas de clasificación de comercios como los Códigos de categoría de comercio (MCCs), que agrupan a los comercios por tipo de negocio (por ejemplo, viajes, bienes digitales o servicios en la nube). Las políticas por categoría pueden ser listas de permitidos (solo se permiten categorías específicas) o listas de bloqueados (se prohíben categorías específicas), y pueden combinarse con reglas a nivel de comercio que apunten a proveedores individuales. En la práctica, las organizaciones suelen combinar reglas por categoría con metadatos de “finalidad”, como centros de coste internos, identificadores de campaña o motivos de renovación de suscripción, para que la compra automatizada siga siendo atribuible y coherente con las políticas de compras.
Los registros en tiempo real proporcionan un historial de eventos de transacciones intentadas y completadas, incluidos marcas de tiempo, importes, identificadores de comercio, datos de categoría y el resultado de la decisión (aprobada o denegada), junto con la regla que activó la decisión. Estos registros respaldan la respuesta ante incidentes (por ejemplo, detectar rápidamente una ráfaga de denegaciones), el seguimiento presupuestario y las auditorías a posteriori. Las implementaciones maduras también registran eventos del ciclo de vida relacionados —cambios de límites, actualizaciones de políticas y movimientos de fondos— para que los revisores puedan reconstruir por qué un agente tenía la capacidad de gastar en un momento dado y si los controles se modificaron de manera adecuada.
Un plano de control típico separa la definición de políticas (límites, categorías y flujos de aprobación) de la aplicación y la observabilidad. La aplicación se produce en línea con la autorización del pago para que las transacciones prohibidas se denieguen antes de la liquidación; la observabilidad se mantiene mediante registros estructurados y consultables que se integran con herramientas financieras y de supervisión de seguridad. Los principales retos de diseño incluyen gestionar casos límite en la clasificación de comercios, garantizar un tratamiento coherente entre regiones y divisas, y evitar la deriva de políticas controlando estrictamente quién puede cambiar las reglas y cómo se revisan los cambios.