Stack Tecnológico de Agencia de IA para Clientes Legales: n8n + Modelos Ajustados + Despliegue On-Prem

Construir soluciones de IA para firmas de abogados requiere un stack tecnológico específico que satisfaga los requisitos de cumplimiento legal mientras permanezca manejable para un equipo pequeño de agencia. Este artículo documenta la arquitectura completa — cada componente, por qué fue elegido y cómo se conectan las piezas.

La Arquitectura Completa

┌─────────────────────────────────────────────────────────┐
│                    RED DEL CLIENTE                        │
│                                                          │
│  ┌──────────┐    ┌──────────┐    ┌───────────────────┐  │
│  │   DMS    │───→│   n8n    │───→│  Inferencia LLM   │  │
│  │(iManage) │    │(self-    │    │  (Ollama/vLLM)    │  │
│  └──────────┘    │ hosted)  │    │  + Adaptadores LoRA│  │
│                  └────┬─────┘    └───────────────────┘  │
│                       │                                  │
│                  ┌────▼─────┐    ┌───────────────────┐  │
│                  │ Vector   │    │  Portal del        │  │
│                  │   DB     │    │  Cliente           │  │
│                  │(Chroma/  │    │  (UI resultados)   │  │
│                  │ Qdrant)  │    └───────────────────┘  │
│                  └──────────┘                            │
└─────────────────────────────────────────────────────────┘

Cada componente corre dentro de la red de la firma de abogados. Ningún dato sale del perímetro.

Selección de Componentes

n8n: Orquestación de Flujos de Trabajo

Por qué n8n:

• Autoalojable (Docker, bare metal) — sin dependencia SaaS
• Constructor visual de flujos de trabajo que personal no técnico puede entender durante demos
• Nodo compatible con OpenAI se conecta directamente a endpoints de LLM locales
• Disparadores webhook para procesamiento de documentos en tiempo real
• Manejo de errores integrado, lógica de reintento y registro de ejecución
• Comunidad open-source activa con plantillas de flujos de trabajo relevantes para el sector legal

Por qué no Make.com o Zapier:

• Ambos son SaaS solo en la nube — los datos deben salir de la red de la firma
• No se pueden autoalojar para despliegues aislados
• La dependencia de proveedor crea riesgo para proyectos a largo plazo

Despliegue de n8n: Contenedor Docker con backend PostgreSQL. Liviano en recursos — 2 cores de CPU y 4 GB de RAM manejan la mayoría de las cargas de trabajo de agencia.

Inferencia LLM: Ollama o vLLM

Ollama para despliegues más simples:

• Instalación de un solo binario, configuración mínima
• Gestión de modelos integrada (descargar, versionar, cambiar modelos)
• Endpoint de API compatible con OpenAI listo para usar
• Menor throughput pero operaciones más simples

vLLM para despliegues de producción:

• Mayor throughput con batching continuo
• Mejor utilización de GPU bajo carga concurrente
• API compatible con OpenAI
• Mayor complejidad operativa (entorno Python, carga de modelos)

Marco de decisión: Comienza con Ollama para despliegues piloto y configuraciones de un solo cliente. Muévete a vLLM cuando necesites servir a múltiples usuarios concurrentes o múltiples adaptadores de cliente en la misma GPU.

Modelos Ajustados + Adaptadores LoRA

La arquitectura de modelo base + adaptador es la base de las operaciones de agencia multi-cliente:

• Un modelo base (Llama 3.1 8B) cargado en memoria de GPU
• Adaptadores LoRA por cliente (50-200 MB cada uno) que personalizan el modelo base para las tareas y estilo específicos de cada firma
• Carga dinámica de adaptadores — intercambia adaptadores en tiempo de inferencia según qué solicitud de cliente se está procesando

Esta arquitectura significa que una sola GPU sirve a todos tus clientes legales. Cada cliente obtiene un modelo que se comporta como si fuera entrenado exclusivamente con sus datos, pero el costo de infraestructura se comparte. Consulta nuestra guía multi-cliente LoRA para los detalles técnicos.

El fine-tuning ocurre a través de Ertas Studio — sube datos del cliente, configura el entrenamiento, exporta el adaptador. No se requiere experiencia en ML.

Base de Datos Vectorial: Chroma o Qdrant

Para IA legal, el fine-tuning puro a menudo se complementa con Retrieval-Augmented Generation (RAG) para tareas que requieren referenciar documentos específicos:

Chroma para despliegues ligeros:

• Modo embebido que corre en proceso (sin servidor separado)
• API simple de Python
• Bueno para colecciones de menos de 1M de documentos

Qdrant para despliegues de producción:

• Servidor dedicado con APIs REST y gRPC
• Mejor rendimiento a escala (millones de documentos)
• Filtrado integrado (útil para aislamiento de datos multi-cliente)
• Despliegue con Docker

Cuándo usar RAG junto con fine-tuning:

• Revisión de contratos contra una biblioteca de cláusulas -> RAG recupera cláusulas similares, el modelo ajustado analiza
• Investigación legal -> RAG recupera jurisprudencia relevante, el modelo ajustado resume y sintetiza
• Due diligence -> RAG busca en la sala de datos, el modelo ajustado extrae y clasifica

Portal del Cliente

Las firmas de abogados esperan una interfaz pulida, no outputs crudos de API. Opciones:

App web personalizada: Una aplicación simple de React o Next.js que:

• Acepta cargas de documentos
• Muestra estado de procesamiento
• Presenta resultados de análisis en un informe formateado
• Proporciona función de exportación (PDF, DOCX)
• Se autentica contra el proveedor de identidad de la firma (SAML/OIDC)

n8n + interfaz de formulario: Para despliegues más simples, el webhook + disparador de formulario de n8n puede servir como una interfaz básica de ingesta. Menos pulido pero más rápido de desplegar.

Integración con herramientas existentes: Muchas firmas prefieren resultados entregados en su sistema de gestión documental existente (iManage, NetDocuments) o plataforma de gestión de asuntos en lugar de un portal separado.

Topología de Despliegue

Despliegue de Un Solo Cliente

Para una firma pequeña (10-50 abogados):

Costo total de hardware adicional para el cliente: $2,500-4,000 (solo estación de trabajo GPU si no tienen una ya).

Despliegue Multi-Cliente de Agencia

Para una agencia gestionando 5-15 clientes de firmas de abogados:

Opción A: Centralizado (Alojado por la Agencia)

• La agencia opera una sala de servidores o rack de colocación
• Los datos de cada cliente están lógicamente aislados (bases de datos separadas, adaptadores LoRA separados)
• Requiere controles de acceso robustos y registro de auditoría
• Menor costo de hardware por cliente
• Nota: Algunas firmas no aceptarán este modelo — sus datos deben estar en su propio hardware

Opción B: Distribuido (Alojado por el Cliente)

• Cada cliente tiene su propio stack de hardware
• La agencia gestiona remotamente vía VPN o acceso remoto seguro
• Mayor costo de hardware (duplicado entre clientes) pero máximo aislamiento de datos
• Preferido por la mayoría de las firmas de abogados debido a requisitos de soberanía de datos

Opción C: Híbrido

• Inferencia alojada por el cliente (GPU + modelo en hardware del cliente)
• n8n alojado por la agencia (solo orquestación, sin datos de cliente persistidos)
• Fine-tuning ocurre en infraestructura de la agencia, archivos de adaptador entregados al cliente

La mayoría de las agencias comienzan con la Opción B y migran clientes dispuestos a centralizar a la Opción A a medida que se construye confianza.

Flujo de Datos: Un Ejemplo Completo

Aquí está el flujo de datos paso a paso para un flujo de trabajo de revisión de contratos:

1. El abogado sube el contrato al portal del cliente (o lo coloca en una carpeta DMS monitoreada)
2. El webhook de n8n se dispara, activando el flujo de trabajo de revisión de contratos
3. n8n extrae el texto del documento (nodo de parsing de PDF)
4. n8n divide el documento en secciones (nodo Function)
5. Para cada sección, n8n consulta la base de datos vectorial buscando cláusulas similares de la biblioteca de precedentes de la firma
6. n8n envía cada sección + contexto recuperado al LLM local con el adaptador LoRA específico de la firma cargado
7. El LLM devuelve el análisis de riesgo para cada sección
8. n8n agrega los resultados en un informe de revisión estructurado
9. El informe se entrega al portal del cliente, se envía por email o se escribe de vuelta al DMS
10. Todos los datos de ejecución se registran en el historial de ejecución de n8n y el log de auditoría

Tiempo total de procesamiento para un contrato de 30 páginas: 2-5 minutos.

Consideraciones de Escalabilidad

Agregar Más Clientes

Cada nuevo cliente requiere:

• Un nuevo adaptador LoRA (entrenado vía Ertas Studio)
• Una nueva colección en la base de datos vectorial (si usa RAG)
• Nuevos flujos de trabajo en n8n (clonados de plantillas, personalizados por cliente)
• Configuración específica del cliente en el portal

El modelo base y la infraestructura de inferencia se comparten. Costo marginal por nuevo cliente: tiempo de fine-tuning + almacenamiento de adaptador (trivial).

Manejar Mayor Volumen

Cuando una sola GPU se satura:

• Agrega una segunda GPU al mismo servidor (la mayoría de las estaciones de trabajo soportan 2 GPUs)
• Usa el paralelismo de tensor de vLLM para dividir modelos entre GPUs
• O despliega un segundo servidor de inferencia y balancea carga con Nginx

Agregar Nuevas Capacidades

Nuevos casos de uso (ej., agregar investigación legal a una firma que comenzó con revisión de contratos) requieren:

• Un nuevo adaptador ajustado para la nueva tarea
• Nuevos flujos de trabajo en n8n
• Nueva colección en la base de datos vectorial (si la tarea usa RAG)

La infraestructura escala horizontalmente — mismo stack, nuevos adaptadores.

---

Lectura Adicional

• n8n + LLMs Locales: Construyendo Automatización Compatible con HIPAA — Inmersión profunda en la integración de n8n + LLM local
• Despliegue de IA Multi-Tenant para Agencias — Gestionando múltiples clientes en infraestructura compartida