Acuerdo de Tratamiento de Datos Personales — LexFlow

Versión: 0.2 Fecha de emisión: 19 de mayo de 2026 Marco legal aplicable: Ley Orgánica de Protección de Datos Personales (LOPDP) del Ecuador, RO 459 del 21 de mayo de 2021, y su Reglamento (Decreto Ejecutivo 904, RO Sup. 459, 13-nov-2023).

Aviso: Este documento es un borrador técnico. Sigue pendiente de revisión por abogado colegiado en Ecuador. NO usar como base contractual definitiva sin revisión profesional previa.

1. Objeto y partes

Este Acuerdo regula el tratamiento de datos personales de terceros (clientes finales del estudio jurídico, partes procesales, testigos, etc.) que el Estudio sube al sistema LexFlow para su gestión.

1.1. El Responsable del Tratamiento

Es el Estudio jurídico Cliente, quien:

• Determina los fines y medios del tratamiento de los datos de sus propios clientes.
• Cuenta con base de licitud para tratarlos (mandato profesional, contrato de servicios legales, obligación legal, etc.).
• Es el punto de contacto frente a los titulares de los datos y la Superintendencia de Protección de Datos Personales (SPDP).

1.2. El Encargado del Tratamiento

Es LexFlow, operado por:

• Nombre: Gabriel Josías Santos Rivera
• Cédula: 1724060478
• Domicilio: Vía Colonia Montúfar Km. 4, Quito - Pichincha, Ecuador
• Correo de contacto en materia de protección de datos: dpo@tiertec.lat
• Correo de contacto comercial y operativo: soporte@tiertec.lat

LexFlow trata los datos del Responsable únicamente por cuenta y bajo instrucciones del Estudio, conforme a este Acuerdo.

2. Naturaleza, finalidad y duración del tratamiento

2.1. Categorías de titulares afectados

• Clientes finales del estudio (personas naturales y empresas).
• Partes procesales mencionadas en los expedientes (contrapartes, testigos, peritos, terceros).
• Profesionales externos que el estudio referencia (abogados de la contraparte, peritos, notarios, etc.).

2.2. Categorías de datos personales tratados

• Datos de identificación: nombre, cédula/RUC/pasaporte, dirección, email, teléfono.
• Datos profesionales: ocupación, razón social, matrícula profesional.
• Datos jurídicos sensibles: materia procesal, juzgado, número de proceso, contenido de actuaciones, notas internas del abogado.
• Categorías especiales que puedan aparecer en los expedientes por la naturaleza del asunto (datos de salud en casos médicos, datos económicos en casos comerciales, antecedentes penales en casos penales, etc.) según el art. 25 LOPDP.

2.3. Naturaleza del tratamiento

LexFlow realiza únicamente las siguientes operaciones sobre los datos:

• Almacenamiento estructurado en PostgreSQL.
• Almacenamiento de archivos asociados en bucket de Storage cifrado.
• Recuperación a solicitud del Estudio.
• Envío de notificaciones automáticas de vencimientos al equipo del estudio (NO a los titulares de los datos).
• Generación de logs de auditoría sobre operaciones internas del Estudio.
• Backup automatizado para fines de continuidad operativa.

LexFlow NO realiza sobre los datos del Responsable:

• Análisis con fines comerciales propios.
• Cesión a terceros (salvo los encargados subordinados listados en la cláusula 4).
• Uso para entrenamiento de modelos de IA.
• Perfilado.
• Decisiones automatizadas con efectos jurídicos.

2.4. Finalidad

Prestar el servicio LexFlow al Estudio para que este, a su vez, administre su práctica jurídica.

2.5. Duración

El tratamiento dura mientras esté vigente el contrato de servicio (Términos de Uso, documento 01). Tras la terminación se aplican los plazos de retención y eliminación de la cláusula 7 de este Acuerdo.

3. Obligaciones del Encargado (LexFlow)

LexFlow se obliga frente al Estudio a:

3.1. Tratar los datos únicamente conforme a las instrucciones documentadas del Estudio, salvo obligación legal en contrario.

3.2. Mantener los datos en estricta confidencialidad. El personal autorizado de LexFlow (en la práctica actual, exclusivamente Gabriel Santos como operador único) está sujeto a deber de confidencialidad equivalente.

3.3. Implementar y mantener las medidas de seguridad técnicas y organizativas descritas en el Anexo A de este Acuerdo.

3.4. Asistir al Estudio en el cumplimiento de sus obligaciones frente a los titulares, en particular: a. Atender solicitudes de ejercicio de derechos (acceso, rectificación, supresión, oposición, portabilidad, limitación). b. Notificar incidentes de seguridad. c. Realizar evaluaciones de impacto cuando corresponda. d. Cooperar con consultas o requerimientos de la SPDP.

3.5. Notificar incidentes de seguridad al Estudio en plazo no mayor a 24 a 48 horas desde que LexFlow tome conocimiento, conforme a la cláusula 9 de este Acuerdo.

3.6. Auditoría: poner a disposición del Estudio, una vez por año o ante requerimiento justificado, la documentación necesaria para demostrar el cumplimiento de este Acuerdo (resumen del Anexo A vigente, evidencias de medidas implementadas, registro de incidentes).

3.7. Devolución o supresión de los datos al terminar el contrato, según elija el Estudio (cláusula 7).

3.8. No subcontratar a otros encargados (sub-encargados) salvo los listados en la cláusula 4 o con autorización previa del Estudio.

3.9. Informar inmediatamente al Estudio si recibe una instrucción que considere contraria a la LOPDP u otra normativa de protección de datos aplicable.

3.10. Continuidad y sucesión operativa. Dado que LexFlow opera actualmente bajo el control de un único operador (Gabriel Josías Santos Rivera, persona natural), el Encargado se obliga a:

a. Designar por escrito a una persona de respaldo con acceso a las credenciales de infraestructura críticas (Supabase, Vercel, Hetzner), facultada para mantener la operación del servicio por al menos noventa (90) días en caso de fallecimiento o incapacidad sobrevenida del operador. b. Mantener actualizada dicha designación con periodicidad anual, y notificar al Estudio cualquier cambio en la persona designada. c. En caso de fallecimiento o incapacidad del operador sin persona de respaldo designada, los herederos o representantes legales del Encargado deberán notificar al Estudio en el plazo máximo de quince (15) días, y el Estudio tendrá derecho a solicitar la exportación completa de sus datos de forma inmediata y gratuita. d. El Encargado mantendrá documentación técnica actualizada suficiente para que un tercero competente pueda continuar la operación del servicio o facilitar la migración de datos del Estudio en caso de incapacidad del operador principal.

4. Sub-encargados de tratamiento autorizados

LexFlow se apoya en los siguientes proveedores externos como sub-encargados. El Estudio autoriza expresamente el uso de los sub-encargados listados a continuación al suscribir este Acuerdo:

LexFlow notificará al Estudio cualquier alta de nuevo sub-encargado con al menos 30 días de anticipación, ofreciendo el derecho de objeción razonable. Si el Estudio ejerce objeción justificada ante el alta de un nuevo sub-encargado, LexFlow evaluará alternativas técnicas. Si no fuera posible prestar el servicio sin el nuevo sub-encargado, cualquiera de las partes podrá terminar el contrato sin penalidad, con derecho del Estudio a exportar sus datos.

5. Transferencias internacionales

Los datos del Responsable se almacenan en infraestructura ubicada fuera del Ecuador, principalmente en Estados Unidos y Alemania.

Marco legal de las transferencias internacionales.

Ecuador no ha emitido al momento de suscripción de este Acuerdo una lista de países con nivel adecuado de protección de datos conforme a la LOPDP. Las transferencias internacionales realizadas por LexFlow se sustentan en las siguientes bases acumulativas:

a. Necesidad para la ejecución del contrato entre el Estudio y LexFlow (LOPDP art. 56.2.b). b. Consentimiento informado del Estudio, manifestado al suscribir este Acuerdo (LOPDP art. 56.2.a). c. Garantías adicionales: certificaciones SOC 2 Tipo II o ISO 27001 vigentes de los sub-encargados donde están disponibles; cifrado en tránsito (TLS 1.3) y en reposo (AES-256); suscripción de DPAs estándar de cada proveedor donde estos los ofrecen.

Histórico (informativo): Hasta el 2026-05-15, el componente conversacional del asistente IA utilizaba DeepSeek (China). La transferencia fue migrada a Anthropic PBC (Estados Unidos) con DPA en proceso de firma. Desde la migración, no existen transferencias de datos a China desde la plataforma. La cláusula 4 lista los sub-encargados vigentes.

El Estudio reconoce y acepta expresamente esta transferencia al suscribir este Acuerdo.

6. Derechos de los titulares

6.1. Recepción de solicitudes

Si un titular ejerce un derecho ARCO+ directamente ante LexFlow, LexFlow:

1. Acusará recibo de la solicitud.
2. Reenviará la solicitud al Estudio responsable en plazo no mayor a 2 días hábiles.
3. Esperará instrucciones del Estudio para responder.

El Estudio es el único legitimado para resolver la solicitud, ya que solo este conoce la base de licitud bajo la cual trata cada dato.

6.2. Asistencia técnica de LexFlow

Para asistir al Estudio en la resolución de solicitudes, LexFlow ofrece:

• Exportación completa de los datos del Estudio (legal/export_tenant_data.sql), en formato CSV, entregada en máximo 15 días hábiles.
• Búsqueda dirigida por titular (consulta SQL personalizada) si el Estudio la solicita.
• Eliminación dirigida de filas específicas si el Estudio confirma por escrito que procede la supresión.

7. Retorno o supresión de datos al terminar el contrato

Al terminar el contrato de servicio:

7.1. Plazo de gracia: durante los 30 días posteriores a la terminación, el Estudio puede solicitar exportación completa de sus datos.

7.2. Período de retención: transcurridos esos 30 días, LexFlow conserva los datos por 60 días adicionales en sistemas activos para permitir reactivación o exportación tardía. Esto suma 90 días totales de retención post-terminación (alineado con cláusula 12.2 de los Términos de Uso).

7.3. Eliminación definitiva: transcurridos los 90 días, LexFlow ejecuta la eliminación irreversible en sistemas activos usando el script legal/delete_tenant_data.sql, dejando constancia mediante manifiesto firmado.

7.4. Backups: los datos pueden permanecer en backups por hasta 60 días adicionales antes de su rotación natural.

7.5. Excepción: datos sometidos a obligaciones legales de retención (facturas SRI por 7 años conforme al art. 41 del Reglamento de Comprobantes de Venta) se conservan únicamente por el tiempo y para el fin legalmente exigido, segregados de la operación activa.

7.6. Storage: los archivos físicos del bucket de Supabase Storage asociados al tenant se eliminan en el mismo procedimiento que las filas de base de datos.

8. Confidencialidad

8.1. LexFlow y todo su personal autorizado guardan confidencialidad sobre los datos del Responsable durante la vigencia del contrato y los 5 años posteriores a su terminación.

8.2. Esta obligación subsiste indefinidamente respecto de los datos sometidos a secreto profesional del abogado (art. 335.b Código Orgánico de la Función Judicial).

9. Notificación de incidentes de seguridad

9.1. Definición de incidente

Para los fines de este Acuerdo se entiende por incidente cualquier evento que comprometa la confidencialidad, integridad o disponibilidad de los datos del Responsable, incluyendo pero no limitado a:

• Acceso no autorizado a la base de datos o storage.
• Filtración de credenciales.
• Compromiso de cuentas de usuarios.
• Ataques exitosos contra la infraestructura.
• Pérdida o destrucción no programada de datos.
• Falla de los proveedores subordinados que exponga datos.

9.2. Plazo de notificación

LexFlow notificará al Estudio en plazo no mayor a 24 a 48 horas desde que tome conocimiento del incidente. La primera notificación podrá ser preliminar si al momento de tomar conocimiento LexFlow aún no dispone de información completa sobre el alcance del incidente; en ese caso, LexFlow enviará actualizaciones sucesivas conforme avance la investigación.

9.3. Contenido de la notificación

La notificación contendrá, en lo que sea conocido al momento:

• Descripción del incidente.
• Categorías y cantidad aproximada de titulares y datos afectados.
• Consecuencias probables.
• Medidas adoptadas y por adoptar.
• Punto de contacto para más información.

9.4. Notificación a la SPDP

Cuando el incidente lo amerite conforme al art. 43 LOPDP, el Estudio (como responsable) notificará a la Superintendencia de Protección de Datos Personales dentro de los plazos legales. LexFlow pondrá a disposición del Estudio toda la información técnica necesaria para que el Estudio pueda preparar y enviar dicha notificación, incluyendo la descripción técnica del incidente, el alcance estimado y las medidas correctivas adoptadas.

9.5. Notificación a los titulares

Cuando el incidente represente alto riesgo para los titulares, el Estudio les notificará individualmente. El plazo para dicha notificación individual a los titulares será de 24 a 48 horas desde que se confirme el alcance del incidente. LexFlow asistirá técnicamente en esta comunicación.

10. Responsabilidad

10.1. La responsabilidad de LexFlow frente al Estudio por hechos imputables a LexFlow se rige por la cláusula 10 de los Términos de Uso (documento 01), incluyendo el límite cuantitativo de 6 meses de pagos efectuados.

10.2. Esta limitación NO aplica en casos de dolo o culpa grave demostrados por el Estudio.

10.3. Cuando el incidente sea imputable al Estudio (compartir credenciales, no aplicar las medidas mínimas exigidas en la cláusula 11, cargar datos sin base de licitud), la responsabilidad recae íntegramente sobre el Estudio.

10.4. Para incidentes de seguridad imputables a terceros externos o fallas de sub-encargados, aplica la cláusula 10.5 de los Términos de Uso (notificación 24-48h + diligencia debida + límite cuantitativo).

10.5. El Prestador no responde por hechos exclusivos de sub-encargados respecto de los cuales haya celebrado DPAs equivalentes al estándar de este Acuerdo y verificado que cuentan con certificaciones SOC 2 Tipo II o equivalentes vigentes al momento del incidente.

11. Obligaciones del Responsable (Estudio)

El Estudio se obliga a:

11.1. Tener base de licitud para todo dato que sube al sistema, conforme al art. 7 LOPDP.

11.2. Informar a sus clientes finales sobre el uso de LexFlow como herramienta de gestión, dentro de su propia Política de Privacidad.

11.3. Limitar el acceso interno a los datos al personal que efectivamente los requiera para su función (principio de mínimo privilegio).

11.4. Mantener actualizada la lista de usuarios autorizados y desactivar oportunamente las cuentas de personal que deje el estudio.

11.5. Usar contraseñas robustas y no compartirlas.

11.6. Notificar a LexFlow cualquier sospecha de compromiso de cuenta en plazo no mayor a 24 horas.

11.7. No cargar datos que el Estudio no tenga base de licitud para tratar (datos obtenidos ilícitamente, datos de terceros sin relación procesal con el asunto, etc.).

11.8. Cumplir sus obligaciones como responsable frente a los titulares y la SPDP.

12. Vigencia

12.1. Este Acuerdo entra en vigencia simultáneamente con los Términos de Uso (documento 01) y rige durante todo el período en que LexFlow trate datos del Responsable.

12.2. Las obligaciones de confidencialidad (cláusula 8), notificación de incidentes (cláusula 9) y eliminación de datos (cláusula 7) subsisten tras la terminación del contrato por los plazos que cada cláusula establece.

13. Ley aplicable y jurisdicción

13.1. Este Acuerdo se rige por las leyes de la República del Ecuador.

13.2. Las controversias se someten a la jurisdicción de Quito, con mediación previa obligatoria conforme a la cláusula 16 de los Términos de Uso.

ANEXO A — Medidas de Seguridad Técnicas y Organizativas

Este Anexo describe en detalle las medidas de seguridad implementadas por LexFlow al momento de emisión de este documento. Constituye evidencia de diligencia debida para los efectos de la cláusula 10.5 de los Términos de Uso y del art. 38 LOPDP.

LexFlow mantiene este Anexo actualizado y notifica al Estudio cuando las medidas cambien materialmente.

Nota sobre la versión pública del Anexo A: existe una versión resumida del Anexo A (ANEXO-A-v0.2-propuesta.md) destinada a ser publicada o entregada a estudios durante el proceso comercial. La versión completa contenida en este DPA se entregará bajo Acuerdo de Confidencialidad y es de acceso restringido.

A.1. Arquitectura general

LexFlow es una aplicación SaaS multi-tenant con la siguiente topología:

Usuario (HTTPS/TLS 1.3)
   │
   ▼
┌──────────────────────────────────────┐
│ Frontend: Next.js 16 sobre Vercel    │  ← Edge Network global
│ - Server Components y Server Actions │
│ - CSP estricta + headers de seguridad│
└──────────────┬───────────────────────┘
               │ Service Role JWT
               ▼
┌──────────────────────────────────────┐
│ Backend: Supabase                    │  ← PostgreSQL 15 + Auth + Storage
│ - 14 tablas con RLS deny-all         │
│ - Aislamiento por tenant_id          │
│ - Cifrado AES-256 en reposo          │
└──────────────┬───────────────────────┘
               │
               ▼
┌──────────────────────────────────────┐
│ Orquestación: n8n en VPS Hetzner     │  ← Workflows programados
│ - Cron de vencimientos               │
│ - Throttling Resend + OneSignal      │
└──────────────────────────────────────┘

A.2. Cifrado

A.2.1. En tránsito

• HTTPS obligatorio en todas las superficies (Vercel, Supabase, n8n).
• TLS 1.3 como mínimo aceptado.
• HSTS habilitado en el dominio principal app.tiertec.lat con upgrade-insecure-requests en la CSP.
• Cookies seguras: flag Secure + SameSite=Lax + Path=/ en cookies de sesión (lib/supabase/server.ts).

A.2.2. En reposo

• PostgreSQL en Supabase: cifrado AES-256 transparente a nivel de disco.
• Storage de archivos en Supabase: cifrado AES-256.
• Contraseñas: hashing bcrypt gestionado por Supabase Auth. LexFlow nunca conoce contraseñas en texto plano.
• Variables de entorno sensibles (service role keys, API keys de OpenAI/Anthropic/Resend/OneSignal): cifradas en Vercel y en n8n (encryption key dedicada en /home/node/.n8n/config).

A.3. Autenticación y control de acceso

A.3.1. Autenticación de usuarios finales

• Supabase Auth con email + contraseña, magic link, y restablecimiento de contraseña con aprobación administrativa.
• Contraseña mínima: el sistema requiere actualmente un mínimo de 8 caracteres. Se recomienda a los usuarios usar al menos 12 caracteres con combinación de mayúsculas, minúsculas, números y símbolos. El requisito técnico de 12 caracteres está en roadmap de implementación.
• Hash de contraseñas: bcrypt con factor de costo gestionado por Supabase.
• JWT firmado para sesiones, almacenado como cookie httpOnly cuando es posible.

A.3.2. Rate limiting y bloqueo de cuentas

Implementado en LexFlow/login_rate_limit.sql:

• 5 intentos fallidos consecutivos por cuenta → cooldown de 5 minutos.
• 7 intentos totales → bloqueo permanente hasta reset por admin.
• 50 fallos / 15 minutos por IP → cooldown de 15 minutos para la IP.
• Anti-enumeración: mensajes genéricos que no revelan si un email existe.
• Función SQL `registrar_intento_login` con SECURITY DEFINER, grant solo a service_role.

A.3.3. Rate limiting de forgot-password

Implementado en LexFlow/rate_limit_forgot_password.sql:

• 3 solicitudes por hora por email.
• 10 solicitudes por hora por IP.
• Anti-enumeración: devuelve {ok:true} cuando se excede el límite (no revela el rate limit al atacante).

A.3.4. Rate limiting del asistente legal IA

Implementado en app/api/asistente-legal/query/route.ts:

• 20 consultas / 10 minutos por usuario + IP (anti-abuso por sesión).
• Cuota mensual por estudio configurable desde el panel super-admin (control de costos en OpenAI/Anthropic).

A.3.5. Roles diferenciados

• admin (del estudio): acceso total dentro de su tenant.
• abogado: acceso a sus casos asignados o con colaboración.
• asistente / pasante: acceso restringido, sin crear/editar clientes.
• super-admin: fuera de cualquier tenant, gestiona el SaaS (Gabriel Santos).

A.4. Aislamiento multi-tenant

A.4.1. A nivel de aplicación

• Toda query del servidor incluye .eq('tenant_id', usuario.tenant_id).
• Helper centralizado getDashboardContext() en lib/auth/dashboard.ts resuelve el tenant_id del usuario autenticado en cada request.
• Validación adicional en server actions: validarClienteTenant, validarUsuarioTenant, filtrarColaboradoresValidos.

A.4.2. A nivel de base de datos

• Row Level Security (RLS) deny-all en las 14 tablas con tenant_id. Migraciones aplicadas en:
• LexFlow/enable_rls_deny_all.sql (12 tablas iniciales).
• LexFlow/enable_rls_deny_all_extras.sql (7 tablas adicionales detectadas).
• Las únicas vías de acceso son operaciones del servidor usando service_role, que bypassa RLS por diseño y aplica el filtro tenant_id en la aplicación.
• Nota operativa: las políticas RLS deny-all funcionan como control de acceso de última línea. La seguridad multi-tenant primaria descansa en los filtros tenant_id aplicados en el código de la aplicación. La implementación de políticas RLS selectivas (lectura por tenant) está en el roadmap de mejora.

A.5. Validación y sanitización de inputs

Implementado en lib/validacion.ts:

• Tipos soportados: texto, email, url, numero, entero, fecha, uuid, boolean.
• Reglas: requerido, longitud mín/máx, valor mín/máx, listas cerradas (valoresPermitidos), protocolos de URL (default https:), etiquetas para mensajes.
• Tope absoluto: cualquier string > 50,000 caracteres es rechazado antes de aplicar la regla, como defensa contra DoS por payload gigante.
• Topes estándar: TEXTO_CORTO=200, TEXTO_MEDIO=2k, TEXTO_LARGO=5k, TEXTO_EXTRA_LARGO=20k, EMAIL=320 (RFC), URL=2k.
• Trim automático en texto (excepto contraseñas, que preservan espacios).
• Allowlist para enums críticos: materia procesal, tipo de actuación, prioridad, tipo de cliente, rol.
• Smoke test documentado en scripts/smoke-test-validacion.ts, 48 casos cubiertos incluyendo vectores de ataque real (SQL injection, XSS, CRLF en email, URL javascript:, payloads >60kb, UUID con SQLi).

A.6. Protección de inyección y XSS

• SQL injection: mitigado al 100% por uso exclusivo del SDK de Supabase (todas las queries parametrizadas).
• XSS: mitigado por:
• Escape automático de React al renderizar (no se usa dangerouslySetInnerHTML con input del usuario).
• CSP estricta (next.config.ts): default-src 'self', frame-ancestors 'none', object-src 'none', form-action 'self', upgrade-insecure-requests.
• X-Frame-Options: DENY y X-Content-Type-Options: nosniff.
• Header injection en correos: mitigado por validación de email con regex estricto que rechaza CRLF y caracteres de control.
• URLs `javascript:` y otros protocolos peligrosos: rechazadas — el validador de URL solo acepta https: por defecto.

A.7. Cabeceras de seguridad HTTP

Configuradas en next.config.ts, aplicadas a todas las rutas:

A.8. Auditoría y trazabilidad

• Tabla `audit_log` registra operaciones críticas: usuario_id, usuario_nombre, tabla, registro_id, caso_id, accion, detalle jsonb, created_at.
• Helper centralizado logAudit() en lib/audit.ts.
• Helper diffCampos() para registrar antes/después en updates.
• El audit log se conserva por la vida del tenant y se exporta en legal/export_tenant_data.sql.

A.9. Monitoreo y respuesta a incidentes

A.9.1. Sentry

• Integración nativa: @sentry/nextjs v10.
• Configurado en instrumentation.ts, instrumentation-client.ts, sentry.server.config.ts, sentry.edge.config.ts.
• Contexto del usuario: componente SentryUserContext adjunta usuario_id, tenant_id, rol, email a cada evento.
• Source maps subidos a Sentry para stack traces legibles.
• Scrubbing automático de campos sensibles configurado por defecto del SDK.
• NO se envía contenido sustantivo de los datos del Estudio (títulos, descripciones, notas), solo metadata operativa.

A.9.2. Logs operativos

• Logs de Vercel: disponibles por 7 días en el plan actual (Hobby).
• Logs de n8n: persistentes en el contenedor, rotados manualmente.
• Logs de eventos de seguridad (login_ip_attempts, rate_limit_eventos): limpieza pasiva a 24 horas para minimizar superficie de exposición.

A.9.3. Procedimiento de respuesta a incidentes

Ante un incidente confirmado, Gabriel Santos (en su rol de operador único actual):

1. Contener: desactivar el vector de ataque (rotar credenciales, bloquear IPs, deshabilitar funcionalidad si es necesario).
2. Investigar: revisar audit_log, Sentry, logs de Vercel y Supabase, eventos de los proveedores subordinados.
3. Notificar al Estudio afectado dentro de 24 a 48 horas desde que se tome conocimiento del incidente, conforme a la cláusula 9. La primera notificación puede ser preliminar si la investigación aún está en curso.
4. Asistir al Estudio en la eventual notificación a la SPDP y a los titulares.
5. Aplicar correcciones técnicas y/o organizativas.
6. Documentar el incidente: causa raíz, alcance, medidas adoptadas, lecciones aprendidas.

Ver también: el Plan de Respuesta a Incidentes LexFlow v0.1 (04-PLAN-RESPUESTA-INCIDENTES-LexFlow-v0.1.md) contiene el procedimiento operativo detallado con roles, plazos específicos, plantillas de comunicación y criterios de escalamiento.

A.10. Backups y continuidad

• Backups automáticos de PostgreSQL gestionados por Supabase: diarios, rotación de 7 días en plan free, hasta 30 días en plan Pro.
• Point-in-time recovery (PITR) disponible en plan Pro de Supabase.
• Configuración de n8n respaldada: workflows en archivos JSON versionados en el repositorio local (LexFlow/lexflow_workflow_vencimientos_v6.json).
• Procedimiento de recuperación documentado en Sistema de Administración de Estudio Juridico/LEXFLOW_CONTEXT.md.

A.11. Gestión de vulnerabilidades

• Dependencias del frontend: Next.js 16, React 19, Supabase JS SDK, OpenAI SDK — todas con actualizaciones de seguridad seguidas.
• Servidor VPS Ubuntu 24.04 LTS: unattended-upgrades activo para parches automáticos de seguridad.
• Headers de seguridad y CSP revisados periódicamente.
• Smoke tests ante cambios en la capa de validación (scripts/smoke-test-validacion.ts).
• GitHub Dependabot habilitado en el repositorio para alertas de vulnerabilidades en dependencias.

A.12. Hardening adicional aplicado

Documentado en Sistema de Administración de Estudio Juridico/codex/SECURITY_CHANGES_2026-05-01.md:

• getCurrentUsuario() en server actions valida activo y expulsa usuarios inactivos.
• Validación server-side en TODA mutación: cliente_id, abogado_responsable_id, colaboradores, acceso real al caso/actuación.
• actualizarCaso / cerrarCaso / reabrirCaso / eliminarCaso requieren admin o responsable principal.
• Pasantes no pueden crear, editar ni eliminar clientes.
• auth/callback: solo permite next con rutas internas seguras (anti-open-redirect).
• Helper centralizado getDashboardContext() usado por layout + 20 páginas internas.

A.13. Personal y procedimientos

• Operador único actual: Gabriel Josías Santos Rivera.
• Acceso al service role key: restringido al operador único.
• Acceso SSH al VPS: clave ED25519, password authentication deshabilitable (pendiente).
• Acceso a Supabase: cuenta gabojosi@gmail.com con 2FA recomendado.
• Acceso a Vercel: cuenta vinculada a GitHub con 2FA.
• Inventario de credenciales: mantenido en archivo local cifrado fuera del repositorio.
• Persona de respaldo para continuidad: designada conforme a la cláusula 3.10 de este Acuerdo. Datos de contacto mantenidos en el inventario de credenciales y disponibles para el Estudio ante solicitud formal.

A.14. Limitaciones reconocidas

LexFlow reconoce las siguientes limitaciones actuales que están en plan de mejora:

• 2FA opcional para los usuarios finales (no obligatorio aún).
• No hay WAF dedicado delante de Vercel; se depende de las protecciones nativas de la plataforma.
• No hay análisis automático de malware en archivos subidos al bucket de Storage.
• Validación de inputs en Fase 1: cubre 5 server actions críticas. Fase 2 (resto de actions) pendiente.
• RLS deny-all está activo pero las políticas de lectura selectivas por tenant aún no están implementadas; la seguridad multi-tenant primaria descansa en los filtros tenant_id aplicados en el código de la aplicación.
• Garantías del modelo conversacional (Anthropic, USA): las llamadas al API de Anthropic están respaldadas por el DPA estándar de Anthropic (en proceso de firma), retención por defecto de 7 días, y compromiso documentado de no entrenar con datos API. Las garantías técnicas se describen en la cláusula 4. Histórico: hasta el 2026-05-15 se usaba DeepSeek (China); migrado por requisito LOPDP.

Estas limitaciones se comunican proactivamente al Estudio para que pueda evaluar el riesgo conforme a sus propias obligaciones como responsable. La versión completa de este Anexo A, con el detalle operativo de cada medida, se entrega bajo acuerdo de confidencialidad. La versión pública resumida (ANEXO-A-v0.2-propuesta.md) está disponible para consulta sin restricción.

ANEXO B — Modelo de aviso de incidente al Estudio

Plantilla que LexFlow usará al notificar un incidente conforme a la cláusula 9:

ASUNTO: [LexFlow — Incidente de Seguridad] Notificación al Estudio <NOMBRE>

Estimado/a administrador/a de <NOMBRE_ESTUDIO>,

En cumplimiento de la cláusula 9 del Acuerdo de Tratamiento de Datos
suscrito con LexFlow, notificamos el siguiente incidente de seguridad:

1. Fecha y hora de toma de conocimiento: <FECHA_HORA>
2. Naturaleza del incidente: <DESCRIPCIÓN>
3. Categorías de datos afectadas: <DATOS>
4. Número aproximado de titulares afectados: <NÚMERO>
5. Consecuencias probables: <CONSECUENCIAS>
6. Medidas adoptadas hasta el momento: <MEDIDAS>
7. Medidas pendientes y plazo estimado: <PENDIENTES>
8. Punto de contacto: Gabriel Santos — dpo@tiertec.lat

Esta notificación se emite dentro del plazo de 24 a 48 horas establecido
en la cláusula 9.2. Si la investigación aún está en curso, se emitirá
una notificación complementaria dentro de las 72 horas siguientes.

Recomendamos:
- Evaluar si corresponde notificar a la SPDP (art. 43 LOPDP).
- Evaluar si corresponde notificar individualmente a los titulares.
- Documentar el incidente en su propio registro interno.

LexFlow está a disposición para asistir en lo que sea necesario.

Atentamente,
Gabriel Josías Santos Rivera
Operador de LexFlow
dpo@tiertec.lat

Quito, 19 de mayo de 2026

Versión: 0.2 — pendiente de validación legal profesional.