[Descripción general de AI Ready, parte 3] Se revela la arquitectura central de AI Ready: el puente de comunicación entre los sistemas de comercio electrónico estandarizados y los grandes modelos de lenguaje

Respuesta directa: la arquitectura AI Ready puede entenderse como la capa intermediaria de gobernanza entre la plataforma de comercio electrónico y el modelo de IA. Es responsable de convertir los datos de la plataforma en tareas estándar, ejecutar permisos y control de costes, verificar la salida del modelo y devolver los resultados al proceso de comercio electrónico a través de webhooks o programación seguros.

¿A quién va dirigido este artículo?#

• Arquitectos de sistemas que necesitan diseñar la arquitectura de una plataforma de comercio electrónico con IA.

• CTO que quiere integrar múltiples funciones de IA en un centro de gobierno unificado.

• Equipos de desarrollo que necesitan evaluar permisos, costes de tokens, tareas asincrónicas y reescritura de datos.

Objetivo arquitectónico: convertir la IA de una herramienta a una capacidad gobernable#

AI Ready no es un único modelo, ni tampoco un único cuadro de chat. Es una arquitectura intermediaria entre plataformas de comercio electrónico y proveedores modelo. Su objetivo es resolver cuatro problemas:

1. Diferencias de plataforma: Las estructuras de datos de WooCommerce, PrestaShop, OpenCart, Magento / Adobe Commerce son diferentes.

2. Diferencias de modelos: Los diferentes proveedores de modelos tienen diferentes API, formatos de salida, precios y capacidades.

3. Riesgo de permiso: las tareas de IA pueden entrar en contacto con información de productos, pedidos, miembros, precios y atención al cliente.

4. Seguridad de reescritura: la salida de IA debe pasar la verificación y los datos de alto riesgo no se pueden modificar directamente.

Por lo tanto, el núcleo de AI Ready no es "permitir que la IA opere libremente el comercio electrónico", sino poner las tareas de la IA en un flujo de datos controlable y un proceso de revisión.

Componente principal uno: Adaptador de plataforma#

El Adaptador de plataforma se instala en el sistema de comercio electrónico y es responsable de convertir los datos nativos de la plataforma a un formato común AI Ready. Generalmente maneja:

• Mapeo de campos de producto: SKU, nombre, descripción, categoría, etiqueta, variante, imagen.

• Resumen del estado del pedido: número de pedido, estado de pago, estado de envío, condiciones de devolución.

• Contexto de atención al miembro y al cliente: exponer únicamente la información necesaria para la tarea para evitar enviar demasiada información.

• Declaración de capacidad: indique a Gateway qué operaciones de lectura y escritura admite este sitio.

Los adaptadores deben ser lo más delgados posible para evitar volver a introducir mucha lógica del modelo en la propia plataforma. De esta manera, se puede mantener la flexibilidad de las actualizaciones de la plataforma y el mantenimiento de plugins.

Componente principal dos: AI Ready Gateway#

Gateway es el centro de gobierno de toda la arquitectura. En lugar de simplemente reenviar la API, es responsable de:

• Verificación de identidad y control de firma. -Clasificación de tareas y verificación de permisos. -Presupuesto de token y límite de tasa.

• Gestión de contexto de esquema y plantilla de avisos.

• Modelo de ruteo de proveedores.

• Verificación del formato de salida y manejo de errores.

• Registros, auditorías, alarmas e reporting de costes.

Por ejemplo, la generación de copias de productos puede utilizar un modelo de bajo coste y limitar la redacción a borradores; el atención al cliente solo puede leer el resumen del pedido del miembro actual al verificar los pedidos; Los ajustes de precios deben ingresar al proceso de aprobación humana.

Componente principal tres: verificación de esquema y salida#

La producción de IA no puede depender únicamente de limitaciones inmediatas. Un enfoque más confiable es utilizar ambos:

• Esquema JSON: limita los nombres de campo, los tipos, los campos obligatorios y la longitud máxima.

• Lista blanca de campos: solo se permite reescribir campos específicos, como draft_short_description.

• Protección de hechos: El modelo no debe modificar el material del producto, el tamaño, el precio, el stock y otros campos.

• Revisión manual: el contenido de alto riesgo o alta exposición ingresa primero a la cola de revisión.

• Registro de reversión: mantenga la versión para cada generación de IA y reescritura.

Este diseño reduce la posibilidad de alucinaciones y reescrituras falsas, pero no puede pretender eliminar completamente los errores. Por lo tanto, los procesos formales deben conservar la verificación, la auditoría y el seguimiento.

Componente principal cuatro: tareas asincrónicas y webhook#

Muchas tareas de IA no son adecuadas para la ejecución simultánea, como la traducción por lotes, el análisis de stock, la generación de contenido SEO y el resumen de conversaciones de atención al cliente. AI Ready debería poner este tipo de trabajo en una cola o tarea en segundo plano para evitar bloquear la navegación en primer plano, el pago y las operaciones en segundo plano.

El proceso típico es el siguiente:

1. El Adaptador de plataforma emite una solicitud de tarea.
2. Gateway verifica la firma y los permisos.
3. Gateway crea la tarea y devuelve job_id.
4. El trabajador en segundo plano llama al proveedor del modelo.
5. El resultado pasa la validación del esquema.
6. Gateway notifica a la plataforma a través de webhook.
7. La plataforma utiliza idempotency_key para garantizar que no se ejecute repetidamente.

Los webhooks deben incluir marcas de tiempo, nonces, firmas y protección contra ataques de reproducción. Para las devoluciones de llamadas que modifican datos, el estado de procesamiento del evento también debe guardarse para garantizar que volver a intentarlo no dé lugar a envíos repetidos, cambios de precios repetidos o creación repetida de cupones.

Gobernanza de costes: el token no es un detalle técnico, sino un coste operativo#

La arquitectura AI Ready debe incorporar el seguimiento de tokens en los paneles operativos. Se recomienda registrar al menos:

-Tipos de tareas: redacción, traducción, atención al cliente, reporting, recomendaciones.

• Fuente del usuario o del sistema.

• Proveedor del modelo y nombre del modelo.

• tokens de entrada/tokens de salida.

• Centro de Estimación de Costes y Presupuestación.

• Éxito, fracaso, reintentos y latencia media.

Esta información puede ayudar al CTO a determinar qué tareas vale la pena automatizar, qué tareas deben degradarse al modelo y qué tareas deben almacenarse en caché o agruparse en lotes.

Preguntas frecuentes#

¿Se debe implementar AI Ready Gateway de forma independiente?#

incierto. Los sitios web pequeños pueden primero utilizar el mismo host o el mismo conjunto de aplicaciones para implementar el concepto de Gateway; Los entornos multisitio o multiplataforma a gran escala son más adecuados para la implementación independiente, lo que facilita el control centralizado de tokens, permisos, registros y proveedores de modelos.

¿Cuáles son los beneficios de la capa de abstracción del proveedor de modelos?#

Permite que las tareas del comercio electrónico no queden ligadas a un único modelo. Cuando cambian los precios, las capacidades, el cumplimiento regional o la estabilidad del proveedor, el enrutamiento se puede ajustar en la capa de puerta de enlace sin cambiar cada complemento de plataforma.

¿Puede la validación de salida de IA evitar errores por completo?#

no puedo. Los esquemas, las listas blancas y la auditoría solo pueden reducir la probabilidad y el alcance de los errores. Las áreas de alto riesgo, como los datos del producto, los precios, los compromisos legales, los reembolsos y el procesamiento de información personal, aún requieren una revisión humana o un motor de políticas claro.

Referencias#

• Centro de búsqueda de Google: los datos estructurados deben coincidir con el contenido visible, https://developers.google.com/search/blog/2025/05/succeeding-in-ai-search
• Colas de mensajes de Adobe Commerce, https://developer.adobe.com/commerce/php/development/components/message-queues/
• Manual de API REST de WordPress, https://developer.wordpress.org/rest-api/