Le règlement sur l'IA de l'UE et KIFF Cloud

1. Ce qu'est cette page

Une correspondance entre des fonctions précises de KIFF Cloud et des articles précis du règlement sur l'IA. Chaque section consacrée à une fonction indique ce que KIFF Cloud fournit aujourd'hui, et aussi ce que nous ne fournissons pas, afin que cette correspondance ne puisse pas être lue comme une garantie de conformité du client.

Lorsque cette page renvoie au règlement sur l'IA, le texte de référence est celui que l'Union européenne publie sur EUR-Lex. En cas de divergence, EUR-Lex prévaut.

2. À qui s'adresse cette page

Aux fournisseurs et aux déployeurs de systèmes d'IA à haut risque au sens de l'article 6 et de l'annexe III du règlement sur l'IA, dont les obligations comprennent un enregistrement traçable (article 12) et un contrôle humain effectif (article 14). KIFF Cloud est conçu pour aider à remplir ces deux obligations précisément ; les autres obligations du règlement sur l'IA restent de la responsabilité du client.

3. Article 12, Enregistrement

L'article 12 du règlement sur l'IA exige que les systèmes d'IA à haut risque permettent « l'enregistrement automatique des événements (journaux) tout au long de la durée de vie du système », de façon suffisante pour permettre l'identification des situations présentant un risque, la traçabilité et la surveillance après commercialisation.

Ce que KIFF Cloud fournit

• L'enregistrement automatique des événements pour chaque action gouvernée, event_ingested, state_changed, decision_recorded, action_validated, action_executed, approval_required, approval_granted, approval_denied, action_blocked.
• L'attribution de chaque enregistrement: chaque événement porte l'identifiant de l'acteur, l'horodatage et l'identifiant de trace qui le relient à sa chaîne causale.
• Une chaîne d'audit en ajout seul au niveau du framework ; le rejeu est déterministe.
• Des empreintes de synthèse qui rendent toute altération détectable, publiées sur une piste publique vérifiable (lorsque le déploiement choisit le mode piste vérifiable).
• Des Reçus signés pour chaque action gouvernée, utilisables comme preuve en dehors de la base de données de KIFF Cloud.

Ce que KIFF Cloud ne fournit pas

• Les décisions sur ce qu'il faut enregistrer. La configuration de domaine du client et ses contrats d'action déterminent quels événements sont émis.
• Les durées de conservation. Par défaut, la conservation dure aussi longtemps que le locataire (tenant) du client existe ; c'est la politique du client qui détermine si cela satisfait au critère d'une durée « adaptée à la destination » de l'article 26, paragraphe 6 (au moins six mois).
• Le signalement automatisé aux autorités de surveillance au titre de l'article 73. Le client est responsable de tout signalement vers l'extérieur.
• La détermination du caractère à haut risque du système du client au sens de l'annexe III. Cette classification revient au client.

4. Article 14, Contrôle humain

L'article 14 du règlement sur l'IA exige que la conception et le développement des systèmes d'IA à haut risque permettent « un contrôle effectif par des personnes physiques pendant leur période d'utilisation ». Cela comprend la possibilité, pour une personne désignée pour ce contrôle, d'interpréter les sorties, d'intervenir dans le fonctionnement et d'arrêter le fonctionnement si nécessaire.

Ce que KIFF Cloud fournit

• Une exigence d'approbation par action. Chaque ActionContract déclare son exigence d'approbation (Required, OptionalIfHigh ou None). Une approbation requise suspend l'exécution jusqu'à ce qu'une personne désignée examine la proposition.
• Un espace d'examen des approbations. Le tableau de bord et l'API présentent les approbations en attente avec tout le contexte causal : les événements d'origine, l'état actuel, l'action proposée et ses paramètres, et la règle qui a déclenché la retenue.
• L'attribution à l'examinateur. Chaque enregistrement approval_granted ou approval_denied porte l'identifiant de l'examinateur, l'horodatage et un champ de motif en texte libre.
• Un refus est définitif. Une approbation refusée bloque toute exécution ultérieure de la même proposition dans le même contexte. Le client ne peut pas contourner par accident une décision de contrôle en réessayant.
• Les champs du Reçu. Le Reçu d'une action soumise à approbation consigne l'attribution à l'examinateur, ce qui rend le contrôle visible pour les auditeurs et les régulateurs en aval.

Ce que KIFF Cloud ne fournit pas

• La formation de l'examinateur humain. L'article 26, paragraphe 2, exige que les personnes chargées du contrôle disposent « des compétences, de la formation et de l'autorité nécessaires » ; c'est le client qui établit cette compétence.
• La définition des actions qui exigent un contrôle. La configuration de domaine du client fixe les exigences d'approbation ; KIFF Cloud applique ce que la configuration déclare.
• La politique de l'organisation. L'article 14, paragraphes 2 et 3, fait peser des obligations de contrôle sur l'organisation du déployeur ; KIFF Cloud ne peut pas se substituer à ces obligations.
• Un « bouton d'arrêt » au niveau du système d'IA. KIFF Cloud opère au niveau de l'action ; arrêter le système dans son ensemble exige les contrôles propres au client.

5. Autres articles pertinents

Au-delà des articles 12 et 14, KIFF Cloud touche plus légèrement à plusieurs autres obligations. Chaque note ci-dessous nomme l'article et la limite de notre contribution.

Article 9, Gestion des risques

Le champ risk_score du Reçu est réservé à des données de référence inter-locataires. Dans la v0.1, il vaut null, car ce jeu de données n'a pas encore été constitué. Les clients ne peuvent pas s'appuyer sur ce champ aujourd'hui.

Article 10, Données et gouvernance des données

Hors périmètre. Les données d'entraînement, de validation et de test du client relèvent de la responsabilité du client.

Article 13, Transparence envers les déployeurs

Le format du Reçu donne à ceux qui l'utilisent en aval un enregistrement de décision structuré qu'ils peuvent lire et auditer ; certains déployeurs le jugent suffisant comme preuve de transparence envers les utilisateurs finaux, selon leur cas.

Article 15, Exactitude, robustesse, cybersécurité

Le dispositif de cybersécurité propre à KIFF Cloud est décrit sur /security. L'exactitude et la robustesse du système d'IA du client relèvent de la responsabilité du client ; KIFF Cloud est une couche de gouvernance, pas un modèle.

Article 17, Gestion de la qualité

Hors périmètre. Le système de gestion de la qualité du client relève de la responsabilité du client.

Article 26, Obligations des déployeurs

Beaucoup d'obligations des déployeurs exigent des preuves de surveillance et de contrôle. La chaîne d'audit et les Reçus de KIFF Cloud sont conçus pour être ces preuves.

6. Ce qui n'est pas sur cette liste

KIFF Cloud est une couche de gouvernance pour les actions des systèmes d'IA. Il ne traite pas les obligations qui découlent du modèle lui-même (origine des données d'entraînement, tests de biais, documentation du modèle), des politiques de l'organisation du déployeur (procédures de signalement d'incidents, enregistrement du déployeur) ou d'une infrastructure de surveillance après commercialisation qui va au-delà des événements enregistrés.

Si votre évaluation de la conformité relève des obligations qui ne sont pas couvertes ici, KIFF Cloud n'est pas le bon outil pour celles-ci. Nous le dirons lors d'un échange commercial plutôt que de laisser entendre le contraire.

7. Le Reçu comme preuve

Un seul Reçu KIFF rassemble, pour une action gouvernée :

• la chaîne causale: les événements, l'état, la décision et la validation de l'action qui ont produit le résultat (preuve d'enregistrement au titre de l'article 12) ;
• l'attribution à l'examinateur lorsqu'une approbation humaine était requise (preuve de contrôle au titre de l'article 14) ;
• la version de la politique sous laquelle la décision a été prise (traçabilité sur le cycle de vie au titre de l'article 12, paragraphe 2, point b)) ;
• une attestation cryptographique portant sur la chaîne, vérifiable indépendamment de la base de données du cloud (intégrité au titre de l'article 15).

Un régulateur qui examine une action présente un Reçu ; un régulateur qui examine un système dans la durée présente l'ensemble des reçus. La forme JSON stable du Reçu vise à rendre cet échange mécanique plutôt que discursif.

8. Limites

Nous ne sommes ni un organisme notifié, ni un évaluateur de la conformité accrédité, ni un mandataire au sens du règlement sur l'IA. Nous ne certifions pas les systèmes des clients. L'évaluation de la conformité prévue à l'article 43 du règlement sur l'IA reste de la responsabilité du client. Le rôle de KIFF Cloud est de fournir des preuves sur lesquelles l'évaluation de la conformité du client peut s'appuyer.

Lorsque la législation dérivée du règlement sur l'IA (actes délégués, actes d'exécution, normes harmonisées) est mise à jour, cette correspondance peut avoir du retard. Nous mettons cette page à jour à mesure que le texte réglementaire et les lignes directrices pertinentes de la Commission évoluent.

9. Versions

Cette correspondance est versionnée. La v0.1 reflète le texte consolidé du règlement sur l'IA publié au JO L du 12 juillet 2024 et les lignes directrices de la Commission disponibles à la date indiquée en tête de page.

10. Contact

Questions de conformité : legal@kiff.dev. Questions de confidentialité : privacy@kiff.dev. Signalements de sécurité : security@kiff.dev.

Version du document : v0.1.
Dernière mise à jour : 24 mai 2026.