# Cómo evaluar un pentest con IA: alcance, evidencia y límites Cómo evaluar un servicio de pentesting con IA: autorización, alcance, verificación de hallazgos, reporte y validación de remediaciones. ## Qué aporta la IA a una prueba de penetración Los agentes pueden ayudar a explorar aplicaciones y relacionar señales para investigar posibles fallas. El valor del servicio depende de los hallazgos que pueda verificar y explicar, no del número de agentes ni del volumen de alertas. La cobertura siempre depende del alcance, los accesos y el tiempo disponibles. ## Antes de iniciar Confirma que puedes autorizar pruebas sobre el sistema. Define dominios, entornos, cuentas y operaciones permitidas, así como exclusiones y un contacto para detener la evaluación. En AI hackers el reporte es privado; no se publican los resultados de un objetivo como contenido del sitio. ## De una alerta a una corrección Revisa evidencia, condiciones de reproducción e impacto con el responsable de la aplicación. Prioriza las correcciones según exposición y consecuencias para el negocio. Tras aplicar un cambio, repite la comprobación pertinente para verificar que resuelve el problema sin afectar el flujo legítimo. ## Qué no garantiza una evaluación Un reporte sin hallazgos no demuestra ausencia de vulnerabilidades. Las pruebas tampoco equivalen por sí solas a una certificación. Si necesitas validar lógica de negocio, accesos internos o un requisito contractual, inclúyelo explícitamente en el alcance antes de comenzar. ## Distinguir exploración, verificación y cobertura Una herramienta puede descubrir rutas o señalar un comportamiento extraño sin demostrar una vulnerabilidad. Pregunta cómo pasa de esa señal a una afirmación verificable y qué evidencia conserva. El alcance debe explicar si se revisará únicamente la superficie pública o también sesiones autenticadas y roles diferentes. La cantidad de solicitudes, agentes o alertas no permite comparar cobertura por sí sola. Dos evaluaciones con el mismo objetivo pueden tener accesos y restricciones muy distintos; la propuesta tiene que hacer esas diferencias visibles antes de iniciar el trabajo. ## Documentar las reglas de la evaluación Un alcance útil nombra dominios, entornos, cuentas, horarios y operaciones permitidas. También incluye exclusiones, límites de carga y un contacto con autoridad para detener las pruebas. Si la aplicación utiliza proveedores externos, sus sistemas se tratan como dependencias y no como objetivos autorizados por defecto. El equipo necesita saber si puede crear registros de prueba, modificar datos o activar correos. Dejar esos detalles para el momento de ejecución genera ambigüedad y puede impedir validar precisamente los procesos que más interesan al negocio. ## Proteger datos y evidencias Antes de entregar accesos, acuerda cómo se custodiarán credenciales, resultados y capturas. Utiliza cuentas con permisos adecuados al alcance y datos de prueba cuando sea posible. El reporte no necesita conservar contraseñas ni información personal completa para explicar un hallazgo. También deben definirse acceso al informe, retención y eliminación de materiales al terminar. Si participa un sistema de IA externo, pregunta qué información recibe y con qué condiciones. El uso de automatización no elimina la responsabilidad de controlar dónde quedan los datos del objetivo. ## Valorar el impacto con el equipo de la aplicación Una clasificación de severidad necesita contexto. Importan la exposición del componente, los permisos requeridos, los datos afectados y el proceso que puede interrumpirse. La evaluación debe distinguir hechos observados de hipótesis que no se pudieron comprobar. Una alerta de versión antigua tampoco demuestra por sí sola que una vulnerabilidad sea explotable en esa configuración. El responsable de la aplicación aporta contexto para priorizar y planear la corrección. Cuando hay incertidumbre, debe conservarse en el reporte en vez de transformarse en una afirmación definitiva. ## Aceptar un reporte y verificar las correcciones La entrega debe describir activos evaluados, metodología, hallazgos y limitaciones. Para cada problema relevante pide ubicación, evidencia depurada, condiciones de reproducción y una corrección aplicable. La aceptación puede incluir una sesión con ingeniería para resolver dudas y asignar responsables. Tras corregir, se repite la comprobación pertinente y se confirma que el flujo legítimo funciona. Si esa validación posterior tiene límites de tiempo o cobertura, deben quedar por escrito. Una tarea marcada como cerrada no demuestra que la causa se haya resuelto. ## Elegir cuándo complementar la automatización La lógica de negocio, los permisos complejos y los procesos internos pueden necesitar conocimiento que una evaluación externa no tiene. Si una aplicación maneja aprobaciones, saldos o datos de distintas organizaciones, proporciona reglas esperadas y ejemplos de uso autorizado. Una revisión de código puede complementar la observación externa cuando forma parte del alcance. El criterio de selección es qué preguntas necesitas responder y qué evidencia obtendrás. Si la propuesta no cubre una necesidad contractual o técnica, se debe ampliar el alcance o elegir otra forma de revisión, sin atribuir capacidades no demostradas a la IA. Fuente: https://owasp.org/www-project-web-security-testing-guide/