Checklist de seguridad

Preguntas para evaluar una plataforma de IA legal

La revisión de seguridad para IA legal no trata solo de infraestructura. La plataforma puede procesar documentos privilegiados, registros confidenciales de clientes, datos sensibles de negocio, prompts, salidas, citas, decisiones de flujo, firmas y contexto de auditoría.

Usa este checklist para estructurar la revisión de seguridad, privacidad, compras y gobernanza de IA.

1. Clasificación y entrada de datos

Pregunta:

• ¿Qué categorías de datos de cliente pueden entrar en la plataforma?
• ¿La plataforma soporta diferentes clases de datos por organización, workspace, asunto, equipo o rol?
• ¿Cómo se manejan documentos, prompts, salidas, referencias de fuentes, firmas, comentarios y auditoría?
• ¿Hay flujos que deban prohibirse o restringirse por sensibilidad de datos?
• ¿Cómo ayuda la plataforma a mantener datos sensibles en el workspace correcto?

Evidencia a solicitar:

• Resumen de flujo de datos.
• Política de tratamiento de datos.
• Documentación de retención y eliminación.
• Política de acceso de soporte.
• Paquete de seguridad o respuesta a cuestionario.

2. Aislamiento de tenant y controles de acceso

Pregunta:

• ¿Cómo se separan los datos de clientes por tenant?
• ¿Cómo se asignan permisos a equipos, roles, workspaces, asuntos y registros?
• ¿La plataforma soporta SSO/SAML, MFA, RBAC y controles administrativos?
• ¿El acceso puede delimitarse por flujo o recurso?
• ¿Cómo se manejan desprovisionamiento y ciclo de vida de usuarios?
• ¿Cómo se registran acciones administrativas privilegiadas?

Buenas respuestas muestran separación clara entre identidad, rol, workspace, asunto, documento y acceso administrativo.

3. Límites de modelo y proveedor de IA

Pregunta:

• ¿Qué proveedores de IA o caminos de modelo pueden usarse?
• ¿Cómo se gobiernan por ambiente, plan, flujo o requisito del cliente?
• ¿Qué términos contractuales sostienen declaraciones de no entrenamiento o uso de datos?
• ¿Prompts, completions, fuentes recuperadas, embeddings, logs o datos derivados se usan para entrenar modelos generales?
• ¿Cómo se gobiernan caídas de proveedor, cambios de modelo o cambios de ruteo?
• ¿Los detalles de modelo/proveedor se exponen a usuarios finales o se gestionan internamente?

Evidencia a solicitar:

• Resumen de gobernanza de IA.
• Explicación de tratamiento de datos por modelo/proveedor.
• Lenguaje contractual de no entrenamiento o equivalente aprobado.
• Lista de subprocessadores.
• Proceso de gestión de cambios para ruteo de IA.

4. Revisión humana y responsabilidad profesional

Pregunta:

• ¿Qué flujos requieren revisión humana antes de que la salida sea final?
• ¿Los puntos de revisión pueden configurarse por flujo, rol, tipo de dato o riesgo?
• ¿Los revisores ven fuentes, limitaciones, incertidumbre o contexto relevante?
• ¿Pueden rechazar, sobrescribir o escalar trabajo asistido por IA?
• ¿Cómo se preserva la identidad del revisor en el registro?

Seguridad y compliance deben tratar la revisión humana como control, no como mensaje de marketing.

5. Grounding en fuentes y controles de evidencia

Pregunta:

• ¿Cuándo la plataforma cita fuentes o muestra evidencia recuperada?
• ¿Cuándo indica claramente que una salida no está basada en fuentes?
• ¿Los equipos pueden restringir flujos a políticas, plantillas, documentos o fuentes legales aprobadas?
• ¿Cómo se manejan fuentes obsoletas, conflictivas o faltantes?
• ¿Citas, extractos o referencias de conocimiento se preservan en el registro cuando corresponde?

Señales de alerta:

• Afirmaciones amplias de "siempre exacto".
• Sin distinción entre salidas basadas y no basadas en fuentes.
• Sin ruta de escalamiento para incertidumbre.
• Sin forma de ver qué fuentes influyeron en la salida.

6. Logs de auditoría y registros

Pregunta:

• ¿Qué eventos de usuario, administrador, flujo, IA y documento se registran?
• ¿Los logs muestran responsable, fuente, revisión, aprobación, firma y contexto de registro?
• ¿Son exportables para seguridad, compliance o incidentes?
• ¿Cuál es el periodo de retención?
• ¿Están protegidos contra alteración o eliminación no autorizada?
• ¿Cómo se registran acceso de soporte y acciones administrativas?

Para equipos regulados, la auditabilidad forma parte del producto. Debe ser fácil de explicar durante compras.

7. Cifrado, infraestructura y certificaciones

Pregunta:

• ¿Los datos están cifrados en tránsito y en reposo?
• ¿Qué regiones, proveedores de nube o modelos de despliegue aplican?
• ¿Cómo se protegen backups?
• ¿Qué procesos existen para disponibilidad, monitoreo e incidentes?
• ¿Cómo se rastrean y remedian vulnerabilidades?
• ¿Existe continuidad de negocio y recuperación de desastre?
• ¿Qué marcos de privacidad se soportan plenamente, como GDPR, LGPD y CCPA?
• ¿Qué certificaciones se mantienen o preparan formalmente, como SOC 2 o ISO 27001, y proveedores centrales tienen SOC 2?

Evidencia a solicitar:

• Resumen de arquitectura de seguridad.
• Resumen de respuesta a incidentes.
• Postura de backup y recuperación.
• Resumen de pentest o materiales de assurance actuales si están disponibles.
• Certificados actuales o documentación formal de preparación, incluidas certificaciones heredadas de subprocessadores como AWS.
• Postura de cumplimiento de privacidad.

8. Retención, eliminación y portabilidad

Pregunta:

• ¿Cuánto tiempo se retienen documentos, prompts, salidas, logs, firmas y registros de bóveda?
• ¿La retención puede configurarse por organización o flujo?
• ¿Qué opciones de eliminación existen durante y después del contrato?
• ¿Cómo se manejan backups después de eliminación?
• ¿Los registros pueden exportarse al terminar?
• ¿Qué ocurre con datos derivados, embeddings o material en caché?

Legal, seguridad y compras deben verificar la respuesta en políticas y contrato antes de firmar.

9. Subprocessadores y acceso de soporte

Pregunta:

• ¿Qué subprocessadores pueden procesar datos de clientes?
• ¿Qué cambios activan aviso al cliente?
• ¿Cómo se aprueba, delimita, registra y revoca el acceso de soporte?
• ¿Puede limitarse a metadatos o sesiones controladas cuando corresponde?
• ¿Los equipos de soporte están entrenados para datos legales y regulados sensibles?

Evidencia a solicitar:

• Lista actual de subprocessadores.
• Proceso de acceso de soporte.
• Ruta de DPA.
• Paquete de seguridad.

10. Preparación para compras

Antes de revisión legal o de compras, reúne:

• Visión general o paquete de seguridad.
• Ruta del acuerdo de procesamiento de datos.
• Lista de subprocessadores.
• Política de privacidad.
• Resumen de respuesta a incidentes.
• Resumen de retención y eliminación.
• Resumen de gobernanza de IA.
• Materiales de accesibilidad o compliance si se requieren.
• Respuesta a cuestionario de seguridad.
• Contacto nombrado para seguridad o compras.

11. Registro mínimo de revisión

Mantén un registro con:

• Fecha de revisión.
• Contactos del proveedor.
• Alcance de producto y despliegue.
• Categorías de datos en alcance.
• Documentos de seguridad recibidos.
• Riesgos abiertos y mitigaciones.
• Cláusulas contractuales a revisar.
• Controles requeridos de implementación.
• Fecha de renovación o reevaluación.

12. Preguntas de seguridad para Forlex

Lleva estas preguntas a una conversación de seguridad o compras:

• ¿Qué controles están disponibles para nuestro plan y alcance?
• ¿Cómo se separan organización, equipos, roles, asuntos y workspaces?
• ¿Qué evidencia sostiene no entrenamiento, retención, soporte y subprocessadores?
• ¿Qué eventos de flujo y decisiones de revisión pueden preservarse para auditoría?
• ¿Qué materiales están disponibles antes de la revisión contractual?
• ¿Qué integraciones requieren escopo adicional de seguridad?
• ¿Qué decisiones de implementación afectan la postura de riesgo?

13. Condiciones de parada y escalamiento

Escala antes de comprar si:

• El proveedor no explica el uso de datos para prompts, salidas, logs, embeddings o derivados.
• Nadie responde por seguridad o DPA.
• Las afirmaciones de no entrenamiento no están respaldadas por contrato.
• El acceso de soporte es amplio, informal o no registrado.
• La revisión humana se promete, pero no es visible en el flujo.
• Los logs no cubren eventos necesarios.
• Retención y eliminación son ambiguas.

La revisión de seguridad debe reducir ambigüedad antes de firmar, no descubrirla durante la implementación.