Un operador de turno en una planta concentradora enfrenta una parada no programada. El SOP dice A, pero él recuerda que hace ocho meses se hizo B porque había una anomalía en un equipo aguas arriba, y B funcionó mejor. Toma la decisión, la planta vuelve a marcha, el turno termina.
La decisión queda registrada, en el mejor de los casos, en un correo. Más probablemente, en una conversación por radio y en la bitácora manuscrita del turno. El razonamiento detrás —por qué B y no A, qué contexto histórico lo justificaba, qué señales se observaron— vive exclusivamente en la cabeza del operador. Cuando se jubile, se lleva eso consigo.
Este patrón se repite en cada operación minera con la que trabajamos. No es un problema de sistemas: SAP, Ellipse, Maximo y las capas de BI están ahí y funcionan bien para lo que fueron diseñados. El problema es que el conocimiento operacional no tiene dónde vivir. Los ERPs capturan transacciones, los historiadores capturan señales, los sistemas de mantenimiento capturan órdenes. Nadie captura el razonamiento.
En los proyectos que hemos llevado en los últimos dos años, identificamos cuatro bolsones recurrentes donde el conocimiento se evapora:
SOPs desactualizados y procedimientos informales. El documento oficial dice una cosa; el terreno hace otra. La divergencia no es indisciplina, suele ser una adaptación razonable a condiciones que el SOP no previó. Pero esa adaptación nunca vuelve al SOP.
Mapeos de datos en integraciones SAP. Cada proyecto de integración acumula decenas de decisiones de mapeo con lógica de negocio detrás. “Este campo se trunca porque en 2019 descubrimos que el sistema origen devolvía basura cuando superaba 40 caracteres.” Dos años después, nadie recuerda el por qué. El código sobrevive; el razonamiento no.
RFIs y especificaciones técnicas en licitaciones. Una licitación grande genera cientos de documentos, preguntas y respuestas. Contradicciones entre versiones, requisitos mutuamente excluyentes, decisiones que cambiaron a mitad del proceso. Detectarlas manualmente antes de firmar la propuesta es trabajo que casi nadie hace bien.
Reuniones operativas. Fathom, Teams y Zoom graban todo. Pero una grabación de 47 minutos no es conocimiento: es materia prima. Las decisiones que se tomaron, los compromisos que se asumieron, las contradicciones con reuniones previas —todo eso requiere un paso de síntesis que rara vez ocurre.
MiniBrain es la plataforma sobre la que hemos consolidado este trabajo. No es un chatbot ni una wiki: es una plataforma multi-agente con varias capas que cooperan, y una de esas capas —la que importa para este post— se dedica específicamente a acumular y estructurar conocimiento operacional.
Sin envolverlo en marketing, esto es lo que hace en concreto:
Síntesis automática de material bruto. Transcripciones de reuniones (Fathom), correos, documentos cargados, conversaciones operativas. El sistema extrae decisiones, compromisos, entidades (proyectos, equipos, personas) y los archiva en páginas de conocimiento interconectadas. Una reunión de una hora produce típicamente 3–8 actualizaciones distribuidas en distintas páginas, no un resumen monolítico.
Detección de contradicciones. Cuando una entrada nueva contradice conocimiento previo, el sistema no la sobreescribe: la marca como supersesión con historial. Un requerimiento que cambió entre la reunión del lunes y la del jueves queda registrado como cambio, con fecha, fuente y razón. Esta es la parte que Karpathy llama lint y que, en implementaciones caseras del patrón, suele ser la primera que se abandona porque es la más tediosa.
Separación dura por cliente y proyecto (multi-tenancy). El conocimiento de un cliente minero no toca el de otro. No por cortesía: por diseño de base de datos. Row-level security a nivel de PostgreSQL, separación explícita en los embeddings y validación en cada consulta. Para operaciones con exigencias de confidencialidad —que son prácticamente todas en minería— esto no es opcional.
Wiki curada + recuperación híbrida. Seamos honestos sobre algo que a veces se simplifica en el discurso público: una wiki generada por LLM es excelente para conocimiento curado, consolidado y relativamente acotado. Para corpus grandes e inmutables —normativas, históricos de incidentes, documentación técnica de proveedores— RAG con embeddings sigue siendo la respuesta correcta. MiniBrain usa ambos, y el sistema decide cuál consultar según el tipo de pregunta. No son enfoques en competencia, son herramientas distintas.
Integración con el flujo de trabajo real. Lo que más frena una herramienta de gestión del conocimiento no es la tecnología, es el paso manual de cargar información. MiniBrain se alimenta en el flujo natural: MCP conectado al calendario, al correo, a los documentos, a las reuniones. El operador no tiene que recordar actualizar nada.
Llevamos aproximadamente ocho meses con MiniBrain en uso real, primero en nuestras propias operaciones y después incorporando paulatinamente contextos de cliente. Algunas lecciones que vale la pena compartir:
El lint automático es lo que separa una wiki viva de una wiki muerta. Sin detección y resolución de contradicciones, el sistema acumula ruido y pierde credibilidad rápido. Los operadores dejan de consultar lo que no saben si es verdad.
La granularidad importa más que el volumen. Una página por entidad conceptual (un equipo crítico, un contrato, una decisión de arquitectura) funciona mejor que páginas largas por proyecto. Lo contamos en cifras que no tratamos de inflar: nuestra wiki interna tiene 18 páginas estructurales vivas respaldadas por cientos de ingestas. No es mucho. Es lo que cabe mantener sano.
La wiki no reemplaza al documento oficial. El SOP firmado sigue siendo el SOP firmado. La wiki captura el contexto vivo alrededor de ese SOP: las desviaciones observadas, las razones documentadas, los casos límite. Cuando corresponde, ese contexto vuelve al SOP a través de un proceso humano de revisión. El LLM no modifica la política de la empresa.
El 4 de abril, Andrej Karpathy publicó en GitHub un gist llamado “LLM Wiki” que se volvió viral: al momento de escribir este post tiene más de 5.000 estrellas y unos 4.700 forks. Describe en términos conceptuales un patrón donde un agente LLM mantiene una colección de archivos markdown como base de conocimiento compilada, con tres capas (fuentes inmutables, wiki generada, archivo de esquema tipo CLAUDE.md) y tres operaciones (ingest, query, lint).
Karpathy es claro en que es un idea file, no un producto: un patrón pensado para uso personal con Claude Code u OpenAI Codex, explícitamente abstracto para que cada quien lo instancie según su contexto.
El patrón que describe es sólido y coincide en varios puntos con decisiones arquitectónicas que veníamos tomando en MiniBrain, sobre todo la separación entre fuentes inmutables y conocimiento sintetizado, y la operación de lint como ciudadano de primera clase. También vimos aparecer, predeciblemente, una ola de titulares proclamando el fin de RAG. El propio Karpathy no dice eso, y la discusión en los comentarios del gist —que vale la pena leer— deja claro que el patrón se complementa con RAG, no lo sustituye.
Para nosotros, lo útil del gist no es la arquitectura en sí (varias implementaciones, incluida la nuestra, ya habían llegado a conclusiones parecidas por necesidad operativa), sino que articula bien un vocabulario compartido. Es más fácil explicarle a un cliente qué hace MiniBrain cuando existe un marco público al que referirse.
Si en tu operación pasa alguna de estas cosas —razonamientos que mueren en correos, decisiones que se repiten porque nadie recuerda la anterior, integraciones cuya lógica de negocio vive solo en la memoria del implementador, licitaciones donde las contradicciones se detectan tarde— probablemente tengas el problema que estamos atacando.
En MinecloudIT trabajamos con equipos mineros y de ingeniería para atacar gestión del conocimiento como lo que es: un problema de infraestructura, no de voluntarismo documental.
Contáctanos en minecloudit.com y conversamos sobre tu operación sin compromiso.