IA para ciberseguridad
El problema de un equipo de seguridad no es que falten alertas: es que hay tantas que las importantes se pierden. El triaje automático ayuda con eso, y solo si su tasa de falso negativo está medida antes de dejarlo filtrar.
En resumen
La métrica que decide todo acá es el falso negativo: cuántas alertas reales habría descartado el sistema. Se mide sobre incidentes históricos antes de dejarlo filtrar nada.
Un triaje que reduce el ruido un 80% y se come un incidente real hizo daño, no ahorro. Por eso el orden es medir primero, automatizar después.
Donde rinde sin discusión es en resumir y correlacionar: juntar señales de varias fuentes en un relato legible para que el analista decida más rápido, sin quitarle la decisión.
No reemplazamos un centro de operaciones de seguridad y no lo vendemos así. Le quitamos la parte de leer y ordenar, que es donde se va el turno.
Dónde se pierde un equipo de seguridad
Ninguno de estos se resuelve con más detección. Los cinco son de volumen y de contexto.
- La consecuencia no es cansancio: es que las importantes se pierden entre las que no lo son.
- Cuando la mayoría de lo que suena no es nada, el equipo empieza a descartar por defecto, y ahí es cuando pasa lo grave.
- El incidente completo solo se ve juntando piezas de tres consolas distintas, a mano.
- El tiempo se va en armar el relato desde los registros, no en decidir qué hacer.
- Y el turno de la noche no lo tiene.
Medir el falso negativo antes de automatizar nada
Un sistema de triaje que reduce el ruido es fácil de construir y fácil de vender: se ve un tablero con un 80% menos de alertas y todo el mundo queda contento. La pregunta que casi nadie hace es qué se fue en ese 80%. Si entre lo descartado había un incidente real, el sistema no ahorró trabajo: creó una brecha con evidencia de que alguien la aprobó.
Por eso el orden no es negociable. Se toman incidentes históricos reales de la organización —los que sí resultaron ser algo— y se corre el triaje sobre ellos como si fueran nuevos. Sale un número: cuántos habría descartado. Ese número se entrega antes de conectar el sistema a nada, y si es distinto de cero se discute qué se automatiza y qué se queda con revisión humana.
Y la separación entre asistir y actuar. Resumir, correlacionar y priorizar no tienen riesgo: el analista sigue viendo todo y decide más rápido. Filtrar y responder sí lo tienen, porque quitan información o ejecutan cambios. Empezamos siempre por lo primero, medimos, y solo entonces se discute lo segundo con límites explícitos.
Los números antes de dejarlo filtrar
| Qué se mide | Qué significa | Por qué manda |
|---|---|---|
| Falso negativo sobre histórico | De los incidentes reales que la organización tuvo, cuántos habría descartado el sistema. | Es la métrica que decide si se automatiza o no. Cualquier otra cifra sin esta es publicidad. |
| Reducción de falso positivo | Cuánto ruido quita, medido solo después de que el falso negativo sea aceptable. | Es el beneficio, pero es el segundo número, nunca el primero. |
| Exactitud del resumen | Sobre una muestra revisada por el equipo: si lo que el sistema dice del incidente está en los registros. | Un resumen que inventa un detalle manda la investigación en la dirección equivocada. |
| Tiempo hasta la decisión | Cuánto tarda el analista en decidir qué hacer, con el sistema y sin él. | Es el ahorro real. «Alertas procesadas» sube solo con el volumen y no dice nada. |
No somos un proveedor de seguridad ni un centro de operaciones. No monitoreamos su red, no hacemos respuesta a incidentes y no reemplazamos las herramientas que ya tiene. Si eso es lo que hace falta, hay firmas especializadas y ese es el camino correcto.
Lo que hacemos es la capa de ingeniería sobre lo que esas herramientas ya producen: correlacionar, resumir, priorizar y medir si ese filtro se está comiendo algo. Y no automatizamos ninguna respuesta —bloqueos, aislamientos— sin límites explícitos aprobados por el responsable de seguridad.
Servicios relacionados
Integraciones y APIs
Servidores MCP contra los sistemas en operación.
Ver servicioAutomatización con IA
Aplicada donde hay volumen y reglas estables, no donde hay expectativa.
Ver servicioConsultoría de IA
Arquitectura, criterios de evaluación y costo por consulta antes de escribir código.
Ver servicioDesarrollo de software
El sistema alrededor del modelo, no solo el modelo.
Ver servicioMás del blog
Preguntas frecuentes
¿Esto reemplaza a nuestro SOC o a nuestras herramientas?
No, y no lo vendemos así. No monitoreamos su red, no hacemos respuesta a incidentes y no sustituimos el SIEM ni el EDR que ya tenga. Trabajamos sobre lo que esas herramientas producen: correlacionamos señales entre ellas, resumimos el incidente en un relato legible y priorizamos, para que el analista dedique el turno a decidir en vez de a leer y ordenar.
¿Cómo saben que el filtro no se come una alerta real?
Se mide sobre incidentes históricos de la organización antes de conectar nada. Se toman los casos que sí resultaron ser algo, se corre el triaje como si fueran nuevos, y se cuenta cuántos habría descartado. Ese número se entrega primero, antes que cualquier cifra de reducción de ruido. Si es distinto de cero, se discute qué se automatiza y qué se queda con revisión humana, y esa conversación la tiene el responsable de seguridad, no nosotros.
¿Puede responder automáticamente a un incidente?
Técnicamente sí, y recomendamos no empezar por ahí. Una respuesta automática —bloquear una cuenta, aislar un equipo— tiene costo operativo cuando se dispara sobre un falso positivo, y ese costo lo paga el negocio. Empezamos por asistir: resumir, correlacionar y priorizar, que no tienen riesgo. La automatización de respuesta se discute después, con el falso negativo medido y con límites explícitos aprobados por escrito.
¿Con qué herramientas se integra?
Con el SIEM, el EDR y las fuentes de registro que ya tenga, por API o servidor MCP. No pedimos cambiar de herramientas: la propuesta es exactamente la contraria, sacarle más a lo que ya está instalado y pagado. Si la organización no tiene todavía una fuente central de registros, ese es el primer proyecto y no es este.
¿Los datos de seguridad salen de nuestra infraestructura?
No, si ustedes no lo aceptan, y en este dominio casi nunca se acepta. Desplegamos sobre Azure OpenAI o Amazon Bedrock dentro de la suscripción de la organización, así que los registros y las alertas no salen de su nube. En cualquier configuración usamos planes empresariales donde lo enviado por API no se usa para entrenamiento, y filtramos identificadores antes de la inferencia cuando el caso lo exige.
¿Cuánto tarda y cómo se cotiza?
La medición sobre incidentes históricos toma una semana y se puede contratar sola, como diagnóstico. Un sistema de correlación y resumen en producción, de cuatro a ocho semanas según las fuentes que haya que conectar. Se cotiza con alcance, precio y fecha cerrados en una propuesta a 48 horas de la primera llamada, y el costo del diagnóstico se descuenta si se sigue al proyecto.
Agendar 15 minutos
Una llamada para poner sobre la mesa qué se está construyendo o qué dejó de funcionar. Termina con una respuesta concreta: se arregla, se construye, o no vale la pena.