IA sin fugas.

En la modalidad Cloud Soberano, el procesamiento ocurre en instalaciones de colocation Tier III certificadas en España. En la modalidad cloud con modelo externo, únicamente se usan regiones de Azure con Zero Data Retention activo: Spain Central y Sweden Central. En ningún caso los datos transitan por centros de datos fuera de la Unión Europea. Para la modalidad On-Premise, el procesamiento ocurre íntegramente dentro del perímetro del cliente.

No, si el despliegue está correctamente configurado. La ruta por defecto prioriza el modelo local. Si el Model Router decide escalar a cloud, solo enruta hacia regiones Azure dentro de la UE con Zero Data Retention, lo que contractualmente impide a Microsoft retener o usar los datos para entrenamiento. El cliente puede restringir por política que ninguna inferencia salga del nodo local.

Los logs de auditoría se almacenan localmente, firmados criptográficamente, y no se replican fuera del perímetro definido en el contrato. Los backups siguen la misma política de residencia que los datos principales. El cliente controla el ciclo de vida de los registros, incluyendo la retención mínima exigida por normativa y el borrado seguro. Se entrega documentación del esquema de backup como parte del onboarding.

La diferencia es arquitectónica, no legal. Un claim de cumplimiento es una declaración; Custody Node es una capa técnica verificable: el dato nunca llega al modelo externo sin pasar por el Data Firewall, y cada inferencia queda registrada con firma. El cliente puede auditar el flujo completo. El cumplimiento de terceros suele depender de sus propios términos de servicio, que pueden cambiar. Aquí la soberanía es una propiedad del sistema, no una promesa contractual unilateral.

Detecta entidades nombradas estructuradas (nombre, DNI/NIF, número de cuenta IBAN, tarjeta, teléfono, email, dirección postal, IP) y entidades contextuales que requieren inferencia semántica (diagnósticos, nombres de expedientes, cargos vinculados a personas). También detecta cuasi-identificadores: combinaciones de atributos que, aunque individualmente no son PII, permiten reidentificación. La precisión varía por idioma y dominio; en castellano jurídico y sanitario el recall supera el 94 % en nuestros benchmarks internos.

Son dos modos distintos con consecuencias legales diferentes. En pseudonimización, cada entidad PII se sustituye por un token ([PERSONA_001]) y el mapping nombre↔token se custodia localmente, cifrado, accesible solo por el cliente. El dato original es recuperable. Bajo RGPD, este dato sigue siendo dato personal, pero el modelo y cualquier tercero solo ven tokens sin significado. En anonimización irreversible, no existe mapping: la entidad se elimina o sustituye por un valor sintético sin posibilidad de reconstrucción. Deja de ser dato personal bajo RGPD.

Usa pseudonimización cuando necesites que la respuesta del modelo sea útil para el caso concreto y luego reconstituirla: por ejemplo, análisis de un contrato donde el nombre de las partes importa para el informe final. Usa anonimización irreversible cuando el objetivo sea estadístico o de entrenamiento, y la identidad individual no sea necesaria. En entornos sanitarios sujetos al ENS o con datos de categoría especial (art. 9 RGPD), la anonimización irreversible reduce drásticamente la superficie de riesgo.

Es una limitación real. Ningún sistema detecta el 100 % de los cuasi-identificadores, especialmente en textos muy específicos de dominio. Custody Node aplica detección estadística de combinaciones de atributos de riesgo, pero no garantiza cobertura total. Lo que sí garantiza es que el operador recibe métricas de entidades detectadas por inferencia y puede configurar umbrales de bloqueo. Para documentos de riesgo alto, recomendamos revisión humana antes del envío.

El nodo local ejecuta modelos open-weights de hasta 70B parámetros sobre hardware NVIDIA GB10 Grace Blackwell con 128 GB de memoria unificada (DGX Spark). Modelos de referencia: Llama 3.1 70B, Mistral Large, Qwen 2.5 72B. Para tareas que requieren mayor capacidad o disponibilidad garantizada, el Model Router puede escalar a Azure OpenAI (GPT-4o) en Spain Central o Sweden Central con Zero Data Retention. La elección entre local y cloud la gobierna una política configurable por el cliente.

El time-to-first-token en el modelo local 70B está entre 1,5 y 3 segundos según carga. La velocidad de generación es de aproximadamente 10-15 tokens por segundo, lo que se traduce en 35-50 segundos para una respuesta de 500 tokens. En cloud (Azure OpenAI Spain Central), el time-to-first-token baja a 300-800 ms con velocidades de generación muy superiores. Para tareas interactivas con respuesta corta, el modelo local es perfectamente viable. Para generación de documentos largos en tiempo real, el cloud ofrece mejor experiencia.

Mediante API REST compatible con el estándar OpenAI Chat Completions, lo que permite reutilizar cualquier cliente o librería existente cambiando únicamente el endpoint base. También se integra con SSO corporativo vía SAML 2.0 u OIDC para gestión de identidad. No se requiere instalar agentes en los equipos de los usuarios. El onboarding técnico estándar para un cliente con infraestructura existente tarda entre 1 y 5 días laborables según complejidad.

El Model Router tiene tres comportamientos configurables: escalar automáticamente a cloud UE, encolar la solicitud con tiempo de espera máximo definido, o rechazar con error controlado. El comportamiento por defecto es escalar a cloud si la política lo permite. Si la política prohíbe cloud, las solicitudes se encolan o rechazan según configuración. El cliente decide qué prioriza: disponibilidad o soberanía estricta. Ambas opciones son auditables en el log.

Cubre directamente las obligaciones del art. 25 (privacidad por diseño y por defecto) y art. 32 (medidas técnicas de seguridad). El Data Firewall actúa como medida técnica documentable ante una DPIA. El Audit Logger proporciona los registros necesarios para demostrar responsabilidad proactiva (accountability). Para el derecho al olvido (art. 17), el sistema soporta eliminación del mapping de pseudonimización asociado a un sujeto. La base legal del tratamiento la determina el cliente; Custody Node actúa como encargado del tratamiento.

Custody Node opera como capa de infraestructura, no como sistema de IA de alto riesgo per se. Ayuda a los clientes que despliegan sistemas de alto riesgo a cumplir los requisitos de trazabilidad (art. 12), supervisión humana (art. 14) y gestión de datos (art. 10) mediante los logs firmados y las políticas de uso. No sustituye la evaluación de conformidad del sistema final, que recae en el deployer. Lo que sí ofrece es evidencia técnica verificable para el expediente de conformidad.

ISO 27001: el servicio opera bajo controles alineados con la norma; la certificación formal está en proceso de auditoría. ENS: aplicable a clientes del sector público español; el despliegue en modalidad dedicada está diseñado para cumplir los controles del ENS nivel Alto, pero la certificación la obtiene el cliente sobre su sistema, no el proveedor de forma independiente. Proporcionamos la documentación técnica necesaria para facilitar ambos procesos. No afirmamos certificaciones que aún no están emitidas.

Se entrega: logs de auditoría firmados por inferencia, DPA (Data Processing Agreement) conforme al art. 28 RGPD, informe técnico de arquitectura del sistema, y registros de acceso a la plataforma. En caso de incidente de seguridad atribuible a Custody Node, se activa el protocolo de notificación en 72 horas conforme al art. 33 RGPD. La responsabilidad sobre el contenido de los prompts y la adecuación del tratamiento a la finalidad recae en el cliente como responsable del tratamiento.