Moving from AI "No" to AI "Go" — A Practical Governance Framework

[#1]

Hello Atlassian Community! I'm @Alan Ross , Chief Security Architect here at Atlassian.

Most security teams I talk to today are dealing with the same tension: employees want to use AI tools now, while security, legal, and procurement still need time to review them. When the default answer is simply "wait," people often find their own workaround. That creates exactly the kind of visibility gap security teams are trying to avoid.

At Atlassian, we’ve developed a four-phase AI governance framework to manage that tension. Instead of treating AI adoption as a one-time allow-or-block decision, the framework lets teams move from controlled experimentation to production use in stages. We aren't lowering the bar for security; we are giving people a safe place to experiment early and applying deeper reviews only as a tool gets closer to real corporate data.

The Four Phases of AI Adoption

The framework separates AI adoption into four practical stages, making it easier to move quickly when risk is low and slow down when a tool starts to touch more sensitive systems or data.

Phase	Isolation Level	Data Permitted	Review Type
01 Experiment	Managed browser	No corporate data	None required
02 Testing	Total isolation (VDI)	Synthetic data only	Light intake
03 Proof of Concept	Managed pilot	Limited corporate data	Accelerated review
04 Production	Integrated	Full corporate data	Full business case

Why This Works

The core advantage of this model is proportionality. A low-risk sandbox should not trigger the same overhead as a production deployment that handles sensitive internal or customer data. Splitting the journey into stages helps teams avoid both extremes: over-reviewing harmless experimentation and under-reviewing real operational risk.

Getting Started

Most organizations do not need a large multi-year program to begin. A staged rollout can start with a few concrete steps:

• Weeks 1-2: Stand up managed access. Launch a managed browser application or profile with basic DLP controls to give employees an approved place to test public AI tools immediately.
• Weeks 3-4: Define a light intake process. Create a short checklist covering terms of service and data retention.
• Months 2-3: Build reusable synthetic data. Start with platforms like Jira or Confluence to test realistic workflows without exposing live records.

I’ve detailed our entire approach—including our design principles and how we handle the "observability layer" for AI agents—in our latest whitepaper: "From Sandbox to Agents: A Practical Governance Framework for Security Leaders."

I’d love to hear from you in the comments: How is your organization balancing the "need for speed" with AI vs. the need for security oversight?

Visit the Atlassian Trust Center  for more information.

[Tim Martin]

@Alan Ross - is there a link to the whitepaper available yet?

I think it's great Atlassian is forming an opinion on this. What I see above focuses on the risk and trust aspects (which makes sense, given its a governance framework). But practically, this isn't just about organisations getting comfortable with rolling out AI tooling, right?

Maybe this will be detailed in the whitepaper, but where do you recommend orgs start addressing some of the practical aspects within these steps? Eg:

- optimising knowledge

- tidying up permissions/access

- enabling staff (training, guides) 

[Alan Ross]

Hi Tim — great question, and you've put your finger on exactly the right gap. The blog is the "what / why" half; the "how" half is where most orgs actually get stuck.

Quick note on your first question: the whitepaper is already published — From Sandbox to Agents: A Practical Governance Framework for Security Leaders on the Atlassian Customer Trust portal. The blog post is the practitioner summary; the whitepaper is the deeper version to share with your governance, security, and IT leadership stakeholders.

On your bigger question — the practical levers — you've nailed the three that matter most. They share a common root cause: most enterprises have no shared knowledge layer for what's actually happening with AI in their environment, so every team rediscovers the same lessons. That's the gap I'm currently building toward — a shared knowledge system spanning AI experimentation, pilot, and production activities, captured as living best-practice patterns rather than static policy. Each of your three aspects maps onto a different surface of that system:

1. Optimising knowledge — start by classifying what you already have before pointing AI at it. Most "AI rollout" projects stumble because the knowledge corpus is full of stale, mis-permissioned, or sensitive content (UGC, customer data, ex-employee notes, half-finished docs). The practical entry point is a content-classification pass — automated where possible — to label what AI can safely traverse vs. what needs human curation. Capturing those classification patterns and the deltas across teams is what stops org #2 from repeating org #1's mistakes.

2. Tidying up permissions/access — the unglamorous truth is that most permission models were built when the only consumer was a human with a browser. Agents traverse content at machine speed and consolidate it across boundaries, which exposes drift you've been carrying for years. The practical sequence: (a) audit current permission state on AI-eligible content, (b) move from blanket "everyone in the org" to role-scoped access on knowledge that touches sensitive operations, (c) introduce machine identities for agents so you can audit what the agent saw on whose behalf. Reusable templates here beat bespoke configs every time.

3. Enabling staff (training, guides) — this is where a shared knowledge system pays its biggest dividend. Static policy docs go stale within a quarter. What works better: living playbooks tied to real activities — "here's how this team is piloting tool X, here's what they learned, here's the guardrail config that worked." The same scaffolding that captures experimentation outcomes becomes the enablement material — no separate authoring effort needed. Layer in lightweight role-based guides (engineers building agents / analysts using LLM tools / managers approving pilots) and you've covered 80% of the demand.

The thread that connects all three: governance only becomes operational when there's a shared, queryable record of what's been tried, what worked, what was risky, and what's now standard. Without that, every team improvises. With it, you get compounding learning across the org and the "Go" decisions get faster because the evidence base is already there.