Si en el último año participó de un piloto de IA que se veía prometedor en la demo y decepcionante en producción, no está solo. Y probablemente el diagnóstico que le dieron fue equivocado.
Neo4j publicó hace poco un artículo que lo plantea sin rodeos: la IA empresarial no fracasa por el modelo. Fracasa porque el agente no entiende el negocio.
Vale la pena detenerse en eso, porque cambia por completo dónde hay que invertir.
El significado que nunca se escribió
Toda organización opera sobre una enorme cantidad de conocimiento tácito. Reglas que todos conocen pero nadie documentó. Excepciones que se aplican “porque siempre fue así”. Campos cuyo nombre no dice lo que realmente significan.
El ejemplo que usa el artículo es perfecto por lo cotidiano: en una base de datos, status = 2 puede significar “suspendido en revisión”. Esa equivalencia existe en el código de la aplicación y en la cabeza de un par de analistas. No está escrita en ningún lado donde un agente pueda encontrarla.
Multiplique eso por cada tabla, cada proceso y cada excepción de su operación. Ese es el terreno sobre el que le está pidiendo a una IA que tome decisiones.
El resultado es predecible: respuestas que suenan bien y están mal. Y algo peor, suenan lo suficientemente bien como para que nadie las cuestione a tiempo.
El error intuitivo: darle contexto a cada agente
La reacción natural es cargarle a cada agente el contexto que necesita. Funciona con el primero. Con el segundo también.
El problema aparece en el quinto: ahora hay cinco copias privadas de las reglas del negocio, mantenidas por equipos distintos, que empiezan a divergir. Alguien actualiza una política en un lado y no en los otros cuatro. El artículo lo llama duplicación semántica, y describe algo que probablemente usted ya vio con las integraciones y los reportes: cada área con su propia versión de la verdad, y reuniones enteras dedicadas a decidir cuál es la correcta.
La alternativa: una capa de conocimiento
La propuesta es invertir el orden. En lugar de agentes pesados cada uno con su contexto, agentes livianos sobre un sustrato compartido y gobernado. Una sola capa donde vive el conocimiento de la organización, que todos consultan.
Esa capa tiene tres partes:
- La ontología: Un mapa vivo y ejecutable del negocio: sus conceptos, sus procesos, sus políticas, y cómo cada uno se conecta con los sistemas reales donde viven los datos. No un diagrama en una presentación: un modelo que se consulta en tiempo real.
- Los datos: Los valores controlados, los datos maestros y los transaccionales que instancian ese modelo.
- La memoria: El rastro de lo que ya se decidió. Cada ejecución deja una traza, y el siguiente agente hereda lo aprendido en las mil ejecuciones anteriores.
Una formulación del artículo lo resume bien: la ontología guarda lo que es posible; la memoria guarda lo que está probado.
Por qué un grafo, y no solo búsqueda vectorial
La mayoría de las implementaciones de IA sobre documentos usan búsqueda vectorial: se convierten los textos en vectores y se recuperan los fragmentos más parecidos a la pregunta.
Funciona bien para encontrar contenido relacionado. Pero tiene un límite estructural: encuentra parecido, no relación. Puede traerle tres documentos que hablan de facturación sin poder decirle que el primero derogó al segundo, o que la política que menciona el tercero solo aplica a una filial.
El conocimiento organizacional es, por naturaleza, una red de relaciones: conceptos que dependen de conceptos, mapeados a sistemas, envueltos en políticas, con un historial de quién cambió qué. Esa forma es la de un grafo.
El enfoque que combina ambas cosas, recuperación vectorial más grafo de conocimiento, se conoce como GraphRAG. Neo4j cita investigación independiente según la cual mejora sustancialmente la veracidad de las respuestas de un agente frente a los enfoques que no lo usan.
Qué significa esto si su negocio construye software
Acá es donde el tema deja de ser abstracto para nosotros.
En desarrollo de software, ese “significado que nunca se escribió” tiene una dirección exacta: está en el código, en la documentación dispersa y en el historial de tickets. Las reglas de negocio de verdad, las que se aplican, no las que están en el manual, viven en funciones que alguien escribió hace cuatro años y en decisiones que quedaron registradas en un comentario de un ticket cerrado.
Por eso una IA que escribe especificaciones sin acceso a eso produce documentos plausibles y poco útiles. Especifica en el vacío: propone construir lo que ya existe, ignora dependencias que van a romperse, y no puede advertir sobre el módulo que nadie recuerda que también consume ese servicio.
Cómo lo resolvimos en Tinet
GenDEV, el agente de especificación de nuestra Suite Loica, se apoya en una base de conocimiento construida exactamente sobre esta lógica.
Combina búsqueda vectorial con un grafo de dependencias, construido sobre Neo4j, que modela los módulos, las APIs, los datos y los flujos de trabajo de cada cliente. Dos capas de fundamento en lugar de una. La indexación es privada por cliente, con aislamiento total, y se sincroniza de forma continua con el repositorio: cuando el código cambia, el conocimiento cambia con él.
El efecto práctico es concreto. Cuando GenDEV lleva una idea de negocio hasta un diseño técnico, cada especificación se valida contra el código que realmente existe: identifica componentes reutilizables y detecta qué módulos se verán impactados, antes de que alguien escriba una línea.
Y una decisión de diseño que consideramos innegociable: en cada etapa hay una persona que revisa y aprueba. El agente propone; el criterio profesional decide. Es exactamente el principio que el propio artículo defiende — los LLM aceleran la adquisición de conocimiento, los humanos lo ratifican.
Si quiere empezar por algún lado
Tres cosas que puede hacer sin comprar nada:
- Identifique su semántica escondida. Junte a sus analistas y pregunte qué reglas conocen que no estén documentadas. La lista suele ser incómodamente larga, y ese es el punto.
- Cuente sus copias de la verdad. ¿Cuántos sistemas, reportes o agentes tienen su propia definición de “cliente activo”? Cada divergencia es un lugar donde su IA se va a equivocar con confianza.
- No empiece por el modelo. La pregunta útil no es qué LLM usar, sino sobre qué conocimiento va a razonar y quién responde por mantenerlo.
Para cerrar
La conclusión de Neo4j es la que mejor resume el punto: la inteligencia se volvió un commodity; el conocimiento es la ventaja competitiva. Los modelos van a seguir mejorando para todos por igual. Lo que su competencia no puede copiar es el conocimiento de su operación, bien modelado y disponible para sus agentes.
Nosotros construimos GenDEV sobre esa convicción. Si le interesa conversar sobre cómo se vería aplicado a su realidad, escríbanos. La primera conversación es un diagnóstico, no una demo.
