Why We Don't Use
Cloud AI APIs

What Cloud AI APIs Actually Do With Your Data

When a KYC provider uses AWS Rekognition to compare a selfie against an ID photo, here's what actually happens: the selfie leaves the provider's server, traverses the internet (TLS-encrypted, yes), arrives at an AWS region, gets decoded in Amazon's infrastructure, processed by Amazon's models on Amazon's GPUs, and a response is sent back.

During that round trip, your face — the biometric data that uniquely identifies you — exists in Amazon's memory. Briefly. But it exists there.

Now read the fine print:

The question isn't whether these companies are trustworthy. It's whether your users' biometric data needs to travel through any third party's infrastructure at all. We decided the answer is no.

What We Run Instead

Every model in our pipeline runs on our own servers via ONNX Runtime on CPU. No cloud API calls. No third-party inference. No data leaving our infrastructure.

All four neural networks are INT8 quantized — 72% smaller, roughly 2x faster, with zero accuracy loss. They run on standard x86 CPUs. No GPU required. No specialized hardware. The entire inference pipeline fits comfortably on a modest VPS.

The Privacy Argument

This is the one that matters most.

When you use FaceVault, your selfie goes from your camera to our server. That's one hop. It gets processed, encrypted at rest (AES-256-GCM), and eventually purged according to your retention policy. At no point does it transit a third party's network, exist in a third party's memory, or touch a third party's disk.

Compare that to a provider using AWS Rekognition:

FaceVault:
  User → Our server → Local ONNX inference → Result
  (1 hop, 0 third parties)

Cloud AI provider:
  User → Provider server → AWS Rekognition → Provider server → Result
  (3 hops, 1 third party, 2 network transits)

Under GDPR, every entity that processes personal data is either a controller or a processor, and each adds compliance obligations, data processing agreements, and liability surface. A cloud AI API is an additional processor. We have zero additional processors in our ML pipeline.

Privacy isn't a feature you bolt on. It's an architecture you build from the ground up. Running our own models is the foundation of that architecture.

The Cost Argument

Cloud AI APIs charge per call. Every face comparison, every OCR extraction, every detection — a line item on your bill.

That looks cheap at $0.005 per verification. But it's a marginal cost that scales linearly with volume. At 100K verifications per month, that's $500/month just for cloud AI — on top of your compute, storage, bandwidth, and everything else.

Our approach has zero marginal cost for ML inference. The models run on the same server that handles the API requests. The 100,001st verification costs exactly the same as the first: nothing extra. Our per-verification cost decreases as volume increases. Cloud AI costs are constant.

This is how we offer verification at a fraction of what Sumsub and Onfido charge. We're not subsidizing with VC money. We just don't have a cloud AI bill.

The Latency Argument

A cloud AI API call involves:

Steps 2–4 and 6 are pure overhead. On a local inference call, none of them exist. The image is already in memory. The model is already loaded. The result is returned from a function call, not a network request.

In practice, a cloud API call adds 100–400ms of latency per model invocation. When your verification pipeline runs multiple models sequentially (face detection, face matching, OCR, anti-spoofing), those milliseconds compound. Local inference eliminates the network overhead entirely.

The Control Argument

When you depend on a cloud AI API, you depend on:

When we run our own models, we control everything. We choose the model. We choose the version. We set the thresholds. We decide when to update. We know exactly what code is running on every request, because we wrote it.

Model updates happen on our schedule, after our test suite passes, after we've validated against our calibration dataset. Not when a cloud provider pushes a silent update on a Tuesday afternoon.

The Trade-offs (Honest)

This approach isn't free of trade-offs. Here's what we gave up:

These trade-offs are real. We've accepted them knowingly, because the benefits — privacy, cost, latency, control — outweigh them for our use case. A startup doing 100 verifications a day might reasonably choose a cloud API for speed of development. But if you're building a KYC platform, the infrastructure is the product. You can't outsource it.

It's a Philosophy, Not a Limitation

The cloud AI model is seductive. Write ten lines of code, get state-of-the-art face recognition. Ship it. Move on. Someone else worries about the models, the hardware, the updates.

But "someone else" is processing your users' faces. "Someone else" knows how many verifications you run. "Someone else" has a data processing agreement that they wrote, protecting their interests. "Someone else" can change their pricing, their terms, or their model at any time.

We chose a different path. Open-source models. Local inference. Encrypted at rest. Purged on schedule. No third-party processors in the ML pipeline. It's more work to build. It's more work to maintain. But it means we can look our users in the eye and say:

That's not a limitation. That's a promise.