The gap in the System of Intelligence thesis
a16z named the right category. For regulated enterprise, the piece is silent on the constraint that determines whether a deal ever closes.
The System of Intelligence thesis is correct. The friend-graph metaphor is the right way to describe where enterprise software value is going. The Systems of Record are the graph, and the intelligence layer reading across them is where the work happens. The argument extends to talent more cleanly than it does to sales, but the category framing is right wherever you apply it.
The piece has one silence. For regulated enterprise, that silence is the question that determines whether a deal closes at all: where does the System of Intelligence run?
Where the thesis was written from
The a16z piece describes an architecture. The System of Intelligence reads from the Systems of Record continuously, reasons over them in the background, and arrives with drafted workflows before a knowledge worker opens her laptop. Nothing in that architecture is wrong. But the inference layer in that architecture is not on the worker's machine. It is not inside the employer's perimeter. It lives where the vendor built it, and it calls back to the Systems of Record through APIs.
That is how most enterprise software is built. Salesforce is built that way. Gong is built that way. The next hundred AI tools shipping this year are built that way. For technology companies, for mid-market companies, for most of the buyers early enterprise AI vendors are chasing, that architecture is correct and the procurement conversation is reasonable.
A bank is not that buyer. An insurer is not that buyer. A health system is not that buyer. For these companies, the question of where the inference runs is answered by legal before the product is evaluated by anyone else. That sequence matters. It means most of the current wave of enterprise AI tools is not being evaluated at regulated institutions. It is being blocked before evaluation begins.
What procurement actually decides first
At a Fortune 500 insurance carrier, six AI hiring vendors were rejected in eighteen months before Nodes ran a line of inference. None of them were rejected on product. None of them made it to a product evaluation. Legal blocked each one on architecture: the system called an external API, and candidate data traveled to a cloud the carrier did not control.
Legal blocked them. Not procurement. Not the CISO. Legal, because a single line in the carrier's data controls said employee and candidate records do not leave the perimeter. The vendor's capability, the model's accuracy, the demo: none of it came into play after that determination.
This is not an unusual result in regulated industries. Banks have analogous controls on customer data. Health systems operate under data residency rules where the question of data movement is answered by compliance frameworks before any vendor sits across the table. Defense contractors work inside classification controls that make data residency the first procurement gate of all. The architecture assumption embedded in most enterprise AI products, that inference can happen in the vendor's cloud, fails at this gate across an entire category of buyer.
What follows is not a slow procurement process. It is a terminated one. The six vendors were not told "come back in six months with a better answer." They were told no, and the search continued. The vendor who answered the architecture question correctly got a seventeen-day legal review and was in production thirty-four days after contract. That is what architectural fit does for a sales cycle.
The VPC constraint, stated plainly
A System of Intelligence for regulated enterprise is VPC-resident, or it is not a System of Intelligence for regulated enterprise.
VPC-resident means the model runs inside the customer's own cloud environment. Single-tenant means the carrier's data never participates in a shared inference pool with another customer's records. No data egress means candidate records, call transcripts, performance data, and compensation history never travel outside the perimeter. Customer-owned weights means if the relationship ends, the intelligence stays in the customer's cloud. The vendor leaves; the model stays.
This is not a deployment preference. It is the precondition for the conversation. A vendor who can offer this architecture gets to legal review. A vendor who cannot is blocked before product review begins.
Practically, this means the connectors that move data from the Systems of Record into the System of Intelligence cannot make external calls. Inference cannot make external calls. Nothing the customer's data touches can make external calls. The integration mechanism that pulls candidate records from the ATS, performance history from the HRIS, and call transcripts from the CRM into the intelligence layer runs entirely inside the customer's perimeter. The mechanism for doing that at the pace regulated enterprise requires is covered in Why a 34-day deployment reads as a red flag. The architecture point is simpler: the constraint is total, and building for it from day one produces a different product than adding a private-deployment mode to a SaaS architecture.
Two markets
The System of Intelligence market is splitting along this line. The split has not been named, and it is not priced into most views of the category.
On one side: cloud-native SoI for the tech sector and unregulated mid-market. Data residency is a preference companies may express rather than a statute they must enforce. Sales cycles are short. Procurement follows product evaluation. Winning here is a competition on model quality, integrations, UX, and speed. The tools a16z described, and most of what the current market is building, live here.
On the other side: VPC-native SoI for regulated industries. Banking, insurance, healthcare, defense, public sector. Data controls are institutional and enforced. The architecture question arrives from legal before any buyer meets the product. Sales cycles are longer and procurement is heavier, but total contract value is larger and churn is structurally lower because the architecture is a switching cost that works in both directions. A carrier with a calibrated model inside their VPC, trained on four years of their own production data across 10,765 agents, is not going to run an eighteen-month procurement cycle for a replacement. The moat is inside the perimeter.
These are two different products, and engineering work that builds for one does not transfer cleanly to the other. When the vendor never sees production data, model improvement runs through a mechanism designed for that constraint: shadow evaluation inside the customer's cloud, weight updates that pool learning by industry without moving raw records, proactive PII stripping with a verification layer on top. What leaves a customer's environment is weights, never data. The weights leave. Your data never does. covers the mechanism. The point here is that it is a design constraint baked into the architecture from day one.
The governance question that comes with the architecture
VPC deployment clears legal. Governance gets the deal to the business owner.
Every AI system in regulated enterprise eventually faces a leader whose role is more compliance-facing than engineering-facing. This person will not say: I cannot evaluate a model. They will say: too early. Too risky. We are not early adopters. The question they are not saying out loud is: when an auditor asks why the system made a recommendation, what is the institution's answer?
The architecture answer is necessary but incomplete. Yes, the data stays inside the perimeter. That does not address what the system does with it once it is there. The complete answer is a queryable Decision Trace on every action: what was read, what was weighted, what the reasoning was, what human input changed it, what the second signer confirmed, what was approved, what was declined. An auditor can pull the trace and reconstruct a decision without taking anyone's word for it. What control model lets you move that fast? covers the full control model. The short version is that a queryable trace converts "we will need to review this" into "here is the record," and regulated institutions know what to do with a record.
Where the thesis is approximate
a16z's piece is precise about which direction enterprise software value is moving. That argument holds across industries. Where it is approximate is about where the intelligence runs.
For the buyers the piece described, cloud inference is the right architecture. For banking, insurance, healthcare, and defense, the intelligence has to live inside the perimeter, and building for that constraint from day one is a different product decision, a different engineering investment, and a different go-to-market than building a cloud product and adding a private-deployment option.
The companies who arrive first with an architecture that clears the first legal gate in regulated industries build a moat the cloud-native tools cannot cross. By the time a competitor's architecture clears regulated procurement, the incumbent has four years of production data inside the carrier's perimeter, a model calibrated to how performance works in that company's territories, and a procurement relationship that has been audited, renewed, and expanded. The new entrant runs the same eighteen-month procurement journey from the beginning, against a system that has already compounded.
The architecture is the product.
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.