Las empresas llevan años ordenando y estructurando sus datos. Pero el conocimiento necesario para interpretarlos y hacerlos accionables también importa, y ahora más. Existe una experiencia común en cualquier organización que haya contratado alguna vez a alguien excelente. Llega una persona con un currículum impecable y unas ganas conmovedoras de resultar útil, y durante las primeras semanas es asombrosamente inútil. No por falta de talento o de acceso a los datos. Simplemente ignora que ese cliente lleva años quejándose por sistema, que aquel procedimiento dejó de aplicarse o que hay una persona cuya aprobación no figura en ningún organigrama, pero sin la cual no se mueve nada. Le falta el contexto.

Esta experiencia se repite ahora con los agentes de IA. Tienen datos, acceso a aplicaciones y documentos y, aun así, devuelven respuestas que cualquiera con experiencia reconoce como incompletas cuando no directamente equivocadas. Saben qué pasa, pero no qué significa.

Consideremos una factura pendiente de cobro. El sistema financiero tiene cliente, importe, vencimiento y estado. Con eso podemos saber qué facturas están vencidas. Pero si pedimos a un agente que decida qué hacer, la situación cambia.

Para saber si debe reclamar, escalar o esperar necesita conocer cosas que no aparecen en ninguna columna: si el cliente es estratégico, si existe un acuerdo comercial, si hay una incidencia abierta, si se aprobó una excepción o quién tiene autoridad, de verdad y no sobre el papel, para decidir.  

El dato dice que la factura lleva veinte días vencida. El contexto indica que no conviene reclamarla todavía. 

 

Del Data Warehouse al Context Warehouse 

Llevamos décadas construyendo ERP, CRM, Data Warehouses y Data Lakes para responder a una pregunta: ¿qué está pasando en mi negocio? El Data Warehouse integra información de sistemas distintos, la estructura y permite analizarla.

La IA necesita responder a otra: ¿qué significa lo que está pasando y qué debería hacerse ahora? Hacen falta políticas, procedimientos, contratos, relaciones entre entidades, histórico de decisiones, permisos, excepciones y reglas de negocio. Todo eso que llamamos, con una palabra deliberadamente amplia, contexto y, por analogía, Context Warehouse. 

Pero un Context Warehouse no es un almacén de documentos más grande. Es la base que permite poner a disposición de personas y sistemas el conocimiento necesario para que los datos sean accionables.  

Entregar a un agente veinte documentos irrelevantes no es darle más contexto, es darle más ruido. También un empleado rendiría peor si junto al expediente le pusiéramos la guía telefónica.

La diferencia es importante porque un chatbot responde preguntas, pero un agente interpreta la situación y actúa sobre otros sistemas. Cuanto mayor es su capacidad de actuar, más peligroso resulta que se equivoque. Desplegar agentes, por tanto, no consiste sólo en darles más datos y herramientas, sino en decidir qué pueden saber y qué reglas limitan lo que pueden hacer.

Resulta tentador pensar que la siguiente generación de modelos resolverá esta conexión. Más razonamiento, ventanas de contexto mayores, agentes mejores... Y ayudará, sin duda, pero hay una parte del problema que no pertenece a los modelos. OpenAI, Anthropic, Google o quien venga después pueden saber muchísimo sobre el mundo. Lo que no pueden es saber cómo funciona tu empresa si tú no eres capaz de explicárselo. Las excepciones no documentadas o la autoridad real para decidir son conocimiento de la empresa. 

 

¿Cómo?

Sin entrar en conceptos demasiado técnicos, construir contexto consiste en identificar de manera unívoca a clientes, contratos o proveedores; describir cada pieza de conocimiento con metadatos; representar las relaciones entre entidades; convertir las reglas de negocio en decisiones explícitas; y registrar cada decisión junto con su motivo. Además, hay que especificar qué contexto debe recuperarse en cada caso, porque un agente no necesita acceder a todo.

 

Por dónde empezar

Desde luego, no construyendo un enorme repositorio corporativo del conocimiento, que es la clase de proyecto que se inaugura con entusiasmo y se abandona con discreción. Empezaría por un proceso concreto: cobros, compras, cierre financiero, atención al cliente o gestión de incidencias. Uno, el que más rabia te dé.

Elegiría una decisión que hoy exija conocimiento repartido por media empresa y reconstruiría lo necesario para tomarla bien: qué datos consultar, qué documentos utilizar, qué reglas aplicar, qué excepciones conocer, a quién preguntar y qué permisos hacen falta para actuar. Este ejercicio enseña muy deprisa qué parte del conocimiento está estructurada y qué parte sigue viviendo en documentos dispersos, correos supervivientes y cabezas concretas que algún día ya no estarán.

Desde RSM trabajamos en ese punto: orientando a nuestros clientes a que sus datos y conocimiento puedan ser utilizados de forma fiable por sistemas y agentes de inteligencia artificial, y definiendo la hoja de ruta más adecuada.

Porque reunir los datos fue el trabajo de la década pasada. Explicar qué significan y hacerlos accionables es ya de esta. 

 

Autor:  Luis Carrasco, del equipo de Process & Data Analytics