ThoughtSpot’s Spotter 3 upgrade changes the data boundary—not just the analyst experience

ThoughtSpot’s newest Spotter experience is not a routine UI upgrade. Spotter 3 changes what data reaches the model, which users can invoke it, and where intermediate artifacts and conversation records persist. Administrators should treat enabling it as a data-processing change with an access and retention review, not simply a feature toggle.

The permission gate is broader than “can ask a question”

ThoughtSpot says Spotter 3 is the default experience on newly created instances; existing instances must have it enabled by an administrator. The documentation also says a user needs Can download data privilege because Spotter accesses and analyzes data on the user’s behalf. That makes download entitlement part of the rollout boundary: teams should inventory who holds it before making Spotter 3 broadly available.

This is materially different from Spotter Classic. Classic primarily works from metadata and governed models and, by default, does not send actual data values to an LLM. Spotter 3 always shares data with an LLM because its research, cross-model and advanced-analysis paths need query context. ThoughtSpot says row- and column-level controls still apply and only filtered query results—not entire tables—are transmitted.

Map four retention surfaces

The data-handling documentation describes more than one place to inspect:

1. LLM processing: filtered query results are sent for analysis; ThoughtSpot says its provided LLMs are stateless and operate under zero-retention and no-training terms.
2. Advanced-analysis artifacts: LLM-created Python is cached in Azure for six hours by default.
3. Conversation history and insights: previous chats are opt-in and retained for six months by default; without saved conversations, temporary persistence can still last up to six hours.
4. Interaction logs and backups: the Spotter Conversations Liveboard data pipeline is enabled by default, with events retained for 180 days, while encrypted daily backups can include chat history and insights when enabled.

These are separate controls. Turning off visible chat history does not, by itself, describe the logging pipeline, temporary artifact cache or backup contents.

Hidden columns are a blunt instrument

Administrators can exclude fields from LLM access by hiding columns in the model. But ThoughtSpot warns that a hidden column also disappears from standard ThoughtSpot Search. A field shown on an existing Liveboard but hidden from Spotter may also make follow-up answers worse because the model cannot see it.

The practical test is therefore not merely “does row-level security still work?” It is: which download-capable users are enabled, which columns are eligible for model transmission, which LLM route and region apply, and which of the persistence surfaces are acceptable under policy.

A safer rollout sequence

Start with existing instances, where Spotter 3 remains disabled by default. Pilot it with a narrowly scoped group, validate row- and column-filter behavior using representative prompts, and inspect the Conversations Liveboard and saved-chat settings. Decide whether to use ThoughtSpot-provided models or bring an organizational key through Azure OpenAI, Vertex AI, Bedrock or a custom gateway. Finally, record the six-hour artifact window and 180-day interaction-log policy in the system’s data-flow inventory.

Spotter 3 offers deeper analysis—multi-source search, research mode, code execution and self-correction—but those capabilities are inseparable from the new data path. The upgrade decision belongs with data governance and security reviewers as much as with analytics owners.