Atlassian AI Compliance: Turn Rovo Settings into Reviewable Evidence

Atlassian publishes a clear Rovo data path: a request may use Atlassian-hosted models or a dynamically selected third-party model, and organizational data that the user may view can be added to the prompt. That description gives a compliance team its starting point. The review still needs customer-side proof of who asked, what content crossed the model boundary, which destination received it, and which policy allowed the transaction.

I would put one Rovo request on a sheet of paper and make every control owner annotate it. A certification badge cannot reconstruct that request.

TL;DR

• Atlassian AI compliance requires evidence for Rovo activation, model routing, data contribution, residency, and connectors, including user permissions.
• Atlassian states that third-party LLM providers operate under zero data retention terms and cannot use customer inputs or outputs to improve their services.
• The customer still owns the request-level decision about sending personal or confidential data, including regulated data, to the selected model route.
• A defensible review joins Atlassian administration records with an independent policy record at the HTTP LLM boundary.

The Rovo data path defines the review scope

Atlassian's AI Trust page says Rovo combines open and self-hosted models with third-party hosted models. Dynamic routing may select models in OpenAI's GPT series and Anthropic's Claude series, as well as Google's Gemini series. Atlassian also says each request sent to an external provider travels individually over an encrypted service, and that those providers retain neither the input nor the output.

That vendor statement should be a testable data-flow record. Name the Atlassian app where the request began and the user. Then record the source objects added as context, the selected model route, and any third-party processor. Record the applicable contract and data location. Cloud Enterprise customers may request Atlassian-hosted LLMs only, which changes the destination path and is part of the approved configuration baseline.

The useful diagram has boxes and arrows labelled with actual owner names. A green rectangle labelled "Rovo" tells an assessor almost nothing.

Configuration evidence needs named owners

Atlassian says AI activation for Atlassian apps is an organization administrator setting, while Search and other non-AI Rovo capabilities are still available. Its documentation also describes app-level opt-out controls, content allowlists or blocklists for certain connectors, data contribution settings, and data residency support for in-scope app data.

Each setting needs an owner and an approval record, plus a recurring test. The AI platform owner should export the enabled-app state and approved routing choice. Privacy should retain the data contribution decision and its rationale. Security should capture connector scope and verify that source permissions are current. Records management should document what residency pinning covers and where transient processing still occurs.

This is where Atlassian Intelligence security and compliance diverge. Security review asks whether permissions and controls work. Compliance review asks who approved those controls and when they were tested. It also asks which artifact proves the result for a sampled request.

Permissions are an input rather than the whole control

Atlassian states that Rovo respects existing permissions across Atlassian apps and configured third-party connectors. Two employees can receive different answers because their accessible Jira work items and Confluence pages differ, as can their connected sources. Automation adds another detail: the connecting user's permissions determine the knowledge available when an automation rule calls an agent.

A review should sample those paths directly. Select a restricted Confluence page and a Jira work item, plus one connected source. Run the same query as two controlled users, then repeat it through an automation identity. Preserve the source references, user or connecting identity, response, and administration state. The owner should explain any difference without reconstructing it from memory.

Permission inheritance is the basis for retrieval eligibility. The later decision to send assembled context to a model route has a separate purpose and destination governed by its data classification. The AI vendor risk assessment should therefore cover both source access and model egress instead of treating a successful permission test as complete evidence.

Privacy review follows the actual disclosure

Atlassian's data-handling page explains its privacy practices, while the Rovo trust material states that customer inputs and outputs are excluded from third-party model training. Those commitments matter. The customer's legal basis and purpose analysis still turns on the content of a particular request and the destination that received it.

For personal information, record the collection purpose and the approved Rovo use. For confidential engineering material, identify the permitted model boundary and any route restrictions. For regulated data, document product-specific limits. Atlassian's AI Trust page, for example, lists which Rovo capabilities are available within supported HIPAA-enabled environments and separately names what is outside that scope.

I would reject a control description that says only "covered by Atlassian terms." A review needs to show exactly which capability and site are covered, plus the route, data class, and policy version. The AI governance audit framework provides the wider testing structure for keeping those artifacts together.

The evidence package for one sampled request

A useful sample starts with the originating identity and timestamp. Add the Atlassian app, source references, connector identity, and effective permissions. Then preserve the model destination, content classification, policy outcome, Rovo transaction or audit identifier, and relevant administration snapshot. Link the sample to the approved use case and processor record.

The package should also include a denied test. Send a controlled payload whose classification is prohibited for the selected route and retain the refusal record. Repeat after a permission change and after the relevant AI capability is disabled. These tests distinguish an operating control from a screenshot of a settings page.

Atlassian's Trust Center can support vendor due diligence, including its statements on SOC 2, ISO 27001, provider retention, and annual audit coverage. Customer evidence covers due care inside the deployment. Both records belong in the file, with separate owners and review dates.

DeepInspect

DeepInspect provides an independent policy decision at the HTTP AI request boundary. For Rovo or another Atlassian workflow deliberately routed through that boundary, it evaluates the supplied identity and role against organizational policy for the content classification and model authorization before the request reaches the LLM.

Each decision produces a signed, tamper-evident record outside the calling application's write path. That record can join the Atlassian administration snapshot, source-permission test, processor record, and model destination into evidence for one sampled request.

Book a technical deep dive at deepinspect.ai.