Del documento al artefacto vivo: qué estructurar antes de automatizar

Una empresa tiene el mismo procedimiento de incorporación en una guía de Word, tres páginas de la intranet, una presentación para responsables, un curso y las respuestas de su asistente interno. El departamento de Recursos Humanos cambia una condición. Una persona corrige el documento principal y otra se acuerda de una de las páginas. Sin embargo, el curso no se actualiza hasta la siguiente reedición y el asistente continúa citando la versión anterior.

La tentación consiste en pedir a la inteligencia artificial que mantenga sincronizados los cinco formatos. Ese encargo automatiza la propagación, pero no resuelve la pregunta incómoda: ¿dónde está la decisión que todos deben respetar? Si la organización no puede señalarla, la IA solo distribuirá contradicciones con más rapidez.

Un artefacto vivo es una unidad con identidad, estructura, propietario, procedencia, historial, validaciones y ciclo de vida. Por tanto, no basta con una web que se regenera sola ni con un PDF que lleva un chatbot encima. Puede publicarse como HTML, PDF, Word, presentación, API o respuesta conversacional, pero ninguna de esas vistas se convierte por naturaleza en la fuente de verdad.

Antes de automatizar documentos, separa tres cosas: las decisiones que deben permanecer coherentes, las reglas que autorizan sus cambios y las vistas que necesita cada audiencia.

El problema no es el formato, sino la verdad duplicada

Word, Excel, PowerPoint y PDF siguen resolviendo problemas reales: la revisión con cambios, el cálculo y el modelado, el relato visual, la firma, el intercambio y la conservación de una representación fija. También son herramientas conocidas por quienes producen y aprueban el contenido.

El problema aparece cuando un archivo intenta ser simultáneamente base de datos, interfaz, registro de decisiones, canal de publicación y contrato entre sistemas. Un párrafo como «los gastos superiores a 300 euros requieren aprobación» contiene al menos una regla, un umbral, una moneda, una acción, un responsable, excepciones, una fecha de vigencia y una fuente normativa. Dentro de un documento resulta legible; para reutilizarlo y comprobarlo, sigue siendo una cadena de texto.

Copiar esa cadena a una intranet, un flujo de aprobación y un asistente crea tres interpretaciones. Ni un buscador semántico ni una ventana de entrada más larga permiten decidir cuál debe prevalecer. Recuperar bien cinco versiones incompatibles continúa siendo recuperar una contradicción.

Por eso el cambio consiste en decidir qué partes merecen identidad y estructura propias, no en «pasar todo a HTML». HTML ofrece una vista especialmente útil: es accesible desde un navegador, enlazable, adaptable y fácil de integrar. Aun así, puede ser tan estático y opaco como un PDF si contiene texto sin modelo, procedencia ni proceso de revisión.

Qué convierte un contenido en artefacto vivo

Usaría el término solo cuando se cumplan estas condiciones:

1. Identidad estable. Cada unidad relevante tiene un identificador que no depende de su título ni de la página donde aparece.
2. Estructura explícita. Un esquema distingue campos, tipos, relaciones y restricciones. El significado importante no queda escondido únicamente en prosa.
3. Procedencia. Puede saberse qué fuente, persona o proceso originó una afirmación y qué revisión la sustituyó.
4. Estado y versión. Borrador, aprobado, vigente, sustituido y retirado no son etiquetas decorativas; condicionan qué se puede publicar o consultar.
5. Propiedad. Existe una persona o función responsable de revisar la unidad, resolver conflictos y decidir su retirada.
6. Validación. El sistema comprueba esquema, referencias, fechas, permisos, accesibilidad y coherencia antes de publicar.
7. Proyecciones derivadas. Las distintas salidas se generan desde la misma versión aprobada o declaran de forma visible por qué se apartan de ella.
8. Ciclo de vida. Se observan uso, errores y caducidad; se puede corregir o volver a una versión anterior sin ocultar el historial.

Esta definición bebe de prácticas que existen desde antes de la IA. DITA trata el topic como unidad básica de autoría y reutilización. También permite referenciar contenido por identificadores y aplicar condiciones para distintos entregables. JSON Schema expresa y valida la forma de una instancia, además de añadir anotaciones como el título o la descripción. PROV-O modela entidades, actividades, agentes, derivaciones, atribuciones y revisiones. Ninguna especificación entrega por sí sola un sistema editorial, pero juntas demuestran que la estructura, la identidad y la procedencia son problemas conocidos.

La inteligencia artificial cambia el coste de extraer, clasificar, relacionar y redactar, pero no elimina la necesidad de decidir qué representación está autorizada. La distinción entre el material recuperado y el autorizado también determina cómo gobernar el suministro de un sistema RAG o un agente.

Tres capas que no conviene mezclar

Una arquitectura mantenible separa el modelo canónico, el gobierno y las proyecciones.

1. El modelo canónico

El modelo contiene las unidades que otros procesos necesitan interpretar sin depender de una página concreta: conceptos, hechos, reglas, pasos, roles, productos, competencias, evidencias, excepciones y relaciones. No tiene por qué guardar toda la prosa como campos diminutos. Puede combinar objetos estructurados con explicaciones, siempre que la frontera sea deliberada.

El modelo tampoco tiene que ser una única base de datos. Un repositorio versionado, un sistema de gestión de contenido, una base relacional y un grafo pueden compartir responsabilidades. «Canónico» significa que la autoridad y la resolución de conflictos están definidas, no que toda la organización escriba en la misma tabla.

2. El gobierno de cambios

El gobierno responde a preguntas que un formato no puede resolver: quién propone, quién revisa, qué evidencia exige una modificación, qué validaciones son obligatorias, cuándo entra en vigor, quién puede ver información restringida y cuánto tiempo se conserva. También registra la relación entre una versión y sus fuentes.

La IA se sitúa en esta capa para extraer una regla de un documento, detectar que dos objetos discrepan o proponer un parche, pero no puede convertir su inferencia en política aprobada sin pasar por las autorizaciones y pruebas del dominio.

3. Las proyecciones

Las proyecciones son las vistas destinadas a personas y sistemas. Pueden ser una página HTML accesible, un PDF para archivo, un documento editable para negociación, una presentación, un catálogo o una API. También incluyen el material que recibe un buscador o la herramienta que consulta un agente. Cada vista selecciona y ordena información para una tarea.

Pandoc ilustra parte de esta idea con lectores, una representación intermedia y conversores de salida para distintos formatos. Su propia documentación advierte de que no todas las conversiones son perfectas: la representación intermedia no expresa todos los detalles de los formatos de origen y algunas transformaciones pierden información. La lección no es «usar Pandoc para todo», sino diseñar de forma explícita qué semántica debe sobrevivir a cada proyección y probarla.

Documento, contenido estructurado o producto

No todo merece la misma solución. Antes de migrar, clasificaría el caso por comportamiento:

Un mismo proceso puede usar las tres formas. La política de gastos puede estar estructurada; el formulario y sus cálculos pertenecen a una aplicación; la resolución firmada se conserva como documento. Forzar una única tecnología empobrece el sistema.

Estructuraría cuando una unidad se repite, cambia con frecuencia, alimenta varias salidas, necesita referencias estables, debe consultarse por atributos o requiere validaciones automáticas. Mantendría un documento cuando prima la negociación humana, la firma, el archivo regulado, la maquetación exacta o el coste de modelar supera claramente el de mantenerlo.

La IA propone cambios; las reglas y las personas autorizadas deciden si se aceptan

La automatización más segura produce una propuesta verificable en lugar de limitarse a pedir «actualiza toda la documentación»:

1. identifica la fuente y su versión;
2. extrae unidades candidatas con enlaces al fragmento original;
3. compara cada candidata con el modelo vigente;
4. clasifica altas, cambios, conflictos y posibles retiradas;
5. genera un conjunto de cambios legible por una persona y por las validaciones;
6. bloquea lo que no tiene evidencia, propietario o permisos suficientes;
7. solicita la aprobación correspondiente;
8. publica todas las vistas desde la versión aceptada;
9. registra qué versión recibió cada canal.

Este flujo reduce el daño de una extracción incorrecta y permite usar modelos distintos sin convertir a ninguno en autoridad. La confianza se deposita en el contrato de datos, la evidencia, las pruebas y la aprobación, no en la elocuencia de la respuesta. Por esa misma razón, verificar el resultado de una automatización con IA exige invariantes y efectos observables, no solo una ejecución sin errores.

Para la recuperación y los agentes, consultaría objetos canónicos con identificador, versión, vigencia y permisos, y exigiría que cada respuesta indicase qué objetos utilizó. Si una persona pregunta por una excepción, el agente debería invocar la operación autorizada que devuelve la regla vigente y sus condiciones, en vez de extraer el contenido de la primera página que encuentre. El contenido mostrado puede seguir siendo HTML, mientras la decisión se apoye en el objeto canónico que hay detrás.

Ejemplo: una política de certificación reutilizada en cinco canales

Imaginemos una organización que certifica una competencia cuando una persona completa dos módulos, supera una práctica y obtiene una validación del responsable. La regla aparece en el campus, un manual, correos de soporte, el sistema de insignias y un asistente.

Un modelo mínimo podría comenzar así:

{
  "id": "certificacion.seguridad.nivel-1",
  "version": "2026-07",
  "status": "approved",
  "effectiveFrom": "2026-09-01",
  "owner": "learning-governance",
  "requirements": [
    { "type": "module", "id": "seguridad-fundamentos", "result": "completed" },
    { "type": "module", "id": "seguridad-practica", "result": "completed" },
    { "type": "assessment", "id": "simulacion-n1", "minimumScore": 80 },
    { "type": "approval", "role": "line-manager" }
  ],
  "exceptions": [],
  "reviewBy": "2027-03-01",
  "provenance": ["decision.comite-seguridad.2026-07-14"]
}

No propongo este JSON como estándar universal. Lo uso para hacer visibles las decisiones que antes estaban repartidas en una frase: identidad, versión, estado, vigencia, propietario, requisitos, umbral, excepción, revisión y procedencia.

Desde ese objeto se puede generar una explicación para el campus, una tabla en el manual, una lista de comprobación para responsables y los datos que usa el asistente. El sistema de insignias no debería copiar la explicación: debería evaluar una regla implementada y versionada contra las evidencias autorizadas. Si existe una excepción, se añade al objeto o a una entidad relacionada y se vuelve a publicar. No se corrigen cinco textos a mano.

La prosa sigue siendo necesaria para explicar el propósito, los ejemplos y los casos límite. La estructura no la sustituye; impide que la decisión operativa dependa únicamente de cómo alguien interpretó un párrafo.

Qué hay que probar

Una canalización de este tipo necesita pruebas editoriales, técnicas y operativas. Como mínimo comprobaría:

• todos los objetos tienen identificador único, propietario, estado y versión;
• el esquema acepta tipos válidos y rechaza campos o combinaciones imposibles;
• no quedan referencias sin resolver ni relaciones circulares no permitidas;
• ninguna regla vencida aparece como vigente;
• cada afirmación sensible conserva fuente y fecha de revisión;
• todas las salidas publicadas muestran la misma versión canónica;
• los permisos y la ocultación de datos se mantienen en la búsqueda, la exportación y las herramientas de los agentes;
• la vista web cumple los criterios de accesibilidad aplicables de WCAG 2.2 y se somete a pruebas sobre el flujo completo;
• una corrección puede publicarse y revertirse sin perder el historial;
• las respuestas generadas citan objetos existentes y no mezclan versiones;
• un fallo parcial no deja unos canales actualizados y otros sin estado conocido;
• retirar una unidad elimina su disponibilidad sin borrar la trazabilidad necesaria.

Validar la sintaxis no basta: JSON Schema puede confirmar que minimumScore es un número dentro de un rango, pero no decidir si el comité autorizó un 80 o un 85. PROV-O puede representar una atribución, pero no demuestra que la fuente sea fiable. Las pruebas automáticas acotan los errores; el gobierno conserva la responsabilidad.

Una migración que no traslade la basura

Empezaría por un dominio pequeño y conflictivo, no por «todos los documentos». La secuencia sería esta:

1. Inventariar decisiones y usos. Qué reglas, hechos y procedimientos consumen qué personas y sistemas; qué archivos los duplican.
2. Asignar propietarios. Lo que nadie puede aprobar o retirar no está preparado para automatizarse.
3. Separar hechos, reglas y explicación. Estructurar solo lo que necesita comparación, reutilización o ejecución.
4. Modelar la unidad mínima útil. Evitar un esquema corporativo total antes de demostrar valor con un caso.
5. Conservar procedencia. Enlazar cada objeto con la fuente y la decisión que autorizó su estado.
6. Publicar dos vistas. Por ejemplo, web y PDF. Si no pueden demostrar equivalencia, añadir canales multiplicará el problema.
7. Probar accesibilidad, permisos y reversión. La automatización no compensa una salida inaccesible o una filtración.
8. Retirar duplicados. Marcar archivos anteriores como sustituidos y eliminar copias sin valor conforme a la política de conservación.
9. Automatizar propuestas. Solo después de que identidad, esquema, revisión y publicación funcionen sin depender del modelo.

La retirada es parte del proyecto. Mantener la carpeta antigua «por si acaso» hace que vuelva a indexarse, citarse o editarse. Si debe conservarse por auditoría, se archiva con estado, alcance y acceso explícitos; no permanece como una segunda fuente operativa.

Medir coherencia, no volumen de generación

El número de páginas creadas o el tiempo ahorrado al redactarlas puede servir como dato de productividad, pero no demuestra que el conocimiento sea mejor. Mediría:

• tiempo entre aprobar un cambio y publicarlo en todas las vistas;
• número de versiones divergentes sin resolver;
• porcentaje de objetos vigentes con propietario, evidencia y fecha de revisión;
• unidades caducadas todavía disponibles para consulta;
• errores bloqueados por validación antes de publicar;
• respuestas de IA correctas y trazables sobre una muestra de preguntas críticas;
• diferencias semánticas detectadas entre salidas;
• tiempo y éxito de una reversión;
• duplicados retirados frente a nuevas copias creadas.

Una buena automatización puede generar menos artefactos y mejorar más el sistema. Para lograrlo, debe conseguir que una decisión aprobada llegue a quien la necesita, en la forma adecuada y sin perder autoridad ni circunstancias de aplicación.

Cuándo no merece la pena

No transformaría un documento solo porque un modelo pueda extraerlo. Mantendría el formato actual cuando:

• cambia poco y solo existe una salida o audiencia relevante;
• su valor depende de la firma, los comentarios, la negociación o la disposición exacta;
• no hay propietario capaz de resolver discrepancias;
• la organización no puede validar el modelo resultante;
• el contenido es demasiado pequeño o efímero para amortizar esquema, proceso y mantenimiento;
• una obligación legal o de archivo exige conservar el artefacto como representación autorizada.

También frenaría si el proyecto empieza discutiendo bases vectoriales, grafos o generadores antes de identificar las decisiones duplicadas. Esas tecnologías pueden ser adecuadas, pero no sustituyen el modelo operativo. Sin gobierno, un grafo representa contradicciones con mucha precisión. Sin vigencia, un sistema RAG recupera mejor contenido caducado; el patrón se parece al de un RAG educativo que alucina pese a recuperar fragmentos. Del mismo modo, un agente sin operaciones autorizadas improvisa sobre vistas.

HTML es una vista; la estructura y el gobierno son el sistema

La IA no marca el final de Word, PDF o Excel, sino el de una comodidad peligrosa: creer que basta con crear otro archivo y confiar en que todos recordarán actualizarlo.

El artefacto vivo aparece cuando una organización puede responder qué sabe, quién lo autorizó, desde cuándo es válido, dónde se reutiliza, qué pruebas ha pasado y cómo se retira. HTML suele ser una forma excelente de presentarlo y un PDF puede ser la salida correcta para conservarlo. Para negociarlo, un documento continúa siendo el espacio idóneo. Un agente puede facilitar la consulta de cualquiera de esas vistas.

Ninguno de esos formatos es la fuente de verdad por decreto. Esa función le corresponde al contrato que une identidad, estructura, procedencia, aprobación y ciclo de vida. Automatizar antes de construirlo solo permite equivocarse a mayor escala.