Por qué está escrito así
Si le pides a una IA una lista de verificación de seguridad sin más contexto, casi siempre te devolverá un índice de libro de texto. La mitad de los veinte puntos corresponderán a funciones que ni siquiera usas, mientras que los puntos verdaderamente críticos de tu despliegue quedarán fuera. Tras leer la lista, la única sensación que queda es: «¿Y ahora qué reviso exactamente?».
El rol de «especialista con experiencia en equipos pequeños» se eligió deliberadamente por una cuestión de alcance. La perspectiva de un auditor de seguridad para grandes corporaciones prioriza políticas internas y requisitos documentales inviables para un equipo de tres o cuatro personas. Una lista imposible de cumplir se hojea una vez y se archiva; es mejor plantear desde el inicio lo que realmente se puede ejecutar.
La clave está en dividir la instrucción: primero identificar los vectores de ataque y luego generar los puntos de control. Obligar a detallar las rutas de ataque saca a la luz los riesgos particulares de la arquitectura —como el flujo de autenticación propio, la subida de archivos o la exposición del panel de administración—, y los puntos de revisión se anclan directamente a ellos. Invertir este orden genera listas genéricas que solo llevan el nombre del proyecto como adorno.
En el formato de salida, la columna «Cómo verificarlo» convierte la lista en tareas accionables. Una frase abstracta como «validar las entradas del usuario» no da instrucciones claras, pero indicar qué archivo abrir o qué ajuste mirar permite ejecutar la comprobación de inmediato. Por último, el párrafo de auto-revisión filtra los elementos que suelen colarse por inercia en el primer paso. Aun así, una lista generada por IA es solo un punto de partida: si manejas datos personales o pagos, siempre será necesaria la revisión de un profesional.
¿Términos desconocidos? Consulta Aha AI: role-prompting, output-format
Comparado con un mal ejemplo
Dame una lista de comprobación de seguridad que deba revisar antes de desplegar un servicio web.
Genera una lista genérica que se puede encontrar en cualquier sitio. Se pierde tiempo revisando funciones que no se usan y se pasan por alto las partes más críticas del servicio, como un sistema de autenticación propio o paneles de administración expuestos. Al carecer de instrucciones sobre «qué y cómo comprobar», no se puede delegar en el equipo y, al final, una sola persona acaba revisando por intuición antes de subir a producción.
Variaciones
Para auditar un servicio que ya está en producción
Quiero realizar una auditoría tardía de {{tipo de servicio}}, que ya se encuentra en producción. La arquitectura utilizada es {{pila tecnológica}} y maneja {{datos a manejar}}. Separa los puntos que se pueden comprobar sin interrumpir el servicio de aquellos que requieren una ventana de mantenimiento. Añade a cada elemento una línea con una medida de mitigación temporal en caso de detectar un problema.
El orden de revisión cambia cuando el servicio ya está activo. Empezar por lo que se puede auditar sin detener la operativa evita posponer la revisión.
Para enfocar únicamente la revisión de código (Code Review)
Genera una lista para revisión de código enfocada en los puntos donde suelen aparecer fallos de seguridad en {{pila tecnológica}}. Agrupa los elementos por tipo de archivo o función y redacta frases cortas con la estructura «Desconfía si ves un código como este». Limita la lista a un máximo de 10 puntos y sitúa al principio los que afecten directamente al tratamiento de {{datos a manejar}}.
Esta lista se utiliza durante la lectura del código y no justo antes del despliegue. Se puede integrar directamente en las pautas de revisión del equipo.
Notas por modelo
La lista generada aquí es un punto de partida para una autoinspección, no un informe de diagnóstico de seguridad formal. Si manejas datos personales o pagos, contrata una auditoría profesional independiente.
Prompts relacionados
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos