Estás leyendo
Red Hat lanza asago para automatizar la gobernanza de IA

Red Hat lanza asago para automatizar la gobernanza de IA

  • Asago conecta políticas, evaluación de riesgos y controles técnicos para llevar la gobernanza de IA empresarial a flujos auditables, trazables y desplegables.
IA Empresarial

Red Hat ha lanzado asago, una comunidad de código abierto diseñada para automatizar uno de los tramos más difíciles de la gobernanza de IA empresarial: convertir políticas internas, requisitos regulatorios y marcos de riesgo en pruebas técnicas, controles y configuraciones desplegables. El proyecto llega cuando la gobernanza de IA empieza a abandonar el terreno de los documentos para entrar en los flujos cotidianos de ingeniería. La cuestión es especialmente delicada para las empresas que quieren desplegar agentes autónomos y modelos generativos sin multiplicar revisiones manuales, herramientas inconexas y evidencias difíciles de auditar.

La iniciativa reúne a Red Hat con Alquimia AI, Brave Software, la coalición EvalEval, IBM Research, Interdisciplinary Transformation University Austria, Microsoft, MIT Lincoln Laboratory, North Carolina State University, NVIDIA y The Alan Turing Institute. Su planteamiento consiste en crear una capa de orquestación abierta que conecte herramientas de evaluación, red teaming, mitigación y despliegue que ya existen. Red Hat sitúa ahí una carencia del mercado: una organización puede disponer de marcos de riesgo y soluciones de seguridad, pero seguir dependiendo de trabajo manual para enlazar una cláusula de política con una prueba concreta y con el control aplicado en producción.

Asago intenta convertir la gobernanza de IA en un flujo técnico

La arquitectura inicial separa ese recorrido en varias fases. El primer paso es interpretar documentos de políticas y extraer riesgos relevantes para un sistema o agente concreto. Después, esos riesgos se relacionan con taxonomías y marcos como NIST AI RMF y OWASP, apoyándose también en IBM AI Risk Atlas. El resultado esperado es una representación estructurada que sirva de entrada a herramientas técnicas posteriores.

A partir de ahí, asago plantea generar escenarios específicos para pruebas de seguridad y red teaming, ejecutar esas evaluaciones y utilizar los resultados para recomendar mitigaciones. Algunas podrían materializarse como guardrails; otras podrían intervenir en distintos puntos de la pila tecnológica. La ambición final incluye producir artefactos desplegables en infraestructuras empresariales, por ejemplo mediante recursos de Kubernetes o configuraciones integradas en los procesos de plataforma.

La trazabilidad es el elemento que une estas piezas. El proyecto pretende mantener una relación verificable entre el requisito original, el riesgo identificado, la prueba realizada y la mitigación desplegada. Para un CIO o un responsable de cumplimiento, esa cadena puede ser más relevante que la automatización aislada: permite reconstruir por qué existe un control y qué evidencia respalda su uso. El Policy Mapper ya incorpora mecanismos para asociar los riesgos detectados con pasajes concretos de los documentos analizados.

Sin embargo, buena parte de ese recorrido sigue siendo una hoja de ruta. El propio equipo de Red Hat describe la arquitectura como inicial y sujeta a evolución. El repositorio público de asago confirma que la comunidad está en fase de formación y que, por ahora, el componente central disponible es Policy Mapper, junto con proyectos de apoyo como Midojo, orientado a probar agentes frente a ataques de inyección indirecta de prompts.

Asago aparece cuando el AI Act entra en fase de aplicación

El calendario regulatorio europeo añade presión, aunque con más matices de los que sugiere una lectura lineal del AI Act. El reglamento empezó a ser aplicable de forma general el 2 de agosto de 2026 y, desde esa fecha, la Oficina de IA de la Comisión Europea y las autoridades nacionales asumieron funciones de supervisión y aplicación. También entraron en vigor nuevas obligaciones de transparencia para determinados sistemas.

Las reglas de alto riesgo, sin embargo, no llegan todas al mismo tiempo. Tras los cambios del AI Omnibus, las obligaciones para determinados usos de alto riesgo, como empleo, educación, biometría, infraestructuras críticas o migración, se han desplazado al 2 de diciembre de 2027. En sistemas integrados en productos regulados, el horizonte se extiende hasta el 2 de agosto de 2028. Para los equipos de tecnología, esa secuencia reduce parte de la urgencia inmediata, pero mantiene una necesidad estructural: documentar decisiones, responsabilidades, controles y evidencias a medida que la IA pasa de pilotos a servicios en producción.

Asago intenta ocupar ese espacio entre lenguaje normativo y ejecución técnica. El NIST AI RMF, por ejemplo, ofrece un marco voluntario para incorporar consideraciones de confianza y riesgo en el diseño, desarrollo, uso y evaluación de sistemas de IA. Su utilidad como referencia no elimina el trabajo de traducir categorías de riesgo a pruebas concretas. El proyecto pretende automatizar parte de esa traducción y conservar el vínculo con el texto que la originó.

El código abierto amplía el alcance y también la exigencia

Una capa destinada a interpretar políticas y recomendar controles puede convertirse en infraestructura sensible dentro de una empresa, porque influye en qué riesgos se detectan, cómo se clasifican y qué mitigaciones se consideran adecuadas. Abrir el código y la gobernanza permite inspeccionar esos mecanismos, incorporar nuevas taxonomías y reducir la dependencia de un único proveedor. Los repositorios principales de la comunidad se publican bajo licencia Apache 2.0.

Te puede interesar
Cosentino - Edificio principal, Cantoria, Almería

A cambio, la calidad dependerá de la amplitud de contribuciones y de la capacidad del proyecto para manejar diferencias regulatorias, lingüísticas y sectoriales. Red Hat ha pedido participación adicional de otras geografías. Una política interna de un banco español, una organización sanitaria británica y un proveedor estadounidense pueden compartir categorías generales de riesgo, pero operar bajo obligaciones y tolerancias distintas.

El repositorio de Policy Mapper ofrece una primera señal de cómo puede abordarse el problema. El software trabaja con documentos no estructurados, extrae riesgos, los relaciona con taxonomías y mantiene pasajes de evidencia asociados a cada identificación. También incorpora puntuaciones de confianza para facilitar la revisión humana. Ese punto importa porque la automatización de la gobernanza introduce su propio riesgo: si un sistema interpreta mal una política, la cadena posterior puede ser técnicamente coherente y partir de una premisa equivocada.

De la revisión manual a una cadena auditable

Para las empresas, el impacto potencial está en cambiar la interfaz entre cumplimiento, seguridad y plataformas. Una nueva aplicación de IA puede obligar a recorrer documentos, seleccionar controles, diseñar evaluaciones, revisar resultados y convertir decisiones en configuraciones que después deben mantenerse. Cuando cada fase utiliza herramientas y responsables distintos, el coste aparece en las transferencias, las excepciones y la dificultad para repetir el proceso. Esa fragmentación es precisamente uno de los problemas que Red Hat identifica en la incorporación de nuevos agentes de IA a entornos empresariales.

Una capa de orquestación podría reducir esa fricción si consigue integrarse con los flujos de DevOps y GitOps y generar artefactos desplegables en infraestructuras empresariales, como plantea la iniciativa. También facilitaría revisiones cuando cambie una política o aparezca un nuevo riesgo, al conservar una relación explícita entre norma, evaluación y control. El valor operativo dependerá, sin embargo, de que esas conexiones funcionen sobre herramientas y plataformas heterogéneas sin añadir otra capa difícil de mantener.

El reto será demostrar que esa automatización mantiene precisión suficiente y no crea una nueva dependencia sobre una capa todavía inmadura. Asago cuenta desde su arranque con empresas tecnológicas, centros de investigación y actores de seguridad de IA, pero su utilidad empresarial dependerá de integraciones, cobertura regulatoria, calidad de las evaluaciones y mecanismos de revisión humana. Mientras el proyecto avanza, los CIO tendrán que decidir qué partes de la gobernanza pueden convertirse en software sin perder el criterio que todavía exige cada caso de uso.

Ver Comentarios (0)

Leave a Reply

Utilizamos cookies para facilitar la relación de los visitantes con nuestro contenido y para permitir elaborar estadísticas sobre las visitantes que recibimos. No se utilizan cookies con fines publicitarios ni se almacena información de tipo personal. Puede gestionar las cookies desde aquí.   
Privacidad