The vendor-of-record decision is one of the most expensive contract details in an AI engagement and one of the least visible at signing. When the AI agency builds a feature that calls a foundation model, processes user data, and deploys to the buyer’s customers, the question of who is the vendor-of-record; the entity that holds the legal relationship with the underlying AI vendors and carries the SOC 2, DPA, and EU AI Act compliance burden; determines who eats a six-figure compliance cost when an audit goes sideways or a regulator asks questions. The default in 2026 is that the buyer carries the risk: the agency uses its accounts for development, transfers ownership at delivery, and the buyer inherits the compliance posture of contracts the buyer did not design. The alternative; agency-as-vendor-of-record; is contractually heavier but moves the compliance burden to the party best equipped to carry it during the build. This piece names the four shapes the vendor-of-record decision can take, the contractual clauses that make each work, and the diagnostic question that exposes whether your current AI agency engagement has chosen the cheap shape.
It extends the AI build-vs-buy-vs-hire decision matrix for 2026. The matrix’s seventh principle holds that most sourcing decisions are re-litigated quarterly; the vendor-of-record decision is among the most under-re-litigated of them in AI agency contracts.
What vendor-of-record means in an AI engagement
In a generic SaaS context, vendor-of-record is the entity that holds the contractual relationship with the software provider; the entity whose name is on the order form, whose account is invoiced, and who is the data controller or processor under the relevant privacy regulation. Vendor-of-record is mostly an accounting decision: who pays the invoice and gets the receipt.
In an AI engagement, vendor-of-record is much more. The AI vendor’s contract specifies data handling, training rights, usage rights, retention, residency, and incident notification. Each of those terms intersects with regulatory regimes: SOC 2 (because the AI vendor is in the data flow), GDPR and analogous state privacy laws (because the AI vendor processes personal data), and the EU AI Act (because the AI vendor’s model produces decisions that may be high-risk under Annex III).
When an AI agency builds a feature that uses OpenAI, Anthropic, Google, or any other foundation model vendor, the agency typically uses its own AI vendor accounts during the build. The engagement deliverable is the code, the prompts, the eval set, and the configuration; not the AI vendor relationship. The buyer is expected to set up its own AI vendor accounts at production deployment.
The transition is where the vendor-of-record question gets sharp. If the agency has been the vendor-of-record during the build, and the buyer becomes the vendor-of-record at production, who is responsible for the data that flowed through the agency’s accounts during development? Whose SOC 2 covers the build period? Whose DPA covered the test data? The default answer; that the agency handled it during build, the buyer handles it from production forward; is operationally tidy and contractually under-specified.
Shape 1: buyer-as-vendor-of-record from day one
In shape 1, the buyer is the vendor-of-record from the engagement’s first day. The buyer’s accounts with OpenAI, Anthropic, etc., are the accounts the agency uses. The agency engineers are users on the buyer’s accounts; the buyer’s DPAs cover the data; the buyer’s SOC 2 covers the controls.
The pros: there is no transition. SOC 2, DPA, and EU AI Act exposure is on the buyer continuously; the agency is a user, not a controller. The buyer’s compliance posture is consistent throughout.
The cons: the agency cannot reuse infrastructure across clients. Most client has its own accounts; agency engineers context-switch between client accounts, which adds friction. Some agency tooling (their internal eval harnesses, their test data libraries) does not work cleanly across multiple clients’ accounts. The agency’s velocity advantage is partially eroded.
Shape 1 is the right shape for buyers in highly regulated industries (financial services, healthcare, government) where the compliance posture must be continuous and the vendor-of-record cannot be a third party even briefly. It is the wrong shape for buyers who want maximum agency velocity in the build phase.
Shape 2: agency-as-vendor-of-record with transfer at delivery
In shape 2, the agency is the vendor-of-record during the build. The agency uses its own AI vendor accounts. At delivery, the contract transfers the AI configuration (prompts, eval sets, routing config) to the buyer’s accounts. The buyer becomes the vendor-of-record from production onward.
The pros: maximum agency velocity. The agency runs its standard tooling, its standard eval harnesses, and its standard test data. The build is fast.
The cons: the transition is contractually heavy and operationally fragile. The data that flowed through the agency’s accounts during build is in the agency’s compliance scope, not the buyer’s. If the buyer needs SOC 2 evidence covering the build period, the buyer needs the agency’s SOC 2 report, the agency’s DPA with the AI vendor, and a flow-down clause in the engagement contract that gives the buyer audit rights. If any of those is missing, the buyer has a gap in their compliance posture.
Shape 2 is the most common shape in 2026 and the most under-specified. The default contract language transfers the deliverables but does not specify the compliance flow-down. The buyer signs the contract, gets the deliverables, and discovers at the next audit that there is no documented control covering the build period.
Shape 3: agency-as-permanent-vendor-of-record
In shape 3, the agency remains the vendor-of-record permanently. The agency holds the AI vendor accounts, the agency’s DPA covers the data, the agency’s SOC 2 covers the controls, and the agency invoices the buyer for AI usage as a pass-through. The buyer is one step removed from the AI vendor.
The pros: the buyer gets a single relationship with the agency that bundles AI vendor access, agency labor, and compliance coverage. The agency’s compliance posture covers everything; the buyer’s compliance posture only needs to cover the agency relationship.
The cons: the buyer is structurally locked into the agency. Switching the agency requires switching the AI vendor relationship, which requires re-establishing accounts, re-doing DPAs, and potentially re-entering AI vendor onboarding queues. Pricing transparency is reduced because the agency’s pass-through is a single line item. And the buyer is exposed to the agency’s solvency; if the agency fails, the buyer’s AI feature fails too because the underlying accounts go away.
Shape 3 is the right shape for small buyers (early-stage startups, single-feature deployments) where the simplification value exceeds the lock-in cost. It is the wrong shape for any buyer where AI is a strategic capability with a multi-year horizon.
Shape 4: split vendor-of-record
In shape 4, the vendor-of-record is split by function. The buyer is the vendor-of-record for production foundation model traffic (production OpenAI account, production Anthropic account). The agency is the vendor-of-record for development and testing (agency’s dev sandboxes, agency’s eval test data). The contract specifies the boundary.
The pros: the buyer’s compliance posture is clean for production traffic. The agency keeps its development velocity. The split is operationally honest about what happens in each phase.
The cons: the contract is more complex. Most clause about AI vendor relationships has to specify which side of the split it applies to. The data-flow auditing is more elaborate because the production data does not flow through the agency’s accounts but development tests do. Sophisticated counsel on both sides is required.
Shape 4 is the emerging best-practice shape for serious enterprise AI engagements in 2026. It captures the agency’s velocity advantage on dev and the buyer’s compliance posture on prod without forcing a single global choice that compromises one or the other.
SOC 2: which shape carries which scope
SOC 2 in an AI engagement covers controls over data handling, access management, change control, and incident response across the systems that touch customer data.
In shape 1, SOC 2 is fully the buyer’s. The agency engineers are in scope as authorized users of the buyer’s systems; the agency’s own SOC 2 (if any) is irrelevant to the engagement.
In shape 2, SOC 2 must cover both periods. The agency’s SOC 2 covers the build period; the buyer’s SOC 2 covers production. The buyer needs to obtain the agency’s SOC 2 report and confirm it covers the engagement period and scope. If the agency does not have a SOC 2 report, the buyer has no evidence for the build period; a gap that surfaces in the next buyer audit.
In shape 3, SOC 2 is the agency’s, with the buyer relying on the agency’s report. The buyer’s SOC 2 (if any) explicitly excludes AI processing because it lives in the agency’s environment. The buyer’s customers asking for the buyer’s SOC 2 receive a report that points to the agency’s SOC 2 as a sub-service organization.
In shape 4, SOC 2 is split by function. The buyer’s SOC 2 covers production AI processing; the agency’s SOC 2 covers development. The buyer’s SOC 2 references the agency’s SOC 2 only for development-phase controls. The split is auditable but requires both reports to coexist.
The detail on agency SOC 2 evaluation is in the field guide to evaluating an AI agency in under 90 minutes; agency SOC 2 readiness is one of the four diagnostic questions that surfaces structural fit.
DPA and EU AI Act allocation
DPA (data processing agreements under GDPR and analogous laws) and EU AI Act obligations track the vendor-of-record but with extra nuance.
DPAs are bilateral. The buyer needs a DPA with each entity that processes personal data on its behalf. In shape 1, the buyer has DPAs with the AI vendors and the agency is a sub-processor under the buyer’s DPA with the AI vendors. In shape 2, the agency has DPAs with the AI vendors during build; the buyer needs a DPA with the agency for the build period and DPAs with the AI vendors for production. In shape 3, the buyer has a DPA with the agency only; the agency has DPAs with the AI vendors. In shape 4, the buyer has DPAs with the AI vendors for production; the agency has DPAs with the AI vendors for development; the buyer has a DPA with the agency for the development data.
EU AI Act obligations are scope-specific. If the AI feature falls under Annex III high-risk categories (employment, education, essential services, law enforcement, migration, justice), the obligations attach to the deployer and the provider. The buyer is typically the deployer; the buyer’s vendor-of-record decision affects whether the AI vendor or the agency is the provider. In shape 2 and shape 3, the agency may be the provider during build, transitioning to the AI vendor at production; a transition the EU AI Act’s documentation requirements treat as a material change requiring conformity reassessment.
The EU AI Act point is non-obvious and load-bearing. A buyer in a high-risk category who chooses shape 2 without specifying the provider transition in the contract creates a documentation gap that an EU regulator can flag as a conformity assessment failure. The clause specifying the provider transition is one of the most important EU AI Act clauses in an AI engagement and one of the least common in 2026 standard contracts.
The contractual clauses that bind the choice
Three contractual clauses make the vendor-of-record decision survivable.
Clause 1: vendor-of-record specification. The contract names which shape applies and to which AI vendors. If shape 4 is chosen, the contract names which AI vendors are buyer-of-record (typically the production foundation model providers) and which are agency-of-record (typically the agency’s internal tooling vendors).
Clause 2: compliance flow-down. The contract specifies that the vendor-of-record (whoever it is) provides the buyer with audit-grade evidence of compliance. For SOC 2, this is a current SOC 2 Type II report covering the engagement period and scope. For DPAs, this is the DPA itself. For EU AI Act, this is the documentation required by Annex IV; system description, data quality, technical documentation, logging.
Clause 3: transition documentation. If the engagement involves a vendor-of-record transition (most shape 2 engagements and some shape 4), the contract specifies the documentation produced at transition. This includes the data-flow diagram showing what processed where, the retention and deletion confirmations for build-period data, the export of any artifacts subject to portability rights, and the conformity reassessment trigger if EU AI Act high-risk applies.
The detail on contracting structure that supports these clauses is in the AI procurement maturity model; the AI-aware MSA template at procurement maturity stage 3 is the natural home for the vendor-of-record clauses.
The diagnostic question
The single diagnostic question that exposes whether the vendor-of-record decision has been made deliberately is: “Show me the data-flow diagram for the AI feature, with each foundation model call labeled with the legal entity that is the vendor-of-record for that call.”
If the agency or the buyer can produce the diagram in 30 minutes, the decision has been made and is operational. If the diagram does not exist, the decision has been deferred, and the engagement is operating on whatever shape happened to emerge from the procurement defaults; almost usually the cheap shape (shape 2 with under-specified flow-down) and almost usually with hidden compliance gaps.
The diagnostic is the cheapest way to expose the compliance gap before an audit does. Run it at engagement kickoff and at most quarterly business review. The discipline of running it is what keeps the vendor-of-record decision visible.
Frequently asked questions
Which shape is right for a mid-market enterprise?
Shape 4 (split vendor-of-record) is the default recommendation. The buyer carries production compliance, the agency carries development velocity, and the split is honest about which entity is best equipped for which phase. Shape 1 is the right alternative if the buyer is in a regulated industry where continuous compliance posture is non-negotiable.
Which shape is right for an early-stage startup?
Shape 3 (agency-as-permanent-vendor-of-record) often wins for early-stage. The simplification value exceeds the lock-in cost when AI is one feature among many and when the engineering team is too small to manage the AI vendor accounts. The startup should plan to migrate to shape 1 or shape 4 when AI becomes strategic.
What if the agency does not have a SOC 2 report?
The engagement is not viable for shape 2 or shape 3. Without an agency SOC 2 report, the buyer has no compliance evidence for any period the agency is the vendor-of-record. The engagement either reverts to shape 1 (buyer-of-record from day one) or the agency obtains a SOC 2 report before the engagement begins.
How does this interact with the EU AI Act high-risk categories?
Substantially. EU AI Act high-risk categories require the deployer and provider to maintain conformity assessment documentation. The vendor-of-record decision determines who is the provider. A vendor-of-record transition mid-engagement is treated as a material change requiring re-assessment. Buyers in high-risk categories should default to shape 1 to avoid the transition risk.
What about US state AI laws?
Most US state AI laws (Colorado AI Act, NYC Local Law 144, California regulations) attach obligations to the deployer rather than the provider. The vendor-of-record decision matters less for these laws than for the EU AI Act, but the data flow obligations still depend on which entity is in the data path. The flow-down clause should explicitly cover applicable US state law obligations.
Is the vendor-of-record decision irreversible?
No, but reversing it is expensive. A shape 2 or shape 3 engagement that needs to migrate to shape 1 requires re-establishing AI vendor accounts under the buyer, re-doing the DPAs, and migrating prompt/eval/routing artifacts to the buyer’s environment. The migration is typically a 4 to 8 week project. Doing it once is fine; needing to do it because the original decision was wrong is the cost of the under-specified default.
How does this relate to the AI agency manifesto?
The vendor-of-record decision is one of the structural questions that distinguishes a serious AI agency from staff augmentation. A serious agency arrives with an opinion on which shape fits the buyer’s industry and with the contract template that operationalizes the chosen shape. Staff augmentation arrives with whatever the buyer asks for, which usually defaults to the cheap shape.
What’s the cost of getting this wrong?
The visible cost is the audit remediation cost; typically $50K to $200K for a mid-market enterprise, more for larger orgs. The invisible cost is the carrying cost of the documentation gap during the period before the audit forces remediation. Both costs are routinely larger than the cost of getting the contract right at signing.
Does the consolidation play affect the vendor-of-record decision?
It simplifies it. With fewer AI vendors, the vendor-of-record decision applies to fewer relationships. A consolidated stack with one platform vendor and one agency has two parties to the vendor-of-record matrix instead of six or seven. The detail on consolidation is in the AI vendor consolidation play on when fewer vendors beats best-in-class.
Should the vendor-of-record clauses be in the MSA or the SOW?
Both. The MSA contains the master vendor-of-record specification (which shape applies, what flow-down standards apply). The SOW contains the engagement-specific instantiation (which AI vendors are in scope, which are buyer-of-record, which are agency-of-record). The MSA-only approach produces unenforceable generality; the SOW-only approach produces inconsistency across engagements. Both is the durable shape.
Key takeaways
The vendor-of-record decision has four shapes: buyer from day one (shape 1), agency-then-buyer with transfer at delivery (shape 2), agency permanent (shape 3), and split by function (shape 4). Shape 2 is the most common and the most under-specified; shape 4 is the emerging best practice for serious enterprise AI engagements.
The decision determines which entity carries SOC 2, DPA, and EU AI Act compliance for each phase of the engagement. Buyer-of-record carries continuous compliance; agency-of-record offers velocity at the cost of a transition risk that the contract must specify. The default in 2026 is the cheap shape; agency velocity in dev with under-specified flow-down; which produces compliance gaps that surface in audits.
Three contract clauses make the choice survivable: vendor-of-record specification (which shape applies to which vendor), compliance flow-down (audit-grade evidence from the vendor-of-record), and transition documentation (data flow, retention, conformity reassessment trigger). The clauses live in the MSA and the SOW; both is the durable shape.
The diagnostic question; “show me the data-flow diagram with each foundation model call labeled with its vendor-of-record”; is the cheapest exposure of whether the decision has been made deliberately. If the diagram does not exist, the decision has not been made; the engagement is on the cheap shape; the audit is the next visibility moment. Running the diagnostic at kickoff and at most QBR is the operational discipline that keeps the decision visible.
Arthur Wandzel
