LLM-Wiki aplicada a la dirección de proyectos: hacia una memoria viva del proyecto
- hace 26 minutos
- 13 min de lectura
En el artículo anterior vimos la idea general de LLM-Wiki: usar un modelo de lenguaje para construir y mantener una wiki persistente a partir de nuestras fuentes de información.
No solo preguntar a documentos, recuprear fragmentos o generar respuestas que desaparecen en el historial del chat. La idea era dar un paso más: convertir documentos, notas, preguntas y análisis en una memoria organizada, enlazada y reutilizable.
Ahora vamos a llevar esa idea a un terreno mucho más concreto: la dirección de proyectos industriales, porque un proyecto no es no es solo una carpeta con documentos. Es una historia en movimiento. Hay alcance, requisitos, cambios, riesgos, incidencias, proveedores, decisiones, cronogramas, reuniones, entregables y conversaciones que se van acumulando durante meses o incluso años.
El problema es que toda esa historia rara vez está completa en un solo sitio ya que está repartida entre contratos, actas, correos, planos, informes, hojas Excel, comentarios del cliente y memoria de las personas.
La pregunta que vamos a explorar en este artículo es sencilla: ¿podríamos usar una LLM-Wiki para construir una memoria viva de un proyecto industrial?
La respuesta inicial sería: sí, pero no como sustituto del project manager ni de los sistemas oficiales. La idea sería usar la LLM-Wiki como una capa de conocimiento operativo que ayude a entender mejor qué está pasando, qué ha pasado, qué está conectado y qué conviene revisar antes de tomar decisiones.
El problema: los proyectos generan más información de la que podemos mantener en la cabeza
Un proyecto de tipo industrial genera información constantemente.
Al principio tenemos la oferta, el contrato, el alcance, los requisitos técnicos, el cronograma base, los layouts, los P&IDs, las listas de equipos y la documentación de partida. Después empiezan las reuniones. Luego llegan los comentarios del cliente. Más tarde aparecen cambios, riesgos, incidencias, informes de avance, documentos de proveedores, correos cruzados, actas revisadas y listas de pendientes.
El proyecto avanza, pero la información se dispersa, y el project manager vive en medio de ese flujo.
Una parte importante de su trabajo consiste en mantener contexto: saber por qué se tomó una decisión, qué requisito estaba detrás de un cambio, qué proveedor está afectando a un hito, qué issue viene de un riesgo anterior o qué acuerdo sigue pendiente desde una reunión con cliente.
El problema es que esa memoria suele depender demasiado de personas concretas: del PM, del ingeniero que lleva más tiempo, del site manager, del que estuvo en aquella reunión hace tres meses..., y cuando alguien no está, cambia de proyecto o simplemente no recuerda el detalle, toca reconstruir la historia: buscar correos, abrir actas, comparar documentos, preguntar a otros y volver a hilar el contexto.
Una LLM-Wiki aplicada a proyectos industriales intenta atacar justo ese problema: no solo guardar documentos, sino mantener una capa de conocimiento que conserve las relaciones importantes entre ellos.
Qué sería una LLM-Wiki de proyecto
Una LLM-Wiki de proyecto sería una base de conocimiento persistente, mantenida con ayuda de un modelo de lenguaje, que organiza la información relevante del proyecto en páginas conectadas.
No sería simplemente un repositorio de documentos. Tampoco sería un chatbot al que le subimos archivos de vez en cuando.
Sería una capa intermedia entre la documentación oficial y el trabajo diario del project manager.
Por debajo estarían las fuentes originales: contrato, requisitos, actas, correos, cronogramas, informes, riesgos, issues, cambios y documentación técnica.
Por encima estaría la wiki: páginas de resumen, decisiones, sistemas, paquetes de trabajo, stakeholders, reuniones, cambios, riesgos, incidencias y síntesis periódicas.
La wiki no sustituye a la evidencia, sino que la organiza, la conecta y la hace navegable. La idea es que el project manager pueda consultar el proyecto no solo por documentos, sino por relaciones: qué decisión afecta a qué requisito, qué issue viene de qué riesgo, qué cambio impacta en qué paquete de trabajo, qué proveedor aparece asociado a qué retraso, qué tema se repite reunión tras reunión sin cerrarse.
Una LLM-Wiki de proyecto no busca crear más documentación sino que busca convertir la documentación existente en una memoria operativa que ayude a entender mejor el proyecto.
La idea sería que el project manager pudiera preguntar cosas como:
¿Qué decisiones siguen abiertas desde la última reunión con cliente?
¿Qué cambios aprobados afectan al alcance de automatización?
¿Qué issues actuales vienen de riesgos que ya estaban identificados?
¿Qué requisitos tienen relación con este paquete de trabajo?
¿Qué proveedores aparecen vinculados a más retrasos documentales?
¿Qué temas se repiten semana tras semana sin cerrarse?
No es solo buscar un documento, es navegar por la memoria del proyecto.
La estructura básica: raw, wiki y reglas
La arquitectura de una LLM-Wiki aplicada a proyectos industriales puede mantenerse bastante simple. La idea base sigue siendo la misma que planteaba Karpathy: fuentes originales, wiki generada y reglas de trabajo.
En una estructura mínima podríamos tener algo así:
project-wiki/
raw/
contracts/
requirements/
schedules/
meetings/
site-reports/
vendor-docs/
emails/
changes/
risks-issues/
wiki/
overview.md
index.md
log.md
work-packages/
systems/
requirements/
risks/
issues/
changes/
decisions/
meetings/
weekly-reviews/
stakeholders/
schema.md
governance.md
En raw/ estarían las fuentes originales o exportaciones controladas desde los sistemas oficiales: contratos, requisitos, actas, informes, cronogramas, documentos de proveedores, cambios, riesgos e incidencias.
En wiki/ estaría la capa de conocimiento mantenida por el LLM: resúmenes, decisiones, relaciones, páginas por sistema, paquetes de trabajo, stakeholders, revisiones semanales y enlaces entre elementos relevantes.
schema.md definiría cómo debe trabajar el modelo: cómo nombrar páginas, qué metadatos usar, cuándo crear una página nueva, cómo citar fuentes, cómo actualizar el índice y cómo registrar cambios.
Y governance.md pondría los límites: qué puede proponer la IA, qué requiere revisión humana y qué elementos nunca debería modificar automáticamente.
Esta separación es clave.
raw/ conserva la evidencia.
wiki/ conserva la comprensión operativa.
schema.md mantiene el orden.
governance.md mantiene el control.
No se trata de crear otro almacén documental paralelo. Se trata de construir una capa de lectura, conexión y síntesis encima de la documentación real del proyecto.
Qué información debería entrar en la wiki
Una tentación bastante normal sería intentar meterlo todo. Todos los correos, PDFs, Excels, las notas y los documentos de todos los proveedores.
Pero una LLM-Wiki de proyecto no debería empezar así. No se trata de acumular información por acumular. Se trata de capturar aquello que ayuda a entender el proyecto y a tomar mejores decisiones.
Por eso, al principio conviene centrarse en las familias de información con más valor operativo para el project manager:
documentos contractuales y alcance,
requisitos técnicos,
actas y transcripciones de reuniones,
cronogramas exportados,
registros de riesgos,
registros de issues,
solicitudes de cambio,
decisiones tomadas,
informes de avance,
documentación clave de proveedores,
pendientes abiertos.
La pregunta no debería ser: “¿podemos meter este documento en la wiki?”. La pregunta debería ser otra: “¿este documento ayuda a explicar qué está pasando en el proyecto?”. Si la respuesta es sí, puede tener sentido incorporarlo, en cambio, si la respuesta es no, quizá solo estamos generando ruido.
Una buena LLM-Wiki no es la que más documentos tiene. Es la que mejor conserva las relaciones importantes: qué ocurrió, cuándo ocurrió, por qué ocurrió, a qué afecta y dónde está la evidencia.
Qué páginas tendría la wiki del proyecto
Una LLM-Wiki de proyecto no debería limitarse a resumir documentos. Su valor estaría en crear páginas que ayuden a navegar el proyecto.
Por ejemplo:
Una página overview.md podría funcionar como vista general: alcance, fase actual, hitos principales, situación de alto nivel y enlaces a las áreas críticas.
La carpeta work-packages/ podría organizar los paquetes de trabajo.
La carpeta systems/ podría recoger los sistemas técnicos: proceso, automatización, electricidad, mecánica, seguridad, utilities o los que correspondan a cada proyecto.
La carpeta requirements/ serviría para mantener requisitos relevantes conectados con sus fuentes originales.
La carpeta changes/ recogería cambios solicitados, aprobados, rechazados o pendientes de análisis.
La carpeta risks/ debería separar claramente los riesgos.
Y la carpeta issues/, los problemas que ya están ocurriendo.
Esta separación es importante. Un riesgo es algo que podría pasar, y un issue es algo que ya está pasando. Mezclarlos suele generar ruido.
También tendría sentido una carpeta decisions/, donde se recojan decisiones importantes: qué se decidió, cuándo, quién participó, qué impacto tiene y qué fuente lo respalda.
Y una carpeta weekly-reviews/, donde el sistema genere síntesis periódicas: qué ha cambiado, qué sigue abierto, qué se ha cerrado y qué necesita atención.
La clave es que cada página ayude a responder una pregunta concreta del proyecto. No queremos una wiki bonita, queremos una wiki útil.
El project manager no escribe la wiki: la supervisa
Una LLM-Wiki de proyecto no debería convertirse en otra carga administrativa para el project manager. La idea no es que el PM dedique horas a escribir páginas Markdown, actualizar enlaces, ordenar carpetas o mantener índices manualmente.
La idea es justo la contraria. El LLM se encarga del trabajo repetitivo: resumir fuentes, crear páginas, actualizar relaciones, detectar contradicciones, mantener el índice y proponer nuevas conexiones.
El project manager aporta otra cosa mucho más importante: criterio.
Decide qué fuentes importan.Revisa las síntesis relevantes.
Corrige interpretaciones.Valida conclusiones.
Marca prioridades.
Define qué información merece quedar en la memoria operativa del proyecto.
Dicho de forma sencilla:
El LLM mantiene la wiki; el project manager mantiene el criterio.
En este modelo, el PM no es el escriba de la wiki, sino el editor jefe, y eso encaja bastante bien con la realidad de un proyecto industrial: la IA puede ayudar mucho a ordenar el ruido, pero el criterio sobre alcance, impacto, prioridad, cliente, coste, plazo y riesgo sigue siendo humano.
El problema no suele ser la falta de documentos, sino la dificultad de mantenerlos conectados.
La wiki como capa operativa, no como sistema oficial
Una LLM-Wiki de proyecto no debería sustituir los sistemas oficiales.
El contrato sigue siendo el contrato.
El cronograma oficial sigue estando donde tenga que estar.
El gestor documental sigue siendo el repositorio formal.
El registro de cambios aprobado sigue siendo el registro de cambios.
La wiki no debe convertirse en una fuente paralela de autoridad, sino que debe ser una capa de trabajo, una forma de entender mejor lo que ya existe en los sistemas oficiales.
Una buena regla sería esta:
la wiki sirve para pensar, coordinar y navegar;
las fuentes originales sirven para verificar, auditar y defender.
Esto evita un riesgo importante: confundir una síntesis generada por IA con una verdad contractual.
La wiki puede ayudarnos a ver que un cambio parece afectar a un requisito, pero la decisión formal debe seguir pasando por el proceso de cambio del proyecto.
La wiki puede señalar que una decisión aparece en varias actas, pero la evidencia sigue estando en esas actas.
La wiki puede proponer que un issue deriva de un riesgo anterior, pero cerrar, aprobar o modificar registros oficiales sigue siendo responsabilidad humana.
En resumen: la LLM-Wiki no manda sobre el proyecto. Ayuda a entenderlo mejor.
Cómo podría funcionar el flujo de trabajo
En la práctica, el funcionamiento de una LLM-Wiki de proyecto podría ser bastante sencillo:
Primero entra una nueva fuente: un acta de reunión, una transcripción, un informe semanal, una solicitud de cambio, un documento de proveedor o una actualización del cronograma.
Después, el LLM la procesa: extrae fechas, decisiones, acciones, riesgos, issues, requisitos, cambios, responsables y relaciones con información que ya existe en la wiki.
A partir de ahí, propone actualizaciones.
Puede crear una nueva página.
Puede actualizar una decisión existente.
Puede enlazar un issue con un riesgo anterior.
Puede añadir un cambio a un paquete de trabajo.
Puede señalar una contradicción entre dos fuentes.
Puede marcar algo como pendiente de revisión.
Después entra el project manager, no para reescribirlo todo, sino para revisar lo importante: confirmar que la interpretación tiene sentido, corregir matices, validar relaciones críticas y decidir qué queda incorporado a la memoria operativa del proyecto.
Una vez revisada, la wiki queda lista para ser consultada, y ahí empieza el valor diario. El PM podría preguntar: qué ha cambiado desde la semana pasada, qué decisiones siguen abiertas, qué temas se repiten sin cerrarse, qué riesgos se han convertido en issues, qué cambios afectan a coste, plazo o alcance, qué información necesita confirmación del cliente.
La diferencia frente a una búsqueda tradicional es que el sistema no consulta solo documentos sueltos. Consulta una estructura de conocimiento que ya ha sido organizada, conectada y mantenida.
La importancia de los metadatos
Para que una LLM-Wiki funcione bien en un proyecto, no basta con tener páginas bien escritas, también hacen falta metadatos, es decir, información estructurada que ayude a entender rápidamente qué es cada cosa, de dónde viene, en qué estado está y con qué se relaciona.
Por ejemplo:
Una decisión podría incluir: fecha, fuente, reunión asociada, responsable, área afectada, estado, impacto, relación con cambios, relación con requisitos, nivel de confianza.
Un riesgo podría tener probabilidad, impacto, propietario, estado, acciones de mitigación y relación con issues materializados.
Un cambio podría tener solicitante, fecha, estado, impacto en coste, impacto en plazo, impacto en alcance y documentos relacionados.
Esto convierte la wiki en algo mucho más potente que una colección de textos. Permite filtrar, agrupar, consultar, generar tablas, detectar huecos, crear vistas dinámicas y sobre todo, permite que el LLM trabaje con información más ordenada.
Una wiki sin metadatos puede ser útil. Una wiki con buenos metadatos puede convertirse en una auténtica capa operativa de proyecto.
Control humano y gobernanza
La parte más delicada de una LLM-Wiki de proyecto no es técnica, es de gobernanza.
¿Qué puede hacer el LLM?
¿Qué no puede hacer?
¿Qué requiere revisión humana?
¿Qué información está validada?
¿Qué ocurre si dos fuentes se contradicen?
¿Qué pasa si una síntesis queda desactualizada?
Estas preguntas hay que responderlas desde el principio. En un proyecto no podemos permitir que el sistema reescriba la historia del proyecto sin control. Tampoco debería aprobar cambios, cerrar incidencias, modificar requisitos oficiales o alterar una baseline.
Lo razonable es que la IA trabaje en modo propuesta. Puede proponer actualizaciones, enlaces, contradicciones, impactos, preparar síntesis, señalar información pendiente de revisión, pero la autoridad final debe seguir siendo humana, especialmente cuando hablamos de alcance, coste, plazo, calidad, seguridad, requisitos o compromisos contractuales.
La IA puede ayudar a preparar contexto, reducir ruido, acelerar análisis, hacer visibles relaciones que estaban dispersas, pero la responsabilidad del proyecto no se delega en una wiki.
La regla debería ser sencilla: IA para preparar mejor las decisiones y personas para tomar y validar las decisiones.
Seguridad: la memoria persistente también puede contaminarse
Una LLM-Wiki de proyecto tiene una característica muy potente: recuerda, y eso es precisamente lo que la hace útil, pero también lo que la hace delicada.
Si el sistema ingiere una fuente incorrecta, mal interpretada, manipulada o incluso maliciosa, esa información puede acabar formando parte de la memoria persistente del proyecto. Ya no estaríamos hablando solo de una mala respuesta en un chat, estaríamos hablando de una mala idea guardada en la wiki.
Por eso una LLM-Wiki industrial necesita mecanismos de protección:
Separar fuentes confiables de fuentes no confiables.
Mantener trazabilidad hacia el documento original.
Marcar información dudosa.
Registrar cuándo se actualizó una página.
Indicar qué está validado y qué está pendiente de revisión.
Evitar que documentos externos puedan dar instrucciones al agente como si fueran órdenes del sistema.
En un proyecto entran documentos de clientes, proveedores, contratistas, fabricantes y terceros. No todo tiene el mismo nivel de confianza.
Una implantación gradual
La forma más sensata de aplicar una LLM-Wiki a un proyecto no sería empezar por una gran wiki de todo el proyecto, sino empezar pequeño, por ejemplo, con una wiki en sombra centrada solo en reuniones, decisiones e issues, sin tocar todavía requisitos oficiales, sin tocar cambios formales, sin tocar la baseline, solo una capa de memoria operativa para entender qué se está hablando, qué se ha decidido y qué sigue abierto.
Después se podrían añadir riesgos, luego síntesis semanales, más adelante, cambios, y solo cuando el sistema demostrara calidad, trazabilidad y utilidad, tendría sentido acercarlo a zonas más críticas: requisitos, documentación contractual o control formal de cambios.
Este enfoque tiene dos ventajas.
Primero, reduce el riesgo.
Segundo, permite comprobar valor rápidamente.
Si una wiki sencilla ya ayuda a preparar reuniones, localizar decisiones, detectar pendientes y entender la evolución del proyecto, entonces merece la pena seguir ampliando. Si no aporta valor en pequeño, tampoco lo aportará por hacerla más compleja.
La clave no es construir la wiki perfecta desde el principio. La clave es empezar con una memoria útil, controlada y revisable.
Qué podría aportar realmente al project manager
Una LLM-Wiki bien aplicada podría aportar valor en varias áreas muy concretas.
La primera es continuidad.
El proyecto dependería menos de la memoria de una persona concreta. Las decisiones, relaciones, pendientes y cambios relevantes quedarían mejor documentados y conectados.
La segunda es velocidad.
Preparar una reunión, revisar una decisión, entender un issue o analizar un cambio podría llevar menos tiempo, porque parte del contexto ya estaría organizado.
La tercera es trazabilidad.
Si la wiki está bien diseñada, una síntesis no debería quedarse en una frase bonita. Debería llevarnos de vuelta a la fuente original: acta, correo, informe, requisito o documento técnico.
La cuarta es mejor lectura del proyecto.
El sistema podría ayudar a detectar relaciones que a simple vista pasan desapercibidas: un riesgo que acaba convirtiéndose en issue, una decisión que afecta a un requisito, un proveedor asociado a retrasos recurrentes o un tema que aparece en varias reuniones sin cerrarse.
La quinta es reutilización.
Una buena respuesta no tendría por qué perderse en el chat. Podría convertirse en una nota de impacto, una síntesis semanal, un briefing para comité o una página nueva dentro de la propia wiki.
Y la sexta es aprendizaje.
El proyecto no solo avanzaría, también iría dejando una memoria estructurada de cómo ha avanzado. Ese es el valor real: no tener una IA que “gestione el proyecto”, sino tener una capa de memoria que ayude al project manager a ver mejor, recordar mejor y decidir con más contexto.
El límite: pensar mejor no significa gobernar automáticamente
Aun así, conviene no confundirse. Una LLM-Wiki no debería convertirse en el piloto automático del proyecto. No debería aprobar cambios, cerrar issues, modificar requisitos oficiales, alterar una baseline, tomar decisiones contracturales, ni sustituir el criterio del project manager.
Su papel sería otro:
Ayudar a pensar mejor.
Ayudar a preparar contexto.
Ayudar a ver relaciones.
Ayudar a encontrar contradicciones.
Ayudar a recordar decisiones.
Ayudar a mantener viva la historia del proyecto.
Y eso ya sería muchísimo, porque en un proyecto muchas veces el problema no es que falte información, sino que sobra información desconectada.
Una LLM-Wiki no resuelve el proyecto por nosotros, pero puede ayudar a que el project manager llegue a cada decisión con más contexto, menos ruido y una visión más completa de lo que está ocurriendo.
Conclusión: una memoria operativa para proyectos complejos
Aplicar una LLM-Wiki a la dirección de proyectos no significa sustituir las herramientas que ya existen. Significa añadir una nueva capa.
Por debajo seguirían estando los sistemas oficiales: contrato, gestor documental, cronograma, registros de riesgos, cambios, calidad, requisitos y documentación técnica.
Por encima seguiría estando el trabajo humano: criterio, liderazgo, negociación, responsabilidad y toma de decisiones.
Y en medio podría aparecer una wiki persistente mantenida por IA, una memoria operativa del proyecto, una capa capaz de conectar actas, decisiones, requisitos, riesgos, issues, cambios, proveedores, hitos y documentos técnicos para que el project manager no tenga que reconstruir siempre el contexto desde cero.
Esa wiki no tendría autoridad por sí misma, pero podría ayudar a encontrar la evidencia, no decidiría pero podría preparar mejor las decisiones, no sustituiría al project manager, pero podría ayudarle a ver mejor el proyecto, y eso, en proyectos cada vez más documentales, rápidos y complejos, puede marcar una diferencia importante.
Muchas veces el reto no es tener más información, sino conservar el sentido de todo lo que ya sabemos.
Si en el primer artículo hablábamos de pasar de buscar documentos a construir memoria, en este segundo damos un paso más: pasar de gestionar documentación dispersa a construir una memoria viva del proyecto, una memoria útil, trazable, revisable y siempre subordinada al criterio humano.
Ese puede ser el verdadero valor de aplicar la idea de Karpathy al project management industrial.
Comentarios