Govern Rovo before you switch it on
Turning Rovo on takes a click. The work that protects you is deciding what it can see, who can use it, and where it stays off, before the rollout instead of after the first surprise.
The hard part of artificial intelligence (AI) in the Atlassian platform was never the model. It is deciding, on purpose, what the thing is allowed to do. Rovo, Atlassian’s AI layer, can search, summarize, and act across your Jira and Confluence, which is exactly why an unconsidered rollout is a liability and a considered one is an advantage. The reassuring part is that most of the work is familiar. It is access and change management, not data science. You already know how to do this. The trap is assuming AI is a new category of problem when it is mostly an old one with the volume turned up.
We have walked into enough of these rollouts to notice a pattern. The teams that struggle are not the ones with the wrong model or the wrong vendor. They are the ones who flipped the switch first and asked the governance questions second, because the answers were inconvenient. The teams that do well treat the switch as the last step.
Your permissions are already your AI security model
AI inside the Atlassian platform answers from what a user can already see. It inherits access rather than inventing it. So the first thing we look at in a rollout is not the AI, it is access, and it is almost always looser than anyone remembers. A Confluence space opened to all logged-in users for one project years ago and never closed again. A Jira project inheriting permissions from a scheme no one has revisited since the team that owned it reorganized. A board of directors space that a well-meaning admin shared with a group that has since tripled in size. None of that was careless. Access debt accretes the way technical debt does, one reasonable shortcut at a time, each made under deadline by someone who meant to circle back.
The difference is that AI surfaces that debt instantly and legibly. A curious person might have taken hours to stumble onto an over-shared space, and most never would. Ask Rovo a plain question, though, and it will happily pull from everything the asker can technically reach, which is frequently more than anyone intended. The salesperson who asks for a summary of an account and gets a paragraph sourced from a half-forgotten finance page is not a security breach in the dramatic sense. It is a permissions problem that was always there, finally made visible. Before you weigh a single model, reconcile who can see what. That reconciliation is the most valuable work in the whole rollout, and it pays off whether or not you ever turn the AI on.
Decide what AI sees on purpose, not by default
Permissions are the floor. On top of them you make deliberate calls: which spaces and projects are in scope, which are walled off, and which data never goes near a model no matter who is asking. Legal hold material, unannounced acquisitions, personnel investigations, anything bound by the Health Insurance Portability and Accountability Act (HIPAA). In a regulated environment those are not preferences, they are commitments your auditors will check, and the auditor does not grade intentions.
The test we use is simple. Can you give a written answer to the question your risk team will ask: what can this see, and how do you know? If the answer is a shrug, or a promise to look into it, you are not ready, and that is fine. It means you have found the work before it found you. We saw this clearly with a Food and Drug Administration (FDA) regulated infant-nutrition company running critical work for 350 people across Jira, Confluence, and Jira Service Management (JSM). In a business operating under that kind of scrutiny, how work moves matters as much as the work itself, and traceability is not a nice-to-have, it is the product. You can read how that came together in our digital workplace work. The point that travels to AI is the same one that governed the original build: decide what is in scope deliberately, write it down, and make it auditable.
AI inside Atlassian answers from what a user can already access. The first question of governance is whether your permissions reflect what people should see, not just what they happen to.
Draw the line between assist and act
Summarizing a ticket is low-stakes. If the summary is wrong, a person reads it, notices, and moves on. Drafting a customer reply, closing a change request, reassigning work, or touching anything with a regulatory consequence is a different category, because the cost of a confident mistake is no longer borne by the reader. Governance is mostly drawing that line on purpose: where AI assists and a person decides, versus where it is allowed to act on its own.
Let convenience draw the line for you and you will find it in the wrong place only after something goes wrong, usually in a postmortem where everyone agrees, too late, that the action should have required a human. Draw it deliberately and the line becomes a feature rather than a liability. A useful way to think about it: AI can prepare, a person commits. Rovo can assemble the draft response, surface the likely root cause, propose the field updates. The human presses the button. As the team builds a track record and you can point to where the AI has been reliably right, you move the line. The teams that get burned are not the ones who were too cautious. They are the ones who let the tool act broadly on day one because it was easier than configuring the boundary.
It is a rollout, not a switch
None of this is set once. You enable AI in stages, watch how it actually gets used, teach people what it is and is not for, and tighten or loosen the boundaries as you learn. The instinct to flip everything on at once is understandable, especially when leadership has seen a demo and wants the value now. That instinct is not wrong about the value. It is wrong about the sequencing. A staged rollout reaches the same place and lets you keep your footing on the way.
What you are really building in those stages is judgment, both the tool’s configuration and your team’s sense of where it helps. Watch which questions people actually ask. Some spaces should never have been in scope, and some boundaries were drawn too tight and are now just friction. Adjust. That discipline is the whole difference between a pilot that grows into something you rely on and one that grows into something you have to explain to a regulator. It also pairs naturally with a move to Cloud, since the platform’s AI runs there, which makes the migration a good moment to set governance correctly rather than carry old habits across.
Done this way, AI becomes a capability you can stand behind, not one you hope is fine. The companies that win with Rovo are not the ones who adopted it first. They are the ones who can answer, plainly and in writing, what it sees and what it is allowed to do. Settle the boundaries first, and the tool earns its place. If you want to see where governance and delivery are getting stuck across your own platform, that is where we start.