La seguridad con IA consiste en usar modelos de inteligencia artificial para encontrar vulnerabilidades de software, encadenarlas en una ruta de ataque realista, proponer el parche correspondiente y verificar que la corrección funcione, siempre con una persona aprobando el despliegue final. No reemplaza al equipo de seguridad: le quita el trabajo repetitivo y le devuelve tiempo para decidir.
El 13 de octubre de 2026, OpenAI publicó el caso de Block, la empresa detrás de Square, Cash App y Afterpay, que aplica este enfoque sobre su propio código. Según la propia OpenAI, su equipo de seguridad pasó de dedicar semanas a ciertas revisiones a resolverlas en horas, con un humano validando cada resultado antes de que toque producción.
Hay una frase del video que resume el problema mejor que cualquier informe: "cada atacante tiene potencialmente una capacidad avanzada en el bolsillo". El mismo modelo que ayuda a un equipo pequeño a defenderse está disponible, por unos dólares, para quien quiera atacar tu sistema. En este artículo revisamos cómo funciona ese ciclo, qué cambia para una empresa peruana y qué no debes creer de las promesas fáciles.
¿Qué hace distinto a un modelo de IA frente a un escáner tradicional?
Los escáneres de código existen desde hace décadas. Un analizador estático, un linter o un revisor de dependencias te dicen "aquí hay un error". Eso ya tiene valor, pero es un valor limitado: cada hallazgo se reporta aislado, y el equipo de TI termina con una lista larga de alertas que nadie alcanza a revisar.
Lo que describe Block es distinto. En sus propias palabras, la herramienta anterior "podía buscar en el software y decir aquí hay un error en tu código", mientras que el enfoque actual puede "encadenar hipótesis sobre patrones de ataque, cruzar límites de confianza y unir una serie de ataques para dar un compromiso de extremo a extremo".
La palabra clave es encadenar. Un atacante real no piensa en fallas sueltas: piensa en caminos. Esta validación de entrada débil me deja llegar a esa función de deserialización, que me permite saltar al servicio que guarda las credenciales. Cada paso por separado puede parecer de severidad baja; unidos, son un compromiso total del sistema.
Modelar esa cadena requería antes un especialista capaz de sostener toda la arquitectura en la cabeza y ponerse a hipotetizar como un atacante. El caso de Block sostiene que ahora el modelo hace esa hipótesis, y el humano valida. Ahí está el cambio de fondo: no es una lista de errores más larga, es una ruta de ataque completa la que aparece sobre la mesa.
¿Cómo se convierte un hallazgo en un arreglo real?
Encontrar la falla es solo la mitad del problema. El propio James Nettesheim, CISO de Block, describe el ciclo que aplican sobre cada hallazgo: ubicar dónde vive el problema en el código, identificar quién es dueño de ese software, proponer un parche, confirmar que la falla es realmente explotable y verificar que el arreglo la cerró, con una persona guiando y desplegando el cambio.
Vale la pena leerlo como seis trabajos distintos que el agente ejecuta en secuencia:
- Localizar la vulnerabilidad en el código.
- Identificar el equipo o servicio responsable, que en una organización grande es un problema difícil por sí solo.
- Redactar un parche.
- Confirmar que el error es explotable de verdad y no un hallazgo teórico.
- Verificar que el parche lo cerró.
- Mantener a un humano guiando y desplegando.
El detalle que más se suele pasar por alto: el valor no está en el hallazgo, está en el ciclo completo. Una herramienta que solo encuentra errores agrega trabajo a la cola de revisión. Un ciclo que encuentra, prueba, arregla y verifica sí reduce el riesgo. Si evalúas proveedores en este espacio, pídeles ver el ciclo completo con una compuerta humana, no un tablero de hallazgos crudos.
Los números que reporta OpenAI sobre este caso ayudan a dimensionar la escala: un aumento del 50% en el rendimiento de triaje de alertas, un 50% más de recolección de inteligencia e investigaciones, aproximadamente 1.100 horas-analista de investigación completadas por trimestre y unas 600 horas-analista de triaje de falsos positivos devueltas al equipo. Son cifras de una empresa grande, con un equipo de seguridad dedicado, y conviene leerlas con esa advertencia: no describen lo que le pasa a una PYME que recién empieza.
¿Qué significa esto para una empresa en Perú o Latinoamérica?
La mayoría de las empresas medianas en Perú no tiene un equipo de seguridad dedicado. Tiene un jefe de TI o un proveedor externo que además administra servidores, respalda bases de datos y atiende incidencias del día. Bajo ese esquema, la revisión de seguridad del código propio casi nunca ocurre: se hace cuando ya hubo un incidente, que es el peor momento para enterarse.
El cambio práctico es de costo de acceso. Lo que antes requería contratar un equipo de pruebas de penetración por semanas, hoy se puede aproximar con un agente bien dirigido sobre las rutas más expuestas de tu sistema. No es lo mismo que un pentest formal, y no reemplaza una auditoría, pero sí te da una primera capa de revisión que antes simplemente no existía para una empresa de ese tamaño.
Hay un dato del caso que conviene subrayar: en ejercicios recientes de red team, el tiempo desde que se entregaba una vulnerabilidad de alto nivel hasta que aparecía un parche propuesto de forma automática fue de 18 minutos. Un equipo humano típico dedica días a eso. La brecha entre quien parcha en minutos y quien parcha en semanas es, en la práctica, la brecha entre estar expuesto y no estarlo.
Y esa moneda tiene dos caras. El mismo modelo que te ayuda a encontrar tus fallas le sirve a alguien más para encontrar las mismas fallas, por unos dólares de inferencia. Si tu equipo tarda semanas en corregir, el tiempo que ganas con la IA lo pierdes por el otro lado. En la práctica, la ciberseguridad para empresas deja de ser un proyecto anual y se vuelve una rutina continua.
¿Qué NO demuestra este caso?
Conviene ser honesto con los límites. Todo lo anterior viene de la propia OpenAI y de Block, es decir, del proveedor y de su cliente, no de una evaluación independiente. Las cifras de horas-analista y de rendimiento no tienen una metodología pública que permita replicarlas.
Además, el caso describe una empresa con un equipo de seguridad maduro, procesos definidos y personal capacitado para revisar lo que el modelo propone. Ese contexto es justamente el que falta en la mayoría de las empresas de la región. Sin alguien capaz de leer un parche y decidir si es correcto, el ciclo se rompe en el paso más importante.
Los agentes tampoco cargan el contexto de la organización ni las razones detrás de decisiones pasadas. Eso lo aporta la persona, y por eso el propio Nettesheim plantea subir el nivel de riesgo de forma gradual: primero sistemas menos sensibles, y solo cuando el juicio del modelo se comprueba en la práctica, avanzar hacia lo más crítico. Copiar el modelo sin esa gradualidad es la forma más rápida de convertir una buena herramienta en un incidente.
¿Cómo aplica esto en tu empresa?
Si desarrollas o mantienes software, el punto de partida no es revisar todo tu código de una vez. Es elegir los objetivos que elegiría un atacante: autenticación, flujos de pago, cualquier punto donde se cruce un límite de confianza entre sistemas o entre usuarios. Empieza por ahí, no por el repositorio completo.
Segundo, define dónde queda la compuerta humana. En el caso de Block está en dos lugares concretos: confirmar que la falla es explotable y aprobar el despliegue. Deja que el modelo haga la investigación tediosa, el mapeo de responsables y el borrador del parche, pero no permitas que empuje cambios a producción por su propio criterio.
Tercero, mide el ciclo completo, no los hallazgos. La pregunta útil no es cuántas vulnerabilidades encontraste, sino cuántas pasaron de hallazgo a parche verificado. Si solo cuentas hallazgos, vas a terminar con una lista larga y ningún riesgo reducido.
Si quieres revisar cómo se ve esto en tu caso concreto, puedes conversar con nosotros sobre tu caso. También puedes revisar nuestro blog para más contenido sobre automatización y herramientas de IA aplicadas al negocio.
Preguntas Frecuentes
¿Qué es la seguridad con IA y en qué se diferencia de un antivirus?
La seguridad con IA usa modelos de lenguaje para analizar el código y el comportamiento de un sistema, encadenar posibles rutas de ataque, proponer parches y verificar que funcionen. Un antivirus detecta software malicioso ya conocido en un equipo; este enfoque busca fallas propias en el software que tú desarrollas o mantienes, incluso antes de que alguien las explote.
¿Una empresa mediana en Perú puede usar agentes de IA para revisar su código?
Sí, con matices. Lo que antes requería contratar pruebas de penetración por semanas hoy se puede aproximar con un agente dirigido sobre las rutas más expuestas de tu sistema, como autenticación y pagos. La condición es tener a alguien capaz de revisar el parche propuesto antes de desplegarlo; sin esa revisión, el ciclo queda incompleto y el riesgo no baja.
¿Los parches automáticos son seguros para producción?
No por sí solos. En el caso de Block, el parche se propone de forma automática pero pasa por confirmación de explotabilidad y verificación del arreglo, con una persona guiando y desplegando el cambio. La recomendación práctica es mantener la compuerta humana exactamente ahí: en confirmar que la falla es real y en aprobar el despliegue a producción.
Conclusión: ¿el hallazgo o el ciclo completo?
La lección del caso de Block no es que la IA encuentre errores, porque eso ya lo hacían los escáneres. La lección es que el ciclo completo, encontrar, probar, arreglar y verificar, es lo que realmente reduce el riesgo, y que ese ciclo ahora es accesible para equipos mucho más pequeños que antes.
Para una empresa en Perú, la pregunta útil no es si adoptar IA en seguridad, sino qué tan rápido puede cerrar el ciclo cuando aparece una falla. Si tu equipo tarda semanas, la ventaja la tiene quien esté mirando tu sistema desde afuera.
Si quieres ordenar este proceso en tu empresa, conversemos sobre tu caso y veamos por dónde empezar.
Por Edgar Vásquez, Consultoría TI · actualizado el viernes, 16 de octubre de 2026
Fuentes y Referencias
- OpenAI — Block on Finding and Fixing Security Risks with OpenAI (YouTube, 13 de octubre de 2026)
- OpenAI — How Block is building AI-powered security with OpenAI technology
- Ken Ashe — When the Vulnerability Scanner Becomes an Attack Planner
✨ Contenido generado con ContentFlow — Consultoría-Ti