El usuario quiere comprender el riesgo en el contexto de seguridad y riesgo de IA y aplicarlo a trabajos prácticos de gobernanza o cumplimiento de IA.
Usa riesgo para resultados adversos potenciales antes o durante la evaluación; usa daño para el efecto adverso que ya ocurrió o que puede describirse de forma concreta.
El riesgo es la posibilidad de un resultado adverso; el daño es el efecto adverso en sí. En la gobernanza de IA, el riesgo describe qué puede ocurrir, qué probabilidad tiene, qué gravedad podría alcanzar y qué controles se necesitan. El daño describe el perjuicio real o descrito de forma concreta para personas, derechos, seguridad, propiedad, organizaciones o sociedad. La evaluación de riesgos es prospectiva y preventiva; el análisis de daños se usa para comprender impacto, responsabilidad, reparación y lecciones después de un incidente o en torno a él.
El riesgo es la señal de advertencia; el daño es la lesión o pérdida sobre la que advierte esa señal. Un modelo de contratación puede tener riesgo de clasificación discriminatoria antes de que alguien se vea afectado. Si candidatos son rechazados injustamente, la organización ya está tratando con un daño. Una buena gobernanza intenta reducir el riesgo antes de que se convierta en daño y responder adecuadamente cuando el daño ocurre.
Analogía
El riesgo es la probabilidad y gravedad de que un puente falle; el daño es el colapso, la lesión, la interrupción o el coste si falla.
La distinción importa porque el trabajo jurídico, técnico y de gobernanza ocurre en etapas diferentes. El lenguaje de riesgo respalda revisiones de diseño, controles de contratación, evaluaciones de impacto, safety cases, selección de controles y aprobaciones de despliegue. El lenguaje de daño respalda quejas, respuesta a incidentes, remedios para usuarios, análisis de causa raíz, notificación, compensación y aplicación normativa. Si los equipos confunden ambos conceptos, pueden exagerar preocupaciones hipotéticas como si fueran daños probados o minimizar daños reales como si fueran solo riesgos teóricos. Un vocabulario claro mejora trazas de auditoría, informes al consejo, análisis regulatorio y responsabilidad de proveedores.
Urgencia
Los equipos deben separar el lenguaje de riesgo y daño en inventarios de IA, registros de riesgo, registros de incidentes y evidencia de seguridad.
Un registro práctico de riesgo de IA debe identificar el peligro o modo de fallo, partes afectadas, daños potenciales, probabilidad, gravedad, detectabilidad, controles existentes, riesgo residual y responsable. Un registro de daño debe identificar qué ocurrió, quién o qué fue afectado, evidencia, gravedad del impacto, causas raíz, mitigación, reparación, notificaciones y lecciones aprendidas. La evaluación de riesgos debe realizarse antes del despliegue y cuando ocurran cambios materiales. El análisis de daño debe realizarse cuando fallos, quejas, incidentes, cuasi incidentes o señales de monitoreo indiquen que pueden haber ocurrido efectos adversos.
El error más común es escribir riesgos vagos como «sesgo de IA» sin identificar el daño específico, grupo afectado, punto de decisión y control. Otro error es tratar el daño como si solo fuera lesión física. En sistemas de IA, el daño puede incluir discriminación, denegación de acceso, intrusión en la privacidad, pérdida económica, daño reputacional, angustia psicológica, compromiso de seguridad o pérdida de autonomía. Los equipos también fallan cuando mantienen registros de riesgo y registros de incidentes desconectados, dificultando aprender si los riesgos previstos se convirtieron en daños reales.
Error 1: Registrar «riesgo de alucinación» sin explicar si el daño posible es error legal, desinformación médica, pérdida financiera o engaño del usuario.
Error 2: Llamar solo riesgo a una fuga de privacidad documentada después de que los usuarios afectados ya hayan quedado expuestos.
Esta página debería enlazar con risk, harm, ai-risk-assessment, safety-case y ai-safety. La comparación más sólida es risk-vs-harm porque respalda una documentación de gobernanza de IA más limpia. También debería conectarse con safety-case-vs-ai-risk-assessment cuando los equipos necesiten entender la diferencia entre identificar daños posibles y construir un argumento de seguridad respaldado por evidencia. Las preguntas relacionadas incluyen what-is-ai-safety, what-is-a-safety-case-for-ai y what-is-model-drift.