Crunchbase vs PitchBook: What You Keep After You Cancel

Crunchbase vs PitchBook comes down to a clause neither demo covers: what you are allowed to keep once you stop paying. Both published answers say expunge. They differ on the carve-outs, on whether an AI system may touch the data at all, and on whether the row may sit in your CRM in the first place.

That is not the comparison the category runs. The usual Crunchbase vs PitchBook head-to-head scores coverage, financials, UI and price, then sends the buyer to a trial. Our position is that those are the reversible decisions. The licence is the irreversible one, because it governs the copies you make, the derived fields you build on top, the model context you ground, and the day the contract ends and someone has to certify that all of it is gone. We read what each vendor publishes rather than what each vendor says in a call, and the two sets of documents do not resolve the same way.

The short answer: Both vendors publish an expunge-on-termination duty, but PitchBook's Data Feed License Agreement grants a written carve-out for archival, regulatory and prior Work Product use while Crunchbase's Terms of Service grant none on their face — and PitchBook's data-feed licence flatly prohibits both AI use and CRM ingestion by default, which is the opposite of how the same dataset is marketed.

Last updated: July 31, 2026.

What each vendor actually publishes

Crunchbase publishes a full Terms of Service, a Data Use Addendum and a Cancellation Policy openly on its website. PitchBook does not publish its platform subscription terms in a form our fetch ladder could retrieve, but it does publish a complete Data Feed License Agreement as the end-user licence attached to its AWS Marketplace listing for that product. Those are the two licence documents this comparison is built on, read alongside Crunchbase's Data Use Addendum and Cancellation Policy. They cover different products, and that is itself part of the answer.

A note on scope, because it changes every conclusion below. Crunchbase's Terms of Service, last updated November 26, 2024 and fetched July 31, 2026, govern "our websites, products, services and applications", and they anticipate programme-specific terms layered on top: "These Terms apply to all such programs unless specifically stated otherwise in the applicable program terms." The word "Enterprise" does not appear in them at all. The explicit Enterprise carve-out sits one document over, in the Cancellation Policy, effective January 13, 2026, which states that it "does not apply to Crunchbase Enterprise, or to any purchase of any product(s) made via an Order Form." So the refund and renewal mechanics later in this article are the self-serve ones, and what an Enterprise Order Form says on any of this is not public. PitchBook's Data Feed License Agreement — published as the EULA for the PitchBook Benchmarking Data product on AWS Marketplace — governs "the data delivered by PitchBook to Licensee via the data feed", not a platform seat.

So a Crunchbase vs PitchBook read on data licensing terms is not "Crunchbase's rules versus PitchBook's rules" in the abstract. It is one company's published general terms and data addendum against another company's published data-feed licence, with negotiated Order Forms able to move either one. Read it that way and the differences are still stark.

Two entries in that table deserve to be read twice. PitchBook's data-feed licence prohibits the two things a modern revenue team assumes it bought the data to do, namely put it in the CRM and point an AI system at it, unless an Order Form says otherwise. And Crunchbase's expunge sentences carry no stated exception at all in the place where PitchBook's has two.

The clause the demo skips: expunge

Both vendors reserve the right to make you delete the data after the relationship ends, and both use the same unusual verb. Crunchbase's Terms say that "upon termination of your account Crunchbase may require you to expunge some or all of the Content in your possession, and you will do so promptly." PitchBook's Data Feed License Agreement says the licensee "must take commercially reasonable efforts to promptly expunge the Content from its possession."

Crunchbase's Terms in fact carry the expunge right twice, and the second instance is the one to notice. Alongside the termination sentence, an earlier passage grants a standing version with no termination trigger at all: "From time to time, Crunchbase may require you to expunge some or all of the Content in your possession, and you will do so promptly upon request." That is a live obligation for as long as you are a customer, not an exit condition.

The verb matters because it is stronger than "stop using". Crunchbase's Terms also warn, separately, that "[a]ccount termination may result in destruction of any Content associated with your account, so keep that in mind before you decide to terminate your account" — that sentence is about the copy Crunchbase holds for you. The expunge sentences are about the copy you hold. They are different obligations pointed in opposite directions, and the first is the one written in the more visible place.

PitchBook's version is drafted with more give and more precision. Section 6.5 sets out three consequences of termination: the licence ends, the licensee "must immediately stop accessing, using, and storing such Content and Services", and the licensee must make commercially reasonable efforts to expunge. Then it carves out two exceptions in the same clause: "(1) Licensee may continue using Work Product; and (2) Licensee may retain Content as needed for archival or regulatory purposes." A regulated buyer with a records-retention schedule can live with that. A buyer under a clause with no stated exception has to raise it in negotiation, and cannot assume the answer.

Two more asymmetries sit alongside it. PitchBook's Section 6.6 lists exactly which sections survive termination: 3, 4, 5, 6, 8, 10, 11, 13, 14, 18 through 22. Sections 3 and 4 are the allowed-usage and prohibited-usage sections. In plain reading of the document, the restrictions on what you may do with the data outlive the licence that let you have it. Crunchbase's approach is the more common formulation: "[p]rovisions that, by their nature, should survive termination of these Terms shall survive termination", with examples given for payment, liability, IP ownership and disputes.

The practical difference is not which vendor is stricter. It is which vendor told you in writing, before you signed, what the end state looks like. On this one dimension PitchBook's published data-feed document is the more useful artefact, and it is the one you can read without a sales process.

Can an AI agent read it? Two vendors, two published answers

Neither published licence permits using the data to build or improve a model, and PitchBook's data-feed licence goes further than that. This is the fastest-moving part of the comparison, and it is where the marketing and the contract have drifted furthest apart at both companies.

Crunchbase's restriction is narrow and precisely aimed. The Terms of Service list prohibited conduct, and item (n) covers any use that "[u]ses or allows the Content to be used to train models (including generative artificial intelligence technologies)". Item (o), immediately after it, prohibits use that "[u]ses or allows the Content to be used in a manner that makes it impossible for the Content to be expunged." A violation "is grounds for account suspension or termination of your right to use or access the Service."

Read (n) and (o) together and they describe a coherent design. Training is out. Anything that makes deletion impossible is out. Retrieval, meaning asking a question and getting a sourced answer back, is not named in either. That is consistent with Crunchbase shipping an MCP server: the Crunchbase MCP page describes answers "grounded in real Crunchbase data — not a model's training data or unverified web results — subject to your existing package permissions and compliance controls", and access "secured through OAuth login" where "only admin-approved seat-holders can connect." Grounding is the product. Training is the prohibition. The company is drawing a line, and it has drawn it in the same document twice.

Where it gets hard is the middle. An embedding index built over exported rows is not training, but it is a durable derived copy. A fine-tune is training. A long-lived agent memory that caches company facts between sessions is neither, exactly. Item (o) is the clause that bites there, because the question it asks is not "did you train" but "can you still delete". A vector index you cannot selectively purge by source row is, on a plain reading, a design that makes expungement hard. We are not going to tell you whether any specific architecture crosses that line. That is a contract question for your counsel, on your facts. What we will say is that (o) is the clause to hand them, and it is the one that goes unquoted while (n) gets all the attention.

PitchBook's data-feed licence does not attempt the distinction at all. Section 4.3 says the licensee "agrees not to use the Content in conjunction with any machine learning, neural network, deep learning, predictive analytics or other artificial intelligence computer." There is no training-versus-inference carve-out, no retrieval exception, and no reference to grounding. "In conjunction with" is broad language and it sits inside a section that survives termination.

That is worth holding next to what PitchBook has been shipping. Its own announcement of June 25, 2026, distributed via Business Wire, describes "a new federated Copilot connector with Microsoft, bringing trusted private capital market data into Microsoft 365 Copilot — including Copilot in Excel, Copilot Chat, and Researcher", and says it "enables licensed users to interact with PitchBook intelligence" there. That is an AI access path to PitchBook data, sold to licensed users, and it is a connector product governed by an agreement we could not retrieve. The data-feed licence is a different contract for a different product. But a buyer who has read only the AI announcements and then signs a data feed will have signed something that, on its face, prohibits the thing those announcements are about.

The lesson generalises past these two vendors: the AI clause you are bound by is the one attached to the specific SKU you bought, not the one implied by the vendor's roadmap. Our earlier work on governing AI connectors makes the same point from the other direction. The connector is where a licence becomes an actual data flow.

Recorded contract seminars are a decent way to hear how practitioners frame this before you take it to your own lawyers. This one covers AI, data protection and technology risk in commercial contracts:

Does the row belong in your CRM at all?

On CRM data enrichment, the Crunchbase vs PitchBook answer diverges hardest. PitchBook's published Data Feed License Agreement says no, by default. Section 4.6, headed "No Use in Third-Party Databases", reads: "Except as explicitly permitted through an Order Form, Licensee may not input any Content into a customer relationship management application or any other third-party database."

That is the sentence that should stop a revenue-operations project. Enriching accounts in a CRM from a purchased feed is the use PitchBook's own AWS listing describes, in the product description sitting above this EULA. Under this licence it is a permission you have to buy on the Order Form, not a capability that comes with the data.

The contradiction is not hypothetical, and it is not something we had to infer. On the same AWS Marketplace page that attaches this EULA, PitchBook's own product description says: "PitchBook fund data can easily be integrated into your CRM or internal database giving you the added assurance of an independent data source." The marketing copy and the licence sit two scroll-lengths apart on one page and point in opposite directions. Neither is wrong on its own terms. "Easily" is a statement about integration effort, not about permission, and the licence does allow CRM ingestion when the Order Form says so. But a buyer reading the description and clicking through is reading a capability claim as a rights claim, and the page does nothing to stop them.

Crunchbase does not carry an equivalent CRM prohibition in its Terms of Service, and its own marketing runs the other way. Its Crunchbase Pro page describes exporting "up to 2K rows monthly to enrich your own analysis, brief your team, or feed your models", and a customer quote on the same page says: "Having the ability to push data directly into our CRM makes it easy to pinpoint the right prospects faster." The Terms do reserve everything not expressly permitted. Beyond insubstantial excerpts for commentary, teaching, scholarship and similar purposes, "[a]ny other uses of Content require Crunchbase's prior written consent", and the Terms point API and product-integration use cases to a separate programme with its own terms and fees. So "not prohibited" is doing real work there, and the export path is plainly contemplated.

The asymmetry is clean enough to put in a table.

That last row is not symmetric either. PitchBook's Section 7 puts the obligation on the customer: "Licensee will permit periodic audits upon reasonable notice and at mutually agreed times", so that PitchBook, at its own expense, can review records and procedures with appropriate personnel to check compliance. Section 10.1 puts the indemnity on the licensee for third-party claims arising from unauthorised use or disclosure. Section 11.3 caps most liability at the fees paid in the preceding twelve months, but that cap expressly excludes the licensee's indemnification obligations. A buyer who assumes the twelve-month cap is the worst case has not read Section 11.3 to the end.

The derived record: what survives when the source has to go

The hardest question in post-termination data rights, and the one a Crunchbase vs PitchBook feature table cannot answer, is not the row. It is everything the row produced. A purchased company record does not stay a single record for long. It becomes a firmographic field, a territory assignment, a lead score, a segment, a slide, a dashboard, a cached fact in an agent's context window, a vector in an index. Some of those are still recognisably the vendor's data. Some are your work. The licence has to draw that line, and most of the time it does not.

PitchBook's data-feed licence at least tries. Section 3.2 defines "Work Product" as presentations and reports incorporating Content, permitted only where the incorporated quantity "has no independent commercial value and is not separately marketable by PitchBook or Morningstar", the output is not issued on behalf of a third party, it is not published to more than 500 individuals without prior written consent, and it carries the attribution "Source: PitchBook Data, Inc." And then: "PitchBook retains sole ownership over any Content incorporated into the Work Product." So the deck survives termination under Section 6.5, but the data inside the deck is still PitchBook's. That is a defensible and unusually explicit position.

Crunchbase's Terms address a different derivative and address it forcefully. "Resultant Data" is defined as "the data related to your use of the Service", and the Terms state that "Crunchbase owns all Resultant Data, which shall be the intellectual property of Crunchbase", with the customer assigning "unconditionally and irrevocably" any rights they might acquire in it. Crunchbase may collect, store, analyse and use it, and share it on a pseudonymised basis, including for benchmarking studies and service development. The Terms' own change summary describes the November 2024 update as including "an additional license grant for Resultant Data". Note the direction of travel: this is the vendor's right over the exhaust from your usage, not your right over the data you bought.

Neither published document tells you what happens to a lead score derived from a purchased field. That is not a criticism of either drafting team. It is the gap this article exists to name, and it is the one that decides what a derived field is worth to you. It also means the honest procurement move is to write the answer down rather than look it up.

Three derivative classes, and what each licence lets you conclude on its face:

The middle row is empty in both columns. That is the finding. If a derived field matters to your business, and a lead score built on funding-stage data is exactly that kind of field, the contract is the only place that gap gets closed, and it closes before signature or not at all.

This is also where the second-copy problem we wrote about in AI workplace search meets a licence. Search and retrieval tooling multiplies copies as a design goal. An expunge duty assumes copies are countable. Those two assumptions cannot both hold unless someone deliberately makes them hold.

The duty you carry while you are still paying

Crunchbase's Data Use Addendum imposes a continuing obligation that has nothing to do with termination, and it is the most operationally demanding sentence in either document. Under the Data Use Addendum, effective November 26, 2024, "Included Data" means "any Personal Data included in the Content and provided to or otherwise accessed by Customer under the Terms". In practice, the people records inside company profiles.

Three duties attach to it while the subscription is live.

First, deletion propagation. The customer "agrees to promptly delete and, if applicable, cease all sales of, any Included Data for which Crunchbase notifies Customer (including by updating the Content) that Crunchbase has received a deletion, opt-out, or similar request, and will indemnify Crunchbase for any claims relating to Customer's breach of the foregoing." Read the parenthetical carefully: notification can happen by updating the Content. A record quietly disappearing from a refreshed feed can be the notice. That converts a legal duty into an engineering requirement. You need a job that detects removals and propagates them into every downstream system.

Second, currency. The Addendum states that the customer "shall regularly check such Content and ensure that it is using the most up-to-date version of the Included Data." A one-time enrichment that is never re-synced does not satisfy a sentence phrased that way.

Third, purpose-scoped deletion. "Notwithstanding anything to the contrary in the Terms, Customer shall immediately delete or destroy all Included Data in its possession upon the conclusion of Customer's purpose for Processing such Included Data." That clock is not tied to the subscription at all. It runs on your stated purpose, which means a campaign that ends, a territory that is retired, or a project that is cancelled can each start it independently.

The Addendum also frames the relationship in a way worth noticing: the parties "are each a separate and independent Controller of any Included Data" and "do not and will not Process Included Data as joint Controllers", each individually responsible for its own compliance. Whatever that means for your obligations is a question for your privacy counsel, not for a blog post. What it means operationally is unambiguous: nobody is going to run the deletion job for you.

PitchBook's data-feed licence carries no equivalent standing duty in the text we retrieved. It does, however, carry Section 4.9 — Content may not be used "as a factor in establishing an individual's eligibility for employment, or for credit or insurance to be used primarily for personal, family, or household purposes". That is the kind of use restriction that fails silently in an automated pipeline unless somebody encodes it as a rule.

The billing side of enrichment we have already covered and will not re-argue here: our analysis of cost per found record works through what you actually pay for a usable row. This piece is about what you are allowed to do with the row once you have it.

What is not public, and why that is the finding

Our fetch ladder could not retrieve pitchbook.com's Terms of Use, its LCD Subscription Agreement, its Equity Research License Agreement, or its privacy policy. All four returned a Cloudflare challenge to both a plain fetch and a browser-user-agent request, and the browser-pane tier was unavailable during this run. So we are not telling you what PitchBook's platform subscription says about termination, AI or CRM ingestion, because we did not read it.

That is a limitation of our method, not proof of anything about PitchBook. Those pages plainly exist and open in a normal browser. But the asymmetry it creates is real for a buyer using the same tools we did, and it is worth stating plainly rather than papering over:

• Crunchbase: Terms of Service, Data Use Addendum, Cancellation Policy, Attribution Instructions and Engagement Suite Terms all retrievable, all dated, all readable before you talk to anyone.
• PitchBook: the data-feed licence is fully public via AWS Marketplace and is a genuinely detailed document. The platform terms were not reachable to us.

The same gap exists on price. Crunchbase's pricing page, fetched July 31, 2026, is a product page carrying no plan prices; the data-licensing page says "Contact us to explore API pricing"; the MCP FAQ answers "How much does the Crunchbase MCP cost?" with "Reach out to your Crunchbase representative or [email protected]". PitchBook publishes no list price we could find; its AWS Benchmarking Data listing is "available free of charge" with "[r]efunds are not offered for this product", which tells you about that one marketplace listing and nothing about a negotiated subscription. Third-party aggregators quote figures for both. We are not repeating them, because a number we cannot verify at the vendor is a number that will be wrong in a procurement pack.

Two more sources a reader would reasonably expect are missing here. G2, Capterra and TrustRadius all returned 403 to our fetch ladder, and Reddit was unreachable, so this article carries no user-review quotes for either product. And to be explicit about the first-hand-experience question: we have not subscribed to Crunchbase or PitchBook. Everything above is read from published documents, each fetched and dated, and nothing in it is a usage report.

Unpublished terms are not a scandal. Enterprise software has long negotiated the interesting clauses on the Order Form. But it does change what a Crunchbase vs PitchBook article can honestly do, and it changes what you should do: the questions in the next-but-one section are the ones you have to ask, because the documents will not answer them for you.

Renewal mechanics you can verify without a sales call

Both vendors publish enough about renewal to build a calendar entry, and the details are the kind that cost money quietly.

PitchBook's data-feed licence sets out the sharper mechanics. Order Forms "automatically renew for additional one-year terms unless written notice of a party's decision to opt out of such auto renewal is provided 30 days in advance", and Section 6.3 separately requires 30 days' written notice of non-renewal. Terminating the Agreement itself, effective at the end of the current term, requires 60 days' written notice under Section 6.4 — so the document carries three notice periods, the longest of them governs ending the relationship, and a diary entry set to the 30-day one will miss it. Then Section 6.4 adds: "Neither party may terminate the services to be provided under an Order Form for convenience." Breach termination requires a written notice specifying the breach and a five-business-day cure window.

Pricing on renewal is stated rather than negotiated: "any annual license fee will be subject to an increase of the higher of (A) 5% or (B) the annual increase in the U.S. Consumer Price Index (All Urban Consumers)". PitchBook may change renewal-term fees on notice no later than 45 days before the end of the current term. A five-percent floor compounding annually is a real number in a three-year plan and it is published, which makes it one of the few forecastable inputs in this category.

Crunchbase's self-serve mechanics are in the Cancellation Policy. Subscriptions "are recurring and will automatically renew"; cancelling in-product "cancel[s] only future renewal charges"; cancellations take effect at the end of the current period and there are no prorated refunds. Refunds may be granted within 7 days of payment, or 14 days for New York residents under state law. And then the clause that most directly connects billing to the licensing argument in this article: "if you exported any data from Crunchbase Pro or Crunchbase Business, including during a trial, you are not eligible for a refund."

That sentence prices the export. The moment your evaluation does the thing you are evaluating, pulling rows out to see whether they match your accounts, the trial stops being reversible. It is an entirely reasonable anti-abuse rule and it is published in plain sight. It also means an honest proof-of-concept design has to decide, up front, whether it is testing coverage inside the product or testing enrichment in your own systems, because those two tests have different costs.

The Expunge Test: five questions before you sign

Here is the diagnostic. It takes one sitting, it needs no lawyer to run, only to review, and it works against any data vendor, not just these two vendors. We call it the Expunge Test, because every question is a version of "on the day this ends, can you actually do what you promised".

1. Which rows? Can you produce, today, a list of every record in every system that originated from this vendor? Not "the enrichment ran on Tuesday". An actual queryable provenance marker on the row. If the answer is no, you cannot satisfy an expunge clause and you cannot satisfy a deletion-propagation duty either. Everything else in this test depends on this one.

2. Which copies? Name every place a copy lands: the CRM, the warehouse, the reverse-ETL destination, the BI extract, the spreadsheet somebody keeps, the nightly backup, the vector index, the agent's cache. Write the list down. The gap between the list you write from memory and the list your architecture actually produces is the size of your problem.

3. Which derivatives? For each derived object, whether a score, a segment, a territory or a model artefact, decide now whether you will treat it as vendor Content or as your work, and get that treatment written into the agreement. Neither document we read answers this. An unanswered question at signature becomes the other side's answer at termination.

4. Which agents? List the non-human identities that can read this data: the MCP connector, the enrichment job, the copilot with a warehouse grant, the workflow that drafts outbound. For each one, check the licence clause that governs it: Crunchbase's training and expungability restrictions, PitchBook's machine-learning restriction, or whatever your vendor's equivalent is. An agent with a broad read grant is a licence exposure with no owner unless you give it one, which is the argument we made in non-human identity.

5. Who signs? Name the person who will certify, in writing, that expungement happened, and name who indemnifies if it did not. If nobody's name fits in that sentence, the obligation is unowned, and unowned obligations are the ones that surface during a diligence process two years later.

Run all five and you get a short document that is worth more in a negotiation than any feature comparison, because it is one of the few artefacts in a buying process that describes the end of the relationship. This is also the point where the NIST AI Risk Management Framework is genuinely useful rather than decorative: NIST AI 100-1 sets out GOVERN 6, "Policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues", with GOVERN 6.1 covering third-party IP risk and MAP 4.1 requiring that approaches for mapping the legal risks of third-party data "are in place, followed, and documented". The Expunge Test is one concrete way to satisfy a documented mapping obligation for a purchased dataset.

Choose Crunchbase if, choose PitchBook if, stay put if

The licensing lens does not overturn the conventional advice about coverage and depth. It adds a second axis, and on that axis the answer is different from the feature answer.

Choose Crunchbase if you are a go-to-market team and you need the enrichment path to be uncontroversial. The Terms carry no CRM prohibition by name, the export allowance on Pro is stated on the product page, the documents are all public and dated, and the MCP product is designed around retrieval with OAuth-gated, seat-scoped access rather than around bulk extraction. The clause to get clarity on is the reservation that uses beyond the stated allowances need prior written consent. In exchange you accept a continuing deletion-propagation duty with an indemnity attached, a vendor-owned Resultant Data position, and expunge clauses with no written carve-out. So you plan for provenance tagging from day one and you negotiate the archival exception rather than assuming it.

Choose PitchBook if you need private-capital depth, you are buying under an Order Form anyway, and you are prepared to negotiate the two default prohibitions explicitly. The data-feed licence is the better-drafted end-state document: it tells you what survives, it grants archival and regulatory retention in writing, it protects your existing Work Product, and it enumerates surviving sections instead of leaving it to "by their nature". The cost of that clarity is that the defaults are restrictive: no CRM ingestion, no AI, an audit right over you, and an indemnity carved out of the liability cap. So the Order Form is not paperwork, it is the product.

Stay with your incumbent if you cannot answer question 1 of the Expunge Test. If you cannot list which rows in your CRM came from which vendor, adding a second vendor makes the problem strictly harder and buys you nothing you can defend. Fix provenance first. It is unglamorous, it takes a sprint, and it is the only work in this article that pays off regardless of which contract you eventually sign.

Buy both if, and only if, the two datasets serve genuinely different jobs with different owners, and you have already decided how you will tell their records apart in a shared system. The failure mode of dual sourcing is not cost. It is that a field enriched from two vendors under two different licences is a field with two sets of restrictions attached, and which of them binds it is a question your counsel has to answer on your facts. Better answered before either contract is signed than after.

When neither vendor is your problem

There is an honest case where this entire comparison is the wrong project.

If your team's actual use of company data is a handful of analysts doing research inside a product UI, and nothing is being exported, scored, synced or fed to an agent, then the licensing questions above are close to inert. The data stays in the vendor's system, the expunge duty has almost nothing to reach, and you should buy on coverage, workflow and price like any other research tool. Adding a governance programme to that is overhead pretending to be diligence.

The comparison starts mattering the moment data crosses a boundary. The first export, the first reverse-ETL sync, the first connector granted to an AI client. Each of those turns a reading licence into a distribution and retention question. If you are early, the cheapest possible move is to decide deliberately when that boundary gets crossed and to instrument it, rather than discovering it in an audit.

And if the honest answer is that the boundary was crossed eighteen months ago by somebody who has since left, then the project is not vendor selection at all. It is finding the rows. Our leaver test covers the shape of that problem where the departed person owned an automation; the version here is the same failure with a licence attached.

Where this analysis stops

Several things in this article are genuinely uncertain, and pretending otherwise would make it less useful.

We did not read PitchBook's platform terms. The data-feed licence is one product's contract. The platform subscription and the Copilot connector are governed by agreements we could not retrieve. Do not assume Section 4.3 or Section 4.6 applies to a platform seat. Ask.

We did not negotiate either contract. Everything above is the published default. Order Forms routinely modify defaults, and both documents say so. PitchBook's expressly provides that Order Form terms control where they conflict with the licence. A restrictive default is a starting position, not a verdict.

We are not interpreting the clauses for you. Whether a particular retrieval architecture "uses" Content to train a model, whether a lead score is a derivative work, whether a vector index makes Content "impossible to expunge", and what a separate-and-independent-controller framing means for your privacy programme. Those are contract and privacy questions on your specific facts, and they belong with your counsel. We have quoted the sentences and named the gaps. Resolving them is not a blog's job.

Terms change under you. Crunchbase's own change summary records that the November 26, 2024 update added the prohibition on using Content to train models. That prohibition did not exist in the prior version. Whatever you verify today has a version number, and a contract clause that lets a vendor update terms on notice is a clause that lets the AI rules change mid-subscription. Diary a re-read.

Nothing here is an accusation. Every clause quoted above is a vendor protecting a dataset it paid to build, and both companies published the words we are quoting. The reason to read them is not that either vendor behaved badly. It is that these are two of the better-documented vendors in the category — one publishing its full terms openly, one publishing a detailed licence through a marketplace — and the derived-record question is still unanswered in both. That is worth checking in the rest of your stack rather than assuming.

Making the answer provable

The reason questions 1, 4 and 5 of the Expunge Test are hard is not legal. It is that the answers are spread across tools that were never asked to agree. Provenance sits in whichever tool did the enrichment, agent access sits in whichever platform hosts the agent, and the person who has to certify deletion is left assembling the picture from whatever those systems happen to have kept.

That is the layer LeapForce builds. Observability and audit records what a request touched and what was refused, so "which agents can read the vendor's rows" has an answer you can export rather than assemble. Access and identity treats non-human identities as first-class, with an owner, a scope and an expiry on every agent. That is exactly the shape question 4 asks for. Connectors is a registry IT vets once, with action-level scoping and human-in-the-loop gates, so a data connector's permissions are a reviewed decision rather than a default. Our gateway rollout follows the same order every time: Observe first. Enforce second. Optimize third. You cannot enforce a licence restriction you cannot yet see being violated.

The honest limit: LeapForce does not read your contracts and will not tell you what a clause means. It makes the operational half provable, recording who accessed what, under which identity, and when it stopped, so that when counsel asks question 5, somebody can answer it with evidence instead of an assurance.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.