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. At the named carrier, the entire context window is treated as regulated. Third-party API processing did not clear their specific review; the verifiable deployment control required that data not leave the carrier's environment, regardless of what a contract might say.
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's deployment used a private customer VPC. That establishes the hosting boundary, not automatic access to every system the carrier owns. Each source and action requires its own authorization, supported operation, mapping, and validation. Do not infer a functioning CRM-transcript or broad cross-system workflow integration from the VPC diagram.
Zero customer production-data egress.
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.
Where customer-specific weights and calibration artifacts exist, ownership and usable exit rights belong in the agreement. The four-year retrospective record is distinct from the live application, which has operated at the carrier since January 2025. Having that history does not establish that the software automatically learns from every later outcome.
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 and a historical study cohort of 10,765 agents support validation. Separately, the live deployment has scored 900,000+ candidates since January 2025. Together they produce a customer-owned context record. The carrier paid for that asset with its data and production environment. A verifiable deployment-mode control means it keeps the record.
This narrows one major source of vendor lock-in because the model and weights remain in the carrier's environment. Integration, operating change, and replacement costs can still create exit friction, so ownership is a control rather than a claim that switching is free.
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? At the named carrier, if the answer was anything that did not amount to a verifiable deployment control inside their own boundary, the review ended the conversation. We observed that surfacing deployment controls in the first meeting saved months of evaluation.
What leaves our environment, and when? Ask for the full approved data path, including models, tools, logs, backups, and support. Nodes does not default to pooling confidential customer memory or training across tenants. Any contemplated artifact export requires explicit authorization and security evaluation; two identifier checks alone would not prove that weights are safe to share.
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.
The six rejections describe one carrier's procurement process, not every regulated enterprise. Other carriers, banks, hospital systems, and federal contractors apply their own legal and security controls. Data residency, model ownership, approval authority, and exit terms are recurring diligence questions, but the threshold and review path vary by organization and use case.
Architecture can determine whether a product enters a regulated buyer's evaluation. The durable lesson from this carrier is narrower: make the deployment boundary and ownership terms testable before a long technical evaluation begins.
Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.