Scope note. This article is general educational and measurement guidance, not legal, tax, financial, security, or platform-specific advice. Current law, first-party platform rules, the facts of the real case, and qualified professional advice control any consequential decision. Procurement has come back with three questions about the AI-visibility tool you want to buy: where the data goes, how long it is kept, and whether anything you send is used to train a model. You do not have the answers, and the vendor's site says "enterprise-grade security" and nothing more specific. This post is the set of questions that closes that gap, plus a plain statement of our own position.
Disclosure first, because it applies to everything below: RankRift publishes vendor-neutral guidance about visibility trackers, including the questions that make our own category uncomfortable. Our conflicts are documented on our disclosure page. Nothing here characterises any named vendor's practices, because we will not describe a company's data handling without quoting its published policy.
Everything in this post is general information about a procurement process. It is not legal advice, and it is not a data-protection assessment. Anything jurisdiction-specific belongs with qualified counsel or your privacy officer.
Why a prompt set is sensitive
Most teams classify their AI-visibility prompt set as marketing data, at roughly the sensitivity of a keyword list. That undersells it. A prompt set is a written description of how you believe your buyers think, and it is usually more specific than anything in your public positioning.
Read one back and see what it actually contains:
- The categories you believe you compete in, which is a positioning decision you may not have announced.
- The competitors you consider real, which is often a shorter and more revealing list than the one in the deck.
- The buying triggers and objections you take seriously, phrased as a buyer would phrase them.
- The segments and geographies you care about enough to measure, including ones you have not entered yet.
- Product or feature names that are not public, if anyone was careless while drafting.
The results are similarly loaded. A tracked history of where you are weak, which competitor owns which question, and what your own remediation attempts did or did not change is a strategy document with a timestamp on every row.
For agencies the exposure compounds. A multi-client prompt library sitting in one vendor account describes the competitive concerns of every client at once, and in some cases describes competing clients side by side.
Where the data goes
A single measurement run usually touches at least three parties, and the contract you sign covers only the first one directly.
| Party | What it typically receives | Where the terms live |
|---|---|---|
| The measurement vendor | Your prompts, brand and competitor names, run schedule, results history, your account and billing data | The vendor's terms, privacy policy, and DPA |
| The model provider | The prompt text sent on each run, via the vendor's API integration | The provider's API terms and data-usage documentation |
| Subprocessors | Hosting, logging, error tracking, analytics, support tooling, and any AI features layered on top | The vendor's published subprocessor list, if one exists |
Two things are worth pulling out. First, API terms and consumer-product terms are usually different documents with different data-usage positions, so "the model provider trains on everything" and "the model provider trains on nothing" are both unsafe assumptions. Read the current API documentation and date what you read. Second, if a vendor measures by driving assistant web interfaces rather than official APIs, the data path is not the one described in any API document, and the account being driven has its own terms attached. That is one of several reasons we treat interface scraping as out of bounds, covered in API-based measurement vs UI scraping.
Retention, training use, and confidentiality questions to ask
Ask these in writing, and treat "we take security seriously" as a non-answer. Every question below should produce either a document link or a contractual commitment.
Retention
- How long are prompt sets retained after a subscription ends, and is deletion on request available?
- How long are run results and citation records retained, and can retention be configured?
- Are backups and logs covered by the same retention period, or do they persist longer?
- What is the documented deletion timeline once a deletion request is made, and is confirmation provided?
Training and secondary use
- Is customer prompt or result data used to train, fine-tune, or evaluate any model operated by the vendor?
- Is customer data used to build aggregate benchmarks, indexes, or public research? If so, is it opt-in, and is it identifiable?
- Which model providers are called on your behalf, and under which data-usage configuration?
- Does a support or debugging workflow ever move customer data outside the production environment?
Confidentiality and access
- Which employees can view customer prompt sets, and is that access logged?
- Is there a published subprocessor list, and is notice given before it changes?
- Where is data hosted and processed, and is a processing location commitment available?
- Is there a documented breach notification commitment with a stated timeframe?
- Can data be exported in full, in a usable format, on demand and on exit?
Contract
- Is a data processing agreement available without escalating to an enterprise tier?
- Does the standard order form assert any licence over your data beyond providing the service?
- Are there published security certifications or reports, and what is their scope and date?Our companion post on questions to ask any vendor covers the measurement-quality side of the same conversation. Run both lists in one procurement pass rather than two.
Agency-specific concerns with client data
Agencies carry obligations their tool vendors are not party to. The client MSA and its confidentiality clause usually predate the AI-visibility tool by years and say nothing about it.
Points that come up repeatedly:
- Subprocessor consent. Many client agreements require notice or approval before a new party processes client information. Adding a measurement platform can trigger that clause. Check before onboarding, not after.
- Segregation. If client prompt sets sit in one shared workspace, an access mistake is a cross-client disclosure. Ask whether the platform supports separate workspaces with distinct access control.
- Competing clients. Two clients in adjacent categories may each be named as a competitor in the other's prompt set. Decide the policy deliberately and document it.
- Exit. When an engagement ends the client usually owns the work product. Confirm you can export their prompt sets and history, and that you can delete their data from your account.
- Aggregate research. If a vendor publishes category benchmarks, establish whether client data can be excluded, and whether the client would need to consent.
None of that is a legal determination. It is a prompt to read your own client agreements alongside the vendor's terms, with counsel where the answer matters.
Data-handling specification for an adopting operator
RankRift does not operate a tracker, accept customer prompt sets, or store customer results. The requirements below are a procurement and implementation checklist, not a claim about a RankRift data service. A deployed operator's dated privacy notice and contracts are authoritative.
- Use official model APIs where an automated measurement is authorized. No scraping of assistant web interfaces, no automated consumer accounts, no rate-limit evasion. The data path is the documented one.
- Treat customer prompt sets and results as confidential competitive material, not as a content input.
- Do not use customer prompt sets or results in public research without specific written permission.
- Do not sell customer data or use it for an unrelated training purpose.
- Retention is defined and documented rather than indefinite by default, with export and deletion available. The specific periods are stated on the privacy page rather than here, so that one page stays authoritative and dated.
- Disclose subprocessors and model providers in a dated list.
If a prompt set is too sensitive to place with a third party, run a small set through authorised documented interfaces, keep the logs internal, and accept the cadence limits. Teams under strict data-residency constraints may be better served by an in-house implementation than by a hosted platform.
A short procurement checklist
Print this, run it once per vendor, and keep the answers with the contract.
- Prompt set classified internally, with an owner and a sensitivity level
- Vendor privacy policy, terms, and DPA read and dated
- Subprocessor list obtained, with a change-notice commitment
- Model providers named, with their current API data-usage position recorded and dated
- Retention periods documented for prompts, results, logs, and backups
- Training and secondary-use position confirmed in writing
- Export and deletion paths tested before rollout, not at renewal
- Access controls and workspace segregation checked against your client structure
- Client agreements reviewed for subprocessor and confidentiality clauses
- Breach notification commitment and timeframe recorded
- Security certification claims verified against the actual report and its date
- Counsel or privacy officer signed off on anything jurisdiction-specific
If a vendor cannot answer half of that list with documents, the gap is the finding.
In Plain English
What this means: the prompt set you send to a measurement tool is a strategy document, it passes through more hands than the vendor's, and the only reliable way to know what happens to it is to ask specific questions and keep the written answers.
Who this helps: anyone whose procurement or privacy team has asked where the data goes, and agencies carrying client confidentiality obligations that predate this whole tool category.
When to use it: during evaluation, before the trial account is loaded with real client prompts, and again at renewal when subprocessor lists have moved on. The wider brand-exposure context sits on our risk and brand safety hub.
What to do next: classify your prompt set, run the checklist against your shortlist, and escalate anything jurisdiction-specific to counsel rather than resolving it from a blog post.
See our privacy position.
Primary-source verification
Checked July 28, 2026. The operational and factual guidance above was reviewed against the primary references below. Provider features, prices, policies, interfaces, jurisdictions, and account-specific results can change; recheck the controlling first-party document and your own account or measured data before acting.
- Google Search: AI features and your website - How Google describes eligibility, preview controls, and appearance in its AI search features.
- Google: common crawlers and special-case user agents - Current Googlebot and Google-Extended identities and controls.
- OpenAI: overview of OpenAI crawlers - Current GPTBot, OAI-SearchBot, and ChatGPT-User descriptions and publisher controls.
- Anthropic: web-crawler controls - Current ClaudeBot, Claude-SearchBot, and Claude-User descriptions and controls.
- Perplexity: crawler and user-agent documentation - Current PerplexityBot and Perplexity-User descriptions and controls.
- OWASP: LLM prompt-injection prevention - Threat categories and layered mitigation practices.
- Apache HTTP Server: mod_log_config - Authoritative Apache access-log fields and formats.
- nginx: HTTP log module - Authoritative nginx access-log configuration and variables.
- Google Analytics: traffic-source dimensions - Current GA4 source, medium, campaign, and default-channel definitions.
- FTC: Endorsement Guides Q&A - Current U.S. regulator guidance on endorsements, disclosures, and reviews.
- FTC: Consumer Reviews and Testimonials Rule Q&A - Current U.S. rule guidance on deceptive review practices.