La ciberseguridad ya no es un proyecto de defensa. Es una carrera de IA contra IA

Durante años, un proyecto de ciberseguridad tenía un punto de llegada razonablemente claro: se definían los controles, se implementaban, se documentaban, y el proyecto se cerraba con esos controles operando. La amenaza cambiaba, sí, pero a un ritmo que permitía tratarla como un problema de mantenimiento periódico, no como una variable en movimiento constante.

Eso terminó. Lo que está ocurriendo ahora no es simplemente que aparecieron amenazas nuevas. Es que el propio objeto del proyecto cambió de naturaleza. Ya no se está construyendo un conjunto fijo de controles frente a un adversario relativamente estático. Se está sosteniendo una capacidad que necesita evolucionar al mismo ritmo que evoluciona quien la ataca, porque ese adversario también tiene acceso a inteligencia artificial. Lo que tenemos hoy es, literalmente, una carrera: IA ofensiva contra IA defensiva, corriendo en paralelo, sin línea de meta.

Esto cambia el tipo de proyecto que hay que diseñar. Un proyecto de ciberseguridad ya no puede plantearse como "implementar estos controles" sino como "sostener una capacidad de adaptación", lo cual es un problema de gestión completamente distinto: distinto en alcance, en cronograma, en la forma de medir éxito y en el tipo de gobierno que necesita.

Cinco términos que conviene tener claros

Antes de entrar en lo que esto implica para quien gestiona proyectos, vale la pena aterrizar algunos conceptos que están detrás de esta carrera, porque no todos los que se sientan en la mesa de decisión vienen de un perfil técnico.

Deepfakes. Contenido de audio, video o imagen generado o alterado por IA para hacer parecer que una persona dijo o hizo algo que nunca ocurrió. La tecnología que hace esto posible es, en esencia, la misma que se usa para generar avatares, doblaje automático o efectos audiovisuales legítimos; el problema no es la herramienta, es el uso.

Ataques de ingeniería social más personalizados. La ingeniería social siempre existió: manipular a una persona para que entregue acceso, información o dinero. Lo que cambió es la escala de personalización posible. Un modelo de lenguaje puede redactar un mensaje sin errores, adoptar el tono exacto de un proveedor conocido o construir un pretexto ajustado al cargo y al contexto específico de la víctima, algo que antes tomaba investigación manual y tiempo.

Malware adaptable. Software malicioso capaz de modificar su propio comportamiento o su código para evitar ser reconocido por las herramientas de detección tradicionales, que suelen buscar patrones o firmas conocidas. En lugar de un virus con una "firma" fija, se enfrenta algo que cambia de forma mientras opera.

Automatización del reconocimiento de vulnerabilidades. La fase en la que un atacante identifica puntos débiles en un sistema —configuraciones abiertas, software desactualizado, accesos mal protegidos— antes existía y era mayormente manual. La IA permite escanear volúmenes enormes de sistemas en busca de esas debilidades de forma automatizada y continua, comprimiendo un trabajo de semanas en un proceso que corre de fondo.

Jailbreaking. Cuando una organización incorpora un modelo de IA, no solo agrega una nueva capacidad: también agrega una nueva superficie de ataque. Un jailbreak consiste en manipular al modelo para que ignore las restricciones con las que fue diseñado y responda o actúe de una forma que normalmente debería rechazar. El riesgo real no está en lograr que un chatbot conteste algo indebido, sino en lo que hay conectado detrás de ese modelo: si tiene acceso a documentos internos, bases de datos, APIs o procesos empresariales, alterar su comportamiento puede convertirse en un problema de seguridad concreto, no solo conversacional.

Un concepto asociado es el prompt injection: una instrucción maliciosa que busca alterar el comportamiento esperado del modelo, a veces de forma directa y a veces escondida dentro de un documento, un correo o cualquier contenido que la IA procese sin que el usuario lo note. Para quien gestiona el proyecto, la conclusión es simple: las instrucciones del modelo no pueden considerarse por sí mismas un control de seguridad. Los permisos, accesos, segregación de funciones y límites sobre las acciones que el modelo puede ejecutar siguen siendo indispensables.

La defensa también está aprendiendo

Lo que suele quedar fuera de la conversación es que este mismo cambio está ocurriendo del lado defensivo, y con un nivel de madurez que ya no es experimental. Los equipos de seguridad utilizan modelos de IA para detectar anomalías de comportamiento en tiempo real —patrones de acceso o tráfico que se apartan de lo esperado—, para automatizar la clasificación inicial de alertas en un centro de operaciones de seguridad, reduciendo el volumen que antes requería revisión humana caso por caso, y para simular ataques contra sus propios sistemas de forma controlada, con el objetivo de encontrar las debilidades antes de que lo haga alguien externo.

También se está avanzando en biometría de comportamiento —analizar no solo si la contraseña es correcta, sino si el patrón de uso de quien la ingresó es consistente con el usuario legítimo— y en tecnologías de "engaño" (deception technology), que consisten en desplegar sistemas señuelo dentro de la red para detectar movimiento no autorizado antes de que llegue a un activo real.

Ninguna de estas capacidades es infalible, y ese es precisamente el punto: no existe una solución que cierre la carrera de forma definitiva. Cada avance defensivo genera presión para que la ofensiva se sofistique, y cada avance ofensivo obliga a ajustar la defensa. Es una dinámica de coevolución, no un problema que se resuelve una vez y queda resuelto.

La oportunidad de servicio que esto abre

Esta dinámica tiene una consecuencia menos evidente, pero especialmente relevante para quienes diseñan y comercializan proyectos de ciberseguridad. Durante mucho tiempo el ciclo comercial fue bastante lineal: primero se implementaba una solución, y después, si el cliente lo requería, se ofrecía un servicio de seguridad gestionada para operarla, monitorearla y atenderla. Una carrera entre capacidades ofensivas y defensivas introduce una necesidad adicional: no basta con operar el control, también hay que comprobar de forma periódica que sigue siendo efectivo frente a amenazas que no dejan de evolucionar.

Esto cambia la conversación de preventa. Un proyecto puede implementar correctamente una plataforma de protección, monitoreo o respuesta y cumplir todos sus entregables, y aun así, meses después, el panorama de amenazas ya cambió, aparecieron nuevas técnicas o surgieron escenarios que inicialmente no se contemplaron. Ahí empieza a cobrar valor una capa adicional de servicio: la validación continua de la capacidad defensiva. No se trata únicamente de mantener la herramienta funcionando, sino de someter la defensa a nuevas pruebas de forma periódica, revisar escenarios emergentes, identificar brechas, ajustar controles y volver a validar su eficacia.

El valor que recibe el cliente también cambia. Ya no compra solamente tecnología ni operación. Compra la capacidad de comprobar que su defensa sigue respondiendo frente a un adversario que tampoco permanece quieto.

El proyecto puede cerrar. La capacidad no.

Esto no significa que los proyectos de ciberseguridad deban convertirse en iniciativas eternas. Un proyecto sigue necesitando alcance, presupuesto, entregables y una fecha de cierre. Lo que cambia es aquello que debe dejar preparado cuando termina.

Antes podía ser suficiente entregar el control implementado, documentado y operativo. En un entorno donde ataque y defensa evolucionan rápidamente, el proyecto debería dejar además definido cómo esa capacidad será evaluada y ajustada después del cierre. El ciclo empieza a parecerse menos a implementar → probar → entregar → cerrar, y más a implementar → probar → operar → validar → ajustar → volver a probar.

Eso afecta desde el diseño del servicio hasta el presupuesto y los indicadores con los que se mide su éxito. Una solución puede estar disponible el 99,9 % del tiempo y, aun así, haber perdido efectividad frente a determinadas amenazas. Por eso las métricas técnicas y operativas necesitan complementarse con una pregunta más incómoda: ¿la capacidad defensiva que implementamos sigue siendo efectiva frente al escenario de amenazas actual?

Para quien gestiona proyectos, el cambio no consiste en aprender a pensar como una inteligencia artificial ni en convertirse en especialista ofensivo. Consiste en reconocer que el entregable tecnológico es solo una parte del resultado: el proyecto también debe dejar una capacidad preparada para seguir evolucionando. Y para quien trabaja en preventa aparece una oportunidad igual de concreta: diseñar desde el inicio no solo la implementación y la operación posterior, sino también el mecanismo mediante el cual esa defensa seguirá siendo puesta a prueba.

La seguridad gestionada seguirá siendo necesaria —alguien tiene que operar las plataformas, analizar alertas, responder incidentes y mantener los controles funcionando—, pero mantener un control funcionando y comprobar que continúa siendo eficaz no son exactamente lo mismo. Esa diferencia, entre operar y validar, puede convertirse en uno de los cambios más importantes en la forma de diseñar servicios de ciberseguridad en los próximos años.

La pregunta que queda abierta

La carrera entre IA ofensiva e IA defensiva no tiene un punto en el que alguien gane de forma definitiva. Lo que sí puede definirse es quién se adapta más rápido: la organización cuyos proyectos de ciberseguridad están diseñados para evolucionar al mismo ritmo que la amenaza, o la que sigue tratando la seguridad como un capítulo que se cierra una vez y no se vuelve a abrir.