IA explicable en sistemas de seguridad… la última vez que revisábamos una detección en nuestro sistema de control de accesos, no sabíamos por qué se había activado una alerta falsa.
¿Te ha pasado algo parecido? Esa incertidumbre —¿por qué el modelo ve lo que ve?— es justo lo que nos pone en rojo.
IA explicable es fundamental cuando el objetivo es mantener sistemas seguros, confiables y auditables. Sin explicaciones claras, los ingenieros, técnicos o gerentes de proyectos perdemos visibilidad, y eso puede abrir fisuras de seguridad, generar falsos positivos/negativos, o complicar investigaciones forenses tras un incidente.
En este artículo, vamos a ver por qué insistimos tanto en este tema, cómo se aplica en proyectos reales del mundo de acceso físico, CCTV, BMS o ciberseguridad; lo que exige la normativa y hacia dónde va todo esto.
¿Qué es IA explicable y por qué debería importarte en seguridad?
En uno de los proyectos con lectores biométricos (reconocimiento facial y térmico), tuvimos un caso raro: a un técnico le negó el acceso tres veces seguidas.
El sistema no fallaba, pero tampoco quedaba claro qué lo bloqueaba. Al revisar las explicaciones del modelo, vimos que los reflejos en sus lentes estaban marcados como “inconsistencias faciales”.
No era un error del todo, pero sí un exceso de sensibilidad. Ajustamos el umbral y esa semana los falsos positivos bajaron casi un 30 %. Sin explicabilidad, ni cuenta nos dábamos.
Otro caso, en una instalación logística con más de 80 cámaras, los falsos positivos por movimientos no humanos (reflejos, mascotas, vibraciones) saturaban el centro de monitoreo.
Al aplicar un modelo explicable con SHAP y contrafactuales, pudimos ajustar los pesos asignados a cada variable. ¿Resultado? Una reducción del 40 % en alertas falsas y un 25 % menos de tiempo en revisiones manuales por parte del personal de seguridad.
Eso, además de mejorar la precisión, alivió bastante la carga operativa.
¿Cómo integrar IA explicable en seguridad sin complicarse demasiado?
¿Qué técnicas se usan en la práctica —SHAP, LIME— y cómo encajan en CCTV o accesos?
Te cuento cómo lo hacemos:
- LIME, por ejemplo, lo usamos cuando queremos saber qué partes de una imagen facial influyeron más en una decisión. Te marca zonas tipo “nariz”, “contorno ocular” o incluso sombras que el modelo consideró claves.
- SHAP es más completo para entradas combinadas. En un sistema donde teníamos sensores + cámaras + tarjetas, SHAP nos mostró que muchas veces el sensor de vibración pesaba más que la cámara. Algo que no esperábamos.
Ambos sirven, pero no son plug & play. LIME es más rápido, SHAP es más exacto pero más pesado. Elegir depende si querés interpretar un solo evento puntual o entender patrones globales.
| Técnica | ¿Dónde rinde mejor? | Lo bueno | Lo que molesta |
|---|---|---|---|
| LIME | Visual (facial, CCTV, térmica) | Rápido y bastante claro | Si cambia un pixel, te da otra explicación… eso confunde |
| SHAP | Entradas mixtas (sensores + datos + video) | Pone peso real a cada variable | Más pesado… no va bien en equipos con poco procesamiento |
¿Cómo se conecta con CCTV, BMS o ciberseguridad sin romper nada?
En campo, todo está pegado con alambre: BMS, cámaras, controladores… Por eso, más que reemplazar, la IA explicable se mete como capa de análisis.
Un ejemplo real:
- En un BMS de planta química, teníamos muchas alarmas por temperatura. Gracias a las explicaciones vimos que el patrón venía de un sensor mal calibrado.
- En CCTV, nos pasaba que una cámara de pasillo activaba alarmas por reflejos de luces LED. El modelo decía “movimiento”, pero SHAP mostró que la luz pesaba más que la figura.
Eso nos ayudó a ajustar sin cambiar hardware. Solo se afinó el análisis.
¿Y la normativa? ¿Qué tanto exigen?
Te lo piden, sí. No con nombre y apellido, pero te tiran la indirecta.
- En ISO/IEC 27001 y la 31000, piden trazabilidad en decisiones automáticas. O sea, si una IA bloquea algo, hay que poder explicar por qué.
- El NIST, en sus guías de IA confiable, ya habla directo de “explicabilidad post-hoc” y validación regular.
- En inspecciones, nos han pedido “¿Dónde están los registros del modelo?”. Si no tenés logs explicables, la auditoría te lo marca.
¿Qué se viene en explicabilidad para seguridad?
Lo que se ve venir en proyectos nuevos:
- Contrafactuales: te dicen “si el dato X hubiera sido distinto, no saltaba la alarma”. Es oro para afinar alertas sin tocar reglas.
- Modelos simbólico-neuro: se está usando para que el sistema tenga reglas claras (“si pasa esto y esto, entonces alerta”), pero también aprenda patrones. Menos caja negra —es decir, menos modelos que te dan una respuesta sin explicar cómo llegaron a ella—.
- Explicabilidad en tiempo real: algunos VMS y BMS nuevos ya traen paneles donde la IA te dice en vivo qué variable activó qué evento. Ideal en entornos críticos, donde un segundo importa.
Preguntas que siempre nos hacen
¿No hace más lenta la detección?
Un poco sí, pero compensa: menos falsas alarmas, menos tickets de soporte.
¿Se puede usar con sistemas viejos?
Sí. Montas una capa externa que analiza lo que sale del modelo actual. Nada invasivo.
¿Dónde guardas las explicaciones?
En logs del SIEM o dentro del BMS. Pero sí o sí con timestamps y relación al evento.
¿Y si mi modelo no da explicación?
Lo envuelves con LIME o SHAP, o cambias a uno más interpretable. No hay muchas vueltas.
En conclusión
No esperes a descubrir una intrusión clásica. Tener IA explicable te permite responder: “¿por qué pasó esto?” con datos, no con suposiciones. La próxima vez que una alarma se dispare por razones “misteriosas”, tendrás herramientas reales para entender y corregir, no solo reaccionar.
Te invito a comentar si ya has enfrentado falsos positivos difíciles de explicar, o si te gustaría un ejemplo adaptado a tu sistema.
Deja una respuesta