Policy and governance. We created a public AI usage policy with hard rules for both internal work and client projects. It covers:

• what tools are approved
• how data is classified before it gets anywhere near an AI tool
• what can and can’t be automated in client-facing work
• who's accountable when something goes wrong.

It’s the kind of work that doesn’t make for exciting blog posts, but it’s what makes everything else possible.

Discipline-specific guidelines. How a developer uses Claude Code is completely different to how a writer uses Claude or how a designer uses generative image tools. Generic policy doesn’t account for that. We worked through the specifics for each discipline, covering what’s appropriate, what requires review, and what’s off-limits entirely.

A proper risk assessment approach. Before AI touches any client work, we assess three things:

• Data sensitivity: whether the information is personal, commercially sensitive, or subject to regulatory requirements.
• Stakes: what the consequence of an error would be.
• Regulatory context: whether privacy law, the Public Records Act, or sector-specific regulation applies.

While human review is mandatory for every AI-assisted output full stop, the risk assessment then tells us how deep that review needs to go: a quick sanity check at the low end, line-by-line scrutiny where sensitivity and stakes are both high. Plenty of organisations rely on this in practice but never write it down, which is exactly where they get caught out.

A register of approved tools, reviewed regularly. The landscape changes fast. A tool we approved three months ago may have changed its data handling terms. We review the register every month and remove tools that no longer meet our standards.

Updated client contracts. Internal policy without legal scaffolding leaves you exposed. We updated our contracts to be explicit about IP ownership of AI-assisted outputs, how client data is handled in AI workflows, and liability when AI contributes to an error. These conversations aren't comfortable, but they build trust.

A no-blame reporting process. People need to feel safe flagging when AI gets something wrong without worrying about being blamed for using it. We built a lightweight incident reporting process, just structured enough that we can learn from mistakes and update our guidance accordingly.

Thursday afternoons belong to the team

We’ve cleared space in the calendar every Thursday afternoon for the whole team. We’re using this space for a range of things: self-led learning and experimentation, group AI workshops, client brainstorms, tool reviews, hack sessions, workflow improvement ideation, and more. It’s protected time in the calendar and it doesn’t get traded away for project work.

Not everything that comes out of these sessions is worth keeping, but watching the team try things outside their comfort zone and have those 'aha' moments has been the best part. We’re really clear that learning is the goal, not any specific output. This means that even if an experiment fails, the learning is still valuable and shared.

People are more willing to bring half-formed ideas, more comfortable saying “I tried this and it didn't work,” and more likely to pick up a tool and just start. A policy document tells people what they're allowed to do; protected time tells them it actually matters.

AI readiness assessments

We run these for clients trying to work out where they stand before committing to a programme of work. It came straight out of our own experience: you can’t bolt AI onto an existing setup and expect it to work. We look at content structure, API readiness, data quality, and governance maturity. The output is a scored report with a prioritised list of recommendations, practical and specific rather than an abstract document.

The pattern is consistent. Most organisations score well on intent and poorly on infrastructure. They’ve thought about AI. They haven’t done the content hygiene, the API mapping, or the data governance that makes AI useful. The tools are rarely the issue. It’s the data and structure underneath them.

Working with clients who are up for it

Some of our best learning hasn’t happened internally. It’s happened on actual projects, with clients who are willing to experiment alongside us. A handful of clients we’re working with now have been open to exploring new processes and workflows together, and we’ve been transparent with them about what we're trying, what we know, and what we’re still figuring out.

We’re having honest conversations with clients about where AI is useful on their project right now, where it introduces risk, and where it still needs a human in the loop. The clients who’ve responded well to that approach tend to get the most out of it, because they’re not waiting for AI to be perfect before they engage with it.

Start with values, not tools. What you care about shapes everything else. If you skip this step, you end up with a policy that doesn’t actually reflect how your organisation works or what it stands for.

Use the NZ frameworks. The AI Forum NZ and MBIE guidance are useful and built for our context. Don’t default to something you found on an American consulting blog.

Update your contracts. Internal policy without legal scaffolding leaves you exposed. Do this earlier than feels necessary.

Build the system, not just the policy. Roles, processes, incident response, and a register of approved tools. A policy without the operating model behind it is just a PDF nobody reads.

Make space and protect it. The cleared space on Thursday afternoons has been the single most important structural decision we’ve made. One-off sessions are energising but they fade. Regular, recurring space is what builds the muscle.