El modelo no es el producto: qué debería evaluar un CISO antes de contratar seguridad ofensiva con IA

Durante años, comprar seguridad ofensiva fue una decisión binaria. O contratabas un equipo de pentesters humanos, con todo lo que eso implica en tiempo y costo, o te resignabas a un escáner automático que escupía falsos positivos. Blanco o negro. Esa época terminó.

La IA ofensiva ya encuentra y explota vulnerabilidades reales (de las que se pagan) a una velocidad y una escala que el pentest manual no alcanza. Dejó de ser una promesa de laboratorio para convertirse en una capacidad disponible. Y eso obliga a cualquier líder de seguridad a replantear no solo a quién contrata, sino cómo compra seguridad ofensiva.

Si yo estuviera del otro lado de la mesa como CISO, decidiendo a quién le confío la superficie de ataque de mi empresa, esa realidad no me llevaría a una conclusión simple. Me llevaría a una pregunta mejor.

‍

Dos caminos válidos, no dos bandos

Hoy tenemos, al menos, dos opciones legítimas, y conviene no confundirlas.

La primera son las empresas de pentest tradicional que potencian a sus pentesters con herramientas de IA y con licencias de modelos como Claude. No es marketing vacío: un buen pentester con un copiloto como Claude razona mejor sobre el código, las respuestas y las hipótesis, y gana en las dos cosas que históricamente se le escapaban al pentest manual: tiempo y cobertura. Cubre más superficie en menos días. Es una mejora genuina del modelo clásico.

La segunda opción es no entregarle un modelo a un humano y confiar en su criterio, sino construir una arquitectura y un modelo de valor alrededor del LLM: donde el modelo no es el producto, sino un componente más, gobernado por un sistema que lo rodea.Es el enfoque de Strike, pero la distinción de fondo no está en decir que se usa IA, sino en dónde vive el control.

No están en bandos opuestos. Son caminos distintos. Y esto no invalida el trabajo del pentester aumentado con IA; de hecho, los mejores sistemas combinan humanos, modelos y controles. La pregunta no es "quién usa más IA" (los dos la usan), sino dónde vive la garantía operacional.

‍

Cómo se ve hoy "dotar a un pentester de Claude": skills

Conviene aterrizar qué significa, en la práctica de 2026, potenciar a un pentester con una herramienta como Claude. Hoy significa, sobre todo, skills: módulos que empaquetan instrucciones, scripts y conocimiento para una tarea concreta. Reconocimiento, la prueba de un tipo de vulnerabilidad, la generación de un reporte. Es la forma en que el sector está extendiendo los modelos, y es genuinamente buena: encapsula experiencia repetible y la pone a un comando de distancia.

La clave está en cómo el modelo decide qué skill usar. Claude no carga todas las skills de golpe; usa recuperación progresiva (progressive disclosure). Al arranque solo ve el nombre y la descripción de cada skill (apenas un centenar de tokens por skill). Con esa metadata, y nada más, juzga si una skill es relevante para la tarea. Solo cuando "cree" que aplica carga el cuerpo de instrucciones; y solo entonces, los scripts y archivos que esa skill referencia. Es elegante: mantiene el contexto liviano y escala a cientos de capacidades.

Pero ahí mismo está la grieta. Esa decisión inicial de ¿esta skill aplica a lo que estoy haciendo? es un juicio del modelo sobre una descripción de una línea, no una regla determinista. Con pocas skills funciona bien. Con muchas, las descripciones compiten y se solapan, y el modelo puede no disparar la skill correcta, disparar la equivocada, o simplemente pasársela por alto. Y lo hace en silencio: no hay excepción, no hay un log que diga "ignoré la skill que probaba IDOR en el body". Peor aún, a medida que se acumula contexto la fidelidad con que el modelo sigue cada instrucción se degrada (el llamado context rot): la información sigue "ahí", pero pesa menos.

Para un pentest, esa grieta es precisamente la peligrosa. Que el modelo omita la skill que validaba un vector, o el control que delimitaba el alcance, no genera un fallo evidente: genera una prueba incompleta que aparenta estar completa. Y ahí aparece la pregunta de fondo.

‍

La pregunta que de verdad importa: ¿quién controla el flujo?

Cuando una parte importante del control operacional queda delegada al modelo, al prompt o a instrucciones en lenguaje natural, aparece una fragilidad que un CISO debería mirar con cuidado. No es un problema de talento del pentester ni de qué modelo se elija: es una cuestión de dónde reside la garantía.

¿Cómo se asegura que el LLM no se salga del scope autorizado? ¿Que no exceda la tasa de peticiones por segundo que se negoció con el cliente? ¿Que no dispare una acción destructiva sobre un recurso que no debía tocar? Si la respuesta a todo eso vive dentro de instrucciones en lenguaje natural, entonces, cuando algo sale mal, la pregunta incómoda es: ¿cómo se depura un error de prompt?

No se depura como se depura el código. Un modelo de lenguaje es no determinista por diseño. El mismo prompt puede comportarse distinto dos veces. No hay breakpoint, no hay stack trace, no hay un test que reproduzca el fallo de forma fiable. En la mayoría de las disciplinas eso es un inconveniente. En pentesting, donde una sola petición fuera de scope o un pico de tráfico pueden tumbar un sistema productivo del cliente o la conectividad de un equipo entero por una sola variable mal propagada, es un riesgo operacional serio.

‍

El modelo no es el producto: la arquitectura sí

Aquí es donde mover el control fuera del modelo cambia la ecuación. La idea central es deliberadamente poco glamorosa: rodear al modelo de una arquitectura determinista, y usar al LLM solo donde aporta valor real —razonar, interpretar, priorizar—, no como el piloto que toma todas las decisiones.

En la práctica, eso significa un proceso por etapas donde cada paso ejecuta herramientas en un orden fijo, reproducible y testeable, y el modelo entra como un perceptor que interpreta resultados, no como un agente suelto que decide qué atacar y cómo. El scope no se "le pide" al modelo en un párrafo: se valida en una compuerta determinista antes de que se dispare una sola petición. La tasa de peticiones no depende de que el LLM "recuerde" no excederse: la impone el sistema. Las acciones destructivas no quedan a criterio del prompt: están protegidas por guardas en el código.

La regla práctica es simple: el control operacional no debería vivir en la cabeza del modelo. Un agente no debería recordar el scope; debería consultar una política firmada antes de cada request. No debería intentar no hacer demasiadas peticiones; debería tener un rate limiter externo al modelo. No debería decidir si un hallazgo es reportable; debería pasar por un validador reproducible.

Y cuando el juicio humano es insustituible, el sistema no improvisa: cede el control en puntos de handoff explícitos, hace el 95% del trabajo de forma automática y deja que la persona toque solo el 5% donde el modelo no rinde. Precisión por encima de autonomía aparente.

Esa mezcla de arquitectura determinista más juicio humano en los bordes es la que permite separar el razonamiento en etapas auditables y confirmar cada hallazgo con un validador determinista y una prueba de explotación reproducible antes de reportarlo.

‍

La arquitectura en la práctica: Codificando el know-how operativo

Pero una arquitectura sólida, por sí sola, tampoco alcanza. En seguridad ofensiva, el control del flujo solo tiene valor si está construido sobre conocimiento real de la materia. Y ahí hay una diferencia importante: Strike no está intentando construir seguridad ofensiva con IA desde una hoja en blanco, ni desde un conjunto de prompts aislados. Está construyendo sobre años de experiencia haciendo pentesting en el mercado, con miles de horas de pruebas sobre empresas, aplicaciones y contextos muy distintos: banca, fintech, e-commerce, retail, SaaS, salud, energía, telecomunicaciones y plataformas internas.

Ese recorrido le da al sistema algo que un modelo por sí solo no tiene: norte. Detrás de cada decisión de arquitectura hay un hacking team con experiencia en explotación, validación, triage, reporte y discusión de impacto con clientes reales; y equipos de ingeniería e inteligencia artificial analizando ejecuciones, bifurcaciones y resultados para mejorar el agente de forma continua.

Todo eso vive dentro de una plataforma que sostiene la operación: ordena ejecuciones, centraliza evidencia, facilita trazabilidad, conecta el trabajo del agente con el criterio humano y ayuda a que los hallazgos lleguen al cliente con contexto, validación y control.

Ese cruce entre hacking skills, security engineering, prompt engineering, inteligencia artificial, plataforma y experiencia operativa es lo que convierte la arquitectura en producto. No se trata solo de automatizar tareas ofensivas; se trata de codificar el know-how acumulado de Strike en reglas, validadores, flujos y criterios que el sistema pueda repetir con control.

‍

Lo que, como CISO, tendría que garantizar a mi negocio

Esto es lo que termina inclinando la balanza. Los errores van a ocurrir (ningún proveedor honesto promete lo contrario). La diferencia es que con una arquitectura determinista alrededor del modelo sé dónde puede fallar el agente y dónde falla el humano, y eso es justo lo que puedo trasladar como garantía a mi negocio:

• Scope: no se rompe, porque se valida en código antes de cada acción, no en un párrafo de instrucciones.
• Carga: la tasa de peticiones la impone la arquitectura, no la memoria del modelo.
• Reproducibilidad: un hallazgo viene con una prueba que puedo volver a correr; un error viene con un punto del flujo que puedo inspeccionar y corregir.
• Decisiones según la arquitectura de cada aplicación: SPAs, APIs, GraphQL, esquemas de autenticación distintos (cada uno con sus reglas) se manejan con lógica explícita, no con la esperanza de que el modelo "lo entienda".

Un pentester potenciado con IA es, sin duda, mejor que un pentester sin ella. La diferencia no está en quién usa IA, sino en dónde vive la garantía: si en el criterio de una persona confiando en una caja no determinista, o en una arquitectura que rodea al modelo. Esta última me da algo distinto: control del flujo en cada etapa del pentest, trazabilidad cuando algo se rompe, y reglas fijas que no dependen de que el modelo tenga un buen día.

Por eso, si yo fuera el CISO, me inclinaría por un proveedor construido con esta filosofía. No por usar IA, sino por una idea de fondo: la próxima generación de seguridad ofensiva no se gana con mejores prompts, sino con arquitecturas que convierten el razonamiento probabilístico en procesos controlados, auditables y reproducibles. En seguridad ofensiva, el modelo no puede ser el producto. El producto es el control. 

‍