Why six AI hiring vendors got rejected at the same carrier
The pattern is not about product quality. It is about where the data has to go.
Six AI hiring vendors. Eighteen months. One Fortune 500 insurance carrier. Every single rejection came before the technical evaluation. Legal reviewed the architecture and said no.
Not the product. The architecture.
What "rejected on architecture" means
Most people assume enterprise procurement works like a consumer purchase: the buyer evaluates the product, likes it, and buys it. At regulated enterprises, that sequence is reversed.
Legal reviews architecture before a product demo ever happens. The question they are asking is not "does this tool work?" It is "can our data touch this vendor's infrastructure?" At a Fortune 500 carrier, that question routes through data-residency counsel, employment law, and the compliance team simultaneously. If any one of those reviews returns a no, the evaluation ends.
At a Fortune 500 insurance carrier, that review ended six engagements in eighteen months. The products were capable. Several were well-designed. The architecture was incompatible with the regulatory environment the carrier operates in.
That is a precise claim, and it is worth unpacking carefully, because the pattern is not specific to this carrier. It is the procurement sequence at every regulated enterprise running AI hiring tools: banks, hospital systems, carriers, federal contractors. Legal does not gate on product quality. Legal gates on data architecture.
This post is the extension of the System of Intelligence framing we laid out earlier this year. That piece covered why the intelligence layer sits above the system of record. This one covers what happens when that intelligence layer tries to enter a regulated enterprise through the front door.
The data that cannot move
The talent System of Intelligence needs to read a specific set of data to do its job. Understanding exactly what that data is explains why the architecture fails the legal review.
Candidate PII is the obvious category. Names, addresses, Social Security numbers, government ID data. Every state has its own rules on how this data can be processed, stored, and transferred. California has CCPA. Illinois has BIPA. New York has SHIELD. The moment candidate PII leaves the carrier's environment and enters a third-party API, the carrier is responsible for whatever happens to it at the destination.
EEOC adverse-impact data is the next category. Any AI hiring tool that screens or scores candidates generates adverse-impact records by definition. Those records are legally discoverable in employment discrimination proceedings. The carrier's compliance team will not allow that data to live outside their environment.
New York City's Local Law 144 requires automated employment decision tools to undergo annual bias audits. Illinois has the Artificial Intelligence Video Interview Act, which governs consent and data retention for AI-based interview tools. These state-level AI hiring laws are multiplying. Every one of them places obligations on the carrier as the employer, and every obligation is harder to satisfy when the data processing happens outside the carrier's walls.
Then there are SOX-controlled records for the financial services employees the carrier is hiring into licensed roles. Compensation data on existing employees that informs ramp benchmarks. Performance records that the intelligence layer needs to calibrate scoring against actual outcomes.
These categories of data, combined, define the context window the talent intelligence layer needs to function. The entire context window is regulated. Third-party API processing fails the legal review because the data cannot leave the carrier's environment under any of the applicable frameworks, regardless of what the contract says.
Why controls do not solve it
The standard vendor response to a data-residency objection is a controls package: encryption at rest and in transit, a Business Associate Agreement, a Data Processing Addendum, SOC 2 reports.
Those documents are real compliance work. They are compliance documents, and that is exactly what they are.
Encryption at rest protects data sitting on a disk. A BAA creates contractual liability for a vendor handling protected health information; the data still traveled to that vendor's infrastructure to get there. A DPA describes how a processor handles personal data under GDPR or CCPA; the processing still happened outside the data subject's origin jurisdiction.
The legal team at a Fortune 500 carrier is not confused about the difference between a compliance document and an architectural constraint. The question they are asking is binary: does the data leave our environment? If the answer is yes, the controls attached to what happens to it afterward are irrelevant to the threshold question.
This is the gap the controls conversation cannot close. Every vendor that responds to a data-residency concern with a tighter DPA or a newer certification is answering a question that was not asked. The question was: where does the model run?
What VPC-native means
VPC-native means the model runs inside the customer's cloud. Not adjacent to it. Not connected to it. Inside it.
The carrier provisions a virtual private cloud inside their own AWS or Azure account. Nodes deploys the model into that environment. The model has access to the carrier's systems (their ATS, their HRIS, their CRM) because those systems are in the same network. The data never leaves that network to be processed. The model reasons over carrier data in a carrier-owned environment under carrier-controlled security policies.
No data egress, ever.
This is the architecture that passes the legal review. At the Fortune 500 insurance carrier, legal approval came in 17 days. Total time from contract to production: 34 days. The six vendors who were rejected had been in procurement cycles ranging from three to eighteen months when they were turned away. The difference was not diligence. The difference was the answer to the threshold question.
The detailed architecture is documented at nodes.inc/security/vpc-deployed-ai-hiring. What matters here is the mechanism: the model runs where the data lives. The data never travels to the model.
The ownership argument
VPC-native deployment has a second implication that procurement rarely surfaces but legal always notices on exit: the customer owns the model.
When the model is trained and fine-tuned inside the carrier's cloud, on the carrier's data, the resulting weights are the carrier's property. Four years of applicant scoring, performance correlation, ramp benchmarking, and outcome tracking produce a calibrated model specific to that carrier's population. That intelligence belongs to the carrier.
Customer-owned weights means that if the carrier ends the relationship, the intelligence stays in their cloud. The vendor walks away. The model stays.
This matters in procurement for two reasons. The first is regulatory: data-residency requirements that apply during the active relationship apply equally to what the relationship produced. A model fine-tuned on regulated data has the same residency obligations as the data itself. Carrier-owned weights satisfy that requirement by definition.
The second is commercial: four years of production data, 10,765 agents, and 850,000+ applicants scored produce an asset. The carrier paid for that asset with their data and their production environment. A VPC-native deployment means they keep it. The compounding belongs to them, not to the vendor.
This is the answer to the vendor lock-in objection. There is no lock because there is no exit penalty. The model is theirs.
What to ask at the first meeting
Regulated enterprise buyers evaluating AI hiring vendors should put these questions to every vendor at the first meeting, before the product demo begins.
Where does the model run? If the answer is "our cloud" or "multi-tenant infrastructure" or anything that is not the buyer's own VPC, the legal review will end the conversation. Better to surface that in the first meeting than after three months of evaluation.
What data leaves our environment, and when? Ask specifically. "Nothing" is the right answer. Any answer that includes API calls to a third-party inference layer means regulated data is leaving the environment.
Who owns the model weights? If the vendor owns the weights, the customer has no exit rights and no data-residency claim on the intelligence produced by their own data. Push for customer-owned weights in the contract.
What happens to our data if we end the relationship? Deletion certificates are not the same as ownership. Verify that the carrier's own production data cannot be retained, used for model improvement elsewhere, or pooled with other customers' data without explicit consent.
Can your architecture pass a legal review at our carrier before the technical evaluation? This is the filter question. The six vendors who were rejected at the Fortune 500 insurance carrier could not answer it. A vendor who can answer it will have the documentation ready before you ask.
The filter is the market
Six rejections at one carrier in eighteen months is a description of the market.
Every Fortune 500 carrier, every large bank, every hospital system, every federal contractor runs the same legal review before any AI hiring tool enters their environment. The review asks the same threshold question. The vendors who cannot answer it are competing for the segment of the market that either is not regulated or has not yet reached the legal review stage. That segment exists. It is not the Fortune 500.
The architecture determines who can buy the product at all. The six rejections are a filter, and the filter is permanent. Every regulated enterprise AI deployment will run through it.
Saad Bin Shafiq is the founder of Nodes. Anchor pilot: Fortune 500 insurance carrier, four years of production data, 10,765 agents. Methodology: Decision Traces.