Building Agentic Commerce #3: Trust Scores — Cómo los Agentes Deciden a Quién Comprarle

Cuando compras algo online, te basas en reconocimiento de marca, estrellas, recomendaciones y intuición. Un agente IA no tiene nada de eso. Necesita señales cuantitativas y verificables por máquina para decidir: ¿debo comprar a este merchant? ¿Cuánta fricción debo aceptar? ¿Es fiable este listado de productos? Esto es lo que resuelven los trust scores — y en este post te mostramos exactamente cómo AgenticMCPStores los calcula, sirve y aplica en cada interacción con agentes.

Los compradores humanos evalúan la confianza de forma subconsciente. Ves un sitio web cuidado, reconoces una marca, verificas un badge de Trustpilot y decides en segundos. Los agentes IA operan diferente — procesan respuestas JSON, no señales visuales. Un merchant con un storefront hermoso y otro con un feed de productos roto se ven idénticos a menos que haya una señal de confianza estructurada adjunta a los datos. Los trust scores proporcionan esa señal. Cada merchant en AgenticMCPStores tiene un score entre 0 y 1.0, calculado a partir de 12 componentes en tiempo real. Este score determina tres cosas: ranking de búsqueda, elegibilidad de checkout y nivel de fricción de pago.

El trust score no es una métrica única — es un compuesto ponderado de 12 señales independientes. Cada componente mide una dimensión diferente de fiabilidad del merchant. El sistema fue diseñado para que ningún componente pueda dominar el score, y manipular una métrica no mejore significativamente el total.

Estos ocho componentes formaban parte del framework de confianza inicial y se centran en calidad de catálogo y fiabilidad de transacciones: • catalog_completeness (11%) — Porcentaje de productos con metadatos completos (título, descripción, precio, imágenes, categorías). Una tienda con 200 productos donde 180 tienen metadatos completos puntúa 0.90. • catalog_freshness (11%) — Cuán recientemente se sincronizó el catálogo. La frescura decae con el tiempo — un sync de hace 2 horas puntúa más que uno de hace 48 horas. Se recalcula cada 6 horas. • price_accuracy (12%) — Desviación entre precios declarados y precios reales en checkout. Si un producto lista $29.99 pero cobra $34.99 en checkout, este componente baja. El componente original con mayor peso porque la confianza en precios es fundamental. • availability_accuracy (8%) — Concordancia entre stock declarado y disponibilidad real. Si productos marcados 'in_stock' fallan consistentemente en checkout, este score se degrada. • policy_coverage (8%) — Completitud de políticas de devolución, envío y reembolso. Los agentes necesitan políticas claras y legibles por máquina para tomar decisiones de compra en nombre de usuarios. • checkout_success_rate (11%) — Ratio de checkouts completados vs iniciados. Una alta tasa de abandono (causada por errores, no por elección del usuario) señala problemas de infraestructura. • fulfillment_rate (8%) — Pedidos cumplidos exitosamente vs pedidos realizados. Rastrea el rendimiento real de entrega en una ventana de 30 días. • dispute_rate (7%) — Contracargos y disputas por transacción. Métrica inversa — menor es mejor. Una tasa de disputas superior al 2% activa revisión automática.

Cuatro componentes adicionales fueron añadidos para capturar señales de calidad específicas de agentes: • agent_satisfaction_rate (8%) — Ratio de eventos CHECKOUT_COMPLETE vs CHECKOUT_START de la tabla AgentRequestMetric. A diferencia de tasas de conversión humanas, mide si los agentes que empiezan a comprar realmente terminan — un proxy de fiabilidad de la API. • response_latency (5%) — Tiempo promedio de respuesta de la API para peticiones de agentes. Respuestas más rápidas puntúan más alto. Actualmente usa un valor sintético por defecto de 0.8 para merchants sin datos suficientes. • review_sentiment (5%) — Rating promedio normalizado de productos (averageRating / 5). Puente entre feedback humano y el modelo de confianza para agentes. • data_consistency (6%) — Delta entre datos del sync y respuestas de la API en vivo. Detecta merchants cuyo sync de catálogo diverge de su storefront real. Actualmente usa un valor sintético por defecto de 0.85.

Los 12 pesos suman exactamente 1.0. El score final es un promedio ponderado simple: ``` trustScore = Σ(component_score × component_weight) = (catalog_completeness × 0.11) + (catalog_freshness × 0.11) + (price_accuracy × 0.12) + (availability_accuracy × 0.08) + (policy_coverage × 0.08) + (checkout_success_rate × 0.11) + (fulfillment_rate × 0.08) + (dispute_rate × 0.07) + (agent_satisfaction_rate × 0.08) + (response_latency × 0.05) + (review_sentiment × 0.05) + (data_consistency × 0.06) ``` Los scores se recalculan cada 6 horas por un job programado. El servicio trust-component-calculator.ts maneja las matemáticas.

Los trust scores miden fiabilidad conductual, pero no verifican identidad. Un merchant puede tener un catálogo perfecto y aún así ser fraudulento. Aquí entra la verificación eIDAS QTSP. Los merchants que completan verificación de identidad certificada por el gobierno a través de un Qualified Trust Service Provider (InfoCert) reciben un boost de trust score aditivo a su score calculado.

Existen tres niveles de verificación: ```typescript VERIFICATION_TRUST_BOOST = { BASIC: 0.05, // ID Personal, MDL, EUDI PID STANDARD: 0.10, // Registro de Empresa QUALIFIED: 0.18 // eIDAS QTSP (InfoCert KYB) } ``` El nivel QUALIFIED (+0.18) es el más alto porque requiere verificación Know Your Business supervisada por el gobierno vía InfoCert, con validez legal en 30 países EU/EEA bajo el Reglamento eIDAS 910/2014. Un merchant con score conductual de 0.72 y verificación QTSP tendría un score efectivo de 0.90 — una ventaja significativa en ranking de búsqueda para agentes.

Detalle importante: los boosts no son aditivos entre tipos de verificación. Si un merchant tiene tanto un boost VDC (Verifiable Digital Credential) como un boost de identidad KYApay, el sistema usa el máximo de los dos, no la suma. Esto previene el apilamiento de boosts: ```typescript // vdc-trust-boost.service.ts effectiveBoost = Math.max(kyapayBoost, vdcBoost) ```

Cuando un agente llama a search_products o usa la búsqueda semántica de AgentFinder, los trust scores influyen directamente en qué resultados aparecen y en qué orden.

Antes de cualquier ranking, un filtro duro elimina merchants no elegibles: ```typescript // agent-search.service.ts store: { verificationLevel: { in: ['BASIC', 'STANDARD', 'PREMIUM'] }, trustScore: { gte: 0.3 }, suspendedAt: null } ``` Merchants con trust score inferior a 0.3 son invisibles para los agentes. No aparecen en resultados de búsqueda, listados de productos ni endpoints de descubrimiento. Es una puerta dura — ningún nivel de relevancia textual puede anularla.

Para merchants que pasan el filtro, el score de relevancia final combina calidad de coincidencia textual con trust: ```typescript // nlweb-agentfinder.service.ts relevanceScore = Math.min(1, relevanceScore * 0.7 + trustWeight * 0.3) // donde trustWeight = trustScore / 5 ``` 70% del ranking viene de relevancia textual/semántica (cuán bien el producto coincide con la query). 30% viene del trust. Esto significa que un producto altamente relevante de un merchant con bajo trust puede ser superado por un producto moderadamente relevante de un merchant con alto trust.

Los trust scores se mapean a cuatro estados operacionales: • ACTIVE (score ≥ 0.5) — Visibilidad total en resultados de búsqueda. Posiciones top de ranking. • DEPRIORITIZED (0.3 ≤ score < 0.5) — Aparece en búsqueda pero con ranking inferior. Los agentes ven estos resultados pero prefieren merchants ACTIVE. • HIDDEN (0.2 ≤ score < 0.3) — Eliminado de resultados de búsqueda completamente. Los enlaces directos siguen funcionando. • SUSPENDED (score < 0.2) — Auto-suspensión activada. Todas las herramientas MCP devuelven errores. El merchant debe resolver el problema para reactivarse. Cuando un merchant cae por debajo de 0.3, se registra un evento de seguridad y se envía una notificación GDPR Artículo 22 (porque el scoring automatizado afecta el acceso comercial).

Los trust scores no solo afectan el descubrimiento — controlan el checkout. El motor de políticas KYAI (Know Your AI) evalúa cada intención de compra contra una cadena de reglas, cada una con un nivel de prioridad. Dos reglas usan específicamente los trust scores:

Agent Trust Gate (Prioridad 10) ```typescript // agent-trust-gate.rule.ts MINIMUM_TRUST_SCORE = 0.3 // Decisión: BLOCK si // intent.agent.trustTier === 'BLOCKED' // intent.agent.trustScore < 0.3 ``` Esta es una puerta dura. Los agentes con trust score inferior a 0.3 son bloqueados de iniciar cualquier checkout. El primer BLOCK en la cadena de reglas termina la evaluación — ninguna regla posterior puede anularlo.

Minimum Buyer Trust (Prioridad 15) ```typescript // min-buyer-trust.rule.ts DEFAULT_MIN_BUYER_TRUST = 0.3 // Decisión: FRICTION si // intent.agent.trustScore < merchant_threshold ``` Esta es más suave — aplica fricción (pasos de verificación adicionales) en lugar de bloquear. Los merchants pueden configurar su propio umbral mínimo de trust del comprador. Un merchant premium puede requerir agentes con score de 0.6+ mientras un merchant de marketplace acepta 0.3+.

El motor KYAI procesa reglas en orden de prioridad (1 a 15). Los resultados posibles son: • ALLOW — Proceder normalmente • FRICTION — Verificación adicional requerida (confirmar intención, proporcionar autorización del usuario) • REVIEW — Marcado para revisión manual del merchant • BLOCK — Transacción denegada Múltiples reglas FRICTION se acumulan — la peor decisión gana. Pero un BLOCK termina la cadena inmediatamente.

AgenticMCPStores usa un modelo de confianza trilateral — tres actores separados, cada uno con su propio score: • Trust de Merchant — 12 componentes, actualizado cada 6 horas, umbral mínimo 0.3 • Trust de Agente Comprador — 8 componentes, actualizado cada hora, umbral mínimo 0.5 • Trust de Agente Vendedor — 8 componentes, actualizado cada hora, umbral mínimo 0.6 Los scores de agentes comprador y vendedor tienen umbrales más altos porque las acciones de agentes tienen impacto más inmediato — un agente comprometido podría realizar compras no autorizadas o listar productos fraudulentos a escala. La asimetría entre comprador (0.5) y vendedor (0.6) refleja el mayor potencial de daño del compromiso de un agente vendedor.

Los trust scores están disponibles tanto por REST como por interfaz MCP. Endpoints REST API: ``` GET /trust/scores/:storeId → Score actual + 12 componentes GET /trust/scores/:storeId/history → Historial de scores (param days) POST /trust/scores/:storeId/compute → Forzar recálculo (admin) GET /trust/health → Estadísticas de la red GET /trust/recommendations/:storeId → Sugerencias de mejora ``` Herramienta MCP: Los datos de trust están integrados en la respuesta de la herramienta `get_merchant_profile`. No existe herramienta de trust separada — los agentes obtienen información de trust como parte del descubrimiento del merchant, alineado con el principio de que el trust debe ser contextual, no aislado.

En la Parte 4 de Building Agentic Commerce, profundizaremos en pagos con stablecoins x402 — cómo los agentes pagan con USDC on-chain, el flujo HTTP 402, soporte multi-cadena (Base, Ethereum, Solana, Polygon, Arbitrum) y el pipeline de settlement asíncrono. Los trust scores juegan un papel ahí también: el motor KYAI puede requerir mayor trust para transacciones x402 de alto valor.