RiverSafe in conversation with Sapna Patel, Technology and Cyber Leader, Board Advisor

Guardrails only work if people understand them

Sapna is clear that governance cannot be a documentation exercise. Policy and training need to be understood, not just issued. “You don’t want to issue training and awareness and policies if nobody’s understanding of it. Who’s going to stick to it?”

On the technical side, she points to a set of controls that make a genuine difference: non-human access control keeping AI agents segregated from each other and other systems, analytics on what the AI is doing, a response plan prepared before something goes wrong, and reducing AI exposure to personal data and external interactions where possible. That last point covers both reputational risk from misinformation and vulnerability to prompt injection or model poisoning.

Security by design, not bolted on at the end

A pattern Sapna sees repeatedly is governance being added after the fact.

“A lot of people kind of let the train leave the station and then go: oh, you should have some governance around that. And at that point we’re a little bit late.”

The fix is the same one the security community has advocated in software development for years: get the right people involved early. Security professionals need to be asking governance questions before architecture decisions are made, not after. Policy and training should make clear that secure by design and privacy by design apply to AI just as they do everywhere else. Doing it at pace makes this harder. AI moves faster than most governance cycles, and Sapna has revised her organisation’s maturity metrics every couple of months to keep up.

How to benchmark maturity

Sapna suggests a matrix view across a few core dimensions: data governance markers, intended access levels of AI and whether it is staying within them, data accessibility including personal data, visibility into each AI component’s behaviour, recovery capability, and supply chain AI maturity. That needs tailoring to the organisation and revisiting regularly.

Culturally, she looks for signals that governance has genuinely been thought about rather than performed. Certifications help, though meaningful AI governance certification is still relatively new. A more basic indicator: does the privacy policy actually say something about how AI handles data? At board level, AI risk should be on the agenda, though she acknowledges many organisations are not there yet.

“It should be, but maybe it isn’t so widely at the moment because a lot of organisations are still on the early stages of their journey.”

Ethical guardrails cannot be assumed to hold

Translating ethical principles into something engineers can build against is genuinely difficult. Topics can be made off-limits, training data can be restricted, and scenarios can be constrained. But the gap between intention and behaviour is real.

Sapna raises a harrowing example involving an AI system that displayed the required safety warning when a vulnerable user raised the topic of suicide, and then continued the conversation as if it had not happened.

“The warning message came up, the particular script that’s meant to be invoked was invoked. And the model then said: yes, that’s going to come up, but don’t worry, I’m still here with you.”

The guardrails were in place in theory. In practice, they did not hold. The only way to know whether ethical constraints are actually working is to test them. “You’d have to involve your red team in pentesting, in testing some of the functionality, just to stay on top of it. Just to stay aware of the ethical guardrails you think you’ve put in place, but can never be sure of.”

Sandboxes help, but they are not a shortcut

For large organisations developing AI internally, a proof-of-concept sandbox is worth having. But it does not replace governance conversations, and it can slow delivery if those conversations have not happened first. “Even if your proof of concept is successful, you may have to rework a lot of things.” For organisations buying rather than building, sandbox control over the vendor’s model is not available anyway.

Closing thought

“Governance in general is about everyone understanding why, and the extent of it, why it’s needed.”

That is Sapna’s parting point, and it holds across all three episodes. The technical controls, the frameworks, the testing cadence: none of it works without a genuine shared understanding of what the risk actually is and who is responsible for it.

This is part three of a three-part series drawn from RiverSafe’s Secure in the Knowledge podcast. Part one covers real-world AI incidents and the limits of human oversight. Part two looks at why AI governance keeps falling through the gap.