There’s an old rule in distributed systems: moving computation to the data is cheaper than moving data to the computation. For regulated workloads, it’s not just cheaper — it’s the difference between a compliant architecture and a risky one.
Three reasons near-data wins
Security. Data you don’t move can’t be intercepted or copied along the way. The raw records stay in one place, behind one boundary. That’s the foundation of data sovereignty.
Latency. The round trip to a remote service dominates the cost of scoring. Run the model next to the data and the network hop disappears — which is how you get sub-100ms fraud scoring.
Cost. Egress fees, duplicate storage and the overhead of keeping copies in sync all vanish when the data has one home.
How KeplerAI does it
The data plane Runner ships with a fast local engine — DuckDB for analytical SQL, Spark-local for heavier jobs. Transformations, training and scoring all run there, on Parquet or directly against your databases. The control plane sends code; the Runner executes it and returns aggregates.
When the LLM has to touch data
Sometimes a model genuinely needs raw content — classifying a free-text field, extracting entities from a document. Rather than shipping that text out, KeplerAI runs a local model in the data plane for those narrow tasks. Frontier-model reasoning stays in the control plane on metadata only.
The default, inverted
Cloud-first architectures made “move the data” the reflex. For compliance, invert it: data stays, compute travels. Near-data isn’t an optimization — it’s the safe default. Read how the Runner connects outbound only.