AI, Rust and the New Functional Safety Standards

Functional safety programmes change slowly, and for good reason. Evidence produced this year has to still be defensible in an assessment three years from now, so the discipline rewards teams who move deliberately. Three changes are arriving anyway, and none of them is waiting for your audit cycle.

The first is AI, which entered safety work from two directions at once: inside the development flow, as assistants that write and review code, and inside the product, as models that make decisions in the field. The second is Rust, which is being chosen for new safety-critical code that would once have defaulted to C or C++. The third is the guidance layer. The Perforce resources below cover standards titles concerned with artificial intelligence and functional safety, and a separate Perforce webinar reports on the state of the field for Rust guidelines and standards.

Waiting for all three to settle does not avoid the work, it defers it into a worse position. Teams accumulate readiness debt: code already written before there was a coding standard to enforce against it, tool decisions already made without qualification evidence to support them, and in some cases an AI component already in a product without a clear account of how its behaviour was verified.

Perforce has published five resources on exactly this ground, three on-demand webinars and two eBooks. They live on perforce.com, and some of them ask for a short registration form before playback or download. What follows is a guide to what each one covers and the order worth taking them in.

AI Has Entered the Safety Argument from Two Directions

The Perforce webinar page states the core difficulty plainly: “Traditional standards and deterministic processes used to verify and validate safety-critical systems often fall short when applied to AI models, which are inherently non-deterministic and continuously evolving.”

That sentence is the whole problem in one line. A conventional safety argument assumes that the same input produces the same output, that the behaviour space can be bounded and enumerated, and that a test suite passing today passes tomorrow for the same reason. A trained model challenges all three assumptions at once, and it does so whether or not your process documentation has been updated to notice.

It helps to separate the places AI actually appears, because they carry different obligations:

• In the toolchain. Assistants that generate, complete or refactor code. The question here is not whether the assistant is allowed, it is what qualified thing checked its output before that output became part of a safety-related build.
• In the development process. Requirements drafting, test generation, triage of static analysis findings. Useful, and the audit question is the same: who or what confirmed the result, and is that confirmation recorded.
• In the product. A model making decisions in the field. This is the case that puts real pressure on a deterministic verification argument, and it is the case the AI-specific standards titles below are concerned with.

The eBook AI Functional Safety covers where AI fits in development workflows, why it introduces functional safety challenges, and gives background on the AI-specific standards ISO/IEC TR 5469 and ISO 8800; the ISO catalogue lists those titles under artificial intelligence and functional safety, and road vehicles, safety and artificial intelligence, respectively. Treat those two titles as vocabulary you will need in your next safety review rather than as a checklist, and take the framing of what they mean for a working team from the Perforce material rather than from anyone’s summary of it, including ours.

The companion session is the on-demand webinar How to Safely Adopt AI in Safety-Critical Software Development, presented by Jill Britton, Director of Compliance at Perforce and a MISRA committee member. The eBook gives you the landscape. The webinar is the better starting point if you need to explain the problem to people who are not going to read an eBook.

Rust Changes the Starting Point, Not the Obligation

Rust reached safety-critical conversations on the strength of memory safety, and that strength is real. A whole class of defect that static analysis of C exists partly to hunt is absent by construction. The mistake is to read that as the safety case being smaller. It is differently shaped.

Language-level protection is one input to a safety argument. The rest of the argument is unchanged: requirements have to be complete and traced, verification evidence has to exist and be repeatable, the project’s own coding standard has to be enforced, and the tools producing the evidence have to be fit for that use. Removing a defect class does not remove any of those.

The eBook How to Address Functional Safety with Rust, subtitled “A Practical Guide for Rust Developers in Safety-Critical Industries”, covers Rust’s traction, what functional safety requires of a project, and where Rust offers benefits over C and C++. It is written for Rust developers moving into safety-critical work, which is the direction most of this traffic is travelling.

The webinar Addressing Functional Safety with Rust, also presented by Jill Britton, pushes the argument further. It looks at how Rust shifts functional safety away from meeting obligations through coding guidelines and toward meeting requirements more directly with the language itself, together with the tooling and evidence considerations that still follow from that. For teams who have already decided Rust is coming, this is the session that reframes what your process documents will need to say.

The third webinar covers the standards landscape. A State of the Field Report on Rust Guidelines and Standards is presented by Alex Celeste, Principal Software Engineer at Perforce, who maintains the C compiler and analyzer and the Rust analyzer for the Perforce QAC (formerly Helix QAC) toolchain and represents Perforce on the MISRA C, ISO C and Safety Critical Rust working groups. We cover this session in detail on our event page for the Rust standards webinar, so rather than repeat it here, read that alongside the recording at the link above.

What Does Not Change: Requirements, Verification, Evidence

Strip the language and AI shifts back and the spine of a functional safety programme is where it was. You state requirements. You verify against them. You keep traceability between the requirement, the code that implements it, the test that exercises it and the result. You show that the analysis and test tools you leaned on were suitable for the claim you are making with their output. An assessor’s questions do not change because your language did, and they do not change because part of your workflow now has a model in it.

Static analysis sits at a specific point in that spine. It is the mechanism by which a coding standard stops being a document and becomes an enforced property of the build, and it is the source of the compliance evidence that says so. That role is identical whether the code under it is C, C++ or Rust.

Which is where the tooling question becomes concrete for mixed codebases. Perforce’s what’s-new documentation states that QAC 2026.1 “introduces initial support for static analysis of Rust”, applying its deep dataflow analysis to Rust projects; the same page states “Analysis is provided by the QAC native Rust checks and the integrated third-party Clippy linter” and describes the support as maturing in the 2026.2 release. Initial means initial. This is the start of a Rust capability in a toolchain whose C and C++ analysis carries TUV SUD certification for use in safety-related development, and it should not be sold or bought as parity with those engines. What it does offer today is one analysis and reporting path across a codebase where new Rust sits next to long-lived C, which is the shape most real programmes are in rather than the greenfield-Rust shape the conference talks assume.

Static analysis is also only half of a shift-left pair. The other half is dynamic unit testing on the target, with structural coverage to show the tests reached the code. That pairing is why teams run QAC alongside Razorcat Tessy, and the logic of it is unaffected by which language the units are written in.

Where to Start, Depending on Where You Are

Five resources is more than most team leads will get through in one sitting. Pick by situation:

• Someone in your organisation has already shipped or approved an AI component. Start with the AI Functional Safety eBook for the standards vocabulary, then the AI adoption webinar to take the argument to the people who made the decision.
• You are still deciding whether Rust belongs in your next programme. Start with the Rust functional safety eBook. It is the one that addresses the benefits-over-C-and-C++ question directly, which is usually the question being asked.
• Rust is already committed and you need to know what you will be assessed against. Go to A State of the Field Report on Rust Guidelines and Standards, with our event page as the summary to circulate.
• Your question is immediate and about tooling. Skip to the QAC Rust support position above, and treat it as an early capability to pilot on a real module rather than a box to tick in a comparison sheet.
• You are the person who has to update the process documents. The Rust webinar is the one that speaks to where the obligations move.

Where GSAS Fits

GSAS Micro Systems is the authorized Perforce engineering partner in India.

That means the practical work around these resources, not the resources themselves. Evaluation licences arranged and set up on your codebase rather than on a demo project. Onboarding that gets the analysis into your build and your CI pipeline instead of leaving it as a desktop tool one engineer runs before a review. Training for the team that has to live with the findings, and help constructing the compliance and qualification evidence in the form an assessor expects to receive it.

Our engineers work with automotive, aerospace, medical device, railway and industrial teams across Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR, which means the person who helps you scope a Rust pilot or an AI-in-the-toolchain policy is in your timezone and can be in your office.

More on the relationship is on our Perforce partner page, and the tool detail sits on the Perforce QAC product page. If you want a scoped conversation about what any of this costs and how long it takes on your codebase, request a quote and we will start with your code rather than with a price list.