La ciberseguridad con inteligencia artificial consiste en usar modelos de IA para investigar alertas, encadenar vulnerabilidades sueltas en una ruta de ataque completa y proponer parches, siempre con una persona validando qué se corrige y qué se despliega. No reemplaza al equipo de seguridad: comprime su tiempo y le devuelve la capacidad de revisar todo, no solo lo más urgente.
El 13 de octubre de 2026, OpenAI publicó un video en el que James Nettesheim, Chief Information Security Officer de Block —la empresa detrás de Square, Cash App y Afterpay—, describe cómo su equipo de seguridad trabaja hoy con modelos de IA. La frase que resume el cambio es incómoda: “cada atacante tiene potencialmente una capacidad avanzada en el bolsillo”. La misma tecnología que defiende está disponible, por unos dólares de cómputo, para quien quiera atacar.
Lo interesante no es que la IA encuentre errores. Los analizadores estáticos llevan décadas señalando código mal escrito. Lo nuevo es que el modelo hipotetiza sobre patrones de ataque, cruza límites de confianza y encadena varias fallas hasta mostrar un compromiso de extremo a extremo. A continuación vemos cómo funciona ese ciclo, qué se puede aplicar en una empresa peruana y qué no prueba todavía esta historia.
¿Qué cambia cuando la IA encadena vulnerabilidades en vez de listarlas?
Un escáner tradicional reporta hallazgos aislados: “aquí hay un error en tu código”. Ese reporte entra a una cola de triaje y, en la práctica, muchas veces nadie lo revisa a fondo. Block describe algo distinto: el modelo toma una alerta aparentemente menor y la sigue hasta ver si forma parte de algo mayor.
El caso que cuenta Nettesheim es elocuente. Una alerta sobre una sola laptop parecía un problema menor de política interna. Durante la revisión, el modelo siguió un indicador que aparecía de forma incidental en la evidencia, lo cruzó contra los registros de identidad de la empresa y destapó un conjunto de problemas mucho más grande. En sus palabras, “una alerta rutinaria de endpoint se convirtió en el desmantelamiento de una campaña”. Ninguna herramienta sola hace ese cruce: la señal solo existe al juntar los registros de dos productos distintos.
El segundo ejemplo viene de un ejercicio de red team. Al modelo se le dieron unas pocas pistas sobre un sistema interno y encadenó una ruta de ataque completa —inyección SQL, escalamiento de privilegios, un punto de apoyo, enumeración de credenciales y un pivote hacia otros sistemas— en aproximadamente dos horas. Ese trabajo normalmente le toma varios días a un especialista humano.
La consecuencia práctica es que la seguridad con IA cambia la unidad de análisis. Ya no se trata de una lista de fallas, sino de rutas de ataque. Y una ruta se puede priorizar, porque se sabe a dónde llega.
¿Cómo se ve el ciclo completo de detección, parche y verificación?
Encontrar el problema es la mitad del trabajo. La otra mitad, la que casi nadie automatiza, es corregirlo. Block describe un ciclo de seis pasos que su equipo recorre en cada hallazgo: ubicar dónde vive la falla en el código, identificar qué equipo o servicio es dueño de ese código, redactar un parche, confirmar que la vulnerabilidad es realmente explotable y no un hallazgo teórico, verificar que el parche la cerró, y mantener a una persona guiando y desplegando el cambio.
Ese último punto es el que más se subestima. Los agentes no cargan el contexto de la organización ni el razonamiento detrás de decisiones anteriores. Una persona aporta ese contexto y esa estrategia. Nettesheim lo plantea como una escalera: a medida que el juicio del modelo se comprueba en la práctica, se sube el nivel de riesgo de lo que se le permite tocar.
Los números que reporta el equipo, según OpenAI, son concretos. El triaje automatizado produjo un aumento del 50% en el volumen de casos procesados y un 50% más de recolección de inteligencia e investigaciones. El sistema completa aproximadamente 1.100 horas-analista de investigación por trimestre, y devuelve unas 600 horas-analista por trimestre que antes se gastaban en descartar falsos positivos. En ejercicios recientes de red team, el tiempo entre enviar una vulnerabilidad de alto nivel y obtener un parche propuesto de forma automática fue de 18 minutos. Y una propuesta de cambio en las reglas de detección se puede reproducir contra siete meses de telemetría de producción en menos de una hora, cuando antes eso significaba reconsultar cientos de casos a mano.
Hay un detalle de gestión poco comentado: el equipo dejó de usar siempre el modelo más reciente. “Solíamos usar el último modelo, pero ya no necesitas hacer eso”, dice Nettesheim. Ahora eligen distintos modelos según la tarea. Para una empresa mediana, esa es una lección directa: la automatización de parches no exige el modelo más caro, exige el proceso más claro.
¿Qué significa esto para una empresa en Perú o Latinoamérica?
La mayoría de las empresas medianas de la región no tiene un equipo de seguridad dedicado. Tiene un jefe de TI o un proveedor externo que atiende servidores, respaldos, accesos y, cuando algo suena feo, revisa los registros a mano. Con ese esquema, la revisión profunda de cada alerta es sencillamente imposible: se atiende lo urgente y lo demás se acumula.
Ese es exactamente el cuello de botella que este enfoque ataca. Si el modelo hace la investigación tediosa —leer registros, mapear quién es dueño de qué servicio, redactar un parche candidato—, el equipo humano se concentra en lo que solo una persona puede decidir: si el hallazgo es real, si el parche rompe algo del negocio y cuándo se despliega.
Pero hay una advertencia que aplica con más fuerza en nuestra región. Si la capacidad de atacar también se abarató, entonces el riesgo cibernético de una PYME peruana ya no depende de que sea un blanco interesante. Depende de que sea un blanco fácil. Y una empresa que factura, cobra y despacha por internet es un blanco fácil si nadie revisa sus rutas críticas.
Para una empresa en Perú, el punto de partida razonable no es el repositorio completo ni todos los servidores. Es lo que un atacante elegiría primero: autenticación, flujos de pago, integraciones con pasarelas, portales de clientes y cualquier punto donde se cruce un límite de confianza entre sistemas. Ahí es donde conviene apuntar una revisión asistida por IA.
¿Cómo aplica esto en tu empresa?
No necesitas montar un centro de operaciones de seguridad para empezar. Necesitas ordenar el ciclo. Estas son acciones concretas que puedes ejecutar este trimestre:
- Inventa tus rutas críticas. Antes de comprar cualquier herramienta, escribe en una hoja qué sistemas tocan dinero, identidad o datos de clientes. Si no sabes qué proteger, ningún agente te va a ayudar.
- Empieza por un solo flujo. Elige el portal de clientes o el módulo de pagos y corre ahí una revisión asistida por IA. No intentes cubrir todo el ecosistema el primer mes.
- Define dónde se queda el humano. Copia el criterio de Block: la persona confirma que la falla es explotable y autoriza el despliegue. El agente investiga y propone; no publica solo.
- Mide horas, no hallazgos. Un reporte con 200 vulnerabilidades no dice nada. Lo que importa es cuántas horas de trabajo experto te devolvió el sistema y cuántas fallas quedaron realmente cerradas.
- Documenta cada decisión. Guarda la evidencia de cada investigación. Es lo que después te permite reproducir un cambio de regla contra meses de historial, como hace Block, en lugar de rehacer el trabajo desde cero.
- Revisa tus integraciones y APIs. Si desarrollas software con .NET, Java o TypeScript, tus endpoints son la superficie más expuesta. Una revisión de diseño de API y de manejo de credenciales suele rendir más que cualquier parche cosmético.
Si quieres aterrizar esto en tu operación, puedes conversemos sobre tu caso en Consultoría TI y revisar juntos por dónde empezar. También puedes ver cómo trabajamos la automatización de procesos con IA en ContentFlow o seguir leyendo análisis en el blog de Consultoría TI.
Preguntas Frecuentes
¿Qué es la ciberseguridad con inteligencia artificial?
Es el uso de modelos de IA para investigar alertas de seguridad, encadenar vulnerabilidades aisladas en una ruta de ataque completa, proponer parches y verificar que el problema quedó resuelto. La diferencia clave frente a un escáner tradicional es que no entrega una lista de errores sueltos, sino una ruta explotable de extremo a extremo, con una persona validando cada corrección antes de desplegarla.
¿Puede una PYME peruana usar agentes de IA para seguridad?
Sí, y probablemente sea el segmento que más lo necesita, porque casi nunca tiene un equipo de seguridad dedicado. La recomendación práctica es empezar acotado: elegir uno o dos flujos críticos, como el portal de clientes o el módulo de pagos, y correr ahí una revisión asistida por IA. No se trata de cubrir toda la infraestructura el primer mes, sino de reducir el riesgo donde más duele y aprender el proceso con un caso real.
¿La IA puede reemplazar al equipo de seguridad de una empresa?
No. En el caso que describe Block, la IA hace la investigación tediosa y la persona decide. Los agentes no cargan el contexto de la organización ni el razonamiento detrás de decisiones pasadas, y por eso el equipo mantiene el control en dos puntos concretos: confirmar que la vulnerabilidad es realmente explotable y autorizar el despliegue del parche. El valor está en comprimir el tiempo del experto, no en sustituir su criterio.
Conclusión: ¿deberías preocuparte por esto hoy?
Sí, pero por la razón correcta. La novedad no es que la IA encuentre errores, sino que encadene fallas menores hasta formar una ruta de ataque completa, y que ese trabajo pase de semanas a horas. Eso significa que el tiempo que antes te protegía —la lentitud del atacante— ya no existe.
Lo que sí sigue existiendo es el criterio humano. El ciclo que describe Block funciona porque alguien decide qué se corrige y cuándo. Ese es el modelo que una empresa peruana puede adoptar sin montar un centro de operaciones: investigar con IA, decidir con personas, medir horas recuperadas y no cantidad de hallazgos.
Si tu equipo de TI hoy solo alcanza a apagar incendios, el primer paso no es comprar una herramienta. Es saber qué sistemas son críticos y quién decide sobre ellos. Desde ahí, la automatización tiene sentido.
Por Edgar Vásquez, Consultoría TI · actualizado el 16 de octubre de 2026
Fuentes y Referencias
- OpenAI — How Block is building AI-powered security with OpenAI technology
- Ken Ashe — When the Vulnerability Scanner Becomes an Attack Planner
- AT Pulse — Block moves security operations onto OpenAI's Daybreak
- OpenAI (YouTube) — Block on Finding and Fixing Security Risks with OpenAI, 13 de octubre de 2026
¿Tu empresa tiene identificados sus sistemas críticos y quién decide sobre ellos? En Consultoría TI podemos ayudarte a ordenar ese punto de partida antes de automatizar cualquier cosa.
✨ Contenido generado con ContentFlow — Consultoría-Ti