AI Dev Cell y desarrollo seguro por diseño: cómo integrar controles sin frenar la velocidad
- Por Amparo Silva | Amsoft
Introducción
El 21 de octubre de 2026, PHP publicó parches de emergencia para dos vulnerabilidades críticas en su motor, bautizadas como PHP2Shell. Permitían ejecutar código en un servidor sin iniciar sesión. Afectaban a casi todas las versiones de PHP de la última década. Con ellas, también a sitios construidos con WordPress, Drupal o Joomla. PHP mueve cerca del 70% de los sitios cuyo lenguaje de servidor se conoce, según cifras citadas por la Universidad de Valparaíso.
Lo que distingue este caso no es solo su alcance. Según Wiz Research, una de las firmas que llegó a la falla, la cadena de condiciones necesaria para explotarla era muy compleja. Un investigador habría tardado meses en encontrarla sin ayuda. Con modelos de IA, lo hizo en una semana. Esa capacidad consiste en auditar código a una profundidad y velocidad que un equipo humano no alcanza en el mismo plazo. Hoy ya se aplica también dentro del ciclo de desarrollo, no solo en la búsqueda externa de vulnerabilidades.
Ese es el tema de este artículo. Un AI Dev Cell es un equipo que incorpora agentes de IA en tareas de programación, revisión y pruebas, como parte habitual del flujo de trabajo. Cuando ese agente revisa también seguridad en cada cambio, la pregunta deja de ser si conviene sumar controles al desarrollo asistido por IA. Pasa a ser cómo hacerlo sin frenar la velocidad que justifica adoptar el modelo.
Se revisan cinco ideas. Qué es un AI Dev Cell y qué muestra el caso PHP2Shell sobre su potencial en seguridad. Por qué el control al final del ciclo ya no alcanza. Cómo integrarlo sin perder velocidad. Qué tipo de fallas encuentra la IA que a un equipo humano se le escapan. Y por dónde empezar a adoptarlo.
1. Qué es un AI Dev Cell y qué muestra el caso PHP2Shell
1.1 De equipo de desarrollo a célula con agentes de IA
Un AI Dev Cell es una forma de organizar el desarrollo de software en la que agentes de IA participan directamente en tareas de programación. Generan código, proponen pruebas, revisan cambios y documentan decisiones, bajo la supervisión de desarrolladores que validan el resultado. No reemplaza al equipo. Cambia qué hace cada persona: menos tiempo escribiendo código repetitivo, más tiempo revisando criterio, arquitectura y riesgo.
Ese cambio ya está ocurriendo en Chile. Según un estudio de Strand Partners para Amazon Web Services, el 45% de las empresas chilenas usa inteligencia artificial, diez puntos más que el año anterior. De ese grupo, un 17% la aplica en sistemas avanzados, desarrollos propios o agentes autónomos. La adopción del desarrollo asistido por IA no es un escenario futuro. Es una práctica que una parte creciente de las empresas chilenas ya incorpora.
La discusión habitual sobre un AI Dev Cell se centra en velocidad: cuánto código se produce, cuántas tareas se resuelven en menos tiempo. El caso PHP2Shell muestra una dimensión distinta. La misma capacidad que acelera la escritura de código puede acelerar también su revisión de seguridad, si se diseña para eso.
Esa distinción importa porque muchas empresas que evalúan sumar un AI Dev Cell lo hacen pensando solo en productividad. Miden cuánto se acorta un proyecto o cuántas tareas asume el agente. La seguridad queda como un tema aparte, a resolver más adelante con una auditoría o una certificación. El caso PHP2Shell plantea una pregunta distinta: si la misma herramienta que escribe el código puede también revisarlo, por qué dejar esa revisión fuera del diseño inicial del modelo.
1.2 Lo que PHP2Shell muestra sobre la IA aplicada a seguridad
Las fallas de PHP2Shell existían desde hacía más de una década sin que nadie las explotara. Según Wiz Research, eran difíciles de encontrar porque requerían una cadena de condiciones específicas. Involucraban errores de memoria mal gestionados durante fallos de una solicitud, que dejaban el estado interno de PHP corrupto para la siguiente solicitud procesada por el mismo proceso.
Dos equipos llegaron a fallas relacionadas por caminos distintos: Wiz Research con sus propias herramientas de IA, y la firma Calif con el modelo GPT-5.6 Sol, en una auditoría financiada por la iniciativa Patch the Planet de OpenAI. Los parches se publicaron el 21 de octubre, para las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
El CSIRT Nacional de Chile, dependiente de la ANCI, emitió la alerta AVC26-00740 el mismo día, dirigida en particular a prestadores de servicios esenciales. Según el académico de la Universidad de Valparaíso Marco Aravena, la alerta no implica que existan sitios chilenos comprometidos. Sí implica que el riesgo es real y que el plazo para actuar es corto.
El valor del caso para este artículo no es la vulnerabilidad en sí. Es la evidencia de que una IA bien dirigida puede encontrar, en código que millones de personas usan a diario, fallas que se escaparon durante años a la revisión humana. Esa misma capacidad, aplicada dentro del ciclo de desarrollo de una empresa, es el argumento central de un modelo de desarrollo seguro por diseño.
Una aclaración importa: PHP2Shell se encontró con herramientas de investigación externa, no con un AI Dev Cell interno. Lo que un AI Dev Cell toma de ese caso es el principio de fondo: un agente integrado al flujo diario detecta patrones que una revisión manual, hecha bajo presión de tiempo, suele pasar por alto.
2. Por qué el control de seguridad al final del ciclo ya no alcanza
2.1 El problema de revisar seguridad cuando el código ya está listo
El modelo tradicional revisa la seguridad después de construir el software, con una auditoría puntual antes del lanzamiento o en una revisión periódica. Ese modelo funcionaba cuando el código se escribía a un ritmo más lento. Un equipo humano podía abarcar la revisión completa sin tardar semanas.
Con un AI Dev Cell, el volumen de código que se produce crece mucho más rápido que la capacidad de un equipo de seguridad para revisarlo manualmente. Si la revisión sigue ocurriendo al final, pueden pasar dos cosas. La primera es que el proyecto se detenga esperando esa revisión, lo que anula la ganancia de velocidad que motivó adoptar el modelo. La segunda, más riesgosa, es que la revisión se salte o se haga de forma superficial para no frenar la entrega.
PHP2Shell ilustra el costo de ese segundo escenario, aunque a otra escala. Las fallas llevaban más de una década en producción porque nadie las encontró a tiempo, no porque nadie las buscara. Una revisión que llega después de que el código ya está en producción cumple un propósito distinto al de prevenir el problema antes de que exista.
2.2 Qué significa seguridad por diseño en la práctica
Seguridad por diseño significa revisar seguridad en el mismo momento en que se escribe el código, no después. En la práctica, implica que cada cambio pase por un control automatizado antes de integrarse al proyecto. No se espera una auditoría trimestral ni un cierre de etapa.
Esto no reemplaza las auditorías externas periódicas. Las complementa. Una auditoría externa revisa el sistema completo con una mirada independiente, cada cierto tiempo. Un control integrado al flujo de trabajo revisa cada cambio, todos los días, antes de que los problemas se acumulen.
La diferencia práctica está en el momento en que se detecta un problema. Corregir una falla cuando el cambio tiene veinte líneas y acaba de escribirse toma minutos. Corregir la misma falla meses después, cuando ya se construyó algo encima de ella, puede significar rehacer una parte importante del sistema.
3. Cómo integrar el control sin frenar la velocidad
3.1 Agentes de revisión dentro del mismo flujo de trabajo
La forma de no frenar la velocidad es usar el mismo tipo de herramienta que acelera la escritura de código para acelerar también su revisión. Un agente de IA puede analizar cada cambio en el momento en que se propone, antes de integrarlo al proyecto. Puede señalar patrones de riesgo conocidos: validación de entradas ausente, manejo de errores que deja datos expuestos, dependencias con vulnerabilidades reportadas.
Ese análisis ocurre en paralelo al trabajo del equipo, no en una cola de espera. El desarrollador recibe la observación junto con el resto de comentarios sobre su cambio, en el mismo ciclo en que lo está escribiendo. La revisión deja de ser una etapa aparte y pasa a ser parte del mismo flujo.
Esto requiere definir con claridad qué hallazgos bloquean la integración del código y cuáles solo generan una alerta para revisar después. Bloquear todo por cualquier observación recrea el mismo cuello de botella que se buscaba evitar. No bloquear nada vuelve el control decorativo. El punto medio son criterios explícitos. Ciertas categorías de falla, como las que permiten ejecutar código remoto (la misma familia de PHP2Shell), detienen la integración hasta corregirse. Otras quedan registradas para una revisión posterior.
3.2 Qué debe seguir siendo responsabilidad humana
Un agente de IA puede señalar un patrón de riesgo. No puede decidir si ese riesgo es aceptable para el negocio. Esa decisión depende del contexto: qué dato maneja ese sistema, quién puede acceder a él, qué pasa si falla. Ese criterio sigue siendo responsabilidad de una persona.
La revisión de IA tampoco reemplaza las pruebas de penetración ni las auditorías externas. Esas evaluaciones miran el sistema completo desde la perspectiva de un atacante, no cambio por cambio. Un AI Dev Cell bien diseñado combina ambas capas: control continuo dentro del flujo de trabajo, más revisión externa periódica del conjunto.
Por último, alguien debe mantener actualizado el criterio del propio agente de revisión. Los patrones de ataque cambian. Un agente configurado hace un año puede no reconocer una técnica nueva. Esa actualización no ocurre sola. Requiere que un equipo humano la revise y la ajuste con cierta frecuencia.
4. Qué tipo de fallas encuentra la IA que a un equipo humano se le escapan
4.1 Vulnerabilidades que requieren revisar muchas combinaciones a la vez
PHP2Shell es un ejemplo de un tipo de falla particularmente difícil de encontrar a mano. Su explotación dependía de una secuencia de condiciones que cambiaba según la versión de PHP, la configuración del servidor y la aplicación específica que corría encima. Revisar manualmente todas esas combinaciones, en todas las versiones afectadas, habría tomado meses a un equipo especializado.
Una IA puede probar un número mucho mayor de combinaciones en el mismo tiempo, de forma sistemática. Eso la hace útil para encontrar fallas de lógica profunda: errores de manejo de memoria, condiciones de carrera, estados inconsistentes entre componentes. Son fallas que rara vez aparecen en una revisión de código leída de arriba hacia abajo.
Una IA puede probar un número mucho mayor de combinaciones en el mismo tiempo, de forma sistemática. Eso la hace útil para encontrar fallas de lógica profunda: errores de manejo de memoria, condiciones de carrera, estados inconsistentes entre componentes. Son fallas que rara vez aparecen en una revisión de código leída de arriba hacia abajo.
Esto no significa que la IA encuentre todo. Sigue dependiendo de cómo se la dirige y de qué patrones conoce. Pero para el tipo de falla que requiere probar muchas variantes antes de dar con la combinación correcta, hay una ventaja real. Su capacidad de cubrir terreno en poco tiempo supera a la revisión manual.
Esa diferencia es relevante para un AI Dev Cell que trabaja sobre un sistema propio, no solo para la investigación de seguridad externa. Un sistema construido durante años acumula código de distintas épocas, con decisiones de diseño que cambiaron en el camino. Revisar todas las combinaciones posibles entre ese código antiguo y los cambios nuevos es exactamente el tipo de tarea donde un agente de IA rinde más que una revisión manual puntual.
4.2 El mismo riesgo corre en ambas direcciones
La capacidad que permite encontrar una falla antes de que se explote es la misma que permite explotarla más rápido una vez que se conoce. Tras la publicación de los parches de PHP2Shell, Cloudflare reportó intentos de ataque activos contra sitios sin actualizar. Se estima que más de un millón de sitios quedaron expuestos mientras no se aplicaba el parche.
Esto tiene una consecuencia directa para cualquier empresa, use o no un AI Dev Cell. El tiempo entre que se publica una vulnerabilidad y que alguien intenta explotarla se acorta. Un proceso de actualización de dependencias que antes podía esperar semanas ahora compite contra herramientas que escanean internet buscando sistemas sin parchear en cuestión de días.
Para una empresa que ya adoptó desarrollo asistido por IA, la respuesta no es desconfiar de la tecnología que lo hace posible. Es usar esa misma tecnología para acortar su propio tiempo de respuesta. Detectar dependencias desactualizadas, priorizar su corrección y verificar que el parche se aplicó, con la misma velocidad con que se escribe código nuevo.
5. Por dónde empezar a adoptar este modelo
5.1 Un piloto acotado antes de extenderlo a todo el desarrollo
Adoptar un AI Dev Cell con control de seguridad integrado no requiere transformar todo el proceso de desarrollo de una vez. Conviene empezar con un proyecto acotado, sobre código propio y no crítico, donde el equipo pueda ajustar los criterios del agente de revisión sin poner en riesgo un sistema central.
Ese piloto debería durar lo suficiente para generar una base de comparación. Cuántos hallazgos reales entregó el agente, cuántos fueron falsos positivos, cuánto tiempo tomó cada revisión frente al proceso anterior. Con esa información, la empresa decide si ajusta los criterios o si amplía el modelo a otros proyectos.
El piloto también sirve para calibrar expectativas dentro del equipo. Un agente de revisión que genera demasiadas alertas sin relevancia genera el efecto contrario al buscado: el equipo deja de prestarle atención. Ajustar esa sensibilidad durante el piloto, antes de extender el modelo, evita que ese desgaste ocurra a mayor escala.
La elección del proyecto piloto también importa. Un sistema interno, usado por pocas personas y sin conexión directa a datos de clientes, permite equivocarse sin consecuencias graves mientras el equipo aprende a calibrar el agente. Un proyecto crítico, expuesto a internet desde el primer día, no es el lugar para aprender por ensayo y error.
Para empresas que recién evalúan sumar desarrollo asistido por IA a su operación, conviene primero entender qué tareas delegar. Amsoft trató ese punto en su artículo sobre inteligencia artificial para pymes chilenas sin equipo técnico, centrado en qué soluciones adoptar según la madurez de cada empresa.
5.2 Gobernanza mínima para no perder trazabilidad
Cada cambio que pasa por un agente de IA, ya sea de generación de código o de revisión de seguridad, debería quedar registrado. Qué propuso el agente, qué aceptó o corrigió la persona que lo revisó, y por qué. Ese registro no es un trámite burocrático. Es lo que permite reconstruir qué pasó si algo falla después.
También conviene definir desde el inicio quién tiene la autoridad para aprobar que un cambio señalado como riesgo se integre de todas formas. Esa aprobación debería quedar condicionada y justificada por escrito. Dejar esa decisión sin dueño claro es la forma más común en que un control de seguridad termina sin aplicarse en la práctica.
Por último, las pruebas automatizadas deberían ser una condición para integrar cualquier cambio, generado por una persona o por un agente de IA. Un sistema de integración y despliegue continuo que no exige pruebas antes de avanzar pierde buena parte del valor de tener un control de seguridad integrado al flujo de trabajo.
Conclusión
El caso PHP2Shell mostró que una IA bien dirigida puede encontrar, en código que lleva más de una década en producción, fallas que se le escaparon a la revisión humana. Esa misma capacidad es la que un AI Dev Cell puede aplicar dentro del ciclo de desarrollo de una empresa, no solo en la búsqueda externa de vulnerabilidades.
Integrar ese control sin frenar la velocidad depende de dónde se ubica la revisión. Un control que ocurre dentro del mismo flujo de trabajo, en el momento en que se escribe cada cambio, no compite con la velocidad del desarrollo asistido por IA. Sí compite un control que sigue esperando al final del proyecto, cuando corregir una falla ya cuesta mucho más.
Desarrollo seguro por diseño no significa agregar una etapa más. Significa que la revisión de seguridad crezca al mismo ritmo que la capacidad de generar código, con criterios claros sobre qué bloquea una integración y qué responsabilidad sigue siendo humana.
¿Cómo puede Amsoft ayudarte en este camino?
En Amsoft desarrollamos software a medida incorporando IA dentro del propio proceso de desarrollo, con revisión de seguridad integrada a cada cambio, no como una etapa final separada. Trabajamos con equipos de tecnología que buscan adoptar este modelo sin perder el control sobre lo que se integra a sus sistemas.
Podemos ayudarte a evaluar un piloto acotado para tu próximo proyecto, definir los criterios de revisión que corresponden al riesgo de tu operación y acompañar al equipo mientras lo ajusta. Contáctanos si estás evaluando sumar desarrollo asistido por IA a tu empresa.
Este artículo fue elaborado por Amparo Silva, miembro del equipo de Amsoft, comprometida con la innovación y la excelencia en el ámbito tecnológico.
Referencias
- Wiz Research. PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet. https://www.wiz.io/blog/php2shell-php-rce
- Infobae. (2026, 21 de octubre). OpenAI detecta con IA dos fallas críticas de PHP antes que los atacantes: 70% de los sitios web de internet. https://www.infobae.com/tecno/2026/10/21/openai-detecta-con-inteligencia-artificial-dos-fallas-criticas-de-php-antes-que-los-atacantes-70-de-los-sitios-web-de-internet/
- Universidad de Valparaíso. Académico UV Marco Aravena analiza las vulnerabilidades en PHP y por qué los gobiernos bajan sus páginas de manera preventiva. https://www.uv.cl/archivo-noticias-uv/29748-academico-uv-marco-aravena-analiza-las-vulnerabilidades-en-php-y-por-que-los-gobiernos-bajan-sus-paginas-de-manera-preventiva
- CSIRT Nacional de Chile (ANCI). Alerta AVC26-00740 – PHP, vulnerabilidades críticas. https://csirt.gob.cl/alertas/avc26-00740/
- Pauta.cl. (2026, 25 de septiembre). El 45% de las empresas chilenas usa inteligencia artificial, pero la mayoría aún la ocupa para tareas básicas https://www.pauta.cl/tendencias/2026/09/25/el-45-de-las-empresas-chilenas-usa-inteligencia-artificial-pero-la-mayoria-aun-la-ocupa-para-tareas-basicas.html