Cuándo aplica la gestión de riesgos de IA y qué hacer después

La gestión de riesgos de IA aplica cuando un sistema, una función, una capacidad de proveedor o un proceso interno puede tener consecuencias significativas para personas, datos, seguridad, clientes o la empresa. No hace falta que el sistema sea de alto riesgo conforme al Reglamento de IA para justificar una revisión. Privacidad, seguridad, fiabilidad, contratos y riesgo operativo pueden exigir controles por sí mismos.

Para un equipo SaaS, la prueba práctica es esta: ¿el uso puede cambiar una decisión, exponer información protegida, afectar a alguien, crear contenido para clientes, automatizar una tarea importante o generar un compromiso que la empresa deba defender? Si la respuesta es sí o no está clara, registre el caso, asigne un responsable y sométalo a una evaluación proporcional antes de adoptarlo o lanzarlo.

Cuándo revisar un uso

Incluya IA orientada a clientes, modelos propios, API de modelos, funciones integradas de proveedores y herramientas de terceros usadas por empleados. La revisión suele ser necesaria si se tratan datos personales o confidenciales; si los resultados influyen en acceso, prioridad u otras consecuencias; si se usan sin revisión humana eficaz; si la IA puede ejecutar acciones; o si cambian finalidad, datos, modelo, proveedor, mercado o usuarios.

Para usos de bajo impacto, la revisión puede ser ligera. Lo esencial es decidir y documentar el alcance conscientemente.

Cuándo aplica una obligación jurídica concreta

La gestión general de riesgos y el cumplimiento del Reglamento de IA están relacionados, pero no son lo mismo. Las obligaciones dependen del sistema, la finalidad prevista, el rol de la organización, la categoría de riesgo y la fecha de aplicación. Una empresa SaaS puede ser proveedor en una función e implementador en una herramienta interna.

El artículo 9 exige que los proveedores de sistemas de IA de alto riesgo establezcan, implanten, documenten y mantengan un sistema de gestión de riesgos. Es un proceso continuo e iterativo durante todo el ciclo de vida: identificar riesgos conocidos y razonablemente previsibles, estimarlos en el uso previsto y el uso indebido previsible, incorporar datos de seguimiento poscomercialización, adoptar medidas específicas y probar el sistema. Como el calendario de aplicación ha evolucionado, conviene consultar la página oficial vigente de la Comisión Europea.

Cinco preguntas de triaje

1. ¿Cuál es la finalidad real, quién usa el sistema y a quién afecta?
2. ¿Qué datos entran, qué resultados salen y cómo se conservan?
3. ¿El resultado es borrador, consejo, recomendación, prioridad o acción automática?
4. ¿Qué puede fallar: exactitud, sesgo, privacidad, seguridad, propiedad intelectual o continuidad?
5. ¿Qué normas, contratos, compromisos e instrucciones internas importan?

Flujo operativo

Cree una entrada estable de inventario con responsable, finalidad, modelo o proveedor, usuarios, afectados, datos, nivel de automatización, mercados y fecha de revisión. Una persona debe mantener completo y actualizado el expediente, aunque producto, ingeniería, seguridad, privacidad y legal adopten decisiones especializadas.

Documente rol, contexto e impacto. El NIST AI RMF organiza el trabajo en Govern, Map, Measure y Manage, con la gobernanza a lo largo del ciclo de vida. Seleccione pruebas proporcionadas: exactitud, modos de fallo, privacidad y seguridad, impacto, red teaming, accesibilidad o evidencias del proveedor. Defina umbrales cuando sea posible y deje constancia de límites e incertidumbre.

Los controles deben responder a riesgos identificados: minimización de datos, entradas prohibidas, configuración, acceso, confirmación humana, límites de acción, registros, avisos, alternativas, seguimiento y escalado. Identifique al dueño y la evidencia de cada control, y registre si el uso queda aprobado, condicionado, pausado o rechazado.

Reevalúe cuando cambien finalidad, usuarios, datos, modelo, proveedor, automatización, geografía, situación legal o comportamiento observado.

Evidencias y errores comunes

Conserve inventario, finalidad y rol, evaluación, flujo de datos, documentación del proveedor, pruebas, límites, aprobaciones, controles, supervisión humana, monitorización, incidentes e historial de cambios. Evite confundir una política con evidencia, revisar solo funciones para clientes, sustituir la evaluación por documentación del proveedor, aplicar el mismo proceso a todos los casos y omitir desencadenantes de cambio.

Preguntas frecuentes

¿Solo aplica a sistemas de alto riesgo?

No. El artículo 9 crea una obligación específica para proveedores de sistemas de alto riesgo. Otros sistemas pueden requerir gestión proporcional por privacidad, seguridad, contratos, expectativas de clientes o compromisos voluntarios.

¿Qué se documenta primero?

Finalidad, responsable, usuarios, afectados, datos, modelo o proveedor, uso del resultado, supervisión humana, rol, riesgos, controles, aprobación y desencadenantes de reevaluación.