What the Online Safety Act Means for Platform Safeguarding Architecture

But flexibility creates risk. Without a clear framework for what good safeguarding architecture looks like, organisations default to what's measurable and defensible: policies documented, tools deployed, assessments completed.

Here's the uncomfortable truth: you can be OSA-compliant and still have safeguarding systems that fail under real-world pressure.

A risk assessment is a document. It describes risks that might exist and measures that might address them. It doesn't tell you whether those measures actually work when a grooming pattern emerges at 2am on a Saturday.

Age assurance reduces some risks by keeping younger users off platforms or away from certain features. But it doesn't eliminate risk. Determined bad actors work around age gates. Users who pass verification can still be harmed. The question of what happens after someone gets through the front door remains.

Content moderation scales policy enforcement. But as I've written elsewhere, enforcement engages after a breach has occurred. The safeguarding question: is this situation developing in a dangerous direction? requires different systems and different capabilities.

If you're responsible for safeguarding at a platform subject to the OSA, here's what I'd prioritise beyond baseline compliance:

First, understand where risk actually forms in your system

Not where policies say it should be managed; where it actually enters and compounds. This usually happens earlier than enforcement systems engage. Account creation, early interaction patterns, permission settings, behavioural changes over time. The Front Door Theory framework provides a structured way to think about this.

Second, examine your escalation pathways

When something concerning is identified, what happens next? How quickly does it reach someone with authority to act? Where does information stall or get lost? Most safeguarding failures aren't caused by absence of policy, they're caused by escalation systems that don't function under pressure.

Third, be honest about the AI-human handover

'Human in the loop' is a phrase that appears in many risk assessments. But at what point does human judgement actually engage? Is that point appropriate to the risk? Can your human reviewers actually make the decisions they need to make with the information and authority they have?

Fourth, stress-test your systems

Not through audits or document reviews; through realistic scenarios that test whether your architecture holds. What happens when multiple concerning signals emerge simultaneously? When a case falls between policy categories? When the person who usually handles escalations is unavailable?

The OSA creates baseline expectations. Meeting them is necessary. But it's not sufficient if your goal is actually protecting users rather than demonstrating regulatory compliance.

The organisations that will navigate this well are those that treat the OSA as a starting point - a floor, not a ceiling - and invest in understanding how their safeguarding systems actually function when things go wrong.

The ones that will struggle are those that treat compliance as the destination, document their way to adequacy, and discover the gaps only when a serious incident exposes them.