Should AI be on by default? Defaults are policy
Should AI features be on by default? Only if the opt-out, the comms and the audit trail ship with it. A designer's view from Atlassian Intelligence.
6 minutes. Maybe a second coffee.
Whether AI should be on by default depends less on the AI than on whether admins can see the change coming, say no easily and prove later what happened. A default is a policy decision, and switching AI on by default is only defensible when the opt-out, the comms and the audit trail ship with it.
You don't get to choose an aggressive default without also shipping the way out.
Why is "on or off by default" the wrong first question?
It's the wrong first question because it treats the default like a setting, when really it's a commitment you're making to every customer who never opens the admin console. Right now the debate splits pretty cleanly. On the buyer and legal side, pieces like TechTarget's What businesses really need from an AI off switch and Marks & Clerk's Stopping "Shadow AI by default" argue that enterprise AI should be opt-in, and that a vendor shouldn't get to switch it on through an update. On the other side, vendors keep shipping AI into products people already pay for, and the reasoning behind whichever default they pick rarely makes it into the changelog.
Both camps are arguing about the toggle. I think the better question is what the default commits you to, because whichever way it points, someone has to live with it.
What does "defaults are policy" mean?
"Defaults are policy" means every default in an admin console says what kind of customer you want, what risk you're comfortable with and what behaviour you're nudging toward. Most admins never change most settings, which sounds like a small detail until you realise it means the default is the policy for most of your customers. They didn't choose it. You did, on their behalf.
That's the line I worked from on Atlassian's AI admin surface, and it's written up as a decision in Defaults are policy. Thousands of admins were going to see those settings and most would never touch them, so the team spent a disproportionate amount of time on defaults. I still think they mattered more than the visible UI by a fair margin, which is a slightly awkward thing for a designer to admit.
What did shipping AI on by default actually take?
Shipping AI on by default took about ten surfaces, owned by different engineering teams, stitched into one event an admin could follow. The change was AI Default-On, which switched Atlassian Intelligence from opt-in to on by default across Enterprise and Premium. It shipped to more than 60,000 Enterprise and Premium customers.
From the outside it looks like one toggle. From the inside it touched the admin hub opt-out flow, per-product override controls, pre-change and post-change customer emails, the Product Updates release note, in-product notifications, audit log entries, and a few more pieces underneath. None of those teams reported into each other, and none of their goals said anything like "the admin has a coherent experience". Engineering shipped each piece correctly on its own terms. Whether the pieces added up to something an admin could understand was the bit nobody else was accountable for, and that was the design seat.
Honestly, a lot of that work was less craft and more getting five teams to agree on a sequence, a name and a rollback behaviour before any UI existed. Not glamorous, but it's the difference between an admin thinking "right, I saw this coming" and an admin finding out from a confused user. The full story is in the Atlassian Intelligence case study.
What does a default-on rollout have to ship with?
A default-on rollout has to ship with everything an admin needs to understand the change, refuse it and defend their choice later. Here's the list I'd hold any team to:
- 1.An opt-out that's easy to find and easy to use. It should work at the organisation level and per product, because "all or nothing" isn't a real choice for a big org.
- 2.Comms that reach the admin before the product does. A pre-change email, a release note and a post-change email, so nobody hears about it first from their own users.
- 3.An audit trail treated as part of the product. When a compliance team asks "show me what AI did in our tenant last quarter", the answer should be one legible export, not a forensics project.
- 4.One coherent event, even when many teams ship the parts. Someone has to hold the admin's view of the whole while each team holds their piece.
- 5.Honest measurement of who said no. Log the opt-outs, and report them as part of the result rather than as a footnote.
If you can't ship all five, I'd argue you haven't earned the aggressive default yet.
How should you read the opt-out number?
You should read the opt-out number as the safety valve working, not as the rollout failing. On Default-On, 15% of enterprise customers and 3% of premium customers used the opt-out the team shipped. That's honest telemetry, logged.
It's tempting to look at an opt-out rate and see rejection. I see admins who had a reason to say no and a control that let them say it, which is the whole point of shipping one. My read is the higher number on enterprise makes sense too, because those are the orgs with the most governance to answer to. A default-on change with an opt-out nobody can find would show a lovely low number and a lot of quietly furious CISOs.
The rollout also sat alongside outcomes the team landed across the wider admin work, including an 8.43% AI enablement lift and a 3.4 point lift in AI admin enablement against the OKR (8.8% against a 5.4% baseline). Those are team numbers, and the case study credits the 3.4 points to the Default-On work and the data governance work that ran alongside it.
When should AI stay off by default?
AI should stay off by default when you can't yet ship the way out, or when the change alters something the customer reasonably believed was settled. That's my position, not a rule, and I hold it loosely. The examples I'd put on that list:
- —a feature that changes how customer data is used, where the original agreement didn't contemplate it,
- —products serving regulated customers, where the admin needs to clear the change with compliance before anyone sees a prompt box,
- —any feature without a credible opt-out, audit trail and advance notice ready on day one.
The opt-in camp makes a strong case here, and I don't think they're wrong about the risk. TechTarget's piece makes the point that switching a feature off in the interface doesn't always mean the processing stops, and that's exactly the kind of gap that breaks trust with an admin. Where I differ is that I don't think "always opt-in" is the only safe answer. A well-built default-on change, with the controls in place, can respect the admin more than a buried opt-in that nobody ever finds.
Anyway. The AI still can't decide this bit for you, which I've written about before. The judgement stays human.
FAQ
Should AI features be on by default in enterprise software?
AI features can be on by default in enterprise software only when the opt-out, the advance comms and the audit trail ship with the change. Without those, opt-in is the safer choice, because the admin has no way to see the change coming or prove later what happened.
What's the difference between opt-in and default-on for AI features?
Opt-in means AI stays off until an admin deliberately switches it on, while default-on (sometimes called opt-out) means AI is switched on unless an admin turns it off. With default-on, the vendor makes the first decision for every customer who never changes the setting, so the vendor carries more responsibility for how that change is explained and reversed.
What admin controls should ship with a default-on AI feature?
A default-on AI feature should ship with an organisation-level and per-product opt-out, notice before and after the change, and audit log entries that record who opted out and when. It also needs a clear place for admins to see what AI is doing in their tenant afterwards.
What does "defaults are policy" mean?
"Defaults are policy" means a default setting is a decision made on behalf of every customer who never changes it. Each default says what kind of customer you want, what risk you accept and what behaviour you're nudging toward.
When should an AI feature stay off by default?
An AI feature should stay off by default when it changes how customer data is used, when regulated customers need to clear it first, or when there's no credible opt-out ready. In those cases opt-in respects the admin's role as the person who decides whether AI runs at all.
Close
The short version of the decision lives at Defaults are policy, and the longer story, with all the surfaces and the people who built them, is in the Atlassian Intelligence case study. If you're working through the same call on your own product, on or off, I'd genuinely like to hear how you're thinking about it. You can get in touch here.