Un buen piloto de una plataforma de gestión de riesgo humano (Human Risk Management, o HRM) no se mide por cuántos empleados completaron una capacitación ni por cuánto bajó la tasa de click en el primer envío. Se mide por una sola cosa: si el comportamiento de las personas cambió cuando volvieron a estar bajo la presión de un ataque simulado. Y el primer paso no es elegir proveedor, es escribir, antes de empezar, qué resultado concreto justificaría la compra. Todo lo demás, la duración, la población, las métricas, se ordena a partir de esa definición.
La conclusión en una frase: qué debe demostrar un buen piloto
Un piloto sirve para responder una pregunta, no para llenar un tablero de actividad. La pregunta correcta es si la plataforma logra que una persona que cayó en un engaño deje de caer en el siguiente, no si el equipo hizo click en menos correos durante el mes de prueba. Esa distinción parece sutil y lo cambia todo, porque casi todas las herramientas muestran una caída inicial de la tasa de click y casi ninguna prueba que esa caída se sostenga.
El motivo por el que esto importa es que el riesgo que se está probando es humano, no técnico. El marco 90-5-5 de Cisco, que estima que cerca del 90 por ciento de las brechas involucran un factor humano, ubica el problema donde de verdad está: en cómo decide una persona bajo presión, no en si vio una diapositiva. Un piloto que mide conocimiento (¿aprobó el curso?) responde la pregunta equivocada. Uno que mide comportamiento (¿volvió a caer cuando lo probamos de nuevo?) responde la que decide la compra.
El riesgo humano se gestiona automáticamente.
Convierte el factor humano en tu primera línea de defensa.
Agenda un demoDemo gratuito · 30 minutos · Sin compromiso
Qué medir en el piloto (y por qué la tasa de click no basta)
La tasa de click de un solo envío mide un momento, no un aprendizaje. Una persona puede no hacer click en un correo porque estaba distraída, porque el mensaje no le aplicaba o porque ese día andaba desconfiada, y volver a caer en el próximo. Por eso el número que de verdad importa en un piloto no es el del primer disparo.
Hay evidencia revisada por pares que respalda esto de frente: completar una capacitación no predice por sí solo la reducción de fallos reales (Ho et al., IEEE Symposium on Security and Privacy 2025; Lain et al., IEEE S&P 2022). Lo que demuestra el cambio es volver a probar el comportamiento. A esa segunda prueba, con otra plantilla pero del mismo tipo y dificultad, se le llama retest, y es la métrica central de un piloto serio.
El correo sigue siendo el terreno donde se prueba, porque más del 90 por ciento de los ciberataques exitosos comienzan con un correo de phishing (CISA): si el piloto simula por el canal por el que de verdad entran los ataques, mide lo que va a pasar en producción.
Junto al resultado del retest, conviene mirar la tasa de reporte (¿la gente empezó a avisar los correos sospechosos en vez de solo evitarlos?) y la evolución del puntaje de riesgo por persona a lo largo de las semanas. Sobre qué mirar exactamente y por qué la tasa de click sola engaña, desarrollamos el tema en tasa de reporte, tasa de click y retest. La regla del piloto es simple: si una métrica no distingue entre "recordó ese correo" y "cambió su forma de reaccionar", no sirve para decidir.
Cuánto debe durar para ver cambio de comportamiento, no el susto inicial
La primera simulación casi siempre baja la tasa de click, y esa caída es el susto inicial, no un aprendizaje. La gente se pone alerta porque sabe que la están probando. Un piloto que termina ahí compra la ilusión del cambio, no el cambio.
Para ver comportamiento real, el piloto tiene que durar lo suficiente para cerrar al menos un ciclo completo: una simulación que revele quién cae, la remediación inmediata sobre quien falló, y el retest tres semanas después para validar que la lección se sostuvo. Eso pone el piso realista de un piloto en torno a las seis u ocho semanas, no en dos. Menos que eso mide el reflejo del primer susto; más que eso empieza a parecerse ya al despliegue. La pregunta que ordena la duración es directa: ¿alcanza el tiempo para que una misma persona falle, se remedie y vuelva a ser probada? Si la respuesta es no, el piloto es demasiado corto para concluir nada.
A quién incluir: por qué el piloto necesita masa suficiente
Un piloto de riesgo humano necesita masa estadística para que el puntaje por persona signifique algo. Por debajo de unas 25 personas, lo que se está midiendo son equipos, no individuos, y el valor de una plataforma de este tipo está justamente en distinguir a la persona, no en promediar al grupo. Un piloto de ocho personas puede sentirse ágil y no dice casi nada.
La población tampoco debe ser un rincón cómodo de la empresa. Un buen piloto incluye una muestra representativa: mezcla de roles y departamentos, y en especial los cargos de alta exposición, como finanzas, dirección y la mesa de ayuda, que son los que un atacante busca primero. Si el piloto solo cubre al equipo de tecnología, que suele ser el más difícil de engañar, el resultado se ve mejor de lo que es y no representa a la organización que va a comprar.
Criterios de éxito y de decisión, definidos antes de empezar
El error más caro de un piloto es decidir qué fue un éxito después de ver los números. Cuando el criterio se fija al final, siempre hay una métrica que se ve bien y sirve para justificar lo que ya se quería hacer. Por eso el criterio se escribe antes. En orden:
Con esos cinco puntos escritos y firmados antes de empezar, el piloto deja de ser una demostración de ventas y pasa a ser una prueba de la que se puede aprender aunque salga mal. Si quieres presionar al proveedor con las preguntas correctas antes de firmar, reunimos las que más pesan en diez preguntas para evaluar un proveedor de riesgo humano.
Del piloto al despliegue: qué habilita cada resultado
Un piloto bien diseñado no tiene un solo desenlace posible, tiene varios, y cada uno habilita una decisión distinta. Si el comportamiento mejoró en el retest, o sea si quienes cayeron dejaron de caer al ser probados de nuevo, el piloto validó lo que importaba y el despliegue está justificado con evidencia, no con fe. Si la tasa de click del primer envío bajó pero el retest volvió a fallar, el piloto reveló algo valioso: esa herramienta mide actividad, no cambio, y conviene mirar otra. Y si el monitoreo de credenciales expuestas encontró cuentas comprometidas desde el primer día, ya entregó un retorno concreto antes de medir una sola simulación.
Ese último punto conecta con por qué las empresas medianas adoptan cada vez más por piloto: es una categoría en fuerte crecimiento, con las pymes como el segmento que más rápido crece según Mordor Intelligence, y un piloto es la forma en que una empresa mediana valida el gasto antes de comprometerse. El piloto no es un trámite previo a la compra, es la mejor herramienta que tiene el comprador para no equivocarse.
En Fensivo diseñamos el piloto sobre las capacidades que ya operan: la implementación es por OAuth con Google Workspace o Microsoft 365, así que el sistema queda operativo en un día y el primer reporte ejecutivo de exposición de credenciales llega en 48 horas, sin esperar a acumular datos de comportamiento. A partir de ahí el ciclo prueba con simulaciones de phishing por correo, remedia sobre quien falla y valida con el retest a las tres semanas, sobre el foco de 25 a 500 empleados donde el puntaje por persona es válido. Puedes ver cómo se traduce esto en casos concretos en nuestros casos de uso.
La pregunta que dejamos abierta es incómoda a propósito: si tuvieras que decidir hoy sobre la plataforma que evaluaste el trimestre pasado, ¿sabrías decir si tu gente de verdad cambió, o solo sabrías cuántos completaron el curso?
Fuentes y referencias
Cisco, The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity, 2025: https://blogs.cisco.com/security/the-90-5-5-concept-your-key-to-solving-human-risk-in-cybersecurity CISA, 4 Things You Can Do To Keep Yourself Cyber Safe: https://www.cisa.gov/news-events/news/4-things-you-can-do-keep-yourself-cyber-safe Ho et al., IEEE Symposium on Security and Privacy 2025: https://ieeexplore.ieee.org/document/11023357 Lain et al., IEEE Symposium on Security and Privacy 2022: https://ieeexplore.ieee.org/document/9833766 Mordor Intelligence, Security Awareness Training Market: https://www.mordorintelligence.com/industry-reports/security-awareness-training-market
El riesgo humano se gestiona automáticamente.
Convierte el factor humano en tu primera línea de defensa.
Agenda un demoDemo gratuito · 30 minutos · Sin compromiso
