How does iDBQuery handle PII and sensitive data?
iDBQuery is designed so sensitive data and PII stay inside your own walls: it queries your sources in place instead of copying them out, enforces role-based access on every query, and can run in your VPC, on a single server, or fully air-gapped. Your data is never used to train an AI model.
The way iDBQuery is built matters more here than any single feature, so the honest answer leads with architecture.
- Query-in-place, not copy-out. iDBQuery builds one live model over your sources and queries them where they live. Because it doesn't force-copy your databases into a separate store, PII isn't duplicated across yet another system.
- Deploy where the data is safest. Run in the cloud, inside your own VPC, on a single on-premise server, or fully air-gapped. A Desktop app and Embedded SDK keep data local, so records with personal or confidential information never have to leave your network.
- Access is controlled. Role-based access control limits which sources and workspaces each person can reach, and permissions are enforced at the query layer, not just hidden in the interface.
- Encryption protects data in transit (TLS) and the metadata and credentials iDBQuery stores at rest.
- No training on your data. Your data is not used to train any AI model; iDBQuery uses it only to answer your questions.
Because every answer is cited back to its exact source rows, you can also see precisely which sensitive records a given figure touched — useful when responding to a data-subject request or an internal review. For teams with the strictest obligations, the air-gapped and Desktop options mean sensitive data can be analysed with plain-language questions while never crossing your perimeter at all.
Updated 2026-06-22