Este artículo cuenta un caso real nuestro, en producción: un retail multicanal con local físico, una sucursal y venta online, con más de 20.000 productos en su sistema de gestión y unas 13.000 publicaciones activas entre Tienda Nube y Mercado Libre. Antes del proyecto, cuatro personas trabajaban todo el día dando de alta productos a mano. El sistema de origen es una aplicación de escritorio a medida, sin API. Lo que sigue es la arquitectura completa del pipeline que construimos, los números reales, y las decisiones de diseño: qué automatizamos, qué dejamos en manos del equipo, y por qué.
En este artículo:
El problema: dar de alta productos a mano no escala
El alta manual de un producto en un ecommerce multicanal no es una tarea, es una cadena de tareas. En el caso de este cliente, para cada producto que entraba, alguien del equipo tenía que:
- Buscar si ya existía publicado, en la tienda o en el marketplace, quizás con otro nombre o en otro talle o color.
- Redactar el título y la descripción, con el estilo de la marca y los datos técnicos correctos.
- Cargar el producto en Tienda Nube, con fotos, categoría, variantes y precio.
- Replicarlo en Mercado Libre, que tiene su propia estructura de categorías, atributos obligatorios y reglas de publicación.
- Aplicar la regla de precios, que no es el mismo número en los dos canales.
Cada paso es corto. La cadena completa, multiplicada por decenas de productos nuevos por semana, ocupaba a cuatro personas a tiempo completo. Y el primer paso es el más traicionero: cuando la búsqueda manual falla, se publica un duplicado, y los duplicados en Mercado Libre degradan el posicionamiento de la publicación original.
El instinto habitual es "contratemos a alguien más" o "usemos ChatGPT para las descripciones". Ninguna de las dos ataca el problema real: el circuito entero depende de que una persona mire dos sistemas que no se hablan entre sí y decida, producto por producto, qué corresponde hacer.
Por qué un conector no alcanza
Existen conectores que sincronizan Tienda Nube con Mercado Libre, y funcionan bien para lo que hacen: si tu catálogo ya está prolijo en un canal, lo replican en el otro y mantienen precios y stock alineados. Si tu único problema es ese, un conector es la solución correcta y no necesitás un desarrollo a medida.
El problema de este caso empezaba antes del primer canal. Tres razones por las que un conector no lo resolvía:
- El origen no es la tienda, es el sistema de gestión. El catálogo maestro vive en una aplicación de escritorio a medida, sin API ni acceso externo a su base de datos. Ningún conector comercial se enchufa ahí.
- Nadie decide qué es nuevo. El sistema de gestión tiene más de 20.000 productos; la tienda, 13.000 publicaciones. Un conector replica lo que ya está publicado, pero no puede responder la pregunta central del alta: de todo lo que entró esta semana, ¿qué es un producto nuevo, qué es una variante de algo ya publicado y qué ya está online con otro código?
- Los textos no se escriben solos. Un conector copia títulos y descripciones existentes. En el alta no existen todavía: hay un código interno, una descripción de dos palabras y un precio.
La conclusión de diseño: el proyecto no era "conectar dos plataformas" sino construir un pipeline con criterio propio entre el sistema de gestión y los canales de venta.
La arquitectura, etapa por etapa
El pipeline completo tiene seis etapas. El stack: n8n como orquestador, Postgres (Supabase) como capa de datos propia, la API de Claude para los textos, y las APIs oficiales de Tienda Nube y Mercado Libre para publicar. Ninguna pieza es exótica; el valor está en cómo se reparten el trabajo.
1. Ingesta: un export diario, sin tocar el sistema de origen
Como el sistema de gestión no tiene API, la integración se resolvió por el camino más simple que funciona: el proveedor del sistema programó un export automático del catálogo completo (código, descripción, código de barras, precio, rubro, fecha de primera compra) que se deposita todos los días a las 5 de la mañana en una carpeta de Google Drive. Un workflow de n8n detecta el archivo medio minuto después, valida que el formato sea el esperado y lo ingesta. Si el archivo no llega o viene incompleto, dispara una alerta en lugar de procesar datos rotos.
Nadie del equipo manda nada ni avisa que llegó. Esa es la vara de una ingesta bien resuelta: desaparece de la rutina de todos.
2. Staging: una capa de datos propia entre el sistema y los canales
El pipeline no escribe directo del export a la tienda. En el medio hay una base propia en Postgres que mantiene el vocabulario del proyecto: qué producto del sistema corresponde a qué publicación en cada canal, en qué estado está cada uno (nuevo, variante, publicado, pendiente, error) y qué pasó en cada intento de publicación.
Esta capa es la que casi todos los proyectos de integración se saltean, y la razón por la que después no pueden responder preguntas básicas como "¿este producto ya se publicó?" o "¿por qué este quedó a mitad de camino?".
3. Detección: nuevo, variante o ya publicado
Cada producto del export se clasifica con reglas de negocio, no con magia:
- La fecha de primera compra del sistema separa lo nuevo de lo histórico: un producto comprado por primera vez esta semana es candidato a alta; uno de 2023 ya tuvo su oportunidad.
- El mapa de lo ya publicado (leído por API de los dos canales) evita duplicados: si el código de barras o el SKU ya está online, no es un alta.
- Las reglas de variantes distinguen un producto nuevo de un talle o color nuevo de algo ya publicado, que no se publica aparte: se agrega a la publicación existente.
Lo que no se puede clasificar con confianza no se publica: va a una cola de casos dudosos que revisa una persona. Sobre este caso hay un dato que muestra cuánto rinde afinar reglas antes que agregar IA: una sola regla de negocio (considerar publicado lo que ya figura en la tienda) bajó los casos dudosos de 4.697 a 1.199, y cargar las marcas y los personajes por rubro resolvió más de 3.000 productos adicionales sin revisarlos de a uno.
4. Textos con IA: el modelo redacta, los datos duros se inyectan
Los títulos, descripciones y keywords los genera Claude a partir de los datos del producto y de ejemplos del estilo de la casa. La decisión de diseño importante es qué no pasa por el modelo: el código interno, el código de barras, el precio y las medidas nunca entran al prompt como texto a redactar. Se inyectan desde el staging al armar la publicación.
La razón es el modo de falla típico de usar un chatbot para fichas de producto: el modelo "acomoda" un número. Un precio inventado o un código alterado en una publicación real es exactamente el tipo de error que hace que una empresa abandone la automatización. Separar redacción (el modelo) de datos (la base) elimina esa clase de error por construcción, no por buenas intenciones.
5. Revisión humana: en la herramienta que el equipo ya usa
Nada se publica sin que una persona lo apruebe. Los productos listos aparecen como tarjetas en el tablero de Notion que el equipo ya usaba para organizarse, con el texto generado, las fotos y los datos. El equipo revisa, corrige lo que haga falta y aprueba desde ahí; el pipeline lee la aprobación y recién entonces publica.
Dos detalles de esta etapa que valen más que la etapa misma:
- Cero herramienta nueva. La revisión ocurre donde el equipo ya trabajaba. La curva de aprendizaje de una interfaz nueva mata más automatizaciones que los bugs.
- Las correcciones se registran. Cada vez que el equipo corrige un texto generado, esa corrección queda guardada y alimenta el ajuste de los prompts. La revisión humana no es solo un control: es el mecanismo de mejora del sistema.
6. Publicación: Tienda Nube primero, Mercado Libre después
Aprobado el producto, el pipeline lo publica por API en Tienda Nube y lo replica en Mercado Libre aplicando la regla de precios de cada canal. En Mercado Libre intenta primero el matcheo contra el catálogo oficial por código de barras, que en este caso funciona para aproximadamente el 90% de los productos; el resto cae a publicación tradicional, con revisión. Todo con manejo de límites de las APIs: las publicaciones salen en tandas, no en avalancha.
Qué automatizar y qué dejar humano
La pregunta que define un proyecto de este tipo no es "¿qué puede hacer la IA?" sino "¿qué sabe el sistema y qué sabe solamente el equipo?". Así quedó repartido en este caso:
| Decisión | Quién la toma | Por qué |
|---|---|---|
| Detectar que llegó catálogo nuevo | Sistema | Es un evento de datos, no requiere criterio |
| Clasificar nuevo / variante / ya publicado | Sistema (reglas) | Reglas de negocio explícitas sobre datos que el sistema tiene |
| Redactar título, descripción y keywords | IA | Es lenguaje; los datos duros se inyectan aparte |
| Si hay stock real para publicar | Equipo | El dato de stock del sistema no siempre refleja la realidad física |
| Si el producto es para el local o para la web | Equipo | No está en ningún campo; es una decisión comercial |
| Kits y combos | Equipo | Su composición requiere criterio caso por caso |
| Aprobación final antes de publicar | Equipo | Es la garantía de que nada sale mal a un canal público |
La fila más importante es la última. En las demos de automatización con IA, el sistema publica solo y todos aplauden. En producción, la aprobación humana antes de publicar es lo que permite que el sistema corra todos los días sin que nadie le tenga miedo. No es una limitación del proyecto: es la razón por la que el cliente lo usa.
Los números del caso
- +20.000 productos en el sistema de gestión de origen, ~13.000 publicaciones activas entre los dos canales.
- 4 personas full-time dedicadas al alta manual antes del proyecto.
- De 4.697 a 1.199 casos dudosos tras aplicar una sola regla de negocio (reconocer como publicado lo que ya figura en la tienda).
- +3.000 productos resueltos automáticamente al cargar marcas y personajes por rubro, sin revisión individual.
- 1 de cada 5 productos sin código de barras; el pipeline los resuelve buscando por SKU en lugar de descartarlos.
- ~90% de matcheo al catálogo oficial de Mercado Libre por código de barras, con fallback a publicación tradicional para el resto.
- Ingesta 100% automática: el catálogo completo entra todos los días a las 5 AM y se procesa solo, sin que nadie mande ni avise nada.
Cómo encarar un proyecto así en tu empresa
Si tu operación se parece a la del caso (un sistema de gestión propio, venta multicanal, y gente cargando productos a mano), esto es lo que conviene verificar antes de arrancar:
- Una forma de sacar los datos del sistema de origen. No hace falta API: un export automático programado a una carpeta compartida alcanza, y suele ser algo que el proveedor del sistema puede configurar en días. Lo que no funciona es depender de que una persona genere el export a mano.
- Acceso API a tus canales de venta. Tienda Nube, Mercado Libre, Shopify y WooCommerce tienen APIs oficiales documentadas. Las credenciales deben ser de tu empresa, no del proveedor que te haga el desarrollo.
- Una persona que revise. El cuello de botella deja de ser cargar y pasa a ser aprobar. Es un rol mucho más chico (revisar tarjetas ya armadas en lugar de crear publicaciones desde cero), pero tiene que existir.
- Las reglas de negocio escritas. Qué hace que un producto sea "nuevo", cómo se relacionan los talles y colores con el producto padre, cuál es la regla de precios por canal. Si esas reglas solo viven en la cabeza del equipo, la primera fase del proyecto es escribirlas.
En plazos: un pipeline de este tipo es un proyecto de semanas, no de días. En este caso se planificó en 6 a 8 semanas, con dos hitos intermedios verificables: la conexión con la cola de trabajo funcionando, y el primer lote de productos publicado de punta a punta con revisión del equipo. Desconfiá de los plazos en días: casi siempre significan que nadie miró los casos borde de tus datos (los productos sin código de barras, los combos, las variantes).
Sobre cómo trabajamos esto
En Duotach construimos este tipo de pipelines para empresas de Argentina y LATAM, incluyendo el caso de este artículo, con IA donde aporta (textos, clasificación) y reglas explícitas donde el negocio las tiene. Si tenés un equipo cargando productos a mano y un sistema que no se habla con tus canales de venta, mirá automatización con IA para empresas o escribinos.
Preguntas frecuentes
¿Se puede automatizar el alta de productos si mi sistema de gestión no tiene API?
Sí, y es el caso más común en empresas medianas. La alternativa práctica es un export automático programado (un archivo con el catálogo completo que el sistema deposita a diario en una carpeta compartida) que el pipeline detecta y procesa solo. En el caso de este artículo, el sistema de origen es una aplicación de escritorio a medida sin API, y la ingesta corre todos los días sin intervención de nadie.
¿La IA publica los productos sola?
En nuestro diseño, no. La IA redacta títulos, descripciones y keywords, y el sistema clasifica y prepara la publicación, pero una persona del equipo aprueba cada producto antes de que salga a un canal público. Esa revisión es una decisión de diseño, no una limitación técnica: es lo que garantiza que nunca se publique un error y lo que genera las correcciones con las que el sistema mejora.
¿Qué pasa con los precios y códigos? ¿No hay riesgo de que la IA los invente?
Ese riesgo existe cuando se le pide a un chatbot que redacte la ficha completa. Por eso los datos duros (código interno, código de barras, precio, medidas) nunca pasan por el modelo de IA: se inyectan directamente desde la base de datos al armar la publicación. El modelo solo redacta lenguaje; los números vienen del sistema. Un error de precio queda eliminado por construcción.
¿Funciona con Tienda Nube y Mercado Libre a la vez?
Sí. El pipeline publica primero en Tienda Nube y replica en Mercado Libre por sus APIs oficiales, aplicando la regla de precios de cada canal. En Mercado Libre intenta el matcheo contra el catálogo oficial por código de barras (cerca del 90% de los productos en nuestro caso) y usa publicación tradicional para el resto.
¿Cuánto tarda un proyecto de este tipo?
Un pipeline completo de alta de productos es un proyecto de 6 a 8 semanas para una operación de decenas de miles de productos, con hitos intermedios verificables (conexión funcionando, primer lote publicado de punta a punta). Los plazos de días que prometen algunas herramientas aplican a replicar un catálogo ya prolijo entre canales, que es un problema distinto y más chico.
¿Esto reemplaza al equipo que carga productos?
Cambia su trabajo más de lo que lo elimina. La carga repetitiva (transcribir, redactar desde cero, replicar en cada canal) desaparece; lo que queda es la revisión y las decisiones que el sistema no puede tomar: si hay stock real, si un producto va a la web o al local, cómo se arma un combo. En el caso del artículo, cuatro personas dedicadas al alta pasan a disponer de la mayor parte de su tiempo para otras tareas.
¿Qué pasa con los productos sin código de barras?
Son más comunes de lo que parece: en este caso, uno de cada cinco. Sin código de barras, el matcheo automático contra lo ya publicado falla y el producto aparecería como nuevo aunque esté online hace años. La solución fue buscar también por SKU en los canales. Es el tipo de caso borde que un proyecto serio releva al principio, porque ignorarlo genera duplicados.
Cómo encaramos la conexión de un sistema de gestión con IA en otros procesos lo contamos en integrar IA con tu ERP y en automatizar facturas con IA.