Cómo pueden los bufetes probar la seguridad de TI antes de implementar otra herramienta de IA
Fusion Legal & Tax · 16 de octubre de 2026Liderazgo de opinión8 min de lectura
Implementar una herramienta de IA con confianza exige más que revisar la aplicación en sí. Su bufete también debe entender la infraestructura mediante la cual los abogados acceden a ella, incluidos los sistemas de identidad, el correo electrónico, los dispositivos terminales, los repositorios de documentos, los respaldos, las integraciones y la mesa de ayuda de TI.
Ese tejido conectivo suele estar administrado por un proveedor de servicios administrados, o MSP. En la práctica, el MSP puede formar parte del entorno de control de IA del bufete, incluso si nunca vende un producto de IA.
La oportunidad de protección es clara: tratar la TI administrada como una extensión del bufete sujeta a gobernanza, no simplemente como una suscripción de soporte. Una relación sólida con un MSP debe ayudar a los abogados a trabajar con confianza dentro de límites claros, a la vez que conserva evidencia de que esos límites funcionan según lo previsto.
Sepa qué puede ver, cambiar y recuperar su proveedor de TI
Un cuestionario para el MSP debe comenzar por lo que el proveedor puede ver, cambiar, aprobar, recuperar y exportar. Los bufetes deben identificar al menos cinco formas de autoridad:
- Autoridad sobre las identidades: ¿El personal del MSP puede restablecer contraseñas, registrar factores de autenticación, crear cuentas o cambiar la pertenencia a grupos?
- Autoridad sobre los dispositivos terminales: ¿Puede acceder a computadoras portátiles de forma remota, instalar software, desactivar herramientas de seguridad o copiar archivos?
- Autoridad sobre los repositorios: ¿Puede administrar el entorno de gestión de documentos, gestión de casos, correo electrónico o respaldos?
- Autoridad sobre las integraciones: ¿Puede aprobar conexiones entre un producto de IA y Microsoft 365, un DMS, un CRM u otro sistema oficial de registro?
- Autoridad sobre la recuperación: ¿Puede restaurar mensajes eliminados, expedientes de asuntos o respaldos históricos, y quién puede autorizar ese trabajo?
Este inventario es más útil que preguntar si el proveedor ofrece “seguridad para bufetes”. Permite identificar las vías por las cuales una acción rutinaria de soporte podría afectar información confidencial.
Haga que las promesas de seguridad sean claras y comprobables
El vocabulario actual del mercado incluye controles de confidencialidad, cifrado, prevención de pérdida de datos, muros éticos, retención, respuesta rápida y monitoreo continuo. Esos términos solo tienen sentido cuando el bufete puede relacionar cada uno con su alcance, responsable, evidencia y excepciones.
Por ejemplo, SADOS describe su servicio de TI para bufetes como uno que incluye controles de acceso específicos para cada asunto, cifrado de correo electrónico, soporte para DMS, respaldos diarios, muros éticos documentados y procedimientos de recuperación probados. También afirma: “Respondemos en un plazo de 4 horas durante el horario laboral y tratamos como prioritarios los asuntos relacionados con plazos judiciales”. Esa redacción aún deja preguntas útiles para la debida diligencia: qué significa “prioritario” en términos de respuesta y resolución, cómo se atienden las emergencias de presentación fuera del horario laboral conforme a esta descripción del servicio y cómo se clasifican los reportes de apropiación de cuentas.
Para cada control prometido, los bufetes deben solicitar un paquete de evidencia específico:
| Promesa | Lo que el bufete debe definir | Evidencia que debe solicitar |
|---|---|---|
| Acceso basado en roles | Sistemas cubiertos, reglas a nivel de asunto, personas que aprueban, excepciones | Matriz de acceso y muestra de un registro de revisión de acceso |
| Muros éticos | Factor desencadenante, responsable de la implementación, aplicaciones afectadas, método de validación | Registro de configuración y resultado de la prueba |
| Cifrado de correo electrónico | Activadores automáticos, opciones de anulación por parte del usuario, flujo de trabajo para destinatarios externos | Exportación de la política y prueba de entrega |
| Respaldo y retención | Sistemas cubiertos, frecuencia, período de retención, manejo de eliminaciones | Inventario de respaldos y registro de una prueba de restauración reciente |
| Respuesta rápida | Definiciones de gravedad, límites del horario laboral, vía de escalamiento | Tabla de niveles de servicio y lista de contactos para escalamientos |
| Soporte remoto | Verificación de identidad, herramientas permitidas, grabación de sesiones, reglas para la transferencia de archivos | Procedimiento de soporte y muestra representativa del registro de auditoría |
El objetivo no es generar documentación porque sí. Es asegurar que los abogados, el personal interno de operaciones, el MSP y cualquier proveedor de IA compartan la misma definición de “protegido”.
Facilite el reconocimiento del soporte legítimo de TI
El soporte remoto merece especial atención porque combina privilegios técnicos con confianza humana. Un técnico puede tener la capacidad de restablecer credenciales, acceder a un dispositivo terminal, cambiar permisos o guiar a un usuario en una acción delicada. Esto convierte a la mesa de ayuda en una función de verificación de identidad, no simplemente en una fila de solicitudes pendientes.
Según informó Law360 el 2 de octubre de 2026, ese año se habían producido varios ciberataques de alto perfil contra bufetes, lo que reflejaba el creciente papel de la IA en los incidentes de seguridad y la mayor sofisticación de los actores maliciosos que atacaban al sector legal. Esa tendencia hace que la verificación por parte de la mesa de ayuda sea un componente práctico de la seguridad en la era de la IA.
Un bufete puede protegerse facilitando el reconocimiento de las prácticas legítimas de soporte. Entre los controles útiles se encuentran:
- exigir que el personal inicie las sesiones remotas mediante un portal conocido o un número publicado;
- prohibir que los técnicos soliciten contraseñas o códigos de autenticación;
- exigir una segunda aprobación para restablecer la autenticación multifactor y realizar cambios en cuentas privilegiadas;
- mostrar la identidad del técnico y el número de solicitud antes de iniciar el acceso remoto;
- restringir la transferencia de archivos durante las sesiones de soporte, salvo que se apruebe por separado;
- registrar el acceso remoto, los cambios administrativos y las exportaciones de datos; y
- crear un canal interno conocido para verificar una solicitud inusual sin depender de los datos de contacto proporcionados en la propia solicitud.
Un ejercicio de simulación debe poner a prueba estos procedimientos. Pida a una persona autorizada para realizar pruebas que se haga pasar por el MSP y solicite con urgencia un restablecimiento de autenticación, una sesión de control remoto o la transferencia de un documento de un cliente. Evalúe si el personal verifica la solicitud, si el MSP detecta la suplantación y si se conservan los registros de escalamiento.
Conecte la revisión del MSP con la del proveedor de IA
La debida diligencia sobre la IA y la debida diligencia sobre el MSP no deben avanzar por caminos separados. El proveedor de IA puede controlar el modelo y la aplicación, mientras que el MSP controla las condiciones de identidad, dispositivos terminales, correo electrónico, repositorios y redes que los rodean.
La guía de Thomson Reuters sobre la debida diligencia de proveedores de IA recomienda obtener detalles específicos sobre dónde se almacenan los datos generados por IA, quién puede acceder a ellos, si las comunicaciones o los datos de transacciones se utilizan para entrenamiento, quién conserva los derechos sobre la información, cómo se eliminan los datos y si la información se comparte con terceros. La guía identifica como señales de alerta las respuestas imprecisas sobre seguridad, las políticas de eliminación poco claras y la renuencia a hablar sobre el intercambio de información con terceros.
Esas preguntas deben incorporarse a una revisión de la integración:
- ¿La aplicación de IA hereda los permisos del repositorio de origen o puede exponer el material de forma más amplia?
- ¿Puede un administrador autorizar un conector para todo el bufete sin una segunda persona que lo apruebe?
- ¿Qué parte registra las instrucciones, los documentos recuperados, los resultados generados, los cambios de permisos y las exportaciones?
- ¿Puede el MSP ver el contenido de las sesiones de IA mientras resuelve problemas?
- ¿Desactivar a un usuario en el sistema de identidad del bufete termina de inmediato su acceso a la IA?
- Cuando se cierra un asunto o un usuario deja el bufete, ¿qué parte elimina las copias almacenadas en caché, indexadas o sincronizadas?
- Si se desconecta la integración, ¿qué datos conserva cada proveedor?
Ningún proveedor debe responder únicamente la parte limitada de estas preguntas que le corresponde. El bufete necesita un diagrama integral del flujo de datos y una matriz clara de responsabilidades que cubra cada punto de transferencia.
Mantenga separados la confidencialidad, el privilegio y la seguridad
En ocasiones, las propuestas tecnológicas utilizan “protegido por el privilegio” como una forma abreviada de referirse al cifrado y a los controles de acceso. Los bufetes deben evitar esa simplificación.
Los controles de seguridad pueden limitar el acceso no autorizado, conservar registros y respaldar el manejo disciplinado del material confidencial. No determinan por sí solos si una comunicación está protegida legalmente por el privilegio, si se ha renunciado a ese privilegio o si una persona en particular debe recibir un documento. Esas siguen siendo cuestiones legales y fácticas que requieren la supervisión de un abogado.
Por lo tanto, el lenguaje de contratación debe describir lo que la tecnología realmente hace: cifra determinado tráfico, limita el acceso por rol o asunto, registra la actividad administrativa, impide transferencias definidas o restaura datos cubiertos. La precisión protege tanto al bufete como al proveedor frente a la posibilidad de depender de un eslogan que vaya más allá del control subyacente.
Un control práctico antes de la compra
Antes de aprobar otra herramienta de IA, los líderes del bufete deben pedir al MSP, al proveedor de IA y al responsable interno que completen un registro de control compartido:
- Datos involucrados: ¿Qué información de clientes, del bufete, del personal o de las operaciones entrará en el flujo de trabajo?
- Sistemas conectados: ¿Qué entornos de identidad, correo electrónico, DMS, gestión de casos, facturación o almacenamiento están involucrados?
- Personas con acceso: ¿Qué integrantes del bufete, técnicos del MSP, integrantes del proveedor y subencargados del tratamiento pueden acceder a los datos o administrar el sistema?
- Usos permitidos: ¿Cuál es la tarea aprobada y qué usos permanecen fuera del alcance?
- Retención y eliminación: ¿Dónde se conservan las instrucciones, los archivos, los índices, los registros y los resultados, y cómo se verifica su eliminación?
- Límites del soporte: ¿A qué pueden acceder los técnicos y qué aprobación adicional se requiere para realizar acciones delicadas?
- Responsabilidad sobre incidentes: ¿Quién contiene el incidente, investiga, conserva la evidencia, se comunica y decide si la integración permanece activa?
- Procedimiento de salida: ¿Cómo se eliminan los accesos, conectores, tokens, datos sincronizados y copias en poder del proveedor?
El punto estratégico va más allá de la ciberseguridad. Los bufetes no pueden ampliar responsablemente el uso de la IA si la gobernanza de sus aplicaciones termina donde comienza la TI administrada. Los bufetes mejor preparados para adoptar la IA con confianza serán aquellos que hagan visible cada transferencia técnica, asignen un responsable a cada acción privilegiada y comprueben que los controles prometidos funcionan antes de que un asunto de importancia dependa de ellos.
Este artículo ofrece información educativa general para profesionales del sector legal y no constituye asesoría legal para ningún bufete, sistema o incidente en particular.