OpenAI's Teen Safety Push: Good Intentions, But Where's the Engineering?

I called my old colleague at Siemens last week about something unrelated, and we got talking about safety standards. He reminded me that in industrial automation, ISO 10218 doesn't give you a blueprint. It gives you requirements. Measurable ones. Maximum force limits. Response times. Test procedures.

What I'm not seeing in OpenAI's announcements is the engineering specifics. How do you actually verify a teenager's age? (Remains unclear, and frankly it's a problem nobody's solved.) What content gets blocked and what doesn't? Who decides? How do you test whether your safety system is working?

The teen safety blog post talks about balancing safety, freedom, and privacy. Which, sure, that's the tension. But it's also the kind of statement that could mean almost anything depending on implementation.

I'm not saying OpenAI is being cynical here. I genuinely think they're trying to get ahead of regulatory pressure and do the right thing. The EMEA grants suggest they're putting actual money behind this, though I couldn't find exact figures for the total commitment.

What This Means for Robotics

Here's why I'm writing about this at all. The robots coming out of Boston Dynamics, Figure, and the rest are going to have AI systems talking to kids. Home robots, educational robots, companion robots. It's coming faster than people think.

When that happens, we're going to need safety standards that combine the physical safety engineering I spent my career on with whatever OpenAI is figuring out for AI interactions. And right now, those two worlds aren't talking to each other much.

The developer guidance OpenAI released is a start. Prompt-based safety policies that developers can implement in their own systems. That's the kind of practical tool that might actually get used. But it's based on prompts, not architecture. It's a layer on top, not built into the foundation.

I've seen that approach before in industrial settings. Bolt-on safety systems instead of inherently safe design. Sometimes it works fine. Sometimes it doesn't.

The Bottom Line

OpenAI deserves some credit for publishing these frameworks publicly rather than keeping them internal. The regional adaptations (Japan, EMEA) suggest they're at least thinking about different regulatory contexts. The developer tools are, well, tools.

But I'd feel better about all this if I saw more specifics. Test results. Failure modes. What happens when the safety system doesn't work? In my world, we had to answer those questions before shipping anything.

It's too early to say whether these blueprints will become industry standards or just marketing documents. I suspect the answer depends on whether regulators start demanding something more concrete. Until then, it's good intentions and reasonable principles, which isn't nothing. It's just not engineering.

Mark Kowalski · 1 hour ago · 5 min