When you buy a SaaS product that uses Claude internally, you are not buying Claude — you are buying the vendor's application, which sends data to a model under the vendor's contract, on a platform the vendor chose, with prompts and logs the vendor controls. Your existing SaaS due-diligence still applies in full; this article covers only the questions the AI layer adds on top.
The single most important fact: the vendor's arrangement is not yours
Anthropic's documentation is explicit that its zero-data-retention (ZDR) arrangements do not cover third-party integrations, and neither does its HIPAA-ready configuration. So even if Anthropic's defaults are reassuring — inputs and outputs deleted within 30 days by default, no training on commercial inputs/outputs without express permission — those describe the relationship between the vendor and its model provider. What governs your data is your contract with the vendor, plus whatever the vendor actually built. A vendor cannot pass through protections it has not itself arranged, and it can add exposures the platform never had: its own prompt logs, its own analytics, its own subprocessors.
Data handling questions
- What of our data enters prompts? Which fields, which documents, assembled by what logic. "Everything in the account" is a very different answer from "the ticket title and body."
- Which platform and path? First-party Claude API, Bedrock, Vertex AI, Foundry — this determines who the data processor is at the model layer and where retained data resides (on Bedrock and Google Cloud, per Anthropic's docs, the cloud provider processes the data within its environment).
- What does the vendor log? Prompt/response payloads, for how long, who has access, and can your tenant's payloads be excluded or redacted. The vendor's log retention is usually the longest-lived copy of your data in the chain.
- Is our data used to improve their product? Model training is only one flavor — ask about prompt tuning, evaluation sets, and analytics built on your content.
- Stateful features. If the vendor uses features that persist data — files, agent sessions, batch jobs — ask how those stores are scoped per customer and cleaned up on termination.
Model versioning questions
Claude model IDs are pinned snapshots — Anthropic documents that every model ID, including the newer dateless-format IDs, refers to a fixed snapshot rather than an evergreen pointer that silently changes. That gives a well-run vendor the ability to control exactly when its product's behavior changes. Ask:
- Do you pin model versions, and how do you test before switching? A model upgrade is a behavior change to the product you bought; the vendor should be able to describe its evaluation process, not just its excitement.
- Will you notify us before a model change that affects our outputs? Material-change notification belongs in the contract, alongside your right to know which model generation is in use.
- What is your plan for deprecations? Models do retire on documented schedules — a vendor with no migration process will one day pass an outage or a hurried, untested model swap on to you.
Incident and accountability questions
Ask how the vendor detects and communicates AI-specific incidents: harmful or off-policy outputs shown to your users, data leakage via prompts or logs, and jailbreak attempts against their product. Notification commitments and timelines are contractual matters to negotiate — get them in writing rather than inferring them from a trust page. Also clarify the reverse direction: your obligations as a customer. Vendors typically bind you to acceptable-use terms that flow down from their model provider's usage policies, and your employees' use of the product should stay inside your own internal AI use policy. Finally, decide accountability internally: outputs the vendor's AI produces for your customers are still, from your customers' point of view, yours.
Track these products in your inventory
SaaS-with-Claude-inside belongs in your AI model inventory just like your own integrations: owner, data classes flowing in, platform path as disclosed, review date. These entries are also prime candidates for periodic access reviews — the connection a vendor holds into your systems tends to outlive the enthusiasm that created it.
Where to go next
For evaluating the platforms themselves, see vendor risk assessment for AI providers; for what your own policy should require of employees using such tools, see department-level usage policies.