What If an AI Analyst Never Saw Your Raw Data?
Overview
The datasets that matter most are often the datasets AI cannot touch.
Patient records sit behind ethics approvals. Student outcomes are protected by institutional policy. Government data is governed by legislation and data-sharing agreements. Survey responses contain identities, beliefs, and experiences that participants never agreed to send to a model provider. The same is true of employee records, insurance claims, financial histories, administrative databases, customer data, and proprietary company information.
There is an obvious use for AI in all of these settings. A capable model could help formulate an analysis, write the code, examine the statistical evidence, suggest additional tests, and explain the result. The problem is that most AI tools begin by sending the material being analysed to the model. For sensitive or restricted data, that may be legally prohibited, ethically unacceptable, or simply unnecessary.
Running the model locally avoids that transfer. Sift supports local models, but local inference has its own practical limit. Reaching frontier-level performance can require considerably more compute than most individuals and organizations have available.
I built Sift to separate access to a capable model from access to the raw data.
Sift is a local-first AI data analyst. A model can help plan the work, write Python, R, or Stata, and interpret the result. The dataset and the computation remain on the user’s machine. The model receives a controlled statistical result rather than the records used to produce it.
How the Separation Works
A Sift session begins with a local dataset, a folder, or an extract that the user has selected from an external source. Sift profiles the material locally. It identifies the structure of the data, variable types, missingness, ranges, and fields that may contain identifiers.
The user controls how much of that profile can be shown to the model. In a highly restricted setting, the model might receive only the variable names. In another setting, it might also receive labels, types, or bounded summaries. This gives the model enough context to reason about the analysis without placing the underlying observations in its prompt.
Suppose a researcher wants to estimate whether an intervention changed an outcome. The model can inspect the permitted schema, propose an appropriate design, and write the analysis. It sends the code to Sift, which executes it locally against the full dataset. The model never receives a connection to the database or a copy of the file.
That execution environment is deliberately narrow. Generated code does not receive a general shell, unrestricted filesystem access, stored credentials, or a network connection. Sift uses operating-system confinement on each supported platform: a deny-by-default sandbox on macOS, AppContainer on Windows, and Bubblewrap on Linux. Readable and writable paths are explicitly limited to what the analysis requires. If the required confinement cannot be established, Sift does not run the code.
The route back to the model is also controlled. Sift does not forward arbitrary terminal output. Analyses produce structured result envelopes with defined fields and size limits. Each result is tied to the current run and checked before it can enter the model’s context.
Statistical disclosure controls are applied at that boundary. Small cells can be suppressed, along with complementary values that would otherwise reveal them by subtraction. Precision can be limited when the available sample does not support a more detailed result. Text originating in the dataset is handled as untrusted content rather than as an instruction to the model.
The user still has access to the complete local analysis. They can inspect the raw data, generated code, full output, plots, profiles, and verification results. The model sees the user’s question, the permitted description of the data, and the statistical evidence that has passed the disclosure boundary.
This creates two views of the same analysis. The person responsible for the data retains the complete record. The model receives what it needs to continue the work, but not the rows behind the result.
More Than a Private Chat Window
Sift is not a chat interface placed on top of a small set of predefined queries. The model can write and revise real analytical code, which allows the workflow to extend beyond simple summaries and charts.
Its maintained methods cover descriptive and inferential statistics, regression, longitudinal and mixed models, survival analysis, survey-weighted estimation, missing-data methods, prediction, time series, Bayesian workflows, and study design. It also supports causal methods including matching and weighting, difference-in-differences, event studies, synthetic control, regression discontinuity, and instrumental variables.
The usefulness of that range depends on the domain. A physician or clinical investigator might examine treatment outcomes without sending patient-level records to a model provider. A researcher might work with restricted participant or administrative data. A public institution might evaluate a programme while keeping citizen records inside its existing environment. A company might investigate pricing, operations, claims, workforce patterns, or customer behaviour without exposing its underlying records.
Sift also preserves the analytical record as the session develops. The plan, code, local results, verification outcomes, source provenance, model usage, and disclosure history can remain attached to the work. That record can be used to produce reports, codebooks, disclosure statements, AI-use statements, and replication packages without including the raw data.
Working With the Existing Data Stack
Sift is designed to work with data where it already lives.
It supports the formats commonly used in research and industry, including CSV, Excel, Stata, SPSS, SAS, R, Parquet, Arrow, ORC, and JSON. It can also work with scientific, clinical, and geospatial formats such as HDF5, NetCDF, MATLAB, FITS, GeoPackage, Shapefile, GeoTIFF, VCF, NIfTI, DICOM, and FHIR.
For databases and warehouses, Sift supports SQLite, DuckDB, PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Snowflake, BigQuery, Redshift, and Databricks SQL. The user selects and initiates a read-only query. The resulting extract is materialized locally before entering the normal analysis pipeline, while the database credentials remain outside both the model prompt and the generated-code environment.
Sift can also import user-selected material from cloud storage and research services, including Amazon S3, Google Cloud Storage, Azure Blob Storage, Zotero, OSF, Dataverse, Zenodo, Figshare, Dryad, Google Drive, OneDrive, SharePoint, Box, Dropbox, REDCap, Qualtrics, KoboToolbox, and OpenClinica. These integrations are selection-based. The user chooses a particular object; the model cannot browse the account behind it.
On the model side, Sift supports Anthropic, OpenAI, Gemini, Amazon Bedrock, and local or remote OpenAI-compatible endpoints. Provider credentials stay in the operating system’s credential service.
Sift is available on macOS, Windows, and Linux and is open source under Apache 2.0.
Conclusion
Most AI data systems are designed around expanding model access. Sift is designed around limiting that access to what an analysis requires. It is an end-to-end analytical environment in which raw data remains local, model-visible evidence is explicitly governed, and every substantive result retains a record of how it was produced.
The value of Sift is not that it makes every dataset available to AI. It is that it makes AI useful without requiring that access.