¿Qué es una biblioteca de controles de IA?
Gobernanza, riesgo y aseguramiento
Una biblioteca de controles de IA es un catálogo estructurado de los controles, pruebas y evidencias que una organización utiliza para convertir la política de IA, las obligaciones legales y los estándares en prácticas repetibles. Vincula cada requisito a un responsable de control designado, un método de prueba y una evidencia, como registros, informes, aprobaciones o registros de incidentes. No es una ley ni una política por sí misma. Es la capa operativa que hace que la gobernanza de la IA sea coherente, revisable y más fácil de auditar.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Conviene entender una biblioteca de controles de IA como el puente entre los principios y el trabajo cotidiano. Una política puede establecer que los sistemas de IA deben ser seguros, estar documentados, supervisados y sujetos a control humano. La biblioteca de controles convierte eso en controles concretos que los equipos pueden ejecutar: quién debe realizar la verificación, cuándo debe realizarse, a qué norma o regla se refiere, cómo se prueba y qué evidencia debe conservarse.
Es diferente de una política de IA, que establece intenciones y reglas, y diferente de una salvaguarda de IA, que es una medida de protección específica dentro de un modelo, una capa de instrucciones o un flujo de trabajo. Tampoco es el sistema de gestión de IA en su conjunto. Es un componente operativo dentro de ese sistema más amplio. Los auditores lo utilizan para comprobar si los controles están bien diseñados y se cumplen; un registro de riesgos lo usa para mostrar cómo se están tratando los riesgos; y un plan de respuesta a incidentes se apoya en él cuando un control falla o surge un problema en producción.
Por qué es importante
La gobernanza de la IA depende cada vez más de la evidencia, no solo de los principios. Las organizaciones se enfrentan ahora a preguntas de reguladores, clientes, consejos de administración, inversores y equipos de contratación que son prácticas, no abstractas: ¿qué se probó?, ¿quién aprobó el lanzamiento?, ¿qué registros existen?, ¿cómo se supervisan los sistemas en producción?, ¿cómo se gestionan los modelos de terceros?, ¿qué ocurre si el sistema causa daño? Sin una biblioteca de controles, esas respuestas suelen estar dispersas entre equipos, herramientas y documentos.
Una buena biblioteca hace que la gobernanza sea repetible. Proporciona a los equipos de producto, ingeniería, datos, seguridad, legal, contratación y cumplimiento un punto de referencia común. Ayuda a la organización a reutilizar un mismo control en varios marcos cuando tiene sentido hacerlo, a elaborar paquetes de evidencia más ordenados para la garantía y la auditoría, y a actualizar los controles cuando cambian los incidentes, los modelos o las obligaciones legales. Esto importa especialmente cuando la IA tiene un alto impacto, pero también es relevante para la compra rutinaria, el despliegue y la supervisión interna.
Cómo funciona
Comienza clasificando el origen de cada requisito
Una biblioteca de controles suele comenzar reuniendo las fuentes relevantes para la organización: legislación, orientaciones regulatorias, estándares técnicos, compromisos de contratación, normas sectoriales y política interna. Cada requisito debe etiquetarse según su origen y su fuerza legal. Esa distinción es fundamental. Algunos controles son vinculantes porque la legislación o un contrato los exige. Otros son voluntarios, pero igualmente útiles porque reflejan buenas prácticas reconocidas. El AI RMF de NIST y su guía de apoyo son expresamente voluntarios y están pensados para adaptarse al contexto. ISO/IEC 42001 enmarca la gobernanza de la IA como parte de un sistema de gestión. El EU AI Act, en cambio, convierte algunos controles en obligaciones vinculantes para los actores dentro de su ámbito de aplicación. Una biblioteca útil separa claramente estas categorías, de modo que los equipos sepan qué verificaciones son obligatorias y cuáles se adoptan como buenas prácticas internas.
Cada control se redacta como un registro operativo
Una biblioteca madura va más allá de enumerar nombres de controles. Cada entrada suele necesitar una declaración de control clara, los sistemas o casos de uso que cubre, el desencadenante para aplicarlo, el responsable, la periodicidad de revisión, el método de prueba, la evidencia requerida, la ruta de escalada si la verificación falla, y las leyes o estándares con los que se relaciona. Si faltan esos campos, la biblioteca se convierte en una lista de verificación imprecisa en lugar de un activo operativo. Si están claros, los equipos pueden usar la misma biblioteca para controles de lanzamiento, revisiones de proveedores, garantía interna, preparación de auditorías e informes al consejo de administración.
Las buenas bibliotecas combinan controles de gobernanza y controles técnicos
La gobernanza de la IA no se limita a las pruebas de modelos. Las bibliotecas eficaces incluyen controles organizativos como el inventario de sistemas, la rendición de cuentas, la formación del personal, las verificaciones de contratación, los acuerdos con proveedores y los canales de comunicación con las autoridades. También incluyen controles técnicos y procedimentales como la gestión de datos, la validación, el registro, la supervisión humana, las comprobaciones de robustez, las medidas de ciberseguridad, la monitorización y el control de cambios. Esta estructura mixta refleja el funcionamiento de los marcos modernos. NIST distribuye la gestión de riesgos entre las funciones de gobernar, mapear, medir y gestionar. El EU AI Act exige gestión de la calidad, gestión de datos, pruebas, documentación, registros, monitorización y rendición de cuentas. Una biblioteca práctica refleja esa amplitud en lugar de tratar la gobernanza de la IA como una tarea de ingeniería de alcance reducido.
Las pruebas y la evidencia forman parte del propio control
Un control sin evidencia es solo una afirmación. Por eso, el registro del control debe indicar tanto cómo se prueba como qué evidencia se considera válida. Según el control, esto puede incluir documentación técnica, registros de validación, registros de actividad, registros de aprobación, historial de pruebas y evaluaciones conservado, informes de monitorización, registros de formación, documentos de proveedores o expedientes de incidentes. Las orientaciones públicas sobre garantía señalan lo mismo en términos más amplios: la confianza depende de evidencia fiable, estandarizada y accesible. En otras palabras, la biblioteca no solo debe indicar qué control existe, sino también cómo puede comprobar un revisor que realmente se ejecutó, si superó la verificación y qué ocurrió si no fue así.
La monitorización y los incidentes alimentan la siguiente versión de la biblioteca
Una biblioteca de controles de IA debe cambiar cuando cambia la realidad. La monitorización en producción, las reclamaciones de usuarios, las revisiones internas y los incidentes deben retroalimentar la biblioteca. Eso es lo que convierte la gobernanza de un ejercicio de lanzamiento en un control continuo. El EU AI Act hace explícita esta lógica para los sistemas de alto riesgo al exigir un sistema documentado de monitorización poscomercialización y al vincular la notificación de incidentes graves a la investigación y a las acciones correctivas. El trabajo de la OECD sobre notificación de incidentes apunta en la misma dirección a nivel internacional, promoviendo criterios interoperables para describir incidentes. En la práctica, una biblioteca madura debe registrar qué controles deben reforzarse, añadirse o retirarse tras un fallo, un casi accidente, una actualización importante del modelo o un cambio en el contexto de despliegue.
La responsabilidad es centralizada; la ejecución, distribuida
Un equipo debe mantener la biblioteca como registro de referencia, generalmente una función de gobernanza, riesgo o cumplimiento. Pero los propios controles suelen ser responsabilidad de distintas áreas del negocio. Los equipos de producto pueden ser responsables de las verificaciones de lanzamiento. Los equipos de datos pueden ser responsables de los controles de linaje y retención de datos. Los equipos de seguridad pueden ser responsables de los controles de acceso, registro y resiliencia. Los equipos legal y de contratación pueden ser responsables de los controles de proveedores y contratos. La dirección puede ser responsable de las aprobaciones, la gestión de excepciones y las decisiones sobre recursos. La auditoría interna u otras funciones de garantía independientes comprueban entonces si los controles están bien diseñados y si los equipos pueden realmente aportar la evidencia que esos controles requieren.
Ejemplos
Ejemplo actual en la UE: cuando una organización actúa como proveedor de un sistema de IA de alto riesgo en la UE, el lenguaje vago de las políticas no es suficiente. El proveedor necesita un sistema de gestión de la calidad documentado, procedimientos definidos de examen, prueba y validación, documentación técnica actualizada, registros bajo su control, un plan de monitorización poscomercialización y un canal para notificar incidentes graves. En la práctica, una biblioteca de controles es el mecanismo mediante el cual esas obligaciones se asignan a responsables designados y se convierten en verificaciones de lanzamiento, expedientes de evidencia, reglas de escalada y pasos de acción correctiva.
Ejemplo de IA generativa: el perfil GenAI de NIST muestra cómo una biblioteca puede incorporar controles que las declaraciones de política genéricas suelen omitir. Señala prácticas como conservar el historial de pruebas, evaluación, verificación y validación; habilitar prácticas de prueba e identificación de incidentes; planificar el intercambio de información y la divulgación; realizar red teaming antes de un lanzamiento más amplio; y actualizar los planes de respuesta y recuperación ante incidentes a medida que aparecen nuevos usos y riesgos. En una biblioteca de controles, cada uno de esos aspectos se convierte en un control repetible con un responsable, un elemento de evidencia, una periodicidad de revisión y una ruta de remediación.
Ejemplo actual de garantía: el AI Verify Toolkit ilustra una forma práctica de conectar las verificaciones técnicas y de gobernanza. Los desarrolladores pueden ejecutar pruebas técnicas mientras los equipos de cumplimiento trabajan de forma independiente con sus listas de verificación, antes de combinar ambas en un informe más completo. Esa estructura es útil cuando una organización necesita demostrar a un consejo de administración, cliente o revisor no solo que se realizaron pruebas, sino qué controles se verificaron, por quién y con qué evidencia.
Malentendidos frecuentes
Un malentendido habitual es pensar que una biblioteca de controles de IA es simplemente una hoja de cálculo. Puede comenzar en una hoja de cálculo, pero solo resulta útil cuando cuenta con control de versiones, responsabilidad asignada, requisitos mapeados y evidencia recuperable.
Otro malentendido es creer que es lo mismo que una política de IA. Una política establece lo que la organización espera. La biblioteca de controles indica cómo se implementan, prueban y evidencian esas expectativas.
Un tercer malentendido es pensar que solo abarca la calidad técnica del modelo. En la práctica, muchos controles importantes son organizativos o procedimentales, incluidos la gobernanza de proveedores, la formación, el mantenimiento de registros, la supervisión humana y la escalada.
También es un error asumir que un marco puede copiarse íntegramente. Los marcos públicos están diseñados para adaptarse al contexto, el riesgo y el ámbito legal, no para trasladarse sin cambios a cada caso de uso.
Por último, disponer de una biblioteca no hace por sí solo que una organización cumpla la normativa. La pregunta real es si los controles están bien elegidos, se utilizan realmente y están respaldados por evidencia creíble.
Riesgos y límites
No existe una definición legal única y globalmente fijada del término "biblioteca de controles de IA". Conviene entenderla como un artefacto de gobernanza que ayuda a las organizaciones a organizar y demostrar el cumplimiento de las obligaciones subyacentes. Eso significa que la biblioteca en sí misma no es la prueba legal. La prueba legal es si los controles subyacentes satisfacen las normas aplicables a un sistema, caso de uso y jurisdicción determinados.
La biblioteca también puede utilizarse de forma incorrecta. Si se convierte en un almacén de documentos con vínculos débiles con la ingeniería, la contratación y las operaciones, genera una apariencia administrativa en lugar de un control real. Si la evidencia es de baja calidad, está desactualizada o es imposible de recuperar, la madurez aparente resulta engañosa. Si los incidentes nunca modifican la biblioteca, la organización no está aprendiendo realmente de los fallos.
La fuerza legal varía considerablemente según el origen. Marcos como el AI RMF de NIST, las orientaciones públicas sobre garantía y muchos marcos de pruebas son generalmente voluntarios, salvo que un contrato, un requisito del comprador, un esquema de certificación o un supervisor sectorial los haga vinculantes en la práctica. Por el contrario, el EU AI Act impone obligaciones vinculantes para los casos dentro de su ámbito de aplicación, y esas obligaciones se aplican en fechas distintas según la parte del régimen. El trabajo internacional sobre notificación de incidentes de IA sigue avanzando hacia una terminología común, por lo que las organizaciones multinacionales deben hacer explícitos sus umbrales de incidentes, categorías de daño y reglas de escalada, en lugar de asumir una taxonomía universal.
Próximos pasos
Designar un responsable de la biblioteca y un responsable para cada dominio de control principal.
Elaborar o verificar un inventario de sistemas de IA, modelos, casos de uso de alto riesgo y componentes de terceros antes de intentar redactar controles de forma abstracta.
Mapear cada requisito significativo a un control, un método de prueba, un elemento de evidencia, una periodicidad de revisión y una ruta de escalada.
Determinar qué evidencia debe existir antes del lanzamiento, qué debe monitorizarse después del lanzamiento y qué eventos desencadenan una nueva prueba o el rediseño del control.
Conectar la biblioteca con la contratación, la gestión del cambio, las aprobaciones, el trabajo de garantía y la gestión de incidentes, de modo que se utilice en decisiones reales y no solo se almacene para el día de la auditoría.
Revisar y actualizar la biblioteca tras incidentes, cambios importantes en los modelos, cambios de proveedores, hallazgos de auditoría y novedades legales relevantes, no solo una vez al año.
¿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
¿Exige la ley una biblioteca de controles de IA?
Generalmente no con ese nombre. Las leyes y los contratos tienden a exigir los controles subyacentes, los documentos, los registros, la monitorización o la notificación. La biblioteca es la estructura que mantiene esas obligaciones organizadas y demostrables.
¿En qué se diferencia de una política de IA?
Una política de IA establece reglas e intenciones. Una biblioteca de controles de IA define las verificaciones, los responsables, las pruebas y la evidencia que hacen operativas esas reglas.
¿En qué se diferencia de una salvaguarda de IA?
Una salvaguarda es una medida de protección específica dentro de un modelo, producto o flujo de trabajo. Una biblioteca de controles puede incluir controles de salvaguarda, pero también abarca controles más amplios de gobernanza, proveedores, documentación e incidentes.
¿Es lo mismo que un sistema de gestión de IA?
No. Un sistema de gestión de IA es el marco organizativo más amplio para gobernar la IA. La biblioteca de controles es uno de los artefactos de trabajo dentro de ese sistema.
¿Tiene que ser una plataforma de software?
No. Muchas bibliotecas comienzan como documentos controlados u hojas de cálculo. Lo que importa es una responsabilidad clara, el control de versiones, el mapeo y la evidencia recuperable.
¿Qué se considera habitualmente como evidencia?
Según el control, la evidencia puede incluir documentación técnica, registros de pruebas, registros de actividad, registros de aprobación, informes de monitorización, registros de formación, declaraciones de proveedores y expedientes de incidentes.
¿Puede una sola biblioteca abarcar varias jurisdicciones?
Sí, siempre que cada control esté etiquetado por jurisdicción, origen legal, ámbito del sistema y regla de evidencia. Un mismo control puede respaldar varios marcos, pero solo si las diferencias de ámbito se hacen explícitas.
¿Con qué frecuencia debe actualizarse?
Siempre que haya un cambio material en el modelo, un nuevo proveedor, un incidente, un hallazgo de auditoría, un nuevo contexto de despliegue o una actualización legal. La revisión anual por sí sola rara vez es suficiente para entornos de IA activos.