Claude para un despacho de abogados, conforme desde el diseño

Los abogados querían usar Claude. El problema no era el modelo, sino todo lo que lo rodea: por dónde pasan los datos, quién los ve, cuánto tiempo permanecen, quién hizo qué. Construimos un perímetro en el que la respuesta a cada una de estas preguntas está escrita en la configuración, no en una promesa.

El cliente

Una asociación profesional de abogados (nombre reservado) que trabaja en derecho civil, mercantil y laboral, con socios, asociados, abogados en prácticas y personal administrativo que trabajan a diario con escritos, contratos, dictámenes y correspondencia con los clientes.

Un material que contiene, por definición, el tipo de dato más delicado que existe en un despacho: información amparada por el secreto profesional, datos personales de clientes y contrapartes, a menudo datos de salud (reclamaciones de daños, laboral) y datos penales.

El encargo

El despacho tenía un problema muy común: la IA ya había entrado, pero por la puerta equivocada. Algunos profesionales usaban chatbots con cuentas personales, pegando fragmentos de escritos y contratos. Ningún contrato de encargo de tratamiento entre el despacho y el proveedor, ningún control sobre adónde iban esos textos, ninguna posibilidad de revocar el acceso cuando un asociado dejaba el despacho, ningún rastro de lo que se había compartido.

Prohibirlo no funcionaba: la ventaja en la redacción de borradores, la síntesis de expedientes y la revisión de contratos era demasiado evidente. Por eso el encargo fue claro: dar Claude a todos, pero dentro de un perímetro en el que cada obligación legal se cumpla y se pueda demostrar.

Los requisitos, puestos por escrito con los socios y con el DPO:

• ningún dato de clientes conservado por el proveedor del modelo ni utilizado para entrenarlo;
• tratamiento solo dentro de la Unión Europea;
• cada usuario identificado individualmente, sin credenciales compartidas;
• minimización de los datos personales antes de que lleguen al modelo;
• separación entre asuntos, para respetar los conflictos de intereses y la confidencialidad interna;
• trazabilidad de quién usa el sistema, sin crear un nuevo archivo de contenidos confidenciales;
• documentación suficiente para la EIPD, el registro de actividades de tratamiento y la información a los clientes.

Por qué AWS Bedrock

Elegimos ofrecer Claude a través de Amazon Bedrock por cuatro razones concretas:

1. El contrato ya es el adecuado. El tratamiento está cubierto por el Data Processing Addendum de AWS (integrado en los Service Terms, con cláusulas contractuales tipo), y AWS pone a disposición a través de AWS Artifact las certificaciones ISO 27001, 27017, 27018, 27701 y los informes SOC necesarios para la EIPD.
2. Bedrock no conserva prompts ni respuestas. Por diseño del servicio, el contenido de las solicitudes no se guarda ni se usa para entrenar modelos, y Anthropic, como proveedor del modelo, no tiene acceso a los prompts ni a las respuestas.
3. Regiones europeas. La inferencia puede limitarse a centros de datos de la Unión Europea.
4. Todos los controles en el mismo lugar. Identidad, red privada, cifrado con claves propias, auditoría y políticas de organización son servicios nativos de AWS, configurables como código y verificables en cualquier momento.

El resto del trabajo consistió en convertir estas premisas en una configuración blindada, porque un servicio conforme mal utilizado sigue siendo un tratamiento no conforme.

La arquitectura en resumen

Nivel	Decisión	Objetivo
Modelo	Claude en Amazon Bedrock, perfiles de inferencia eu.	Sin conservación, tratamiento en la UE
Identidad	IAM Identity Center federado con el proveedor de identidad del despacho, MFA	Cuentas individuales, revocación centralizada
Minimización	Capa de seudonimización + Bedrock Guardrails	El modelo ve lo mínimo posible
Red	VPC endpoints privados (PrivateLink), sin acceso público	El tráfico no pasa por internet
Cifrado	AWS KMS con claves gestionadas por el despacho	Control de las claves sobre todos los datos en reposo
Documentos	Bedrock Knowledge Bases con filtros por asunto	Murallas éticas entre expedientes
Auditoría	CloudTrail inmutable + auditoría de aplicación solo con metadatos	Quién, cuándo, qué, nunca el contenido
Gobernanza	AWS Organizations, SCP, AWS Config, infraestructura como código	Nadie puede desactivar los controles

1. Zero data retention: qué pasa realmente con los datos

"Zero retention" es una promesa que se rompe con facilidad. No basta con que el modelo no conserve nada: hay que cerrar cada punto de la cadena en el que un texto podría quedar escrito en algún sitio.

• En Bedrock. Los prompts y las respuestas se procesan y el servicio no los guarda, no entrenan ningún modelo y el proveedor del modelo no tiene acceso a ellos.
• Model invocation logging desactivado. Bedrock permite registrar íntegramente prompts y respuestas en CloudWatch o S3. Útil en desarrollo, peligroso en producción. Lo desactivamos y prohibimos volver a activarlo con una Service Control Policy: ni siquiera un administrador de la cuenta puede hacerlo.
• Prompt caching. La caché de prompts de Bedrock es temporal (minutos) y no persistente: reduce costes y latencia en documentos largos sin crear un archivo.
• Sin historial por defecto en la aplicación. Las conversaciones viven en la sesión. Guardarlas es una decisión explícita del usuario, vinculada a un asunto, cifrada y con borrado automático al vencer (TTL) según el plazo fijado en la EIPD.
• Sin contenidos en los logs de la aplicación. Los logs del backend están filtrados: registran identificadores técnicos, tiempos y códigos de error, nunca el texto. Todos los log groups tienen un periodo de retención configurado, nada de "conservar para siempre".
• Ningún dato en el navegador. La interfaz no guarda conversaciones en localStorage ni en la caché del navegador, para que un portátil abierto o compartido no se convierta en un archivo.
• Funciones que sacan datos del perímetro, desactivadas. Nada de búsqueda web, nada de herramientas que llamen a servicios externos, nada de modelos de terceros del marketplace, nada de fine-tuning (que obligaría a conservar datos de entrenamiento).

2. Residencia de los datos: todo en la Unión Europea

• Regiones europeas. La cuenta opera desde una región de la UE. Claude se invoca mediante perfiles de inferencia entre regiones eu., que reparten la carga solo entre regiones europeas.
• Perfiles globales prohibidos. Los perfiles global. pueden enrutar las solicitudes a cualquier región del mundo: están bloqueados a nivel de organización.
• Regiones no europeas bloqueadas. Una SCP deniega cualquier operación fuera de las regiones de la UE (con las únicas excepciones técnicas de los servicios globales como IAM).
• Todo lo demás, también. Buckets S3 de documentos, índice vectorial, claves KMS, trails de auditoría y copias de seguridad están en las mismas regiones europeas.

Un extracto de las políticas de organización aplicadas a la cuenta:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyGlobalInferenceProfiles",
      "Effect": "Deny",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "arn:aws:bedrock:*:*:inference-profile/global.*"
    },
    {
      "Sid": "DenyInvocationLoggingChanges",
      "Effect": "Deny",
      "Action": [
        "bedrock:PutModelInvocationLoggingConfiguration",
        "bedrock:DeleteModelInvocationLoggingConfiguration"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyBedrockApiKeys",
      "Effect": "Deny",
      "Action": ["iam:CreateServiceSpecificCredential", "bedrock:CallWithBearerToken"],
      "Resource": "*"
    }
  ]
}

3. Cuentas individuales, sin claves compartidas

El error más común en los proyectos de IA empresariales es una única clave de API pegada en un archivo de configuración y usada por todos. En un despacho de abogados significa no saber quién ha enviado qué, y no poder retirar el acceso a una persona sin retirárselo a todas.

• Single sign-on con el proveedor de identidad del despacho. Los usuarios entran con las mismas credenciales que usan para el correo y los documentos, mediante IAM Identity Center federado. MFA obligatoria.
• Aprovisionamiento automático (SCIM). Cuando un asociado deja el despacho, se le desactiva en un solo punto y pierde el acceso en todas partes, en el mismo momento.
• Sin usuarios IAM ni access keys permanentes. Solo credenciales temporales. La creación de usuarios IAM, de access keys y de API keys de Bedrock está prohibida mediante SCP.
• Permisos por rol. Socios, abogados, abogados en prácticas y personal administrativo tienen perfiles distintos: qué modelos pueden usar, qué colecciones documentales pueden consultar, quién puede guardar conversaciones.
• Mínimo privilegio también para la aplicación. El backend solo puede invocar los modelos y perfiles de inferencia aprobados, y solo con el guardrail del despacho aplicado.
• Cuenta root protegida. MFA por hardware, ningún uso operativo, procedimiento de acceso de emergencia documentado.

4. Datos personales y secreto profesional: minimizar antes del modelo

El dato más seguro es el que el modelo nunca recibe. Para la mayoría de las tareas (resumir un contrato, revisar una cláusula, estructurar un escrito) el modelo no necesita saber cómo se llama el cliente.

Seudonimización reversible. Antes de cada llamada, una capa de aplicación que se ejecuta en la cuenta del despacho sustituye los identificadores por marcadores coherentes: [PERSONA_1], [SOCIETA_2], [CF_1]. Nombres, códigos fiscales italianos (codice fiscale), números de IVA (partita IVA), IBAN, correos electrónicos, teléfonos, direcciones, matrículas, números de registro judicial. La tabla de correspondencias permanece solo en memoria durante la solicitud y sirve para recomponer la respuesta: el abogado lee el texto con los nombres reales, el modelo nunca los ha visto.

Cuando una tarea requiere realmente los datos reales (por ejemplo, la redacción final de un escrito), el usuario puede desactivar la seudonimización para esa solicitud: la decisión es consciente y queda registrada en la auditoría.

Bedrock Guardrails como segunda línea. Por encima de la seudonimización, un guardrail aplicado tanto a la entrada como a la salida:

• filtros de datos sensibles que enmascaran o bloquean los tipos de PII reconocidos;
• expresiones regulares personalizadas para formatos italianos, donde el reconocimiento automático genérico es menos fiable: codice fiscale, partita IVA, IBAN italiano, números de registro judicial (numeri di RG);
• filtro contra prompt attacks, importante porque los usuarios suben documentos de terceros que podrían contener instrucciones ocultas (prompt injection);
• control de grounding en las respuestas basadas en los documentos del despacho, para reducir las respuestas que las fuentes no respaldan.

El guardrail no es opcional: la política IAM deniega cualquier invocación del modelo que no incluya el guardrail del despacho, mediante la condition key bedrock:GuardrailIdentifier.

Un ejemplo del patrón utilizado para el codice fiscale:

\b[A-Z]{6}[0-9LMNPQRSTUV]{2}[ABCDEHLMPRST][0-9LMNPQRSTUV]{2}[A-Z][0-9LMNPQRSTUV]{3}[A-Z]\b

Categorías especiales y datos penales. Los tratamientos que implican datos de salud (art. 9 RGPD) y datos relativos a condenas e infracciones penales (art. 10 RGPD) se mapearon por separado en la EIPD, con reglas de uso específicas.

5. Red privada y cifrado

• Nada pasa por internet. Las llamadas a Bedrock, S3 y KMS pasan por VPC interface endpoints (AWS PrivateLink). La aplicación se ejecuta en subredes privadas.
• Credenciales inútiles fuera del perímetro. Las políticas solo permiten invocar Bedrock a través del endpoint privado del despacho (condición aws:SourceVpce): incluso una credencial robada no funciona desde fuera.
• Cifrado en tránsito con TLS 1.2 o superior, y las solicitudes no cifradas se rechazan a nivel de bucket (aws:SecureTransport).
• Cifrado en reposo con claves del despacho. Documentos, índice vectorial, conversaciones guardadas, logs y trails se cifran con claves KMS gestionadas por el cliente, con rotación automática y key policies que separan a quien administra las claves de quien las usa. Revocar una clave deja los datos ilegibles.
• Bloqueo del acceso público activo a nivel de cuenta en todos los buckets S3.
• Opción External Key Store. Para los requisitos más estrictos, la arquitectura está preparada para mantener las claves en un HSM externo a AWS (XKS), evaluado en el análisis de transferencias.

6. Documentos del despacho y murallas éticas

El verdadero valor llega cuando Claude puede trabajar con los documentos del despacho: modelos de escritos, dictámenes anteriores, contratos tipo, jurisprudencia recopilada a lo largo de los años.

• Bedrock Knowledge Bases sobre buckets S3 en la UE, con un modelo de embeddings multilingüe ejecutado en Bedrock en la UE e índice vectorial cifrado.
• Metadatos en cada documento: asunto, cliente, equipo asignado, nivel de confidencialidad.
• Murallas éticas aplicadas en el servidor. Cada búsqueda se filtra según los grupos del usuario leídos de la identidad SSO, no del texto de la pregunta. Un abogado que no está asignado a un asunto no puede recuperar sus documentos, ni siquiera pidiéndolos explícitamente. Es el mismo principio con el que el despacho gestiona los conflictos de intereses y la confidencialidad interna, trasladado al sistema de IA.
• Fuentes citadas en cada respuesta, con enlace al documento original, para que la verificación sea inmediata.
• Borrado coherente. Cuando se elimina un documento o se archiva un expediente, la sincronización lo elimina también del índice. Las reglas de conservación siguen las del expediente.

7. Trazabilidad sin archivar los contenidos

Hay que poder responder a "quién ha usado el sistema, cuándo y en qué asunto" sin crear un segundo archivo de datos confidenciales.

• AWS CloudTrail a nivel de organización, en todas las regiones, con validación de la integridad de los archivos y almacenamiento en una cuenta de logs separada en buckets con Object Lock (no modificables ni borrables durante el periodo definido).
• Auditoría de aplicación solo con metadatos: usuario, hora, modelo, asunto, número de tokens, posible intervención del guardrail (el tipo, no el texto), desactivación de la seudonimización.
• Control continuo de la configuración con AWS Config, Security Hub y GuardDuty: si alguien intenta activar el registro de contenidos, crear una clave permanente, desactivar CloudTrail o abrir un bucket, salta una alerta.
• Costes asignados por área mediante application inference profiles con etiquetas, útiles también para saber quién usa realmente la herramienta.

8. Gobernanza de la cuenta y papel de Rayo

• AWS Organizations con cuentas separadas para la carga de trabajo de IA, los logs y la seguridad: quien administra la aplicación no puede tocar los logs de auditoría.
• La cuenta es del despacho. Rayo opera mediante un rol entre cuentas con acceso temporal, aprobado y registrado. Rayo no tiene acceso al contenido de las conversaciones ni a los documentos.
• Rayo como encargado del tratamiento con contrato conforme al art. 28 RGPD, solo para las actividades de gestión técnica.
• Infraestructura como código. Toda la configuración está versionada y es revisable: cada cambio tiene un autor, una fecha y un motivo, y el entorno puede reconstruirse de forma idéntica.
• Presupuestos y cuotas con umbrales de alerta, para evitar sorpresas en la factura y detectar usos anómalos.

9. El marco normativo, punto por punto

Norma	Obligación	Cómo se cubre
RGPD art. 5 y 25	Minimización, protección de datos desde el diseño y por defecto	Seudonimización, zero retention, historial desactivado por defecto
RGPD art. 28	Contrato con los encargados	DPA de AWS, contrato del art. 28 con Rayo
RGPD art. 30	Registro de actividades de tratamiento	Entrada específica para el asistente de IA, con finalidades, categorías de datos y medidas
RGPD art. 32	Seguridad del tratamiento	Cifrado, MFA, mínimo privilegio, red privada, monitorización
RGPD art. 33 y 34	Gestión de brechas de datos	Alertas automáticas y procedimiento de notificación en 72 horas
RGPD art. 35	Evaluación de impacto	EIPD completa, con las medidas técnicas documentadas
RGPD art. 9 y 10	Datos de salud y penales	Reglas de uso específicas y controles reforzados
RGPD capítulo V	Transferencias fuera de la UE	Tratamiento en la UE, Data Privacy Framework y cláusulas tipo, evaluación de impacto de la transferencia
Código deontológico de la abogacía italiana (Codice deontologico forense), art. 28	Reserva y secreto profesional	Perímetro cerrado, murallas éticas entre asuntos, ningún acceso del proveedor del modelo
Ley italiana 132/2025, art. 13	Uso de la IA en las profesiones intelectuales solo como apoyo e información al cliente	Resultados siempre marcados como borrador, cláusula en la hoja de encargo, información a los clientes
AI Act, art. 4	Alfabetización en materia de IA	Formación obligatoria para todos los usuarios antes de la activación
AI Act, clasificación	Verificación del nivel de riesgo	Uso de apoyo documentado como no de alto riesgo, reevaluado en cada nuevo caso de uso

10. Lo que la tecnología no puede hacer sola

Una configuración perfecta no basta si quien la usa no sabe lo que está haciendo. El proyecto incluyó además:

• Política de uso interna: qué se puede introducir, cuándo desactivar la seudonimización, cómo verificar las fuentes, qué no delegar nunca.
• Formación para socios, asociados, abogados en prácticas y personal administrativo: alucinaciones, verificación de citas, riesgos de prompt injection en documentos de terceros.
• Supervisión humana obligatoria. Cada resultado es un borrador. La firma y la responsabilidad siguen siendo del abogado, como establece la ley.
• Información a los clientes y una cláusula en la hoja de encargo que explica de forma sencilla qué herramientas de IA se usan y con qué garantías.
• Revisión periódica de la configuración y de la EIPD con cada nuevo modelo o nueva funcionalidad.

La checklist completa

Todo lo que verificamos antes de dar acceso al primer usuario:

Datos y conservación

• Model invocation logging desactivado y bloqueado mediante SCP
• Sin historial por defecto, TTL en las conversaciones guardadas
• Logs de aplicación sin contenidos, retención configurada en cada log group
• Ningún dato guardado en el navegador
• Búsqueda web, herramientas externas, marketplace y fine-tuning desactivados

Residencia

• Solo perfiles de inferencia eu., perfiles global. prohibidos
• SCP que deniega las regiones fuera de la UE
• S3, índice vectorial, KMS, logs y copias de seguridad en la UE

Identidad

• SSO con el proveedor de identidad del despacho y MFA obligatoria
• Aprovisionamiento y desaprovisionamiento automáticos mediante SCIM
• Sin usuarios IAM, sin access keys permanentes, API keys de Bedrock prohibidas
• Permisos por rol y mínimo privilegio en la aplicación
• Cuenta root protegida con MFA por hardware

Minimización

• Seudonimización reversible antes del modelo
• Guardrail obligatorio en entrada y salida, impuesto mediante IAM
• Patrones personalizados para codice fiscale, partita IVA, IBAN y números de registro judicial
• Filtro contra prompt attacks y control de grounding

Red y cifrado

• PrivateLink para Bedrock, S3 y KMS
• Invocación permitida solo desde el endpoint privado
• TLS obligatorio, acceso público a S3 bloqueado
• Claves KMS gestionadas por el despacho con rotación automática

Documentos

• Metadatos por asunto, cliente, equipo y confidencialidad
• Filtros de acceso en el servidor basados en la identidad SSO
• Citación de fuentes y borrado sincronizado

Auditoría y gobernanza

• CloudTrail de organización con Object Lock en una cuenta separada
• Auditoría de aplicación solo con metadatos
• AWS Config, Security Hub y GuardDuty con alertas
• Infraestructura como código, presupuestos y cuotas
• Acceso de Rayo temporal, registrado y sin visibilidad de los contenidos

Documentación y personas

• EIPD, registro de actividades de tratamiento, análisis de transferencias
• Contrato del art. 28 con Rayo
• Política de uso interna y formación conforme al art. 4 del AI Act
• Información a los clientes y cláusula en la hoja de encargo

Resultados

• Fin de la IA "en la sombra". Las cuentas personales se dieron de baja: todo el despacho usa una única herramienta, bajo el control del despacho.
• Cumplimiento demostrable. Para cada obligación existe una configuración precisa, verificable y documentada en la EIPD. Si la autoridad italiana de protección de datos (Garante) o un cliente pregunta "¿adónde van mis datos?", la respuesta es una página, no una promesa tranquilizadora.
• Ningún nuevo archivo de datos confidenciales. El sistema produce borradores, resúmenes y revisiones, y no retiene nada más allá de lo que decide el despacho.
• Revocación instantánea. Un asociado que se marcha pierde el acceso en el mismo momento en que se desactiva su cuenta corporativa.
• Controles que no se pueden eludir. Las protecciones más importantes se imponen a nivel de organización: no dependen de la buena voluntad de quien administra la cuenta.

Stack tecnológico

Ámbito	Tecnologías
Modelo	Claude en Amazon Bedrock (perfiles de inferencia UE)
Identidad	AWS IAM Identity Center, SSO federado, SCIM, MFA
Protección de datos	Capa de seudonimización a medida, Amazon Bedrock Guardrails
Documentos	Amazon Bedrock Knowledge Bases, Amazon S3, índice vectorial cifrado
Red	Amazon VPC, AWS PrivateLink
Cifrado	AWS KMS con claves gestionadas por el cliente
Auditoría y seguridad	AWS CloudTrail, S3 Object Lock, AWS Config, Security Hub, GuardDuty
Gobernanza	AWS Organizations, Service Control Policies, infraestructura como código

En resumen

Usar Claude en un despacho de abogados de forma conforme no exige renunciar al mejor modelo, exige construir a su alrededor el perímetro adecuado. Zero retention, datos en la UE, identidades individuales, minimización, cifrado con claves propias, murallas éticas y auditoría: ninguno de estos puntos basta por sí solo. Juntos convierten una IA potente en una herramienta que un despacho puede usar con expedientes reales, y defender ante cualquiera que le pida cuentas.