简介：《VDA PI 产品诚信（Product Integrity）》是德国汽车工业协会（VDA）于2018年11月发布的第一版非强制性建议文件，面向汽车行业质量、产品安全与合规管理人员，以及需要建立产品安全与一致性管理机制的组织的从业者。文件围绕产品安全与一致性、质量管理体系、责任与合规、最新技术水平、风险管理及持续改进等主题，给出组织层面的推荐行动，并注明仅供 Automotive Lighting Group 内部使用。包内共1个PDF文件，大小约833KB，便于检索、打印和内部传阅。已有1211人学习或下载，说明其在汽车质量与产品诚信议题上具有一定参考热度。读者可从中了解VDA对产品安全与一致性管理的基本框架、FMEA等风险识别思路、质量工具与方法的应用方向，以及如何在合规前提下持续改进质量管理体系，适合作为汽车供应链质量审核、产品安全专员和体系工程师的内部参考资料。

1. 两条常见的误解：产品安全与一致性如何合成产品诚信

VDA PI 产品诚信（Product Integrity）这个题目，第一次翻原始文件的人容易把它当成又一份质量管理体系的补充说明，其实它只做了一件事：把「产品安全」和「产品一致性」两条要求并列起来，合成一个不可拆分的责任概念。产品安全说的是产品投放市场后，在预期使用和可预见误用下都不得危及任何人的健康；产品一致性说的是流程、产品和服务既要满足约定的客户要求，也要满足出口国、进口国以及客户指定目的地国的适用法律法规。两条缺一条，产品在市场里就站不住脚。这份 2018 年 11 月首版、12 月出版的非强制性建议，面向的是整条汽车供应链上的组织——主机厂、各级供应商、带软件和服务的乙方都算。它不给认证，也不发证书，给的是一张责任地图：谁负责、在哪个阶段负责、出事之后按什么顺序动作。把这张地图先装进脑子，后面所有模块才有地方挂。

2. 组织与委派：执行管理层、PSCR 与委派级联的三层结构

组织这一章是整个体系的承重结构。原材料把话说得很直接：投放市场的产品的安全与一致性，根本责任在执行管理层；建议里的所有动作，最初都归属到执行管理层头上，然后才谈往下分。这句话决定了很多事情的边界——它不是一句口号，而是后面所有委派动作的前提。梳理下来会发现，组织这一章其实在回答三个问题：谁最终负责、责任怎么合法地往下传、传下去之后怎么证明它还活着。这三问对应三层结构，任何一层塌了，PI 体系就只是一堆文件夹。

2.1 执行管理层扛的是不可委派的那一段

先把「产品」这个词的边界划清楚，这是最容易想窄的地方。原文的定义是所有制造出来的物品，包括可移动物、其他可移动物的部件，也包括不可移动物，并且明确把集成软件、软件和服务包含进来，举例里出现了紧急呼叫、分选措施、第三方返工、开发服务。也就是说，一个由外部团队开发的嵌入式模块、一次外包的返工动作，都在产品诚信的射程里。很多组织的 PI 体系只覆盖硬件 BOM，软件和服务挂在另一个流程下，这就是典型的边界漏算。

责任范围同样不能打折：它覆盖整个产品生命周期，也覆盖整条供应链，而且供应链的深度必须写进合同安排里。这句话的重量在于「合同」两个字——不是内部流程文件写一句「我们关注二级供应商」就够了，而是要在商务合同层面把追溯深度落到条款上。出了偏差再去追三级供应商，没有合同支撑，追责链条是断的。

执行管理层还有一项躲不掉的义务：组织内使用的规范、程序、方法和工具，其根本适用性和恰当性由执行管理层负责。换句话说，工具选错了、方法不匹配产品复杂度，不能把锅甩给下面执行的人。而「有效性监控」这件事，原文明确落在执行董事会身上，支撑手段包括内部审核、产品和过程审核、合规指南的定义与评审。注意这里的措辞是监控有效性，不是监控有没有做——有没有做是形式，有没有效果才是责任。

提示：把「有没有做」和「有没有效」分开检查，是 PI 体系成熟度最直观的分水岭。前者查记录，后者查偏差率和重复发生率。

2.2 委派级联：职责可以往下走，责任不能消失

原文有一句话值得逐字读：执行管理层的根本责任不可委派，但为履行这个责任而设计的职责可以委派。这句话把「责任」和「职责」拆成了两层。责任是壳，摘不掉；职责是内容，可以分。分的前提是权限（决策权和行动权）被可验证地定义，通常就是书面化。口头交代一句「这事你盯一下」，在 PI 语境里等于没委派。

再往下是资质要求。原文 2.2 只给了框架，落到可执行层面，通常拆成三块：技术专长（懂产品、懂法规、懂本公司流程）、人格适配（敢在压力下说不、能把坏消息往上捅）、以及可验证的培训记录。第三块最容易被省略——「他干了十年，肯定懂」这种判断在审核现场是不成立的，必须有交底记录。

表格里第四行是血泪经验最集中的地方。原文写得很清楚：人员变动时，委派者必须尽快重新指派，在重新指派完成之前，委派者保留责任。也就是说那段空窗期，责任自动回到上一层，不会因为「当时没人」而消失。现实里最常见的翻车是核心 PSCR 离职，岗位挂着、事情停着，等到客户审核问起，发现三个月没人签过任何一致性文件。

委派的规模也不是拍脑袋定的，它取决于组织 PI 相关活动的范围，遵循「委派级联」的原则——把职责、权限和责任转移到第三方，或者转移到相邻、下级的层级。级联意味着它可以有多层，但也意味着每一层都要重复上面那六个条件。二级 PI 职责，比如产品一致性这一块，可以委派给已有部门和专家：法规事务、生产一致性（CoP）或型式认证专家、功能安全管理、质量管理。这样做的好处是不用另起炉灶，坏处是容易出现「多人有责等于无人负责」，所以每个接受委派的角色都必须按组织自己的准则正式任命，而不是口头挂靠。

2.3 资质与沟通网络：人、位置、联系方式要一直有效

委派解决的是「谁干」，沟通网络解决的是「找得到谁」。原文要求执行管理层保证组织内指定联系人的联系方式始终保持最新，这些 PI 联系人要在组织内部和相关地点都被恰当指定并且广为人知。这一条听起来像行政琐事，实际是应急响应的第一块砖——偏差发生时，第一通电话打不通，后面所有流程都要往后推。

内部沟通网络的建议是跨相关地点搭建，作用是共享早期预警和经验教训。注意「早期预警」这个词，它比「事故通报」往前了一步：还没定性为偏差的异常信号，也应该在网里流动。供应链侧同样需要 PI 沟通网络，目的是在产品预警必要时能快速交换信息，并且明确要求相关 PSCR 参与进来。这条把上游和下游绑在同一个响应节奏上，而不是各查各的。

3. 生命周期六段：PI 要求从需求到市场监控的落地节奏

产品诚信不是一个节点，是一条线。原材料把这条线切成六个阶段：需求、开发、生产、使用、产品监控、市场监控。前四个是产品自身的生命段，后两个是组织对外部的观察段。这个切法的用意是：责任不只到交付为止，交付之后的观察义务同样是体系的一部分。很多组织的 PI 文件写到量产批准就结束了，后面两段空着，而这恰恰是召回风险最集中的地方。

3.1 先定焦点领域：不是所有产品都同一档强度

原文 3.1 讲的是在公司内确定 PI 焦点领域。这一步是整章的前置动作，逻辑很朴素：资源有限，不可能所有产品线用同一档强度。焦点领域的判定通常看几个维度——产品组合里哪些涉及安全相关功能、销往哪些市场、这些市场的法规环境变化快不快、历史偏差和客户投诉集中在哪。定完焦点，才谈得上在不同产品上配置不同深度的 PSCR 组织和不同频率的监控。

这一步最容易走过场：焦点领域直接抄上一年的清单，或者干脆全公司一档强度。前者的问题是市场变了清单没变，后者的问题是重点被稀释，真正的风险点淹没在密密麻麻的同等检查里。梳理下来会发现，焦点领域应该是一个每年重评、并且能说清「为什么今年多了这两类产品」的东西。

3.2 需求、开发、生产：把 PI 要求写进节点

需求阶段的核心动作是把三类要求收集齐并转成可验证的条目：客户约定要求、出口国/进口国/客户指定目的地国的法律法规要求、以及公众的合理安全期望。第三类最虚也最容易漏——「合理安全期望」不是写在合同里的，它来自客户、消费者以及未涉及的第三方（也就是一般公众）。原文特别强调这一点，因为产品被市场判定为「不安全」时，触发义务的不是合同违约，而是这份期望落空。

开发阶段要处理的是设计层面的验证和风险识别，特殊特性的识别通常在这里完成，功能安全管理和质量管理的方法在这个阶段介入。软件集成带来的复杂度提升，原文在前言里点过：产品创新带来复杂度上升，同时开发周期在缩短，这对所有参与方都是挑战。落到执行上，就是变更管理和配置管理必须从开发阶段就启动，而不是等到量产。

生产阶段的关键词是生产一致性（CoP）。设计验证通过不等于每一台下线产品都一致，特殊特性的过程控制、变更的再验证、返工和分选措施的记录，都是这个阶段的具体抓手。第三方返工被明确列进「产品」和「服务」的范畴，意味着外包的返工动作也要纳入同一套 PI 要求。

3.3 使用、产品监控、市场监控：出厂之后责任才真正开始

使用阶段的判断基准是「预期使用或可预见误用」。前半句好理解，后半句才是功夫所在：可预见误用意味着要主动想象用户会怎么错误地使用产品，而不是只按说明书场景做评估。这一条在汽车行业尤其现实，因为产品的使用者不只是车主，还有维修人员、拆解人员和路人。

产品监控和市场监控是并列的两件事，原文把它们分成两个独立小节，这个区分很多人没注意到。产品监控盯的是产品自身在市场上的表现数据；市场监控盯的是产品之外的环境——法规的修订、监管机构的态度、公共讨论的走向、同类产品的召回动态。前者能告诉你「我的产品出问题了」，后者能告诉你「规则要变了，我的产品可能会出问题」。只做前者，等于只有后视镜没有前挡风玻璃。

注意：市场监控缺位的组织，通常在法规切换期集中爆发一致性问题。这类问题不是产品质量坏了，而是判定标准变了，但内部没人盯着变。

4. 偏差响应：从召回管理到 RAPEX 风险评估的处置链

前面三章讲的是怎么不让偏差发生，这一章讲偏差已经发生之后怎么办。原材料的第四章是整份文件里操作密度最高的部分，从召回管理系统的建立，一路写到情况分析、风险评估、决议，还配了中小企业和案例两个示例。这条链条的内在逻辑是：先有制度（召回管理系统），再有信息（沟通与文档、供应链信息流），再有判断（情况分析、风险评估），最后有决断（决议）。顺序不能乱，跳步就会出错——最常见的跳步是拿到一条信息直接跳到决议，中间的情况分析和风险评估全省了。

4.1 召回管理系统与偏差的沟通、文档化

原文要求在企业内部实施召回管理系统。注意用词是「系统」，不是「预案」——预案是文件，系统是能运转的东西：谁触发、谁判断、谁决策、谁执行、谁对外沟通、记录保存在哪、保存多久。一个能运转的召回系统，即使三年没用过一次，也应该能随时拉出来跑一遍演练。

沟通与文档化这一节处理的是「说清楚」的问题。偏差的描述必须包含足够的信息让别人能独立判断：涉及哪个产品、哪个批次、哪个市场、偏差的具体表现、已经流到哪里、目前采取了什么临时措施。文档化不只是留痕，它是后续风险评估的输入——情况分析做不做得动，取决于前面记录得够不够细。

# PI 偏差记录模板（字段按实际体系增删，注释说明用途） deviation_id: PI-2024-0007 # 唯一编号，便于跨部门引用与追溯 detected_at: 2024-05-11T09:20:00 # 发现时间，用于计算响应时效 detected_by: incoming_inspection # 发现环节：来料/过程/售后/市场监控 product: name: 某照明模组 # 产品名称，与配置管理条目对应 part_number: XXXX-XXXX batches: ["L2404", "L2405"] # 受影响批次，空表示待定 markets: ["DE", "FR"] # 已流入市场，决定适用哪国法规 deviation: description: 密封圈硬度低于图纸下限 category: conformity # safety / conformity / both potential_harm: 渗水导致功能失效 # 危害描述，风险评估的输入 containment: action: 库存冻结与在途拦截 effective_at: 2024-05-11T14:00:00 supply_chain: upstream_pscr_notified: true # 上游 PSCR 是否已被告知 downstream_notified: ["某整车客户"] status: under_evaluation # open / under_evaluation / closed owner: PSCR_照明事业部 # 责任人，须与委派记录一致

这份模板里几个字段值得单独说。category把安全和一致性分开，因为两者的处置路径不同：安全类要走更短的决策链，一致性类可以走常规纠正。markets决定适用法规，同一批货卖到不同国家，判定结论可能完全相反。upstream_pscr_notified和downstream_notified对应的是供应链信息流的双向要求，缺一头，链条就是断的。owner必须和委派记录里的名字对得上，否则追责时找不到人。

4.2 供应链信息流与纠正措施

供应链内的信息流是原文单独成节的内容。要求很明确：信息要在链条上快速流动，必要时相关 PSCR 要参与。现实中的难点在两端——上游供应商不愿意过早暴露问题，下游客户不愿意听「可能有问题」。PI 体系要解决的就是这个博弈：把「早说」变成合同义务和流程动作，而不是靠关系。

纠正措施这一节要区分三个层次，很多人混着用。遏制措施是止血，目标是别让坏东西继续流；纠正措施是治伤，目标是让已发生的问题不再扩大；预防措施是健身，目标是让同类问题不再发生。原文在偏差响应语境下强调的是前两个的时效性，第三个通常回流到 Lessons Learned 里。分不清这三层，就会出现「用一份整改报告同时回答三个问题」的情况，审核时一问就露。

4.3 情况分析与风险评估：RAPEX 示例怎么用

情况分析要做的是把事实边界画出来：发生了什么、影响了什么范围、时间线是怎么走的、目前的状态是什么。它不负责判断严重程度，只负责把事实摆平。很多组织把情况分析和风险评估合成一份文件写，结果事实描述里混进了判断，判断里又夹着没核实的信息，最后谁也不敢据此决策。

风险评估才是判断环节。通用做法是把危害的严重度和发生的可能性分开评，交叉出风险等级，再对应到是否需要进一步行动。原材料里给了 RAPEX 的方法示例，这套逻辑在欧盟非食品类危险产品的快速通报机制里用得比较多：先确定危害类型和可能受影响的人群，再评估暴露路径和暴露程度，然后落到风险等级上，等级决定是否需要通报以及通报的紧急程度。

这套方法的可迁移之处不在于具体分级阈值，而在于它的结构：危害、暴露、等级、动作，四步一一对应。搬到企业内部也一样用——任何一条偏差，先问危害是什么、谁会暴露、暴露多深，再问等级够不够触发召回。供应链中的风险评估还要多一步：往上游追溯，确认偏差是单批次偶发还是系统性存在。这一步做不实，召回的边界就会画小。

4.4 决议、中小企业示例与工具方法

决议环节要解决的是「谁有权拍板」。原文在示例部分给了中小企业的做法和一个案例研究，思路是共通的：中小企业人手少，一人多角色是常态，但权限必须书面化，而且要设置一个「不由同一人完成」的复核点。比如一个人可以既是 PSCR 又是质量经理，但涉及召回的决议不能由他一个人签，必须有第二个人复核。这条设计不是不信任，而是防止单点判断失误直接变成对外动作。

工具与方法部分列了七项：组织对 PI 的敏感性、持续监控、PSCR 组织或职责一览、配置管理、沟通指南、经验教训、特殊特性。敏感性解决的是「全员知道这事重要」，靠培训和案例；持续监控解决的是「一直有人看」，靠指标和巡检；PSCR 职责一览解决的是「找得到人」，靠一页纸的矩阵；配置管理解决的是「知道装的是什么」，尤其软件集成之后，没有配置管理就没有可追溯的版本；沟通指南解决的是「对外怎么说」，统一口径避免二次伤害；经验教训解决的是「别再犯」；特殊特性解决的是「重点盯哪些参数」。

配置管理这一项值得单独提一句，因为它在软件占比上升之后权重明显变大。一个产品的 PI 状态，本质上是一组配置项的状态之和：硬件版本、软件版本、供应商版本、法规基线。配置管理没做好，偏差发生时连「受影响范围」都圈不出来，后面的风险评估全是空中楼阁。

5. 五个易错点：产品诚信复习里最容易翻车的地方

这一章是整份梳理里最该反复看的部分。前面四章讲的是体系长什么样，这一章讲的是体系在哪些地方会悄悄失效。每一条都按「易漏点 → 为什么漏 → 怎么补」写，方便对着自己的组织逐项核对。这些点有个共同特征：它们都不会在文件评审阶段暴露，只会在真出事的那一天集中爆发。

5.1 责任与委派上的三个漏点

易漏点一：把「遵循 VDA 建议」当成免责凭证。为什么漏：文件开头的非约束性声明和免责声明，很容易被读成「照着做就没事」。实际原文写的是反过来的——符合这些建议不免除企业在产品责任法下的后果，这些要求对责任和保修范围没有相关性。也就是说，体系做得好是管理成熟度，不是法律抗辩理由。 怎么补：在内部培训里把这一条单独拎出来讲，明确 PI 体系的目标是降低风险概率，不是取得豁免资格。管理层 briefing 里放一页纸讲清这个区别，避免决策时误判风险敞口。

易漏点二：把执行管理层的根本责任也一并委派出去。为什么漏：「授权」这个词在日常语境里含义很宽，容易理解成「这件事我交给你了，我就不管了」。原文的表述是根本责任不可委派，可委派的只是为履行该责任而设计的职责。 怎么补：在所有委派文件的开头加一句固定表述，说明本次委派的对象是职责而非根本责任，委派者保留监督有效性的义务。这句话不是形式，它在事后追责时决定了责任落点。

易漏点三：人员变动后没及时重新指派，以为空窗期无责。为什么漏：组织直觉是「人走了，事停了，等招到人再说」，很少有人意识到这段空窗期的责任自动回到委派者身上。 怎么补：把 PSCR 及所有 PI 相关委派角色做进人事异动流程的强制检查项——离职流程里必勾一项「PI 委派是否已重派」。同时在委派文件里写明代理人和重派时限，避免出现无人签字的连续空白期。

5.2 流程与边界上的两个漏点

易漏点四：供应链深度只在流程文件里写，没进合同。为什么漏：内部程序文件写「我们关注二级、三级供应商」很容易，落到商务合同上要谈条款、谈责任、谈成本，很多人到这一步就停了。原文明确要求供应链深度必须以合同安排的方式记录下来。 怎么补：把 PI 相关的信息通报义务、追溯深度、审核权写进采购合同模板，作为标准条款而不是特批条款。梳理现有合同，标出没有相关条款的供应商，按风险等级排序补签。

易漏点五：只做产品监控，不做市场监控。为什么漏：产品监控有数据、有报表、有系统，做起来有成就感；市场监控是看法规、看讨论、看同行动态，产出的是判断而不是数字，容易被当成「务虚」。 怎么补：把市场监控做成有固定节奏的动作——按季度扫一遍目标市场的法规更新和监管动态，形成一页纸的简报，进入管理层评审议程。关键是有人名、有节奏、有输出物，而不是等出了事再去查。

提示：这五条里，第一和第二条属于认知层，第三、四、五条属于执行层。认知层错了，执行层做得再漂亮也是白做，所以复习时先过前两条。

6. 复习清单：一张能自查的 PI 落地检查表

把前面几章压缩成可执行的核对动作，大概分三层：责任层看人和权限，流程层看节点和证据，证据层看记录能不能自证。三层里最容易糊弄的是证据层，因为记录可以补，但补出来的记录往往在时间戳和关联关系上对不上，一查就露。

再给一份可以每周跑一遍的清单模板，字段不多但要求填满，填不满的地方就是本周该补的地方。

# PI 周度自查清单（未填项即为待办，不要留空过关） week: 2024-W20 responsibility: pscr_active: true # PSCR 在岗且可联系 delegation_valid: true # 所有委派均在有效期内 contact_list_updated: true # 联系人清单本周有变更则更新 process: open_deviations: 3 # 未关闭偏差数，>0 时需说明处置阶段 containment_effective: true # 遏制措施是否确认有效 market_watch_done: false # 本周市场监控是否完成，false 即待办 evidence: deviation_records_complete: true # 新记录字段是否齐全 config_baseline_current: true # 配置基线是否为最新版本 notes: 市场监控因法规更新延迟，下周一补

这份清单的价值不在字段本身，而在于它强迫每周回答一次「市场监控做了没有」。我自己踩过的坑就在这一栏：连续几周填 false 都没人管，等到法规切换，一批在途货的判定标准变了，才发现前面几个月的外部信号一条都没接住。从那以后我每次接手新项目，都会先把焦点领域和 PSCR 联系人这两栏填完再往下走流程，哪怕当天就要交样件，这两行也不跳过——因为跳过它们的代价，往往要到一两年后才结算。希望帮到你。

本文还有配套的精品资源，点击获取