A bug report can contain everything needed to reproduce a failure and several things nobody intended to send to an AI service: a customer email address, an authorization header, a production screenshot, or an internal incident discussion. Asking Rovo to summarize that report creates a data-handling decision before it creates a useful summary.
For a QA lead, the decision depends on separate controls. Source permissions determine who can retrieve evidence. AI processing and retention policies describe what happens during and after a request. Atlassian's data contribution settings govern eligible data used to improve experiences across customers. Approving one of these does not settle the others.
Start with a specific QA task, such as preparing regression coverage after a checkout change. List the material the assistant would need and where it lives. A Jira work item may link to a Confluence requirement, a support conversation, and an external document. Copying all of them into a prompt can expand the processing scope beyond the original bug description.
For each source, record its owner, audience, sensitive fields, and intended use. Include comments and attachments in the review, even when the planned request mentions only the issue summary. Decide whether a sanitized reproduction, synthetic payload, or short requirement excerpt would be sufficient.
Also identify the service handling the request. Native Atlassian AI, a Teamwork Graph connector, a Marketplace test-management app, and an external assistant are different data paths. A policy about Rovo's model providers does not automatically describe a separate app that reads the same Jira issue.
Atlassian says Rovo follows existing permissions in Atlassian apps and connected sources. Users can receive different answers because they can access different material. A response may draw on accessible Jira and Confluence content across app experiences, rather than only the app where the user started.
That means a broadly shared document remains broadly accessible context. Before connecting a repository of QA evidence, inspect its existing audience. Check whether incident documents, exported logs, and customer-support attachments have wider access than the team intended. Restrict the source or prepare an approved derivative instead of relying on an assistant to recognize confidential passages.
The connector type also changes the review:
Atlassian documents synchronization of permission changes, but the reviewed guidance does not supply an instantaneous revocation guarantee. If a sensitive source has been restricted or removed, have its owner and administrator confirm the relevant connector state before allowing further use. Do not assume that removing access retroactively erases a summary someone already copied elsewhere.
AI activation is another control, not a substitute for source restrictions. Atlassian's Cloud guidance says that when AI is activated for apps on a site, AI features can use data from other apps on that site, subject to access permissions. Turning off AI for one app is not evidence that the app's data is isolated from every AI experience.
Atlassian says the LLM providers used for Rovo do not retain inputs and outputs or use them to improve their services. Its current guidance also describes strict zero data retention agreements with third-party hosted LLM partners. These are provider commitments within the documented service, not a promise that no system retains anything.
The Rovo privacy guideline separately says Atlassian retains Chat and agent inputs and outputs for 30 days for safety and security purposes. A QA reviewer should therefore reject the shorthand “Rovo has zero retention.” Record who retains which data and why, even when the external provider does not retain the request.
Data contribution has another retention schedule. Atlassian's detailed contribution documentation says that, when applicable contribution settings are changed to opt out, or an app or site is deleted, corresponding in-app data is removed from improvement datasets within 30 days and corresponding content attributes within 90 days. It also describes retraining models previously trained on that data and stopping further collection and recurring-pattern identification.
There is an important qualification beside those withdrawal periods: data de-identified and aggregated at customer level so that it is no longer associated with individual customers, including common patterns, may be retained for up to seven years. The FAQ's shorter metadata-retention summary should not be read as a guarantee that every derived pattern disappears within 90 days. Nor is an improvement-dataset removal period a universal deletion deadline for all operational records.
For sensitive QA work, minimize the input before processing. Opting out later is not an immediate recall mechanism for every derivative or downstream copy.
Atlassian's updated contribution policy took effect on August 17, 2026. Its initial scope includes Jira, Confluence, Jira Service Management, and embedded Platform apps such as Rovo, with settings for certain Teamwork Graph connectors. Atlassian says it does not contribute metadata or in-app data from apps for which contribution settings are not available.
The categories extend beyond an uploaded document. In-app data includes Jira work item titles, descriptions, and comments. Metadata includes content attributes, such as statistical characteristics and numeric fields, and common patterns derived from search queries and results, Rovo Chat prompts and responses, and configuration data. Calling something metadata does not mean the QA team can ignore how it was derived.
Atlassian says contributed data is de-identified and aggregated before use to improve experiences for all customers. It also says contributed metadata may be used to fine-tune open-source models within Atlassian's infrastructure, subject to contribution settings. This is separate from the promise that third-party LLM providers do not train on customer inputs and outputs.
Defaults follow the highest active plan within each Atlassian organization, including trials. They do not follow only the Jira subscription the QA team happens to use. Review each organization independently.
For an otherwise eligible organization, the documented defaults are:
Highest Active Plan | Metadata Contribution | In-App Contribution Default |
|---|---|---|
Free or Standard | On; no metadata opt-out | On |
Premium | On; no metadata opt-out | Off |
Enterprise | On; metadata opt-out available | Off |
These are defaults, not a readout of your tenant. Previous selections, scoped exceptions, compliance exclusions, and plan changes can affect the actual configuration. An organization administrator can change available in-app contribution settings. Metadata choice requires an active Enterprise plan unless the organization is excluded from contribution.
Have the organization administrator review Atlassian Administration, then Security, then Data contribution. Record the organization, highest active plan, actual settings, and exceptions rather than attaching an unqualified statement that “Premium is opted out.” Premium's in-app default does not turn metadata contribution off.
When organization-level in-app contribution is On, the documented controls allow exclusions for specific spaces, Atlassian apps, or eligible Teamwork Graph connectors. When it is Off, selected sources can be included instead. Confirm the relevant source and current configuration before requesting a change through your normal approval process.
Platform-app contribution is governed at organization level. The inclusion guide says administrators cannot choose individual Platform apps for inclusion. Content that does not belong to a specific space or app also follows the organization-level setting. Do not promise a separate Rovo-only contribution switch, or assume excluding a space's in-app content also disables metadata contribution.
Compliance eligibility needs explicit confirmation. Official pages describe exclusions for offerings such as customer-managed keys, Government Cloud, and Isolated Cloud, together with HIPAA-related exclusions, but their descriptions of government and financial-services customer eligibility are not identical. The FAQ also distinguishes government-run educational institutions. Do not infer an exemption from your industry or affiliation alone. Ask the administrator and Atlassian support to confirm the organization's classification and displayed settings before relying on an exclusion.
AI activation and contribution remain independent settings. Disabling an AI experience does not establish that eligible Jira descriptions stop contributing under the organization's contribution policy.
Data residency answers where in-scope app data is stored. It does not, by itself, prove that every AI request is processed in that region. Atlassian's AI trust guidance says default Rovo processing can send requests to third-party hosted LLM providers. Review the applicable processing arrangements separately from the app's pinned storage location.
Contribution documentation adds another limit: customer residency settings cannot be applied to contributed data de-identified and aggregated at customer level so it is no longer associated with individual customers. A residency sign-off should name the covered data and exceptions, rather than declare that all source material and derivatives always remain in one region.
Marketplace apps require their own review. Being outside Atlassian's current contribution settings does not mean an app performs no processing or retains no data. Check the app's terms, privacy documentation, subprocessors, retention, and residency scope for the workflow you intend to use.
For example, Sherlock Test Management describes selecting Jira issues, Confluence pages, and files to prepare a testing brief and proposed test cases, with human approval before changes enter the baseline. A sanitized source set and a reviewed brief fit that workflow. Those capabilities do not establish Sherlock's privacy terms or make native Rovo retention and provider commitments apply to Sherlock. Keep approval of generated coverage separate from approval of the data-processing arrangement.
Consider a fictional refund defect. Its Jira description contains the reproduction steps, while an attached log contains a customer email address and a live authorization token. A linked incident page is shared with a broader audience than the payment team. The QA lead wants suggested regression scenarios, not a replay of the production transaction.
The lead first asks the source owners to prepare an approved reproduction using synthetic identifiers and a structurally representative payload without the token. The incident owner reviews the page's audience. The administrator identifies the relevant connector and checks the organization's contribution settings, including any source-specific exceptions and the actual highest active plan.
The request can then focus on behavior: suggest regression cases for repeated refund requests, permission checks, and a gateway timeout using the approved requirements. It should exclude the original log and unnecessary customer details. This is a proposed workflow, not a claim that redaction guarantees anonymity or that a particular tenant has passed a privacy test.
A reviewer still checks the suggested cases against the requirements before accepting them into the test baseline. They also inspect generated descriptions and shared summaries for unnecessary sensitive context. Human review of test design improves the artifact; it does not retroactively authorize the input that produced it.
Keep a short decision record beside the QA workflow: approved task and source set, source owners and audiences, connector type and scope, applicable processing and retention terms, contribution settings and exceptions, residency limitations, and the person approving use. If an essential boundary remains uncertain, use a sanitized alternative or defer that source rather than filling the gap with a general no-training assurance.
Revisit the decision when a connector is added, a source audience changes, or a plan or trial changes the available contribution controls. Atlassian documents notification and review periods for relevant plan changes, but those should not replace an owner tracking the change. The useful approval is specific enough that another QA lead can see what evidence is allowed, for which task, and what would make the approval expire.
Two reports can describe the same symptom while disagreeing about where the failure occurs. If a reviewer accepts a duplicate suggestion because the titles…
A checkout test times out while waiting for an order confirmation. The runner reports an assertion failure, the application records a failed request, and…
A recipient-preview rule changes, but the regression suite still checks the earlier behavior. An AI agent may choose a different route through the editor…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
