OpenComplAI está diseñado para mantener separada la lógica de evaluación de riesgos de la IA de las reglas utilizadas para representar un marco normativo específico. En una publicación de DEV Community del 27 de octubre, el desarrollador del proyecto describió el enfoque como un motor reutilizable para evaluar controles y evidencias, con los requisitos específicos de cada regulación gestionados en una capa de correspondencias.
El foco inmediato sigue siendo la Ley de IA de la UE: el desarrollador afirma que la mayoría de las reglas codificadas en OpenComplAI actualmente corresponden a esa regulación. Sin embargo, el objetivo arquitectónico es evitar que el propio motor dependa de la terminología de la Ley de IA de la UE. Esa separación pretende permitir adaptar el sistema a otros marcos sin reconstruir su maquinaria central de evaluación.
Un motor general con correspondencias específicas para cada marco
En este diseño, el motor central evalúa los controles y las evidencias asociadas, mientras que una correspondencia de políticas conecta esos elementos subyacentes con los requisitos de un marco elegido. La distinción es importante: un control es un componente básico de evaluación, mientras que una correspondencia explica cómo se relaciona ese componente con una política o regulación específica.
El desarrollador afirma que el paquete central no depende de HTTP ni utiliza nombres específicos de regulaciones en sus primitivas. En cambio, las herramientas de línea de comandos y los servicios utilizan el motor y aplican la correspondencia que se haya cargado. Esto establece un límite entre las funciones generales de evaluación de riesgos y la interpretación específica del marco que se añade por encima.
El desarrollador sostiene que codificar de forma rígida la redacción de una regulación en la lógica de evaluación encarecería la compatibilidad con cada marco adicional. Añadir otra jurisdicción o norma podría entonces requerir cambios en todo el motor o una bifurcación independiente. Con una capa de correspondencias, la alternativa prevista es mantener intacto el proceso general de evaluación y añadir una nueva correspondencia de políticas cuando sea necesario.
El desarrollador describe esto como una apuesta arquitectónica, no como un resultado demostrado. La publicación solicita comentarios de equipos que trabajen con un segundo marco, en lugar de basarse únicamente en una suposición hecha durante el diseño. Por eso, la experiencia práctica con otro marco será la próxima prueba significativa del enfoque.
Qué admite actualmente el proyecto
El repositorio de GitHub de OpenComplAI describe el proyecto como una herramienta de cumplimiento de código abierto que puede ejecutar evaluaciones de riesgos en pipelines de CI/CD. Indica que la Ley de IA de la UE se evalúa de forma nativa, mientras que NIST AI RMF se deriva de las mismas evidencias mediante una tabla de correspondencias. El repositorio califica ese soporte para NIST como parcial y no revisado, y señala que no cuenta con un escáner NIST independiente.
El repositorio describe ISO/IEC 42001 de otra manera: ofrece un paquete basado en declaraciones de conformidad, cuyas entradas siguen sin verificarse hasta que se registra una declaración. También indica que DORA y EBA solo están cubiertas mediante correspondencias. Estas distinciones son importantes porque una correspondencia con un marco no equivale necesariamente a una implementación completa y evaluada de forma independiente.
Hay una diferencia de énfasis entre la publicación del desarrollador y la descripción más detallada del repositorio. La publicación afirma que la arquitectura puede incorporar una correspondencia con NIST RMF o ISO 42001 sin reescribir la lógica de evaluación de riesgos. Mientras tanto, el repositorio matiza que la cobertura actual de NIST e ISO es parcial y no está revisada, y explica que ambos se gestionan de maneras distintas. Por tanto, la posibilidad arquitectónica no debe interpretarse como una afirmación de que todos los marcos ya cuentan con soporte completo.
El proyecto también deja claro que sus resultados no constituyen una certificación de cumplimiento. El repositorio describe artefactos de evidencia, verificaciones y flujos de trabajo de documentación, y advierte que la documentación generada puede incluir marcadores de posición cuando no se ha proporcionado la información requerida. Los equipos aún deben aportar y revisar evidencias, decidir cuáles son sus obligaciones y evaluar si la cobertura de la herramienta satisface sus necesidades.
Por qué la separación importa a los desarrolladores
El trabajo de cumplimiento de la IA puede abarcar requisitos de producto, controles técnicos, evidencias de respaldo y procesos de lanzamiento. Cuando estas cuestiones se vinculan directamente a un único marco dentro de una base de código, los cambios en el alcance normativo pueden quedar entrelazados con los cambios en la lógica de riesgos subyacente. Separar la correspondencia del motor ofrece a los desarrolladores una forma de mantener estas cuestiones más diferenciadas.
Esta estructura también puede facilitar la inspección del software. Un equipo puede preguntar qué controles verifica el motor, qué evidencias espera y cómo se corresponden esas verificaciones con el marco seleccionado. La correspondencia se convierte en una parte revisable de la implementación de cumplimiento, en lugar de una suposición implícita dispersa por el código de evaluación.
Para los equipos que utilizan integración continua, este tipo de herramienta puede acercar las verificaciones de cumplimiento al flujo de trabajo de desarrollo. El repositorio de OpenComplAI describe verificaciones automatizadas que pueden ejecutarse antes del lanzamiento y producir resultados de aprobado o reprobado. En general, una barrera en el pipeline puede ayudar a detectar controles o evidencias faltantes durante el desarrollo, pero su utilidad depende de lo que realmente compruebe y de que sus datos de entrada estén actualizados y completos.
La separación también tiene límites. Una correspondencia solo puede representar lo que se ha codificado y revisado. Si dos marcos definen obligaciones diferentes, una traducción de un conjunto de evidencias a otro puede ser incompleta o inadecuada. Las descripciones matizadas de la cobertura de NIST e ISO en el repositorio subrayan por qué los equipos deben revisar el estado específico de cada marco, en lugar de suponer que un motor compartido implica la misma profundidad en todos los regímenes.
Qué pueden evaluar los equipos a continuación
OpenComplAI se presenta como software de código abierto para incorporar verificaciones de cumplimiento de IA en pipelines de desarrollo. Su repositorio describe una interfaz de línea de comandos, un SDK de Python e integraciones de CI, además de servicios para tareas como la evaluación de riesgos y la gestión de evidencias. La página de precios indica que la versión de código abierto es gratuita bajo la licencia AGPL-3.0; una oferta Enterprise añade un panel alojado, soporte y otros servicios destinados a organizaciones.
Para los desarrolladores que evalúan este enfoque, un paso siguiente útil consiste en inspeccionar el límite entre el núcleo y sus correspondencias, y luego probar la herramienta con un sistema real y las obligaciones del marco pertinentes para ese sistema. Los equipos deben examinar qué verificaciones son nativas, cuáles son derivadas o se basan en declaraciones de conformidad, qué evidencias se requieren y cómo se gestionan las evidencias incompletas o desactualizadas. También deben confirmar cómo se aplica la licencia del proyecto al uso que pretenden darle.
La siguiente prueba del propio proyecto consiste en una validación más amplia. Su desarrollador busca comentarios de personas que apliquen el mismo motor a un segundo marco. Si ese trabajo demuestra que se puede añadir una nueva correspondencia sin realizar cambios invasivos en el núcleo, respaldaría la afirmación central del diseño. Si revela supuestos incorporados en las primitivas de evaluación, quizá haya que modificar la arquitectura.
Por ahora, OpenComplAI ofrece un ejemplo concreto de cómo tratar las políticas normativas como una capa sobre una maquinaria reutilizable de evaluación de riesgos. Esta distinción resulta útil para los desarrolladores porque hace visible el límite entre marcos. Sin embargo, la flexibilidad arquitectónica no demuestra que el cumplimiento sea completo: las correspondencias, las evidencias y el proceso de revisión siguen determinando lo que un sistema puede evaluar de manera significativa.
Fuentes: DEV Community, The Verge, TechCrunch, GitHub, Opencomplai
