La IA puede ayudar a preparar funciones, pruebas y configuraciones para una aplicación empresarial. Sin embargo, que una pantalla responda correctamente durante una demostración no demuestra que la entrega esté lista para utilizar datos reales. El código necesita una revisión que conecte lo solicitado con lo que efectivamente cambiará.
Para empresas de Venezuela y Latinoamérica, esta responsabilidad también aplica cuando el desarrollo está contratado. La siguiente propuesta permite pedir evidencia concreta al equipo o proveedor antes de aprobar una versión, sin convertir cada entrega en una auditoría completa.
1. Define qué significa terminar el cambio
OWASP SAMM recomienda establecer dónde se permite utilizar IA en el desarrollo y qué controles acompañan cada uso. También mantiene la responsabilidad del software en la organización y sus equipos. [1]
Como aplicación práctica, escribe una ficha de aceptación antes de revisar el resultado. Si se pidió agregar un formulario de solicitudes, identifica sus campos, destinatario, datos permitidos y comportamiento esperado ante errores.
Acuerda quién explicará la solución y quién aprobará la entrega. Solicita una relación de componentes afectados, incluidos servicios externos. Así podrás contrastar una propuesta concreta con el alcance contratado, en lugar de aceptar únicamente una presentación que indique que todo funciona.
2. Comprueba las dependencias sugeridas
OWASP advierte que los asistentes pueden proponer paquetes inexistentes o versiones con vulnerabilidades conocidas. Recomienda verificar los componentes y auditar sus dependencias antes de incorporarlos. [2]
Pide una lista de bibliotecas nuevas con nombre exacto, versión, origen y motivo de uso. El responsable técnico debe comprobar que cada paquete corresponde al proyecto previsto y revisar su mantenimiento y avisos de seguridad.
Como control de aceptación, solicita que la versión entregada pueda reconstruirse utilizando los componentes registrados. Si un proveedor sustituye una biblioteca durante la revisión, actualiza la evidencia y repite las comprobaciones afectadas. Una explicación del asistente sobre la reputación de un paquete no sustituye esa verificación.
3. Revisa el cambio completo con una persona responsable
La guía de revisión de código de OWASP pide mayor atención a autenticación, autorizaciones, configuraciones de entrega y cambios de dependencias. También señala que las herramientas de revisión con IA complementan la aprobación humana de cambios relevantes para la seguridad. [3]
Solicita que el revisor examine la diferencia entre versiones y sus efectos sobre el resto de la aplicación. Si se agregó un formulario, revisa también el servicio que recibe los datos y dónde terminan almacenados.
Define qué hallazgos impedirían aceptar la entrega. Por ejemplo, como criterio interno, cualquier modificación no explicada en permisos administrativos debe quedar pendiente de aclaración. Divide las entregas demasiado grandes para que cada aprobación corresponda a cambios comprensibles.
4. Combina comprobaciones técnicas diferentes
Qualys describe controles complementarios para el proceso de construcción y entrega: análisis del código, revisión de componentes, búsqueda de credenciales y pruebas sobre aplicaciones en ejecución. Cada uno examina aspectos distintos. [4]
Pide resultados asociados a la versión candidata. Un informe anterior o de otro entorno no demuestra que esta entrega haya pasado las mismas comprobaciones. Registra alcance, fecha, herramienta utilizada y hallazgos pendientes.
Como práctica de gestión, acuerda qué evidencia necesita el aprobador para decidir. Si falta una comprobación relevante, identifica al responsable de completarla. Evita convertir la ausencia de resultados en una aprobación implícita por presión de calendario.
5. Verifica que las pruebas demuestren el requisito
OWASP advierte que los agentes pueden debilitar o eliminar pruebas para conseguir una ejecución satisfactoria. Recomienda revisar sus modificaciones y señala que las pruebas creadas por el mismo agente no proporcionan garantía independiente. [2]
Para el formulario del ejemplo, prepara casos de aceptación desde la necesidad del negocio: envío válido, campos obligatorios ausentes y fallo del servicio receptor. Utiliza datos ficticios y un entorno autorizado.
Pide comparar el resultado esperado con el observado. Conserva evidencia de las pruebas fallidas y de su corrección. Si cambió el requisito, documenta quién lo aprobó antes de modificar la prueba; el comportamiento observado no debe redefinir por sí solo lo aceptable.
6. Entrega una versión que pueda mantenerse
Propón una ficha final con versión, responsables, resultados y pendientes. Utiliza ITSM para coordinar el cambio y asignar seguimiento. Incluye instrucciones de reversión y una comprobación posterior del proceso empresarial afectado.
Si existe un SOC, acuerda qué señales del despliegue necesitan seguimiento y verifica su disponibilidad. No incluyas credenciales ni datos personales en el expediente cuando basten referencias protegidas.
Comienza aplicando estos criterios a una entrega pequeña. La aprobación debe permitir explicar qué cambió, qué se comprobó y quién atenderá un problema después.
Para complementar la revisión de tus desarrollos, conoce nuestros servicios de ethical hacking y pentesting y gestión de vulnerabilidades con Qualys. Si necesitas organizar estos controles, contacta a INSTALINE para definir el alcance.
Referencias oficiales
Consultadas el 27 de octubre de 2026.
