China's Robotaxi Fleets: The Fleet-Readiness File

When a city, fleet operator, insurer, automotive supplier, mobility platform or commercial partner asks whether a China robotaxi programme is “ready,” the answer is often hidden behind an impressive number. A company may report millions of rides, hundreds or thousands of vehicles, a new city footprint, a remote-operations ratio, a revenue milestone or a new vehicle generation. A government notice may announce a mandatory standard. A municipal action plan may set a large trip target. Each item is useful. None is a substitute for the specific evidence needed to accept a vehicle on a route under a named operating and commercial arrangement.

That distinction has become more important. China has announced a mandatory national standard for autonomous-driving-system safety that takes effect on 1 July 2027. It applies to M- and N-category vehicles equipped with Level 3 and Level 4 systems and calls for lifecycle safety assurance as well as simulation, field and road tests. The standard creates a real vehicle-system boundary. It does not, by itself, issue a city permit, prove a particular robotaxi's safety, define an operating design domain, settle a remote-assistance arrangement, insure a ride or accept a fleet into a buyer's programme. The relevant government notice is a better starting point than a marketing claim, but it is still only one layer of the file.

China's operators also now disclose enough activity that a prospective partner can see why diligence is worth doing. Baidu says Apollo Go exceeded 20 million cumulative public rides in February 2026. Pony.ai's 2025 annual report says 1,446 Robotaxis had been produced as of 25 March 2026 and reports US$16.6 million of Robotaxi-service revenue for 2025. WeRide says its China Robotaxi fleet exceeds 800 vehicles and covers more than 1,000 square kilometres in stated Beijing and Guangzhou service areas. These are company disclosures about their own operations. They are not independently comparable safety scores, incident statistics, permits for a reader's route or proof that a commercial rollout will work elsewhere.

This is a desk-research field guide for partners considering a China robotaxi relationship or trying to interpret one: fleet operators, cities, airports, vehicle and component makers, insurers, platforms, infrastructure providers and corporate mobility buyers. It does not test a vehicle, ride a route, inspect a control room, audit an operator, validate a safety case, check a permit, assess an incident record or give traffic-safety, engineering, insurance, legal or procurement advice. Its purpose is narrower and practical: to turn public signals into a seven-file readiness request, so a partner can distinguish what has been reported from what it still needs to see.

Quick answer: accept a route-specific file, not a robotaxi headline

The right question is not “Which China robotaxi company is winning?” It is: Can the proposed operator connect this vehicle configuration, this route, this operating design domain, this local permission context, this remote-operations model and this commercial arrangement to current, controlled evidence? A ride count is not that connection. A national standard is not that connection. A city target is not that connection.

The practical outcome is a change in vocabulary. Instead of asking an operator whether it is “fully autonomous” or “commercially ready,” a partner can ask more exact questions:

• Which vehicle and software configuration is proposed for this route?
• What is the operating design domain, including the conditions in which the service is intended to operate and the conditions in which it is not?
• Which authority, permission, test programme or local process is relevant, and what document may be reviewed?
• Which validation material can be disclosed under a controlled process, and who owns the explanation of its limitations?
• What is the remote-operations role, the escalation path and the boundary between assistance and control?
• Which commercial and insurance assumptions attach to the named service, rather than to the operator's overall business?
• What event would make the packet stale: a vehicle change, software release, route extension, permit change, incident, service-model change or contract amendment?

Those questions are deliberately less dramatic than a robotaxi launch announcement. They are more useful because they give each party a way to say “known,” “not available,” “requires controlled review,” or “not applicable to this route.” A partner who can make those distinctions is not anti-robotaxi. It is preparing to make a decision that can withstand a changed route, changed vehicle or changed commercial promise.

This approach also gives an operator a fair way to progress a serious conversation. It does not demand that every technical or contractual artefact be sent to a broad email list. It asks for a controlled index: which record exists, what it covers, who owns it, which authorised person can explain it, what confidentiality condition applies and what change will make it stale. A partner can then decide whether the next step is an NDA, a data-room review, an engineering session, a local-authority check, a commercial amendment or a pause. The index is not the proof itself; it is the path to proof.

The 2027 standard changes the vehicle question, not the fleet verdict

China's announced autonomous-driving-system safety standard should be treated as a structural signal. According to the government notice on the mandatory standard, it is scheduled to take effect on 1 July 2027. The notice says it applies to M- and N-category vehicles equipped with Level 3 and Level 4 autonomous-driving systems, while excluding automated parking systems. It says manufacturers must improve safety-assurance mechanisms across the product life cycle and carry out simulation, field and road tests during development and verification. It also describes human-machine-interaction and user-notification requirements, including monitoring a driver's readiness to take over for Level 3 vehicles.

Those details matter because they resist two opposite mistakes. The first mistake is to dismiss a standard as policy theatre. An announced mandatory standard with a defined effective date, vehicle-category scope and validation language changes the environment in which vehicle manufacturers and operators must organise their engineering and launch work. The second mistake is to treat the same standard as a certificate for every robotaxi service. The notice does not publish a safety finding for a named Baidu, Pony.ai, WeRide or other fleet. It does not identify a local route. It does not disclose a particular vehicle build, software version, road condition, passenger service rule, remote-assistance plan, permit or insurance arrangement.

For a buyer, that means the standard belongs in a vehicle-system and validation file. The file should record the exact standard reference the parties are using, the intended effective date, the proposed vehicle category, the stated automation-system level, the manufacturer and integration roles, and the owner of any documentation that the buyer is allowed to see. It should also record the scope boundary: the public summary says automated parking is excluded, and Level 3 driver-monitoring language is not the same thing as a blanket statement about Level 4 robotaxi operations. Do not compress those distinctions into the slogan “China has approved robotaxis.”

This file also helps a commercial team avoid version confusion. A company can describe a vehicle platform, an autonomous-driving stack and a fleet service with similar names. The vehicle sold or proposed to a partner may use a different sensor set, compute configuration, safety driver policy, software branch, remote-operations tooling or geographic restriction from the vehicle described in an earlier press release. A standard reference gives the parties a common language for a configuration question; it does not remove the need to ask what configuration is actually on the road.

The same caution applies to the shorthand “L4.” In ordinary discussion, the label often gets used as if it tells a reader every important fact: whether there is a driver, whether passengers can book the service, whether a route is open, whether the vehicle operates in rain, whether an operator can assist it remotely, whether it is insured for a particular commercial programme or whether a city has accepted the service. It tells none of those things by itself. The government notice calls L3 and L4 out as system levels in the standard's stated scope; a partner still needs a route-specific operating record.

Read reported scale as an operating signal, not a safety score

The strongest public evidence of momentum in China's robotaxi sector comes from the operators themselves. That is useful, provided the reader keeps attribution visible. The numbers show what an operator says it has done, built or sold. They do not establish a cross-company safety ranking, a universal operating condition or an accepted risk profile for a buyer's proposed deployment.

Baidu's investor-relations material says that Apollo Go had exceeded 20 million cumulative public rides by February 2026. It also describes its own permits, driverless operations and city footprint. The right way to write or use this is: Baidu reports a cumulative ride milestone. That signal may justify asking for a more detailed route packet. It does not answer how the rides are defined, what vehicles or conditions they include, what route restriction applied at the time, what a rider experienced, how an incident was classified, what remote assistance occurred or what would apply outside the reported service context. A partner should not convert a cumulative ride number into a safety-rate denominator it cannot inspect.

Baidu's intelligent-driving disclosure also presents Apollo Go as an autonomous ride-hailing service and describes company-reported permit and city information. A commercial reader should use that to identify questions, not to skip them. For example: Which city and zone are relevant to the proposed relationship? Is the expected service passenger carrying, testing, validation, a limited zone, a partner deployment or a different product? Does the party proposing the deal control the fleet, own the vehicle, provide the software, manage the passenger interface or merely supply a component? A large operator can have several routes with different terms. A public company overview cannot resolve those distinctions for an outside counterparty.

Pony.ai's 2025 annual report gives another kind of signal. It reports 1,446 produced Robotaxis as of 25 March 2026 and US$16.6 million of Robotaxi-service revenue for 2025. It also reports its own city-level unit-economics milestones and operating figures. These disclosures matter because they place the conversation beyond a laboratory demo: the company presents fleet production and a revenue line. Yet the evidence boundary is equally important. Fleet vehicles produced are not necessarily vehicles operating on the route a reader has in mind. A service revenue figure does not state the counterparty's commercial model, utilisation, pricing, maintenance cost, insurance cost, subsidy treatment, passenger demand or gross-margin result for a new partnership.

Use the numbers as a request trigger. If an operator says a particular generation is being produced at scale, ask for the exact generation and configuration in scope. If it reports a commercial service, ask whether the proposed arrangement uses the same service model, local authority boundary, passenger interface and remote-support policy. If it reports citywide unit economics, do not assume the same conclusion travels to another city, airport, industrial park or overnight route. The mature response to a reported milestone is not disbelief. It is a narrower evidence request.

WeRide's 2025 annual report says its China Robotaxi fleet exceeds 800 vehicles and covers more than 1,000 square kilometres in stated Beijing and Guangzhou service areas. The report also describes a business that includes vehicle sales, operational and technical support services and other technology services. This is a useful reminder that “robotaxi company” can obscure several roles. An operator may sell vehicles, provide a technology stack, operate a passenger service, provide technical support or work with a local partner. The entity a buyer is speaking with may not be the entity that controls the route, holds the relevant permit, staffs the operational team or bears the passenger-facing commercial risk.

The safe conclusion is not that one reported fleet is better than another. It is that public company disclosures make it reasonable to ask, with more discipline, who owns each part of the case. A fleet count points to asset and maintenance questions. A reported ride number points to definition and operating-context questions. A service revenue number points to commercial-boundary questions. A stated coverage area points to city, zone and route questions. None of these signals replaces a route acceptance file.

A city plan is a context signal, not a deployment acceptance

Municipal policy can make a robotaxi programme look inevitable. That is understandable: roads, data infrastructure, test mechanisms, traffic management, local industrial policy and passenger-service rules all affect whether a programme can move beyond a single demonstration. But a city plan and a fleet acceptance are different evidence objects.

Shanghai's published action-plan summary is a useful example. The government account of the plan says Shanghai aims to see Level 4 autonomous vehicles make more than 6 million passenger trips by 2027 and open more than 5,000 kilometres of roads for autonomous driving. It also describes proposed third-party platforms, including a traffic-safety laboratory, intended to improve validation for autonomous-driving systems and operational services. These are significant policy targets and infrastructure intentions. They indicate why an operator, supplier or partner may want to take Shanghai seriously.

They do not mean that 6 million trips have occurred, that 5,000 kilometres are currently available to a particular operator, that every route in the city is open to a robotaxi, or that a counterparty has permission to start a passenger service. They also do not say which vehicle configuration, weather condition, time window, passenger category, remote-operations arrangement or commercial product is accepted. Treat the plan as a city-context file: a dated record of stated direction, relevant geographic ambitions, local validation concepts and questions to be confirmed with the actual authority and operator.

This distinction prevents a common commercial error. A supplier sees a city opening roads and tells its board that a local robotaxi opportunity is “approved.” A platform sees an operator announce a service and describes an entire municipality as driverless. A prospective insurer sees a policy target and assumes it has an agreed operational profile. These statements collapse policy, permit, route, operator and commercial responsibility into one word. The word is usually “ready.” It conceals the very things a partner needs to negotiate.

A better city conversation begins with boundaries. What public plan, regulation, pilot rule or authority process is relevant? Which exact zone is proposed? Which organisation owns the relationship with the authority? Which document establishes the current status? What happens if the route crosses a district, airport boundary, toll area, private campus or road type not covered by the initial service? Is the operator asking the buyer to rely on a public target, or can it provide route-specific documentation through the permitted channel? If the answer is “we are still discussing it,” that is not necessarily a failure. It is a reason not to represent the programme as accepted.

Build the seven-file robotaxi readiness packet

The following seven files are an editorial framework. They are not a Chinese permit, a safety-case template, an insurance certificate, a technical standard or a statement that any robotaxi service is safe. Their purpose is to make ownership, version, scope and gaps visible to the people deciding whether to proceed.

1. Vehicle and configuration file

Start with the physical and software object. Record the legal manufacturer or vehicle supplier where known, the vehicle platform and generation as described by the operator, the autonomous-driving hardware and sensor configuration that is in scope, the software release or version-control reference, the communication and compute responsibilities, the vehicle identifier or batch reference where disclosure is appropriate, and the date of the description. Name the party that can explain a configuration change.

This is not a request to publish sensitive source code or every component specification. It is a way to stop a photo, demo vehicle or generic model name from standing in for the actual object. If a vehicle is substituted, sensors are changed, software is updated, a safety driver policy changes or a remote-operations function is reconfigured, the file should show whether the evidence packet remains applicable. An outside partner cannot assess what it cannot identify.

2. Operating design domain and service file

The second file names the intended operating envelope. It should cover the service type, proposed road or zone, hours, geographic boundary, passenger category if applicable, traffic environment, constraints the operator chooses to disclose, and the party who owns the current version. It should make unknowns visible. “Citywide” is not a complete operating design domain. “Airport service” is not a complete operating design domain. “L4” is not a complete operating design domain.

For a commercial partner, the important question is not whether the operator can list every possible edge case. It is whether the parties can recognise a material mismatch. A route may involve a specific curbside pickup pattern, a controlled campus gate, a tunnel, a weather regime, a roadworks condition, a shift change or a passenger-assistance requirement. If the service model changes, the file needs a revision and a person responsible for deciding whether other evidence must be refreshed.

3. Route, authority and permission-status file

This file records the exact route or zone and the current public or contractual status that the parties may rely on. It should identify the operator entity, local partner, authority-facing entity, applicable city programme or permit process, document owner, date, scope, condition and disclosure restriction. It should not use a public city plan as a proxy for a route permission.

The right status words are modest: proposed, testing, designated-passenger service, operational in a specified zone, under review, expired, revised, not disclosed or not applicable. A partner should resist replacing those words with “approved” unless it has a current document that supports that conclusion for the precise service. If documentation cannot be shared openly, the file can still name an authorised reviewer, a data-room route, an NDA requirement and an escalation path. Controlled access is different from no evidence; the packet should distinguish them.

4. Validation and safety-case access file

The national standard's announced emphasis on lifecycle assurance and simulation, field and road testing makes this file unavoidable. The question is not “show us a safety slide.” It is: What validation material exists for the configuration and operating context, who owns it, what can an authorised counterparty review, what does it cover, and what does it not cover? The file can index test plans, verification summaries, release gates, simulation or field-test categories, issue-management processes and review limitations without asking an operator to publish sensitive engineering material.

The key word is access. A buyer should not pretend that it has evaluated a safety case merely because it received a presentation. An operator should not promise that a public brochure is a complete safety case. The file should say whether a relevant artefact is available, whether it applies to the proposed configuration and service, who may explain it, and what missing evidence blocks a readiness representation. This respects both confidential engineering practice and the buyer's need not to rely on a vague assurance.

5. Remote operations and passenger-service file

Robotaxi conversations often become imprecise around remote assistance. A proposal may mention a remote operator, a command centre, teleoperations, customer support, emergency response or a passenger help button as if those terms were interchangeable. They are not. The file should name the service role being described, the entity responsible, the escalation path, the limits of the described support, the relevant training or operational-material owner, the passenger communication route and the version/date.

This does not require the article to determine how a particular operator controls a vehicle. It prevents a partner from making a claim it cannot support. For example, a passenger-support process may not be a remote-driving process. A remote-assistance ratio may not tell the buyer what intervention authority exists on its route. A control-room demonstration may not show the staffing, language, incident, privacy or escalation conditions that apply to a new commercial service. Ask for the operational boundary in terms the service owner can defend.

6. Commercial, insurance and data-boundary file

Fleet readiness is not only an engineering question. The proposed operator, platform, vehicle supplier, local partner, insurer and corporate customer may each have a different role. This file identifies the contracting entities, vehicle owner where relevant, passenger-facing service entity, pricing model, support responsibility, maintenance boundary, insurance-information owner, data-processing roles, service-level assumptions and exclusions. It is not an insurance opinion and it does not estimate premium, liability or profitability.

The purpose is to stop technical confidence from leaking into commercial assumptions. A reported service revenue number may show that an operator has a commercial line; it does not determine who pays for downtime in a buyer's contract. A city programme may create operating opportunity; it does not decide data rights. A vehicle manufacturer may supply hardware; it may not run the service. When each party is named, legal and commercial teams can ask the right follow-up question instead of assuming the technology company carries every responsibility.

7. Change, incident and representation log

Every other file becomes unreliable if it is frozen at the launch presentation. The final file records material change: vehicle substitution, hardware change, software release, service-zone extension, new route, altered hours, operational-policy change, remote-support change, permit-status change, contract amendment, significant incident-notification process or a new limitation. For each change, record the date, the old and new state, evidence owner, decision owner, affected counterparties, disclosure route and next review.

This is not an incident database and it does not ask the editorial team to judge an event. It is a governance record. A buyer may have a contractual or regulatory reason to be notified of a safety-relevant or service-relevant change. An operator may have confidentiality and legal constraints around incident information. The log gives both sides a way to say what triggers notice, who receives it and whether the prior readiness packet can still be cited. Without it, last year's route dossier can be mistakenly used to support this year's different service.

Run one real-route evidence drill

The test of the packet is not whether it looks polished in a shared drive. It is whether people from engineering, operations, commercial, insurance and procurement can follow it for one actual proposed service. Choose a vehicle configuration, a defined route or zone, a named service model and one counterparty relationship. The aim is not to certify the fleet in a meeting. The aim is to discover where the evidence stops.

Begin with one sentence: “Show the controlled readiness record for this vehicle configuration, this operating design domain and this route, and tell us what would change if the vehicle, software, service zone or support model changed next month.” Then work through the packet.

1. Match the vehicle/platform description to the exact configuration proposed.
2. Match the service model to a defined operating design domain rather than to a city label.
3. Name the operator entity, local partner and authority-facing entity.
4. Identify the current route or permission-status record and its disclosure condition.
5. Ask what validation or safety-case material can be reviewed, by whom, and for what scope.
6. Describe remote operations, passenger support and escalation without assuming the terms mean the same thing.
7. Name commercial, insurance and data owners for the contemplated deal.
8. Test one recent or hypothetical material change and follow the notification/review path.

The drill produces three useful outcomes. Developable means the parties can identify the configuration, route, record owners, controlled-review path and change process; a buyer may still need specialised review, but it knows where to start. Remediable means information exists but is scattered across an operator, OEM, local partner, city team or insurer, or uses inconsistent versions and labels. A remediation owner and time-bound request can be assigned. Pause the representation means the parties cannot say which vehicle, route, authority status, validation access, remote-operations boundary, commercial entity or change process applies. The appropriate response is not to call the operator unsafe. It is to stop calling the proposed service ready.

That last category is particularly important in fast-moving China robotaxi discussions. A company may be genuinely expanding. A city may be genuinely supportive. A standard may be real. The proposed commercial arrangement can still lack a retrievable file. Pausing a representation protects both parties from promising more than the evidence supports.

Use a city or supplier relationship to improve the packet, not to manufacture certainty

The seven-file method is useful beyond the operator. An OEM can use it to distinguish a hardware supply agreement from fleet operation. A sensor or compute supplier can identify which configuration and route it is actually supporting. An infrastructure provider can state the service boundary for charging, connectivity, mapping or roadside systems. An insurer can separate a fleet's reported scale from the policy information it needs. A city or airport can separate a strategic plan from the specific operating documents its partner must provide. A platform can distinguish passenger booking from vehicle operation.

This is also why the topic belongs beside the broader China AI and Robotics: The Deployment Evidence Guide. China can be a consequential place to watch autonomous-machine deployment without making every headline a procurement conclusion. The same habit appears in the World Robot Conference 2026: A Buyer's Test: public demonstrations and industry claims can be valuable signals, but a buyer needs an object, an owner, a testable boundary and a stop rule.

For a China-linked supplier relationship, add a simple appendix to the usual quality and commercial file. State whether the supplied component, software, service or infrastructure is part of the proposed vehicle configuration; who receives change notices; what evidence may be shared; what performance claim the supplier is and is not making; and whether the operator can carry the change into its own validation and release process. A component datasheet cannot establish fleet readiness. But a supplier that can identify its role and change path is more useful than one that repeats a robotaxi headline.

A pause rule for “robotaxi ready” claims

Use this internal sentence:

> Do not describe a China robotaxi vehicle, fleet, city programme, route or commercial service as ready until the team can identify the configuration, operating design domain, current route/permission status, validation-access owner, remote-operations boundary, commercial/insurance roles and material-change process.

The rule does not require a counterparty to reveal every confidential engineering artefact in an initial meeting. It requires the parties to identify what exists, what it applies to, who can review it, what condition controls access and what gap remains. A credible operator can say, “This is the configuration and operating route we are discussing; this is the authority and validation material that can be reviewed under a controlled process; this is the support model; these are the facts we cannot yet represent.” A credible buyer can say, “We are interested, but we will not turn public scale or a city target into an acceptance statement.”

That is a stronger basis for a deal than a generic safety assertion. It leaves room for technical review, local legal work, insurance analysis, commercial negotiation and actual operating evidence. It also gives an operator a fair chance to show its preparation without forcing it to convert confidential work into an unqualified public promise.

Method and limitations

This desk-research article was completed on 28 August 2026. It uses the government notice on China's mandatory autonomous-driving safety standard, the Shanghai action-plan summary, Baidu's investor-relations description of Apollo Go, Pony.ai's 2025 annual report and WeRide's 2025 annual report. Company-reported rides, fleet production, service footprint and revenue remain attributed to the company that reported them.

The editorial team did not ride, test, monitor, audit, insure or verify a robotaxi fleet; inspect a vehicle or control room; review a route permit, safety case, incident record, policy, contract, operating design domain or commercial data room; or determine the safety, legality, availability or economics of a service. Standards, city programmes, operator disclosures, vehicles, routes and commercial arrangements can change. This is not engineering, traffic-safety, insurance, legal or procurement advice. The seven-file packet is an editorial organisation tool, not an acceptance test.

Frequently asked questions

Does China's 2027 autonomous-driving standard approve robotaxi fleets?

No. The announced mandatory standard describes vehicle-system scope and lifecycle, simulation, field and road-test expectations for specified L3/L4 vehicles. It does not itself grant a route permission, accept a named fleet, evaluate an operator or determine whether a commercial service is safe for a specific passenger, city or buyer.

Does a large Apollo Go, Pony.ai or WeRide fleet prove safety?

No. Their public ride, vehicle, revenue and footprint figures are useful company-reported operating signals. They should be attributed to the reporting company and used to target diligence questions about the configuration, route, operating conditions, evidence owner and commercial arrangement; they are not independent safety scores.

Is a city target the same as a robotaxi permit?

No. Shanghai's public plan shows policy direction and stated targets for trips, roads and validation infrastructure. A particular service still requires route-, entity-, vehicle- and current-status evidence. Do not use a plan target as a substitute for the document that supports the proposed operation.

What should an insurer or commercial partner request first?

Start with one real proposed service: vehicle configuration, route/operating design domain, responsible entities, route/permission status, controlled validation-access path, remote-operations boundary, commercial and insurance role map, and change-notice log. If the parties cannot identify those objects, pause a readiness representation.

Can a supplier use this file if it does not operate the robotaxi?

Yes. The supplier should state its exact configuration, service or component role, what evidence it owns, who receives change notices and which operating or commercial conclusion belongs to the fleet operator or another party. It should not use a relationship with a robotaxi company to claim that an entire fleet or route is ready.

By China Made & Tech Team. Independent English field guide to China's niche hardware brands, hidden champions, founders, factory towns, and supplier clusters.