El enriquecimiento automático y lo que se le escapa

El enriquecimiento automático hace lo que un analista haría a mano: consulta fuentes y junta lo que contestan. Lo que cambia es que la plataforma no se detiene a pensar cuando una consulta sale mal. Una fuente puede no responder (se agota el tiempo), responder vacío (no tiene datos), responder con un dato viejo o responder algo que contradice a otra fuente. Cada caso significa una cosa distinta, y los cuatro son distintos de «esta dirección es limpia».

Un playbook bien escrito distingue esos estados en una condición y los trata como lo que son: dato que falta. Uno mal escrito convierte el vacío en un valor por defecto, y casi siempre el valor por defecto es el que deja seguir: «limpio», «sin hallazgos».

En la ejecución de PB-12 sobre la alerta ALR-9021, la plataforma consultó cuatro fuentes. La tabla enriquecimiento dice, para cada una, si respondió y qué usó el playbook para decidir. La señal de que algo se leyó mal es una fila donde esas dos cosas no cuadran: el estado dice que no hubo respuesta y el resultado usado dice que todo está bien.

Un dato puede responder bien y estar viejo. La lista de puestos de la empresa dice a quién pertenece cada uno, y una mudanza o un cambio de turno lo desactualiza en semanas. Por eso la plataforma tiene una política de frescura: cuántos días puede tener un dato de cada fuente para usarse sin confirmación. Se compara la fecha del dato con la fecha de la alerta, y lo que se pasa de ese máximo se marca antes de que decida nadie.

Cruza enriquecimiento con politica_de_frescura. La fecha de la alerta está en alerta.

Hay un riesgo que no está en el enriquecimiento sino en lo que se hace con él: los campos de una alerta no siempre los controla la empresa. El asunto de un correo lo escribe quien lo envía; si el playbook lo copia dentro de otro paso sin validarlo, quien envía el correo decide en parte lo que ese paso hace. Una cosa es que ese texto aparezca en el título de un caso. Otra, muy distinta, es que forme parte de una búsqueda que después actúa sobre buzones.

La revisión de un playbook incluye mirar qué datos de origen externo entran en qué pasos, y si alguien los valida. Lo haces solo leyendo campos_usados.