Comercio Agéntico: Cómo Dejar que los Agentes IA Compren de Forma Segura

Por qué esto importa ahora

Los agentes IA ya son buenos en conversaciones, recomendaciones y búsquedas. El siguiente paso es obvio: dejarlos completar transacciones. Un agente que puede verificar disponibilidad, comparar opciones y reservar entradas es más útil que uno que solo te muestra las opciones y te hace pasar por un formulario de checkout.

Pero en el momento en que un agente puede gastar dinero, todo cambia. Un agente de soporte al cliente que reserva el show equivocado. Un agente de viajes que reserva 50 asientos en vez de 5. Un asistente de compras que hace un pedido de un producto que el proveedor ya no tiene. No son escenarios hipotéticos. Son el resultado predecible de conectar un LLM a una API de checkout sin gobernanza.

Construimos un protocolo para esto. Lo llamamos el Agentic Checkout Protocol (ACP). Gobierna cómo los agentes IA inician, validan y completan transacciones comerciales dentro de una plataforma multi-tenant. Este artículo explica la arquitectura desde cero.

Para contexto sobre cómo abordamos los sistemas de IA agéntica y la arquitectura multi-agente, esas guías cubren los patrones generales. Este artículo se centra específicamente en el problema de las transacciones comerciales.

El problema central

Los flujos de checkout tradicionales asumen que un humano está tomando la decisión. El backend del comerciante llama a la API de checkout con una API key, el pedido se valida, el pago se captura. El humano es el responsable.

Con el comercio agéntico, el que llama es un agente IA. El agente opera dentro de un hilo de conversación, tiene acceso a herramientas y puede tomar acciones de forma autónoma. Esto introduce riesgos que el checkout tradicional no maneja:

La solución no es "no dejar que los agentes compren cosas." La solución es un protocolo que gobierne cada paso.

El Agentic Checkout Protocol

ACP compone cinco sistemas en un marco de confianza único:

┌─────────────────────────────────────────────────────────┐
│                   FLUJO ACP                              │
│                                                          │
│  Usuario: "Reserva El Rey León para 2 adultos el sábado"│
│                         │                                │
│                         ▼                                │
│  ┌─────────────────────────────────┐                    │
│  │  1. CAPA DE HERRAMIENTAS MCP   │                    │
│  │  El agente llama               │                    │
│  │  createCheckout()              │                    │
│  │  via Model Context Protocol    │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  2. MOTOR DE POLÍTICAS         │                    │
│  │  Verificar: ¿Este agente       │                    │
│  │  puede reservar con este       │                    │
│  │  proveedor?                    │                    │
│  │  ¿El valor está dentro de los  │                    │
│  │  límites?                      │                    │
│  │  Resultado: PERMITIR o DENEGAR │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│          PERMITIR│       DENEGAR ──▶ Error al agente     │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  3. PUERTA DE APROBACIÓN HITL  │                    │
│  │  Si valor del pedido >         │                    │
│  │  umbral:                       │                    │
│  │  Suspender workflow, notificar │                    │
│  │  al equipo de operaciones      │                    │
│  │  Esperar aprobación humana     │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│              APROBADO                                    │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  4. EJECUCIÓN DEL PROVEEDOR    │                    │
│  │  Reservar inventario           │                    │
│  │  Confirmar reserva con el      │                    │
│  │  proveedor                     │                    │
│  │  Generar recibo HMAC           │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  5. REGISTRO DE AUDITORÍA      │                    │
│  │  Escribir registro inmutable   │                    │
│  │  actor_type: "agent"           │                    │
│  │  thread_id, tenant_id, receipt │                    │
│  └─────────────────────────────────┘                    │
│                                                          │
└─────────────────────────────────────────────────────────┘

Cada componente tiene valor de forma independiente. Juntos, forman un marco de gobernanza completo para el comercio iniciado por IA.

Componente 1: Capa de Herramientas MCP

El agente no llama a las APIs directamente. Usa herramientas MCP (Model Context Protocol) que están registradas con el framework del agente. Cada herramienta es un punto de entrada controlado con validación de entrada, aplicación de políticas y registro de auditoría.

// Definición de herramienta MCP para crear un checkout
const createCheckoutTool = createTool({
    id: 'createCheckout',
    description: 'Create a checkout for a product booking',
    inputSchema: z.object({
        productId: z.string(),
        date: z.string().datetime(),
        persons: z.array(z.object({
            type: z.enum(['adult', 'child', 'senior']),
            count: z.number().int().positive(),
        })),
    }),
    execute: async ({ productId, date, persons }, ctx) => {
        // 1. Validar que el producto existe en el índice de búsqueda
        const product = await searchApi.getProduct(ctx.tenantId, productId);
        if (!product) throw new ToolError('Product not found');

        // 2. Verificar política
        const policy = await policyEngine.evaluate(
            ctx.tenantId, ctx.channelId, 'create_order',
            { productId, supplierId: product.supplierId, estimatedValue: product.price }
        );
        if (!policy.allowed) throw new ToolError(`Policy denied: ${policy.reason}`);

        // 3. Iniciar workflow de checkout
        return checkoutWorkflow.start({ productId, date, persons, ctx });
    },
});

La herramienta valida que el producto realmente existe (previene reservas alucinadas), verifica la política antes de cualquier acción financiera, y enruta a un workflow gobernado. El agente nunca tiene acceso directo a la API del proveedor.

Este patrón viene de cómo diseñamos los sistemas de flujos de trabajo IA. La herramienta es la frontera de confianza. Todo dentro de la herramienta está gobernado. Todo fuera es solo conversación.

Componente 2: Motor de Políticas

Antes de cualquier acción financiera, el motor de políticas evalúa reglas específicas del tenant. Las reglas se almacenan por tenant y se cachean con un TTL de 5 minutos.

interface PolicyRule {
    action: string;                    // "create_order", "cancel_order", "search"
    effect: "allow" | "deny";
    conditions: {
        max_order_value?: number;          // Tope máximo, rechazar por encima
        allowed_suppliers?: string[];      // Restringir qué proveedores
        require_human_approval_above?: number;  // Umbral HITL
        max_items_per_order?: number;      // Prevenir fraude en masa
    };
}

Reglas de evaluación

1. Las reglas de denegación tienen prioridad. Si alguna regla de denegación coincide, la acción se rechaza inmediatamente.
2. Reglas de permiso con condiciones. Si una regla de permiso coincide, sus condiciones se evalúan contra la solicitud.
3. Sin regla que coincida = denegado. Default-deny. Un agente no puede hacer nada que no esté explícitamente permitido.

Ejemplo de política

{
    "tenant_id": "tenant_acme",
    "rules": [
        {
            "action": "create_order",
            "effect": "allow",
            "conditions": {
                "max_order_value": 5000,
                "allowed_suppliers": ["supplier_alpha", "supplier_beta"],
                "require_human_approval_above": 500,
                "max_items_per_order": 10
            }
        },
        {
            "action": "cancel_order",
            "effect": "allow",
            "conditions": {}
        },
        {
            "action": "search",
            "effect": "allow",
            "conditions": {}
        }
    ]
}

Los agentes de este tenant pueden buscar libremente, crear pedidos de hasta 5.000 EUR (pero los pedidos superiores a 500 EUR necesitan aprobación humana), reservar solo con dos proveedores aprobados, y crear pedidos con un máximo de 10 artículos. Pueden cancelar pedidos sin restricciones. Cualquier otra cosa se deniega.

El motor de políticas tiene alcance por tenant. Diferentes comerciantes reciben diferentes reglas. Una gran empresa podría establecer el umbral HITL en 2.000 EUR. Un operador pequeño podría requerir aprobación para todo lo que supere 100 EUR. El operador de la plataforma establece las políticas por defecto, y los tenants pueden personalizar dentro de su rango permitido.

Componente 3: Puertas de Aprobación HITL

Cuando un pedido supera el umbral require_human_approval_above, el workflow de checkout se suspende y espera la aprobación humana.

// Dentro del workflow de checkout
async function checkoutWorkflow(ctx, params) {
    // Paso 1: Reservar inventario
    const reservation = await supplierAdapter.reserveInventory(
        ctx.tenantId, params.productId, params.date, params.persons
    );

    // Paso 2: Verificar si se necesita aprobación humana
    if (reservation.totalPrice > policy.require_human_approval_above) {
        // Suspender workflow, notificar al dashboard de operaciones
        const approval = await workflow.suspend({
            reason: 'Order exceeds approval threshold',
            totalPrice: reservation.totalPrice,
            threshold: policy.require_human_approval_above,
            productName: reservation.productName,
            reservationExpiresAt: reservation.expiresAt,
        });

        if (!approval.approved) {
            await supplierAdapter.cancelReservation(reservation.id);
            return { status: 'REJECTED', reason: approval.rejectionReason };
        }
    }

    // Paso 3: Confirmar reserva
    const booking = await supplierAdapter.confirmBooking(reservation);

    // Paso 4: Generar recibo
    const receipt = generateHmacReceipt(booking, ctx.tenantId);

    // Paso 5: Registro de auditoría
    await auditLog.write({
        action: 'order_completed',
        actor_type: 'agent',
        thread_id: ctx.threadId,
        tenant_id: ctx.tenantId,
        order_id: booking.orderId,
        receipt_hmac: receipt.hmac,
    });

    return { status: 'COMPLETED', orderId: booking.orderId, receiptHmac: receipt.hmac };
}

El workflow usa suspend() y resume() del framework del agente. Cuando está suspendido, el dashboard de operaciones muestra el pedido pendiente con todos los detalles. Un operador puede aprobar o rechazar con un motivo. El workflow se reanuda automáticamente cuando se toma la decisión.

La reserva tiene un tiempo de expiración. Si el humano no aprueba antes de que la reserva expire, el sistema cancela automáticamente la reserva e informa al agente. El agente puede entonces decirle al usuario que la ventana de reserva se ha cerrado.

Para más información sobre la supervisión humana en sistemas de IA, consulta nuestra guía sobre IA con humano en el bucle.

Componente 4: Recibos HMAC

Cada pedido completado genera un recibo a prueba de manipulaciones usando HMAC-SHA256. Esto proporciona prueba criptográfica de lo que ocurrió.

Especificación del recibo

Payload del recibo

interface ReceiptPayload {
    order_id: string;
    tenant_id: string;
    products: Array<{
        id: string;
        date: string;
        total_price: number;
    }>;
    total_price: number;
    currency: string;
    booker_email: string;
    created_at: string;  // ISO 8601
}

Firma

function generateHmacReceipt(order: Order, tenantId: string): Receipt {
    const payload: ReceiptPayload = {
        order_id: order.id,
        tenant_id: tenantId,
        products: order.items.map(item => ({
            id: item.productId,
            date: item.date,
            total_price: item.totalPrice,
        })),
        total_price: order.totalPrice,
        currency: order.currency,
        booker_email: order.bookerEmail,
        created_at: order.createdAt.toISOString(),
    };

    // JSON canónico: claves ordenadas para salida determinista
    const canonical = JSON.stringify(payload, Object.keys(payload).sort());
    const secret = await secretsManager.getTenantSecret(tenantId);
    const hmac = crypto.createHmac('sha256', secret).update(canonical).digest('hex');

    return { payload, hmac, signedAt: new Date().toISOString() };
}

Verificación

GET /v1/order/{orderId}/verify
Response: { valid: true, signed_at: "2026-06-15T14:30:00Z" }

El endpoint de verificación recalcula el HMAC a partir de los datos del pedido almacenados usando el secreto del tenant y lo compara con el recibo almacenado. Una discrepancia significa que los datos del pedido fueron manipulados después de la firma. Esto da a los comerciantes, auditores y reguladores evidencia verificable de que un agente específico, actuando dentro de un alcance de tenant específico, creó un pedido específico en un momento específico.

Componente 5: Pista de Auditoría Inmutable

Cada acción ACP genera una entrada de auditoría. El sistema de auditoría usa una arquitectura de dos niveles:

Nivel 1: Log operacional (base de datos, consultable, retención de 90 días)

{
    action: 'order_completed',
    actor_type: 'agent',           // "agent" | "human" | "system"
    thread_id: 'thread_abc123',    // qué conversación
    tenant_id: 'tenant_acme',
    channel_id: 'ch_web_en',
    order_id: 'ord_xyz789',
    total_price: 450,
    currency: 'EUR',
    supplier_id: 'supplier_alpha',
    receipt_hmac: 'a1b2c3...',
    policy_evaluated: true,
    hitl_required: false,
    created_at: '2026-06-15T14:30:00Z',
}

Nivel 2: Archivo inmutable (almacenamiento de objetos con escritura-única/lectura-múltiple, retención de 7 años)

El log operacional se transmite al almacenamiento de objetos con bloqueos de objeto (modo compliance). Una vez escritas, las entradas no pueden ser modificadas ni eliminadas durante el período de retención. Esto satisface los requisitos regulatorios para registros de transacciones financieras.

Cada entrada de auditoría incluye actor_type y thread_id. Esto hace posible rastrear exactamente qué agente IA, en qué conversación, inició qué acción financiera. Combinado con el recibo HMAC, la pista de auditoría proporciona prueba de extremo a extremo de la cadena de decisiones.

Para cómo construimos sistemas de auditoría y observabilidad de forma más amplia, consulta nuestras guías sobre gobernanza de IA y observabilidad de IA.

ACP vs Checkout Tradicional

Idempotencia

Las transacciones iniciadas por agentes necesitan idempotencia a nivel de protocolo. Los reintentos de red, los reintentos del agente y las repeticiones del workflow no deben crear pedidos duplicados.

// Clave de idempotencia para checkouts iniciados por agentes
const idempotencyKey = `${tenantId}:${threadId}:${productId}:${date}`;

// Verificar antes de procesar
const existing = await idempotencyStore.get(idempotencyKey);
if (existing) {
    return existing.result;  // Devolver resultado cacheado
}

// Procesar y almacenar
await idempotencyStore.acquire(idempotencyKey);
const result = await processCheckout(params);
await idempotencyStore.complete(idempotencyKey, result);
return result;

La clave de idempotencia combina tenant, hilo de conversación, producto y fecha. El mismo agente en la misma conversación reservando el mismo producto en la misma fecha siempre devuelve el mismo resultado. Un hilo de conversación diferente obtiene una clave nueva.

El store usa escrituras condicionales para prevenir condiciones de carrera. Si dos workers intentan adquirir la misma clave simultáneamente, solo uno tiene éxito.

Aislamiento por Tenant

Cada operación ACP tiene alcance por tenant y canal. La jerarquía de identidad asegura el aislamiento de datos en cada capa:

Tenant (organización del comerciante)
  └── Canal (tienda o canal de ventas)
       └── Cliente (usuario final)
            └── Sesión (sesión de navegador/dispositivo)
                 └── Hilo del Agente (conversación individual)

El hilo del agente hereda su contexto de tenant y canal de la sesión autenticada. Cada llamada a herramienta, cada evaluación de política, cada entrada de auditoría lleva estos identificadores. El acceso a datos entre tenants es arquitectónicamente imposible porque cada consulta incluye el alcance del tenant como filtro obligatorio.

Este es el mismo patrón de aislamiento multi-tenant que describimos en nuestra guía de arquitectura de sistemas. La diferencia en ACP es que el agente añade otro nivel de alcance: el hilo. La memoria y el contexto de un agente tienen alcance tenant_id + session_id + thread_id. El agente A en un tenant no puede ver la conversación del agente B en otro tenant.

Qué puede salir mal

Incluso con ACP, hay modos de fallo que manejar:

Consideraciones de implementación

Cuándo introducir ACP

No toda integración de comercio con IA necesita el protocolo completo. Considera el nivel de autonomía:

Empieza con solo búsqueda. Añade la construcción de carrito cuando la confianza esté establecida. Pasa al checkout asistido con HITL en cada pedido. Gradúa al checkout autónomo con umbrales HITL basados en políticas solo después de que tengas datos sobre la precisión del agente y la tasa de error sea aceptable.

Opciones tecnológicas

ACP es a nivel de protocolo, no de implementación específica. Los componentes se pueden construir con diferentes tecnologías:

El diseño del protocolo importa más que las herramientas específicas. Si implementas los cinco componentes (gobernanza de herramientas, evaluación de políticas, puertas de aprobación humana, recibos a prueba de manipulaciones y auditoría inmutable), el sistema es seguro independientemente de la tecnología subyacente.

Para nuestra perspectiva más amplia sobre arquitectura de sistemas de IA y cómo abordamos las consultoría, esas páginas proporcionan más contexto.

Errores comunes

1. Dejar que los agentes llamen a las APIs de proveedores directamente. La capa de herramientas MCP es la frontera de confianza. Sin ella, no tienes aplicación de políticas, ni pista de auditoría, ni idempotencia.

2. Política default-allow. ACP usa default-deny. Si no existe una regla de permiso explícita para una acción, se rechaza. Default-allow con overrides de denegación es más débil porque tienes que anticipar cada mala acción por adelantado.

3. Saltarse los recibos HMAC. Sin recibos a prueba de manipulaciones, no puedes demostrar a un comerciante o regulador que un pedido no fue modificado después de su creación.

4. Mismo formato de clave de idempotencia para todas las operaciones. La clave debe incluir contexto (hilo, producto, fecha). Una clave global como order:123 no impide que un agente diferente en una conversación diferente reserve el mismo producto.

5. Sin expiración de reserva. Si la aprobación HITL tarda indefinidamente, la reserva retiene inventario sin fin. Siempre establece una expiración y maneja el caso de timeout.

6. Confiar en los datos de producto proporcionados por el agente. La herramienta debe validar que el producto existe en el índice de búsqueda. El agente podría alucinar un ID de producto, un precio o una fecha de disponibilidad.

7. No aislar la memoria del agente por tenant. Un agente que sirve al tenant A no debe tener acceso al historial de conversaciones, catálogo de productos o reglas de políticas del tenant B.

8. Tratar el checkout agéntico como una funcionalidad, no como un protocolo. ACP no es una funcionalidad que atornillas después. Es un marco de confianza que debe diseñarse en el sistema desde el principio.

Conclusiones clave

• Los agentes no pueden "simplemente reservar cosas." Cada transacción financiera iniciada por un agente necesita evaluación de políticas, aprobación humana opcional, recibos a prueba de manipulaciones y una pista de auditoría inmutable. Esto no es opcional para comercio en producción.

• La herramienta MCP es la frontera de confianza. El agente nunca tiene acceso directo a la API. Cada acción pasa por una herramienta gobernada que valida, verifica políticas y registra.

• La política default-deny es innegociable. Si no existe una regla de permiso explícita, la acción se rechaza. Las reglas de denegación siempre tienen prioridad sobre las de permiso.

• Las puertas HITL son configurables, no binarias. Los pedidos pequeños pasan automáticamente. Los grandes esperan aprobación humana. El umbral es por tenant, por acción.

• Los recibos HMAC demuestran qué ocurrió. Claves de firma por tenant, serialización JSON canónica, HMAC-SHA256 codificado en hexadecimal. Verificable por cualquier parte con el secreto.

• La idempotencia previene pedidos duplicados. La clave debe incluir contexto de la conversación (thread ID), no solo los datos del pedido.

• Empieza con búsqueda, gradúa a checkout. No le des a los agentes poder de compra autónomo desde el día uno. Construye confianza de forma incremental con datos sobre precisión y tasas de error.

El comercio agéntico es inevitable. La pregunta es si construyes la gobernanza primero o limpias los daños después. Construimos ACP porque lo necesitábamos para una plataforma de comercio multi-tenant real con múltiples proveedores y agentes de reserva impulsados por IA. El protocolo funciona. La arquitectura está probada en producción.

Si estás construyendo comercio impulsado por IA y necesitas ayuda para diseñar la capa de gobernanza, habla con nuestro equipo o solicita un presupuesto. También puedes explorar nuestros servicios de IA y nuestra práctica de arquitectura ecommerce para más contexto.