AI governance best practices, and the order we actually did them in

I'm Andrew, a principal engineer on Miro's developer experience and infrastructure team. I also spent the past year as the engineering lead for our company-wide AI transformation, working alongside partners in product and design to figure out how we adopt AI tools at scale. This is what that process looked like, in the order it really happened, and what I'd tell another engineering leader trying to do the same thing on a tighter timeline.

Quick answer: Most AI governance advice assumes you build the rules first and adopt the tools second. In practice, that's rarely how it goes. This is one account of adopting AI fast, deliberately letting governance lag behind for a defined period, and catching up once the resourcing was in place, plus what we'd do differently if we started over.

The part nobody puts on the slide

Ask me now, in hindsight, whether we got this right from the start, and the honest answer is no. Not at first.

In the middle of last year, we recognized how much was happening in the AI tooling space and wanted to give people the freedom to figure out what was actually worth using. So we opened up a constrained budget and broad access to whatever tools people wanted to try: Cursor, Windsurf, GitHub Copilot, the JetBrains AI coding assistant, and more. We told people it was a free-for-all: try things, tell us what to invest in, tell us what to drop. We learned an enormous amount very quickly. We also created a genuine wild west, where everyone was experimenting with a different tool and there was no shared golden path. At that early stage, that was fine. It's what got us the information we needed.

Then came what a lot of people in the industry now call the "Opus moment." A new Opus model launched around October or November of last year, and over the following weeks, people who tried it kept having the same reaction: this is a different category of capable than what we were used to. One of our most AI-forward team members, an analyst and a real advocate for using these tools well, sat down with our head of engineering one Friday afternoon and got him set up, so he could spent the whole weekend experimenting with our codebase, and came back Monday morning saying we needed to think about this completely differently and move faster, because the tools were more capable than he'd expected. That week happened to coincide with an engineering leadership offsite, which meant the whole team was already in the room to make a call. The decision that came out of it: get everyone hands-on, accelerate the program from a planned six months down to two weeks, and open up the budget so personal spending limits weren't holding anyone back.

Getting 600 people hands-on in two weeks

I ended up coordinating that program, which meant deciding what to promote, what enablement to build, and how to actually reach everyone in that time window. The approach that worked was mobilizing roughly 70 volunteers, people nominated by their managers or who put their hands up themselves, who already sat toward the front of the adoption curve. Rather than running slide-based training, we asked them to run small, hands-on sessions where people brought a real problem they were stuck on that day and worked through solving it with AI, together. You can't teach this from a deck. People needed to have their own version of that "oh, this changes things" moment, the same way our head of engineering had his.

The other half of the work was picking one standard baseline: a single toolset, configuration, and set of connections that everyone started from, even though people could still branch out to other tools if they wanted. With 600 people involved, supporting a different setup for every person just isn't viable. We settled on Claude Code as that baseline. Because a lot of the people going through this, especially in product and design, had never opened a terminal before, our developer experience team built onboarding tooling that automated the parts that would otherwise have been a wall: access credentials, environment variables, and connections into around seven or eight internal knowledge systems, including the Miro MCP for board access, all preconfigured so people could get straight to trying things instead of troubleshooting setup.

What actually moved, and who noticed first

The adoption numbers were the clearest signal that something had actually changed rather than just spiked and faded. Usage climbed fast during the rollout and then settled into a roughly 98% plateau that's held since, meaning people kept using these tools well after the initial novelty wore off. Over the period we measured, code changes per engineer were up by roughly 50%.

One story that stuck with me: a product manager on our team had been mulling over a product idea for years without the time to build it. Once these tools were available, he used Claude Code to build a working prototype of it in about 20 minutes and called the result "revolutionary" for him. He also told me later that what pulled him in wasn't being handed the tools, it was coming back from holiday and seeing how far ahead everyone else already was. That fear of falling behind turned out to be just as strong a driver as genuine curiosity, for him and for a lot of other people.

That initial 50% figure also wasn't a peak we've since come down from. As of this September, merged PRs per engineer are up 113% compared to where we started in January of last year, and the curve is still climbing.

We also used Miro itself throughout this process. The enablement materials for those onboarding sessions were coordinated and pushed onto a shared Miro board through Miro's AI integrations and the Miro MCP, which is the same connective tissue that let people plug their AI coding tools into our own boards for context.

The part we almost didn't put in this article

Here's the piece that's less comfortable to share, but it's the most useful part for anyone earlier in this process than we are: we made a deliberate decision to prioritize speed over governance.

Security was involved from day one, in the sense that our partners from the security stream were in the room, working with us. But formal guardrails and a standardized security baseline weren't ready when we opened things up, and we decided not to wait. The reasoning at the time was straightforward: we couldn't afford to do nothing while we waited for every guardrail to be ready, because the industry was moving too fast to wait for perfect conditions before anyone touched these tools. So, our leadership made a deliberate decision to accept the risk for a period of time and catch up on governance once we had the resources to do it properly. We did catch up. But I want to be direct about the fact that there was a real window where adoption was ahead of the guardrails, on purpose, not by accident.

That same instinct showed up elsewhere too: we generally optimized for shipping something usable over getting it perfect, following the logic that any improvement beats none, and that waiting for the ideal version meant getting left behind while the industry moved on without us.

For context, here's what Miro's documented AI governance approach includes today: a written AI policy defining objectives, boundaries, and limitations; a broader set of Miro AI principles guiding AI use across the company; engineering-specific AI development principles, loaded directly into the configuration files AI coding tools read, that separate hard "must not" rules from softer "should not" guidance; ISO 42001 certification, checked by both internal and external auditors and built to cover requirements from the EU AI Act; customer-facing transparency information on Miro's trust pages; and technical controls including restrictions on AI tools bypassing permission checks, observability and threat detection on AI tooling, enterprise-grade agreements with model providers with no vendor permitted to train on Miro's code or data, and centralized secrets management.

There's no finish line, and that's the actual problem

Before this turns into a checklist, it's worth naming something that made this harder than it needed to be: there was no playbook to copy.

This is a change management problem, and it's one nobody's really solved before, certainly not at this pace. We went looking for how other companies handled their own AI rollouts and governance catch-up, and there wasn't a clean reference point to borrow from. We were figuring it out in the industry and inside Miro at the same time, which meant every rule we wrote was a best guess based on where things stood that week, not a proven model pulled from someone else's playbook.

And it doesn't resolve. I used to assume we'd eventually hit a stable point and settle into a fixed set of rules. That point hasn't arrived, and I don't think it's coming. Staying on top of what's changing, in the industry and inside our own company, is a constant effort rather than a project with an end date. That's really the problem AI governance has to solve for: not "what's the right policy for today's tools," but "how do we build something that keeps working once today's tools are gone."

What I'd tell someone earlier in this process

If I'm honest about what actually moved the needle versus what we're still fighting about, it looks like this.

Standardizing on one baseline tool had the single biggest impact of anything we did. Once everyone had a shared starting point, we had one surface to apply security guardrails to instead of a dozen, and one thing to teach and support instead of many.

Don't leave enablement and governance as a side project. At first, we ran onboarding through a handful of people coordinating it alongside their day jobs for a while, and it wasn't long before we couldn't actually support what was happening because there was no standardized path and no team accountable for it. We eventually formed a team, though even now it's a virtual one pulled together from other parts of the business rather than a fully dedicated group. We didn't do that soon enough. You can't run this as a side gig. It needs resourcing from day one.

Expect the tension between one vendor and staying tool-agnostic to stay unresolved. We tried standardizing on a single tool because it's simpler to secure and support. People immediately asked for other options, and we didn't feel we could reasonably say no to a best-of-market approach. So we're still genuinely balancing that: wanting to give people the best tools available against the real cost of securing and supporting all of them.

The human side of this

There's a real spectrum of reactions to this kind of change, from people who were all in immediately to people who stayed cautious and felt like they were falling behind. As a leadership team, one of the most useful things we did was lead from the front and actually show people we worked this way ourselves, rather than just telling them to.

The part that surprised me most was how many people were afraid to ask basic questions in front of peers who seemed further along. During the accelerated rollout, we had to be explicit that these were safe, small, peer group spaces where no question was a stupid one, because if people didn't ask, we couldn't actually help them.

That pressure hasn't gone away, it's just changed shape. Early on, the exhaustion was about keeping up with an industry moving faster than anyone could track. Now it's more personal: a kind of FOMO where people measure themselves against colleagues who seem further along and feel like they're competing to keep up. I feel this myself. Switching off at the end of the day is genuinely harder than it used to be, because the next useful result is one prompt away, and the cost of trying is so low that it's easy to convince yourself to take just one more shot at it. Good governance has to make room for that human reality, not just the technical one. A framework that only works for your most confident, most technical people isn't governance for the whole company, it's a policy for a subset of it.

Start where you are, not where you wish you were

I said it earlier, and it's still the honest answer: there's no point where this settles down and you get to breathe out. It's not a project you finish once and file away. So if I'm honest, the advice isn't "wait until you're ready." It's "start now, and keep building it as you go," because that's closer to what actually happened for us, whether we planned it that way or not.

If you're building out your own AI-assisted workflows and want a workspace that supports both the fast, real-time collaboration and the async handoffs that this kind of transformation actually requires, you can see how Miro's innovation workspace fits into that by signing up for free.

Frequently asked questions

What is AI governance? AI governance is the set of principles, policies, and technical controls that determine who's accountable for an AI system's outcomes and what safeguards exist to reduce risk. It covers everything from written AI principles to the technical guardrails built into the tools teams use every day.

Should you wait for full AI governance before rolling out AI tools? Not necessarily, and waiting isn't free of risk either. Teams that hold off on adoption until governance is airtight often end up with people building unsanctioned workarounds in the meantime. A more realistic approach is to shorten the gap between adoption and governance rather than trying to eliminate that gap before anyone is allowed to start, and to be honest with yourself and your organization about the trade-off you're making while that gap exists.

What are the most important AI governance best practices for engineering teams? Standardize on a baseline toolset before scaling access broadly, since a shared starting point gives you one surface to secure instead of many. Give governance and enablement dedicated ownership from day one instead of running it as a side project. Write AI principles that guide judgment, not just a list of approved and banned tools that will go stale within months. And expect the tension between speed and standardization to stay unresolved rather than assuming you'll eventually settle it once and for all.

How does ISO 42001 relate to AI governance? ISO 42001 is an international standard for AI management systems. Certification against it means an organization's AI governance approach has been reviewed by independent auditors rather than only self-reported, which gives customers and partners a way to verify that stated practices match actual practices.

What's the difference between AI principles and AI guardrails? AI principles are the written guidance that shapes judgment, such as distinguishing hard "must not" rules from softer "should not" guidance. AI guardrails are the technical controls that enforce those principles in practice, such as restricting which model providers can receive proprietary code or requiring human approval before higher-risk automated actions.