15 de mayo de 2026 · Pedro Aldea
Estandarizar antes de automatizar: por qué un catálogo desordenado hace fracasar la IA
El paso 2 del Zero Friction Method es estandarizar. Sin esto, la automatización amplifica el caos y la IA aprende los errores. Aquí está cómo se hace en una operación real.
Estandarizar antes de automatizar es lo que separa los proyectos de IA que escalan de los que se atascan en piloto. Cuando una empresa tiene la misma marca escrita de cuatro maneras distintas (BOSCH, Bosh, BOCH S.A., B0SCH), poner IA encima produce una respuesta probabilística: funciona el 80% de las veces, falla el 20%, y el 20% que falla es estructural — las marcas con menos ejemplos. Estandarizar no es imponer rigidez; es definir tres cosas en orden: el canónico (cuál es la versión por defecto), las reglas de excepción (qué es variante a colapsar y qué es excepción real), y el mecanismo de mantenimiento (quién decide cuándo entra una grafía nueva). Cuando esos tres elementos están en su sitio, la IA del paso 5 hace lo que ningún sistema determinista puede: matching de variantes nuevas contra un canónico ya definido. Lo difícil — decidir cuál es ese canónico — no lo hace una herramienta, lo decide un director de operaciones.
Cuando alguien intenta vender una solución de IA encima de eso, lo que ocurre es predecible: la IA aprende cuatro entidades distintas. El comercial sigue sin poder buscar. El responsable de compras sigue sin poder comparar. Y el reporting de ventas por marca sigue sin existir, porque para el sistema son cuatro marcas distintas.
Ese es el paso 2 del Zero Friction Method: estandarizar. Y es el que separa los proyectos que escalan de los que se atascan en piloto.
Por qué la automatización no es la respuesta primero
La narrativa fácil dice “hay un problema de datos sucios, montemos un sistema de limpieza automática con IA”. Esa narrativa funciona en el deck. No funciona en la operación.
Limpiar variantes con un modelo encima de un catálogo heterogéneo da una respuesta probabilística. Funciona el 80% de las veces, falla el 20%, y el 20% que falla es estructural: las marcas con menor frecuencia, las que no tienen suficientes ejemplos para que el modelo las agrupe bien. El comercial que busca una pieza de un fabricante pequeño sigue sin encontrarla. El responsable de compras sigue sin saber si la nueva entrada del proveedor es la marca que ya tenía en otra forma.
Y la IA, al confirmar matches con confianza, introduce un nuevo problema: errores difíciles de auditar. Antes el catálogo estaba sucio pero el responsable de catálogo lo sabía. Ahora está semi-limpio y nadie sabe exactamente qué está colapsado y qué no.
La estandarización no se hace primero con IA. Se hace primero con decisión humana.
Qué significa estandarizar, en concreto
Estandarizar no es imponer rigidez. Es definir tres cosas, en este orden:
Primero, el canónico. Para cada categoría de variación, escribir cuál es la versión por defecto. BOSCH (todo mayúsculas, sin S.A., sin sufijo). El canónico se decide en una reunión de 30 minutos con el responsable de catálogo, no en un comité de seis personas. Se documenta en una tabla, no en un PDF.
Segundo, las reglas de excepción. Para cada caso que no encaje en el canónico, definir si es una excepción real (existe una razón presente) o una variante a colapsar (es la misma entidad escrita distinto). Las excepciones reales son pocas. Las variantes a colapsar son la mayoría.
Tercero, el mecanismo de mantenimiento. Cuando entre una factura nueva con una grafía nueva, ¿quién decide si es excepción o variante? La respuesta correcta no es “la IA”. La respuesta correcta es: una persona del equipo, con una herramienta que le muestra la grafía nueva al lado de las grafías existentes y le pide una decisión binaria. La IA puede sugerir, pero la persona decide.
Cuando esos tres elementos están en su sitio, la IA del paso 5 hace lo que tiene que hacer: matching de variantes nuevas contra el canónico ya definido. Lo difícil ya está resuelto.
Lo que pasa cuando esto se hace bien
Cuando el catálogo de un distribuidor industrial pasa por este ejercicio, lo primero que aparece son cifras incómodas. Cientos de marcas con variaciones múltiples. Cientos de miles de referencias sin categorizar. Tablas históricas desconectadas del inventario actual. Y la pregunta que nadie quería hacerse: ¿hace cuántos años deberíamos haber hecho esto?
Una vez se ataca con orden, el resultado se ve en la operación, no en el deck. El comercial busca “BOSCH” y aparece todo el inventario asociado, con independencia de cómo lo introdujera quien lo metió en 2015. El responsable de compras compara precios entre proveedores sobre la misma SKU, no sobre cuatro entidades distintas. El reporting de ventas por marca, que llevaba años siendo aproximado, empieza a ser exacto. Y la venta cruzada, que hasta entonces era manual y dependía de la memoria de los comerciales veteranos, se convierte en una sugerencia automática basada en datos que ya están limpios.
Lo escribimos con detalle en el caso de categorización de productos, donde más de tres millones de filas en quinientas tablas pasaron por este proceso. Lo importante de ese caso no son las cifras, son las decisiones humanas previas que hicieron posible que la cifra existiera. Sin ellas, el pipeline técnico habría producido un resultado peor con más esfuerzo.
Por qué se salta tan a menudo
Estandarizar es trabajo poco glamuroso. No se vende en pitches porque no hay diapositiva atractiva para un canónico de marca. Nadie hace presentaciones de casos de éxito sobre tres meses de limpieza de catálogo, aunque sea exactamente eso lo que hace que el proyecto de IA posterior funcione o no.
Y hay otro motivo, más profundo: estandarizar exige tomar decisiones que llevaban años posponiéndose. ¿Aceptamos que esa marca antigua deja de aparecer con su grafía histórica? ¿Decidimos que el formato de factura del proveedor X tiene que aterrizar al canónico en el momento de entrada, no después? ¿Asumimos que el responsable de catálogo tiene autoridad para colapsar variantes sin pedir permiso por cada caso?
Esas decisiones no las toma una herramienta. Las toma un director de operaciones. Y son las que liberan todo lo que viene después.
Cuándo viene la IA
Cuando el canónico está definido, las reglas de excepción están escritas, y el mecanismo de mantenimiento está activo, la IA del paso 5 entra a hacer lo que ningún sistema determinista puede: matching de variantes nuevas que no encajan exactamente en ninguna grafía conocida. Una marca que llega escrita en una forma nunca vista antes, con una falta de ortografía, con un sufijo que el regex no contemplaba, con un acento que el sistema antiguo no reconocía.
Para eso, la IA es la herramienta correcta. Para definir el canónico, no. Para decidir qué es excepción y qué es variante, tampoco. Para asegurar que el equipo del cliente puede mantener el sistema cuando nos vamos, mucho menos.
Estandarizar antes de automatizar no es un detalle metodológico. Es la diferencia entre un proyecto que escala y uno que se queda en piloto. ¿Cuántas variantes de la misma entidad conviven hoy en vuestra base de datos sin que nadie haya decidido oficialmente cuál es el canónico?
Si vuestra empresa tiene un catálogo, una base de proveedores o una tabla de clientes con años de variantes acumuladas y queréis saber qué se puede colapsar antes de meter IA encima, el diagnóstico operativo de 2 semanas deja por escrito el canónico recomendado y las decisiones de estandarización por orden de impacto.