Arquitectura de Cumplimiento LegalTech (LegalTech Compliance Architecture)
Operador y contacto: Gabriel Salas Troya, persona natural que opera bajo la marca AmparoLex. Correo provisional para soporte, privacidad y consultas sobre el servicio: amparolexcol@gmail.com. Las referencias a AMPAROLEX en este documento identifican la plataforma y a su operador en el rol que corresponda.
Versión: 2026-09-30
Producto: AMPAROLEX
Estado: documento rector interno y contractual complementario
1. Posicion juridica central (Core Legal Position)
AMPAROLEX se estructura sobre una separacion estricta de roles:
- El abogado o firma juridica es el Responsable del Tratamiento (Controller) respecto de los datos personales de sus clientes, procesos y asuntos juridicos.
- AMPAROLEX es el Encargado del Tratamiento (Processor) respecto de los datos procesales tratados por instruccion del abogado o firma.
- Los proveedores cloud y servicios tecnicos son Subencargados (Sub-Processors) cuando tratan datos para prestar infraestructura, seguridad, comunicaciones o soporte.
- El sistema judicial es fuente publica o institucional de informacion, no una fuente para explotacion comercial masiva.
AMPAROLEX no decide que consultar, no explota datos judiciales, no comercializa informacion procesal y no crea una base paralela indiscriminada. AMPAROLEX automatiza, por encargo del abogado, una actividad profesional legitima que el abogado ya puede realizar.
Un mismo proceso judicial puede ser consultado o seguido por varias personas por canales publicos o institucionales. AMPAROLEX no privatiza el proceso ni bloquea que otros abogados lo consulten. Lo que AMPAROLEX controla es la instruccion interna de seguimiento registrada por cada usuario profesional dentro de su cuenta o firma.
2. Naturaleza de la plataforma (Platform Nature)
AMPAROLEX es una plataforma SaaS B2B LegalTech para apoyar el ejercicio profesional juridico mediante:
- seguimiento automatizado de procesos definidos por el usuario profesional;
- organizacion de informacion procesal;
- generacion de alertas y notificaciones;
- gestion de perfiles profesionales, cuentas, pagos y seguridad;
- soporte tecnologico para abogados, firmas y organizaciones juridicas.
La plataforma no es un agregador masivo de datos, no reemplaza a la Rama Judicial, no presta asesoria juridica automatica al cliente final y no sustituye el criterio profesional del abogado.
La capa publica y operativa de AMPAROLEX debe operar mediante dominios controlados, certificados HTTPS/TLS vigentes y canales cifrados para proteger los datos en transito.
3. Doble capa de datos (Two-Layer Data Model)
3.1 Datos operativos propios de AMPAROLEX
AMPAROLEX puede actuar como Responsable del Tratamiento respecto de datos necesarios para operar la plataforma:
- cuenta de usuario, correo, autenticacion y recuperacion;
- identidad profesional basica, documento, tarjeta profesional y verificacion;
- perfil publico o privado, foto, avatar, datos de contacto visibles segun configuracion;
- roles, permisos, sesiones, dispositivos, logs y seguridad;
- suscripcion, pagos, cupos, facturacion y soporte;
- notificaciones, preferencias y evidencias de aceptacion contractual;
- auditoria tecnica y prevencion de abuso.
Estos datos tienen finalidad operativa: crear cuenta, prestar el servicio, proteger la plataforma, gestionar pagos, cumplir obligaciones contractuales y demostrar cumplimiento.
3.2 Datos procesales tratados por encargo
El abogado o firma decide que instrucciones de seguimiento registrar, activar, pausar o eliminar dentro de su cuenta. En esa capa:
- el abogado/firma es Responsable del Tratamiento;
- AMPAROLEX es Encargado del Tratamiento;
- la finalidad es el seguimiento profesional del asunto juridico o una revision puntual legitimada por el ejercicio profesional;
- la retencion depende del encargo, de la instruccion de seguimiento, de la configuracion del usuario y de obligaciones aplicables;
- AMPAROLEX ejecuta instrucciones tecnicas y no reutiliza los datos para fines propios incompatibles.
4. Arquitectura cloud e integraciones (Cloud and Integration Architecture)
AMPAROLEX debe distinguir tres escenarios:
4.1 Infraestructura cloud propia de AMPAROLEX
Servicios contratados por AMPAROLEX para operar la plataforma, como hosting, base de datos, almacenamiento, correo transaccional, monitoreo, seguridad o backups.
Rol: estos proveedores actuan como Subencargados de AMPAROLEX cuando tratan datos personales para prestar el servicio.
4.2 Nubes o repositorios conectados por el usuario
Servicios seleccionados, contratados o administrados por el abogado o firma, como Google Drive, OneDrive, Dropbox, S3 propio, NAS, servidor local, correo o calendario corporativo.
Rol: el proveedor conectado no es automaticamente Subencargado de AMPAROLEX. Puede ser proveedor o encargado del propio Responsable, segun el contrato entre el usuario y ese proveedor. AMPAROLEX actua como herramienta tecnica que sincroniza o accede con permisos limitados bajo instruccion del usuario.
4.3 Agentes locales o infraestructura distribuida
Componentes instalados en el despacho, equipo, mini servidor o Raspberry del usuario para ejecutar sincronizacion local o almacenamiento local.
Rol: puede reforzar minimizacion y control del Responsable si reduce datos centralizados y transmite solo metadatos necesarios a AMPAROLEX.
Regla comun: toda integracion debe tener finalidad, permisos minimos, revocacion, auditoria y documentacion de rol.
5. Marco Colombia (Colombian Data Protection Layer)
La estructura se alinea con la Ley 1581 de 2012 y sus principios de legalidad, finalidad, libertad, veracidad o calidad, transparencia, acceso y circulacion restringida, seguridad y confidencialidad.
Puntos de diseno:
- Responsable: quien decide sobre la base de datos o tratamiento.
- Encargado: quien trata datos por cuenta del Responsable.
- Titular: persona natural cuyos datos son tratados.
- Derechos: conocer, actualizar, rectificar, ser informado, solicitar prueba, revocar autorizacion o pedir supresion cuando proceda, y acceder gratuitamente a los datos.
- Procedimientos: consultas y reclamos deben poder documentarse, atenderse y, cuando aplique, remitirse al Responsable competente.
- Datos sensibles: deben evitarse salvo necesidad juridica estricta, habilitacion legal y medidas reforzadas.
Para datos judiciales publicos o semipublicos, AMPAROLEX no asume que "publico" equivale a tratamiento ilimitado. Se exige finalidad profesional, minimizacion, seguridad y retencion limitada.
6. Marco Europa / GDPR (European Data Protection Layer)
La estructura se alinea con GDPR como estandar de referencia:
- Controller / Processor / Sub-Processor.
- Data protection by design and by default.
- Lawfulness, fairness and transparency.
- Purpose limitation.
- Data minimisation.
- Accuracy.
- Storage limitation.
- Integrity and confidentiality.
- Accountability.
Cuando haya usuarios, titulares, operaciones o proveedores con impacto europeo, se deberan revisar bases legales, transferencias internacionales, medidas tecnicas y organizativas, registros de tratamiento, asistencia en derechos y evaluaciones de impacto cuando el riesgo lo exija.
7. Documentos regulatorios (Regulatory Documents)
La arquitectura documental de AMPAROLEX se compone de:
- Constitucion de Plataforma (Platform Constitution): regla rectora de comportamiento de usuarios, sistema, automatizacion e IA.
- Politica de Privacidad (Privacy Policy): explica roles, datos, finalidades, derechos, retencion y seguridad.
- Terminos y Condiciones (Terms of Service): regula uso SaaS, licencia, elegibilidad, responsabilidades y propiedad intelectual.
- Acuerdo de Tratamiento de Datos (DPA): contrato anexo entre Responsable y Encargado para datos procesales tratados por encargo.
- Politica de Uso Aceptable (AUP): prohibe abuso, consultas masivas indiscriminadas, reventa de datos y usos incompatibles.
Documentos complementarios:
- Compliance Architecture.
- Data Governance Model.
- Security Controls.
- Institutional Position Paper.
- Copia historica del documento vigente de registro.
La entrega de esta arquitectura documental a autoridades, clientes, aliados o terceros no implica cesion de derechos de autor ni autorizacion para explotar, copiar, adaptar o publicar el modelo documental de AMPAROLEX fuera del proposito concreto de evaluacion, cumplimiento, interoperabilidad o colaboracion institucional.
8. Flujo de registro objetivo (Target Registration Flow)
El flujo futuro deberia exigir aceptacion expresa y versionada de:
- Politica de Privacidad.
- Terminos y Condiciones.
- DPA.
- AUP.
Cada aceptacion deberia registrar:
- usuario;
- documento aceptado;
- version;
- fecha y hora;
- evidencia tecnica razonable;
- direccion IP o metadato equivalente cuando sea proporcional;
- metodo de aceptacion.
El flujo actual no debe romperse hasta que exista una migracion controlada.
9. Evaluacion obligatoria de nuevas funcionalidades
Toda nueva funcionalidad debe responder:
- finalidad del tratamiento;
- si trata datos operativos propios o datos procesales por encargo;
- rol de AMPAROLEX en esa capa;
- datos estrictamente necesarios;
- base juridica o instruccion del Responsable;
- retencion;
- seguridad;
- auditoria;
- derechos del usuario o titular;
- riesgos regulatorios;
- cambios documentales;
- cambios tecnicos.
Decision posible: aprobar, aprobar con controles, redisenar o rechazar.
10. Posicion frente a arquitectura distribuida
AMPAROLEX puede evolucionar hacia agentes locales, mini servidores o dispositivos tipo Raspberry bajo control del abogado o firma. Esa arquitectura puede reforzar privacidad si:
- reduce centralizacion innecesaria;
- envia a la nube solo datos minimos operativos;
- mantiene trazabilidad de instrucciones;
- conserva seguridad, autenticacion y actualizaciones;
- evita eludir restricciones de fuentes publicas;
- se documenta en DPA, AUP y terminos de servicio.
La arquitectura distribuida no elimina obligaciones de proteccion de datos; las redistribuye y debe documentarlas con precision.