Cuando pensamos en dar contexto a una IA dentro de un estudio de arquitectura, la primera reacción suele ser bastante lógica: conectarle nuestros documentos.
Memorias, detalles, plantillas, normativa, actas, proyectos anteriores, manuales internos. Cuanto más pueda consultar, mejor debería responder.
Pero no necesariamente.
Un estudio puede tener miles de archivos perfectamente ordenados y seguir sin tener un verdadero sistema de conocimiento.
Porque el conocimiento profesional no está solo en las carpetas. Está repartido entre documentos, proyectos anteriores, soluciones que funcionaron, decisiones tomadas por un motivo concreto y, muchas veces, personas que llevan años resolviendo problemas y saben qué mirar, qué descartar y qué criterio aplicar.
La IA está haciendo visible una cuestión que ya existía antes:
¿Qué sabe realmente nuestro estudio y cómo conseguimos que ese conocimiento pueda reutilizarse sin perder el contexto en el que nació?
Para mí, ahí está una de las aplicaciones más interesantes de la IA en arquitectura. No tanto conseguir que genere más información, sino conseguir que el estudio aproveche mejor lo que ya sabe.
El estudio sabe más de lo que tiene documentado
Pensemos en un estudio de diez o quince personas.
Parte de su conocimiento está formalizado. Tiene una plantilla de memoria, algún procedimiento de revisión, una biblioteca de detalles, criterios gráficos, pliegos anteriores o documentos tipo que el equipo reutiliza.
Pero otra parte permanece escondida dentro de los proyectos.
Un buen detalle de cubierta desarrollado hace dos años. Una solución de fachada que consiguió resolver un encuentro especialmente delicado. Una estructura de pliego que funcionó bien. Una forma de organizar determinada documentación para una administración. Una decisión tomada durante una obra que evitó repetir un problema que ya había aparecido anteriormente.
Ese conocimiento existe.
El problema llega unos meses después, cuando alguien pregunta:
"¿En qué proyecto hicimos aquello?".
Y empieza la búsqueda por carpetas. O se pregunta directamente a la persona que lo recuerda.
Aquí aparece probablemente la parte más importante: una gran cantidad del conocimiento de un estudio pequeño o mediano vive todavía en las personas.
La arquitecta que sabe por qué determinada solución suele fallar. El jefe de proyecto que recuerda cómo se resolvió una situación parecida. La persona que lleva años preparando determinadas entregas y detecta rápidamente qué falta. El técnico que sabe qué detalle de la biblioteca es realmente el bueno y cuál quedó allí después de una prueba.
Esto no significa que debamos intentar "vaciar la cabeza" de los profesionales y documentarlo todo. Gran parte del juicio experto es contextual y difícil de formalizar.
Pero sí podemos hacernos otra pregunta:
¿Qué conocimiento estamos utilizando repetidamente y sigue dependiendo innecesariamente de que determinada persona esté disponible?
Mientras una solución dependa de recordar quién la conoce o en qué proyecto se utilizó, el estudio posee ese conocimiento, pero todavía no lo ha convertido en una capacidad compartida.
Parte de este problema comienza incluso antes de introducir IA: en cómo gestionamos y estructuramos la información dentro del estudio. Proyectos, bibliotecas, decisiones y documentación pueden existir y seguir siendo difíciles de recuperar y reutilizar.
Tener décadas de archivos no significa tener décadas de conocimiento utilizable
El AI Firm Toolkit de AIA, publicado en agosto de 2026, plantea una distinción especialmente útil: disponer de archivos y repositorios históricos no equivale automáticamente a disponer de una base preparada para trabajar con IA. Antes de avanzar, importa identificar qué información tiene valor, cómo está estructurada y qué necesita realmente la firma.
Imaginemos que un estudio conecta directamente veinte años de proyectos.
La IA puede encontrar tres versiones de un detalle, una especificación que ya no se utiliza, una memoria desactualizada, un criterio interno que posteriormente cambió y una solución válida únicamente para las condiciones de un proyecto concreto.
Encontrar la información ya no es el único problema. Hay que saber qué significa esa información.
Por eso no parece razonable comenzar intentando limpiar o estructurar todo el histórico.
Tiene mucho más sentido identificar unas pocas categorías que realmente se utilizan: detalles recurrentes, estándares internos, determinados procedimientos, precedentes, especificaciones o lecciones aprendidas.
La pregunta deja entonces de ser:
"¿Qué documentos podemos conectar a la IA?".
Y pasa a ser:
"¿Qué conocimiento merece la pena convertir en reutilizable?"
Ese cambio de pregunta modifica bastante el proyecto.
Cuando ese conocimiento empieza a ponerse a disposición de un asistente específico, la calidad, la estructura y la coherencia de la información de partida importan mucho más que el volumen de archivos acumulados.
Qué están haciendo ya otras firmas AEC
Al observar cómo se está abordando actualmente este problema en arquitectura aparecen soluciones diferentes. Algunas se centran en mantener vivo el contexto de un proyecto; otras, en recuperar soluciones desarrolladas anteriormente; otras empiezan a convertir conocimiento profesional en procedimientos reutilizables.
Lo interesante es que todas parten de un problema que existe mucho antes de incorporar IA: cómo conservar, encontrar y reutilizar mejor el conocimiento profesional.
BDG: no basta con guardar el briefing si el proyecto sigue cambiando
En febrero de 2026, BDG Architecture + Design presentó un experimento con un "cliente virtual" basado en información específica del cliente y del proyecto.
El proceso organiza la información en brief, requisitos estatutarios y contenido vivo del proyecto. Incluye además validación humana y mecanismos para comprobar las respuestas frente a la información proporcionada. BDG contempla también que las decisiones y preferencias surgidas durante el desarrollo formen parte de ese contexto vivo.
El problema que intenta resolver es muy cotidiano.
Imaginemos un proyecto de vivienda colectiva desarrollado durante año y medio.
Al inicio existe un briefing del promotor. Después llegan reuniones, correos, cambios de programa, ajustes de presupuesto, comentarios de consultores y nuevas instrucciones.
Tres meses después alguien pregunta:
"¿Qué decidió finalmente el cliente sobre las cocinas abiertas?"
Buscar cocina puede devolver una petición inicial, dos alternativas intermedias y un acta posterior donde se tomó la decisión definitiva.
Aquí el problema no es documental.
El problema es temporal y contextual: qué se decidió finalmente y qué información ha quedado superada.
No hace falta construir un «cliente virtual» para aplicar este principio.
Puede empezar simplemente por conseguir que, dentro de un proyecto, determinadas decisiones importantes tengan estado, fecha, procedencia y relación con la documentación vigente.
Entonces la IA puede ayudarnos a recuperar el contexto.
Pero antes hemos tenido que construirlo.
CRAFT: conseguir que una buena solución sobreviva al proyecto donde nació
CRAFT Engineering Studio ya disponía de una plantilla de Revit con detalles estándar. Conforme desarrollaban proyectos aparecían nuevas soluciones que podían quedar encerradas dentro de aquellos proyectos. La firma ha utilizado Pirros para hacer detalles y familias más accesibles y reutilizables entre sus equipos y oficinas.
Imaginemos que un estudio termina una vivienda unifamiliar y durante el proyecto resuelve especialmente bien un encuentro entre fachada y cubierta.
Dos años después aparece una situación similar.
La búsqueda comienza:
"Creo que ese detalle estaba en la vivienda de…".
Si encontramos el archivo, todavía necesitamos saber algo más.
¿Por qué se resolvió así?
¿Era una solución general o dependía de unas condiciones concretas?
¿Ha aparecido alguna información posterior que cambie la forma de resolverlo?
El valor no está en extraer el detalle de una carpeta y meterlo en otra biblioteca.
Está en conseguir que parte del contexto y del aprendizaje asociado al detalle también sobreviva.
Ahí se produce un cambio importante: el proyecto genera conocimiento que puede volver al estudio.
Y eso facilita además la transferencia de experiencia hacia profesionales que todavía no han vivido situaciones similares.
BDP: utilizar la IA para llegar antes a la fuente correcta
BDP desarrolló ChatBDP porque localizar información mediante búsquedas tradicionales en su intranet y SharePoint estaba resultando cada vez más difícil.
El primer prototipo se construyó sobre unos 200 documentos seleccionados. El sistema permite consultar conocimiento interno mediante lenguaje natural, genera un resumen y mantiene acceso a los documentos utilizados. La propia firma señala además que la respuesta generada no elimina la necesidad de completar y comprobar el trabajo.
El problema puede no ser que la información no exista.
Puede ser que parte del equipo no sepa que existe o no sepa dónde encontrarla.
En lugar de navegar por varias carpetas, alguien podría preguntar:
"¿Qué comprobaciones hacemos antes de emitir la documentación de proyecto básico?"
La IA puede acercarnos rápidamente a la información relevante.
Pero hay una frontera importante: recuperar conocimiento no equivale a delegar la comprobación.
Si una respuesta afecta a una decisión de proyecto, necesitamos seguir pudiendo consultar su procedencia, especialmente cuando intervienen criterios técnicos, contractuales o normativos.
En este tipo de sistemas, la IA funciona mejor como capa de acceso al conocimiento que como nueva fuente de autoridad.
Broadway Malyan: aprender también de cómo se desarrollan los proyectos
Broadway Malyan ha trabajado en conectar datos de finanzas, personas y proyectos para encontrar relaciones que antes quedaban ocultas entre sistemas separados. Un ejemplo concreto consistió en comparar número de planos, honorarios, duración y tamaño del equipo. Al aparecer determinados patrones, pudieron revisar expectativas de producción, planificación, formación y control del alcance.
Esto amplía lo que entendemos por conocimiento del estudio.
No todo está en una memoria o en un detalle constructivo.
También podemos aprender de cómo se desarrollaron nuestros proyectos: cuánto esfuerzo acabaron requiriendo, dónde aparecieron desviaciones, qué tipos de encargos generaron determinados problemas o qué decisiones organizativas funcionaron.
Esta lógica conecta con una cuestión más amplia: utilizar datos de proyectos anteriores para detectar patrones y fundamentar mejor determinadas decisiones.
En un estudio pequeño no hace falta construir un gran sistema analítico.
Quizá basta con conservar algunas variables comparables entre proyectos y, al cerrarlos, registrar dos o tres aprendizajes que realmente merezca la pena recuperar después.
Porque un proyecto no debería dejarnos únicamente planos y fotografías.
También debería dejarnos experiencia.
ALPA: cuando el conocimiento empieza a convertirse en una forma de trabajar
El proyecto abierto Skills for Architects de ALPA lleva esta idea un paso más allá.
La iniciativa organiza conocimiento profesional en componentes reutilizables que combinan instrucciones, referencias, contexto y objetivos. La documentación publicada muestra distintas Skills asociadas a tareas y fases profesionales.
La idea interesante aquí no es la Skill en sí.
Es el paso previo: hacer explícito un criterio profesional que hasta entonces podía estar repartido entre documentos, proyectos anteriores y experiencia personal.
Imaginemos que en un estudio existe una arquitecta senior que realiza especialmente bien la revisión previa a una entrega.
No se limita a leer una checklist.
Sigue determinado orden. Sabe dónde aparecen habitualmente las incoherencias. Contrasta unas piezas con otras. Utiliza ciertas referencias y presta especial atención a algunos puntos porque la experiencia le ha enseñado que allí suelen aparecer problemas.
Una parte de ese método estará escrita.
Otra parte probablemente no.
Antes de pensar en una Skill podemos intentar entender cómo hacemos realmente bien esa tarea.
Quizá el primer resultado sea simplemente un procedimiento mejor.
Si posteriormente comprobamos que es estable, repetible y útil para distintas personas, entonces sí puede tener sentido convertirlo en una capacidad asistida por IA.
La progresión sería:
experiencia → conocimiento explícito → procedimiento probado → posible capacidad reutilizable con IA.
La tecnología aparece al final, no al principio.
Hay dos tipos de conocimiento que conviene separar
Los ejemplos anteriores apuntan a una distinción bastante sencilla.
Por un lado tenemos el conocimiento reutilizable del estudio.
Son aquellas cosas que pueden tener valor más allá de un encargo concreto: criterios internos, estándares, procedimientos, soluciones técnicas, precedentes, aprendizajes y determinados razonamientos profesionales.
Por otro tenemos el contexto vivo del proyecto.
El briefing de un cliente, las condiciones de una parcela, la normativa aplicable, una decisión de diseño, un acta, un cambio solicitado durante el desarrollo o la indicación de un consultor.
Las dos capas se relacionan continuamente, pero no son intercambiables.
Un detalle utilizado anteriormente puede ser una referencia muy buena y no ser adecuado para el proyecto actual.
Un criterio interno puede ser el punto de partida y quedar condicionado por una decisión específica del encargo.
Una plantilla puede ayudarnos a preparar una memoria, pero no contiene por sí misma la información del proyecto.
Y una decisión tomada en un proyecto no debería convertirse automáticamente en criterio general del despacho.
Esta separación resulta especialmente importante cuando entra la IA, porque encontrar relaciones entre documentos no significa conocer automáticamente la jerarquía profesional de las fuentes.
Cuatro preguntas antes de confiar en una fuente
No hace falta comenzar implantando una arquitectura de gobierno compleja.
Pero cuando una información pueda influir en una decisión, deberíamos ser capaces de responder al menos a cuatro preguntas:
¿Está vigente?
¿En qué contexto aplica?
¿Qué prevalece si contradice otra información?
¿De dónde procede?
Imaginemos una consulta aparentemente sencilla.
La IA encuentra un detalle estándar del estudio, otro utilizado en un proyecto anterior, una versión inicial de la memoria del proyecto actual y un acta posterior donde se modifica la solución.
Ha encontrado mucha información.
Todavía no sabe necesariamente qué debe creer.
Esa es una diferencia fundamental entre tener documentos disponibles y tener contexto profesional utilizable.
El conocimiento que vive en las personas requiere otra estrategia
En firmas pequeñas este problema puede ser todavía más importante.
El funcionamiento diario suele apoyarse mucho en unas pocas personas que concentran experiencia, antecedentes y conocimiento técnico.
Eso tiene ventajas. La comunicación puede ser rápida y el conocimiento circula informalmente.
También crea dependencia.
Si continuamente escuchamos:
"Pregúntale a Ana".
"Eso solo lo sabe Javier".
"Cuando vuelva Marta lo vemos".
probablemente hay una parte del conocimiento recurrente del estudio que todavía no es suficientemente accesible.
No todo ese conocimiento debe documentarse.
Hay decisiones que requieren experiencia, interpretación y juicio profesional y que seguirán requiriéndolos.
El objetivo no debería ser sustituir al experto.
Debería ser evitar que el experto tenga que volver a explicar cien veces aquello que sí puede convertirse razonablemente en conocimiento compartido.
Eso permite que las personas con más experiencia intervengan precisamente donde su juicio aporta más valor.
Si tuviera que empezar mañana, no empezaría por la IA
Empezaría escuchando al estudio.
Buscaría frases como:
"Esto siempre se lo preguntamos a la misma persona".
"Sé que lo hicimos en otro proyecto, pero no recuerdo cuál".
"Tenemos una plantilla, pero no sé cuál es la última".
"Esto ya nos ocurrió una vez".
"Hay un detalle bueno, pero no sé dónde está".
Son pequeñas señales de algo importante: hay conocimiento útil, pero acceder a él tiene demasiada fricción.
Escogería uno de esos problemas. Solo uno.
Por ejemplo, los detalles que el equipo reutiliza con mayor frecuencia.
Revisaría cuáles son realmente válidos, qué contexto necesitamos conservar y quién debería decidir cuándo se incorpora una nueva solución.
Después probaría con un conjunto pequeño.
Y solo entonces elegiría cómo queremos acceder a él.
Quizá sea suficiente una estructura documental mejorada.
Quizá tenga sentido una herramienta de búsqueda.
Quizá un asistente.
Más adelante, si existe un procedimiento suficientemente estable, podría aparecer un agente o una Skill.
Pero no necesitamos decidir la tecnología antes de saber qué conocimiento queremos conservar y para qué queremos utilizarlo.
El Cerebro del Estudio no tiene por qué ser una aplicación
Durante años hemos organizado documentos para poder encontrarlos. La IA nos obliga ahora a plantearnos una cuestión distinta: qué parte de todo lo que produce y aprende un estudio merece seguir siendo útil después de terminar un proyecto.
Ahí están los detalles que funcionaron, las decisiones que evitaron un problema, los procedimientos que hemos ido afinando, los errores que no queremos repetir y una parte del criterio que hoy sigue dependiendo de la experiencia de determinadas personas.
No todo debe convertirse en una base de conocimiento. Y mucho menos automatizarse.
Pero si cada nuevo proyecto empieza buscando otra vez la misma información, preguntando a las mismas personas o intentando recordar dónde resolvimos aquel problema, hay una parte de la experiencia del estudio que estamos desaprovechando.
Por eso no empezaría preguntando qué herramienta necesitamos.
Empezaría por algo mucho más concreto:
¿Qué hemos aprendido ya que no queremos tener que volver a descubrir desde cero?
A partir de ahí sí podemos decidir qué merece conservarse, qué debe seguir ligado a cada proyecto, cómo mantener su contexto y dónde puede ayudarnos la IA.
Porque un estudio que consigue hacer esto no solo encuentra mejor sus archivos.
Consigue que cada proyecto deje al siguiente un estudio un poco más capaz.
Y probablemente ahí esté el verdadero valor de construir su "cerebro".