Le modèle planifie. Il n’exécute rien.
Le modèle d’IA ne détient aucun identifiant et n’exécute aucune requête. Une couche d’exécution distincte valide chaque étape, applique l’accès en lecture seule et enregistre toute l’exécution pour que vous puissiez la vérifier.
Des frontières appliquées par l’architecture
Aucune ne repose sur une consigne demandant au modèle de bien se comporter. Elles tiennent même quand ce n’est pas le cas.
- 01
Le modèle n’exécute rien.
Il renvoie un plan structuré. Une couche d’exécution distincte vérifie ce plan par rapport à un schéma strict et exécute elle-même chaque étape — une action hallucinée n’a donc aucun chemin vers votre base de données ni vers le réseau.
- 02
Chaque requête est validée avant son exécution.
Le SQL est analysé en arbre syntaxique complet — pas de correspondance de motifs — et rejeté si ce n’est pas une lecture : SELECT, CTE et opérations ensemblistes uniquement. KQL et ES|QL passent par des validateurs dédiés qui bloquent toute commande de modification ou d’administration. Une limite de lignes est appliquée à chaque requête.
- 03
Le code d’analyse n’a pas accès à Internet.
Le Python généré s’exécute dans un bac à sable isolé, sous des plafonds stricts de CPU et de mémoire. Le trafic sortant est bloqué au niveau réseau — un pare-feu de sortie, pas une vérification dans le code.
- 04
Les identifiants n’atteignent jamais le modèle.
Les identifiants de connexion sont chiffrés au repos et déchiffrés uniquement au moment où une requête s’exécute. Le modèle voit votre question et les métadonnées du schéma — jamais les détails de connexion, jamais vos tables.
- 05
Chaque compte est isolé.
Chaque enregistrement est rattaché à votre compte dans chaque requête, avec la sécurité au niveau des lignes de la base de données comme filet. Les exécutions, les connexions et les tableaux de bord ne sont visibles que par le compte qui les a créés.
- 06
Chaque exécution est enregistrée, étape par étape.
La question, le plan du modèle, ce qui a réellement été exécuté et ce qui est revenu — réouvrable depuis votre historique, pour qu’une réponse puisse être auditée après coup.
Le guide analytique IA en lecture seule : architecture, contrôles et modèle de menaces détaille chaque frontière et les menaces qu’elle arrête.
Ce qui circule, et vers où
- 01
Question
Part vers le modèle avec les métadonnées du schéma : noms de tables et de colonnes, types, clés et les descriptions que vous avez renseignées. Les résultats bruts des requêtes ne sont jamais renvoyés au modèle.
- 02
Plan
Le modèle renvoie un plan structuré. La couche d’exécution le valide par rapport à un schéma strict avant la moindre exécution.
- 03
Exécution
Chaque étape s’exécute dans un service isolé : exécution de requêtes en lecture seule sur votre base de données, ou Python dans le bac à sable sans réseau.
- 04
Résultat
Les tableaux et les graphiques vous reviennent et sont conservés avec la trace de l’exécution. Seul le jeu de résultats de la question posée est conservé — vos tables ne sont jamais copiées.
Pour le parcours complet du flux de données — ce que reçoit le modèle, qui détient la connexion et où vivent les secrets — voir comment Datarelix garde les identifiants de base de données hors du modèle d’IA.
Ce que nous conservons — et ce que nous ne faisons pas
Conservé
- Informations de compte : nom, e-mail, méthode de connexion.
- Métadonnées de connexion : hôte, port, dialecte, périmètre de schéma.
- Identifiants de connexion — chiffrés au repos, déchiffrés uniquement pour exécuter une requête.
- Traces d’exécution : la question, le plan, la requête exécutée et le jeu de résultats de cette question.
- Télémétrie d’usage agrégée. Aucun contenu de ligne.
Jamais fait
- Nous ne copions pas vos tables sur notre infrastructure.
- Nous ne transmettons pas les résultats bruts des requêtes au modèle.
- Nous ne donnons pas d’identifiants au modèle et ne le laissons pas appeler votre base de données directement.
- Nous ne laissons pas le code d’analyse accéder à Internet.
- Nous ne partageons pas vos données avec des tiers, au-delà du fournisseur du modèle et de l’infrastructure cloud qui fait tourner le service.
Le service tourne sur Google Cloud. Le trafic est chiffré en transit, le stockage est chiffré au repos, et les identifiants de connexion portent une couche supplémentaire de chiffrement applicatif.
Authentification et accès
Connexion
Google, Microsoft (mono- ou multi-tenant, avec liste d’autorisation de tenants en option), ou e-mail et mot de passe avec vérification et réinitialisation.
Vos permissions, par utilisateur
Sur Azure SQL, Databricks et Kusto, les connexions peuvent s’exécuter avec les permissions de base de données propres à l’utilisateur connecté (On-Behalf-Of par utilisateur) plutôt qu’avec un compte de service partagé.
Moindre privilège, recommandé
Connectez-vous avec un utilisateur de base de données en lecture seule, limité aux schémas sur lesquels vous voulez poser des questions. La lecture seule est appliquée à la couche des requêtes dans tous les cas — un utilisateur à périmètre restreint en fait une défense en profondeur.
Limites connues
Là où le système peut encore se tromper de réponse, et le contrôle qui le contient.
-
Si une question est ambiguë
Le modèle peut interpréter une question ambiguë autrement que vous ne l’entendiez — la requête s’exécute, mais mesure quelque chose de légèrement différent. Chaque réponse affiche sa requête et ses sources : un coup d’œil suffit pour voir exactement ce qui a été mesuré. Et quelle que soit l’interprétation, elle ne peut que lire les données — jamais les modifier.
-
L’accès suit ce que vous connectez
Datarelix peut lire ce que l’identifiant connecté peut lire — et rien de plus. Les garde-fous tiennent dans tous les cas : validation en lecture seule sur chaque instruction, limites de lignes automatiques et aucun chemin d’écriture. Connecter un utilisateur de base de données en lecture seule et à périmètre restreint ajoute une couche supplémentaire ; nos guides expliquent comment.
-
Un modèle d’IA traite vos questions
Votre question et les métadonnées du schéma sont traitées par le modèle d’IA qui alimente le service. Nous gérons le fournisseur, les clés et la configuration — vous n’avez rien à mettre en place, et vos tables ne font pas partie de cet échange.
Questions, audits et signalements
Les questionnaires de sécurité, le statut SOC 2 et les DPA passent par la page de contact. Les signalements de vulnérabilité vont directement à support@datarelix.ai. Si vous menez une évaluation, partez de la checklist de sécurité de l’analytique IA, indépendante des fournisseurs.
Voyez les garde-fous par vous-même.
Connectez une base de données, posez une question et lisez la requête qui s’est exécutée.
14 jours gratuits · sans carte bancaire