Evaluación de impacto de IA después del despliegue: el error que llega tarde

Parece una pregunta de calendario: ¿cuándo se hace la evaluación de impacto de un sistema de inteligencia artificial? Pero la respuesta cambia todo lo que sigue. En los proyectos de implementación que revisamos con más frecuencia, la evaluación de impacto se hace después de que el sistema ya está en producción, cuando ya no puede cambiar nada del diseño. Este es uno de los errores que ISO/IEC 42001 pide evitar de forma explícita, porque convierte un control preventivo en un trámite de archivo.

Qué pide ISO/IEC 42001 sobre la evaluación de impacto

ISO/IEC 42001 pide que la organización identifique, dentro de su proceso de gestión de riesgos de IA, el impacto potencial de cada sistema sobre las personas: qué datos usa, sobre quién decide o influye, y qué consecuencias tendría un error. No es un formulario que se llena una vez. Es un análisis que debe estar listo a tiempo para influir en decisiones de diseño: qué datos se excluyen, dónde se necesita una persona revisando, y si el sistema debería ajustarse —o no desplegarse— tal como está planteado.

El error: hacer la evaluación después del despliegue

La diferencia entre hacer la evaluación de impacto antes o después del despliegue no es de forma, es de función. Antes del despliegue, la evaluación todavía puede cambiar el diseño del sistema: qué datos se usan, a quién se le aplica, dónde hace falta una persona revisando. Después del despliegue, la evaluación solo puede documentar lo que ya ocurrió. Y en medio de ese lapso hay personas afectadas —clientes, candidatos, empleados— de una forma que se pudo haber evitado si la evaluación hubiera llegado a tiempo.

Por qué pasa

Casi siempre pasa por presión de fechas. El equipo de producto o tecnología ya construyó el sistema, ya lo probó técnicamente, y lo considera «listo». La evaluación de impacto llega entonces como un paso adicional que retrasa un lanzamiento que ya se había comunicado hacia arriba. En ese contexto, es fácil que la evaluación se convierta en un documento que se llena para tener evidencia ante una eventual auditoría, en lugar de un análisis que realmente pudo haber cambiado algo del sistema.

Cómo se hace bien

Corregir este error es, sobre todo, una decisión de secuencia dentro del proyecto, no un documento nuevo:

• Fijar el punto de entrada. La evaluación de impacto se define como un entregable obligatorio antes de la etapa de despliegue, no como una validación posterior.
• Definir quién puede detener el proyecto. Antes de que exista presión de fecha, se decide qué área tiene autoridad para pausar un despliegue si la evaluación encuentra un riesgo relevante.
• Conectar la evaluación con el diseño. El resultado de la evaluación alimenta decisiones concretas: qué datos se excluyen, qué controles se agregan, dónde se necesita supervisión humana.
• Revisar la evaluación cuando el sistema cambia. Un sistema de IA no es estático; si se reentrena con datos nuevos o se aplica a un uso distinto, la evaluación se revisa de nuevo.

Un ejemplo: el sistema de preselección de personal

Una empresa desarrolla un sistema de IA para preseleccionar currículums antes de que un reclutador los revise. El equipo de tecnología lo prueba, funciona bien técnicamente y se anuncia como listo para producción en dos semanas. La evaluación de impacto —qué candidatos podrían quedar sistemáticamente excluidos por sesgos en los datos de entrenamiento— se agenda para «después del lanzamiento, cuando haya tiempo». Tres meses después, alguien nota que el sistema descarta de forma desproporcionada currículums con huecos laborales, sin distinguir sus causas. Para entonces, cientos de candidatos ya fueron afectados. Si la evaluación hubiera ocurrido antes del despliegue, ese patrón se habría detectado con los datos de prueba, y el diseño se habría podido ajustar antes de que produjera un efecto real sobre personas reales.