Industr-IA · Gestión del conocimiento
La empresa industrial no tiene un problema de datos. Tiene un problema de conocimiento que no está en ningún sistema: vive en la cabeza de personas que rotan, cogen bajas o cambian de empresa. Knowledge as a Service es la capa que lo retiene, lo hace consultable y lo convierte en la base de cualquier automatización con IA.
Respuesta rápida
Knowledge as a Service (KaaS) es un modelo en el que el conocimiento operativo de una empresa —sus reglas de negocio, criterios de decisión y excepciones— deja de estar disperso en personas, hojas de cálculo y código de integración, y pasa a vivir en una capa propia: explícita, versionada, gobernada y consultable en tiempo real por cualquier sistema o agente de IA. Su valor es doble: retiene el conocimiento frente a la rotación y las bajas, y hace posible automatizar con criterio, porque un agente solo puede aplicar reglas que alguien ha escrito antes.
El conocimiento que sostiene tu operativa no está en tu ERP
Hay una empresa de distribución técnica con 180.000 referencias en su ERP. Datos, tiene todos: stock, precios, escandallos, diez años de histórico.
Y sin embargo, cuando entra un pedido de su tercer cliente por facturación, hay un jefe de almacén que lo mira y decide no servirlo parcial. No está escrito en ningún procedimiento. Lo sabe porque hace nueve años ese cliente devolvió un camión entero.
Esa empresa no tiene ningún plan para el día que esa persona no esté. Y ese día puede llegar de siete maneras distintas: una jubilación, una baja larga, un cambio de turno, una oferta de la competencia, una reestructuración, una excedencia, un lunes cualquiera.
No es un problema demográfico. Es un problema estructural.
Dato, información y conocimiento no son lo mismo
La distinción no es académica. Explica exactamente qué sistema cubre qué, y dónde está el hueco.
| Nivel | Ejemplo real | Dónde vive hoy |
|---|---|---|
| Dato | La referencia 44-A tiene 320 unidades en el almacén 2. | ERP |
| Información | Ese stock cubre 11 días de demanda media. | BI / cuadro de mando |
| Conocimiento | Ese cliente no acepta entregas parciales, ese proveedor entrega tarde en agosto, y por debajo del 18% de margen hay que escalar a dirección. | En siete cabezas, cuatro hojas de cálculo y una cadena de correos de 2019 |
El conocimiento operativo de una empresa industrial no está en sus sistemas. Está en el margen que sus sistemas no supieron modelar.
El conocimiento se pierde por goteo, no solo por jubilación
La jubilación es el caso fácil: se ve venir con años de antelación y aun así casi nadie hace nada. El problema serio es el otro, el que no avisa.
- Rotación. Un responsable de compras se va a la competencia y se lleva veinte años de criterio sobre proveedores, plazos y excepciones.
- Bajas largas. Seis meses de ausencia en atención al cliente dejan a tres personas improvisando condiciones comerciales.
- Cambio de ERP. Se migran los datos. La lógica que los interpretaba se pierde entera.
- Reestructuraciones. Se prejubila al único que entendía el escandallo de la línea antigua.
- Crecimiento. Entra gente nueva más rápido de lo que el conocimiento se transmite, y el onboarding se convierte en aprendizaje por error.
En todos esos casos la empresa no pierde datos. Pierde la capacidad de interpretarlos. Y no lo detecta el día que ocurre: lo detecta seis semanas después, cuando aparecen errores que antes no aparecían y nadie sabe explicar por qué.
Hay un cálculo que casi ninguna dirección general ha hecho: cuántas decisiones operativas diarias dependen de una sola persona que no ha documentado nada. En la mayoría de industriales con los que trabajamos, esa cifra se sitúa entre el 20% y el 40% de la operativa crítica. Eso no es un equipo experimentado. Es una concentración de riesgo.
Por qué las integraciones clásicas no generan conocimiento
Llevamos años construyendo integraciones entre ERP y canal digital: SAP, Odoo, Microsoft Business Central, Sage, A3, AS/400. Y conviene decirlo con claridad: una integración mueve registros, no significado.
Sincronizas un artículo y llega el código, la descripción, el precio y el stock. No llega por qué ese artículo tiene tres precios distintos según cliente, ni qué condición logística lo excluye del envío gratuito, ni que su equivalencia técnica está en otra familia.
Esa lógica existe. Pero vive enterrada en el código del conector, en forma de condiciones, excepciones y parches acumulados durante tres años de proyecto. El resultado es una paradoja que reconocerá cualquiera que haya hecho una migración: el conocimiento más valioso de la operativa está escrito en un middleware que nadie del negocio puede leer.
Cuando esa lógica está enterrada, no se puede auditar, no se puede reutilizar en otro canal y desde luego no se le puede entregar a un agente de IA para que decida con ella. Es el mismo patrón que describimos en cómo automatizar la entrada de pedidos B2B y en la integración de un PIM: la tecnología está resuelta, el criterio no.
Qué es Knowledge as a Service en términos operativos
Knowledge as a Service consiste en sacar ese conocimiento de las cabezas y del código, y convertirlo en una capa propia de la empresa. No es un repositorio documental. No es un chatbot sobre tus PDFs.
Es una capa que cumple cuatro condiciones:
- Explícita. Las reglas de negocio están declaradas, no inferidas del comportamiento de un script.
- Contextual. Cada entidad —cliente, artículo, proveedor, pedido— arrastra su significado, sus relaciones y sus excepciones, no solo sus campos.
- Servida, no copiada. Los sistemas la consultan en tiempo real. No hacen una copia local que envejece en tres semanas.
- Gobernada. Se sabe quién puede escribir una regla, quién la aprueba y qué ocurre cuando cambia.
La diferencia con el enfoque tradicional es de propiedad. En un proyecto de integración clásico el conocimiento es un subproducto del desarrollo. En Knowledge as a Service el conocimiento es el producto, y la integración es lo que lo alimenta.
Las cuatro capas: así lo construimos en IntegrafyOS
eComm360 desarrolló Integrafy como plataforma de integración entre eCommerce y ERP. IntegrafyOS es lo que ocurrió cuando dejamos de tratar ese middleware como una tubería y empezamos a tratarlo como el lugar donde vive el conocimiento de la empresa.
| Capa | Qué resuelve |
|---|---|
| 1. Conectividad | Sincronización bidireccional con el ERP vía API, ficheros o base de datos: clientes, pedidos, catálogo, stock y precios. Imprescindible, pero por sí sola no es un producto. |
| 2. Normalización | PIM y modelo de datos común. Aquí 180.000 referencias dejan de ser 180.000 filas y pasan a tener estructura, atributos coherentes y relaciones. |
| 3. Contexto | La capa que marca la diferencia. Reglas de negocio declaradas fuera del código: condiciones por cliente, excepciones logísticas, umbrales de margen, equivalencias técnicas, criterios de escalado. |
| 4. Exposición | Servir ese conocimiento mediante MCP a quien lo necesite: un agente, un configurador, un asistente de cotización, una automatización de compras. Todos consultan la misma capa y obtienen la misma respuesta. |
La consecuencia práctica es la que buscábamos: cuando el criterio está declarado en un solo sitio, añadir un canal, un país o un agente deja de ser un proyecto y pasa a ser una configuración.
El orden importa: agentes sin capa de conocimiento es automatizar el error
La secuencia que se vende es: pon un agente, conéctalo a tus sistemas, mira el resultado. La secuencia que funciona es otra.
DATO → NORMALIZACIÓN → CONTEXTO → AGENTE
Un agente sobre datos crudos es un becario muy rápido con acceso a todo y criterio de nadie. Va a proponer servir parcial a ese cliente. Lo va a proponer con una confianza absoluta y una redacción impecable. Y va a estar equivocado, porque la regla que lo impedía nunca salió de la cabeza de una persona.
Automatizar un proceso roto no lo arregla: lo escala.
Por eso Knowledge as a Service no es una moda paralela a los agentes de IA. Es su requisito previo. Lo desarrollamos también en agentes de IA en eCommerce B2B y en dónde aplicar IA primero en un eCommerce industrial.
Un agente conectado a tu ERP sabe lo que hay. Un agente conectado a tu capa de conocimiento sabe qué hacer con ello.
Hay un efecto secundario que a nosotros nos parece el más relevante de todos: construir esta capa obliga a la empresa a escribir, por primera vez, cómo decide. Muchas descubren en ese ejercicio que no tenían una política, sino siete criterios distintos según quién estuviera de guardia.
La empresa tiene derecho a ese conocimiento, y la obligación de conservarlo
Hay una incomodidad cultural que conviene nombrar, porque frena más proyectos que cualquier limitación técnica: «me estáis pidiendo que escriba cómo hago mi trabajo para luego prescindir de mí».
Es una lectura comprensible. También es falsa, y hay que desmontarla con hechos.
El conocimiento operativo generado dentro de la empresa, en horario de trabajo, con sus clientes, sus máquinas y sus datos, es de la empresa. No es una opinión: es la base de cualquier política de continuidad de negocio, y es exactamente lo mismo que ya se asume con los planos, las fórmulas o el código fuente. Que ese conocimiento viva en una cabeza en lugar de en un sistema es un accidente histórico, no un derecho adquirido.
Y hay una lectura mucho mejor para el propio equipo. La persona que declara su criterio en un sistema deja de ser el cuello de botella al que llaman por teléfono los sábados. Se libera de la parte repetitiva de su conocimiento —las cien decisiones idénticas que toma cada semana— y se queda con la parte que requiere juicio real: las excepciones y los casos nuevos.
Sistematizar el conocimiento no sustituye al experto. Le quita el trabajo de repetirse.
Eso sí, con una condición honesta: la empresa debe comprometerse a que quien aporta su conocimiento no queda peor situado por hacerlo. Sin eso, el proyecto no arranca. Y con razón.
Antes de firmar: ¿de quién es esa capa?
Si vas a sacar el criterio operativo de tu empresa de la cabeza de tus veteranos y meterlo en una capa de software, hay tres preguntas que responder antes de firmar nada:
- Dónde reside esa capa y bajo qué jurisdicción.
- Quién puede exportarla, en qué formato y con qué frecuencia.
- Qué te llevas exactamente el día que cambias de proveedor.
Una capa de conocimiento va a ser el activo más estratégico que construya tu empresa en la próxima década. Externalizarla sin portabilidad no es eficiencia: es dependencia con otro nombre. Lo decimos siendo parte interesada, porque nosotros vendemos esto. Y aun así, la primera pregunta que debería responderte cualquier proveedor —nosotros incluidos— es cómo te devuelve tu conocimiento el día que decidas irte.
Por dónde empezar: cuatro pasos realistas
- Mapea la concentración de riesgo. Lista las decisiones operativas diarias y marca cuáles dependen de una sola persona. Ese es tu punto de partida, no un plan tecnológico.
- Empieza por un proceso, no por la empresa. Entrada de pedidos, condiciones comerciales o gestión de excepciones logísticas. Uno solo, entero.
- Declara las reglas fuera del código. Que negocio pueda leerlas, discutirlas y cambiarlas sin abrir un ticket de desarrollo.
- Solo entonces, conecta agentes. Con supervisión humana en las decisiones que superen un umbral de importe, margen o riesgo de cliente.
Preguntas frecuentes sobre Knowledge as a Service
¿Qué es Knowledge as a Service?
Es un modelo en el que el conocimiento operativo de una empresa —reglas de negocio, criterios de decisión y excepciones— se extrae de las personas y del código, y se estructura en una capa propia: explícita, versionada, gobernada y consultable en tiempo real por sistemas y agentes de IA.
¿En qué se diferencia de un gestor documental o de una intranet?
Un gestor documental almacena archivos para que los lean personas. Una capa de Knowledge as a Service almacena reglas y contexto estructurados para que los ejecuten sistemas. La diferencia práctica: un PDF no puede impedir que se confirme un pedido que incumple una condición del cliente; una regla declarada, sí.
¿Es lo mismo que un PIM?
No. Un PIM normaliza la información de producto: atributos, relaciones, contenidos. Es la capa 2 de cuatro. Knowledge as a Service añade encima el contexto de negocio —condiciones por cliente, excepciones, umbrales de decisión— y su exposición a los agentes. El PIM es requisito, no sustituto.
¿Cuánto tarda en implantarse?
Sobre una integración ERP ya existente, un primer proceso acotado —entrada de pedidos o condiciones comerciales— se declara y se pone en producción en un plazo de 8 a 12 semanas. Sin integración previa, el proyecto arranca por la capa de conectividad y el plazo depende del ERP.
¿Puede una pyme industrial aplicarlo?
Sí, y a menudo con más urgencia que una gran empresa, porque su concentración de riesgo es mayor: en una pyme de 40 personas, perder a dos veteranos puede paralizar la operativa. El enfoque no cambia; cambia el alcance del primer proceso.
¿Qué pasa con la protección de datos y el EU AI Act?
Una capa de conocimiento bien construida facilita el cumplimiento en lugar de dificultarlo: las reglas están declaradas, versionadas y son auditables, lo que permite explicar por qué un sistema tomó una decisión concreta. Ese requisito de trazabilidad es exactamente lo que exige la normativa europea a los sistemas de IA de riesgo alto.
¿Sustituye la IA a los expertos de la empresa?
No. Absorbe la parte repetitiva de su conocimiento —las decisiones idénticas que toman cada semana— y les devuelve tiempo para las excepciones y los casos nuevos, que es donde su criterio aporta valor real.
Siguiente paso
¿Cuántas decisiones de tu empresa dependen hoy de una sola persona?
Analizamos tu operativa, identificamos dónde está concentrado el conocimiento crítico y te proponemos el primer proceso a declarar. Sin compromiso.
El conocimiento operativo es la única ventaja que no se puede comprar hecha. Está en tu casa, disperso, sin escribir, y sujeto a que las personas que lo sostienen sigan ahí el mes que viene.
Convertirlo en una capa consultable no es un proyecto de IT. Es una política de continuidad de negocio que además resulta ser el prerrequisito de todo lo que quieras automatizar después.
Integrado, automatizado, rentable.
