Configurar políticas de detección y niveles de severidad
Cómo diseñar, escalonar y desplegar las políticas de detección de Zeuslock sin perder la confianza del operador — desde Monitor inicial hasta Block.
El modelo de política en un párrafo
Cada política de Zeuslock es una matriz de tipos de hallazgo (lo que se ha detectado) cruzada con acciones (qué hacer al respecto). Para cada tipo de hallazgo, usted elige una acción entre tres: Monitor registra el evento y reenvía el prompt intacto; Anonymize reescribe el valor sensible en sitio mediante una redacción que preserva el formato antes de que el prompt salga del dispositivo; Block rechaza la petición y muestra al usuario una explicación integrada. Las acciones se asignan por tipo de hallazgo, por grupo y opcionalmente por destino. No existe un interruptor global de forma intencionada.
Categorías de hallazgos sobre las que actuar
Zeuslock incluye detectores en cinco familias. Usted asigna una acción a cada una de forma independiente.
- Credenciales —
api_key(AWS AKIA, Stripe sk_, OpenAI sk-, Azure, Google/Gemini, GitHub ghp_, Slack xoxb-, GitLab glpat-, npm npm_, tokens Bearer),password,jwt,private_key,connection_string,env_variable. - Financiero —
credit_card(validado por Luhn),IBAN,crypto_wallet. - Datos personales —
email,phone, DNI/NIE en formato compatible, NIR francés, SSN estadounidense,passport, dirección postal,ip_address. - Código fuente — detección heurística de código propietario pegado, con huella de lenguaje.
- Identificadores organizativos — sus detectores personalizados (nombres en clave de proyectos, identificadores internos de clientes, objetivos de M&A). Consulte la guía para desarrolladores sobre detectores personalizados para el flujo completo de creación.
Niveles de severidad y cómo se asignan
La severidad se calcula en el momento de la detección a partir de tres señales: el riesgo intrínseco del tipo de hallazgo, las heurísticas contextuales alrededor de la coincidencia (tokens circundantes, estructura del prompt, destino) y la puntuación de confianza del detector. Puede sobrescribir el mapeo por defecto por tipo de hallazgo, pero recomendamos mantener los valores por defecto durante el primer mes.
| Severidad | Significado | Disparadores típicos | Acción por defecto |
|---|---|---|---|
| Crítica | Secreto activo o identificador regulado con alta confianza | private_key, par AWS AKIA + secreto, credit_card válido, NIR | Block |
| Alta | Probablemente sensible, confirmación parcial | Token Bearer, contraseña en estructura clave/valor, IBAN | Anonymize |
| Media | Sensible pero recuperable, o menor confianza | Combinación email + teléfono, patrón de pasaporte, forma genérica de API key | Anonymize |
| Baja | Informativo, a menudo con riesgo de falso positivo | email aislado, ip_address, identificador público | Monitor |
El despliegue que recomendamos
No empiece con Block. Las dos primeras semanas de cualquier despliegue DLP le enseñan lo que su organización pega realmente en ChatGPT, Claude y Gemini — y la respuesta casi siempre es más variada de lo que el equipo de seguridad había previsto. Escalone el despliegue en tres fases.
- Semanas 1-2 — Monitor en todo. Ponga cada tipo de hallazgo en Monitor. Revise el panel de Incidentes a diario. Afine los detectores personalizados. Identifique los tipos de hallazgo ruidosos propios de su entorno.
- Semanas 3-5 — Anonymize en finanzas y datos personales. Cambie
credit_card,IBAN,email,phone,passport,SSN,NIRy direcciones postales a Anonymize. La redacción que preserva el formato envía al LLM aguas abajo un valor estructuralmente válido, así que los flujos de trabajo de los usuarios no se rompen. - Semana 6 en adelante — Block en credenciales y código fuente. Cambie
api_key,password,jwt,private_keyy código fuente a Block. A estas alturas los usuarios han visto suficientes avisos de Anonymize para entender por qué Zeuslock rechaza, y su tasa de falsos positivos es lo bastante baja como para que los bloqueos se acepten sin fricción.
No empiece nunca con Block. Las políticas Block desde el primer día generan tickets airados, empujan a los usuarios a sus dispositivos personales y queman el capital político que necesita para desplegar el resto del programa. Monitor primero. Siempre.
Sobrescrituras por grupo
Una sola política raramente sirve para toda la empresa. Los desarrolladores pegan claves de API y código en Copilot todo el día; el equipo comercial pega listas de clientes en ChatGPT para redactar correos; finanzas pega IBAN en Gemini para conciliar. Cada grupo necesita una postura distinta.
- Vaya a
Settings → Policies → Groups. - Elija el grupo SCIM (o cree un grupo manual) y pulse Override default policy.
- Verá la misma matriz que la política por defecto, con flechas de herencia junto a cada celda. Las celdas que no toque seguirán heredando de la política por defecto — así que cuando cambie el valor por defecto más tarde, esas celdas se actualizarán automáticamente.
- Guarde la sobrescritura. Se aplica en el siguiente prompt; no hace falta reiniciar el cliente.
Un patrón habitual: los desarrolladores reciben Anonymize en api_key (con claves falsas estructuralmente válidas para que sus fragmentos de código se parseen), mientras que el resto recibe Block.
Excepciones por franja horaria
El riesgo no es constante a lo largo del día. Los prompts fuera del horario laboral hacia herramientas de IA de consumo son estadísticamente más propensos a ser exfiltración o proyectos personales descuidados. En Settings → Policies → Schedules, adjunte una variante más estricta a las horas no laborables — por ejemplo, eleve Anonymize a Block en credenciales entre las 20:00 y las 07:00 hora local, y los fines de semana. Los horarios respetan la zona horaria de cada usuario desde su perfil SCIM.
Sobrescrituras por destino
No todas las herramientas de IA merecen el mismo nivel de confianza. Recomendamos tres niveles.
- LLM internos validados (un Mistral autoalojado, un despliegue Azure OpenAI dentro de su tenant) — relaje a Monitor en PII y finanzas, mantenga Block en credenciales.
- Herramientas comerciales validadas (ChatGPT Enterprise, Claude for Work con DPA firmado) — aplique su política por defecto.
- Herramientas no autorizadas o de alto riesgo (DeepSeek, Poe, cualquier herramienta señalada por la detección Shadow AI) — suba todo un nivel. Anonymize pasa a Block, Monitor pasa a Anonymize. Zeuslock informa automáticamente al CISO el primer uso de cualquier herramienta no autorizada.
Detectores personalizados
Los detectores personalizados permiten capturar identificadores organizativos — nombres en clave de proyectos internos, nombres de objetivos M&A, formatos de ID de empleado, números de referencia de cliente. Participan en el mismo modelo de severidad que los detectores integrados y se les puede asignar cualquiera de las tres acciones. El flujo completo de creación, incluida la herramienta de backtest sobre los últimos 30 días de tráfico, vive en la guía para desarrolladores.
Pruebe cada cambio de política con dry-run
Antes de activar un cambio, ejecútelo en modo dry-run. Zeuslock reproduce las últimas 24 horas de prompts a través de la política propuesta y le muestra exactamente qué se habría bloqueado, anonimizado o registrado — por usuario, por grupo, por destino. Si el dry-run muestra 400 nuevos bloqueos sobre el equipo legal por un falso positivo de Bearer en sus plantillas de contrato, usted se entera antes que ellos. Active únicamente cuando el informe dry-run coincida con su intención.
Qué vigilar durante el primer mes
- El panel de Incidentes, a diario, filtrado por Crítica y Alta.
- La cola de Falsos positivos — todo lo que se señale aquí alimenta el ajuste de detectores.
- Informe Shadow AI — nuevas herramientas que aparecen en su entorno.
- Tasas de bloqueo por grupo — si un grupo genera 10 veces más bloqueos que otro, probablemente la política necesita una sobrescritura, no un sermón.