IA para ecommerce: arquitectura de plataforma, no plugins

Casi todos los proyectos de IA para ecommerce empiezan por el sitio equivocado: un chatbot en la ficha de producto. Meses despues sigue ahi, aislado, sin acceso al stock real ni al historial del cliente. El problema no era el modelo, era que nadie diseño la plataforma por debajo.

Un plugin no es una plataforma

Hay una pregunta que separa instalar IA de construir sobre IA: ¿que pasa cuando cambias de modelo? Si la respuesta implica rehacer integraciones, reescribir prompts repartidos por cinco herramientas y volver a conectar el ERP, no tienes una plataforma. Tienes dependencias sueltas.

Una tienda online es, en el fondo, un flujo de eventos. Se visita un producto, se abandona un carrito, entra un pedido, se retrasa un envio, se abre una devolucion, se agota una talla. Cada evento puede disparar una decision. La pregunta de arquitectura no es que modelo usar. Es donde vive esa logica de decision y quien puede cambiarla sin desplegar codigo.

Cuando la logica vive dispersa en integraciones puntuales, cada mejora cuesta un proyecto. Cuando vive en una capa propia, cada mejora cuesta una configuracion.

Las cuatro capas que hacen falta

Montar una empresa sobre agentes de IA no es elegir proveedor. Es decidir que hay debajo. En un ecommerce, la estructura minima tiene cuatro capas y ninguna es opcional.

El error tipico es construir solo la primera y la ultima: conectar un modelo y poner una interfaz bonita. El valor esta en las dos del medio, que son las que nadie ve y las que determinan si el sistema aguanta en produccion.

• →Contexto: catalogo, stock real, historial del cliente, politicas de envio y devolucion. Un agente sin acceso al stock inventa disponibilidad, y una promesa falsa cuesta mas que una respuesta lenta.
• →Acciones: que puede hacer el agente, no solo que puede decir. Consultar un pedido, generar una etiqueta de devolucion, aplicar un descuento. Cada accion con permisos y limites explicitos.
• →Orquestacion: que agente atiende que evento, en que orden, y cuando escala a una persona. Aqui se decide si el sistema es util o es un embudo hacia el buzon de soporte.
• →Observabilidad: traza de cada decision. Que datos vio el agente, que herramientas llamo, que devolvio. Sin esto no hay depuracion posible ni auditoria.

Decisiones estrategicas que no delega el departamento tecnico

La primera es el limite economico de la automatizacion. Un agente que aprueba devoluciones necesita un techo en euros y una regla de escalado. No es un detalle tecnico: es politica comercial escrita en codigo, y la firma direccion.

La segunda es la propiedad de la logica. Si las reglas de negocio viven dentro de un SaaS cerrado, el conocimiento acumulado se marcha con el contrato. Conviene distinguir que capas se alquilan (modelos, infraestructura) y cuales se poseen (contexto, reglas, trazas).

La tercera es el grado de especializacion. Un agente generico responde a todo de forma aceptable y a nada de forma excelente. Los agentes que funcionan conocen el sector: su vocabulario, sus objeciones, sus tiempos. Se ve claro en verticales alejados del retail, como en agencia de IA para concesionarios, donde el ciclo de compra cambia por completo la arquitectura conversacional.

La cuarta es el ritmo. Automatizar atencion al cliente antes de tener el catalogo estructurado produce un agente rapido dando datos malos.

Sin metricas propias no hay mejora

La sensacion de que el agente funciona no es un indicador. Un sistema agentico serio expone su propio panel, y las metricas relevantes en ecommerce son operativas, no de vanidad.

Interesa el porcentaje de conversaciones resueltas sin intervencion humana, la tasa de escalado y su motivo, el coste por conversacion, los errores de disponibilidad o precio, y el efecto sobre carritos recuperados y devoluciones evitadas. Cada una debe poder cruzarse con la traza que la origino.

Ese es el bucle real: medir, encontrar el fallo en la traza, corregir la regla o el contexto, volver a medir. Un sistema que no permite cerrar ese bucle se queda congelado en la version del dia del lanzamiento.

El escaparate tambien ha cambiado

Operar con agentes resuelve la mitad del problema. La otra mitad es que los compradores cada vez preguntan antes a una IA que a un buscador, y esa IA recomienda tiendas concretas. Si tu catalogo no es legible para esos sistemas, no apareces en la recomendacion. Ese frente se trabaja aparte, y esta bien explicado en como lograr que las IAs citen tu tienda.

Las dos mitades comparten cimientos. Un catalogo estructurado, con atributos limpios y politicas explicitas, es a la vez lo que necesita tu agente interno para no equivocarse y lo que necesita un modelo externo para citarte con precision. Ordenar los datos sirve dos veces.

Quien monta esto desde cero suele infravalorar el trabajo de plataforma frente al trabajo de modelo. Sobre como llega una base agentica al estandar que pide una empresa, hay mas detalle en plataformas agenticas listas para empresa.

Este tema tambien se trata, desde otro enfoque, en All ITs AI · Agent Hub · GEOySEO.

La IA para ecommerce deja de ser un experimento cuando se trata como infraestructura: capas definidas, limites explicitos, trazas de todo y metricas propias. Ese trabajo no se ve en la ficha de producto, pero es lo unico que distingue un piloto simpatico de una tienda que opera con agentes. Si estas en el punto de decidir que construir y que alquilar, en Potenciado hablamos de arquitectura antes que de herramientas.