La lista de verificación del CISO para software generado por IA

La pregunta de seguridad sobre el código generado por IA normalmente se hace al revés. «¿Es el código de IA menos seguro que el código humano?» invita a un concurso de citas de estudios y pierde el punto operativo: la IA cambia el volumen, la velocidad y la autoría del código, y esos tres cambios rompen las suposiciones sobre las que se construyó tu programa de garantía existente. Los pen tests anuales asumen que la base de código cambia lentamente. La revisión manual asume un autor humano que entendió el cambio y puede responder por él. El muestreo asume que el código no muestreado se parece al código muestreado. Bajo el desarrollo con IA, nada de eso se sostiene.

Así que el requisito a nivel de CISO no es un veredicto sobre la calidad del modelo, los modelos seguirán cambiando de todos modos. Es un conjunto de propiedades que debe tener el sistema de desarrollo sin importar qué modelo escribió el código: cada cambio atribuible a un prompt, una persona y una aprobación; los cambios consecuentes filtrados por política antes del merge; pruebas de seguridad que corren continuamente y confirman hallazgos contra la aplicación en vivo en lugar de inundarte de ruido estático; y un registro inmutable lo bastante bueno para reconstruir cualquier cambio para un auditor o una revisión de incidente.

Enmarcado así, el desarrollo con IA no es una nueva categoría de riesgo que exija una nueva teoría. Es una categoría familiar (gestión de cambios a escala) que exige mejor maquinaria. La lista de verificación de abajo es esa maquinaria, escrita como requisitos que puedes poner delante de cualquier proveedor o equipo de plataforma interno.

La postura importa tanto como los controles. La postura productiva es asumir que el software generado por IA ya existe en tu organización, porque existe, y hacer que la vía gobernada sea la atractiva en lugar de anunciar una prohibición que empuja la construcción más hacia las sombras. Los equipos de seguridad que publican una ruta sancionada con controles claros obtienen visibilidad y adopción; los equipos que prohíben no obtienen ninguna de las dos, más el mismo riesgo. Cada requisito de abajo sirve a esa estrategia: cada uno hace que la forma segura de construir sea también la forma fácil de responder por lo que se construyó.

Empieza con lo que ya es verdad: las unidades de negocio están generando aplicaciones con herramientas de IA hoy, en su mayoría fuera del campo de visión de seguridad. El incidente realista a corto plazo no es un ataque exótico a un modelo; es una app construida con IA sin revisar con una política de base de datos demasiado permisiva exponiendo silenciosamente registros de clientes, descubierta por un cliente. El desarrollo de IA en la sombra es TI en la sombra con un generador de código adjunto, y hereda cada fallo clásico (flujos de datos desconocidos, dependencias sin parchear, sin propietario) a mucha más velocidad de producción.

Dentro de ingeniería, el riesgo es más sutil: erosión de la revisión bajo volumen. Cuando los pull requests generados por agentes se triplican y la plantilla de revisores no, la aprobación o se convierte en el cuello de botella que mata la ganancia de productividad o se convierte en un sello de goma que mata el control. Ambos resultados son malos, y las organizaciones que nunca tomaron la decisión explícitamente suelen obtener el segundo por defecto. La única respuesta estable es la clasificación por política: las máquinas despejan lo rutinario, los humanos revisan lo que las reglas señalan como consecuente, con la propia política propiedad de seguridad, no de quien escribió el prompt.

Y cuando algo sí sale mal, la pregunta de respuesta a incidentes se convierte en todo el juego: ¿puedes reconstruir qué cambió, quién o qué lo cambió, qué pruebas corrieron, y quién lo aprobó? Si la respuesta honesta es un log de chat en la cuenta de un contratista que ya se fue, no tienes un programa de garantía para el desarrollo con IA. Tienes exposición con buenas intenciones.

Espera que la presión externa también aumente. Auditores, aseguradoras cibernéticas y clientes enterprise han empezado a hacer preguntas directas sobre código generado por IA en cuestionarios de seguridad y evaluaciones de proveedor: cómo se revisa, qué pruebas lo filtran, si existe procedencia. Las organizaciones que puedan responder desde un registro de auditoría pasarán esas revisiones como rutina; las organizaciones improvisando respuestas sentirán cada una como un simulacro de incendio. Construir la maquinaria de evidencia ahora, antes de que un auditor específico la exija, es materialmente más barato que construirla durante un hallazgo.

La capa de gobernanza de Ciao se diseñó exactamente contra esta lista de verificación. Guardrails mapea el código en áreas de negocio, detecta cambios de riesgo, aplica políticas en lenguaje sencillo, registra la revisión humana y deja un registro de auditoría tras cada merge; el rastro es de solo adición y cubre prompts, merges, despliegues y acciones de administración. Security ejecuta análisis estático, comprobación de dependencias y pruebas de control de acceso, y confirma vulnerabilidades contra la app en vivo antes de señalarlas: la diferencia entre un feed de hallazgos en el que confía tu equipo y uno que silencian. QA filtra cada publicación con réplicas deterministas del navegador y ejecuta comprobaciones de producción después.

Del lado del riesgo de proveedor: los informes SOC 2 Tipo II están disponibles bajo NDA; la plataforma admite SSO vía SAML y OIDC, MFA opcional y control de acceso basado en roles; el código del cliente no se usa para entrenar modelos y la inferencia se ejecuta bajo contratos de modelo de retención cero; y una escalera de modelos multiproveedor con fallback reduce la dependencia de cualquier proveedor único. Los destinos de despliegue incluyen tu propia cuenta de AWS, Azure o GCP, VPC privada, u on-prem bajo términos aparte para cargas clasificadas. Los programas de desarrollo serios empiezan en 10.000 USD al año. Si estás construyendo el estándar interno para el desarrollo con IA, solicita el paquete de seguridad y puntúa a Ciao contra cada línea de arriba.

Una sugerencia de despliegue de equipos que lo han hecho bien: secuéncialo como inventario, luego vía sancionada, luego migración. Primero encuentra qué software construido con IA ya existe y quién lo posee; segundo, monta la plataforma gobernada y enruta los nuevos builds a través de ella; tercero, mueve las herramientas existentes en orden de radio de impacto. Publicar la propia lista de verificación como tu estándar interno, sea cual sea la plataforma que elijas, convierte una preocupación difusa en un programa puntuado y propio, y le da a las unidades de negocio una respuesta clara a «¿qué haría esto correcto?» en lugar de una puerta cerrada.