“AI-powered” usually means “send us your data and we’ll run a model on it.” KeplerAI’s AI is built the opposite way: the agents do the modeling work, but they never see a single raw record. Understanding how requires looking at exactly what the agents consume.
Two agents, two roles
- The business agent understands the compliance problem — KYC, AML, fraud, scoring — translates the need, and interprets results.
- The data-science agent implements the “how”: it generates transformation, training and scoring code in DuckDB SQL, PySpark or Polars.
The business agent delegates technical tasks to the data-science agent, coordinator-style.
What the agents actually see
This is the crux. To generate code, an agent needs to understand the shape of your data, not its contents. So it receives:
- Schema — table and column names, types.
- Column statistics — fill rates, ranges, distributions, top values.
- Optional anonymized or synthetic samples — never real rows.
From that metadata, the agent writes code. The code is shipped to your data plane and executes where the data lives. What comes back is aggregated results and metrics — never raw data.
The boundary, precisely
Down to the data plane: metadata and code. Up to the control plane: aggregates, metrics, errors. Blocked at the boundary: raw rows, database credentials, trained model weights. Tools like get_schema, profile_columns, run_duckdb_sql and train_model all execute in the data plane; only their filtered results return.
Where the model runs
Reasoning and code generation use a frontier model (Claude) in the control plane, which only ever sees metadata. When a task genuinely needs a model to touch raw data — classifying free text, extracting entities — a local model runs in the data plane, so even that never leaves. For the strictest clients, a 100% local isolation tier keeps metadata home too.
The lesson: “AI” and “data sovereignty” aren’t opposites. Put the boundary in the right place, and you get both. See it on the Platform page.