Comment Datarelix garde les identifiants hors du modèle IA

Datarelix garde les identifiants de base de données hors du modèle IA. Les services de connexion les utilisent pour tester l’accès, découvrir le schéma et exécuter les requêtes. Le modèle reçoit la question et le contexte pertinent, propose un plan structuré et laisse la validation et l’exécution à ces services.

Pour les utilisateurs métier et les analystes qui connectent une base, il faut savoir quelles informations le modèle traite, quels résultats le service conserve et ce que la connexion permet de lire. Les responsables de bases peuvent utiliser ce même flux pour examiner les identifiants et les droits.

Quelles informations sont traitées ?

Information	Utilisation dans Datarelix
Mot de passe, jeton ou clé de la base	Chiffré au repos, déchiffré par les services de connexion lorsque nécessaire ; non transmis au modèle
Noms, types, relations et descriptions des tables et colonnes	Contexte du modèle pour comprendre la question et produire une requête
Question et conversation	Préparation de la réponse et interprétation des demandes suivantes
Résultats et éléments d’exécution	Conservés par Datarelix pour consulter les réponses et rouvrir un travail
Certaines valeurs d’un résultat à une ligne	Peuvent entrer dans le contexte du modèle pour une question suivante, y compris des valeurs textuelles
Messages d’erreur de la base	Peuvent être transmis au modèle pour corriger une requête

Le mécanisme de suivi ne transmet pas les tableaux de résultats à plusieurs lignes au modèle. Cela ne signifie ni qu’aucune donnée de résultat ne lui parvient, ni que Datarelix ne conserve aucun résultat. La politique de confidentialité décrit plus largement le traitement des données du service.

Ainsi, une réponse à une ligne contenant customer_name et revenue peut fournir certaines valeurs au contexte de la question suivante. Un résultat à une ligne n’est pas nécessairement un agrégat anonyme.

De la connexion à la réponse

Ajoutez une connexion avec les accès approuvés par le responsable de la base. Datarelix teste l’accès et lit les informations de schéma accessibles à ce compte.
Posez une question. Le modèle reçoit la question et le contexte pertinent, puis propose un plan structuré.
Datarelix valide le plan et la requête. Son service de requêtes utilise la connexion enregistrée pour exécuter la lecture autorisée.
Examinez la réponse, le SQL, les tables sources, le nombre de lignes renvoyées et la durée. Les résultats conservés permettent de reprendre le travail.
Posez une question de suivi. Le contexte peut alors inclure certaines valeurs d’un résultat à une ligne, selon le mécanisme décrit ci-dessus.

Le SQL et le résultat permettent d’examiner le calcul. Ils ne prouvent pas que la définition métier est correcte. Le guide de vérification aide à contrôler les périodes, les filtres et les totaux.

Accorder les droits nécessaires au rapport

Pour le chiffre d’affaires par région, une vue contenant les dates, les régions et les montants peut suffire. La connexion n’a pas besoin des adresses des clients simplement parce qu’elles existent dans la base.

Demandez au responsable de la base d’examiner les droits effectifs du compte, y compris ceux hérités. Limiter les tables ne limite pas nécessairement les fonctions exécutables, les droits publics ou la visibilité des métadonnées. Consultez les guides de connexion pour les étapes propres à chaque moteur.

Renouvelez les identifiants dans la base, puis mettez à jour la connexion Datarelix. Le service ne renouvelle pas ces secrets à votre place. Testez la connexion après un changement pour éviter de découvrir un accès défaillant au moment de préparer le rapport.

Distinguer authentification et contexte du modèle

Un outil peut utiliser des identifiants sans les inclure dans un prompt. La distinction tient au lieu de l’authentification et au composant qui reçoit le secret. Pour un autre produit, demandez ce flux au lieu de le déduire d’une interface de discussion ou d’un outil d’exécution SQL.

Dans Datarelix, le service s’authentifie auprès de la base. La requête proposée par le modèle est validée en lecture seule avant son exécution, selon le modèle de menace décrit dans les contrôles de l’analytique IA en lecture seule. Garder les identifiants hors du contexte réduit une voie d’exposition, mais ne dispense pas de protéger leur stockage, les accès administratifs et le traitement des erreurs.

Ne collez pas de chaîne de connexion, mot de passe ou clé privée dans une question pour expliquer un problème d’accès. Saisissez les secrets dans le formulaire de connexion. Les descriptions de tables sont aussi des entrées du modèle : décrivez le sens des champs sans ajouter d’identifiants. Le guide contexte du schéma et définitions métier montre ce qu’une description utile contient.

Ce qui se passe lorsqu’une requête échoue

Une erreur de base peut signaler une colonne inconnue, un type incompatible ou un autre problème d’exécution. Elle peut être transmise au modèle pour proposer une correction. Toute requête révisée repasse la validation, dans la limite des nouvelles tentatives autorisées.

L’erreur fait partie de la revue des flux, car elle peut identifier des tables ou d’autres éléments de contexte. Elle ne justifie pas de transmettre le secret de connexion au modèle. Pour le diagnostic, conservez les informations disponibles sur les requêtes en échec et réussies, puis vérifiez que le résultat final répond à la question initiale.

Maintenir et révoquer une connexion

Désignez un responsable des identifiants avant qu’un rapport devienne récurrent ; la liste de contrôle sécurité propose un modèle de compte rendu pour cette responsabilité. Cette personne doit connaître l’identité de base utilisée, les vues accessibles et l’endroit où mettre à jour le secret après une rotation.

Changement	Contrôle avant de reprendre le reporting
Rotation du mot de passe ou jeton	Mettre à jour la connexion et la tester
Nouvelle table de reporting	Confirmer sa visibilité et ses droits sans élargir l’accès à toute la base
Évolution des responsabilités	Réexaminer les données lisibles par l’identité connectée
Révocation de l’identité	Confirmer l’arrêt de l’accès source et traiter séparément les résultats conservés

Arrêter l’accès à la base et supprimer les informations enregistrées sont deux opérations différentes. Un identifiant révoqué empêche de nouvelles lectures autorisées avec cette identité ; il n’efface pas à lui seul les résultats déjà conservés. Utilisez la procédure de suppression documentée et confirmez les règles applicables dans la politique de confidentialité.

Adapter l’accès source au travail de reporting

Un analyste qui étudie les retards peut avoir besoin d’identifiants de commandes et de dates, sans détails de paiement. Un utilisateur métier préparant les ventes régionales peut n’avoir besoin que d’une vue agrégée approuvée. Accordez les champs et lignes nécessaires, puis testez la requête réelle sous cette identité.

Examinez les rôles hérités, droits publics, fonctions et politiques avec le responsable de la base. Un rôle ayant reçu SELECT sur trois tables peut disposer d’autres droits effectifs. La documentation des connexions rassemble les exigences propres à chaque moteur.

Vérifier les modalités de travail

Les connexions, conversations et tableaux de bord sont privés au compte qui les crée. Un forfait Team mutualise les questions mensuelles entre ses sièges ; il ne crée pas à lui seul de connexions ou de tableaux de bord partagés. Confirmez séparément les besoins d’identité Enterprise.

Ne placez pas de secrets dans les questions ou les descriptions de schéma : ces textes sont des entrées du modèle. Examinez la présentation de la sécurité avec le responsable de la base, puis suivez le démarrage rapide pour connecter une source autorisée.