Sin arquitectura de contexto, los agentes solo automatizan tu ignorancia organizacional
Un agente sin acceso al conocimiento real de la organización produce respuestas genéricas con tono de autoridad. El problema no es el modelo: es que el conocimiento de la empresa no existe en ninguna forma que una máquina pueda consultar.
Una organización despliega un asistente conectado a sus documentos internos. Las primeras semanas generan entusiasmo. Después empiezan las quejas: las respuestas son genéricas, a veces contradicen procedimientos vigentes, y con frecuencia son correctas en general pero equivocadas para esta empresa en particular.
El diagnóstico habitual apunta al modelo: hay que cambiarlo, ajustarlo, mejorar los prompts. Rara vez es ahí donde está el problema.
El problema suele ser que el conocimiento que la organización necesita que el agente use no existe en ninguna forma consultable. Existe en la cabeza de siete personas, en hilos de correo, en decisiones tomadas en reuniones sin acta, en convenciones que todos siguen y nadie escribió. El agente no puede consultar nada de eso, así que responde con lo que sabe del mundo en general.
De ahí una formulación que conviene tener presente antes de cualquier despliegue: sin arquitectura de contexto, los agentes solamente automatizan la ignorancia organizacional.
Qué es la arquitectura de contexto
Es el conjunto de decisiones sobre qué conocimiento organizacional existe en forma recuperable, cómo está estructurado, quién lo mantiene y bajo qué permisos se accede.
No es lo mismo que tener documentación. Una organización puede tener miles de documentos y ninguna arquitectura de contexto, si esos documentos están desactualizados, duplicados con versiones contradictorias, sin fecha, sin dueño y dispersos en cuatro sistemas distintos.
Los componentes que la hacen funcionar son concretos:
Conocimiento en formato consultable. Texto estructurado, con metadatos, en sistemas con interfaz de consulta. No capturas de pantalla de procedimientos ni presentaciones con la información en imágenes.
Fuente única para cada concepto. Un procedimiento vigente y una forma de saber que es el vigente. La duplicación con divergencia es peor que la ausencia, porque produce respuestas seguras y equivocadas.
Fecha y dueño. Todo artefacto de conocimiento con fecha de última revisión y un responsable identificable. Sin eso no se puede distinguir lo vigente de lo histórico.
Decisiones registradas. No solo qué hacemos, sino por qué. El conocimiento sobre las razones es el que más rápido se pierde y el que más determina si una decisión nueva será coherente con las anteriores.
Permisos alineados con la clasificación. Qué puede consultar quién, y por extensión, qué puede consultar un agente que actúa en nombre de quién.
El repositorio como sistema de registro
Hay una práctica que las organizaciones de software descubrieron por necesidad y que resulta generalizable: convertir el repositorio en el sistema de registro del conocimiento técnico.
La experiencia de equipos que operan agentes sobre sistemas complejos apunta consistentemente en esa dirección: hacer que el conocimiento del repositorio sea la fuente de verdad fue una condición para que los agentes pudieran trabajar de forma confiable.
El motivo tiene que ver con propiedades que el repositorio tiene y una carpeta compartida no: historial completo, autoría de cada cambio, revisión antes de integrar, cercanía física al artefacto que describe, y accesibilidad programática. Todas esas propiedades son exactamente las que un agente necesita para operar con contexto confiable.
Esto no significa que toda la organización deba mudar su conocimiento a un repositorio de código. Significa que las propiedades importan: versionado, autoría, revisión, proximidad al trabajo y accesibilidad para máquinas. Cualquier sistema que las provea sirve.
El costo de no tenerla
Sin arquitectura de contexto pasan cuatro cosas, todas caras.
Las respuestas son genéricas y suenan expertas. Esta combinación es peligrosa. Una respuesta genérica marcada como genérica es útil. Una respuesta genérica presentada con la confianza de quien conoce el caso induce decisiones equivocadas.
El conocimiento tácito sigue siendo un cuello de botella. Las mismas siete personas siguen siendo indispensables, y ahora además hay un sistema que compite con ellas sin tener su información.
No se puede auditar de dónde salió una respuesta. Cuando alguien pregunta en qué se basó una recomendación, la trazabilidad se corta en el modelo.
La organización confunde el problema. Invierte en cambiar de modelo o de proveedor cuando el problema es que su conocimiento no está escrito. El resultado es una serie de migraciones caras que no mejoran nada.
Por dónde se empieza
La forma que rinde es empezar por el uso, no por el catálogo completo.
Elige un caso de uso concreto y valioso: responder consultas de un procedimiento operativo, orientar a alguien que se incorpora, resolver preguntas frecuentes de clientes. Para ese caso, identifica exactamente qué conocimiento hace falta. Va a ser mucho menos de lo que parece: normalmente entre diez y treinta artefactos.
Para esos artefactos, haz el trabajo completo: verifica que estén vigentes, asigna dueño, ponles fecha, elimina duplicados, escribe lo que estaba solamente en la cabeza de alguien. Después conéctalos al agente.
La diferencia en calidad de respuesta va a ser inmediata y perceptible. Y esa diferencia es el argumento para hacer el mismo trabajo en el siguiente caso de uso. Es una estrategia incremental que produce valor en cada paso, a diferencia de un proyecto de gestión del conocimiento que promete valor al final y muere a mitad de camino.
El conocimiento que hay que escribir primero
Cuando una organización decide poner por escrito lo que estaba en la cabeza de la gente, la pregunta inmediata es por dónde. El instinto lleva a documentar procedimientos, que es la categoría de menor rendimiento.
Los procedimientos suelen ser lo más fácil de reconstruir por observación y lo que menos determina la calidad de una decisión. Hay cuatro categorías que rinden bastante más.
Las razones detrás de las reglas. Por qué este proceso tiene este paso, por qué ese cliente tiene condiciones distintas, por qué no se hace de la forma obvia. Sin las razones, cualquiera —persona o agente— aplica la regla fuera de contexto o la elimina por considerarla arbitraria.
Las excepciones y sus criterios. Casi todo procedimiento organizacional tiene casos donde no aplica. Ese conocimiento es el que distingue a alguien con experiencia de alguien que sigue el manual, y es el que casi nunca está escrito.
Lo que se intentó antes y no funcionó. El histórico de intentos fallidos evita repetirlos. Es información que solo tienen quienes estaban entonces y que desaparece con la rotación.
Las relaciones entre entidades. Qué implica que un cliente esté en cierto estado, qué desencadena qué, qué depende de qué. Es el contexto que permite razonar en vez de responder por coincidencia de palabras.
Hay una forma eficiente de capturar las cuatro sin lanzar un programa de gestión del conocimiento: registrar las preguntas que se hacen.
Durante un mes, cada vez que alguien tiene que preguntarle algo a otra persona para poder avanzar, se anota la pregunta. Al final del mes hay una lista de preguntas reales, ordenada por frecuencia. Las que más se repiten son exactamente el conocimiento que falta documentar, y están formuladas en el lenguaje en que efectivamente se preguntan.
Ese método tiene dos ventajas sobre el enfoque de catalogar. Produce una lista corta y priorizada por demanda real en vez de por criterio de completitud. Y captura las preguntas tal como se hacen, que es como un agente también las va a recibir, en vez de como alguien cree que deberían formularse.
La pregunta previa a cualquier despliegue
Antes de conectar un agente a los datos internos de tu organización, hay una pregunta que ahorra meses de frustración:
Si una persona nueva, competente, tuviera acceso a todo lo que este agente va a poder consultar y nada más, ¿podría hacer bien este trabajo?
Si la respuesta es no —porque le faltaría contexto que solo se transmite hablando con alguien—, entonces el agente tampoco va a poder. Y ninguna mejora de modelo va a cubrir esa brecha, porque no es una brecha de capacidad. Es una brecha de información.