Investigar incidentes y construir detectores personalizados a partir de hallazgos reales

El panel de incidentes

Cada prompt analizado por la extensión de navegador, el agente de escritorio, el CLI o la capa MCP que produce un hallazgo aterriza en un único sitio: app.zeuslock.ai/incidents. Ahí pasa la mayor parte de su tiempo como operador. El panel está pensado para llevarle de «algo se ha disparado en la última hora» a un ticket cerrado en pocos clics.

En la parte superior de la tabla está la barra de filtros. Cada filtro es de selección múltiple y se combina con los demás:

• Rango de fechas — desde los últimos 15 minutos hasta los últimos 90 días, más una ventana personalizada para auditorías.
• Severidad — Crítica, Alta, Media, Baja. La fija el detector que se disparó, no el usuario.
• Tipo de hallazgo — todas las categorías de detector: api_key, credit_card, IBAN, password, JWT, private_key, source_code, etc.
• Usuario — por correo o por grupo sincronizado vía SCIM.
• Destino — ChatGPT, Claude, Gemini, Copilot, Mistral, Perplexity, DeepSeek o cualquier dominio personalizado capturado por el modo Universal.
• Estado — Abierto, En revisión, Resuelto, Descartado.

Ordene por marca temporal (por defecto), severidad, usuario o destino. El conjunto de filtros activos se codifica en la URL, de modo que puede compartir una vista de triaje con otro analista copiando el enlace.

Leer una tarjeta de incidente

Cada fila de la lista es una tarjeta compacta con todo lo necesario para decidir si abrirla:

• Identidad y grupo del usuario.
• Navegador o cliente de escritorio y sistema operativo.
• URL de origen a la que iba a salir el prompt (p. ej. chat.openai.com).
• Una insignia de severidad de color.
• Chips de tipo de hallazgo — uno por cada detector disparado sobre el mismo prompt.
• Una vista previa redactada del prompt. Los segmentos sensibles se enmascaran al renderizar; el valor en bruto nunca llega a su navegador.
• Marca temporal en su zona horaria de operador.
• Acción aplicada: Monitor, Anonymize o Block.

Abrir un incidente

Pulse una tarjeta para abrir la vista completa. Obtendrá la cronología de todo lo ocurrido, en orden:

1. Detección en el navegador — la capa regex se disparó, con los desplazamientos dentro del prompt y el ID del detector.
2. Confirmación ML opcional — si la política escaló al modelo NER alojado en la UE, verá la puntuación de confianza devuelta y la versión del modelo.
3. Acción — lo que hizo el cliente: dejar pasar, anonimizar en sitio o bloquear con un cartel visible para el usuario.

Bajo la cronología encontrará la regla de detección original (para ver exactamente qué casó), la puntuación de confianza del paso ML y las posiciones a nivel de carácter de cada hallazgo dentro del prompt. Pase el cursor por una posición para resaltarla en la vista previa redactada.

Flujo de triaje

Trate cada incidente como un ticket pequeño. El flujo es deliberadamente corto:

1. Abra el incidente y lea la cronología.
2. Decida: hallazgo real o falso positivo. Pulse Confirmar o Descartar como falso positivo. Los descartes alimentan la cola de ajuste de detectores que revisamos semanalmente.
3. Si es real y necesita seguimiento, asígnelo a un miembro del equipo desde el desplegable Asignado a. El asignado recibe aviso por correo y, si está configurado, por DM de Slack.
4. Hágalo avanzar por los estados: Abierto → En revisión → Resuelto. Cada cambio de estado se escribe en el registro de auditoría con actor, marca temporal y motivo.

Recomendamos una pasada diaria de 15 minutos sobre Crítica y Alta, y un barrido semanal sobre Media. Baja rara vez necesita revisión humana salvo que un patrón aparezca en los informes.

Construir un detector personalizado a partir de un incidente

Lo más valioso que puede hacer en este panel es convertir un hallazgo real recurrente en un detector. Caso clásico: ve repetidamente sus propios identificadores internos de cliente (algo como CUS-12345) saliendo en prompts de ChatGPT. Un detector genérico no los pillará, pero puede crear uno en menos de un minuto.

1. Abra un incidente que contenga el identificador recurrente.
2. En el panel derecho, pulse Crear detector a partir de este hallazgo.
3. Zeuslock propone una regex (p. ej. \bCUS-\d{5}\b), una severidad y una acción sugeridas.
4. Ajuste la regex si hace falta, ponga nombre al tipo de hallazgo (p. ej. internal_customer_id) y elija la acción: Monitor, Anonymize o Block.
5. Pulse Backtest sobre los últimos 30 días. Zeuslock vuelve a ejecutar la regex candidata sobre los últimos 30 días de incidentes (y una muestra de prompts limpios) y le dice cuántas alertas extra habría producido y sobre qué usuarios.
6. Si el nivel de ruido es aceptable, pulse Activar. El detector se distribuye a cada extensión de navegador y agente de escritorio en el siguiente heartbeat de política (menos de 60 segundos).

Etiquetas, evidencia, listas de vigilancia, SIEM

Etiquetar incidentes

Las etiquetas de texto libre en un incidente se conservan en informes y exportaciones. Úselas para lo que el esquema no captura: error-proveedor, rgpd-art-32, revision-t2. Las etiquetas son lo que hace que las revisiones mensuales sigan siendo consultables meses después.

Exportar evidencia

Dos formatos de exportación, desde la barra de herramientas:

• Exportar → CSV sobre una lista filtrada — una fila por incidente, con usuario, destino, tipos de hallazgo, acción, severidad, marcas temporales, etiquetas y asignado. Es lo que suelen pedir los auditores.
• Exportar → PDF sobre un incidente concreto — la cronología, la regla, el prompt redactado, la acción y el rastro de auditoría de asignaciones y cambios de estado. Es el artefacto que adjunta a un ticket de investigación interna.

Listas de vigilancia

En Incidents → Listas de vigilancia, ancle usuarios, grupos o destinos concretos. Las entidades ancladas suben a la parte superior del panel, pueden disparar alertas por correo o Slack y tienen su propio mosaico de KPI. Casos típicos: anclar al equipo financiero durante el cierre trimestral, anclar deepseek.com mientras se cierra una decisión sobre shadow-AI, anclar a un colaborador externo mientras dure el encargo.

Enviar incidentes a su SIEM

Cada incidente puede empujarse a su SIEM en tiempo real. Se dispara un webhook por incidente con un payload JSON, firmado con HMAC-SHA256 para que su colector verifique que viene realmente de Zeuslock. Para la forma del payload, la semántica de reintentos y la verificación de firma, consulte Webhooks e integración con SIEM. Splunk HEC, Microsoft Sentinel y Elastic los consumen sin código a medida.

Cómo se ve un buen triaje

Sabrá que el panel funciona cuando se cumplan tres cosas: su cola de incidentes Abiertos tiene menos de un día de antigüedad, la tasa de falsos positivos por detector baja semana a semana, y la mayoría de incidentes pasan por Anonymize en lugar de Block. Ese último punto es el objetivo: sus usuarios siguen trabajando y sus datos sensibles permanecen donde deben.