Hay tareas con IA que salen bien varias veces seguidas. Guardamos el prompt, repetimos la operación y pensamos: esto ya está resuelto.
Hasta que cambia algo.
Entra otro documento. La tarea la hace otra persona. Aparece una excepción que nadie había previsto. O el resultado parece correcto, pero ya no tenemos tan claro de qué fuente salió un dato.
Ahí se ve con claridad la diferencia entre una interacción que funciona y una forma de trabajo que realmente podemos repetir, revisar y mejorar.
Esta diferencia me interesa especialmente porque obliga a mirar menos la herramienta y más el trabajo. Antes de hablar de Work, agentes o automatización, hay que poder explicar qué queremos conseguir, con qué información, qué parte puede asumir la IA y dónde sigue estando la responsabilidad profesional.
No significa documentarlo todo ni convertir cada uso puntual en un procedimiento. Sería absurdo. Hay consultas, pruebas y pequeñas tareas que pueden seguir siendo informales.
La cuestión cambia cuando queremos repetir algo, delegarlo, incorporarlo al trabajo del equipo o utilizarlo en una documentación que después alguien tendrá que revisar.
En ese momento ya no me basta con pensar "el prompt funciona”. Necesito saber por qué funciona y qué tendría que ocurrir cuando deje de hacerlo.
Esta pregunta está un paso antes de los flujos y los agentes. Antes de decidir cómo automatizar, conviene comprobar si el trabajo está suficientemente claro para que tenga sentido hacerlo.
Que funcione no significa que esté definido
En una prueba aislada es lógico mirar el resultado. ¿Me ha servido? ¿He ahorrado tiempo? ¿La respuesta es suficientemente buena? Para muchos usos, eso basta.
Pero si mañana otra persona tiene que hacer lo mismo, la prueba cambia.
Ya no importa solo la calidad de la respuesta. Importa si sabe qué información usar, cuál es la versión válida, qué pasos son relevantes, qué debe comprobar y cuándo tiene que detenerse.
Un buen resultado puede esconder mucho trabajo que sigue sin estar definido.
Por ejemplo, alguien puede saber de memoria que un determinado documento está desactualizado. Otra persona puede recordar una excepción habitual. Quien suele hacer la tarea conoce qué parte del resultado hay que mirar con más cuidado. Nada de eso aparece en el prompt porque hasta ahora no hacía falta explicarlo.
Mientras trabajan siempre las mismas personas, ese conocimiento tácito puede sostener el día a día.
El problema aparece cuando queremos delegar, incorporar IA o simplemente conseguir que la misma tarea sea menos dependiente de una persona concreta.
La IA no crea necesariamente ese problema. Muchas veces lo hace visible.
Una licitación deja ver muy bien dónde está el trabajo
Pensemos en el análisis inicial de una licitación.
Podemos pedir a una herramienta de IA que extraiga fechas, solvencia, documentación exigida o criterios de adjudicación. Como primera lectura, puede ser muy útil.
Pero imaginemos que queremos incorporar esa ayuda al funcionamiento habitual del estudio.
Entonces aparecen otras preguntas.
Para que esa ayuda sea repetible, hay que aclarar qué documentos forman parte del análisis y cuál es la versión válida. También qué datos pueden resumirse y cuáles deben conservar una referencia directa a la fuente.
Y cuando aparecen contradicciones o dudas, hace falta saber qué revisa una persona, cuándo se detiene el trabajo y qué necesita recibir quien toma la decisión.
Eso ya no se resuelve afinando dos líneas del prompt.
Estamos definiendo el trabajo.
Y aquí aparece algo que, para mí, tiene valor. Al intentar explicar una tarea a una IA, hacemos visible conocimiento que antes estaba repartido entre personas, documentos y hábitos del estudio.
Si el problema principal está en localizar o mantener documentación fiable, antes habrá que resolver cómo organizamos el conocimiento. Es una cuestión distinta, desarrollada con más detalle en NotebookLM en arquitectura: necesitamos saber con qué información estamos trabajando y cuál podemos considerar válida.
Empezar por el final aclara muchas cosas
Una forma sencilla de ordenar una tarea es empezar por su salida.
"Analizar un pliego” es demasiado abierto.
En cambio, podemos definir una salida concreta: una ficha con identificación de la licitación, fechas críticas, solvencia, documentación exigida, criterios de adjudicación, alertas y referencia a la fuente de cada dato relevante. La ficha, además, debe permitir que una persona revise la información antes de tomar una decisión.
Eso ya nos obliga a concretar.
Si tuviera que hacer una comprobación rápida antes de plantear más automatización, agruparía la revisión en cuatro bloques:
- Resultado y entradas: qué decisión o salida debe facilitar, qué documentos y contexto necesita y cuál es la fuente válida.
- Trabajo y reparto: qué pasos importan, en qué orden y qué parte corresponde a la IA o a una persona.
- Control y excepciones: qué se revisa, contra qué fuente y qué situaciones obligan a detenerse o pedir criterio.
- Salida y responsabilidad: qué se entrega, qué trazabilidad debe conservar y quién puede dar el resultado por válido.
No lo planteo como una metodología universal. No creo demasiado en las recetas aplicadas sin contexto.
Me sirve más como prueba. Si cuesta explicar uno de estos puntos, ahí probablemente sigue escondida una parte importante del trabajo.
Esta lógica también encaja con marcos más amplios. La ISO/IEC 42001:2023 incorpora procesos, responsabilidades, control y mejora dentro de la gestión de sistemas de IA. El NIST AI Risk Management Framework insiste en contexto, responsabilidades, medición y gestión del riesgo.
No trasladaría esos marcos literalmente a una tarea cotidiana de un estudio pequeño. Sería sobredimensionarla. Lo que sí me parece útil es la idea de fondo: el control no puede aparecer solo al final, cuando la IA ya ha producido algo.
La revisión forma parte del diseño
"Hay que revisar lo que produce la IA" es una frase correcta. Pero, como criterio de trabajo, dice muy poco.
La revisión necesita responder a cinco preguntas: qué se comprueba, contra qué fuente, en qué momento, quién lo hace y con qué profundidad.
No necesita el mismo control una clasificación inicial de documentos que una consulta normativa que puede condicionar una decisión técnica.
En una consulta de mayor riesgo, la comprobación tiene que volver a la fuente aplicable y al profesional responsable. En una tarea más sencilla puede bastar una revisión acotada o por excepción.
El AIA AI Firm Toolkit insiste precisamente en mantener responsabilidad profesional y controles humanos cuando la IA entra en el trabajo de los estudios.
Y el NIST AI RMF Playbook desarrolla una lógica parecida: gobernar, contextualizar, medir y gestionar no son actividades que se añaden cuando todo ha terminado.
Por eso prefiero pensar la revisión como parte del propio diseño de la tarea.
También sirve para detectar si estamos utilizando IA donde realmente aporta valor. Si comprobar la salida obliga a rehacer casi todo desde cero, quizá la herramienta está interviniendo en la parte equivocada. O quizá la tarea todavía está mal definida.
La misma lógica aparece al hablar de riesgos, límites y responsabilidad profesional en el uso de IA generativa en arquitectura: el nivel de supervisión no puede ser genérico. Tiene que responder a la naturaleza del trabajo y a las consecuencias razonables de un error.
Cuando algo falla, tocar el prompt no siempre es la solución
Otra ventaja de trabajar de una forma más explícita es que podemos diagnosticar mejor los fallos.
Con una interacción aislada, es muy fácil concluir: "la IA se ha equivocado”.
Pero quizá no sea tan simple.
El fallo puede estar en la fuente, en el archivo de partida, en una instrucción ambigua o en el orden de los pasos. También puede aparecer porque la revisión llega demasiado tarde o porque hemos dejado a la IA tomar una decisión que no le correspondía.
Esto evita un bucle muy habitual: corregir el prompt una y otra vez hasta conseguir una respuesta que vuelve a convencernos.
A veces el problema no está en el prompt.
Está en la entrada, en el contexto, en la fuente, en la secuencia o en el control.
Poder distinguirlo convierte un fallo en aprendizaje. Y eso permite mejorar el trabajo, no solo conseguir una salida mejor esta vez.
No todo lo repetitivo merece automatización
Que algo se repita lo convierte en candidato. No en una buena decisión.
Hay tareas que cambian demasiado entre proyectos. Otras dependen de información difícil de mantener. Algunas concentran mucho juicio profesional. Y otras dejan de resultar interesantes cuando sumamos el tiempo de preparación, mantenimiento y revisión.
Yo miraría, al menos, cuatro cosas: estabilidad, calidad de las entradas, capacidad de verificación y valor real.
Si casi todo son excepciones, probablemente todavía no hay una base suficientemente estable.
Si la información está dispersa, quizá el primer trabajo sea ordenarla.
Si los criterios importantes solo están en la cabeza de una persona, habrá que hacerlos visibles antes.
Y si el resultado no puede verificarse de una forma razonable, automatizar puede darnos una sensación de control sin aportar demasiado control real.
Por eso me interesa más una secuencia sencilla: entender, probar, mejorar y solo después automatizar lo que tenga sentido.
No es nueva ni espectacular. Pero funciona mejor que empezar por la herramienta.
Primero entender. Después probar. Luego decidir cuánto automatizar
Hoy es relativamente fácil empezar por un agente, una integración o una nueva función.
Lo difícil sigue siendo otra cosa: decidir qué trabajo queremos mejorar.
Yo empezaría pequeño. Una tarea concreta. Una salida clara. Las fuentes necesarias. Los pasos importantes. Qué hace la IA. Qué revisa una persona. Qué excepciones obligan a parar. Quién responde del resultado.
Después la probaría.
Observaría dónde aporta valor de verdad y dónde falla.
Ajustaría lo necesario.
Y solo cuando esa forma de trabajo estuviera suficientemente clara y revisable, aumentaría la integración.
Pruébalo, observa qué pasa y ajusta desde tu propia experiencia. No todos los estudios necesitan la misma estructura ni todas las tareas merecen el mismo nivel de sistematización.
La integración profesional de IA no empieza cuando una tarea se ejecuta sola.
Empieza antes: cuando podemos explicar qué estamos intentando hacer, con qué información, cómo sabremos si está bien y quién conserva la responsabilidad.
Y quizá esa sea una de las aportaciones menos visibles de trabajar con IA: nos obliga a entender mejor nuestro propio trabajo.
Por eso, antes de preguntarnos qué más podemos automatizar, quizá convenga hacernos otra pregunta: ¿qué parte de este trabajo todavía no sabemos explicar bien?
Cuando esa respuesta está clara, la IA deja de ser una capa añadida y empieza a integrarse de verdad en la forma de trabajar. El criterio profesional no desaparece: se vuelve más explícito, compartible y revisable.
Del uso puntual de IA a una forma de trabajo que puedas revisar
Si ya utilizas IA en tareas concretas y quieres pasar de usos aislados a procesos mejor definidos, repetibles y supervisados, el Curso Avanzado de IA aplicada a la Arquitectura trabaja precisamente ese siguiente nivel.