guardia-ai/gitlab-componentScanneur de conformité à l'AI Act européen pour les pipelines CI/CD GitLab — détecte les bibliothèques IA/ML et publie la classification des risques sous forme de commentaires MR.
Pour vous faciliter la prise en main de GitLab, voici une liste d'étapes recommandées.
Déjà un expert ? Modifiez simplement ce README.md et personnalisez-le. Vous voulez faire simple ? Utilisez le modèle en bas !
cd existing_repo
git remote add origin https://gitlab.com/guardia-ai/gitlab-component.git
git branch -M main
git push -uf origin main
Utilisez l'intégration continue intégrée dans GitLab.
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to makeareadme.com for this template.
Chaque projet est différent, alors considérez lesquelles de ces sections s'appliquent au vôtre. Les sections utilisées dans le modèle sont des suggestions pour la plupart des projets open source. Gardez également à l'esprit que même si un README peut être trop long et détaillé, trop long vaut mieux que trop court. Si vous pensez que votre README est trop long, envisagez d'utiliser une autre forme de documentation plutôt que de supprimer des informations.
Choisissez un nom explicite pour votre projet.
Faites savoir aux gens ce que votre projet peut faire spécifiquement. Fournissez du contexte et ajoutez un lien vers toute référence que les visiteurs pourraient ne pas connaître. Une liste de fonctionnalités ou une sous-section Contexte peut également être ajoutée ici. S'il existe des alternatives à votre projet, c'est un bon endroit pour lister les facteurs de différenciation.
Sur certains README, vous pouvez voir de petites images qui transmettent des métadonnées, comme si tous les tests passent pour le projet. Vous pouvez utiliser Shields pour en ajouter à votre README. De nombreux services ont également des instructions pour ajouter un badge.
Selon ce que vous fabriquez, il peut être judicieux d'inclure des captures d'écran ou même une vidéo (vous verrez souvent des GIFs plutôt que des vidéos réelles). Des outils comme ttygif peuvent aider, mais jetez un œil à Asciinema pour une méthode plus sophistiquée.
Dans un écosystème particulier, il peut y avoir une manière courante d'installer les choses, comme utiliser Yarn, NuGet ou Homebrew. Cependant, considérez la possibilité que celui qui lit votre README soit un novice et souhaite plus de conseils. Lister des étapes spécifiques aide à éliminer l'ambiguïté et permet aux gens d'utiliser votre projet le plus rapidement possible. S'il ne fonctionne que dans un contexte spécifique comme une version de langage de programmation particulière ou un système d'exploitation, ou s'il a des dépendances qui doivent être installées manuellement, ajoutez également une sous-section Exigences.
Utilisez des exemples généreusement et montrez le résultat attendu si possible. Il est utile d'avoir en ligne le plus petit exemple d'utilisation que vous pouvez démontrer, tout en fournissant des liens vers des exemples plus sophistiqués s'ils sont trop longs pour être inclus raisonnablement dans le README.
Dites aux gens où ils peuvent obtenir de l'aide. Cela peut être n'importe quelle combinaison d'un suivi des issues, d'un salon de discussion, d'une adresse e-mail, etc.
Si vous avez des idées pour des versions futures, c'est une bonne idée de les lister dans le README.
Indiquez si vous êtes ouvert aux contributions et quelles sont vos exigences pour les accepter.
Pour les personnes qui souhaitent apporter des modifications à votre projet, il est utile d'avoir une documentation sur la façon de commencer. Il y a peut-être un script qu'elles doivent exécuter ou des variables d'environnement qu'elles doivent définir. Rendez ces étapes explicites. Ces instructions pourraient également être utiles à votre futur vous-même.
Vous pouvez également documenter les commandes pour linter le code ou exécuter des tests. Ces étapes aident à garantir une haute qualité de code et réduisent la probabilité que les modifications cassent quelque chose par inadvertance. Avoir des instructions pour exécuter les tests est particulièrement utile si cela nécessite une configuration externe, comme le démarrage d'un serveur Selenium pour les tests dans un navigateur.
Montrez votre appréciation à ceux qui ont contribué au projet.
Pour les projets open source, dites comment il est sous licence.
Si vous n'avez plus d'énergie ou de temps pour votre projet, mettez une note en haut du README indiquant que le développement a ralenti ou s'est complètement arrêté. Quelqu'un peut choisir de forker votre projet ou de se porter volontaire pour devenir mainteneur ou propriétaire, permettant à votre projet de continuer. Vous pouvez également faire une demande explicite de mainteneurs.
Au-delà de détecter quelles bibliothèques d'IA vous utilisez, le scanner lit votre source et signale des obligations spécifiques à des lignes spécifiques :
| Règle | Ce qu'elle recherche |
|---|---|
GA-ART50-001 | Un point de terminaison orienté utilisateur qui atteint un modèle, sans aucune divulgation dans le dépôt que les réponses sont générées par l'IA |
GA-ART12-001 | Un modèle invoqué sans appel de journalisation, d'audit ou de traçage dans la portée |
Les résultats apparaissent de trois manières : sous forme de commentaire sur la demande de fusion, sous forme de marqueurs dans le diff de la demande de fusion via le rapport de qualité de code, et — avec une clé API — sous forme d'enregistrement dans votre tableau de bord Guardia qui suit ce que vous avez corrigé et ce que vous avez introduit, commit par 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'
Les résultats se résolvent d'eux-mêmes. Corrigez le code — notre correctif ou le vôtre — et le prochain scan cessera simplement de le signaler. Rien à cliquer.
Pour en accepter un à la place, dites-le dans le code :
# guardia: ignore GA-ART50-001 — notice is rendered by the chat UI shell
Cela ne fait jamais échouer une build, et cela arrive dans votre tableau de bord comme une acceptation de risque documentée avec l'auteur depuis git blame, ce qui est ce qu'un auditeur veut voir.
Un dépôt de cinq ans aura des résultats que personne de l'équipe actuelle n'a causés. Gelez-les une fois, et seul le nouveau travail doit être propre :
guardia-scan . --write-baseline .guardia/baseline.json
Commitez ce fichier. Les résultats de référence restent visibles dans le rapport et dans votre tableau de bord — ils ne font jamais échouer la vérification. Tout ce qui est introduit après le fait.
Chaque exécution peut écrire un enregistrement inviolable — ce qui a été trouvé, sur quel commit, sous quelle version du pack de règles, et combien de révision juridique chaque règle a eue à ce moment-là :
- uses: GharbiiAhmed/guardia-ai-action@v1
with:
evidence-file: guardia-evidence.json
evidence-signing-key: ${{ secrets.GUARDIA_EVIDENCE_KEY }} # optional
Les enregistrements s'enchaînent par hachage, donc en modifier un passé casse tous les enregistrements après lui. Sans une clé de signature qui prouve la cohérence interne, pas l'authenticité — l'enregistrement le dit lui-même plutôt que de vous laisser supposer.
Les résultats indiquent ce que votre code fait et citent l'obligation. Ils n'affirment pas que vous êtes en infraction — si une obligation s'applique dépend de l'objectif et du contexte de déploiement de votre système, ce qu'aucun scan de code ne peut déterminer. Les règles citent textuellement le Règlement (UE) 2024/1689 afin que vous puissiez vérifier le raisonnement vous-même.
La détection s'exécute entièrement hors ligne. Votre source ne quitte jamais l'exécuteur.