About this week's forced rollout of Rovo

[Juha Kohvakka]

Bit of background: am a senior Atlassian solution consultant, can see into many Atlassian Cloud instances in Finland, some large and some small, all editions represented. I'm writing this post from the POV of someone who works with orgs for whom data security is essential - think public sector orgs, orgs essential to national stability and the supply of critical services, defence sector, etc.

Yesterday morning (11 September), we started seeing Rovo enabled in instances where it previously wasn't. Some had AI enabled and some not.

From Team25 onwards during the summer, there were regular communications from  Atlassian about future enablement of Rovo, which were worded like (I quote directly from the emails):

"subscription(s) for Jira, Confluence, and Jira Service Management Premium and Enterprise plans will now include Rovo"

"your organization will gain access to Rovo over the next few days, which we're making available as part of your existing Jira, Confluence, or Jira Service Management subscription(s)"

"Once your organization has access to Rovo, you will see it in Atlassian Administration > Products and your users will be able to access Rovo features from Confluence, Jira, and/or Jira Service Management and the app switcher. No action is required to give your users access to Rovo and it will respect your existing AI enablement settings"

To take a small detour here, I'd like to point out that the UI path mentioned in the email doesn't exist for some customers, as the rollout of the new Atlassian Cloud Admin UI is in progress, meaning that the management of Rovo is in a different place depending on which UI the customer has. (In the new UI, the path is Atlassian Administration > Apps > AI settings > Rovo.) You might say that this is OK because these original emails where this info was given are 2-3 months old now, but even in the latest emails which arrived on the 9th, there are instructions such as: "In support of your data residency requirements, you can now request to have your in-scope Rovo data pinned to the supported location of your choice. Schedule your move in Atlassian Administration > Security > Data Residency." But in the new Atlassian Cloud Admin version, the path is actually Atlassian Administration > Data management > Data residency. ANYWAY ...

Back on topic, the primary concern here is that for some of our customers Rovo is not desired, for some it is not allowed. Some reasoning behind it is that the processing of data for the various features of Rovo is not transparent enough and the statements regarding the safety of data are not specific enough. Rovo will therefore not easily pass organizational approval and before there is approval, it cannot exist for the organization (which is different than showing/hiding its UI buttons). It also DEFINITELY is not allowed to touch the Jira/Confluence apps data, neither to index it nor to generate responses, nor to refer to the data even when database access is denied.

Still, some artifacts of the enablement we noticed during the day was:

1. When Rovo was enabled, and AI access to apps was disabled, Rovo could still refer to the Jira data somewhat, for example by showing smart links.

2. When Rovo is enabled, and AI access is disabled, it can be used as an uncontrollable AI tool, which is not allowed in these orgs, because AI tools have to be approved by the orgs case-by-case, and the process is not allowed to be started by the app vendor like this.

3. When AI access is disabled and therefore Rovo's buttons are hidden from the app UI's, the Rovo UIs can still be accessed from their URL (for example, if an end-user had time to bookmark Rovo Search, while it was available from Jira's UI)

4. Inside Jira with Jira and JSM in use, when AI access to JSM is disabled, but access to Jira is enabled, Rovo is still shown when using a service workspace, and no matter where you use Rovo, it can access data inside service workspaces (yes, even if AI access to JSM is disabled).

We noticed during the day that there were some steps we could take:

1. We can indeed disable AI access to the apps to hide Rovo. However, there are a couple of issues with this:

- The organization may have approved the use of Atlassian Intelligence, but not approved Rovo. So, this "nuclear solution" rolls back already approved/enabled features in order to get rid of Rovo.

- This solution only hides Rovo, it does not disable it from running nor uninstall it. The latter actions are necessary for orgs where the tool is not allowed to exist in the cloud instance.

2. We can indeed set the data residency of Rovo, however there are again a couple of nasty caveats as far as I understand (correct me if I'm wrong):

- It only applies to in-scope data

- It only applies to data stored (not data in transit / processing)

To close this story off, I'd like to make a couple of general statements which are somewhat situational to my environment and clients:

1. One major criticism I would raise is that the per-instance-change was not alerted centrally enough to the admins of the instance beforehand inside the Atlassian Cloud UI. Emails are OK but not great. In this case emails didn't really work to prepare anyone for the enablement on this particular day.

2. While this change was/is happening, the instructions in the Rovo documentations (and emails that arrived way back) are incomplete, out of date and sometimes misleading. This is really not acceptable. The documentation should explain Rovo's technical details better and instructions should apply to all versions of, for example, Atlassian Cloud Administration.

3. Rovo must be able to be uninstalled if necessary for the customer. Statements like (quote from the official documentation) "Can I turn off Rovo? No, you can’t turn off Rovo" are not acceptable for enterprise grade business software. If you can install it, clients must be able to uninstall it. This should definitely be a near-future feature.

4. Changes such as this should always be opt-in. This is obvious enough that I should have to point it out, but orgs approve new apps beforehand, not after when there's no other choice. And to reiterate, the process to approve new apps is not allowed to be started by a vendor, it is started by end-users, IT service owners or IT management.  Not vendors such as Atlassian.

5. Change such as this should follow the release tracks chosen by the Atlassian Cloud Admins. For example, in this case we suspect that for at least one client, their bundled release happened on 9/9, but the Rovo enablement for Jira happened on 9/11. 

I hope I was able to shed some light on how this rollout was perceived by us and some of the clients we work for. I also hope you (Atlassian) can find some learnings from this text and, for others reading, feel free to use this thread for commentary on how the launch happened for you. Thank you for reading.