Antes, una seguridad madura significaba tener un SOC: analistas por turnos, mirando una pared de monitores y esperando a que saltara una alerta. Ese es el modelo tradicional. Webflow gestiona la detección y respuesta sin necesidad de eso.
Durante años, la premisa en seguridad ha sido clara: los programas maduros de detección y respuesta requerían un SOC (Centro de Operaciones de Seguridad). Un equipo de analistas mirando una pared de monitores a la espera de que se activara una alerta.
Ese modelo tenía sentido cuando la única forma de escalar el juicio humano era contratar a más humanos.
La verdad sobre la IA en el SOC
La conversación sobre la IA en seguridad es, en su mayoría, ruido de proveedores. Cada herramienta promete arreglar un silo del SOC: triaje, enriquecimiento, inteligencia de amenazas. Si compras suficientes, terminas reconstruyendo la misma pila fragmentada, solo que con una etiqueta de IA en cada pieza.
Lo que nadie dice lo suficientemente alto es esto: no hace falta comprar seguridad asistida por IA. Un equipo pequeño, técnico y motivado puede desarrollar estas capacidades internamente, con una integración más estrecha, mejor contexto y mucho más control del que cualquier producto comercial te ofrecerá jamás.
En Webflow, hemos pasado el último año integrando IA en nuestros flujos de trabajo de detección y respuesta. No como una prueba piloto, ni como una demo. En producción, refinada activamente y en constante evolución. Y lo más importante que hemos aprendido es esto:
La IA no cambió lo que significa una buena seguridad. Cambió cuánto puede hacer un solo equipo.
Lo que realmente construimos
El programa de detección y respuesta de seguridad de Webflow está liderado por ingenieros. No hay SOC. No hay analistas dedicados rotando en turnos. Hay un pequeño equipo de ingenieros de seguridad responsables de todo el ciclo de vida: desde escribir y probar detecciones hasta responder a incidentes y mejorar el sistema con el tiempo. Durante mucho tiempo, esto significó priorizar sin piedad, porque es imposible investigarlo todo. Hay que tomar decisiones difíciles.
La IA cambió esas decisiones de dos formas concretas.
1. Un triaje que no empieza de cero
Cada alerta solía empezar igual: abrir el ticket, obtener el contexto, verificar la propiedad del activo, correlacionar la actividad reciente y hacer una evaluación preliminar de la gravedad. El trabajo no es difícil, pero consume mucho tiempo. Hay que iniciar sesión en múltiples plataformas para validar registros en varios sistemas antes de que empiece cualquier investigación real.
Sinceramente, la IA nos obligó a actuar. Cuando vimos un aumento del 200% en las detecciones en un solo trimestre, quedó claro que el viejo modelo —donde cada alerta empezaba de cero y cada triaje se hacía manualmente— no iba a aguantar. Tuvimos que replantear el flujo de trabajo, no solo añadir capacidad.
Ahora usamos IA para realizar el trabajo de ensamblaje antes de que un ingeniero siquiera vea la alerta. Cuando un humano interviene, el ticket ya cuenta con contexto enriquecido, señales históricas relevantes y una evaluación de gravedad preliminar. Y para las alertas que identificamos con alta confianza como falsos positivos, hemos creado mecanismos de cierre automático que resuelven el problema sin intervención humana. No es un atajo; es una decisión arquitectónica deliberada basada en meses de ajuste y validación. Sabemos exactamente qué patrones de alerta cumplen los requisitos para el cierre automático y revisamos esos criterios regularmente a medida que nuestro entorno cambia. Estos pequeños cambios ahorraron a nuestro equipo 504 horas en un solo trimestre.
El ingeniero sigue tomando todas las decisiones importantes. La IA se encarga de la configuración y elimina por completo los falsos positivos evidentes.
Lo que hemos visto en la práctica: un triaje más rápido, menos fatiga por cambio de contexto y investigaciones de mayor calidad, ya que los ingenieros comienzan con una imagen más completa en lugar de tener que construirla desde cero bajo presión.
2. Los LLM como compañeros de investigación
El problema más difícil es la investigación ambigua, esa en la que las señales deben conectarse entre las capas de identidad, terminales y aplicaciones sin un manual que se aplique claramente. Independientemente de la experiencia, a menudo los responsables se quedan pensando: "¿Qué hago ahora?".
Aquí es donde hemos estado experimentando con LLMs con mayor cautela. No para tomar decisiones, sino para reducir la carga cognitiva durante el triaje complejo: resumiendo volúmenes de registros sin procesar, sacando a la luz incidentes pasados similares y sus manuales asociados, sugiriendo los siguientes pasos y redactando cronologías iniciales que un ingeniero luego valida y amplía. El factor humano permanece en el centro de cada punto de decisión importante. No es una limitación que estemos intentando sortear, sino un principio de diseño. La IA presenta, organiza y sugiere. Los ingenieros validan, deciden y actúan. En el momento en que esa frontera se desdibuja, se introduce un riesgo difícil de auditar y aún más difícil de explicar a posteriori.
Somos muy cuidadosos con dónde confiamos en los resultados de la IA y dónde los verificamos de forma independiente. Esa confianza se gana de manera gradual, del mismo modo que nos ganamos la confianza en cualquier nueva lógica de detección antes de dejar que funcione sin supervisión.
3. La IA en el proceso posterior a un incidente
Una de las aplicaciones más subestimadas de la IA en seguridad no tiene nada que ver con la fase de detección o respuesta. Se trata de lo que ocurre después de que se cierra un incidente.
El análisis posterior a un incidente es uno de esos procesos que todo el mundo coincide en que es valioso, pero en el que casi nadie invierte. Cuando acabas de pasar horas o días en modo respuesta, sentarte a redactar un análisis exhaustivo parece lo último para lo que tienes energía. El resultado suele ser una documentación más pobre de lo que debería, tareas pendientes que no se rastrean y lecciones que no se incorporan a los manuales.
Hemos empezado a usar la IA para cambiar eso.
Una vez cerrado el incidente, alimentamos a la IA con todo el conjunto de pruebas de la respuesta: cada mensaje del canal de incidentes, transcripciones de reuniones, notas, documentos de cronología y artefactos relevantes. La IA realiza entonces el trabajo de síntesis que antes llevaba horas:
- Revisar todas las comunicaciones y documentos para reconstruir una cronología completa del incidente.
- Redactar el análisis posterior al incidente, capturando qué ocurrió, qué hicimos bien, qué pasamos por alto y dónde tuvimos suerte.
- Generar tareas pendientes con suficiente contexto para que sean realmente ejecutables, no solo recordatorios vagos.
- Actualizar o crear manuales basados en lo que reveló el incidente, cubriendo lagunas, corrigiendo suposiciones y capturando esos casos excepcionales que solo aparecen en incidentes reales.
Es fácil escribir una revisión posterior a un incidente que se centre en lo que salió mal y lo que salió bien. Lo más difícil y valioso es capturar los golpes de suerte, aquellas cosas que salieron bien no gracias al sistema, sino a pesar de él. Ahí es donde a menudo se esconden las mejoras más importantes. La IA es sorprendentemente buena sacándolas a la luz cuando tiene el contexto completo de las comunicaciones del incidente.
El resultado es una documentación posterior al incidente más completa, producida más rápido y que realmente retroalimenta el sistema de detección y respuesta en lugar de quedarse olvidada en una carpeta. Cada incidente genera un resultado concreto: un manual actualizado, una laguna detectada, una regla de detección propuesta. La IA hace el trabajo pesado. Los ingenieros validan y cierran el círculo. La diferencia es que nada se pierde en el agotamiento tras un incidente difícil.
La parte que la mayoría del contenido sobre IA y seguridad omite
Esto es lo que no se dice lo suficiente: la respuesta asistida por IA es tan buena como la base sobre la que se asienta.
Antes de poder obtener valor del triaje con IA, necesitábamos:
- Canales de datos limpios y fiables que alimenten nuestro SIEM, y no solo volumen de datos, sino datos correctamente formateados y normalizados sobre los que la IA pueda razonar de forma significativa.
- Un inventario de activos bien mantenido para que el enriquecimiento sea preciso.
- Una lógica de detección ajustada con la suficiente precisión para que la IA no se limite a procesar ruido más rápido.
- Manuales documentados e historial de incidentes sobre los que los LLM puedan razonar.
Si esos elementos no están en su lugar, la IA no resuelve el problema, lo escala. Las detecciones ruidosas se vuelven más ruidosas. El contexto obsoleto se presenta con total confianza. Los falsos positivos se trian de forma más eficiente, directamente hacia una pérdida de tiempo de ingeniería.
Los equipos que hemos visto luchar con la IA en seguridad no fracasan porque eligieran el modelo equivocado. Fracasan porque intentan usar la IA para compensar lagunas fundamentales que la IA no puede llenar.
Qué significa realmente para nosotros ser "agnósticos respecto al modelo"
Deliberadamente no estamos atados a un único proveedor de IA. Las herramientas en este ámbito evolucionan demasiado rápido como para hacer esa apuesta, y la capacidad subyacente importa más que la marca.
Lo que hemos descubierto es que la pregunta correcta no es "¿qué modelo?", sino "¿dónde aporta valor el juicio de la IA y dónde necesita una revisión humana?". Esa pregunta debe responderse según el caso de uso, el nivel de riesgo y, sinceramente, según el tipo de incidente.
Algunas alertas son buenas candidatas para el triaje automático asistido por IA. Otras, cualquier cosa que toque el acceso privilegiado, datos de clientes o posibles escenarios de brecha, pasan primero por ojos humanos, con la IA como capa de apoyo en lugar de protagonista. Esa es una elección arquitectónica deliberada, no una carencia que planeemos solucionar.
Lo que un equipo pequeño puede lograr hoy en día
Gestionar la seguridad de una empresa en crecimiento sin un SOC solía significar aceptar un límite en tu capacidad de cobertura. Ajustabas las detecciones para reducir el volumen, automatizabas lo obvio y clasificabas el resto según su prioridad.
Ese límite ha cambiado. No porque la IA sea mágica, sino porque maneja el trabajo cognitivo repetitivo lo suficientemente bien como para que los ingenieros dediquen más tiempo a las tareas que realmente requieren su criterio.
Triaje más rápido. Mejor calidad en las investigaciones. Menos fatiga en los días de muchas alertas. Seguimos midiendo el impacto a largo plazo con cuidado, pero la tendencia es clara.
Un equipo de seguridad pequeño y bien estructurado, con IA integrada en cada ciclo de respuesta a incidentes, nos permite operar a un nivel que hace dos o tres años habría requerido mucho más personal. No es un discurso de ventas; es lo que vemos en la práctica.
La conclusión
No necesitas un SOC. Necesitas un sistema: uno con datos limpios, detecciones precisas, procesos documentados y ciclos de retroalimentación que lo hagan más inteligente con el tiempo. La IA no reemplaza ese sistema; permite que un pequeño equipo de ingenieros que confían entre sí avance al ritmo del negocio sin necesidad de aumentar la plantilla. Construye primero los cimientos. Entiende tu panorama de amenazas antes de automatizar. Y cuando incorpores la IA, sé honesto sobre dónde se gana tu confianza y dónde todavía necesita una revisión humana.
Esa es la versión de la seguridad asistida por IA que realmente funciona.
