Le 2 août 2026, les obligations de l'AI Act sur les systèmes d'IA à haut risque (Annexe III) entrent en application complète. Question récurrente depuis l'annonce Daybreak : si j'utilise OpenAI Daybreak (ou Claude Mythos via un partenaire Glasswing), suis-je en train de manipuler un système haut risque au sens de l'AI Act ? La réponse dépend de votre usage, pas du modèle. Voici la matrice.
Ce que dit l'AI Act sur les systèmes haut risque
L'Annexe III de l'AI Act liste 8 catégories de systèmes haut risque :
- Identification biométrique à distance.
- Infrastructures critiques (énergie, transport, eau).
- Éducation et formation professionnelle (notation, accès).
- Emploi et gestion des travailleurs.
- Accès aux services privés essentiels et publics (crédit, assurance, prestations).
- Application de la loi (forces de l'ordre).
- Migration, asile, contrôle des frontières.
- Administration de la justice et processus démocratiques.
Pour qu'un système soit haut risque, il faut qu'il détermine substantiellement une décision dans l'une de ces 8 catégories. Voir AI Act : préparer l'application au 2 août 2026.
Daybreak / Mythos en eux-mêmes : pas haut risque par défaut
Daybreak fait du threat modeling et de la patch validation. Mythos fait de la découverte de vulnérabilités. Ni l'un ni l'autre prend des décisions dans les 8 catégories. Donc l'usage par défaut (cybersécurité applicative) n'est pas haut risque AI Act.
C'est carré comme principe. Mais il y a 3 nuances importantes.
Nuance 1 : ton usage peut basculer dans le haut risque
Si vous utilisez Daybreak ou Mythos pour valider du code qui pilote :
- Un système d'évaluation de crédit (Annexe III §5) → l'outil de validation devient un composant du système haut risque.
- Un dispositif médical (réglé par d'autres directives, mais qui converge AI Act) → idem.
- Un système de tri de CV automatisé (Annexe III §4) → idem.
Dans ce cas, Daybreak / Mythos hérite des obligations du système qu'il valide. Ce n'est pas Daybreak qui devient haut risque, c'est votre intégration qui retombe dans les obligations Annexe III.
Implication concrète : si vous validez un module crédit avec Daybreak, votre dossier Annexe IV AI Act doit mentionner Daybreak comme composant, avec sa traçabilité.
Nuance 2 : obligations GPAI (modèles fondationnels)
GPT-5.5 et Claude sont des modèles d'IA à usage général (GPAI) au sens de l'AI Act. OpenAI et Anthropic ont des obligations propres :
- Documentation technique (transparence sur les capacités, données d'entraînement, performances).
- Politique de respect du droit d'auteur UE.
- Système de gestion des risques systémiques pour les modèles dits "à risque systémique" (GPT-5.5 et Claude récents y tombent vraisemblablement).
Ce que ça veut dire pour vous côté utilisateur : vous pouvez et vous devez exiger de OpenAI / Anthropic la documentation GPAI. Si votre fournisseur vous la refuse, c'est un signal rouge. À date, OpenAI publie des "system cards" sur ses modèles ; Anthropic publie des "model cards". Lis-les avant de signer. Voir AI Act et fournisseurs amont.
Nuance 3 : usage offensif et déontologie
Mythos et GPT-5.5-Cyber génèrent des exploits offensifs. L'AI Act n'interdit pas explicitement les outils de cybersécurité offensive — il les laisse dans le scope du droit national. Mais :
- Article 5 liste des pratiques interdites (manipulation, score social, etc.) — la cyber offensive autorisée n'y tombe pas.
- Considérant 119 mentionne que les outils défensifs de cybersécurité bénéficient d'une présomption d'utilité publique.
Du coup, utiliser Daybreak côté défensif et GPT-5.5-Cyber côté red team interne, c'est compatible AI Act tant que les usages restent légitimes (pas d'intrusion sans mandat, pas d'exploit livré à des tiers non autorisés).
Les 4 obligations qui s'appliquent à votre intégration Daybreak / Mythos
Indépendamment de la qualification haut risque, ces obligations s'appliquent à toute organisation utilisant des systèmes IA :
1. Transparence (Article 50)
Si Daybreak / Mythos produit des contenus visibles par des personnes (commentaires sur PR, suggestions de patch revues par des humains), vous n'avez pas d'obligation spécifique côté transparence pour des usages internes. En revanche, si ces outputs sortent à des clients (rapports d'audit envoyés à un client), vous devez indiquer la nature IA.
2. AI literacy (Article 4)
Au 2 février 2025 déjà — applicable depuis longtemps — vous devez t'assurer que les personnes qui utilisent l'IA dans votre org ont un niveau de compréhension adapté. En pratique : formation des devs et RSSI qui utilisent Daybreak / Mythos, traçable.
3. Surveillance humaine (Article 14, si haut risque)
Si votre usage tombe en haut risque, vous devez pouvoir intervenir, désactiver, ou ignorer les recommandations IA. Procédure documentée.
4. Cybersécurité (Article 15, si haut risque)
Mesures techniques pour assurer la résilience aux attaques contre le système IA lui-même (poisoning, model evasion). Ironique pour un outil de cybersécurité, mais l'obligation est là.
Décision pratique en 1 page
| Usage Daybreak / Mythos | Statut AI Act | |---|---| | Threat modeling code applicatif standard | Hors haut risque | | Validation patches sur composant médical | Haut risque hérité (Annexe III dispositifs médicaux) | | Validation patches sur scoring crédit | Haut risque hérité (Annexe III §5) | | Red team interne sur infra non critique | Hors haut risque, mais AI literacy + politique interne | | Red team sur infra énergétique / transport | Haut risque hérité (Annexe III §2) |
Action recommandée d'ici le 2 août 2026
- Cartographie usage : où Daybreak / Mythos est utilisé, sur quels périmètres.
- Qualification AI Act : pour chaque périmètre, application de la matrice ci-dessus.
- Si haut risque hérité : mettre à jour le dossier Annexe IV du système haut risque concerné.
- Si non haut risque : politique interne + AI literacy + traçabilité.
Donc voilà : Daybreak et Mythos ne sont pas magiquement "haut risque AI Act". C'est votre usage qui peut les y amener. La bonne nouvelle : pour la majorité des cas (cybersécurité applicative classique), vous n'êtes pas en haut risque. La moins bonne : il faut quand même cartographier et tracer.
