Construir un chatbot parece sencillo. Diseñar un agente de inteligencia artificial capaz de revisar un contrato de 50 páginas y proponer redlines sin romper el formato del documento es otra historia. En este artículo repasamos cómo abordé este reto como proyecto de fin de semana y cómo terminé diseñando un sistema para automatizar la revisión contractual pensado para equipos legales.
El núcleo del problema no es llamar a una API de LLM. Es todo lo demás: mantener la estructura del documento, lidiar con párrafos que cambian, y generar cambios controlados en Microsoft Word en formato de control de cambios OOXML.
El espacio de problemas La revisión de contratos sigue un patrón predecible. Un equipo legal recibe un contrato con redlines del contraparte, revisa cada cambio frente a las políticas de riesgo de la organización y acepta, rechaza o modifica cada sugerencia. Ese proceso puede tomar horas por documento. Para automatizarlo hay que resolver varias capas: analizar contratos contra guías específicas, generar sugerencias textuales con fundamentación, aplicar los cambios como tracked changes en Word y sobrevivir a las mutaciones del documento cuando los usuarios editan mientras el análisis está en curso.
Muchas herramientas se quedan en la interfaz de chat. Generan sugerencias que el usuario debe copiar y pegar. Eso no es automatización, es un Ctrl+F más elegante. Aquí explico la arquitectura y los patrones que permiten una automatización real.
Arquitectura general Tres componentes principales: una interfaz web para gestión de reglas y métricas, un complemento para Word que muta el documento sin romper su formato y un backend que orquesta el análisis y el procesamiento de OOXML. En la práctica la lógica crítica vive en el add-in de Word y en la API que procesa documentos y coordina los modelos.
Reto 1: el documento mutable Un fallo común: asignar sugerencias a índices de párrafo en el momento del análisis. Si el usuario borra o mueve párrafos antes de aplicar las sugerencias, estas quedan desalineadas. La solución es anclar párrafos con identificadores persistentes integrados en el OOXML. Al preprocesar el DOCX se insertan marcas que persisten frente a operaciones comunes como cortar y pegar o aceptar cambios. En el cliente una estructura ligera mantiene dos mapas bidireccionales entre índice y UUID y resuelve en tiempo de aplicación dónde está el párrafo que corresponde a cada sugerencia.
Reto 2: generar tracked changes en Word Office.js no expone una API nativa para crear redlines. insertText reemplaza texto pero no genera un control de cambios real. La aproximación que funciona es: generar un diff entre el texto original y la sugerencia, mapear ese diff a fragmentos OOXML y aplicar esos fragmentos respetando las propiedades de párrafo. Los diffs a nivel de carácter generan basura visual en Word. Por eso implementamos un diff basado en tokens. Un cambio como cambiar brown por red se representa como inserciones y eliminaciones limpias, no como un mosaico de caracteres cambiados. Además hay que preservar numeración, estilos e indentación: la sustitución naive destruye el formato y eso es inaceptable en contratos.
Reto 3: análisis de larga duración Un contrato de 50 páginas sometido a 30 reglas puede tardar varios minutos. Las peticiones HTTP no deben bloquear tanto tiempo. El patrón que usamos es asincronía basada en sesión: el cliente crea una sesión, el servidor lanza una tarea en background y el cliente consulta el estado periódicamente por SSE o polling. Junto a esto, la validación por hash de contenido evita rehacer análisis innecesarios cuando el documento no cambió. En producción la caché reduce un porcentaje apreciable de trabajo redundante.
Reto 4: anclaje y prevención de alucinaciones En documentos legales la precisión es crítica. Un modelo que sugiere un tope de responsabilidad distinto al que figura en el contrato es peor que no sugerir nada. La solución pasa por imponer salidas estructuradas que incluyan citas textuales al fragmento fuente. Cada sugerencia debe referenciar el texto exacto y una validación adicional comprueba que el fragmento citado existe en la versión actual del documento.
Puesta en conjunto: la canalización de análisis El flujo clásico es ingestión DOCX y extracción a OOXML, normalización que produce vistas sincronizadas original y revisada en un formato markdown unificado, análisis por reglas y LLM con salida estructurada y finalmente generación de OOXML con tracked changes mediante el algoritmo de token diff. Mantener la complejidad en la capa de conversión OOXML a markdown permite que el LLM trabaje sobre texto limpio sin perder fidelidad del documento.
Resultados y métricas Con esta arquitectura un documento de unas 20 páginas se procesa en 30 a 45 segundos según la complejidad de reglas. Métricas típicas en un despliegue: tasa de aciertos de caché cercana a 40 por ciento, tasa de alucinación menor al 5 por ciento gracias a validaciones y conservación de formato superior al 95 por ciento en propiedades de párrafo.
Lecciones aprendidas Office.js es potente pero está poco documentado para manipulación avanzada de OOXML. Los diffs deben ser tokenizados, no a nivel de carácter. Los patrones asíncronos y la gestión de estado ante recarga de navegador o reinicios de servidor requieren cuidados adicionales. La validación que obliga a referencias explícitas al texto fuente reduce drásticamente errores de interpretación del modelo, y los hashes de contenido son un seguro económico ante coste de LLM.
Cómo encaja Q2BSTUDIO En Q2BSTUDIO como empresa de desarrollo de software y aplicaciones a medida transformamos estos patrones en soluciones productivas para clientes. Somos especialistas en software a medida, inteligencia artificial y ciberseguridad y trabajamos integrando servicios cloud aws y azure y soluciones de inteligencia de negocio como Power BI. Si su objetivo es automatizar procesos legales, implantar agentes IA o desarrollar una aplicación a medida que conserve fidelidad documental, en Q2BSTUDIO podemos ayudar.
Por ejemplo, ofrecemos proyectos de inteligencia artificial para empresas que incluyen diseño de agentes IA y pipelines seguros de procesamiento de documentos. Con una aproximación industrial resolvemos problemas de anclaje, control de cambios y trazabilidad. Vea nuestras capacidades en IA en servicios de inteligencia artificial y descubra cómo podemos desarrollar soluciones a medida consultando nuestra página de desarrollo de aplicaciones y software a medida.
Conclusión La parte interesante de los productos de IA rara vez es simplemente llamar al modelo. El verdadero trabajo es mantener la fidelidad de los datos, gestionar estado en operaciones largas y proteger la salida con capas de validación. En el caso de revisión contractual esas capas incluyen anclaje de párrafos, manipulación de OOXML y diffs tokenizados. Si está construyendo en este espacio, nos interesa conocer su enfoque y explorar colaboraciones para llevar agentes IA robustos a producción con todas las garantías de seguridad y cumplimiento que exige el entorno legal y empresarial.