Politique de gouvernance des données, des risques et de conformité

IuVeAI / iuve.eu

Version: 1.0
Date d’entrée en vigueur: 26 août 2026
Service: https://www.iuve.eu/

Opérateur

Développeur de projet : Iurie Verejan

Société juridique / opérateur: RECLAMA-VEREJAN I.I.

DNO / Cod: 1003600053323

Adresse: MD-2042, Moldova, CHISINAU CIOCANA, mun. Chisinau, Alecu Russo, 24/2

La présente Politique sur la gouvernance des données, les risques et la conformité complète Politique de confidentialité, Conditions d'utilisation, Politique relative aux cookies, Politique d'utilisation acceptableet AI et politique de formation modèle. - Lorsqu'une politique plus spécifique établit une protection plus stricte, l'exigence plus stricte prévaut, sauf si la loi l'interdit. La présente politique ne remplace pas la politique de confidentialité pour les procédures relatives aux droits des personnes concernées.

1. Objet

Cette politique du DGRC établit le cadre de gouvernance utilisé par IuVeAI pour gérer les données des utilisateurs et des espaces de travail; les systèmes et modèles d'intelligence artificielle; les fournisseurs de modèles d'intelligence artificielle; l'inférence locale et nuageuse; les intégrations d'API; les agents autonomes et semi-autonomes; les appareils connectés; les autorisations d'accès; les risques de sécurité; les risques de modèle et d'exploitation; la vérifiabilité; et la conformité juridique et réglementaire.

L'objectif est de s'assurer que l'IuVeAI fonctionne en fonction de la vie privée, de la sécurité, de la responsabilité, de la transparence, de la minimisation des données, du contrôle humain et de la gouvernance de l'IA proportionnelle au risque.

2. Portée

La présente Politique s’applique aux services et composants IuVeAI exploités par l’intermédiaire d’iuve.eu ou connectés à celui-ci, notamment IuVeAI Chat ; l’assistant Iulia AI ; le routage et l’inférence des modèles d’IA ; les modèles d’IA locaux ; les fournisseurs d’IA externes ; l’accès aux API ; le traitement des fichiers et documents ; l’entrée et la sortie vocales ; STT et TTS ; les intégrations GitHub ; les dépôts et outils de programmation ; IuVe Connect ; Desktop Agent ; Avatar et l’automatisation locale ; l’appairage d’appareils ; Semantic Marketing ; Website Agent ; les intégrations Marketplace ; les intégrations d’IA Genesis CMS ; les espaces de travail d’équipe ; les systèmes administratifs ; ainsi que les systèmes de surveillance et de sécurité.

Elle s'applique aux administrateurs, développeurs, employés, entrepreneurs, fournisseurs de services, agents d'IA et aux processus automatisés qui accèdent aux systèmes ou données contrôlés par IuVeAI.

3. Principes de gouvernance

3.1 Confidentialité par défaut

L'information privée sur l'espace de travail doit rester privée par défaut. L'accès ne peut avoir lieu que lorsque l'utilisateur a besoin de fournir une fonction demandée, de maintenir la sécurité du système, de se conformer à la loi ou d'effectuer une action administrative explicitement autorisée.

3.2 Minimisation des données

Seuls les renseignements raisonnablement nécessaires à l'opération demandée peuvent être recueillis, transmis ou conservés.

3.3 Limitation du but

Les renseignements recueillis à une seule fin ne doivent pas automatiquement être réutilisés à une fin non liée.

3.4 Le moindre privilège

Les utilisateurs, les services, les clés API, les agents et les administrateurs ne doivent recevoir que les autorisations requises pour leur tâche.

3.5 Pouvoir explicite

Un agent d'IA n'a pas d'autorité simplement parce qu'il peut techniquement effectuer une action. L'autorité doit provenir de la permission de l'utilisateur, de la configuration de l'espace de travail, de la politique de l'administrateur, d'une subvention de capacité approuvée ou d'une autre source documentée d'autorité.

3.6 Contrôle humain

Les actions susceptibles de produire des conséquences financières, juridiques, sécuritaires, personnelles ou opérationnelles importantes doivent rester soumises à un contrôle humain approprié.

3.7 Traçabilité

Les opérations sensibles à la sécurité et exécutées par des agents doivent être attribuables à un utilisateur, un service, une clé API, un modèle, un agent ou un processus système.

3.8 Échec sécurisé

Lorsque l'identité, l'autorité, la politique ou l'état d'exécution ne peuvent pas être déterminés de façon fiable, le système doit être par défaut dans un état plus sûr.

4. Classification des données

IuVeAI utilise quatre classifications de données primaires.

PUBLIC

Information destinée à la divulgation publique (par exemple, contenu du site Web public, documentation publique, listes publiques du marché et articles publics). Les informations publiques peuvent être traitées par des systèmes IuVeAI autorisés sans restrictions supplémentaires de confidentialité.

INTERNAL

L'information opérationnelle n'est pas destinée à une divulgation publique sans restriction (par exemple, mesures internes, configuration du système, registres opérationnels non sensibles et documentation interne). L'accès devrait être limité aux systèmes et au personnel autorisés.

CONFIDENTIAL

Informations associées à un utilisateur, un espace de travail, une organisation ou une activité privée (par exemple conversations, fichiers téléchargés, contenu du dépôt, code source, notes privées, informations sur le projet, transcriptions vocales, contexte d'exécution des agents, et informations sur les clients). Les données confidentielles ne doivent pas être divulguées à des utilisateurs ou des services indépendants.

RESTRICTED

Informations nécessitant la plus haute protection (par exemple mots de passe, clés privées, secrets d'authentification, jetons d'accès, secrets d'API, références de session, justificatifs de récupération, informations d'authentification de paiement et informations personnelles très sensibles). L'information restreinte ne doit pas être utilisée intentionnellement comme données de formation sur l'IA. Lorsque cela est techniquement possible, les informations restreintes devraient être détectées, effacées, masquées ou bloquées avant la transmission à un modèle d'IA ou à un fournisseur externe.

5. Gouvernance du cycle de vie des données

IuVeAI régit les données tout au long : Collection → Classification → Traitement → Stockage → Accès → Transmission → Conservation → Suppression.

Pour chaque catégorie importante de données, IuVeAI devrait être en mesure d'identifier les raisons pour lesquelles l'information est traitée; quel service traite cette information; sa classification; où elle est stockée; qui ou quoi peut y accéder; si elle est envoyée à un tiers; règles de conservation applicables; mécanismes de suppression.

6. Gouvernance du modèle d'IA

Chaque modèle intégré à IuVeAI devrait avoir un dossier de gouvernance identifiable. L'enregistrement peut comprendre le nom du modèle, la version, le fournisseur, le lieu de déploiement, l'utilisation prévue, les capacités, les limitations connues, les limites de contexte, les restrictions de sécurité applicables, les caractéristiques de traitement des données, les résultats d'évaluation, la priorité d'acheminement et les conditions de repli. Les modifications du modèle matériel doivent être présentées en version et vérifiables.

7. Traitement local et cloud de l'IA

IuVeAI peut utiliser des modèles locaux, une infrastructure auto-portée et des fournisseurs d'IA externes. Les décisions d'acheminement peuvent tenir compte de la configuration de l'utilisateur, du type de tâche, des capacités du modèle, des exigences en matière de confidentialité, de la latence, de la disponibilité, du coût, de la sécurité, des exigences contextuelles, de la disponibilité des ressources et des seuils de qualité.

Lorsque le traitement local est configuré ou requis, IuVeAI devrait préférer l'exécution locale approuvée avant de transmettre des informations privées à l'extérieur. Le repli du cloud ne doit pas surcharger silencieusement une confidentialité explicite ou une restriction locale.

8. Fournisseurs externes d'IA

Les fournisseurs d'AI externes doivent être traités comme des services de traitement tiers. Avant d'utiliser la production, IuVeAI devrait évaluer, le cas échéant, les modalités de traitement des données, les pratiques de conservation, les politiques de formation, les contrôles de sécurité, l'emplacement du traitement géographique, la disponibilité, les capacités du modèle, les répercussions réglementaires et l'historique des incidents.

Les informations sensibles ne doivent pas être transmises à un fournisseur d'intelligence artificielle externe uniquement parce qu'il produit une réponse de meilleure qualité. Les exigences en matière de confidentialité et d'autorité priment sur la qualité du modèle.

9. Formation modèle et apprentissage continu

Les informations sur l'espace de travail privé ne doivent pas automatiquement devenir des données de formation. IuVeAI distingue les données d'inférence, la télémétrie opérationnelle, les données d'évaluation, les exemples d'apprentissage approuvés et les ensembles de données de formation. Le transfert de l'information d'une catégorie à une autre exige une base juridique et technique définie.

Une formation communautaire ou d'amélioration de produits basée sur des conversations d'utilisateurs privés reste opt-in, comme spécifié dans la AI et politique de formation modèle. L'abandon de la formation ne doit pas empêcher l'inférence ordinaire nécessaire pour fournir le service d'IA demandé. L'information restreinte ne doit pas être incluse dans les ensembles de données de formation.

10. Gouvernance de l'apprentissage continu

Les systèmes d'apprentissage automatisés ou continu ne doivent pas modifier directement le comportement de production sans validation contrôlée. Un cycle de vie d'apprentissage devrait suivre: Capture → Sanitise → Évaluer → Train → Test → Canary → Vérifier → Approuver → Déployer.

La réussite de la formation à elle seule ne suffit pas au déploiement de la production. Un nouveau modèle, un nouvel adaptateur, une nouvelle règle ou un nouveau comportement appris doit passer les barrières de qualité, de sécurité et de régression applicables avant l'activation de la production. Le recul de la production doit rester possible.

11. Gouvernance des agents d'IA

IuVe Connect, Desktop Agent, Avatar et d'autres agents fonctionnent sous des capacités explicites. Les agents ne doivent pas assumer le contrôle de l'appareil ou du compte sans restriction. Les catégories de capacités peuvent comprendre l'accès aux fichiers, le contrôle de l'application, l'interaction du navigateur, l'exécution des terminaux, l'accès au dépôt, les actions de réseau, la configuration du système, l'accès au presse-papiers et la communication externe. Les capacités doivent être limitées par les subventions des utilisateurs ou des administrateurs. Les capacités à impact élevé devraient appuyer la révocation et l'enregistrement des audits.

12. Classification des actions de l'agent

Niveau 0 — Lecture seule (inspection, recherche, analyse, résumé): normalement exécutable sans confirmation supplémentaire lorsque déjà autorisé.

Niveau 1 — Réversible (créer une ébauche, créer un fichier temporaire, modifier l'état de la demande réversible) : peut s'exécuter avec une subvention de capacité approuvée.

Niveau 2 — Changement de matériel (modifier les fichiers de projet, déployer les logiciels, modifier la configuration, mettre à jour les ressources de production) : nécessite une vérification plus rigoureuse de l'autorité et des garanties appropriées.

Niveau 3 — Impact élevé (supprimer les données importantes, envoyer des transactions financières, exposer les pouvoirs, modifier la politique de sécurité, accorder des privilèges administratifs, effectuer des opérations irréversibles): ne doit pas être exécuté uniquement parce qu'un modèle d'IA recommande l'action. Une autorisation humaine supplémentaire ou une politique explicitement préapprouvée est requise.

13. Séparation des motifs et des pouvoirs

Le raisonnement généré par l'IA est consultatif. Une réponse modèle ne constitue pas en soi une permission. La couche d'exécution doit vérifier indépendamment l'identité de l'acteur, l'octroi des capacités, la politique, la portée de l'exécution, l'environnement et les restrictions de sécurité applicables.

14. Surveillance humaine

IuVeAI doit préserver une surveillance humaine significative des décisions matérielles automatisées. Les utilisateurs devraient être en mesure, le cas échéant techniquement, d'examiner les actions proposées, de rejeter les actions, de révoquer les autorisations, d'arrêter un agent, d'inspecter les résultats d'exécution et de signaler un comportement incorrect.

15. Transparence

Les utilisateurs doivent pouvoir comprendre lorsqu'ils interagissent avec un système d'IA plutôt qu'avec un humain. Lorsque la loi applicable l'exige et que le contenu produit ou manipulé par l'IA est techniquement approprié, il doit appuyer une divulgation appropriée ou une identification lisible par machine. L'IuVeAI ne doit pas représenter intentionnellement un système artificiel en tant qu'individu humain dans des circonstances où cela pourrait induire l'utilisateur en erreur matérielle.

16. Utilisations à risque élevé et utilisations interdites

IuVeAI doit appliquer des contrôles supplémentaires aux utilisations de l'IA susceptibles d'affecter matériellement l'emploi, le crédit, l'assurance, les soins de santé, les droits juridiques, l'identification biométrique, les services publics, les infrastructures essentielles, l'application de la loi ou les actifs financiers. La fonctionnalité entrant dans des catégories réglementées ou interdites doit faire l'objet d'une évaluation juridique et des risques spécifiques avant le déploiement. La disponibilité d'un modèle capable n'autorise pas automatiquement cette utilisation.

17. Prise de décision automatisée

Lorsqu'un système d'IA aide à prendre des décisions corrélatives, il devrait clairement faire la distinction entre la recherche d'information, la recommandation, la notation, la décision automatisée et l'exécution. Lorsque la loi l'exige, les utilisateurs doivent avoir accès à l'examen humain ou à un autre mécanisme de contestation approprié.

18. Gouvernance de la sécurité

IuVeAI applique des contrôles de sécurité fondés sur le risque, y compris, le cas échéant, le cryptage en transit, le hachage sécurisé des mots de passe, la protection des clés de l'API, la séparation secrète, l'authentification, le contrôle d'accès fondé sur le rôle, la limitation des taux, la protection des sessions, l'enregistrement des audits, la gestion de la dépendance, l'assainissement de la vulnérabilité, les sauvegardes, les contrôles de récupération et la surveillance des services. Les contrôles de sécurité doivent être revus périodiquement en fonction des changements apportés à l'architecture et aux modèles de menace.

19. Gestion des secrets

Les secrets ne doivent pas être stockés directement dans les dépôts publics, les frontend JavaScript, les journaux publics, les ensembles de données de formation, les charges utiles analytiques ou l'historique de chat ordinaire. Les clés et les identifiants d'API doivent être globulés, révocables et séparés par but. Clés de licence IuVe Marketplace (mp_live_*) et les références IuVeAI API (kai_live_*) doivent rester logiquement séparés.

20. Gouvernance de l ' accès

Les décisions d'accès devraient être fondées sur l'identité et le rôle authentifiés. L'accès privilégié devrait suivre : Identité → Authentification → Rôle → Portée → Politique → Action. L'accès administratif ne doit pas être accordé uniquement par la possession d'un identificateur public. Les mesures privilégiées devraient être vérifiables.

21. Intégrations de tiers

Les services connectés tels que GitHub et les API externes doivent fonctionner en utilisant uniquement les autorisations requises pour la fonctionnalité demandée. Les références d'intégration doivent être révocables. L'élimination d'une intégration devrait mettre fin à l'accès futur chaque fois que cela est techniquement possible. L'intégration de tiers n'accorde pas à IuVeAI la propriété de contenus tiers.

22. Transferts de données

Lorsque des renseignements personnels ou confidentiels sont transférés à un tiers ou à une autre juridiction, IuVeAI devrait évaluer les exigences applicables en matière de confidentialité et de contrat. Le cas échéant, des garanties appropriées doivent être établies avant le transfert.

23. Exploitation forestière et vérification

IuVeAI peut conserver les dossiers de sécurité et de vérification opérationnelle nécessaires pour établir qui a exécuté une action; quel service ou agent l'a exécutée; quand elle s'est produite; quelle capacité a été utilisée; si l'action a réussi; si l'approbation était nécessaire; et les événements de sécurité pertinents. Les registres d'audit eux-mêmes doivent être protégés contre toute modification ou divulgation non autorisée. Les journaux ne doivent pas contenir inutilement de secrets complets ou de charges utiles confidentielles.

24. Gestion des risques

IuVeAI utilise une approche fondée sur le risque. Les risques peuvent comprendre le risque de confidentialité, le risque de cybersécurité, l'hallucination du modèle, l'injection rapide, la fuite de données, l'escalade des privilèges, l'utilisation d'outils malveillants, le compromis entre la chaîne d'approvisionnement, la panne du fournisseur, la dégradation du modèle, une action autonome incorrecte, le risque réglementaire et le risque de réputation. Le risque est évalué selon la probabilité × Impact × Exposition. Les contrôles doivent être proportionnels au risque qui en résulte.

25. Registre des risques d ' IA

Les composants d'IA matériels devraient être représentés dans un registre interne des risques d'IA. Chaque dossier peut contenir le système, le propriétaire, le modèle, l'objet, les utilisateurs touchés, les catégories de données, la classification des risques, les risques connus, les mesures d'atténuation, l'état d'évaluation, l'état de déploiement et la date d'examen.

26. Évaluation des facteurs relatifs à la vie privée

Une évaluation des risques liés à la protection de la vie privée ou à l'IA devrait être effectuée avant de déployer des fonctions susceptibles de créer un risque accru pour les personnes, y compris le profilage à grande échelle, le traitement biométrique, les renseignements personnels sensibles, les décisions en conséquence automatisées, la surveillance continue ou de nouveaux transferts importants de données par des tiers.

27. Gestion des incidents de sécurité

Un incident suspect de sécurité ou de confidentialité doit être: Détecté → Contenu → Enquête → Évaluation → Rémédié → Documenté. Lorsque la loi l'exige, les personnes concernées ou les autorités compétentes doivent en être informées dans les délais applicables. Les preuves d'incident devraient être conservées suffisamment à l'appui de l'enquête.

28. Gestion des incidents liés aux AI

Les incidents d'IA comprennent des événements matériels impliquant une exécution autonome dangereuse, une divulgation importante de données confidentielles, une sortie dangereuse systématique, un contournement du contrôle de sécurité, un dysfonctionnement du modèle matériel ou une action non autorisée de l'agent. Les incidents d'IA doivent être évalués séparément des erreurs d'application ordinaires lorsque le comportement d'IA a contribué de façon significative à l'événement.

29. Droits et contrôle des utilisateurs

IuVeAI devrait prévoir les mécanismes requis par la loi applicable sur la protection des données pour permettre aux utilisateurs d'exercer des droits pertinents concernant leurs informations personnelles, qui peuvent comprendre l'accès, la correction, la suppression, la restriction, l'objection, la portabilité et le retrait du consentement. Une vérification d'identité peut être nécessaire avant de répondre à une demande d'information sur un compte privé. Les modalités de procédure sont exposées dans le document Politique de confidentialité.

30. Conservation des données

L'information ne doit pas être conservée indéfiniment sans but défini. Les périodes de conservation peuvent varier selon la fonctionnalité du service, la configuration du compte, les exigences en matière de sécurité, les exigences contractuelles, les obligations légales et les demandes de suppression d'utilisateur. La suppression des systèmes actifs ne peut pas retirer immédiatement les informations des sauvegardes protégées lorsque la rétention temporaire est techniquement nécessaire pour la reprise après sinistre.

31. Suppression des données

Les procédures de suppression devraient porter sur les copies applicables dans les bases de données primaires, le stockage de fichiers, le stockage de conversations, les index vectoriels ou de recherche, les caches, les ensembles de données dérivés, les ensembles de données candidats à la formation et les sauvegardes lorsque cela est techniquement et juridiquement approprié. Supprimer un objet visible par l'utilisateur ne doit pas laisser une copie active non divulguée utilisée pour un traitement non lié.

32. Cadre de conformité

IuVeAI cherche à fonctionner de manière cohérente avec les exigences applicables et les principes reconnus, y compris, le cas échéant: le règlement général de l'UE sur la protection des données; la loi de l'UE sur l'intelligence artificielle; les exigences applicables en matière de protection des données moldaves; les obligations contractuelles en matière de traitement des données; les principes de confidentialité par conception et de sécurité par conception; et les règles applicables en matière de propriété intellectuelle et de droit d'auteur. L'applicabilité dépend du service pertinent, de l'activité de traitement, de la compétence et du rôle de l'IuVeAI.

33. Relations avec d'autres politiques

La présente politique de la DGRC devrait être interprétée en même temps que la politique de confidentialité, les conditions d'utilisation, la politique sur les cookies, la politique d'utilisation acceptable, la politique sur l'IA et la formation modèle, les conditions de licence applicables au marché et les politiques spécifiques au produit.

34. Responsabilité en matière de gouvernance

L'exploitant d'IuVeAI est chargé d'établir le cadre de gouvernance de la DGRC. Les composantes techniques peuvent appliquer ce cadre automatiquement, mais la responsabilité de gouvernance ne peut être entièrement déléguée à un modèle d'IA. Les fournisseurs modèles, les fournisseurs d'infrastructure et les services tiers demeurent responsables de leurs propres obligations en vertu des accords et des lois applicables.

35. Application des politiques

La violation de la présente politique peut entraîner le blocage de la demande, le refus d'action de l'agent, la révocation de la capacité, la révocation de la clé API, la restriction de compte, une enquête administrative, la suspension du service ou l'escalade d'incident. L'application devrait être proportionnelle à la gravité, à l'intention et au risque.

36. Examen des politiques

La présente politique doit être revue lorsqu'il y a des changements importants à l'architecture IuVeAI, aux fournisseurs d'IA, aux capacités de modèle, aux autorisations d'agent, au traitement des données personnelles, au droit applicable ou aux menaces à la sécurité. Un examen officiel devrait également avoir lieu périodiquement même si aucun changement majeur n'a été relevé.

37. Règle de base de la DGRC

IuVeAI suit un principe de gouvernance primordial: La capacité n’est pas synonyme d’autorité.

Un système d'IA ne peut accéder aux données, utiliser des outils ou effectuer des actions que lorsque l'identité, la permission, la politique et les conditions de risque requises sont remplies.

Data → Authority → Policy → AI → Action → Verification → Audit

Cette chaîne de contrôle constitue la base de l'exécution responsable de l'IA dans IuVeAI.

Coordonnées

Pour toute question concernant cette politique, contactez l'opérateur en utilisant les détails ci-dessus ou par courriel hello@iuve.eu.