Primer borrador de registro de riesgos con causas y dependencias
Un registro de riesgos en blanco intimida, y los riesgos que un PM apurado enumera tienden a ser genéricos ("aumento de alcance", "problemas de recursos") en lugar de las dependencias y los cuellos de botella específicos que realmente hunden la entrega. La IA es buena para interrogar la descripción de un proyecto y sacar a la luz cadenas de causa-riesgo-consecuencia y dependencias entre workstreams que luego puedes cuestionar. Es una ayuda para pensar, no un oráculo — la probabilidad y el impacto que asigna son conjeturas por validar, no hechos.
Eres un asistente de gestión de riesgos para un gerente de proyectos. Basándote únicamente en los detalles del proyecto que te doy, ayúdame a construir un primer borrador de registro de riesgos. Sé específico para este proyecto — nada de riesgos genéricos de relleno. Resumen y objetivos del proyecto: {{project_summary}} Alcance, restricciones y cronograma: {{scope_constraints}} Dependencias conocidas (proveedores, equipos, aprobaciones, sistemas): {{dependencies}} Produce una tabla con las columnas: Riesgo (expresado como causa -> riesgo -> consecuencia) | Categoría | Probabilidad (A/M/B) | Impacto (A/M/B) | Mitigación sugerida | Rol responsable sugerido. Reglas: - Basa cada riesgo en la información que te di. Cuando un riesgo dependa de un supuesto, indica el supuesto explícitamente en una lista separada de "Supuestos que estoy asumiendo" en lugar de tratarlo como un hecho. - Prioriza los riesgos de dependencia, secuenciación, integración, aprobación y cuellos de botella de recursos por sobre amenazas vagas. - Marca todas las calificaciones de Probabilidad e Impacto como "BORRADOR — validar con el equipo". No las presentes como probabilidades medidas. - No inventes datos históricos, referencias ni estadísticas. Si necesitarías datos que no te di, dilo. - Termina con 3 a 5 preguntas cuyas respuestas cambiarían de forma sustancial el registro.
Rellena tus datos y el prompt se actualiza al instante — luego cópialo.
Riesgo: La limpieza de datos de operaciones de ventas se atrasa -> se migran registros sucios -> los usuarios pierden confianza en el nuevo CRM. Categoría: Datos / dependencia | Probabilidad: M (BORRADOR — validar) | Impacto: A (BORRADOR — validar) Mitigación: Fijar una fecha límite de limpieza dos semanas antes de la migración; auditar una muestra antes del corte. Responsable sugerido: Líder de Operaciones de Ventas Supuestos que estoy asumiendo: La revisión de seguridad corre en paralelo, no después, de la limpieza de datos. Preguntas que cambiarían este registro: - ¿Existe un plan de reversión si la migración falla en el corte? - ¿Quién aprueba que la calidad de los datos es "suficientemente buena" para migrar?
El flujo de trabajo completo
- Aliméntale al prompt tu resumen real del proyecto, restricciones y dependencias conocidas
- Revisa cada riesgo sugerido por su relevancia y elimina los genéricos que no aplican
- Valida cada calificación de probabilidad e impacto con el equipo y con datos históricos — no aceptes las calificaciones del borrador
- Asigna responsables reales, carga el registro en tu herramienta y revísalo con una cadencia fija
Cuidado con
La probabilidad y el impacto asignados por la IA son conjeturas, y el modelo puede pasar por alto el verdadero cuello de botella o inventar uno irrelevante. Trata el registro como un punto de partida para poner a prueba con el equipo y datos de proyectos anteriores — nunca envíes las alertas de riesgo de la IA directamente a decisiones o informes a la junta sin validación humana.
No pegues arquitectura confidencial, contratos con proveedores ni detalles que identifiquen al cliente en una herramienta de IA de consumo. Describe el proyecto en términos generales o usa una cuenta empresarial aprobada.
De dónde sale esto
Cada caso de uso de este sitio se basa en relatos reales de los gerentes de proyectos en activo — no lo inventamos nosotros.
Más casos de uso de IA para los gerentes de proyectos
Informes de estado semanales y actualizaciones para stakeholders a partir de notas en bruto
automatizaciónNotas de reuniones convertidas en decisiones, tareas y responsables
planificaciónBorradores de plan de proyecto y estructura de desglose del trabajo
redacciónConvertir un cambio de alcance en una comunicación clara para stakeholders
análisisSíntesis de retrospectivas y lecciones aprendidas
← Los 6 casos de uso: cómo los gerentes de proyectos usan la IA