guardia-ai/gitlab-componentEscáner de cumplimiento de la Ley de IA de la UE para pipelines de CI/CD de GitLab: detecta bibliotecas de IA/ML y publica la clasificación de riesgo como comentarios en las MR.
Para facilitarte el inicio con GitLab, aquí tienes una lista de pasos recomendados.
¿Ya eres un profesional? Solo edita este README.md y hazlo tuyo. ¿Quieres hacerlo fácil? Usa la plantilla al final.
cd existing_repo
git remote add origin https://gitlab.com/guardia-ai/gitlab-component.git
git branch -M main
git push -uf origin main
Usa la integración continua incorporada en GitLab.
Cuando estés listo para hacer tuyo este README, solo edita este archivo y usa la práctica plantilla de abajo (o siéntete libre de estructurarlo como quieras, ¡esto es solo un punto de partida!). Gracias a makeareadme.com por esta plantilla.
Cada proyecto es diferente, así que considera cuáles de estas secciones aplican al tuyo. Las secciones usadas en la plantilla son sugerencias para la mayoría de los proyectos de código abierto. También ten en cuenta que, aunque un README puede ser demasiado largo y detallado, es mejor que sea demasiado largo que demasiado corto. Si crees que tu README es demasiado largo, considera usar otra forma de documentación en lugar de recortar información.
Elige un nombre autoexplicativo para tu proyecto.
Haz saber a los visitantes qué puede hacer específicamente tu proyecto. Proporciona contexto y añade un enlace a cualquier referencia que pueda ser desconocida. Aquí también se puede añadir una lista de Características o una subsección de Antecedentes. Si hay alternativas a tu proyecto, este es un buen lugar para enumerar los factores diferenciadores.
En algunos READMEs, puedes ver pequeñas imágenes que transmiten metadatos, como si todas las pruebas están pasando para el proyecto. Puedes usar Shields para añadir algunas a tu README. Muchos servicios también tienen instrucciones para añadir una insignia.
Dependiendo de lo que estés haciendo, puede ser buena idea incluir capturas de pantalla o incluso un video (a menudo verás GIFs en lugar de videos reales). Herramientas como ttygif pueden ayudar, pero mira Asciinema para un método más sofisticado.
Dentro de un ecosistema particular, puede haber una forma común de instalar cosas, como usar Yarn, NuGet o Homebrew. Sin embargo, considera la posibilidad de que quien lea tu README sea un principiante y necesite más orientación. Enumerar pasos específicos ayuda a eliminar ambigüedades y consigue que la gente use tu proyecto lo más rápido posible. Si solo se ejecuta en un contexto específico, como una versión de lenguaje de programación o sistema operativo en particular, o tiene dependencias que deben instalarse manualmente, añade también una subsección de Requisitos.
Usa ejemplos con libertad y muestra la salida esperada si puedes. Es útil incluir en línea el ejemplo de uso más pequeño que puedas demostrar, proporcionando enlaces a ejemplos más sofisticados si son demasiado largos para incluirlos razonablemente en el README.
Indica a los visitantes a dónde pueden acudir para obtener ayuda. Puede ser cualquier combinación de un rastreador de incidencias, una sala de chat, una dirección de correo electrónico, etc.
Si tienes ideas para versiones futuras, es buena idea enumerarlas en el README.
Indica si aceptas contribuciones y cuáles son tus requisitos para aceptarlas.
Para las personas que quieran hacer cambios en tu proyecto, es útil tener documentación sobre cómo empezar. Quizás hay un script que deberían ejecutar o algunas variables de entorno que deben configurar. Haz explícitos estos pasos. Estas instrucciones también pueden ser útiles para tu yo futuro. También puedes documentar comandos para comprobar el código o ejecutar pruebas. Estos pasos ayudan a garantizar una alta calidad del código y reducen la probabilidad de que los cambios rompan algo inadvertidamente. Tener instrucciones para ejecutar pruebas es especialmente útil si requiere configuración externa, como iniciar un servidor Selenium para pruebas en un navegador.
Muestra tu aprecio a quienes han contribuido al proyecto.
Para proyectos de código abierto, indica cómo está licenciado.
Si te has quedado sin energía o tiempo para tu proyecto, deja una nota al principio del README diciendo que el desarrollo se ha ralentizado o detenido por completo. Alguien puede decidir hacer un fork de tu proyecto u ofrecerse como mantenedor o propietario, permitiendo que tu proyecto continúe. También puedes hacer una solicitud explícita de mantenedores.
Además de detectar qué bibliotecas de IA usas, el escáner lee tu código fuente e informa obligaciones específicas en líneas concretas:
| Regla | Lo que busca |
|---|---|
GA-ART50-001 | Un endpoint orientado al usuario que llega a un modelo, sin ninguna divulgación en el repositorio de que las respuestas son generadas por IA |
GA-ART12-001 | Un modelo invocado sin ninguna llamada de registro, auditoría o trazabilidad en el ámbito |
Los hallazgos aparecen de tres maneras: como comentario en la solicitud de fusión, como marcadores en el diff de la solicitud de fusión a través del informe de Calidad del Código, y — con una clave API — como un registro en tu panel de Guardia que rastrea lo que arreglaste y lo que introdujiste, commit a commit.
include:
- component: gitlab.com/guardia-ai/gitlab-component/scan@main
inputs:
guardia_api_key: $GUARDIA_API_KEY # optional — keeps the record
code_analysis: 'true'
fail_on_findings: 'none'
Los hallazgos se resuelven solos. Arregla el código — nuestro parche o el tuyo propio — y el siguiente escaneo simplemente deja de reportarlo. No hay nada que hacer clic.
Para aceptar uno en su lugar, indícalo en el código:
# guardia: ignore GA-ART50-001 — notice is rendered by the chat UI shell
Eso nunca falla una compilación, y llega a tu panel como una aceptación de riesgo documentada con el autor del git blame, que es lo que un auditor quiere ver.
Un repositorio de cinco años de antigüedad tendrá hallazgos que nadie del equipo actual causó. Congélalos una vez, y solo el trabajo nuevo debe estar limpio:
guardia-scan . --write-baseline .guardia/baseline.json
Haz commit de ese archivo. Los hallazgos con línea base permanecen visibles en el informe y en tu panel — simplemente nunca fallan la comprobación. Cualquier cosa introducida después sí lo hará.
Cada ejecución puede escribir un registro resistente a manipulaciones — qué se encontró, en qué commit, bajo qué versión del paquete de reglas, y cuánta revisión legal tuvo cada regla en ese momento:
- uses: GharbiiAhmed/guardia-ai-action@v1
with:
evidence-file: guardia-evidence.json
evidence-signing-key: ${{ secrets.GUARDIA_EVIDENCE_KEY }} # optional
Los registros se encadenan por hash, por lo que alterar uno pasado rompe todos los registros posteriores. Sin una clave de firma que demuestre consistencia interna, no autenticidad — el registro lo dice por sí mismo en lugar de dejarte asumir.
Los hallazgos indican lo que hace tu código y citan la obligación. No afirman que estés en incumplimiento — si una obligación aplica depende del propósito de tu sistema y del contexto de despliegue, que ningún escaneo de código puede determinar. Las reglas citan el Reglamento (UE) 2024/1689 textualmente para que puedas comprobar el razonamiento tú mismo.
La detección se ejecuta completamente fuera de línea. Tu código fuente nunca abandona el ejecutor.