The moat is the data that never leaves your VPC
Feb 18, 2026
Every AI vendor will tell you their model is smarter, faster, cheaper.
In regulated hiring, none of that mattered. The only thing that moved legal from “absolutely not” to “approved in 17 days” was one architectural choice: the model never leaves your infrastructure, and your data never leaves your VPC.
Everything else – accuracy, ramp time, cost savings – fell out of that constraint.
The obvious moat everyone chased (and why it failed in hiring)
Most AI companies started with the same story arc:
Build a better model.
Wrap it in an API.
Centralize as much customer data as possible.
Win with scale.
That playbook works when you’re optimizing product recommendations or email copy. It breaks the moment you touch candidate PII, performance reviews, or any data a regulator might reasonably ask about.
In enterprise hiring, the questions are different:
Where does candidate data go?
What external systems see it?
Can we prove how decisions were made if a regulator, plaintiff, or journalist asks two years from now?
A centralized API is the worst possible answer to those questions. The most “obvious” moat – aggregating everyone’s hiring data in one place, then training a giant model on it – is the one thing legal will never let you do.
So we took the opposite path: no shared model, no central data lake, no magic API in our cloud. Everything runs inside yours.
What 660,000 candidates taught us about constraints as moats
When we started, “run all of this inside the customer’s VPC” felt like a handicap.
It meant:
No managed GPU cluster we could control.
No centralized labeling team.
No easy way to debug by “just pulling the logs” from our own environment.
No shared, cross-customer training set living anywhere we could touch.
But then CNO Financial, a Fortune 500 insurer, did something surprising.
They had blocked every AI hiring tool for 18 months over data privacy and sovereignty concerns. They wouldn’t let vendors send candidate data to external APIs. They wouldn’t let anyone train models on their performance reviews. They wouldn’t accept “trust us” as a governance model.
They approved us in 17 days.
Not because our marketing was better. Not because our slide deck was prettier. They approved us because the architecture made their favorite answer possible: “Nothing leaves your cloud.”
That decision unlocked everything else:
We could actually train models on real performance outcomes, not proxy metrics.
We could ingest ATS data, HRIS data, and CRM/communication traces with full legal sign-off.
We could validate predictions against actual performance reviews, not click-through rates or survey scores.
The constraint that looked like a handicap – never letting the model or data leave their infrastructure – became the reason we were allowed to touch the one dataset that actually matters: who they hired, how they performed, and why.
Small models, big context, zero external calls
From the outside, “AI in your VPC” sounds like a checkbox. In practice, it forces you to make different technical choices.
We chose small, specialized models over huge, general ones.
Model size: 7B–20B parameter models that can run comfortably in a customer’s environment, often on CPU, without requiring a mini–research lab worth of GPUs.
Deployment: single-tenant, inside the customer’s VPC on AWS, Azure, or GCP, with no outbound calls to external model APIs.
Training: fine-tuning on the customer’s own ATS + HRIS + communication data, entirely inside their environment.
When we compared approaches on predicting top performers, the pattern was clear:
Prompting frontier models against generic job data got you “smart-sounding” answers and mediocre correlation with actual performance.
Fine-tuning smaller models on a company’s real outcomes – who turned into top performers, who didn’t, and what the interview panels decided – produced dramatically higher accuracy, because the model finally saw the ground truth it needed.
But the only reason those smaller models could see that ground truth was the one thing most AI vendors avoid: we never asked the customer to send that data anywhere.
The AI lived where the data already was.
The decision traces everyone else throws away
Traditional systems of record all have the same blind spot.
ATS: knows who applied, who advanced, who got hired. It doesn’t know why.
HRIS: knows who got promoted, who underperformed, who left. It doesn’t know what was said in the hiring loop.
CRM: knows how reps talk to customers. It doesn’t know which of them are top performers a year later.
Everyone sees the outcome. No one captures the reasoning.
In hiring, that missing layer is where the real moat lives.
We call the missing layer “decision traces” – the sequence of signals, judgments, and exceptions that led from “new candidate” to “hired” or “rejected,” and then from “hired” to “top performer” or “miss.”
A few examples:
The underwriter who didn’t meet the stated years-of-experience requirement but was pushed through by a hiring manager who “just knew” – and turned into a star.
The sales candidate the panel split on, where one interviewer dug in on objection handling and later turned out to be right.
The engineer who came from an unconventional background, failed a generic coding screen, but excelled on a bespoke take-home and is now a staff-level anchor.
In most companies, that context is ephemeral. It lives in:
Slack channels and email threads.
Verbal debriefs after interviews.
The gut feelings of your best hiring managers.
The minute the decision is made, the trace dies.
We made a different choice: treat every hiring decision as an eval that should be preserved and abstracted into patterns.
Not “John Smith had X,” but “candidates with pattern X, in context Y, tend to succeed in role Z.”
We call those EVPs – Evals and Patterns. They are the atomic unit of our moat.
They are generated at decision time, not reconstructed later.
They live inside the customer’s VPC, not in some vendor’s shared sandbox.
They can be queried, audited, and used to train future models – without exposing raw PII.
You can’t scrape this dataset. You can’t buy it. You can’t approximate it from resumes alone. You have to be present when the decision is made.
That’s where we live.
Why incumbents and foundation models can’t follow you into the VPC
If the moat is the data that never leaves your VPC, the obvious next question is: why can’t incumbents or foundation model providers just copy this approach?
On paper, they have everything:
HRIS vendors sit on decades of employee data.
ATS vendors own the candidate journey.
Data platforms aggregate everything downstream.
Foundation models have the most powerful pattern-machines ever built.
In practice, they’re in the wrong place in the workflow.
HRIS sees outcomes, not decisions. By the time someone is in the HRIS, all of the messy debates and exceptions that led to their hire are gone.
ATS sees pipeline, not performance. It watches candidates move from stage to stage but rarely sees the long-term performance data that proves whether those decisions were right.
Data platforms are downstream archives. They receive data only after systems of record have flattened all the nuance into structured fields.
Foundation model providers are structurally blocked from ever training on the full decision traces of regulated hiring. Legal teams will not allow raw candidate and performance data to leave the enterprise perimeter for someone else’s model training pipeline.
All of them can approximate behavior from the outside. None of them can sit in the middle of the decision, capture the trace, and train on it – inside your infrastructure, under your governance, with your legal team actually comfortable.
We didn’t win access to that position with slogans. We earned it by accepting constraints:
No central model trained on everyone’s candidates.
No centralized data lake in our cloud.
No “trust us, we anonymize” pitch decks.
We show up where it matters – in the VPC, at decision time – and we stay there.
From hiring intelligence to workforce intelligence
Once you start capturing decision traces and outcomes in one place, something else happens.
You stop “doing AI” for one decision and start building a context graph for every decision.
The same infrastructure that helps you answer “Who should we hire?” starts answering:
Who is on a fast path to leadership, based on the same patterns we see in your best managers?
Which internal candidates should we consider for this role, based on demonstrated strengths, not job titles?
Where are we taking hiring risks that routinely pay off, and where are we taking risks that consistently backfire?
What does a successful ramp actually look like, and how do we compress it?
At CNO, once the hiring loop was instrumented and the system had a few quarters of outcomes, something changed in ramp:
New hires with access to an AI co-pilot trained on top performer patterns stopped spending their first 8–12 months “figuring things out.”
They adopted the behaviors and workflows of your best people in 6–8 weeks, because the system could surface the “how” behind success, not just the “what.”
The same traces that made hiring defensible and compliant made ramp predictable and compressible. The moat we built for legal turned out to be the moat for performance.
The three questions enterprise buyers should ask every AI vendor
If you are buying AI for hiring – or anything else touching regulated, high-stakes workflows – the marketing all starts to sound the same.
Everyone promises:
Better candidates, faster.
Reduced bias.
Better “insights.”
Ignore the slogans. Ask these three questions instead:
Where does my data actually live?
If the answer involves their cloud, their API, or any external model endpoint, assume legal will have concerns.
If they can’t run entirely inside your VPC, they can’t safely train on your most sensitive data.
Can this system train on my performance outcomes without sending anything outside my infrastructure?
If not, they are guessing. They might sound smart, but they can’t see the truth.
The models that matter are the ones that can learn from your hires, your misses, your promotions, your regretted losses – on your hardware, under your governance.
Will I have a queryable record of how decisions were made a year from now?
If all you get is a score and a “trust us” explanation, you don’t have a defensible system.
You need decision traces – not just to satisfy regulators, but to understand your own organization’s judgment.
If the answer to any of these is “no,” you’re renting pattern recognition from someone else. You are not building a moat. You are training theirs.
What this means for AI builders
If you’re an AI founder, this is the part most people don’t want to hear:
Your moat is not a bigger model. It’s not a glossier orchestration diagram. It’s not “agents” as a buzzword.
Your moat is the dataset that:
No one else can legally touch.
No one else can structurally observe.
No one else can easily recreate without standing where you stand in the workflow.
The constraint that protects that dataset – “never leaves the VPC,” “no external APIs,” “no central training lake” – is not your enemy. It is the shape of your moat.
Design for that constraint from day one.
Choose model sizes and architectures that can live where the data is, not where your GPU credits are.
Build for fine-tuning on real outcomes, not prompt-engineering against generic benchmarks.
Capture the full decision trace, not just the final label, or you will starve your future models of the only signal that matters.
The accelerant is not one more clever prompt. It’s the simple, boring truth:
You either control the data that never leaves the VPC, or you don’t.
We chose the hard path early: no shared model, no central data.
In exchange, we got something harder to copy than any feature list:
We became the place where your talent decisions are made, remembered, and improved – and we never had to ask you to send your crown-jewel data anywhere else.
