Safety Technology Innovation: Build It In

I'm Kurt Schmidt, founder of Schmidt Consulting Group, and I've spent years watching organizations treat safety the same way they treat compliance paperwork: something you deal with after the real work is done. That instinct is understandable. It's also increasingly expensive. The conversation on safety technology innovation I've been tracking closely through my work with engineering and product teams makes one thing clear. The firms that figure out how to design safety in from the start are pulling ahead, and the ones that bolt it on at the end are the ones hitting certification walls right before launch.

This post is about how that shift happens practically, why the robotics and AI agent space is forcing the issue faster than any regulator could, and what B2B product and services firms should understand before their next development cycle.

What Does "Safety Technology Innovation" Actually Mean for Modern Product Teams?

Safety technology innovation is the practice of building risk identification, hazard mitigation, and validation testing into the core product development process rather than treating them as a downstream quality gate. It's the difference between designing a cliff-detection system for a home robot at the same time you design the motor controller versus discovering you need one during final QA.

That distinction sounds simple. In practice, it restructures who is involved during design, what tools the team uses to track requirements, and how often the system gets tested as it evolves. I've talked through this with engineers who've worked at both the startup and enterprise levels, and the consensus is consistent: once a product's control system reaches a certain level of complexity, a bolt-on safety layer becomes the performance ceiling. Amazon learned this internally. When you're managing a million-plus workers alongside fleets of autonomous robots, a reactive approach to safety stops scaling almost immediately.

The definition matters here because "safety" in this context covers at least three distinct surfaces: physical robotics (torque limits, collision detection, emergency stops), functional safety in the software layer (sensor fusion reliability, state machine validation), and increasingly, AI agent outputs that feed downstream systems. A hallucinated value from a data-processing AI agent that flows into a robotic actuator's decision loop is a safety event, even if no physical robot is visible on screen. Teams that understand all three surfaces are the ones building systems that can actually be certified.

Why Are AI Agents Now Considered a Robotics Safety Risk?

An AI agent processing a spreadsheet doesn't look like a robot. But if that agent produces values that feed into a physical system. A factory floor controller, a logistics routing algorithm, a humanoid robot's path planner. Any error in that output propagates downstream. The chain from software hallucination to physical harm is shorter than most people realize.

I've been following the evolution of how safety engineers think about this, and the framing that makes the most sense to me is treating any AI agent as a software robot. It has inputs, logic, and outputs. Those outputs carry consequences. Once you accept that framing, you apply the same structured risk quantification you'd use for a physical system: identify hazards, define safety functions, specify requirements, design to those requirements, then test and validate. The V-model development process. Where you trace every requirement from concept down through design and back up through verification. Applies regardless of whether your system has wheels.

The regulatory environment hasn't caught up. We see congressional testimony about large language model safety, but the specific intersection of AI agents and physical robotics has almost no prescriptive regulation yet. That's a window. Companies that establish rigorous internal safety processes now, before regulators mandate them, will have a structural advantage when certification requirements arrive. They'll also avoid the scenario that killed widespread autonomous vehicle adoption: one high-profile safety failure that freezes an entire product category. Waymo and Tesla have shown the technology works. The reason fully autonomous personal vehicles aren't in your driveway yet is a safety confidence problem.

How Do You Quantify Risk Instead of Just Avoiding It?

Risk quantification is the analytical alternative to the two failure modes most organizations fall into: ignoring risk entirely or becoming so averse to it that they can't ship anything.

The framing I find most useful comes from thinking about risk the way a good actuary does. The question is never "could this go wrong?" Everything can go wrong. The question is: what is the probability, what is the severity of the outcome, and what mitigation reduces the risk-exposure product to an acceptable level? Standing in Ohio and calculating your shark-bite probability before breakfast is a low-risk morning. Deploying a 200-pound humanoid robot in a warehouse without a formal hazard analysis is a different situation entirely.

For product teams, quantification means moving through a defined sequence. First, enumerate hazards systematically. Not just the obvious ones, but the edge cases that emerge from combinations of conditions (low lighting, new sensor firmware, a child placing an obstruction in front of a cliff-detection sensor). Second, assign each hazard a risk level based on probability and severity. Third, define safety functions that bring each hazard below the acceptable threshold. Fourth, decompose those safety functions into verifiable requirements that can be tested. Fifth, run the tests. Sixth, re-run them every time something changes. Because in a modern AI-enhanced product, things change constantly.

The analogy I've heard that resonates with non-engineers is TurboTax for safety. TurboTax guides you through a complex, standards-driven process with structured prompts, prevents you from skipping required fields, and produces an output that can be reviewed by a third party. The difference with a full-lifecycle safety platform is that the auditor runs continuously rather than once a year.

This connects directly to and how firms structure their value proposition around a process advantage rather than a feature advantage.

Who Needs to Be Involved When Safety Gets Designed?

The biggest structural mistake I see is treating safety as the safety engineer's job. It isn't. Safety outcomes are produced by mechanical engineers, electrical engineers, firmware developers, product managers, UX designers, and operations staff collectively. A safety system designed only by the safety team will miss failure modes that are obvious to anyone who has actually operated the machine.

The challenge is that most of those contributors find safety documentation tedious. And honestly, that's a reasonable response to how safety processes have historically been designed: dense standards documents, arcane notation, and a workflow that feels disconnected from what the team is actually building. The UX of safety tooling has been an afterthought for decades.

Getting cross-functional participation requires making the process one people actually want to join. That means interfaces that translate safety analysis into language electrical and mechanical engineers recognize, that surface relevant requirements based on what the team has already defined, and that make it immediately obvious when a design change invalidates a previous safety assumption. When the tool does that well, safety stops being a gate at the end and becomes something people want to engage with during design. Because it's giving them useful feedback in real time.

I've seen this active play out in healthcare organizations too. Prevention only becomes a daily practice when the tools make it as easy as checking an Oura ring rather than scheduling a quarterly review. The gamification principle applies here: if the safety process surfaces useful information frequently and makes people feel like they're moving forward rather than filing paperwork, adoption follows. See also cross-functional team design for how this applies to services firm delivery teams.

How Does Third-Party Certification Actually Work for Robotics and AI Systems?

Third-party certification is how the market establishes trust in a product's safety independently of the manufacturer's claims. You've seen the UL mark on electronics. That stamp means a Nationally Recognized Testing Laboratory (NRTL) reviewed the product against a defined standard and found it compliant. The NRTL has no financial stake in whether the product sells. That independence is what makes the stamp meaningful.

For robotics, the relevant standards include IEC 61508 (functional safety of electrical and programmable systems), ISO 13849 (safety of control systems), and IEC 62061, among others. These are type A, B, and C standards with different levels of prescriptiveness. Type C standards are very specific to product categories; type A and B standards are more architectural, which means they provide enough latitude to cover diverse technologies. A drone, a humanoid robot, a home cleaning device. Without requiring a complete process overhaul every time the specific type C standard is updated.

The strategic implication is real. A safety process built on type A and B standards is more durable than one built to satisfy a specific type C requirement that may change next year. This matters particularly for AI-enhanced products, where the underlying model or sensor suite may update on a continuous basis. A validation framework designed around architectural principles rather than prescriptive checklists can absorb those updates without triggering a full recertification cycle from scratch.

For teams engaging third-party certifiers, the traceability of your safety case matters enormously. Certifiers want to see a clear chain from hazard identification through requirement definition, design, and test results. If that chain exists in a structured platform rather than scattered across SharePoint folders and email threads, the certification review moves faster. I covered related forces in how B2B firms structure their delivery quality systems on The Schmidt List.

What Can Startups Learn From How Large Organizations Incubate Safety Innovation?

Large enterprises maintain things well but struggle to innovate quickly. Startups innovate quickly but struggle to scale past the first inflection point. Getting from zero to one is a startup's native skill. Getting from one to two. Building the processes, the teams, the institutional knowledge that turn an innovation into a repeatable product. Is a different challenge that requires different people and a different operating model.

The pattern I find most instructive from the Amazon case is the concept of incubation with proof-of-value gates. A small, agile team takes an identified internal need, develops a solution at startup speed, and demonstrates value in a real operational context. Each gate requires proving the concept again, often to increasingly senior stakeholders. The pressure is real. But each successive proof-of-value round builds the institutional confidence that eventually opens the decision to take the technology to market.

What made that process work in this case was alignment across a technical management chain that could evaluate the work on its merits, combined with a legal and licensing path that gave all parties a clean outcome. Enterprise innovation partnerships don't always end with the startup retaining the IP and the enterprise becoming a strategic partner; that outcome requires both good execution and specific organizational conditions that are genuinely rare.

For founders and intraprenuers inside large organizations: the approach that consistently works is following every rule while pushing every idea as hard as possible within those rules. Shortcuts through policy create legal exposure that kills deals at the finish line. And the discipline of working within constraints often improves the output. You end up building something that can survive due diligence because it was built with diligence from the start.

If you're a small firm looking purely at demand generation rather than embedded innovation partnerships, a specialist B2B demand generation strategy may be a better fit than the structured enterprise co-development model described here.

Refer to the IEEE Robotics and Automation Society for ongoing standards developments and technical publications on functional safety in robotics systems.

Key Takeaways

• Safety technology innovation is the practice of building hazard identification, risk quantification, and validation into the product development cycle from the first design sprint. Parallel to control system development rather than downstream of it.
• AI agents carry the same risk surface as physical robots when their outputs feed into systems that affect humans. A data-processing agent that halluccinates and produces a bad value downstream is a safety event.
• Risk quantification asks three questions: what is the hazard, how probable is it, and how severe is the outcome? Mitigation is calibrated to that product, not to a blanket standard of risk avoidance.
• Third-party certification (UL, NRTLs, IEC 61508 compliance) establishes consumer trust independently of the manufacturer. Building to type A and B standards provides durability when specific type C standards update.
• Cross-functional participation in safety design. From electrical engineers to product managers to operations staff. Is the structural requirement that most teams get wrong. The safety team alone can't see all the failure modes.
• Enterprise innovation partnerships work when the agile team follows every rule while proving value at each gate. The discipline of operating within constraints is what makes the deal survivable at the legal and licensing stage.

The open question that I think will define the next five years: as AI agents become embedded in more physical systems, who owns the safety case when the model updates mid-deployment? The answer isn't settled, and the teams building the answer right now are the ones to watch.