Guardrails that actually work | Trust in the time of AI

When Portable's research and innovation team set out to build a voice agent for mental health helplines, the first question wasn't "how do we build this?" It was something harder: "What would it mean for someone in crisis to be let down by this tool?"

That question, from UX Researcher Deb Cupitt, shaped everything that followed. The testing methodology, the audience selection, the decision about which AI model to use and why. It also turned out to be a better question than the one most teams start with.

This article draws on conversations with three practitioners inside Portable who've built AI tools in regulated environments: Deb Cupitt (UX Researcher), Belinda Donald (Principal Design Strategist), and Luke Thomas (Principal Product Strategist). Their experience spans mental health services, legal technology, and public sector AI. Their answers are grounded in specific projects, specific failures, and specific things they'd do differently. That's the point. 

"How fast can we safely implement AI?" is a reasonable question. Belinda Donald's honest answer: "How long is a piece of string?"

"If you want to implement Claude helping you write emails, great. Easy. Do it," she says. "If you want to implement a voice assistant to support people on mental health helplines, that's a much different kettle of fish."

Luke Thomas's answer is more specific, and more useful for teams trying to plan: "If you know exactly what you want and have done the deep thinking, it can move much faster. With a clearly defined need, solution, and guardrails, a project can move as fast as six to eight weeks." He points to Portable's work with IP Australia as an example of what's possible when the problem is genuinely well understood before anyone starts building.

The underlying point is the same. Speed with safety can only be determined by how much actual thinking has been done before you start. The teams that move fast safely have usually already done something most teams skip: defined the problem precisely, mapped the risks, and brought in everyone who needs to be involved.

Deb's version of the first question is: "What problem do you want to solve here? Which ones feel the safest and best fit for the AI options we have?" Belinda asks "Why do you want to use AI for this?" before anything else. Luke's is: "What experience are you trying to create and solve for?" Three questions that sound different, but they're all doing the same thing: pulling focus back to the problem before anyone touches a tool.

One of the counterintuitive things Belinda learned during Portable's mental health voice agent project is that moving faster was sometimes the right call, as long as the direction was right.

The team had planned to prototype from day three of a five-day sprint. They ended up starting on day one. That early start let them experiment with four or five different tools quickly, narrow down what actually had the capability they needed, and start building safety protocols in from the beginning rather than retrofitting them later. "Getting in there early and just starting to play with the thing, even if it wasn't perfect, was really helpful for understanding the potential of the tools we were using," she says.

The key distinction is between speed to prototype and speed to the public. Luke's held-back moment was the opposite: on Amica, his team was working on a more intuitive AI chatbot, had everything tested, and were getting close to something that worked well. "But the amount of risk was higher with this kind of chatbot. In the end we had to stick with the more typical setup." The temptation to ship the better version was real. The decision to hold back was the right one.

Deb describes a similar pressure in the mental health context. Moving to public testing before the team understood the failure modes would have been "a lot more risky, both for the people being tested on and for us as a business." The reason is specific: when you don't know the people you're testing with, you can't scaffold for them. You can't provide trauma-informed support if something goes wrong. The people you can't reach to help are the ones most likely to be harmed.

The pattern across all three is consistent: move fast in controlled environments. Slow down before you move to real people.

Ask practitioners what teams consistently forget to ask, and you get three different answers that together cover a lot of ground.

For Deb, the overlooked question is about sustainability and volume. During the mental health helpline project, our partners flagged something the team hadn't fully factored in: their call volume was too high for AI to be financially viable at that scale. "What is the volume of this thing? Is that the best choice in this use case?" Portable's response was to extend that thinking further: what's the smallest possible model that meets our minimum quality standards and has the lowest environmental footprint?

For Belinda, the missing question is structural: "At what point do we need human oversight?" She sees this as a critical thinking layer that teams routinely fail to design into their processes from the start. "What checks should we be putting in place to make sure this isn't hallucinating, that it's doing the job we want it to do?" The question isn't whether to have human oversight. It's how to design it in, at what stages, and against what criteria.

For Luke, the blind spot is stakeholder mapping. "Who are all of the stakeholders that need to sign off or be involved? IT teams, legal, investors. It's important to get buy-in and let them be heard from the very beginning." The problems this prevents aren't just political. A tool that's been through legal review from day one is a different, usually better, tool than one that hits legal review at the end.

"Human in the loop" has become a kind of reassurance phrase in AI implementation. Luke's experience suggests it's more complicated than that.

"Human in the loop is a fantastic guardrail in testing and iterating," he says. "But once the product is live, it's too late in most instances. Human in the loop is a function that needs to help prep and teach the guardrails, otherwise the chat has already happened and potentially already caused the harm."

This reframes the question. Human involvement that catches failures after the fact is less valuable than human involvement that shapes the conditions under which failures are less likely. Belinda describes a testing scenario where someone intentionally tried to sexually harass the AI, and the guardrail they'd designed for that case failed. "That's why we test prototypes," she says. "You need people giving the AI ridiculous scenarios to push the limits of the thing and make sure it actually does its job."

Another technique that emerged from this project: using a second AI to evaluate the outputs of the first. The team used a built-in assessor in ElevenLabs that allowed them to select a separate model to review the voice agent's responses against a set of defined criteria. "It flags failures, you go back to the model and try to fix it, then you go through the loop again," Deb explains. It doesn't replace human review. But it surfaces failures at a scale and speed that human review alone can't match.

Both approaches point to the same conclusion: build oversight upstream and into the process, not as a final check at the end.

Safe AI implementation needs clear human ownership. Someone has to be responsible for the quality, the safety, and the ongoing monitoring of what the tool is doing.

Belinda frames it as a management question: "If you had a human delivering this service, you'd have a manager for that human. Who is the manager of the AI? Who is making sure it's working as intended and keeping an eye on that?"

Deb describes how that oversight works in practice: start by reviewing everything, and as the system improves and trust is earned, shift to reviewing flagged interactions, then to random sampling. "It's like when you hire someone new." The oversight scales down as confidence builds.

For teams starting this process, the NSW Government's AI Assessment Framework, which Portable has used across multiple projects, provides a structured way to assess risks, compliance obligations, and ethical considerations before deployment. It's a useful scaffold for teams who don't yet know what they don't know, and is an example of what’s possible with governance and the sharing of best practice.

Luke adds one more dimension: make sure the right people are in the room when you're setting the criteria, not reviewing the outputs. "It's really important to surface and speak to what is making you nervous or creating concern. There are likely ways that the thorniest issues can be solved with specific ways of building and including criteria." The discomfort is the signal. Following it early saves significant trouble later.

When asked what scared them most, Deb, Belinda, and Luke gave different answers that point at the same underlying concern.

For Deb: "That it lets people down. That you allow people to fall through the cracks. You really don't want to cause distress and harm to people because you're relying on some efficiency tool."

For Belinda, the concern is longer-term. Patient-centred health is an emerging practice that's only just gaining ground across the industry, and she worries that premature or poorly governed AI in healthcare could reverse that progress. "I'm concerned that AI might move that work backwards." Her example is specific: an AI system that can't adapt to the context of a patient's full medical history, that just follows its programmed questions regardless of what someone tells it.

For Luke, as for most of us: what does the future of work look like? "I don't have a good answer to that."

None of these are reasons not to build. They're reasons to build carefully, with the right questions already in mind, and with the people most affected by these tools genuinely involved in the process.

The teams doing this well aren't waiting for certainty. They're building with the understanding that the work is iterative, that failures in testing are better than failures in production, and that stakeholders, including the people who will actually use these tools, need to be part of the process from the start.

What Portable's practitioners share across very different projects is a disposition, not a checklist. It comes back to classic human centred design practices of asking better questions earlier, testing in small, safe environments, and building in oversight. Bring in everyone who needs to be heard before anyone starts building. Name what makes you nervous and find ways to address it in the criteria, not after the fact. This is people-centred AI and mirrors the ways we’ve found success in over 20 years of business.

The question we're all still sitting with, the one Deb, Belinda, and Luke each named in different ways: what does this mean for work, for the people doing it, and for the people on the other end of the services AI is increasingly shaping?

We don't have a clean answer. We have a practice, and the conviction that asking the right questions early is the most useful place to start.