Pregunta a diez proveedores por la «IA en e-commerce» y nueve te mostrarán un chatbot que responde preguntas del FAQ. Es el uso más frecuente, más barato y menos valioso de la inteligencia artificial en una tienda: implantado para que en la web aparezca una etiqueta «AI-powered», y no para que cambie algo en el resultado financiero.
Este artículo va de otra cosa. Mostramos tres casos de uso que hemos implantado en producción y que trabajan a diario en tiendas reales. De cada uno describimos lo mismo: qué problema de negocio resuelve, cómo funciona realmente por debajo (el mecanismo, los datos necesarios, los puntos de integración), de dónde sale el retorno de la inversión y, igual de importante, cuándo no vale la pena implantarlo. Porque la recomendación más honesta sobre IA suele ser: «en vuestro caso esto no se va a amortizar».
Por qué la mayor parte de la «IA en e-commerce» es teatro
Un chatbot de FAQ es teatro porque no tiene acceso a nada que importe. No conoce el stock, no ve el estado del pedido del cliente, no conoce las reglas de las promociones, no sabe calcular un descuento. Responde a preguntas generales que el cliente no hace de todos modos, y ante la primera pregunta concreta remite al formulario de contacto. La implantación lleva una semana, cuesta poco y no mueve ninguna métrica, porque no se ha conectado a ningún proceso que genere esa métrica.
Los proyectos de IA fallidos suelen fallar de una de estas tres maneras, y conviene reconocerlas antes de firmar un contrato. Primera: el modelo no está conectado a datos vivos, así que responde con generalidades en lugar de con hechos de tu sistema. Segunda: resuelve un problema que no tienes; construye un asistente donde bastaba un buen filtro. Tercera: nadie definió qué debía cambiar, así que después de la implantación no se puede decir si algo funciona. Cada uno de estos tres errores se puede evitar, pero solo antes del arranque, no después.
Nuestro principio es el contrario: empezamos por el problema de negocio, no por la tecnología. La pregunta no es «dónde encajamos la IA», sino «¿resuelve la IA este problema concreto mejor y más barato que las alternativas que ya existen?». Si un buen buscador con filtros resuelve el asunto, desaconsejamos la IA. Si tres dashboards responden al 90% de las preguntas de la dirección, desaconsejamos un asistente analítico. La IA solo tiene sentido allí donde realmente quita trabajo, acorta el tiempo de decisión o cierra una venta que de otro modo no habrías cerrado.
Un chatbot que no tiene acceso a tu almacén, a tu tarifa y al estado de los pedidos no es «IA en e-commerce». Es un widget. El valor empieza solo allí donde el modelo obtiene acceso a tus datos reales y a tus procesos reales.
Los tres casos de uso siguientes comparten una cosa: el modelo está conectado a los datos vivos de la tienda y hace un trabajo concreto en un proceso concreto. Es el único tipo de IA que aporta un retorno medible, y el único que implantamos.
Caso de uso 1: Asistente de compra y caja de autoservicio
El mismo motor atiende dos canales: la pantalla de la caja de autoservicio en la tienda física y un widget en la tienda online. Lo implantamos en producción para un cliente de retail.
El problema de negocio
El cliente está en la caja de autoservicio o navega por el catálogo online y se atasca: no encuentra el producto, no sabe si está incluido en una promoción, no consigue escanear el código, no está seguro de si una variante concreta está disponible. En la tienda física llama a un empleado, si es que hay alguno libre. Online simplemente se va. Cada una de estas situaciones es o tiempo de atención consumido o un carrito abandonado.
Cómo funciona realmente
No es un chatbot pegado a la web. Es un modelo de la clase GPT-4 integrado en una arquitectura RAG (retrieval-augmented generation): la pregunta del cliente pasa primero por una búsqueda sobre el catálogo de productos vectorizado, y el modelo formula la respuesta únicamente a partir de lo que realmente encuentra en tus datos. A eso se suman llamadas a funciones de sistemas vivos: consulta del stock, del estado del pedido, de las reglas de promoción. Gracias a ello el asistente no «inventa» un precio: o lo conoce desde el sistema, o dice que no lo sabe y deriva a atención al cliente. Esa única diferencia —una respuesta obtenida del sistema en lugar de generada por el modelo— es lo que distingue a un asistente de producción de un chatbot decorativo. Un cliente en la caja no puede recibir un precio que el tique no vaya a aceptar, ni una promesa de disponibilidad que el almacén no confirme. Toda la ingeniería de este caso de uso se reduce a mantener el modelo con la correa corta de tus datos reales.
Lo que necesita una implantación así:
Un catálogo de producto limpio: nombres, atributos, variantes, precios, disponibilidad. Es el cimiento; sobre su calidad escribimos más abajo y es él quien decide todo.
Una API de tarifas y promociones, para que la respuesta sobre un descuento coincida con lo que cobrará la caja. Una discrepancia aquí es peor que no tener asistente.
Estado de almacén y de pedidos: disponibilidad de una variante concreta, seguimiento del envío.
Un punto de contacto: la pantalla de la caja de autoservicio o un widget en la tienda online. La lógica es común a ambos canales (omnicanal), solo cambia la interfaz.
De dónde sale el ROI
En nuestra implantación de retail el asistente quitó a atención al cliente del orden del 60% del tiempo que los empleados dedicaban antes al soporte en las cajas en los primeros meses. Son horas reales de plantilla trasladadas a tareas de mayor valor: no una «mejora», sino capacidad de equipo contable. Online, el mismo mecanismo cierra carritos que de otro modo habrían desaparecido con el primer «no sé si esto encaja». El retorno es medible porque la métrica —tiempo de atención, tasa de abandono— la definimos antes del arranque, y no la ajustamos al resultado después.
Cuándo no vale la pena
Si tienes un catálogo pequeño, poco tráfico en las cajas y una búsqueda con filtros que funciona, el asistente no recuperará su coste, porque no hay de dónde. Si tus datos de producto están desordenados, ordena primero los datos: un asistente basado en un catálogo basura dará respuestas erróneas con seguridad y elegancia, y eso es peor que no tener asistente en absoluto.
Caso de uso 2: Búsqueda visual (visual search)
El cliente busca productos haciéndoles una foto en lugar de describirlos con palabras. Este caso de uso lo implantamos en clientes D2C con un catálogo visualmente rico.
El problema de negocio
El cliente ha visto un producto —un mueble en casa de un conocido, una chaqueta en una foto, una lámpara en una cafetería— y quiere comprarlo, pero no sabe describirlo. Escribe «una lámpara de madera de estilo retro» y el buscador de texto devuelve o demasiado o nada. La intención de compra es alta y la barrera de la descripción la mata. Es una venta que pierdes no por el precio ni por la disponibilidad, sino porque el cliente no sabe nombrar lo que quiere.
Cómo funciona realmente
El cliente hace una foto. Un modelo de visión (de la clase CLIP) codifica esa foto en un vector en el mismo espacio en el que antes incrustamos las imágenes de todo tu catálogo; una búsqueda de vecinos más cercanos devuelve los productos visualmente más parecidos. Una detección previa del objeto permite reconocer y acotar la categoría, para no mezclar sillas con lámparas. El catálogo se vectoriza una vez y después se reindexa con cada cambio de surtido: si no, las novedades no se pueden encontrar.
Lo que aquí es crítico:
Fotografía de producto coherente y de buena calidad: es el combustible de este caso de uso. Cuanto más rico y más «visual» sea el catálogo, más acertadas serán las coincidencias.
Un índice vectorial sobre las imágenes del catálogo, actualizado junto con el surtido.
Una taxonomía de categorías, para acotar y ordenar los resultados con sentido.
Una subida cómoda, sobre todo en móvil: el cliente hace la foto con el teléfono, así que allí tiene que funcionar sin fricción.
De dónde sale el ROI
En categorías impulsadas por el aspecto —moda, muebles, decoración, accesorios— la búsqueda por foto suele elevar la conversión en un porcentaje de dos dígitos bajo (en nuestras implantaciones, del orden del 12–18% en tiendas con un catálogo visualmente rico). El mecanismo es simple: recuperas la intención de «lo vi en algún sitio», que la búsqueda de texto no puede atender, y acortas el camino de la foto al carrito a unos segundos.
Cuándo no vale la pena
Con catálogos basados en especificaciones y no en el aspecto —tornillos, cables, componentes B2B— la búsqueda paramétrica por texto es simplemente mejor; una foto no distinguirá nada entre dos piezas casi idénticas. Si la fotografía es pobre o incoherente, o el catálogo es pequeño, la búsqueda visual será un gadget y no una herramienta de venta. Y si los clientes encuentran los productos sin problema por nombre o por SKU, no tienes un problema que resolver.
Caso de uso 3: Asistente analítico sobre los datos de la tienda
La persona que dirige la tienda pregunta por los datos en lenguaje natural, en lugar de escribir consultas o esperar un informe. Este caso de uso lo implantamos en un cliente B2B.
El problema de negocio
El propietario o el director quiere preguntar en lenguaje natural: «Muéstrame los 10 productos más rentables de los últimos 30 días con la tendencia interanual». Hoy eso significa o escribir una consulta SQL, o pasar por cuatro informes, o —lo más habitual— abrir un ticket al departamento de IT y esperar dos días. El conocimiento está en los datos, pero el acceso a ellos es el cuello de botella y, por eso, parte de las decisiones se toman «a ojo» aunque las cifras estén en la base de datos.
Cómo funciona realmente
Un LLM (Claude o GPT-4) actúa como capa que traduce el lenguaje natural en una consulta a tus datos. La pregunta se convierte en una consulta a la base de pedidos, clientes y productos, se ejecuta sobre datos reales y el resultado vuelve como cifras más una descripción concisa. Lo clave: el modelo no «conoce» tus ventas por su entrenamiento, consulta tu base en vivo. Sobre la base colocamos una capa semántica con definiciones de métricas (qué significa exactamente «rentabilidad»), control de acceso (quién puede preguntar sobre qué) y registro de todas las consultas.
Condiciones sin las cuales esto no funcionará:
Datos de venta fiables y bien modelados: un esquema coherente o un almacén de datos. Sin ello, las respuestas serán a la vez seguras y erróneas.
Definiciones de métricas fijadas: si no, «margen» significará algo distinto en cada respuesta y nadie confiará en la herramienta.
Control de acceso y auditoría de consultas, porque es una capa sobre datos financieros sensibles, no sobre descripciones de producto.
De dónde sale el ROI
Aquí el retorno es distinto al de los dos anteriores: es la democratización de los datos. Quienes deciden obtienen respuestas sin la intermediación de IT y sin cola ante el analista. El valor está en el tiempo de decisión acortado, no en un porcentaje llamativo; es más difícil de atribuir a una cifra concreta, pero en la práctica significa decisiones más rápidas, más frecuentes y mejor fundamentadas en datos. Para una tienda en la que cada semana alguien espera un informe, es un cambio real de ritmo en el trabajo de la dirección.
Cuándo no vale la pena
Es el más exigente de los tres casos de uso y el más fácil de estropear. Si tus datos están desordenados, obtendrás lo peor posible: un modelo que con total convicción dará una cifra errónea, y esa cifra acabará en una presentación para la dirección. Si tienes tres informes que responden al 90% de las preguntas y nadie hace realmente preguntas ad hoc, no lo construyas. Una cifra alucinada en una decisión de negocio es más cara que la falta de herramienta.
El cuello de botella no es el modelo, son tus datos
Si de las tres secciones anteriores se desprende un patrón, es este: cada vez que la IA falla, la causa son los datos, no el modelo. Un asistente de compra es tan bueno como limpio esté el catálogo. La búsqueda visual es tan buena como coherente sea la fotografía. Un asistente analítico es tan bueno como fiable sea el almacén de datos. Los modelos de la clase GPT-4 o Claude ya son hoy suficientemente buenos para el e-commerce: no son ellos la limitación.
No construimos modelos desde cero para aplicaciones típicas de e-commerce. Los foundation models más fine-tuning o RAG son más baratos y mejores que un entrenamiento propio. El trabajo de verdad —y el presupuesto de verdad— va a ordenar los datos, no al modelo.
Por eso, antes de calcular el ROI de la IA, a menudo recomendamos ordenar primero los datos de producto: es exactamente el trabajo que hacemos en las implantaciones de PIM. Sin un catálogo limpio y completo, cada uno de estos casos de uso arranca en negativo, y pagas por un modelo que no tiene con qué trabajar.
La segunda cosa que distingue una implantación en producción de una demo vistosa es la ingeniería alrededor del modelo:
Monitorización y fallbacks: cuando el modelo o la API del proveedor no responde, el proceso de venta no puede detenerse. Tiene que haber un plan B.
Control de los costes de API: caché de respuestas, elección del modelo según la tarea (un modelo más pequeño y barato a menudo basta), límites de consumo estrictos.
Seguridad y RGPD: configuración de retención cero de datos en el proveedor (OpenAI Enterprise, Anthropic con BAA), anonimización de datos sensibles antes de enviarlos al modelo, auditoría RGPD antes de pasar a producción.
Qué caso de uso encaja con tu tienda
Un mapa de decisión resumido: de qué depende que un caso de uso se amortice y cuándo es mejor dejarlo:
Caso de usoMayor retorno cuando…Datos que deben estar limpiosCuándo dejarloAsistente de compra / caja de autoserviciocatálogo grande, tráfico alto, muchas preguntas de «¿encaja / está disponible?»catálogo, tarifa, promociones, stockcatálogo pequeño, los buenos filtros ya bastanBúsqueda visualcategorías impulsadas por el aspecto (moda, muebles, interiorismo)fotografía de producto coherente y ricacatálogo de especificaciones (piezas, B2B), fotografía pobreAsistente analítico LLMpreguntas ad hoc frecuentes, cola larga hacia IT / el analistabase de ventas bien modelada + definiciones de métricasdatos desordenados o los dashboards responden al 90% de las preguntas
Cuánto cuesta
No damos aquí un precio fijo, y lo hacemos a propósito. El coste de una implantación de IA depende de tres cosas: la complejidad del caso de uso, el número de integraciones y el nivel de seguridad de datos requerido. A grandes rasgos crece en el orden en que hemos descrito los casos de uso: el asistente de compra suele ser el más sencillo, y el asistente analítico sobre una base financiera sensible el más exigente, porque se añaden el control de acceso y la auditoría. A la implantación puntual hay que sumar un coste fijo y previsible de las llamadas a la API, del orden del coste mensual de una herramienta del stack de la empresa, no de una persona a jornada completa.
En lugar de promesas definimos KPI de negocio antes del arranque y los medimos en una ventana de 90 días. Si pasado ese tiempo el objetivo no se ha alcanzado, buscamos primero la causa —normalmente está en los datos, no en el modelo— y lo corregimos sin coste adicional. Si resulta que la IA simplemente no encaja con ese problema, en nuestros contratos devolvemos parte del valor del proyecto. Esa es una definición operativa de «ROI medible», y no un eslogan de landing page.
Conclusiones
La IA en e-commerce funciona exactamente cuando deja de ser un adorno y empieza a estar conectada a tus datos y a tus procesos. Los tres casos de uso anteriores —asistente de compra, búsqueda visual y asistente analítico— comparten que cada uno quita un trabajo concreto o cierra una venta concreta, y que su éxito depende más de la calidad de tus datos que de la elección del modelo. Lo más habitual es que la mejor recomendación sea acotar: un caso de uso, un KPI definido, una ventana de 90 días.
Si quieres comprobar cuál de ellos —si alguno— se amortizará en tu tienda, describimos nuestro enfoque con más detalle en la página de IA en e-commerce. Y si prefieres hablar directamente de un problema concreto y de los datos que tienes, escríbenos. Empezaremos por la pregunta de si la IA es aquí la herramienta adecuada.