¿Qué es un programa de evaluación del impacto de la IA?
Gobernanza, riesgo y aseguramiento
Un programa de evaluación del impacto de la IA es el proceso organizativo repetible para decidir cuándo debe evaluarse un sistema de IA o un caso de uso, qué ruta de evaluación corresponde, quién debe participar, qué evidencia debe registrarse, quién puede aprobar el riesgo residual y cuándo debe actualizarse la revisión. Es más amplio que una evaluación de impacto de IA individual. Un programa sólido vincula las obligaciones legales, la gobernanza, la contratación, los controles de despliegue, el seguimiento y la escalada, de modo que la evaluación se realice de forma temprana y coherente.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Puede entenderse como el modelo operativo que sustenta las evaluaciones individuales. En lugar de dejar que cada equipo decida de forma ad hoc si realizar una revisión amplia de IA, una DPIA o una evaluación centrada en derechos, el programa establece las preguntas de entrada, los umbrales de activación, las plantillas, los revisores, las rutas de aprobación y las normas de registro.
Esto importa porque la IA moderna se adquiere con frecuencia a proveedores, se integra en servicios más amplios y se modifica tras su lanzamiento. Un formulario puntual rara vez es suficiente. El programa debe abarcar tanto los sistemas desarrollados internamente como los adquiridos, distinguir entre una revisión ligera y una evaluación completa, y garantizar que se realice una reevaluación cuando cambien el caso de uso, el modelo, los datos, los usuarios o los grupos afectados.
Por qué importa
Sin un programa, usos similares de IA pueden recibir un tratamiento completamente distinto dentro de la misma organización. Un equipo realiza una revisión de privacidad, otro se apoya en la documentación del proveedor y un tercero despliega primero y pregunta después. Esto genera exposición legal, una rendición de cuentas débil y escasa evidencia cuando los consejos de administración, compradores, trabajadores, clientes, auditores o reguladores preguntan por qué se aprobó un sistema.
Un buen programa mejora la coherencia y la oportunidad. Ayuda a las organizaciones a detectar problemas antes del despliegue, a derivar los asuntos pertinentes a especialistas en privacidad, legal, seguridad, recursos humanos o contratación, a documentar por qué la IA es necesaria y proporcionada, y a demostrar que la aceptación del riesgo fue consciente y no accidental. En entornos regulados, también facilita la combinación de obligaciones superpuestas, como las DPIAs y las evaluaciones de derechos fundamentales, sin confundirlas.
Cómo funciona
Comienza con el alcance y las reglas de activación
El programa arranca con una fase de entrada, generalmente vinculada a la contratación, la aprobación de proyectos o el control de cambios. Los equipos responden a un conjunto breve de preguntas sobre la finalidad del sistema, el nivel de automatización, si pueden verse afectadas personas, si se utilizan datos personales, si la herramienta apoya decisiones sobre empleo, crédito, seguros, servicios públicos o seguridad, y si interviene un modelo o servicio de terceros. El objetivo no es someter cada uso de IA a la misma ruta, sino realizar una clasificación temprana y aplicar un nivel de revisión proporcionado.
Por eso los programas maduros distinguen entre una revisión ligera y una evaluación completa. La orientación oficial del sector público en Canadá lo señala con claridad: un sistema puede estar dentro del alcance incluso cuando un ser humano toma la decisión final, mientras que la investigación y la experimentación que no afectan a clientes reales pueden quedar fuera del proceso completo. Se trata de una lógica de gobernanza útil mucho más allá del sector público canadiense.
La responsabilidad recae en más de un lugar
Un programa suele tener un responsable central, a menudo en gobernanza, riesgo, privacidad o cumplimiento, pero cada caso de uso sigue necesitando un responsable de negocio designado. Las normas y las orientaciones de los reguladores apuntan en la misma dirección: la alta dirección sigue siendo responsable, los roles deben documentarse, los equipos necesitan formación y las decisiones sobre riesgos no deben dejarse únicamente en manos del personal técnico.
En la práctica, los colaboradores suelen incluir especialistas en legal, privacidad, seguridad, contratación, recursos humanos o sectores específicos, además de expertos en el área y, cuando proceda, personas que representen a los grupos afectados. Un comité de gobernanza de la IA central o un foro equivalente es entonces el lugar para las escaladas, las excepciones y las decisiones sobre riesgo residual material.
El programa elige la ruta de evaluación adecuada
La derivación es la función central. Algunos casos requieren una evaluación de impacto de IA amplia. Otros necesitan una DPIA porque implican el tratamiento de datos personales de alto riesgo. Otros requieren una revisión de derechos fundamentales bajo un régimen específico. Estas revisiones pueden compartir hechos y evidencias, pero no son idénticas y no deben fusionarse en un formulario genérico.
Esta distinción importa tanto en el ámbito legal como en la práctica de aseguramiento. En virtud del EU AI Act, ciertos responsables del despliegue de determinados sistemas de IA de alto riesgo deben realizar una evaluación de impacto sobre los derechos fundamentales antes del despliegue, y dicha evaluación complementa, en lugar de sustituir, a una DPIA cuando ambas son exigibles. La orientación oficial de aseguramiento del Reino Unido también distingue entre la evaluación de impacto prospectiva y la evaluación de impacto retrospectiva, lo que importa porque la verificación posterior al despliegue no puede sustituir a la revisión previa. Los métodos orientados a los derechos humanos, como HUDERIA, también resultan útiles aquí porque añaden una clasificación proporcional y la participación de las partes interesadas, en lugar de asumir que todos los casos requieren la misma profundidad.
Genera un expediente de evidencias, no solo una puntuación
Un programa creíble solicita evidencia suficiente para justificar la decisión de continuar. Esto incluye normalmente la finalidad prevista, el contexto de uso, las personas o grupos afectados, el momento y la frecuencia de uso, las fuentes y flujos de datos, el grado de supervisión humana, los beneficios esperados, los daños plausibles, las alternativas consideradas, las medidas de control, las vías de reclamación o recurso, la información del proveedor y una declaración clara del riesgo residual.
La evidencia debe ser comprensible tanto para los especialistas como para los responsables de la toma de decisiones de alto nivel. Para los usos de datos personales, la ICO señala que la DPIA debe explicar el tratamiento con claridad, incluir consultas cuando proceda, registrar la opinión del DPO si existe y mostrar si cada riesgo fue eliminado, reducido o aceptado. Para ciertos despliegues de alto riesgo en la UE, la ley solicita expresamente información sobre los grupos afectados, los riesgos específicos, las medidas de supervisión humana y los mecanismos internos de gobernanza y reclamación. Por tanto, un programa debe producir un registro de decisión utilizable, no solo un semáforo.
La aprobación, el despliegue y el seguimiento están vinculados
Un programa de evaluación debe estar integrado en las puertas de etapa. Ningún despliegue en producción debe producirse antes de que las revisiones requeridas estén completas y aprobadas al nivel adecuado. Los umbrales de aprobación suelen depender de la gravedad del daño, la sensibilidad legal y el impacto público. El registro debe alimentar después el registro de riesgos de IA, los controles de contratación, los avisos a trabajadores o usuarios, los planes de pruebas y la respuesta a incidentes.
Esto importa especialmente en los sistemas adquiridos. La contratación no transfiere la responsabilidad. Si un sistema está parcial o totalmente externalizado, la organización sigue necesitando información suficiente para evaluar el caso de uso en su propio contexto, comprender los roles de responsable y encargado del tratamiento cuando se manejan datos personales, y revisar las afirmaciones del proveedor si el servicio cambia.
Permanece activo tras el lanzamiento
Los mejores programas tratan la evaluación como un control vivo, no como un ejercicio de marcar casillas. Las revisiones se actualizan cuando un piloto pasa a producción, cuando cambian el modelo, el proveedor, los datos, el grupo de usuarios, la geografía o la finalidad, cuando aparecen incidentes o reclamaciones, o cuando el seguimiento revela desviaciones o nuevos daños.
Este es un patrón duradero en todos los marcos de referencia. NIST exige un seguimiento continuo y revisiones periódicas; la ICO describe la DPIA como un documento vivo; la AIA de Canadá debe actualizarse cuando cambian la funcionalidad o el alcance; y el EU AI Act exige actualizaciones cuando la evaluación original de derechos fundamentales ya no está al día. Un programa maduro también establece criterios de detención, reversión y reaprobación para los casos en que el riesgo se vuelve inaceptable.
Ejemplos
Una empresa quiere utilizar una herramienta de IA para filtrar candidatos a un puesto de trabajo. El programa debe derivar el proyecto a revisión antes de que se finalice la contratación, no después de firmar los contratos. Dado que la herramienta puede implicar la evaluación sistemática de aspectos personales y puede afectar al acceso al empleo, la organización debe comprobar si una DPIA es obligatoria, documentar una revisión humana significativa, consultar a las partes interesadas internas pertinentes y a los grupos afectados cuando proceda, y decidir si el proveedor debe modificar el producto o si se necesita un proveedor diferente.
Un departamento federal canadiense quiere automatizar parte de una decisión administrativa, como la evaluación de elegibilidad, admisibilidad o permisos. La orientación gubernamental exige una Evaluación de Impacto Algorítmico al inicio de la fase de diseño. El nivel de impacto determina entonces las medidas de mitigación, y la AIA debe revisarse y actualizarse si cambian la funcionalidad o el alcance del sistema. Canadá también considera que la automatización parcial puede estar dentro del alcance, incluso cuando un funcionario sigue tomando la decisión final.
Un organismo público de la UE, o una entidad privada que presta un servicio público, planea desplegar un sistema de IA de alto riesgo en un contexto en el que el EU AI Act exige una evaluación de derechos fundamentales. Antes del despliegue, el programa debe requerir una revisión específica del contexto sobre las personas y grupos afectados, los daños probables, el diseño de la supervisión humana y los mecanismos de reclamación y gobernanza. Si la normativa de datos personales también exige una DPIA, la evaluación de derechos debe complementarla y no sustituirla.
Malentendidos frecuentes
Idea errónea: si hay un ser humano implicado al final, el uso de IA queda fuera del programa.
Corrección: no necesariamente. Varios marcos oficiales analizan si el sistema influye o apoya el juicio, no solo quién pulsa el botón final.
Idea errónea: la documentación del proveedor es suficiente.
Corrección: la documentación del proveedor ayuda, pero el contexto de despliegue local sigue siendo relevante. La organización que despliega suele conservar obligaciones legales y de gobernanza importantes.
Idea errónea: una DPIA es el programa completo.
Corrección: una DPIA es una ruta de evaluación dentro del programa. Muchos usos de IA también plantean cuestiones de derechos, laborales, de contratación, seguridad, accesibilidad o derecho público.
Idea errónea: todas las herramientas de IA deben pasar por la misma revisión completa.
Corrección: los buenos programas utilizan la clasificación. Los usos internos de bajo riesgo pueden necesitar solo una revisión ligera, mientras que los usos sensibles o de alto impacto requieren una evaluación más profunda y una aprobación más rigurosa.
Idea errónea: la evaluación termina en el momento del lanzamiento.
Corrección: los programas maduros actualizan las revisiones cuando cambian la herramienta, los datos, el proveedor, los usuarios o el contexto, o cuando los incidentes, las reclamaciones o el seguimiento revelan nuevos riesgos.
Riesgos y límites
Un programa de evaluación del impacto de la IA no es en sí mismo un término jurídico universal. En la mayoría de las jurisdicciones, la obligación legal se vincula a evaluaciones o controles específicos, no a la etiqueta del programa. El programa es el marco organizativo que hace que esas obligaciones se cumplan de forma fiable y a tiempo.
También puede aplicarse de forma incorrecta. Si toda herramienta interna de bajo riesgo debe superar una revisión completa, el personal buscará la manera de eludir el proceso. Si el programa se convierte en un ejercicio de papel sin incidencia en la contratación, la aprobación o el seguimiento, genera una falsa sensación de seguridad. Y si las organizaciones se apoyan en afirmaciones genéricas de proveedores o en fichas de modelo sin una revisión específica del contexto, pueden pasar por alto los riesgos reales sobre derechos, entorno laboral o prestación de servicios que genera el despliegue local.
Algunos detalles legales siguen en desarrollo. En la UE, se han estado preparando orientaciones adicionales para los responsables del despliegue y una plantilla para las evaluaciones de impacto sobre los derechos fundamentales. Las organizaciones deben, por tanto, tratar las matrices de activación específicas de cada jurisdicción como documentos controlados que necesitan una actualización legal periódica, en lugar de asumir que la primera versión seguirá siendo completa.
Próximos pasos
Designe un responsable del programa y un foro de decisión. Elabore un proceso de entrada sencillo y un inventario de IA, y defina las reglas de derivación para las evaluaciones generales de IA, las DPIAs, las revisiones de derechos fundamentales y cualquier verificación sectorial específica. Establezca los requisitos mínimos de evidencia, los umbrales de aprobación, los desencadenantes de actualización y las normas de publicación o notificación cuando sean aplicables. Integre el proceso en la contratación, la aprobación de proyectos, el control de cambios y las puertas de despliegue, y forme a los revisores para que casos similares se evalúen de forma coherente en toda la organización. Por último, pruebe el programa con un caso de uso real y ajústelo antes de hacerlo obligatorio de forma más amplia.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Cuál es la diferencia entre una evaluación de impacto de IA y un programa de evaluación del impacto de la IA?
La evaluación es la revisión específica de un sistema o caso de uso concreto. El programa es el proceso organizativo repetible que decide cuándo se realizan las evaluaciones, qué ruta corresponde, quién las revisa y cómo se registran las decisiones.
¿Necesitan todos los sistemas de IA una evaluación completa?
No. Un buen programa comienza con la clasificación. Algunas herramientas solo necesitan una revisión ligera, mientras que los sistemas utilizados en decisiones sensibles, servicios públicos, empleo, crédito, seguridad o tratamiento de datos personales a gran escala suelen requerir una revisión más profunda.
¿Puede una sola revisión abarcar privacidad, derechos y ética conjuntamente?
Con frecuencia, la misma evidencia puede reutilizarse, pero las obligaciones legales no siempre son idénticas. Cuando se exigen tanto una DPIA como una evaluación de derechos fundamentales, las revisiones deben coordinarse en lugar de fusionarse de forma descuidada.
¿Quién debe ser responsable del programa?
Habitualmente, una función central de gobernanza, riesgo, privacidad o cumplimiento es la propietaria del proceso, mientras que cada caso de uso tiene un responsable de negocio designado. El riesgo residual material debe escalarse a un foro de alto nivel, como un comité de gobernanza de la IA.
¿Qué ocurre si solo adquirimos IA de un proveedor?
El programa sigue siendo necesario. Adquirir una herramienta no elimina la necesidad de evaluar el propio contexto, los datos, los usuarios, las obligaciones legales y la calidad de la evidencia del proveedor.
¿Cuándo debe actualizarse una evaluación?
Debe actualizarse cuando el sistema pasa de pruebas a producción, cuando cambian el modelo, el proveedor, los datos, la finalidad o el grupo de usuarios, o cuando los incidentes, las reclamaciones, el seguimiento o los cambios legales indican que la revisión original ya no está vigente.
¿Es esto principalmente una cuestión del sector público?
No. Los regímenes del sector público tienen algunas de las obligaciones de evaluación formal más claras, pero las organizaciones privadas también necesitan procesos de evaluación repetibles, especialmente cuando la IA afecta a trabajadores, clientes, prestatarios, pacientes o personas aseguradas.