Cómo automatizamos la generación de documentos RGPD en un despacho de abogados

Hay un tipo de proyecto que nos gusta especialmente: cuando el problema es claro, el proceso es repetible, y la automatización produce un resultado medible en horas de trabajo ahorradas. Este fue uno de esos.

El cliente es un despacho de abogados especializado en cumplimiento RGPD. Asesoran a empresas en todo lo relacionado con el Reglamento General de Protección de Datos: auditorías, contratos con encargados del tratamiento, análisis de impacto, políticas de privacidad. Cuatro tipos de documentos principalmente, cada uno con su estructura, sus campos específicos, y su lógica de contenido en función del tipo de cliente y sector.

Antes de la automatización, generar cualquiera de esos documentos era un proceso manual de entre 45 minutos y 2 horas. Buscaban el documento anterior más parecido, lo abrían en Word, cambiaban los datos del cliente nuevo, revisaban que no quedaran referencias al cliente anterior (paso crítico y frecuentemente fallido), exportaban a PDF, lo enviaban por email, esperaban la firma, y archivaban el documento firmado.

Con un volumen de entre 8 y 12 documentos por semana, el equipo dedicaba entre 14 y 18 horas semanales a ese proceso. No a trabajo jurídico. A copiar, pegar, revisar, exportar, enviar, y archivar.

Lo que querían conseguir

El brief inicial era simple: "queremos generar el documento en PDF, mandárselo al cliente, y que esté listo para firma en menos de 5 minutos desde que introducimos los datos."

Cinco minutos desde la introducción de datos hasta el portal de firma. Para documentos que antes tardaban hasta dos horas en salir, y con los errores de copia y pega que inevitablemente ocurrían.

El reto técnico añadido: los documentos tienen que cumplir RGPD. Eso significa que el propio sistema de generación tenía que gestionar correctamente los datos personales que procesaba —datos de los clientes del despacho y, en algunos casos, datos de los empleados de esas empresas—.

Un sistema para automatizar el cumplimiento RGPD que no cumple él mismo el RGPD es un problema de reputación considerable para un despacho de abogados.

La arquitectura del flujo

Diseñamos un flujo en cinco etapas:

Formulario → n8n → Plantilla → PDF → Google Drive → Email al cliente → Portal Signaturit → Actualización de estado en portal CI4

Vamos por partes.

El portal CI4: tres roles, un flujo

Construimos el portal de gestión en CodeIgniter 4 con tres niveles de acceso claramente diferenciados.

Los socios del despacho tienen visibilidad completa: todos los documentos, todos los clientes, el historial de firmas, y la capacidad de aprobar documentos que por su complejidad requieren revisión antes de enviarse (fundamentalmente los DPIAs más complejos). También pueden editar plantillas y configurar el sistema.

El personal de secretaría tiene acceso al generador de documentos: rellenan el formulario con los datos del cliente, seleccionan el tipo de documento, y lanzan la generación. Pueden ver el estado de todos los documentos (generado, enviado, firmado, archivado) y hacer seguimiento de los pendientes.

Los clientes del despacho acceden con un link externo de solo lectura: pueden ver sus documentos, su estado, y firmar a través del enlace a Signaturit. No tienen acceso al sistema interno.

n8n como motor de generación

El webhook de n8n recibe el POST del formulario CI4 con todos los datos del cliente y el tipo de documento solicitado.

El primer nodo es un Switch que lee el campo document_type y dirige el flujo a la rama correspondiente: contrato de gestión RGPD, DPIA, acuerdo con encargado del tratamiento, o política de privacidad. Cada rama tiene su propia plantilla Word y su propio mapeo de campos.

Las plantillas Word usan la sintaxis de docxtemplater: los campos del documento son variables entre llaves como {nombre_empresa}, {nif_responsable}, {base_juridica_principal}, {plazo_conservacion}. Cuando el nodo de generación ejecuta docxtemplater con el objeto de datos del cliente, sustituye cada variable por el valor correspondiente. Si un campo no se mapea, docxtemplater devuelve un error claro —no deja la variable sin sustituir silenciosamente—.

La conversión de Word a PDF se hace con LibreOffice en modo headless. Evaluamos CloudConvert y similares, pero hay una razón de peso para no usarlos: los datos que contienen esos documentos son datos personales bajo RGPD, y enviarlos a un servicio externo de conversión requiere base jurídica, contrato con encargado del tratamiento, y posibles transferencias internacionales si el proveedor tiene servidores fuera de la UE. LibreOffice instalado en el propio servidor convierte localmente, sin que los datos salgan del entorno controlado del despacho. Ese es el estándar correcto para este tipo de proyecto.

Google Drive con estructura de carpetas

El PDF generado se sube a Google Drive con una estructura de carpetas predefinida: Clientes/{nombre_cliente}/{año}/{tipo_documento}/{nombre_archivo_con_fecha}.pdf. Eso permite que los socios encuentren cualquier documento en 10 segundos sin depender del portal.

El nodo de Google Drive devuelve el File ID y la URL de descarga, que se almacenan en la base de datos de CI4.

Signaturit para la firma electrónica

Una vez el PDF está en Drive, n8n hace un POST a la API de Signaturit con el PDF, los datos del firmante (nombre, email, móvil para el OTP si se requiere firma con certificado), y los parámetros de la solicitud de firma (cuántas rúbricas, en qué páginas, si requiere certificado cualificado o firma simple).

Signaturit devuelve el ID de la solicitud y el link de firma para el cliente. n8n almacena el ID en CI4 y dispara el email automático al cliente con el link.

Configuramos un webhook de Signaturit que notifica a n8n cuando cambia el estado de la solicitud: enviado, visto, firmado, caducado, rechazado. Cada evento actualiza el estado en CI4 en tiempo real.

RGPD del propio sistema

Este es el punto que más trabajamos en la propuesta inicial, porque un fallo aquí habría sido grave para la reputación del despacho.

Tabla de consentimientos y base jurídica. Cada registro de datos en el sistema tiene asociada la base jurídica que legitima su tratamiento (ejecución de contrato, en este caso), la fecha de alta, y el registro de auditoría de accesos.

Función de derecho de supresión. Implementamos una función en CI4 que, cuando se solicita la supresión de un cliente, verifica el período de retención legal aplicable (en el caso de contratos, mínimo 5 años por obligaciones mercantiles y fiscales), bloquea los datos si están dentro del período de retención (no se pueden suprimir todavía pero se limita el acceso), o ejecuta la supresión efectiva si el período ha expirado.

Alertas de revisión de política de retención. Un job programado revisa mensualmente los registros para alertar a los socios de clientes cuyos períodos de retención han expirado y cuyos datos deberían ser suprimidos.

Minimización. El formulario de generación solo pide los campos necesarios para cada tipo de documento. No hay campos opcionales de "por si acaso". Cada campo tiene su finalidad documentada en el código.

Resultados a los tres meses

Los números son claros:

El tiempo de generación pasó de 45-120 minutos a una media de 3 minutos. Incluye el tiempo del operador completando el formulario, la generación, la subida a Drive, y el envío de la solicitud de firma. El PDF llega al cliente en menos de 2 minutos desde que se pulsa "generar".

Las horas semanales dedicadas al proceso pasaron de 14-18 horas a aproximadamente 2 horas. Esas 2 horas son el tiempo de completar los formularios, revisar los documentos complejos que requieren aprobación de socio, y gestionar las firmas pendientes.

Los errores por datos cruzados entre clientes llegaron a cero. Antes, el proceso de "buscar el documento anterior y cambiar los datos" producía errores con una frecuencia que el propio despacho estimaba entre uno y tres por semana. No eran errores graves en la mayoría de casos —un nombre incorrecto que el abogado atrapaba antes de enviar—, pero el tiempo de revisión y corrección se sumaba al tiempo de generación.

Lo que no automatizamos (y por qué)

Los DPIAs complejos —Análisis de Impacto en la Protección de Datos— que requieren evaluación real de riesgos no están automatizados. El sistema puede generar la estructura del documento y rellenar los datos básicos del responsable, pero la evaluación de riesgos, las medidas de mitigación, y la recomendación final sobre viabilidad del tratamiento son trabajo jurídico que requiere criterio humano.

Automatizar la parte mecánica de esos documentos habría sido posible. Hacerlo habría dado una falsa sensación de que el trabajo estaba hecho cuando en realidad la parte importante —el análisis legal— seguía siendo necesaria. Preferimos ser explícitos: el sistema genera los DPIAs estándar, los DPIAs complejos se marcan con un flag "requiere análisis manual" y entran en la cola de revisión de socio antes de salir.

La automatización útil sabe dónde terminar. Automatizar el 80% del proceso y ser claro sobre el 20% que requiere criterio humano es más valioso que automatizar el 100% de forma que parezca que el criterio humano ya no hace falta.