En mi forma de trabajar, documentar y mejorar procesos con IA significa utilizar la herramienta para transformar decisiones dispersas, correcciones, criterios y experiencias acumuladas en un sistema que pueda volver a utilizar. No se trata simplemente de guardar conversaciones. El objetivo es que lo aprendido durante un proyecto no desaparezca cuando termina una tarea, cambia el contexto o pasan varias semanas antes de retomarlo.
He comprobado que muchos problemas no aparecen porque falte conocimiento, sino porque una decisión que ya habíamos tomado no quedó suficientemente documentada. Entonces volvemos a discutirla, aplicamos un criterio diferente o repetimos un error que ya había sido corregido.
La IA puede ayudar bastante en este punto: resumir decisiones, comparar versiones, detectar contradicciones, transformar observaciones en reglas más claras y reorganizar información extensa. Pero la documentación solo adquiere valor cuando una persona verifica que representa realmente lo ocurrido y decide qué debe convertirse en parte estable del proceso.
Documentar un proceso no es simplemente guardar información
Podemos acumular cientos de conversaciones, documentos, correos, notas y listas de tareas y seguir teniendo un proceso mal documentado.
Guardar información responde a una pregunta: ¿tenemos todavía el contenido?
Documentar responde a otras mucho más importantes:
- ¿qué decidimos?;
- ¿por qué lo decidimos?;
- ¿qué pasos seguimos?;
- ¿qué salió mal?;
- ¿qué corregimos?;
- ¿qué debe repetirse la próxima vez?;
- ¿qué depende del contexto y no debería convertirse en una regla general?;
- ¿qué sigue pendiente?
La diferencia está en convertir información histórica en conocimiento operativo.
Una conversación extensa con IA puede contener una decisión importante escondida entre decenas de mensajes. Si dentro de tres meses tengo que leer todo el intercambio para descubrir qué habíamos acordado, técnicamente conservé la conversación, pero no construí una documentación especialmente útil.
Por eso intento extraer aquello que necesitaré para actuar en el futuro.
Qué información considero útil conservar
No todo lo que ocurre durante un proyecto merece convertirse en una regla permanente.
Si intento documentarlo absolutamente todo, termino creando otro problema: demasiada información para encontrar aquello que realmente importa.
En mis proyectos me resulta más útil distinguir varios tipos de información:
| Tipo de información | Qué conviene conservar | Para qué sirve |
|---|---|---|
| Decisión | Qué se decidió y, cuando importa, por qué | Evitar volver a discutir lo ya resuelto |
| Criterio | Regla que orienta decisiones similares | Mantener consistencia |
| Procedimiento | Secuencia de una tarea repetible | Poder ejecutarla de nuevo |
| Corrección | Problema detectado y solución adoptada | Evitar repetir el error |
| Estado | Qué está terminado, pendiente o bloqueado | Retomar el trabajo |
| Evidencia | Datos, pruebas o fuentes que sustentan una decisión | Poder verificarla después |
| Excepción | Situación donde la regla general no corresponde | Evitar aplicar procesos mecánicamente |
| Revisión futura | Qué necesita volver a comprobarse y por qué | Mantener el sistema actualizado |
Esta separación también ayuda a la IA. Cuanto más claro esté qué tipo de información estamos procesando, más fácil resulta pedirle que la estructure sin mezclar decisiones permanentes con detalles temporales.
Las decisiones importantes necesitan sobrevivir a la conversación donde nacieron
Este es uno de los aprendizajes que más ha influido en mi forma de utilizar IA.
Durante una sesión podemos resolver muchas cosas: cambiar una estructura, descartar un tema, establecer un límite editorial, confirmar una URL, decidir cómo presentar determinada experiencia o corregir una manera de trabajar.
Mientras la conversación está abierta, todo parece evidente.
El problema aparece semanas después.
Podemos recordar la decisión general pero no el detalle. O podemos recordar el resultado y olvidar por qué habíamos descartado la alternativa anterior. Incluso podemos repetir un análisis prácticamente idéntico porque nadie convirtió la conclusión en una referencia reutilizable.
Por eso, cuando una decisión afectará trabajos posteriores, intento que salga de la conversación y pase a alguna forma de documentación estable.
Puede convertirse en:
- una regla editorial;
- una actualización del mapa del proyecto;
- una lista de contenidos terminados;
- un procedimiento;
- una nota de revisión;
- una tabla de estados;
- un contexto de continuidad;
- una lista de control.
La IA puede preparar esa síntesis. Mi responsabilidad es comprobar que no haya simplificado demasiado, omitido una excepción importante o convertido una propuesta provisional en una decisión definitiva.
Utilizo la IA para convertir correcciones en reglas observables
Una corrección aislada resuelve un problema una vez. Un buen proceso intenta reducir la probabilidad de que vuelva a aparecer.
Supongamos que durante la revisión de varios artículos detecto repetidamente un mismo problema: demasiados subtítulos con apenas una o dos frases.
Puedo corregir cada artículo individualmente.
Pero también puedo preguntar qué patrón produjo el problema y convertir la respuesta en una regla más concreta:
No crear un H2 o H3 cuando la idea solo necesita una o dos frases; integrarla en el apartado superior o desarrollarla únicamente cuando exista contenido suficiente para justificar el encabezado.
La segunda forma es mucho más útil que registrar algo como “mejorar la estructura”.
Una buena regla debe permitir comprobar si se está cumpliendo.
Lo mismo ocurre con otras correcciones. En vez de escribir:
Hay que mejorar las metas.
puedo documentar:
La meta debe describir el beneficio real de la página, mantener la misma intención del título y comprobarse antes de publicar.
Cuanto más observable es la regla, más útil resulta tanto para una persona como para una IA.
La herramienta puede ayudarme precisamente a transformar comentarios vagos en criterios operativos.
No todas las correcciones deben convertirse en reglas generales
Existe también el riesgo contrario.
Si cada situación particular se convierte automáticamente en una norma, el sistema termina lleno de reglas contradictorias o innecesariamente rígidas.
Por ejemplo, que un artículo necesite una tabla no significa que todos deban tenerla. Que una introducción concreta sea demasiado extensa no implica que debamos imponer el mismo número de palabras a todas las introducciones.
Por eso, antes de convertir una corrección en regla intento determinar qué clase de problema estoy observando.
Si el error responde a un principio que se repetirá —por ejemplo, inventar URLs, atribuir experiencia inexistente o publicar datos sin verificar— sí merece un criterio estable.
Si depende de una situación concreta, probablemente sea mejor conservarlo como decisión o excepción del contenido específico.
La IA puede ayudar a detectar similitudes entre varias correcciones, pero soy yo quien debe determinar si existe realmente un patrón.
Mi proceso para convertir trabajo repetido en un sistema documentado
Cuando una tarea empieza a repetirse, intento no limitarme a ejecutarla cada vez desde cero. Observo qué partes permanecen relativamente estables y cuáles necesitan adaptarse al contexto.
Una secuencia que me resulta útil es la siguiente:
- Realizo primero el trabajo real. No intento diseñar un procedimiento perfecto sobre una tarea que todavía no comprendo. Necesito haber pasado por el proceso y conocer dónde aparecen las dificultades.
- Registro las decisiones importantes. Qué pasos seguí, qué información necesité, qué alternativas descarté y qué comprobaciones resultaron necesarias.
- Identifico qué se repite. La IA puede ayudarme a comparar varias ejecuciones y detectar elementos comunes, pero reviso personalmente si realmente representan el proceso.
- Separo reglas de decisiones contextuales. Una parte puede mantenerse siempre y otra depender del proyecto, herramienta, audiencia o situación.
- Convierto el proceso en instrucciones ejecutables. Intento que cada paso tenga un propósito claro y que sea posible saber cuándo está terminado.
- Añado controles. Qué debe verificarse antes de dar la tarea por concluida, qué errores son especialmente importantes y qué información no debe asumirse.
- Vuelvo a utilizar el proceso. Solo al aplicarlo nuevamente descubro si la documentación realmente funciona.
- Corrijo el sistema, no solamente el resultado. Si aparece nuevamente el mismo problema, reviso qué parte del procedimiento permitió que pasara.
Este último paso es uno de los más importantes. Un proceso documentado no debería considerarse terminado solo porque existe un documento.
Tiene que sobrevivir al trabajo real.
Los contextos de continuidad me ayudan a retomar proyectos complejos
Cuando gestiono proyectos durante semanas o meses, la continuidad se vuelve un problema en sí misma.
Puedo recordar el objetivo general y, sin embargo, olvidar detalles que condicionan la siguiente tarea:
- qué páginas ya están creadas;
- cuáles están terminadas;
- qué URLs están confirmadas;
- qué contenidos siguen pendientes;
- qué errores ya fueron corregidos;
- qué decisiones no deberían reabrirse;
- qué temas pertenecen a otro proyecto;
- qué información todavía necesita comprobación.
En estos casos utilizo contextos de continuidad.
No pretenden conservar absolutamente todo. Intentan responder una pregunta práctica:
¿Qué necesita saber alguien para continuar correctamente desde este punto?
La IA puede ayudarme a construir ese contexto a partir de conversaciones y documentos extensos. Después lo reviso, porque una omisión aparentemente pequeña puede cambiar una decisión futura.
Esto resulta especialmente útil cuando administro proyectos con muchas páginas y relaciones editoriales. Mantener claras esas fronteras complementa la forma en que organizo varios proyectos digitales sin mezclarlos.
Separo la información estable del estado temporal del proyecto
No toda documentación envejece de la misma manera.
Un principio editorial puede mantenerse durante años. El estado de una entrada puede cambiar mañana.
Si mezclo ambos tipos de información en un solo bloque sin distinguirlos, tarde o temprano aparecerán contradicciones.
Por eso me resulta útil pensar en dos capas.
La primera contiene criterios relativamente estables: propósito del proyecto, alcance, categorías, principios editoriales, forma de atribuir experiencia, políticas de fuentes o reglas fundamentales de publicación.
La segunda contiene estado operativo: qué se está trabajando, qué artículo sigue, qué URL todavía no se ha confirmado, qué página está pendiente de revisión o qué tarea acaba de terminar.
La IA puede utilizar ambas capas, pero no debería tratarlas como equivalentes.
Por ejemplo, “no inventar una URL que no conocemos” puede ser una regla estable.
En cambio, “la URL de este artículo todavía no está confirmada” es una situación temporal. Cuando se confirme, esa información necesita actualizarse.
Esta diferencia evita que una nota antigua termine convirtiéndose en una instrucción obsoleta.
También utilizo IA para comparar documentación y detectar contradicciones
Cuando un proyecto empieza a acumular documentos, puede ocurrir que dos referencias digan cosas diferentes.
Una arquitectura inicial puede haber sido actualizada. Un inventario antiguo puede mostrar menos contenidos de los que ya existen. Una decisión posterior puede haber corregido una regla anterior.
Revisar manualmente documentos extensos puede ser laborioso.
Aquí la IA puede ayudar a comparar:
- versiones de un procedimiento;
- listas de contenidos;
- criterios editoriales;
- estados de proyecto;
- instrucciones antiguas y nuevas;
- decisiones aparentemente incompatibles.
El objetivo no es pedirle que decida automáticamente cuál tiene razón.
Quiero que señale la discrepancia.
Después puedo determinar qué documento tiene prioridad, qué decisión es más reciente o si simplemente estamos ante dos reglas aplicables a situaciones diferentes.
Esta capacidad de comparación resulta especialmente valiosa antes de comenzar una tarea importante. Permite descubrir problemas en el sistema antes de trasladarlos al resultado.
Un procedimiento útil debe explicar también qué no hacer
Una documentación compuesta únicamente por pasos puede parecer completa y seguir siendo insuficiente.
A veces los errores importantes aparecen precisamente en las fronteras.
Por eso, además de explicar qué hacer, intento registrar determinados límites.
Por ejemplo, un proceso editorial puede indicar:
- no atribuir experiencia que no existe;
- no inventar una URL;
- no asumir que una interfaz continúa igual sin comprobarla;
- no crear una página nueva antes de revisar las existentes;
- no convertir una investigación en un supuesto caso propio;
- no aplicar automáticamente una recomendación que depende del contexto.
Estas restricciones tienen una función distinta de los pasos.
Los pasos indican la ruta habitual.
Los límites protegen contra errores previsibles.
En sistemas asistidos con IA esto me parece especialmente importante porque una respuesta puede ser lingüísticamente convincente incluso cuando partió de una suposición equivocada.
La lista de control sirve para cerrar el proceso
Mientras un procedimiento explica cómo realizar una tarea, una lista de control responde otra pregunta:
¿qué debo comprobar antes de considerarla terminada?
No necesito convertir cualquier actividad en una lista de veinte puntos. Pero en tareas donde determinados errores se repiten, una comprobación final puede evitar bastante retrabajo.
En un contenido web, por ejemplo, podría revisar:
- ¿responde realmente a la intención definida?;
- ¿las afirmaciones importantes están verificadas?;
- ¿la experiencia atribuida es real?;
- ¿los enlaces llevan a destinos confirmados?;
- ¿la estructura tiene apartados suficientemente desarrollados?;
- ¿existen repeticiones innecesarias?;
- ¿hay instrucciones internas que no deberían publicarse?;
- ¿el artículo aporta algo específico?;
- ¿la conclusión responde a lo desarrollado?
La IA puede ejecutar una primera revisión a partir de estos criterios.
Pero no considero que marcar automáticamente todas las casillas sustituya la revisión humana. Necesito comprobar especialmente aquello que depende de hechos, experiencia o decisiones editoriales.
Mejorar un proceso exige revisar también sus resultados
Documentar no debería congelar una forma de trabajar.
Un procedimiento que funcionaba bien puede dejar de hacerlo porque cambia el proyecto, aparece nueva información, una herramienta modifica su funcionamiento o descubrimos una manera más sencilla de alcanzar el mismo resultado.
Por eso intento relacionar proceso y resultado.
Si una tarea termina bien de forma consistente, el procedimiento probablemente está ayudando.
Si aparecen continuamente los mismos errores, tengo varias posibilidades:
- la regla no está clara;
- el contexto no llega a quien ejecuta la tarea;
- falta una comprobación;
- existen instrucciones contradictorias;
- el procedimiento es demasiado complejo;
- o el problema no fue correctamente identificado.
La IA puede ayudarme a comparar incidencias y buscar patrones.
Pero mejorar el sistema requiere decidir qué cambiar y observar qué ocurre en la siguiente ejecución.
Utilizo un ciclo sencillo de mejora
No necesito una metodología complicada para cada tarea. Me resulta suficiente trabajar con un ciclo básico:
Primero, ejecuto. Necesito un proceso real y un resultado observable.
Después, observo. Identifico qué funcionó, dónde apareció fricción y qué errores necesitaron corrección.
Luego, documento. Registro aquello que debería conservarse para la siguiente vez.
A continuación, ajusto. Modifico pasos, reglas, controles o contexto.
Finalmente, vuelvo a ejecutar. La siguiente tarea permite comprobar si la modificación produjo una mejora real.
La IA puede participar en todas estas etapas: resumir, comparar, señalar diferencias y ayudar a reescribir el procedimiento.
Pero el ciclo solo tiene sentido si la experiencia posterior modifica la documentación cuando es necesario.
Un manual que nunca cambia puede convertirse gradualmente en un registro histórico en lugar de un sistema de trabajo.
Evito documentar procedimientos que todavía no conozco suficientemente
La IA puede producir un procedimiento muy convincente para casi cualquier actividad.
Eso no significa que ese procedimiento haya sido validado.
Existe una diferencia entre utilizarla para explorar cómo podría realizarse algo y publicar o adoptar esas instrucciones como si ya fueran un método probado.
Si todavía no he realizado una tarea, puedo preparar:
- preguntas;
- posibles pasos;
- riesgos;
- aspectos que necesito investigar;
- una primera hipótesis de trabajo.
Pero prefiero tratarlo como una propuesta.
Después de ejecutar el proceso puedo documentar qué ocurrió realmente.
Este criterio evita que la documentación se llene de sistemas teóricos que parecen completos porque están bien redactados, aunque nadie los haya puesto a prueba.
La documentación excesiva también puede convertirse en un problema
Existe una tentación de crear manuales para cualquier cosa una vez que la IA facilita tanto escribirlos.
No considero que eso sea necesariamente una mejora.
Un procedimiento de dos minutos no necesita siempre diez páginas de documentación. Una regla que puede expresarse con claridad en una frase tampoco requiere convertirse en un capítulo.
La documentación debería reducir fricción, no crearla.
Antes de ampliar un sistema me resulta útil preguntar:
- ¿esta información se necesitará nuevamente?;
- ¿evita un error relevante?;
- ¿ayuda a otra persona o a mi yo futuro a continuar?;
- ¿es difícil reconstruir la decisión después?;
- ¿la tarea se repite suficientemente?;
- ¿hay consecuencias si se ejecuta mal?
Cuanto más importantes sean esas respuestas, más sentido tiene documentar.
La IA reduce el costo de producir documentación, pero no elimina el costo de mantenerla.
Un buen sistema necesita saber cuál es su fuente de verdad
Cuando existen varias notas sobre el mismo tema, es importante saber cuál tiene prioridad.
De lo contrario podemos terminar con una arquitectura que dice una cosa, una conversación posterior que dice otra y una lista antigua que conserva todavía la primera versión.
En mis proyectos intento que las decisiones importantes terminen reflejadas en una referencia identificable.
Eso no significa que todos los documentos tengan que fusionarse.
Significa que necesito poder determinar:
- qué documento contiene las reglas principales;
- dónde se mantiene el estado actual;
- cuál versión está vigente;
- qué información es solo histórica;
- qué decisiones posteriores modificaron una regla anterior.
Este orden también mejora el trabajo con IA.
Si proporciono cinco documentos contradictorios y no indico qué jerarquía tienen, no debería esperar que la herramienta adivine correctamente qué decisión sigue vigente.
El contexto también necesita arquitectura.
Documentar por qué decidí algo puede ser tan importante como documentar qué decidí
No todas las decisiones necesitan una justificación extensa.
Pero algunas pierden sentido cuando solamente conservamos el resultado.
Supongamos que decido no crear una nueva página sobre determinado tema.
Meses después puedo encontrar nuevamente la misma idea y pensar que olvidé desarrollarla.
Si la documentación únicamente dice “no crear”, no sé si el motivo sigue siendo válido.
En cambio, registrar que la intención ya está cubierta por otra URL permite volver a evaluar la decisión cuando cambien las circunstancias.
Lo mismo ocurre al elegir una herramienta, descartar un plugin, separar dos proyectos o mantener una categoría fuera del índice.
El razonamiento aporta contexto para futuras revisiones.
La IA puede ayudar a resumir esa justificación sin conservar una conversación completa.
También documento incertidumbres y asuntos pendientes
Un sistema útil no debería aparentar que todas las decisiones están cerradas.
A veces todavía falta información.
Puedo estar evaluando una herramienta, esperando datos, investigando una nueva opción o posponiendo una decisión hasta adquirir experiencia.
En esos casos prefiero documentar claramente el estado:
- pendiente de verificar;
- hipótesis;
- decisión provisional;
- aprendizaje en curso;
- requiere datos;
- revisar después de determinada etapa.
Esto evita un problema importante: que una suposición temporal reaparezca meses después presentada como un hecho.
También encaja con la forma en que intento distinguir experiencia, investigación y aprendizaje dentro de mi metodología editorial.
Cómo compruebo que un proceso realmente mejoró
No considero mejor un proceso únicamente porque ahora tenga un documento más extenso.
Busco señales más prácticas.
Un proceso mejora cuando:
- puedo retomarlo con menos reconstrucción;
- disminuyen errores que antes se repetían;
- las decisiones son más consistentes;
- sé dónde buscar la información relevante;
- puedo explicar por qué se sigue determinado criterio;
- las excepciones están suficientemente claras;
- una nueva ejecución requiere menos correcciones;
- puedo actualizar una regla sin rehacer todo el sistema.
También me interesa cuánto esfuerzo exige mantenerlo.
Una documentación que evita cinco minutos de trabajo pero necesita una hora mensual para actualizarse probablemente no sea especialmente eficiente.
Por eso la mejora no consiste solamente en añadir controles. A veces mejorar significa simplificar.
La IA me ayuda a conservar aprendizaje, pero la documentación sigue necesitando responsable
Una de las mayores ventajas que encuentro en la inteligencia artificial es su capacidad para ayudarnos a convertir trabajo disperso en información estructurada.
Puede analizar conversaciones extensas, comparar versiones, detectar patrones, resumir decisiones y reformular instrucciones ambiguas.
Eso permite que una corrección deje de ser un incidente aislado y se convierta en aprendizaje reutilizable.
Pero también puede resumir mal, perder un matiz, mezclar dos decisiones o llenar un vacío con una inferencia que nunca acordamos.
Por eso no considero la documentación generada por IA como una fuente de verdad automática.
La trato como un borrador que necesita validación.
Dentro de la inteligencia artificial aplicada a proyectos digitales, este es uno de los usos que más valor encuentro: no pedir a la tecnología únicamente que haga más trabajo, sino utilizarla para que el trabajo realizado deje mejores sistemas para la siguiente vez.
Cuando una experiencia produce una decisión, la decisión se documenta y la documentación mejora el próximo proceso, la IA está ayudando a construir capacidad acumulativa.
Ese resultado me parece más valioso que ahorrar unos minutos en una tarea aislada.
