Comment iDBQuery gère-t-il les données personnelles (PII) et sensibles ?

La façon dont iDBQuery est construit compte davantage ici que n'importe quelle fonctionnalité isolée, si bien que la réponse honnête commence par l'architecture.

• Interrogation sur place, pas de copie au-dehors. iDBQuery construit un modèle unique et vivant par-dessus vos sources et les interroge là où elles vivent. Comme il ne copie pas de force vos bases de données dans un magasin distinct, les données personnelles ne sont pas dupliquées dans un système de plus.
• Déployez là où les données sont le plus en sécurité. Fonctionnement dans le cloud, dans votre propre VPC, sur un unique serveur sur site ou entièrement isolé (air-gapped). Une application de bureau et un SDK embarqué conservent les données en local, de sorte que les enregistrements contenant des informations personnelles ou confidentielles n'ont jamais à quitter votre réseau.
• L'accès est contrôlé. Le contrôle d'accès basé sur les rôles limite les sources et espaces de travail que chaque personne peut atteindre, et les permissions sont appliquées au niveau de la couche de requête, et pas seulement masquées dans l'interface.
• Le chiffrement protège les données en transit (TLS) ainsi que les métadonnées et identifiants qu'iDBQuery stocke au repos.
• Aucun entraînement sur vos données. Vos données ne sont pas utilisées pour entraîner un quelconque modèle d'IA ; iDBQuery ne les utilise que pour répondre à vos questions.

Comme chaque réponse est citée jusqu'à ses lignes sources exactes, vous pouvez aussi voir précisément quels enregistrements sensibles un chiffre donné a touchés — utile pour répondre à une demande d'accès d'une personne concernée ou à une revue interne. Pour les équipes aux obligations les plus strictes, les options isolée (air-gapped) et bureau signifient que les données sensibles peuvent être analysées à l'aide de questions en langage naturel sans jamais franchir votre périmètre.