不用AI是否构成过失？技术人面临的新责任边界

AI 技术这几年发展太快几乎每个行业都在谈“如何用 AI 提效”“如何拥抱 AI”。但真正落到工作场景中不少人却陷入一种尴尬的处境用了 AI怕出错、怕泄密、怕被追责不用 AI又怕落后、怕效率低、怕被质疑“不作为”。这个现象在英文里有一句很贴切的描述Damned if you do and damned if you dont。翻译过来就是“怎么做都不对”。更值得思考的是国外已经开始出现一种严肃的讨论如果某个专业人士在明知 AI 可以显著降低风险、提升质量的情况下仍然拒绝使用 AI一旦出现问题是否要承担“疏忽”negligence责任这不是科幻小说里的桥段而是医疗、法律、金融、工程、软件开发等高风险行业中正在发生的真实争议。本文不打算站队也不想制造焦虑而是想从技术人的视角把“不使用 AI 是否构成过失”这个问题拆开来看它的前提是什么、逻辑是什么、在哪些行业已经出现苗头、又会给开发者和技术管理者带来哪些实际影响。如果你是后端开发、AI 应用开发者、技术负责人或者正在思考“团队要不要强制用 AI”这篇文章应该能给你一个比较完整的参考框架。1. 背景与核心问题AI 普及带来的“新式两难”1.1 从“会不会用”到“该不该用”过去几年大家对 AI 的讨论集中在“它能不能做”“做得好不好”。比如AI 能不能写代码、能不能画图、能不能写文档、能不能分析数据。到了现在很多问题已经不再是“能不能”而是“你不让它做是不是反而有问题”。举几个真实场景一个影像科医生用 AI 辅助筛查肺结节AI 标出了一个可疑区域医生没有采纳。后来这个区域确诊为恶性肿瘤。患者家属质疑为什么 AI 已经提示了风险你却不看一个律师用 AI 做法律检索AI 给出的判例中混入了大模型编造的虚假案例。律师没有核实直接写进诉讼材料被法庭处罚。一个程序员用 AI 生成了一段有漏洞的登录代码没有做安全评审就上线导致用户数据泄露。公司追责时程序员说“AI 写的代码我不知道有问题”。反过来另一个程序员坚持所有代码手写拒绝使用 AI 辅助工具。结果项目周期变长同样一个功能隔壁组的交付速度快了一倍。管理者开始质疑为什么你不用 AI你的效率是不是已经不达标了第一种情况是你用了 AI结果出问题第二种情况是你没用 AI结果也被批评。两种声音交织在一起就形成了“用也不是不用也不是”的局面。1.2 negligence过失/疏忽到底是什么要在技术语境里讨论“不使用 AI 是否构成 negligence”必须先把这个法律概念说清楚。在法律上negligence 通常指行为人没有做到一个“合理谨慎的人”reasonable person在相同情形下应当做到的注意义务并因此给他人造成了损害。它的成立通常需要满足四个条件条件解释Duty of care注意义务行为人对受害人负有法律上认可的注意义务Breach of duty违反义务行为人没有达到应有的注意标准Causation因果关系违反义务的行为与损害结果之间存在因果联系Damages损害后果受害人实际遭受了损失或伤害注意这里的关键不是“你用了 AI 还是没用 AI”而是你的行为是否偏离了行业公认的“合理标准”。如果整个行业都已经把 AI 辅助工具作为“标准操作流程”的一部分而你仍然拒绝使用并在工作中出现了本可以避免的错误那么“拒绝使用 AI”就有可能被认定为没有达到应有的注意标准。但这里有一个巨大的现实障碍目前绝大多数行业还没有形成“必须使用 AI”的公认标准。所以“不用 AI 过失”更多是一个前瞻性命题而不是一个已经成熟的裁判规则。1.3 技术人对“过失”讨论的敏感性作为技术人我们可能觉得“这主要是法律问题跟开发关系不大”。但实际上这场讨论会直接影响几类人负责技术选型的人要不要把 AI 工具纳入研发流程。写代码的人用 AI 生成的代码自己要不要逐行审查。做数据/AI 应用开发的人你交付的模型客户有没有正当理由拒绝使用。技术管理者团队引入 AI 后如何定义“合理使用边界”。换句话说这已经不是一个纯粹的法学话题而是“AI 工程实践”的一部分。只要你的工作会涉及专业判断就绕不开这个问题。2. 为什么“不用 AI”可能构成过失三个关键前提2.1 前提一AI 已经成为行业公认的“合理工具”要认定“不用 AI 有过失”第一道门槛是在这个行业、这个岗位、这个场景下AI 是不是已经成为一种合理且被广泛接受的工作方式。举例来说在医疗影像领域如果国家卫健委或三甲医院已经把 AI 辅助筛查纳入了诊疗规范医生不使用 AI 做初步筛查出现漏诊后被认定为有过失的可能性会显著上升。在软件安全领域如果漏洞扫描、依赖检查、AI 代码审计已经成为行业基线而开发者完全依赖人工 review一旦线上出现低级漏洞管理者就会质疑“为什么没有提前用工具拦截”。在金融风控领域如果反欺诈模型已经被验证能识别出人工规则发现不了的风险而机构仍然只用传统规则出现大规模欺诈损失时“过度依赖经验主义”就会成为追责点。反之如果 AI 工具本身还没成熟、行业没有统一标准、工具结果反复无常那么“不用 AI”反而可能是更谨慎的选择。所以第一个问题的本质是行业规范是否已经把 AI 纳入了“合理标准”的范畴。这需要行业协会、监管机构、技术社区共同推动目前大多数领域还没有走到这一步。2.2 前提二不用 AI 会导致损害结果这个前提很关键。过失不是“不思进取”的代名词它必须对应到具体的损害。比如医生不用 AI漏诊了患者的病情被延误。律师不用 AI漏检了关键判例客户的案件败诉。工程师不用 AI 做代码 review一个已知模式的安全漏洞被带上了生产环境。数据分析师不用 AI 做异常检测批量交易中的欺诈行为持续了两个月才被发现。在这些场景里“不用 AI”之所以可能构成过失不是因为它不够“时髦”而是因为它直接导致了本可以避免的负面结果。但要注意一个反向问题用了 AI也不能免除责任。AI 的结果只能作为辅助参考最终的专业判断责任仍然在人。所以过失讨论不一定是“不用 AI 就有罪”而更可能是“你是否尽到了合理注意义务”。2.3 前提三AI 的能力边界已经清晰且稳定这是最容易被人忽略的条件。如果 AI 工具的输出不稳定今天给一个答案明天给另一个答案甚至经常出现“一本正经地胡说八道”那么即使行业里有人在用“不用 AI”也很难被认定为过失。因为使用一个不可靠工具本身就是在增加风险。只有当 AI 在特定任务上的表现稳定优于或显著等效于人工并且这种结论已经被足够的证据支持它才能成为“合理标准”的一部分。这也是为什么很多行业对 AI 落地非常谨慎不是不愿意用而是责任边界太难划清了。3. 现实中的“两难”用 AI 也可能构成过失3.1 AI 幻觉看起来合理其实是编造“AI 幻觉”是这个时代技术人最熟悉也最头痛的问题之一。大模型在生成内容时可能生成流畅、自信、详细但完全不真实的信息。在法律场景中已经出现过真实案例律师使用 ChatGPT 辅助法律检索提交的诉讼材料里引用了 6 个不存在的判例。法官发现后律师不仅面临罚款还差点被吊销执照。在软件开发场景中AI 生成的代码也可能包含“幻觉式”的 API 调用。比如# 假设有一个开发助手生成了下面这段代码 from some_cloud_sdk import deploy_service def deploy(): deploy_service( service_nameorder-service, replicas3, auto_scalingTrue )如果some_cloud_sdk并不是一个真实存在的 SDK这段代码会在 import 阶段直接报错。但如果 AI “聪明”地用了某个真实 SDK 中不存在的参数代码能正常运行只是参数不生效这种问题往往更难发现。所以“用了 AI”并不等于“尽职尽责”。恰恰相反使用 AI 的人必须承担验证、审查、兜底的责任。3.2 数据安全与隐私合规风险企业场景下代码往往涉及核心业务逻辑、数据库连接信息、内部接口定义。如果开发者把完整代码贴给一个公共 AI 工具代码就会被发送到外部服务器这在很多公司属于严重的数据泄露。举个例子// 错误示范不要将生产环境的数据库密码粘贴到公共 AI 工具中 String url jdbc:mysql://prod-db.internal.example.com:3306/orders; String username ordering_admin; String password sk-xxxxxxxxxxxxxxxxxxxxxxxx;如果这段信息通过 AI 工具被发送到外部攻击者可能通过日志、缓存或其他方式获取这些敏感信息。即使 AI 厂商没有恶意行为第三方的数据使用协议也可能与公司的合规要求冲突。这种风险意味着即使“不用 AI 可能是过失”的讨论成立也不能简单理解成“什么都能往 AI 里塞”。真正的合规姿势是采用企业私有化部署、本地模型、通过 API 网关做脱敏等方案。3.3 过度依赖人的专业判断力退化还有一个被讨论很多的风险——能力退化。当开发者习惯让 AI 生成代码、自动修复 bug、自动写测试之后可能会出现“离开 AI 就不会写代码”的状态。一旦 AI 工具不可用或者 AI 给出错误建议人的判断力不足后果会更加严重。这就是“用也不是”的另一个层面不是 AI 出错让你担责而是你因为长期依赖 AI失去了发现 AI 错误的能力。4. 这场讨论对技术人的实际影响4.1 软件研发AI 编程助手从“选修”变“必修”在软件开发行业“不用 AI 是否构成过失”的讨论来得比想象中更快。原因很简单AI 编程工具如 Cursor、GitHub Copilot、通义灵码等的提效已经足够明显。对于常见需求、样板代码、单元测试、代码解释、重构建议AI 的能力已经能稳定输出“可用质量”的结果。在这种背景下很多团队已经开始要求开发者使用 AI 辅助编码甚至将其纳入绩效指标。这里不是说“不用 AI 就违法”而是说从工程管理和团队协作角度看如果一个开发者完全不用 AI可能会出现交付速度明显慢于使用 AI 的同事。对 AI 生成代码的审查能力缺失。无法应对团队制定的 AI 辅助研发流程。在实际项目中更合理的方式不是“强制用”而是把 AI 使用能力作为“工程能力”的一部分来建设。4.2 AI 应用开发你的产品可能承担“推荐义务”如果你是做 AI 应用开发的比如开发一个医疗问答系统、法律文书辅助系统、代码扫描工具这个问题会更复杂。你的产品一旦被用户依赖你就面临“产品责任”和“使用说明义务”的问题。你需要想清楚产品输出是否明确标识了“AI 生成仅供参考”产品是否提供了人工复核流程产品是否在特定场景下明确告知用户“不要依赖 AI 做最终判断”产品的错误率是否被充分测试和公开换句话说AI 应用开发者的“过失”风险不只是“不用 AI”也包括“AI 产品设计不合理”。4.3 医疗、法律、金融传统专业人员的新压力在医疗、法律、金融等传统行业从业者过去主要通过经验、文献、同行评审来做决策。现在AI 辅助工具已经能覆盖文献检索、病案分析、合同审查、风险识别等环节。如果某个 AI 工具已经被所在机构采购并且验证过效果而专业人员拒绝使用一旦出现负面结果机构的追责逻辑很可能就是“我们的工具明明提供了信息你为什么不用”这种压力不是技术上的而是职业文化上的。对于技术人员来说理解这些行业朋友的处境有助于设计更符合“人类负责制”的 AI 工具。5. 如何构建负责任的 AI 使用框架与其纠结“用还是不用”不如思考“怎么用才算负责任”。无论你是开发者、管理者还是行业专家下面这套框架都值得参考。5.1 明确 AI 的角色辅助者不是决策者在任何高风险场景中AI 都应该被定位为“辅助者”。它的决策和建议只能作为参考最后一步必须有人工复核。以软件开发为例AI 生成的代码必须经过 code reviewAI 提供的依赖版本必须经过安全扫描AI 写的测试用例必须确认断言是否正确。一个简单的做法是给 AI 的输出打标签。比如场景AI 角色人工职责代码生成草稿提供者逐行审查、运行测试、安全评审代码解释信息提供者对照源码验证准确性测试生成用例建议者补充边界条件、确认断言文档编写初稿生成者核对技术细节、修订版本描述5.2 建立“可解释”的 AI 使用流程如果一个流程完全依赖“AI 说什么就是什么”出了问题就会变成“甩锅大会”。更好的做法是建立可追溯的使用流程。比如团队在引入 AI 辅助开发时可以约定AI 生成的代码必须记录使用的模型和提示词。代码提交时必须包含“AI 辅助”或“人工编写”标注。AI 产出的代码必须通过自动化测试和同行评审。高风险模块支付、鉴权、数据删除禁止直接使用 AI 生成代码必须人工设计后由 AI 补全。定期对 AI 辅助代码做安全审计。听起来繁琐但这是把“AI 使用”纳入工程规范的最直接方式。5.3 “不用 AI”什么时候是正当的“不用 AI”未必就是过失。在以下情况下不用 AI 反而是合理选择数据安全不允许无法在满足合规要求的前提下使用外部 AI 服务。结果不可验证AI 的输出无法在合理时间内被验证其正确性。场景风险过高AI 的错误会造成不可逆的严重后果。行业规范未确立领域内没有形成“AI 辅助为必须”的共识。工具能力不足当前的 AI 工具在该任务上的表现不稳定。如果你因为上述原因拒绝使用 AI最好的做法不是口头说明而是把这些理由书面化、流程化。比如提交一份“AI 使用风险评估报告”说明为什么当前场景不适合引入 AI以及你采用了哪些替代方案来保证质量。这样即使将来被追责也能证明你尽到了注意义务。5.4 个人层面把“AI 素养”当成专业能力无论是“用 AI”还是“不用 AI”背后真正需要的是AI 素养。这包括知道什么时候该用 AI。知道什么时候不该用 AI。知道 AI 可能在哪里犯错。知道如何验证 AI 的输出。知道如何向不懂技术的人解释 AI 的风险。知道如何在合规边界内使用 AI。这已经不仅仅是训练一个模型或者调用一个 API 的问题而是一种工程化、体系化的能力。6. 高风险场景与排查思路结合前文的讨论下面整理几个常见的高风险场景以及对应的“排查”思路。这里的“排查”不是排查代码 bug而是排查 AI 使用流程中的责任风险。场景风险点排查思路开发者用 AI 生成登录鉴权代码鉴权逻辑存在安全漏洞AI 未识别必须人工 code review 安全测试不能直接上线律师用 AI 检索判例AI 编造不存在的案例使用可信法律数据库交叉验证记录检索来源医生用 AI 辅助影像筛查AI 漏检或过度标注建立双人复核机制AI 结果只作为“第二意见”团队用公共 AI 工具处理内部代码数据泄露风险部署私有化模型或在发送前做脱敏处理数据分析师用 AI 写 SQL 做报表查询逻辑错误导致数据失真验证结果行数、关键指标并与历史报表对照产品上线 AI 功能未提示风险用户基于 AI 结果做重大决策产品界面必须标注 AI 局限性提供人工渠道管理者强制推广 AI 但未培训员工误用引发事故制定 AI 使用规范安排培训建立反馈通道这组表格的价值在于不要等出事之后再讨论责任而是在流程设计阶段就把责任边界写清楚。7. 隐私、安全与合规一个不可回避的底座7.1 数据分类分级是前提在讨论“该不该用 AI”之前先要回答一个问题你的数据能不能交给 AI这里建议团队提前做数据分级数据级别示例AI 使用策略L1 公开开源代码、公开文档可以使用任何 AI 工具L2 内部内部设计文档、非敏感配置可以使用企业认可的 AI 工具但不允许上传源代码L3 机密核心业务代码、客户数据仅允许私有化部署的模型处理L4 绝密加密密钥、未公开财报、批量用户隐私禁止任何 AI 工具处理没有这个分级谈“用 AI 还是不用 AI”都是空谈。7.2 最小权限与可审计企业引入 AI 工具时建议做到AI 工具的账号权限遵循最小权限原则。所有发给 AI 的请求都要有日志。敏感数据必须先做匿名化、脱敏再进入 AI 工具。定期审计 AI 工具的使用记录排查异常请求。这既是安全要求也是将来“证明自己尽到注意义务”的证据。7.3 生产环境变更要有评审如果你的团队正在尝试把 AI 接入生产环境比如用 AI 做代码自动修复、自动发布、自动扩缩容请务必先经过变更评审。任何生产环境的自动化改动都应该具备变更前备份。最小灰度范围。快速回滚方案。监控告警。责任人的审批记录。这不仅是工程规范也是降低“过失”风险的基础设施。8. 最佳实践给自己和团队设计一份“AI 使用免责声明”最后给一个可直接落地的建议无论你是个人还是团队都建议编写一份“AI 使用说明与边界清单”。清单可以包括以下内容AI 工具列表哪些允许用哪些不允许用。允许输入的数据级别参考上面的 L1-L4 分级。需要人工复核的场景。禁止 AI 直接决策的场景。出错时的上报与追责流程。AI 输出结果的保存方式。定期审查周期。比如一个后端团队可以这样写# AI 辅助开发使用规范 ## 允许使用的 AI 工具 - Cursor已对接企业代理数据不回传外部 - 内部部署的代码补全模型 ## 禁止输入的数据 - 数据库连接串 - 密钥类文件 - 客户个人隐私数据 - 未公开的商业计划文档 ## 必须人工复核的场景 - 登录与权限模块 - 支付相关代码 - 数据迁移脚本 - 涉及删除操作的 SQL ## AI 代码提交要求 - 提交信息中必须标注 [AI Generated] - 必须有至少一名同事 review - 高危模块必须增加自动化安全扫描这样的文件不需要多复杂但它能解决一个核心问题当风险发生时你和你的团队能证明自己已经做了合理规划而不是在无序中使用 AI。9. 总结与后续思考回到标题的问题“Can NOT using AI amount to negligence”目前最准确的答案是在某些特定条件下答案是 yes但在绝大多数行业条件尚未成熟。真正决定你是否过失的不是你用不用 AI而是你有没有在具体场景中尽到“合理注意义务”。如果你没用 AI但你通过其他严谨流程达到了同等或更高的质量你没有过失如果你用了 AI但完全放弃审查那一样可能构成过失。对技术人来说与其焦虑“将来会不会因为不用 AI 被追责”不如现在就把三件事做好提升自己的 AI 素养该用的时候能安全地用不该用的时候能清晰解释为什么不安全。把 AI 使用流程化、可审计、可追溯避免“甩锅式”管理。关注所在行业的规范和标准当行业把 AI 纳入“合理标准”时你已经提前准备好应对方案。未来几年随着 AI 工具稳定性提升、监管规则完善、行业案例积累“哪些岗位必须使用 AI”“哪些决策不能交给 AI”会越来越被写进行业规范。到那时候今天讨论的“两难”也许会变成一个更清晰的规则体系。现阶段最稳妥的姿态是做一个既能用 AI 提升效率又能为 AI 结果负责的人。这比纠结“用还是不用”更有价值。如果这篇文章对你有帮助可以收藏备用。也欢迎在评论区聊聊你在实际工作中遇到过的“AI 使用两难”场景大家一起讨论比一个人纠结更有用。