Protección de datos

Los modos de detección, la biblioteca de 60 detectores, la detección de entidades y sus modelos a elegir, el análisis de seguridad, el aviso al modelo y la retención.

La protección de datos se ejecuta en cada petición antes de despachar. El modo por defecto es tokenize: cada valor detectado se sustituye por un token tipado estable como «EMAIL_1». Solo los tokens llegan al proveedor, y la respuesta se restaura a los valores reales de vuelta hacia usted, en streaming o no. El mapa de tokens vive en memoria durante la vida de la petición y nunca se persiste.

# tokenize mode (the default): what you send
curl https://api.sluis.ai/v1/chat/completions \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "sluis/auto", "messages": [{ "role": "user",
        "content": "Mail j.devries@acme.nl that IBAN NL91ABNA0417164300 is active." }] }'

# what the model provider receives — only stable typed tokens
{ "role": "user",
  "content": "Mail «EMAIL_1» that IBAN «IBAN_1» is active." }

# what you get back — restored at the single client egress, streaming included
{
  "choices": [{
    "message": {
      "role": "assistant",
      "content": "Draft: Dear j.devries@acme.nl, your account NL91ABNA0417164300 is active…"
    }
  }]
}

Otros modos: mask reescribe los valores detectados de forma irreversible, block rechaza la petición con 422, y allow_log la deja pasar mientras marca la fila de auditoría.

60 detectores integrados vienen de serie: 28 para datos personales, del número de la Seguridad Social de EE. UU. a un paquete de identificadores nacionales de 12 países de la UE validados por suma de control, y 32 para secretos y credenciales. Cada uno se puede activar o desactivar por organización, y los términos personalizados (texto plano o regex) cubren cualquier cosa específica de su negocio:

Detección de entidades

Personas, organizaciones y ubicaciones son difíciles de detectar solo por patrón. Sluis añade cinco capas opcionales: heurísticas de contexto (tratamientos, saludos, firmas; solo personas), correlación de correo (deriva nombres de las direcciones en el mismo texto), un directorio de nombres del inquilino, un diccionario de nombres incluido y NER: un modelo de reconocimiento operado por Sluis como sidecar interno a la red, de modo que el texto nunca sale del perímetro del despliegue para ser analizado. NER encuentra personas, organizaciones y ubicaciones en prosa libre.

El diccionario de nombres es la contraparte determinista del NER: nombres de pila y apellidos compilados a partir de datos abiertos de administraciones públicas en un diccionario incluido en la pasarela. Detecta nombres completos y nombres precedidos de un tratamiento, sin latencia añadida y sin que nada salga de su perímetro. Los nombres que también son palabras corrientes solo se detectan con contexto con forma de nombre; los nombres poco frecuentes siguen siendo tarea del directorio o del NER.

Modelos NER a elegir

Dos niveles equilibran latencia y tasa de detección: swift (spaCy xx_ent_wiki_sm) responde en milisegundos de un dígito con cobertura multilingüe básica; deep (GLiNER2-PII sobre base mDeBERTa-v3, Apache-2.0) detecta bastante más, con una latencia mayor por segmento analizado. Elija por organización en Políticas → Protección de datos; una clave puede elegir otro modelo mediante sus option overrides, pero nunca puede activar la capa cuando la organización la mantiene desactivada.

Medido el 2026-08-12 en un benchmark interno: frases de prueba de WikiANN en seis idiomas (NL, EN, DE, FR, ES, IT; 150 por idioma), puntuadas como micro-F1 sobre pares (etiqueta, texto) a nivel de texto con el filtro de falsos positivos de producción aplicado, en una máquina de desarrollo Apple Silicon en FP32. WikiANN es material de Wikipedia con anotación automática y el terreno de entrenamiento de spaCy: lea las cifras como guía relativa entre niveles, no como precisión absoluta en campo.

Análisis de seguridad

Detección opcional de inyecciones de prompt y jailbreaks en la esclusa, analizada antes del despacho. Tres modos: off | log | block. log registra los aciertos en el registro de auditoría sin tocar el tráfico; block rechaza la petición con un 403 permission_error sellado ("request refused: prompt-injection scan flagged this request"). El umbral de disparo se configura por organización, y el análisis falla en abierto: una caída del escáner nunca tumba el tráfico.

El análisis añade unos 20 ms en un prompt corto y unos 620 ms en uno largo (1500 caracteres), medido en un banco de pruebas interno; el peor caso está acotado, porque el escáner limita cuántas ventanas de 512 tokens puntúa por petición. Corre en paralelo con el escaneo NER, así que la latencia añadida combinada se acerca al mayor de los dos, no a la suma. La detección es un clasificador, no una prueba: texto benigno con aspecto de instrucción puede puntuar como inyección, una realidad conocida en todo el sector, y por eso log es el modo inicial recomendado.

Cada acierto se divulga en el registro de auditoría como sec:injection:<score>, así que la revisión no necesita herramientas adicionales. Las desviaciones por clave usan los mismos option overrides que la protección de datos.

Built with Llama. The scan model is Llama Prompt Guard 2 86M (multilingual), used under the Llama 4 Community License.

Por separado, la detección opcional de anomalías del comportamiento de las claves corre como trabajo en segundo plano, sin latencia alguna en las peticiones: líneas base por clave con estadística robusta y estacionalidad hora-de-semana, más una capa multivariante de bosque de aislamiento. Las alertas son explicables, nunca una puntuación desnuda, y llegan a la pestaña Seguridad de la consola, con correo opcional.

Aviso al modelo

Cuando la tokenización reescribió una petición, Sluis inyecta un mensaje de sistema inicial que indica al modelo que los tokens «…» son marcadores opacos que debe mantener intactos; eso es lo que hace fiable la restauración. Activado por defecto; personalícelo o desactívelo por organización.

Retención y fidelidad de auditoría

La retención de contenido (los cuerpos de petición y respuesta para el registro de auditoría) está activada por defecto y cifrada en reposo; la fidelidad de auditoría decide si el contenido retenido guarda los tokens o los valores originales. Desactive la retención para un registro solo de metadatos; eso también desactiva las cachés de respuesta.

Anonimización de documentos

Envíe un archivo docx, pdf, imagen o texto a POST /v1/documents/anonymize y el mismo documento vuelve con los PII y secretos sustituidos por etiquetas como «PERSON_NAME_1» en el texto, y difuminados en imágenes y páginas PDF. El procesamiento es local a la gateway, OCR incluido; la operación se sella en la cadena de auditoría y se factura por página/imagen. El mapa de tokens solo se devuelve si usted lo pide y nunca se almacena. Los PDF censurados conservan una capa de texto invisible y buscable construida a partir del texto anonimizado. Para documentos grandes, encole un trabajo asíncrono y recoja el resultado más tarde con una URL firmada de duración limitada.

La misma protección funciona en tránsito: con la política dlp_documents activa, los archivos subidos por /v1/files y los documentos OCR inline se anonimizan antes de salir hacia un proveedor, se rechazan en modo block y se analizan en modo allow_log.

# enqueue a large document (202 + job id; Idempotency-Key honoured)
curl https://api.sluis.ai/v1/documents/anonymize/jobs \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -F file=@archive.pdf

# poll until succeeded; the signed download_url then needs no API key
curl https://api.sluis.ai/v1/documents/anonymize/jobs/9c31… \
  -H "Authorization: Bearer $SLUIS_KEY"

{
  "id": "9c31…",
  "state": "succeeded",
  "filename": "archive.pdf",
  "summary": { "pages": 12, "images": 3, "categories": ["PERSON_NAME", "EMAIL"], "downgraded": false },
  "download_url": "https://api.sluis.ai/v1/documents/deliverables/9c31…?tenant=…&exp=…&sig=…"
}

Embeddings

Los tokens pseudonimizados son estables dentro de una solicitud, no entre solicitudes; los embeddings de texto tokenizado pueden no coincidir entre llamadas. El ajuste dlp_embeddings controla si el análisis cubre /v1/embeddings: activado por defecto, ponerlo en off envía las entradas de embedding al proveedor sin analizar. Cada llamada exenta queda registrada en el registro de auditoría.

Option overrides por clave

Las anulaciones por cabecera de petición han desaparecido: las desviaciones son configuración de clave permanente y gobernada. Un owner o admin fija option_overrides dispersos en una clave, en la vista API keys de la Consola o mediante POST/PUT /admin/keys: el modo de protección de datos (incluido off), el modelo NER y el modo del análisis de inyecciones. Lo no fijado hereda la política de la organización, y una clave nunca puede activar una capa que la organización mantiene desactivada.

# per-key option overrides are standing key config, set by an owner or admin
curl -X PUT https://api.sluis.ai/admin/keys/{key_id} \
  -H "Authorization: Bearer $SLUIS_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "option_overrides": {
        "dlp": { "mode": "off" },
        "ner_model": "deep",
        "security": { "prompt_injection": { "mode": "block" } } } }'
# sparse: absent fields inherit org policy; every deviation is sealed in the audit trail

La cabecera de petición x-sluis-dlp ha sido eliminada. Una petición que aún la lleve, con cualquier valor, se rechaza con 400 y una referencia a los option overrides de la clave. Cada desviación vigente se divulga en la fila de auditoría sellada, así el registro siempre muestra qué configuración se ejecutó realmente.