For a public-sector AI hardware project, your first decision is not whether a device looks capable. It is whether one traceable evidence packet can pass five gates: declared use and accountable owners; exact hardware identity; data and subcontractor mapping; destination and lifecycle evidence; and controlled acceptance. For China-origin hardware, keep every claim tied to the named entity, SKU, version, destination, and representative pilot.
How this public-sector route differs from the enterprise checklist
You use this route when a public body needs evidence for a service or controlled trial. The AI procurement checklist for enterprise buyers covers the broader enterprise China-to-customer path. This page adds public-sector questions on purpose, impact, data protection, equality, transparency, audit, change, exit, and accountable acceptance. It does not decide what your jurisdiction requires; confirm destination- and use-specific obligations with responsible officials or advisers.
Gate 1. Declare the public task and name every owner
Write the service problem before you describe a device. State who will use it, who may be affected, what decision or action its output informs, where human review sits, and what happens when the system is unavailable or wrong. Ask whether a simpler non-AI route could meet the same need.
Name the service, commercial, technical, privacy, security, equality or accessibility, contract, and acceptance owners. Ask which impact, data-protection, equality, transparency, records, or consultation reviews apply. Record the answer, owner, date, and next decision point rather than a legal conclusion.
Gate 2. Freeze the entity, SKU, version, and physical configuration
Record the contracting, manufacturing, after-sales, and invoicing entities; do not assume one name covers every role. Freeze the SKU, regional variant, hardware revision, firmware, operating system, compute, sensors, accessories, power configuration, packaging, and language set. Record manufacture and shipment details only when current documents support them.
Ask which entity issued each technical statement and version. A family name, photograph, listing, or logo is insufficient. Keep the comparison open until the unit, evidence, and commercial document match one identity and configuration.
Gate 3. Map data, remote access, and subcontractors
Draw the representative data path: inputs, outputs, device storage, local applications, cloud services, portals, logs, telemetry, updates, support access, and deletion. At each transfer or access point, record purpose, data type, location, retention, security evidence, and the owner who can approve or revoke access. Ask what changes if cloud functions are disabled.
List every disclosed subcontractor or service provider involved in hosting, support, analytics, updates, model services, or repair. Record its function, processing or access location, and notice process for a change. Ask the responsible privacy and security officials whether a data-protection impact assessment or equivalent review is needed for the actual destination and use. Do not turn a supplier answer into your authority’s conclusion.
Gate 4. Match destination evidence to the supply and repair path
Create a destination-and-use register before accepting document labels. Ask responsible officials or advisers which approvals, reports, declarations, manuals, labels, reviews, accessibility evidence, import records, or other documents apply. Record each item’s issuer, scope, version, date, covered SKU, and verification route. Unrelated, expired, or family-level evidence does not close a SKU-level question.
Map the lifecycle route separately: who supplies the exact unit, who provides updates, where replacement parts come from, who receives a repair, what data may remain on returned hardware, and who owns reconfiguration after service. Ask for a written change notice covering entity, component, firmware, cloud, subcontractor, and support-path changes. Record any response-time or service commitment only if it appears in the proposed agreement; do not infer one.
Gate 5. Put audit, exit, and acceptance into the evidence packet
Define needed governance access: technical documents, version history, update records, administrative logs, test and incident evidence, subcontractor notices, and independent review where appropriate. Do not assume source-code or unrestricted-system access; state the rights you need and resolve gaps before commitment.
Write an exit rehearsal for hardware, software, and data. Identify export formats, credential transfer or revocation, remote-access shutdown, return or disposal decisions, and deletion evidence from the primary provider and relevant subcontractors. Assign each item an owner and verification step.
Run a representative pilot against the frozen SKU and version under real conditions, with representative data, difficult cases, human review, recovery, security, and accessibility checks where relevant. Set criteria before testing without inventing performance claims. Preserve failures, changes, exclusions, and decisions. A pass covers only the declared use and version tested.
Keep evidence and ownership together
| Evidence object | Questions you should close | Accountable owner |
|---|---|---|
| Purpose and impact record | What public task, affected groups, human review, and applicable assessments are recorded? | Service owner plus responsible review officials |
| Identity sheet | Which entities, SKU, region, hardware revision, firmware, modules, and documents match? | Technical and commercial owners |
| Data and subcontractor map | Where does data move, who can access it, what changes, and who can revoke access? | Privacy and security owners |
| Destination and lifecycle register | Which destination evidence applies, and how do supply, repair, updates, and notice work? | Responsible official or adviser plus contract owner |
| Control and acceptance record | What audit, exit, deletion, and pilot evidence closes the declared scope? | Contract and acceptance owners |
Stop when a critical line has no evidence or owner. Holds include an undefined SKU or entity, an incomplete data route, an undisclosed provider, an unowned destination question, a missing repair or change route, an unrehearsed exit, or an unrepresentative pilot. A hold is unresolved evidence, not an official determination.
FAQ
Is this a legal or regulatory checklist?
No. You use it to organise questions, documents, owners, and decision records for a public-sector AI hardware project. The applicable process depends on your destination, use, data, users, and authority. Ask the responsible legal, privacy, security, commercial, equality, accessibility, import, and records officials or advisers which obligations and approvals apply. Keep their decisions in the project evidence packet.
Which China-origin hardware fields should you freeze first?
Start with the exact contracting, manufacturing, after-sales, and invoicing entities, then freeze SKU, regional variant, hardware revision, firmware, operating system, included compute, sensors, accessories, power configuration, and language set. Match every material statement and document to that identity. If the proposal names only a family or model line, keep the configuration gate open and request a version-specific response.
What should your data and subcontractor map contain?
Show each input, output, storage point, processing location, cloud service, administrative portal, log, telemetry route, update channel, support session, and deletion step. Name each disclosed subcontractor or service provider and its role, access location, and change-notice path. Record who can authorise, review, or revoke access. Ask responsible officials to determine which data-protection review applies to your use.
How should you treat certificates and destination documents?
Treat each file as evidence with an issuer, scope, date, version, covered SKU, and verification route. Do not assume a badge, logo, family-level statement, or unrelated report satisfies your destination and use. Ask responsible officials or advisers what documentation is required, then match the response to the exact configuration. Leave missing or mismatched evidence open instead of inferring approval or conformity.
What belongs in a representative acceptance pilot?
Use the frozen SKU, version, accessories, data path, and intended operating environment. Include normal cases, difficult cases, human-review steps, recovery, security, and accessibility checks where relevant. Set acceptance criteria and owners before testing. Preserve failures, exclusions, configuration changes, and decisions. The resulting record should support only the declared use and tested configuration, not a broader accuracy or suitability claim.
When should you contact CNPS about the hardware path?
Use Start a conversation when you can share the destination, declared task, exact or candidate configuration, data constraints, required document list, support and repair expectations, pilot conditions, and named decision owners. Ask for gaps to be answered in writing. CNPS can discuss a sourcing requirement, while destination-specific obligations and acceptance decisions remain with your responsible officials and advisers.
You should leave this checklist with a versioned packet, not a general assurance: one declared public task, named owners, exact entity and hardware identity, mapped data and subcontractors, destination-specific questions, a documented supply and repair route, change and audit controls, an exit rehearsal, and representative acceptance evidence. Keep every unresolved item open, and ask responsible officials or advisers to confirm obligations that depend on destination and use.