Documento legal

Acuerdo de tratamiento de datos (DPA)

Acuerdo entre LexFlow y el estudio (responsable del tratamiento).

Acuerdo de Tratamiento de Datos Personales — LexFlow

Versión: 0.1 (borrador inicial) Fecha de emisión: 11 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.

Aviso: Este documento es un borrador técnico. NO ha sido revisado por un abogado colegiado en Ecuador. NO usar en producción 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). 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 72 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.

4. Sub-encargados de tratamiento autorizados

LexFlow se apoya en los siguientes proveedores externos como sub-encargados:

Proveedor	Función	Sede de procesamiento	Garantías
Supabase Inc.	Base de datos PostgreSQL, autenticación, storage	Estados Unidos (us-east-1 / sa-east-1)	SOC 2 Tipo II + cifrado AES-256 en reposo + TLS 1.3 en tránsito
Vercel Inc.	Hosting frontend Next.js	Estados Unidos	SOC 2 Tipo II + DPA estándar de Vercel
Hetzner Online GmbH	VPS con n8n (orquestador de workflows)	Alemania (Falkenstein FSN1)	ISO 27001 + ubicación en la UE (GDPR-compliant)
OpenAI L.L.C.	Generación de embeddings vectoriales	Estados Unidos	DPA estándar de OpenAI + Zero Data Retention para API empresarial
Anthropic PBC	Modelo conversacional del asistente legal (Claude Haiku 4.5)	Estados Unidos	SOC 2 Tipo II + DPA estándar en proceso de firma + retención 7 días por defecto + sin training en datos API. Las llamadas a Anthropic NO contienen identificadores personales del usuario ni de terceros.
Resend Inc.	Envío de correos transaccionales	Estados Unidos	SOC 2 Tipo II + DPA estándar de Resend
OneSignal Inc.	Notificaciones push	Estados Unidos	SOC 2 Tipo II + DPA estándar de OneSignal
Functional Software, Inc. (Sentry)	Monitoreo de errores	Estados Unidos	SOC 2 Tipo II + scrubbing automático de PII configurado
Namecheap Inc.	Registrador del dominio tiertec.lat	Estados Unidos	Solo procesa datos WHOIS del Prestador, no del Estudio

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.

5. Transferencias internacionales

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

Base de licitud para la transferencia (LOPDP art. 56):

Necesidad para la ejecución del contrato entre el Estudio y LexFlow.
Garantías adicionales: certificaciones SOC 2, DPAs estándar, cifrado de extremo a extremo.

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:

Acusará recibo de la solicitud.
Reenviará la solicitud al Estudio responsable en plazo no mayor a 5 días hábiles.
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) 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 72 horas desde que tome conocimiento del incidente.

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 asistirá al Estudio en la preparación de esa notificación.

9.5. Notificación a los titulares

Cuando el incidente represente alto riesgo para los titulares, el Estudio les notificará individualmente. 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 72h + diligencia debida + límite cuantitativo).

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.

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: 12 caracteres recomendados (no impuesto a nivel técnico aún, pendiente refuerzo).
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.
Si una server action olvida el filtro tenant_id, RLS no salva el día (porque service_role lo ignora). Por eso la validación es defensa en profundidad, no salvavidas.

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:

Header	Valor
`X-Content-Type-Options`	`nosniff`
`X-Frame-Options`	`DENY`
`Cross-Origin-Opener-Policy`	`same-origin`
`Referrer-Policy`	`strict-origin-when-cross-origin`
`X-DNS-Prefetch-Control`	`off`
`Permissions-Policy`	`camera=(), microphone=(), geolocation=(), payment=(), usb=(), serial=(), bluetooth=()`
`Content-Security-Policy`	Ver cláusula A.6

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 (titulos, 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):

Contener: desactivar el vector de ataque (rotar credenciales, bloquear IPs, deshabilitar funcionalidad si es necesario).
Investigar: revisar audit_log, Sentry, logs de Vercel y Supabase, eventos de los proveedores subordinados.
Notificar al Estudio afectado dentro de 72 horas conforme a la cláusula 9.
Asistir al Estudio en la eventual notificación a la SPDP y a los titulares.
Aplicar correcciones técnicas y/o organizativas.
Documentar el incidente: causa raíz, alcance, medidas adoptadas, lecciones aprendidas.

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. Si getUser() falla, valida access_token contra admin.auth.getUser(token).

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.

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 sin políticas de lectura selectivas implementadas (defensa en profundidad, no RLS funcional). Toda la seguridad multi-tenant depende del filtro aplicado en código.

Estas limitaciones se comunican proactivamente al Estudio para que pueda evaluar el riesgo conforme a sus propias obligaciones como responsable.

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

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, 11 de mayo de 2026

Versión: 0.1 — borrador inicial pendiente de revisión legal profesional.