Cómo crear un agente de IA para tu tienda paso a paso (con n8n)
Crear un agente IA para tu tienda online con n8n, paso a paso: disparador, modelo, prompt de sistema, herramientas, memoria y aprobación humana.

Crear un agente de IA para tu tienda consiste en montar cinco piezas: un disparador que lo activa, un modelo con un prompt de sistema que define su trabajo, herramientas conectadas a tus datos reales (pedidos, stock, CRM), memoria para mantener el contexto y un punto de aprobación humana con registro de todo lo que hace. En n8n, una herramienta de automatización visual, eso es un flujo con el nodo AI Agent en el centro y cada herramienta colgando de él. La clave no es el modelo: es acotar bien la tarea y los límites antes de escribir una sola línea.
Soy Oscar Álvarez, fundador de SEOscar, agencia de ecommerce en Barcelona. Llevo meses montando agentes en tiendas online reales y te cuento algo antes de empezar: la parte difícil de crear un agente IA no es el modelo ni el prompt. Es decidir qué tarea concreta hace, con qué datos y dónde se detiene a pedir permiso. Lo que ves en los vídeos de YouTube funciona en demo y se rompe en producción por esto.
En este artículo te enseño el esqueleto que uso en n8n, una herramienta de automatización visual con nodos que permite conectar un modelo de lenguaje con las APIs de tu tienda. Paso a paso, con lo que mido y lo que me he comido en despliegues reales. Si todavía no tienes claro el concepto, te dejo antes la base en qué es un agente de IA. Más abajo te enseño capturas de un flujo real mío, sin datos de ningún cliente, para que veas cómo quedan las piezas montadas en n8n.
Antes de empezar: qué tarea y qué límites
Antes de abrir n8n tienes que escribir en una frase qué hace el agente y qué no puede hacer nunca. Un agente de IA es un sistema que recibe un objetivo, decide por su cuenta qué herramientas usar y las ejecuta hasta cumplirlo. Esa autonomía es justo lo que lo hace útil y lo que lo hace peligroso si no le pones límites por escrito.
La trampa típica del primer proyecto es pedir un agente que "ayude con la atención al cliente". Eso no es una tarea, es un departamento. Una tarea es: "responder dónde está mi pedido consultando el número de seguimiento en la API del transportista y contestar por email en menos de dos minutos". Lo segundo se puede construir, probar y medir. Lo primero no.
Las tres preguntas que hago en cada proyecto
¿Qué pasa si el agente se equivoca en esta tarea? Si la respuesta es "se envía un reembolso erróneo" o "se cancela un pedido", esa acción va con aprobación humana obligatoria.
¿Cuántas veces al día ocurre esta tarea? Por debajo de cinco o diez veces diarias, muchas veces no compensa el mantenimiento. Automatiza lo repetitivo, no lo raro.
¿De dónde saca el dato correcto? Si tú mismo no sabes en qué sistema vive la verdad (Shopify, el ERP, una hoja de cálculo), el agente tampoco lo va a saber.
Un agente sin límites escritos no es autónomo, es impredecible. Y en una tienda que factura, impredecible sale caro.
Paso 1: el disparador
El disparador es el nodo que arranca el agente y define cuándo entra en acción. En n8n tienes tres familias: webhook (algo llega desde fuera, como un mensaje de chat o un pedido nuevo), programado (cada hora, cada noche) y manual (tú le das al botón). Elegir mal el disparador es la causa número uno de agentes que se ejecutan muchas más veces de las necesarias y disparan el gasto de la API.
Para un agente de ventas IA que responde en la ficha de producto, el disparador es un webhook: el visitante escribe y tu web hace una llamada al flujo. Para un agente que revisa stock bajo y avisa a compras, el disparador es programado a primera hora de la mañana. Para un agente que redacta descripciones de producto en lote, manual, porque quieres controlar cuándo gasta tokens.
Consejo práctico desde el primer día: pon un filtro inmediatamente después del disparador. En los flujos que monto, el primer nodo tras el webhook descarta mensajes vacíos, bots y repeticiones del mismo usuario en menos de dos segundos. Así el modelo solo se ejecuta cuando hay algo real que hacer.
Paso 2: el modelo y el prompt de sistema
El modelo es el motor de razonamiento y el prompt de sistema es su contrato de trabajo. En n8n se conecta un nodo de modelo (OpenAI, Anthropic, Google o uno local) al nodo AI Agent, y el prompt de sistema se escribe en ese nodo agente. Ahí defines rol, tono, qué herramientas debe usar y, sobre todo, qué hacer cuando no sabe algo.
El bloque que más me ha ahorrado problemas es el de la incertidumbre. Algo del estilo: "Si no encuentras el dato en las herramientas disponibles, di que no lo tienes y ofrece pasar con una persona. No inventes plazos de entrega, precios ni disponibilidad bajo ninguna circunstancia". Suena obvio y sin esa frase explícita el modelo rellena huecos con lo que le parece razonable.
Estructura de prompt de sistema que uso
Identidad y ámbito: quién eres, de qué tienda, de qué puedes hablar y de qué no.
Datos de la tienda que no cambian: políticas de devolución, plazos genéricos, zonas de envío.
Reglas de uso de herramientas: cuándo consultar pedidos, cuándo buscar en catálogo, cuándo escalar.
Reglas de prohibición: nada de inventar, nada de descuentos no autorizados, nada de datos personales de otros clientes.
Formato de salida: longitud, tono, si debe terminar con una pregunta o con un enlace a producto.
Sobre qué modelo elegir: empieza por uno intermedio y mide. En agentes de atención con herramientas bien definidas, un modelo medio suele bastar y el coste por conversación baja bastante respecto al modelo más grande. El salto al modelo grande lo justifico cuando el agente tiene que encadenar tres o cuatro herramientas y razonar sobre el resultado.
Paso 3: las herramientas (pedidos, stock, CRM)
Las herramientas son las acciones que el agente puede ejecutar por su cuenta, y son lo que separa un agente real de un modelo que conversa. En n8n cuelgas cada herramienta del nodo AI Agent: una llamada HTTP a la API de Shopify para consultar un pedido, un nodo de base de datos para mirar stock, un nodo de HubSpot o Klaviyo para crear o actualizar un contacto.
Cada herramienta necesita una descripción escrita para el modelo, no para ti. El modelo decide si la usa leyendo esa descripción. "Consulta pedido" es mala. "Devuelve el estado, la fecha de envío y el número de seguimiento de un pedido a partir del número de pedido o del email del cliente. Úsala siempre que el cliente pregunte por el estado de un envío" es buena. En las revisiones que hago, una parte muy alta de los fallos de un agente que "no hace caso" son descripciones de herramienta vagas.
Herramientas mínimas para una tienda online
Consulta de pedido por número o email, con estado y seguimiento.
Búsqueda en catálogo con filtros de talla, color, precio y disponibilidad real.
Consulta de stock por SKU, el código único que identifica cada variante de producto.
Alta o actualización de contacto en el CRM o en la herramienta de email marketing.
Escalado a persona: crear un ticket o enviar un aviso a Slack con el historial de la conversación.
Si vas a conectar muchas herramientas, mira el protocolo MCP, que estandariza cómo un agente accede a sistemas externos sin que tengas que programar cada integración a mano. Lo explico aplicado a n8n en n8n y MCP. Para el primer agente no lo necesitas: tres herramientas HTTP bien descritas te llevan muy lejos.
Paso 4: memoria y datos propios
La memoria y los datos propios son cosas distintas y conviene no mezclarlas. La memoria guarda el hilo de la conversación actual para que el agente no pregunte dos veces el número de pedido. Los datos propios son tu catálogo, tus políticas y tus fichas, y se consultan con RAG (Retrieval Augmented Generation), una técnica que busca los fragmentos relevantes de tu documentación y se los pasa al modelo antes de que responda.
En n8n la memoria se añade con un nodo de memoria conectado al agente, usando una clave de sesión que normalmente es el ID del visitante o el email. Mi recomendación: ventana corta, entre diez y quince mensajes. Memorias largas disparan el coste por conversación y aportan poco en una tienda, donde la conversación media dura pocos turnos.
Para los datos propios, el error clásico es volcar el catálogo entero en una base vectorial y olvidarse. El catálogo cambia: precios, stock, productos descatalogados. Lo que hago es separar lo estable (políticas, guías de tallas, preguntas frecuentes, fichas descriptivas) en la base vectorial, y lo volátil (precio y stock) siempre por llamada en vivo a la API. Si te interesa el detalle técnico, lo desarrollo en qué es RAG.
Paso 5: aprobación humana y registro
La aprobación humana es un punto del flujo donde el agente se detiene y espera que una persona confirme antes de ejecutar una acción con consecuencias. Va en toda acción que toque dinero, datos personales o el estado de un pedido: reembolsos, cancelaciones, cambios de dirección, descuentos. Sin ese punto, un agente con acceso de escritura a tu tienda es un riesgo que no compensa.
En n8n lo monto con el nodo de espera y un mensaje a Slack o a email con dos botones, aprobar y rechazar. El agente prepara la acción, explica por qué la propone y se queda parado hasta que alguien decide. En la práctica, pasadas unas semanas ves qué tipo de aprobaciones se confirman siempre y puedes liberar esas, dejando la revisión solo donde hay variedad de criterio.
El registro no es opcional
Guarda cada ejecución en una tabla propia: fecha, entrada del usuario, herramientas que invocó el agente, respuesta final, tokens consumidos y si hubo escalado. n8n guarda el historial de ejecuciones, pero caduca y no se consulta cómodo. Con una tabla en Postgres o incluso en Google Sheets al principio, en pocas semanas tienes material para mejorar el prompt con datos y no con intuición.
Ese registro es además lo que te permite calcular el coste real por conversación y compararlo con lo que te cuesta una respuesta de soporte humano. Es el número que más convence a un director de ecommerce a la hora de decidir si el agente se queda.
Cómo probarlo antes de soltarlo
Antes de poner el agente delante de clientes, prueba con un banco de casos escritos y una fase en sombra. El banco de casos son entre treinta y cincuenta preguntas reales sacadas de tu bandeja de soporte, incluidas las raras y las mal escritas. La fase en sombra consiste en que el agente genere la respuesta pero no la envíe: la ve una persona, la compara con lo que habría contestado y la puntúa.
Checklist de pruebas que aplico
Casos felices: pregunta clara, dato disponible, respuesta correcta.
Casos sin dato: pedido que no existe, producto descatalogado. Debe reconocer que no lo tiene y escalar.
Casos adversarios: alguien que le pide un descuento, que le dice "ignora tus instrucciones" o que le pregunta por la competencia.
Casos de idioma: si vendes fuera, prueba en todos los idiomas de la tienda, incluido el catalán si aplica.
Casos de coste: una conversación larga de veinte turnos, para ver cuánto se dispara el consumo.
El despliegue lo hago por etapas: primero interno para el equipo, después un porcentaje reducido del tráfico y, si los indicadores aguantan, el resto. Los indicadores que miro son tasa de escalado a humano, porcentaje de respuestas marcadas como incorrectas en la revisión, coste por conversación y, en agentes de venta, conversión de las sesiones que han interactuado frente a las que no, medida en GA4.
Qué haría yo desde SEOscar en tu caso
En los proyectos que llevo, empiezo siempre por mirar los datos antes de montar nada: qué preguntas repiten tus clientes en el soporte, qué páginas tienen tráfico que no convierte y qué procesos internos consumen horas. Con eso se decide si lo que necesitas es un agente de ventas IA en la tienda, una automatización interna o simplemente arreglar antes la ficha de producto.
Construyo sobre tu plataforma actual, sea Shopify, WooCommerce o Magento, sin obligarte a migrar, y el flujo de n8n y el código quedan en tu propiedad. Si quieres ver cómo organizo el trabajo por etapas, está todo público en el método.
Si has llegado hasta aquí y tienes clara la tarea que quieres automatizar pero no por dónde entrar, reserva un diagnóstico. En la primera semana miro tus datos reales y te digo si un agente tiene sentido en tu tienda o si hay algo más rentable que hacer primero. El plan es tuyo, sigamos trabajando juntos o no.
Preguntas frecuentes
¿Qué necesito para crear un agente de IA en n8n?
Necesitas una instancia de n8n (en la nube o autoalojada), una clave de API de un proveedor de modelos como OpenAI, Anthropic o Google, y acceso a las APIs de los sistemas que quieras conectar: tu tienda, tu CRM o tu ERP. Con el nodo AI Agent de n8n conectas el modelo, las herramientas y la memoria en un mismo flujo visual. No hace falta saber programar, pero sí entender cómo funcionan las llamadas HTTP y la autenticación con tokens.
¿Cuánto cuesta mantener un agente de IA en una tienda online?
El coste tiene tres partes: la infraestructura de n8n, el consumo del modelo por conversación y el mantenimiento del flujo cuando cambian tus sistemas. El consumo del modelo se calcula por tokens y varía mucho según el modelo elegido y la longitud de la memoria. Por eso insisto en registrar cada ejecución con sus tokens desde el primer día: solo con ese registro sabrás tu coste real por conversación y podrás compararlo con el coste de atender esa consulta a mano.
¿Qué diferencia hay entre un agente de IA y un chatbot de reglas?
Un chatbot de reglas sigue un árbol de decisión fijo: si el usuario pulsa una opción, responde un texto predefinido. Un agente de IA recibe un objetivo, decide por su cuenta qué herramientas usar y las ejecuta hasta resolverlo, consultando datos reales como el estado de un pedido o el stock de una talla. Esa autonomía le permite resolver casos que nadie programó, y por eso necesita límites escritos y aprobación humana en las acciones sensibles.
¿Puede un agente de IA equivocarse y dar información falsa a un cliente?
Sí, y por eso se diseña contra ello. Las dos defensas que funcionan son anclar el agente a datos reales mediante herramientas (que consulte la API en vez de recordar) y escribir en el prompt de sistema una instrucción explícita de reconocer cuando no tiene el dato y escalar a una persona. Además, los datos volátiles como precio y stock nunca deben vivir en la base vectorial: se consultan en vivo en cada respuesta.
¿Cuánto se tarda en montar un primer agente de IA funcional?
Un agente con una sola tarea bien acotada, tres herramientas y aprobación humana se puede montar en pocos días. Lo que alarga el proyecto no es construir el flujo, sino limpiar los datos a los que se conecta y preparar el banco de casos de prueba. En los despliegues que hago, la fase de pruebas en sombra, con el agente generando respuestas que revisa una persona antes de enviarlas, suele llevar más tiempo que la construcción.
¿Puedo crear un agente de IA sobre Shopify o WooCommerce sin migrar la tienda?
Sí. Un agente construido en n8n se conecta por API a Shopify, WooCommerce o Magento sin tocar la plataforma ni obligar a migrar. En SEOscar trabajamos siempre sobre el stack actual del cliente: el agente consulta pedidos, stock y catálogo mediante las APIs existentes, y el flujo queda documentado y en propiedad del cliente para que pueda mantenerlo o llevárselo.
¿Qué indicadores debo medir para saber si el agente funciona?
Los cuatro que miro siempre son: tasa de escalado a humano, porcentaje de respuestas marcadas como incorrectas en la revisión manual, coste por conversación y, en agentes orientados a venta, la conversión de las sesiones que interactuaron con el agente frente a las que no, medida en GA4. Si el escalado baja y la conversión no se mueve, el agente está ahorrando soporte pero no vendiendo, y eso cambia la decisión sobre dónde invertir.
