PONS: 3 decisiones de arquitectura para IA legal en Azure

Por qué la arquitectura pesa más que el modelo en IA legal

La conversación sobre IA legal suele girar en torno a qué modelo responde mejor o qué abogado será reemplazado primero. PONS, una plataforma europea de IA para despachos y equipos legales internos, demuestra que el cuello de botella real está en otra parte: en cómo se conectan fuentes regulatorias actualizadas con documentos confidenciales de clientes sin que ninguno contamine al otro.

La startup corre toda su pila en Microsoft Azure, con residencia de datos en Azure Sweden Central, y separa su trabajo en dos componentes: una Data Factory que ingesta y curatela corpus legal público (legislación, jurisprudencia, precedentes), y un AI Engine que razona contra ese corpus y contra archivos de clientes mantenidos en aislamiento. Para Tobias Zimmergren, CTO y cofundador técnico de PONS, la promesa central al cliente es directa: sus documentos nunca entran al corpus público ni se usan para entrenar modelos de terceros.

Esa promesa no es marketing: es una decisión arquitectónica que recorre todo el sistema.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Decisión 1: separar el corpus confiable del contexto privado

La mayoría de las plataformas de IA legal que vemos nacer mezclan, en el mismo pipeline de indexación, las fuentes regulatorias con los documentos cargados por cada cliente. El problema aparece tres meses después, cuando un cliente corporativo pregunta dónde quedó un contrato confidencial y la respuesta honesta es «está mezclado con la base de conocimiento general».

PONS evita ese escenario con un flujo unidireccional: la Data Factory ingiere, valida y enriquece continuamente legislación y jurisprudencia pública; los documentos del cliente se almacenan en contenedores separados dentro del mismo tenant Azure y son procesados únicamente por el AI Engine, sin retroalimentar la base de conocimiento común.

En la práctica, esto significa tres cosas que cualquier founder puede replicar:

Residencia y aislamiento por región. Todo vive en Azure Sweden Central, con cifrado AES-256 antes de llegar a la base de datos, en reposo y en tránsito, por defecto.
Contenedores de almacenamiento y bases de datos separados por cliente, con acceso asignado a usuarios individuales, no a la organización.
Trazabilidad inversa. Cada respuesta cita la fuente; cada cita apunta a un documento trazable, lo que permite auditoría real cuando un compliance officer pregunta de dónde salió un número.

Para tu startup, la lección clave es cronológica: si vas a mezclar conocimiento público actualizado con datos sensibles de clientes, diseña el límite el día uno. Rehacer la separación después significa migrar embeddings, reescribir permisos y renegociar con cada cliente enterprise el contrato de procesamiento de datos.

Decisión 2: comprar infraestructura indiferenciada para enfocarse en diferenciación

La segunda decisión de PONS es la más contraintuitiva para un equipo chico que quiere control total de su stack. En lugar de montar Kubernetes, colas custom y pipelines de despliegue propios, la startup adoptó servicios gestionados de Azure de extremo a extremo:

Azure App Service para la aplicación (sin operar servidores).
Azure SQL Database y Azure Storage para datos estructurados y archivos.
Azure Key Vault para secretos y certificados fuera del código.
Azure App Configuration para configuración compartida no sensible.
Azure Queue Storage para desacoplar la API del motor de IA, lo que permite escalar el razonamiento sin escalar la ruta de solicitud.
Azure Web PubSub para devolver resultados y notificaciones a la UI en tiempo real.
Azure OpenAI como modelo base y Microsoft Foundry como hosting de modelos ajustados.

El resultado operativo es que un equipo reducido puede concentrarse en lo que realmente factura: calidad del corpus legal, razonamiento citado, evaluación de salidas y experiencia del cliente. La localización en UE pasa de ser un proyecto de ingeniería a una decisión de configuración.

Para tu startup, el criterio para elegir servicio gestionado no es «cuánto cuesta», sino qué trabajo recurrente te quita y qué controles te garantiza. Si tu diferenciación está en datos de dominio o comportamiento de producto —no en operaciones de infraestructura— ceder control de bajo nivel a cambio de escala, identidad, logs y cumplimiento regional suele ser el trade correcto.

Decisión 3: convertir el cumplimiento en controles exigibles, no en documentos

Cuando un general counsel o un equipo de procurement evalúa una plataforma de IA legal, las preguntas no son técnicas en abstracto. Son operativas:

¿Dónde residen los datos?
¿Quién puede acceder?
¿Se puede auditar el sistema?
¿Los documentos del cliente terminan entrenando el modelo de alguien?
¿Esto se sostiene en cada jurisdicción donde operamos?

PONS traduce cada pregunta en un control embebido en el sistema, no en un PDF de compliance:

Localización y acceso vía aislamiento regional y permisos con alcance.
Trazabilidad con registros de procedencia ligados a citas y logs de auditoría.
Reejecución automática de salidas que fallan las puertas de evaluación, con rechazo por diseño cuando el sistema no puede conectar una respuesta a una fuente.
Exclusión explícita de documentos de cliente del pipeline de Data Factory y del entrenamiento de modelos.
Certificaciones de entrada empresarial: SOC 2 Tipo II, ISO 27001 y cumplimiento de GDPR, más pruebas de penetración periódicas.

Para tu startup, el punto es que estas preguntas hay que planteárselas antes de escribir la primera línea de producto, mientras los límites sobre datos, acceso y comportamiento del modelo todavía pueden diseñarse dentro del sistema. Documentarlas después, cuando un cliente enterprise ya hizo la due diligence y pidió cambios, es mucho más caro y casi siempre más invasivo.

¿Qué significa esto para tu startup?

Más allá de PONS, los patrones que aplica esta arquitectura son transferibles a cualquier startup que venda IA a clientes regulados (salud, finanzas, seguros, sector público). Tres acciones concretas que podés implementar este mes:

Audita tu pipeline de datos y marcá en un diagrama dónde se cruzan fuentes públicas con datos privados de clientes. Si el diagrama tiene una sola caja donde ambos flujos entran al mismo índice, tenés un riesgo arquitectónico que un enterprise buyer va a encontrar tarde o temprano.
Mapea cada pregunta típica de procurement a un control técnico embebido. No como política, como código o como configuración verificada. «¿Dónde residen los datos?» tiene que poder responderse con un screenshot del recurso Azure, no con un párrafo en una política.
Calculá cuánto trabajo de infraestructura estás haciendo que un servicio gestionado te quitaría. Si tu diferenciación no está ahí, cada hora en tareas indiferenciadas es una hora menos en el delta que le vendés al cliente.