According to the Ministry of Industry and Information Technology, on July 30, 2026, the MIIT organized the formulation and released the mandatory national standard Safety Requirements for Autonomous Driving Systems of Intelligent Connected Vehicles (GB 44721—2026), which was approved by the State Administration for Market Regulation and the Standardization Administration of China. The standard is set to be officially implemented on July 1, 2027.

So, what does the release of this standard mean? What are its requirements for autonomous driving products? What needs to be implemented in product development? What potential challenges might arise? What impact will it have on the development of autonomous driving?

This article interprets the GB_44721-2026 standard from the perspective of an autonomous driving industry practitioner, aiming to provide information and general knowledge.

First, the Nature of the Matter Has Changed

In fact, there was an old version of the L3/L4 regulations called GB/T 44721—2024, where the “/T” stands for “recommended.” In plain terms: the state suggests you “do it this way,” but it's okay if you don't.

Now, the “/T” has been removed in the new version. In plain terms: if you claim your vehicle is L3/L4, you must meet this GB national standard; otherwise, your vehicle cannot be approved for sale.

This is the essential difference. Over the past two years, L3 road tests across various regions, including the two conditional approvals obtained by Changan SL03 in Chongqing and ARCFOX Alpha S in Beijing in 2025, were all based on that “recommended” version. Starting from July 2027, it becomes a hard requirement. It also indicates that starting from July next year, there will be vehicles that can openly claim to be L3/L4 autonomous driving cars.

From a regulatory perspective, the requirements of this regulation are:

In the past, it was “you prove the car can drive.” Now, it's “you prove the car won't crash, and you must prove you have the capability to consistently prove this.”

The latter part is where the real difficulty lies, as we will discuss later.

Scope of Application: Passenger vehicles and freight vehicles equipped with L3 and/or L4 systems. Automatic parking is not included.

So, what exactly are the requirements?

The standard spans 62 pages, which I will break down into several sections.

Section 1: The Car Must Be Able to Drive (Chapter 5)

This chapter sets the “passing grade” and is relatively abstract, with a core message in one sentence:

“The safety level of the ADS should at least match that of a qualified and attentive driver.”

Note the wording—not an “average driver,” but a “qualified and attentive driver,” meaning someone who is sober, not looking at their phone, has sufficient driving experience, and is in good condition. This benchmark is set quite high.

The requirements are then expanded upon in four scenarios: when everything is normal (nominal scenarios), when dangers are encountered (risk scenarios), when the system fails (failure scenarios), and when operating outside the designated range (non-compliance with ODC).

Among these, there are three points that practitioners need to pay special attention to:

① You must account for the unseen. (5.1.2.4) The standard explicitly requires reasonable control strategies for “undetectable areas”—blind spots inherent to sensors, areas blocked by other vehicles, or obscured by curves and slopes. In plain terms: if a large truck blocks your front-right view, you cannot pretend nothing is there. This directly incorporates occlusion reasoning, a topic discussed in academia for years, into the regulation.

② For L4, there is no retreat when it comes to police cars and traffic police. (5.1.2.10, 5.1.2.11) When encountering police cars, fire trucks, or ambulances on duty, or traffic police giving hand signals at intersections—L3 can choose to “yield or request driver takeover,” but L4 can only yield and must follow the traffic police's hand signals. There is no option to say, “I don't understand, you take over,” because L4 fundamentally lacks a “you.”

This is a typical long-tail perception task, now made mandatory.

③ After stopping once, you must restart. (5.1.6.1) If the L3 system executes an MRM (i.e., “I can't drive anymore, I'm pulling over”), the vehicle must restart the powertrain before autonomous driving can be reactivated after coming to a stop. It cannot stop, recover, and continue driving automatically.

This is already the practice for current L2++ systems, so there is no significant difficulty in compliance.

Section 2: L3 on Highways—Down to the Decimal Point (Appendix B)

These 12 pages contain the most detailed engineering specifications in the entire document. The earlier sections are relatively abstract, but here, it's all about numbers.

First, let's talk about perception range.

The standard employs a clever and stringent design: the faster you want to go, the farther you must see. Moreover, to exceed 60 km/h, there's a prerequisite—the vehicle must have a deceleration capability of at least 5 m/s².

What does 130 meters mean? At 120 km/h, 130 meters is where you'll be in 3.9 seconds. Roughly 30 vehicles lined up bumper to bumper.

But more critical is the definition of “detection range.” The standard clearly states: it refers to the distance at which targets can still be reliably identified, and control signals generated based on that, even after accounting for sensor aging and degradation over the vehicle's lifetime due to time and use.

In plain terms: it's not the “maximum detection range of 200 meters” on your spec sheet. It's the distance you can still rely on for decision-making after the lens has accumulated dust, been in use for eight years, and the coating has worn off a bit.

Additionally, if your system can change lanes, it requires coverage of at least 9 meters to the left and right of the vehicle's centerline, forward, lateral, and rearward. Nine meters is roughly two and a half lanes, meaning you must be able to see vehicles one lane over.

Now, lane changing. This is, in my opinion, the most challenging part for large model data teams or rule-based planning and control teams.

You're on the highway and want to change lanes to the left. You glance back left and see it's clear. Can you change lanes?

The standard says: no, you can't think that way.

It requires you to assume—the vehicle you didn't see is right at the edge of your rear perception capability, and it's going 30 km/h faster than the road's speed limit. (B.1.2.3.2.2)

You must calculate based on this assumption. After calculating, you must ensure that after changing lanes, the other vehicle doesn't need to brake harder than 3 m/s², and it maintains a following distance of at least 1 second from you at all times.

What's the impact of this? It locks “whether you can change lanes” to “how far you can see behind you.” If your rear perception isn't far enough, you don't qualify to change lanes on this road. Either add hardware or honestly reduce the maximum speed in your ODC. This is a clear cost/capability trade-off point, and the sooner you decide, the better.

By the way: activating your turn signal 3 seconds in advance can reduce your safe distance requirement from 1.4 seconds to 0 seconds. This is a clear “good behavior reward” given by the standard, and it's very much worth utilizing in planning and control.

There are also several scattered but must-implement requirements: during lane changes, additional lateral acceleration must not exceed 1 m/s² (centrifugal force from curves doesn't count); deceleration commands during lane changes must not exceed 2 m/s²; if the distance to the vehicle behind is already tight, no additional braking force is allowed within 2 seconds after completing the lane change.

Cutting off and being cut off by others.

The standard provides a formula to define “under what circumstances you must avoid colliding with a cutting-in vehicle”:

TTC > V rel/12 + 0.35

The 12 represents 2×6, implying a braking capability assumption of 6 m/s². The TTC timer starts very precisely: the moment the front outer edge of the cutting-in vehicle's front wheel crosses the outer edge of the lane line by 0.3 meters. It also requires at least 0.72 seconds of identifiable lateral movement time—too sudden a cut-in isn't your responsibility.

For pedestrians, the requirement is unconditional. (B.1.1.9) An unobstructed pedestrian crossing at no more than 5 km/h (normal walking speed), with the predicted collision point within ±20 cm of the center of your vehicle's front—you must avoid the collision. No ifs, no unlesses.

The rhythm of takeover requests.

The timing design here is quite interesting and worth examining closely:

For takeover events that can be anticipated in advance (e.g., exiting the highway at an upcoming ramp, going out of the ODD), how early must the intervention request be? Early enough that “even if the driver completely ignores you, the MRM can bring the vehicle to a stop before the event occurs.” This requirement is quite aggressive.

After the request is issued, it must escalate (louder, more urgent) no later than 4 seconds, and if the vehicle is still moving after escalation, continuous or intermittent vibration prompts must be added.

From the issuance of the request to termination due to MRM, at least 10 seconds must be given for the driver to react.

However, in cases of severe failure, direct MRM without a request is allowed—because there's no time.

MRM deceleration must not exceed 4.0 m/s², and the hazard lights must remain on (replaced by turn signals during lane changes, then switched back to hazard lights afterward).

Section 3: L3 Vehicles Must Monitor the Driver (Appendix A)

This section is only four subsections long, but each one could require significant changes to your hardware BOM.

① Seatbelts cannot rely solely on the buckle switch. (A.2.1) The standard requires that determining whether the driver has fastened their seatbelt must involve at least one method “other than the buckle.”

Why? Because everyone knows the insert can be plugged in separately while the person sits on top of it. So you need to use a camera, or a tension sensor, or a pressure sensor. This is a new component. However, it's now commonly handled with an in-cabin camera.

② If the driver is not in their seat for more than 1 second, a takeover request must be issued. (A.3.2)

③ This one is the toughest: at least two independent indicators, each making its own judgment, with a 30-second cycle. (A.4.1)

The standard requires you to use at least two effective indicators to independently confirm that the driver had takeover capability within the last 30-second cycle. Indicators can include eye movement, head movement, body movement, specific interactive operations, voice, physiological characteristics, etc.

The key is in the latter part: if fewer than two indicators can be monitored, it is also considered “no capability.”

Think about when this might apply: the driver is wearing sunglasses (eye movement is useless), nighttime infrared interference, the face is covered, hands are off the wheel while the head doesn't move... Anytime your DMS drops to only one signal, the system must consider the person unreliable.

④ From “prompt” to “takeover request,” a maximum of 15 seconds. (A.4.2) If the person's state is detected as incorrect, a prompt must be issued immediately (and this prompt must be clearly distinguishable from all other prompt sounds in the vehicle), continuing until the person recovers or escalating to a takeover request—this escalation must not occur later than 15 seconds.

Combined with a requirement from Chapter 5: determining that “the person is ready to take over” requires at least simultaneous satisfaction of hand on the wheel + gaze in the driving-related area for a sufficient duration. Both are required. And if gaze monitoring is temporarily unavailable, you must clearly state in the safety documentation what substitute (replacement) is used.

Section 4: Additional Homework for L4 (Appendix C)

The capability list is mandatory. If the ODD is only highways and urban expressways, at least the following must be supported: lane cruising, lane changing, and obstacle avoidance by borrowing lanes. If the ODD includes other roads (i.e., urban areas), at least the following must be supported: lane cruising, lane changing, intersection navigation, obstacle avoidance by borrowing lanes, reversing, and U-turns.

Including reversing and U-turns in the mandatory list indicates that regulators are thinking about true driverless operations, not just highway shuttles.

If the vehicle allows standing passengers (think Robobus), acceleration and deceleration must not exceed 2.4 m/s², and the rate of change must not exceed 5.0 m/s³. This constraint will significantly impact operational efficiency, so those working on bus scenarios should take note.

The section on remote assistance is quite particular. The core message is threefold: you must not rely on remote assistance to execute driving tasks (C.2.1.2)—remote assistance can only “help,” not “take over and drive”; during remote assistance, the steering is still controlled by the ADS, and the vehicle is still driving itself, not having remote direct access to the throttle pedal; the communication state must be self-detected (signal strength, latency, jitter), and MRM must be initiated when connectivity is lost.

This effectively eliminates an entire category of business models—those relying on “remote driving cockpits as a fallback” cannot be used as a basis for safety arguments under this standard.

There's also an easily overlooked requirement: after stopping, the vehicle must not move again until it confirms that “the reason for the initial stop has been resolved.” (C.1.4.3)

Section 5: You Need a “System” (Chapter 6)

This chapter doesn't discuss the vehicle but rather the autonomous driving system.

It requires you to establish and operate an SMS (Safety Management System) with seven modules, none of which can be omitted: safety policy, risk management, safety assurance, safety improvement, design and development management, production management, and post-deployment safety management. It also requires KPIs to measure system effectiveness, supply chain agreements, and regular independent internal and external audits.

Then there's Section 6.2.1. I believe this is the most underestimated section in the entire document.

It discusses “simulation test conditions,” but what it's really asking is not whether your simulator is good to use, but why your simulator can be trusted.

Requirements include: code verification (static analysis, dynamic analysis, convergence analysis), numerical error estimation (discretization error, rounding error, iterative convergence error), sensitivity analysis (which inputs have the greatest impact on results), statistical consistency proof between simulation outputs and real-world results, uncertainty quantification, and even requiring you to clearly separate aleatoric uncertainty (inherently random things, like road surface adhesion coefficients) from epistemic uncertainty (things you haven't figured out, like errors from model simplification).

Also, if your simulation involves random numbers, you must be able to deterministically reproduce the same run; if you can't, you must demonstrate that this uncertainty does not affect credibility. The qualifications and training records of those who develop the simulator, those who evaluate it, and those who conduct experiments with it must all be documented.

The prototype for this framework does not come from the automotive industry. It is more akin to NASA's standards for model and simulation credibility.

Most of the current simulation platforms for domestic passenger vehicle teams are at the stage of 'being able to run scenarios.' The gap between 'being able to run scenarios' and 'being able to serve as admission evidence' is measured in person-years. Moreover, buying commercial software won't solve the issue—the standard does not assess the tools but your understanding and justification of them. Suppliers cannot write the sensitivity analysis conclusions for you.

Section 6: Safety Dossier—A Defense (Appendix D)

This is the longest appendix in the document, spanning 17 pages.

Its structure is quite similar to a Ph.D. thesis defense: you present a series of claims, each supported by arguments, and each argument is backed by evidence. Moreover, you must be able to trace from 'a specific requirement in the standard' all the way to 'a specific piece of data from a specific test,' with traceability in both directions.

Several key figures require attention.

① ASIL classification is rigidly assigned. (Table D.1)

The standard directly lists 11 categories of vehicle hazards and their corresponding ASIL levels. ASIL D represents the highest level of automotive functional safety, implying the most stringent development process, the highest diagnostic coverage, and typically redundant hardware.

Another perspective—these 11 hazard categories are not abstract; when grouped by physical properties, they are distributed across four directions of the vehicle:

Those receiving ASIL D include: unexpected lateral motion, unexpected loss of lateral control, unexpected acceleration, loss or reduction of active deceleration capability. Additionally, 'MRM loss or error' for L4 is also D (L3 only requires B); 'non-response to driver intervention' for L3 is D (L4 may not assign this, as it does not rely on the driver at all).

Two architectural red lines accompany this, seemingly simple but costly:

No single electronic or electrical fault should cause complete loss of active steering, active braking, or active parking capabilities (D.2.4.2.5).

For L3, no single fault should cause complete loss of alerting capabilities (D.2.4.2.7)—the auditory, visual, and vibration channels cannot all be disabled by the same fault, implying redundancy in alerting channels.

② The threshold for residual risk is the most critical figure in the document. (D.2.3.1.3)

The standard provides a reference algorithm: to prove that 'the collision accident rate is below 1 in 10,000 per hour,' you need to accumulate 16,000 hours of operation without incident, giving you 80% confidence that the target is met.

16,000 hours sounds manageable? If a vehicle operates 10 hours a day, that's 1,600 days, or four and a half years. With a fleet of 50 vehicles, it could be done in four months.

But 16,000 hours corresponds to the most lenient tier.

You must also prove that the fatal accident rate is below 1 in 10 million per hour. Using the same statistical logic, the scale jumps to tens of millions of hours. What does 10 million hours mean? 1,000 vehicles operating 24/7 for over a year. Moreover—every time you modify an algorithm version, theoretically, you must start over.

So this path is mathematically unfeasible. The standard knows this and leaves a loophole elsewhere: simulation, data-driven approaches, and shadow modes (D.2.6.4.9). You can use simulation mileage to offset real-world mileage.

But what determines the conversion ratio? It depends on how credible your simulation is.

Thus, it loops back to 6.2.1.

This creates a circular dependency, which I believe is the deepest threshold in the entire standard:

Your simulation credibility → determines your equivalent mileage conversion ratio → determines whether you can pass residual risk → determines whether you can gain admission.

Whoever establishes this closed loop first will accelerate their admission process by an order of magnitude. This is not a competition of algorithmic capability but of engineering systems.

③ The list of scenarios that must be covered. (Table D.2)

The standard provides a list of 'minimum scenarios to test,' with a few interesting entries:

Lanes without markings, broken markings, fading markings, lanes changing in number, construction zones, gantry frames, toll stations, height restriction barriers, irregular objects (water trucks, barrier vehicles), low-contrast targets, overturned or obliquely placed objects, pedestrians with umbrellas, electric two-wheelers with raincoats, and an entire category of 'user misuse': accidental activation, misuse after activation, failure to take over, erroneous takeover, erroneous exit.

It's clear that this list is derived from real accidents and complaints. Those working on perception will likely smile at the entries about pedestrians with umbrellas and electric two-wheelers with raincoats.

④ Another interesting requirement. (D.4) Before type approval, you must conduct an independence review, and the records must clearly state 'identified defects, areas with low confidence, and unclear aspects.'

In other words, the standard requires you to document your weaknesses and submit them. Concealing them is a risk.

Section 7: Three Gates (Chapters 7, 8, and 9)

The new standard's inspection system has three layers, evaluating not just the product but also the system documentation:

System inspection—assessing whether your company's SMS is reliable and whether your simulation/site/road test conditions are adequate. The SMS inspection report is valid for 3 years.

Dossier inspection—checking whether your safety dossier is complete (whether the claim-argument-evidence chain is bidirectionally traceable) and robust (whether residual risks are sufficiently low and evidence is reproducible).

Spot-checking and retesting—third parties conduct their own tests using simulation, site, and road methods. Moreover, inspectors can request your assistance in reproducing the evidence you submitted.

The third point deserves attention. This means you cannot simply submit 'beautiful data from past runs'—you must be able to rerun the same software version, tool version, scenario, and parameters to produce identical results at any time. This is a real test of engineering documentation capabilities.

Section 8: Any Change Requires Retesting (Chapter 10)

This chapter has the most significant impact on product and project management.

The standard lists a long series of factors that must remain 'identical' for the same type approval: sensor types, manufacturers, models, quantities, and installation locations; ECU manufacturer models and quantities; electronic and electrical architecture; ADS software architecture characteristics (explicitly including end-to-end model frameworks); human-machine interaction methods; MRM strategies; ODC; L3 takeover monitoring components, metrics, and thresholds...

Software versions are allowed to differ, but with a condition: 'without affecting ADS performance.'

These nine words represent the largest gray area in the entire standard and will be the most contentious battleground in the industry over the next two years.

Because—does retraining an end-to-end model count as 'affecting ADS performance'?

No one can answer this now. Companies must establish a change classification ledger: which level of modification can be directly OTA'd without affecting performance, which triggers supplementary inspections, and which requires full re-approval. This judgment standard can only be refined through repeated interactions with inspection bodies. It's advisable to start accumulating experience now, not waiting until 2027.

Another rule: ODC can only be narrowed, not expanded. (10.2) Road types can only be reduced, operating periods can only be shortened, maximum speeds can only be lowered, weather conditions can only become stricter, and lane types can only be reduced.

Want to expand ODD? Go through the inspection process again.

This directly conflicts with industry habits. The common approach is to 'launch in one city, expand to ten once it works, and gradually release firmware updates monthly.' Under the new standard, every 'release' is a compliance event.

Timeline

July 1, 2027—New models applying for type approval must comply.

August 1, 2028—Existing models with type approval must comply (by the 13th month).

There are 11 months until the first deadline.

Safety dossier preparation and SMS inspection typically take 12 to 18 months at a normal pace. If you haven't started yet, objectively speaking, it's already late.

So what exactly needs to be implemented?

For companies planning to deploy L3/L4 internally, I've outlined a responsibility checklist by team:

System architecture—redundant steering, braking, and parking (no single fault should disable all); ASIL D decomposition plan; L3 triple-channel redundant alerts; architectural justification for 'no hazard from a single perception fault.'

Perception hardware—derive detection range from target speed (120 → 130 meters); full omnidirectional coverage of 9 meters left and right for lane-changing capability; rear detection distance (directly determines lane-changing eligibility); calibration of usable range after aging and degradation; documentation of installation angle tolerances.

Planning and control—rear safety distance assessor, including the worst-case branch of 'not seeing the rear vehicle'; lane-changing A/B parameter logic; TTC formula for Entering the car (vehicle cutting in); MRM state machine (including MRM lane changes, turn signal and hazard light switching, MRC locking); preconditions for cross-lane collision avoidance; recognition and yielding to police vehicles and traffic officer gestures.

DMS/cabin—non-buckle-based seatbelt detection (new hardware); 1-second threshold for occupancy monitoring; dual-metric 30-second cycle capability assessment; 15-second sequence from insufficient capability to takeover request; 4-second escalation and vibration channels; dual-condition (hand on wheel + gaze) exit judgment.

Product/HMI—takeover request icon (must include graphics of hands and steering wheel); red flashing during MRM; and a complete user training and confirmation process:

Confirm driver training completion at every power-on (three options: in-person training and confirmation / biometric identification / stationary account login + password); provide a confirmation method for 'having read and understood the manual,' confirmable only when the vehicle is stationary and requiring a long press or at least two intentional actions (e.g., double-tap); if the manual is updated via OTA, reconfirm before next activation; if no confirmation occurs within 30 days, force reconfirmation before next activation.

Honestly, this framework is rigid in compliance but extremely counterintuitive in user experience. Poor implementation will be annoying, but non-compliance means ADS cannot be activated. Product teams must get involved early; this cannot be resolved with a 'last-minute popup.'

Testing/simulation—complete V&V package for the simulation toolchain (as discussed earlier, this is the largest piece); calibration records for site and road test equipment; toolchain documentation for evidence reproducibility.

Functional safety/SOTIF—HARA and ASIL justification per Table D.1; validation coverage for all trigger conditions in Table D.2; layered quantitative justification for residual risks; confidence justification for unknown hazard scenarios.

Quality/process—full SMS suite; post-deployment safety monitoring process (event reporting → investigation → risk assessment → countermeasures → effectiveness feedback); change impact analysis and regression strategy.

Legal/admission—safety dossier (8 submission categories + 6 reference categories); independent internal audit records before type approval; change boundary ledger for the same type.

Cloud—data Return Link (functional and performance requirements for collection, processing, transmission, labeling, and mining must be documented in the dossier); shadow mode; L4 remote assistance platform.

Several pitfalls, ranked by pain level:

1. Residual risk justification—a mathematical deadlock. As discussed, 16,000 hours only suffice for the most lenient tier, while fatal accident rates require tens of millions of hours. The only way out is simulation conversion, but the legitimacy of the conversion ratio depends on simulation credibility. This creates a circular dependency and represents the standard's deepest moat.

2. 'Evidence eligibility' for simulation toolchains. 'Able to run scenarios' ≠ 'able to serve as evidence.' Sensor model validation requires statistical significance against real-world data, with quantified uncertainty separated into aleatory and epistemic components—largely uncharted territory in the domestic passenger vehicle context. This should be the top priority, as it's a prerequisite for item 1.

3. The chain reaction triggered by 'assuming the worst case even if the rear vehicle is unseen.' A hypothetical rear vehicle at +30 km/h relative speed, a 3 m/s² deceleration limit, and a 1-second time gap push the required rear detection distance to aggressive levels. Many existing platforms' rear-lateral perception (especially pure vision solutions) cannot support high-speed lane changes. The options are to add hardware or reduce ODD speed. This requires an immediate decision.

4. Direct conflict between same-type judgment and OTA cadence. 'Same software architecture characteristics' + 'ODC can only contract' + 'versions must not affect performance'—combined, these place routine retraining of end-to-end models in a gray area. Industry-standard iteration rhythms clash head-on with these rules.

5. Productization of the user training process. A pure product design challenge. Compliance requirements are rigid, user experience is rigidly averse, and a balance must be struck.

6. This fundamentally tests organizational capability, not technical capability. SMS + safety dossier + triple inspection test whether 'your company has an auditable safety governance system.' This structurally favors companies with high self-research levels and mature processes. Those relying on piecemeal external solutions will face an awkward reality: suppliers won't provide process evidence, leaving their dossiers incomplete.

What will happen to this industry?

First, the era of conceptual marketing is over. Vague rhetoric like "NOA", "L2+", and "quasi-L3" will no longer have room. ODC must clearly specify road types, time periods, vehicle speeds, weather conditions, and lane types in accordance with GB/T 45312, and then include this information in the safety documentation.

This is both a constraint and a clarification of responsibility boundaries. For companies genuinely willing to assume L3 responsibility, it is actually a good thing—finally, there is a clear line that can be pointed to, saying, "Within this line is my responsibility, and outside of it is not."

The competitive landscape has changed. The key factors determining who will be the first to obtain L3 approval are no longer primarily about the mileage data of takeovers, but rather: whether the simulation toolchain is qualified as evidence, whether the safety documentation can pass bidirectional traceability reviews, and whether the SMS can demonstrate robustness.

This represents a reordering from "demo capabilities" to "engineering systems." It will clearly distinguish a group of companies, and the criteria for differentiation are quite different from what has been competed over in the past two years.

BOM costs are being pushed up by standards. Forward perception of 130 meters, lateral perception of 9 meters, reverse perception for rear sensing, redundant steering and braking, non-buckled seatbelt monitoring, and multimodal redundant alerts—all lead to rigid cost increases. Therefore, L3 will initially be implemented in high-speed and urban expressway scenarios, as well as in mid-to-high-priced vehicle models in the short term. This also explains why Appendix B only covers high-speed expressways.

Supply chain relationships will need to be restructured. Standards require you to sign development interface agreements with all participants, assess suppliers' SMS, and audit their processes. Tier 1 suppliers will transition from "selling parts" to "delivering auditable evidence of safety processes." Suppliers that can provide complete documentation to support their claims will receive a premium, while those that cannot will be excluded from L3 projects.

Approval has shifted from a "one-time" process to a "lifetime" system. Post-deployment safety management requires continuous monitoring, incident reporting, risk assessment, OTA fixes, and effectiveness verification. This essentially establishes a "post-market surveillance" system for high-level autonomous driving, similar to that for pharmaceuticals. Cloud-based safety operations will now be a mandatory part of approval, not an option.

Finally, there is a strategic variable that is easily overlooked. Officials have explicitly stated that this standard has been coordinated with the United Nations ADS GTR. If the alignment is indeed high, then the safety documentation developed domestically may be reusable for future exports.

This is the commercial rationale for investing in this "seemingly burdensome" system—not just to obtain certification domestically, but to secure a certification that will be valid in the future.

References and Images

"Safety Requirements for Autonomous Driving Systems of Intelligent Connected Vehicles" (GB 44721—2026) pdf

*Reproduction and excerpting are strictly prohibited without permission-