这次我们不聊具体某个开源模型而是聊一个让 AI 工程师和产品经理都越来越头疼的问题当 AI 变成了行业标配你不用 AI 算不算失职甚至连“用了但没用好”都可能成为责任认定的一部分。这个标题非常直白“Damned if you do and damned if you dont: Can NOT using AI amount to negligence?”翻译过来就是“用 AI 也错不用 AI 也错不使用 AI 是否构成过失”这不是哲学讨论而是正在进入法律、医疗、金融、工程设计等专业领域的一个现实问题。尤其对做 AI 落地的人来说它直接影响交付标准、合规边界、责任划分和工程实践方式。本文会拆解这个问题的核心逻辑什么时候“不用 AI”会被认为不专业什么时候“用 AI”反而要承担更大责任以及作为开发者和技术决策者应该如何设定一套可复核、可追责、风险可控的 AI 使用流程。1. 核心问题拆解不使用 AI 是否构成过失先把这个标题里的法律概念说清楚。“negligence”在普通法体系里指“过失”认定通常需要满足几个条件行为人负有某种注意义务duty of care行为人违反了这种义务breach of duty违反义务造成了损害causation损害是可以预见且实际发生的damage。注意这不是刑法意义上的“犯罪”而是民事侵权、职业责任、医疗责任、工程责任里最常见的归责逻辑。过去注意义务的衡量标准是“一个合理谨慎的专业人士在同样情况下会怎么做”。现在问题来了如果这个“合理谨慎的专业人士”已经开始使用 AI 工具辅助诊断、审查代码、分析合同、计算结构安全那么继续沿用传统人工方式的人是否已经低于注意义务的标准从逻辑上看答案是有条件地成立。关键条件包括行业是否已经形成使用 AI 的普遍实践。如果只是极少数先驱在用那不用不构成过失如果主流机构都已经把 AI 纳入标准流程那不用就需要合理解释。AI 是否能够显著降低可预见的风险。比如在医学影像筛查中AI 辅助已经证明可以减少漏诊率如果医生拒绝使用且出现漏诊法院更有可能追问“为什么不用”。是否有替代措施。如果团队通过加强人工复核、增加质检环节达到同样效果那么不用 AI 也不一定构成过失。所以这个标题真正想说的是AI 时代职业责任的标准正在发生位移。过去是“你按传统规范做了就没有过错”现在是“你按传统规范做但传统规范可能已经不够了”。从工程实践角度看这不是教你如何规避法律风险而是提醒所有做 AI 项目的人你以为你在做技术选型其实你在帮客户定义未来几年内的“职业注意义务标准”。2. 适用场景与使用边界哪些行业最容易陷入这种困境不是所有行业都必须用 AI。是否构成过失要看这个行业的风险密度、AI 成熟度和监管态度。下面这几个场景是讨论热度最高、也最容易出现责任争议的领域。2.1 医疗健康AI 辅助诊断与漏诊责任医疗影像、病理分析、心电图解读、药物相互作用检查这些领域已经有大量临床验证的 AI 工具。如果某家医院有 AI 辅助筛查系统但医生没看 AI 提示最终漏诊患者家属完全可以质疑“为什么没有使用已采购的辅助系统”。反过来如果医生完全依赖 AI忽略了患者症状也存在过度依赖的过失。这里的边界很清楚AI 是“辅助”不能替代临床决策但拒绝使用成熟的辅助工具本身可能成为过失的证据。2.2 代码开发与软件质量AI 代码审查和自动测试软件工程里漏洞造成的数据泄露、财产损失已经有不少法律判例。现在 GitHub Copilot、SonarQube AI、自动化测试平台已经被广泛使用。如果你是外包公司合同里写了“按行业最佳实践交付”但你完全不用 AI 辅助代码审查而其他同类公司都用那一旦出现严重安全问题客户追责时你很难解释。但要注意AI 代码提示本身有版权和许可风险。直接复制 AI 生成的代码到商业项目里如果这段代码与某开源项目高度相似可能造成侵权。所以“用了 AI”不等于“尽到了注意义务”还要有审查机制。2.3 金融风控反欺诈模型与合规审查银行、支付机构、保险公司的反欺诈系统早就用上了机器学习。如果一个中小金融机构因为人手不足坚持纯人工规则审核导致大规模欺诈事件监管机构大概率会追问“为什么没有建立模型风控体系”。这里的“AI”未必是大模型也可能是传统机器学习模型但本质上都属于“智能化工具”。边界在于AI 决策必须可解释、可审计。你不能说“模型拒绝了这笔贷款”就完事要能给出拒绝的理由。如果不具备可解释性使用 AI 反而会放大合规风险。2.4 法律与合规审查AI 合同审查和尽职调查法律行业对 AI 的使用越来越普遍。合同审查工具可以快速扫描风险条款尽职调查工具可以批量分析工商信息。如果律所在大额交易中漏掉了一个关键条款而同类律所已经在使用 AI 审查流程客户完全可以主张“服务未达到行业标准”。但法律文书的准确性要求极高AI 幻觉是致命问题。所以实践中通常是“AI 初筛 律师复核”。这里的核心是流程留痕不是“用没用 AI”的问题而是“谁能证明你做了足够的努力”。2.5 工程设计AI 辅助计算和结构分析建筑设计、机械设计、土木工程里AI 辅助优化已经非常普遍。如果某个设计团队为了省成本拒绝使用行业通用的仿真优化工具导致结构缺陷事故调查时就会追问“有没有进行充分的仿真分析”。这里的边界是AI 计算不能替代物理公式和工程力学原则。AI 优化结果必须经过传统计算复核。两者结合才是行业认可的做法。2.6 不适合强制使用 AI 的场景法律规定必须人工审核的环节比如司法判决、行政审批涉及核心商业秘密且 AI 服务商无法保证数据隔离的场景AI 输出无法验证正确性的高精度计算场景客户明确书面要求不使用 AI 的服务项目。在这些场景里拒绝使用 AI 不仅不构成过失反而是正确的合规选择。关键要留下决策记录说明为什么不用避免未来被追责时没有依据。3. AI 责任认定的技术基础可记录、可追溯、可解释讨论“过失”不能只讲概念落到工程上就是三个能力可记录、可追溯、可解释。没有这三条无论你用不用 AI都很难自证清白。3.1 可记录Logging所有 AI 调用都应该有完整的日志。包括调用的模型版本输入数据的摘要或哈希输出内容推理参数温度、top_p、步数等调用时间调用人/系统标识。这样将来如果出问题至少能回放“当时系统看到了什么、输出了什么”。如果连日志都没有法律上基本无法证明你做了什么处理。3.2 可追溯Traceability可追溯是说每一个 AI 输出都能追溯到数据源、模型版本和触发链路。比如医疗 AI 给出一个诊断建议你要能回答这个建议基于哪些影像特征模型训练数据包含哪些病例类型模型在哪个版本下生成的输出工程上建议建立模型版本管理和数据血缘管理。不要把 AI 系统当成黑盒子要像管理代码依赖一样管理模型和数据的依赖关系。3.3 可解释Explainability可解释不是要求每个模型都输出自然语言解释而是说决策过程必须有可解读的特征依据。比如风控模型拒绝一个贷款申请至少要输出影响决策的关键因子排名。图像模型识别出病变区域至少要标注热力图。从法律责任角度讲完全不可解释的 AI 输出很难作为“已尽注意义务”的证据。相反如果 AI 输出伴随特征解释那就可以作为支持决策的辅助材料。3.4 实践建议建立 AI 使用台账建议每个正式项目都维护一份 AI 使用台账记录以下内容| 项目阶段 | 使用的 AI 工具 | 模型版本 | 用途 | 人工复核人 | 复核结果 | 风险备注 | | --- | --- | --- | --- | --- | --- | --- | | 需求分析 | ChatGPT-4o | 2025-05 | 生成需求文档草稿 | 张三 | 已修改第三章节 | 注意数据脱敏 | | 代码审查 | SonarQube AI | 9.9 | 静态代码扫描 | 李四 | 修复 3 个高危漏洞 | 无 | | 合同审查 | Coze 法务插件 | 1.2 | 风险条款提取 | 王五 | 补充了违约金条款 | 未见异常 |这张表本身就是“尽职”的证据。无论是客户问、监管查还是法院审这张表比任何口头解释都有用。4. 工程实践构建合规的 AI 工作流与其纠结“用不用 AI 算不算过失”不如直接设计一套默认合规的 AI 工作流。下面给出一个通用模板适用于大部分本地部署或云端调用的 AI 工具。4.1 第一阶段AI 预检在正式使用 AI 工具之前先做四个检查数据合规检查输入数据是否包含个人敏感信息、商业秘密、未公开的财务数据如果有必须脱敏或使用本地私有化部署模型。模型合规检查模型许可证是否允许商用训练数据是否包含受版权保护的内容如果模型是学术研究用途商用会出问题。输出合规检查AI 输出内容是否可能包含版权风险如果需要商用建议做一次查重。场景评估这个场景是否允许 AI 参与是否有法律明确禁止 AI 介入的环节这四个检查做完基本能规避 80% 的合规风险。4.2 第二阶段AI 执行与日志执行阶段要保证日志完整。下面是一个简单的本地调用 Python 示例包含日志记录逻辑import json import hashlib import datetime import requests def call_llm_with_log(prompt, model_name, api_url, api_key, log_file): # 记录输入摘要 input_hash hashlib.sha256(prompt.encode(utf-8)).hexdigest() payload { model: model_name, prompt: prompt, temperature: 0.7, max_tokens: 1024 } headers { Authorization: fBearer {api_key}, Content-Type: application/json } start_time datetime.datetime.now().isoformat() response requests.post(api_url, jsonpayload, headersheaders, timeout120) result response.json() end_time datetime.datetime.now().isoformat() log_entry { timestamp_start: start_time, timestamp_end: end_time, model: model_name, input_hash: input_hash, prompt_excerpt: prompt[:200], output_excerpt: result.get(output, )[:200], status_code: response.status_code, latency_ms: (datetime.datetime.fromisoformat(end_time) - datetime.datetime.fromisoformat(start_time)).total_seconds() * 1000 } with open(log_file, a, encodingutf-8) as f: f.write(json.dumps(log_entry, ensure_asciiFalse) \n) return result # 示例调用 # result call_llm_with_log( # prompt请审查以下合同条款中的风险点..., # model_nameqwen2.5-14b-instruct, # api_urlhttp://127.0.0.1:8000/v1/chat/completions, # api_keylocal-test-key, # log_file./logs/ai_call_20250501.jsonl # )这里的关键不是代码本身而是记录输入哈希和输出摘要。这样即使未来磁盘上的日志被清理依然能通过哈希验证某条输出是否来自特定输入。4.3 第三阶段人工复核AI 输出必须有人工复核环节这是判定“是否尽到注意义务”的核心。复核工作不能只写“已复核”要具体到复核人复核时间是否有修改修改内容最终审批人。示例复核记录{ ai_output_id: 20250501-001, reviewer: 张三, review_time: 2025-05-01 14:30:00, original_output: ..., revised_content: ..., revision_reason: 第三条款存在歧义已改为更明确的表述, final_approver: 李四 }如果团队做到这一步即使未来发生争议“人工复核”这层屏障也足以说明你并未盲目依赖 AI。4.4 第四阶段定期审计建议每季度做一次 AI 使用审计重点检查有没有未记录日志的 AI 调用有没有跳过人工复核流程有没有使用未经合规检查的新模型有没有把敏感数据发送到外部 API。审计结果形成报告留存备查。这种做法一方面是合规要求另一方面也是工程管理的常识你不可能管理一个看不见的 AI 系统除非你定期检查它到底做了什么。5. 接口 API 与批量任务的合规设计风险最高的往往不是单次调用而是批量任务。比如批量生成营销文案、批量审核合同、批量处理用户提交的图片。批量任务一旦出错影响范围会成倍放大。所以必须设计闭环。5.1 批量任务队列推荐用目录加任务状态文件的方式管理批量任务简单且可审计batch_20250501/ ├── input/ │ ├── 001.txt │ ├── 002.txt │ └── 003.txt ├── output/ │ ├── 001_result.txt │ ├── 002_result.txt │ └── 003_result.txt ├── log/ │ ├── call_001.json │ ├── call_002.json │ └── call_003.json └── review/ ├── 001_reviewed.md ├── 002_reviewed.md └── 003_reviewed.md每个子目录对应一个任务单元。输入和输出一一对应日志和人工复核记录一一对应。将来出问题直接按任务编号回溯即可。5.2 批量处理脚本示例下面是一个简单的批量调用本地 API 脚本带失败重试和日志import os import json import time import requests from pathlib import Path API_URL http://127.0.0.1:8000/v1/chat/completions API_KEY local-test-key INPUT_DIR Path(./batch_20250501/input) OUTPUT_DIR Path(./batch_20250501/output) LOG_DIR Path(./batch_20250501/log) def process_one(file_path): text file_path.read_text(encodingutf-8) payload { model: local-llm, messages: [{role: user, content: text}], temperature: 0.3, max_tokens: 2048 } headers {Authorization: fBearer {API_KEY}} for attempt in range(3): try: resp requests.post(API_URL, jsonpayload, headersheaders, timeout60) if resp.status_code 200: return resp.json() except requests.exceptions.RequestException: pass time.sleep(2 ** attempt) # 指数退避 return None def main(): OUTPUT_DIR.mkdir(parentsTrue, exist_okTrue) LOG_DIR.mkdir(parentsTrue, exist_okTrue) for file_path in sorted(INPUT_DIR.glob(*.txt)): result process_one(file_path) out_file OUTPUT_DIR / f{file_path.stem}_result.txt log_file LOG_DIR / f{file_path.stem}.json if result: content result.get(choices, [{}])[0].get(message, {}).get(content, ) out_file.write_text(content, encodingutf-8) log_entry { input_file: file_path.name, success: True, output: content[:500] } else: out_file.write_text(ERROR: 调用失败, encodingutf-8) log_entry { input_file: file_path.name, success: False, error: 调用失败已重试 3 次 } with open(log_file, w, encodingutf-8) as f: json.dump(log_entry, f, ensure_asciiFalse, indent2) print(f处理完成: {file_path.name}) if __name__ __main__: main()从合规角度看批处理脚本最重要的是失败留痕。不要用静默失败每条失败记录必须写明原因。未来即使出现少量失败只要能证明不是系统性遗漏责任认定也会更清晰。5.3 接口访问控制如果 AI 服务是部署在服务器上的 API千万不要把所有端口暴露到公网。建议只监听本机或内网 IP使用 API Key 鉴权对调用频率做限制记录调用方 IP 和调用时间如果必须外网访问使用网关加白名单。下面是简单的 fastapi 服务限制访问示例from fastapi import FastAPI, HTTPException, Header app FastAPI() API_KEYS {test-key-123} app.post(/v1/chat/completions) def chat_completions(authorization: str Header(default)): token authorization.replace(Bearer , ).strip() if token not in API_KEYS: raise HTTPException(status_code401, detailInvalid API key) # 处理请求 return {message: ok}不要觉得这些是多余的安全措施。一旦 AI 接口被未授权访问可能产生大量不合法输出到时候你就变成了“AI 滥用”的责任方。6. 资源占用与性能观察AI 决策系统需要可测这条可能看起来和“过失”没关系但实际上关系很大。任何一个 AI 责任认定最后都要落到“这个系统在事发时是否正常工作”。如果系统在高峰期响应超时、显存不足、调用失败那么错误输出可能不是 AI 模型的问题而是系统稳定性问题。这时候“是否尽到注意义务”就变成了“是否对 AI 系统做了充分的性能保障”。6.1 如何观察显存占用在 Linux 下用nvidia-smi定时记录显存使用nvidia-smi --query-gputimestamp,memory.used,memory.total,utilization.gpu --formatcsv -l 5每秒记录一次显存和 GPU 利用率生成 CSV 文件。之后如果出现性能问题可以直接分析这个文件定位是显存不足还是引擎瓶颈。6.2 推理参数对资源的影响大模型推理中以下几项会显著影响显存和响应时间max_tokens / max_length越长显存占用越高batch_size批量推理时batch_size 越大显存占用指数增长并发请求数并发过高会导致显存溢出或请求排队上下文长度输入文本越长显存占用越大。建议先小参数测试再逐步增加。在正式业务上线前做一次压测给出系统的最大并发量和平均响应时间。6.3 性能监控与过失认定的关系如果因为系统资源不足导致 AI 调用失败而你又没有日志证明失败原因那责任认定时可能会被解释为“故意忽略系统故障”。所以AI 系统的监控日志本身就是合规材料。不要只保存业务日志也要保存系统资源日志。7. 常见问题与排查方法围绕“不使用 AI 是否构成过失”工程侧常见的问题一般不是模型本身而是流程和管理。下面整理了一份排查表。问题现象可能原因排查方式解决方案客户质疑没有使用 AI 导致质量问题项目流程中未体现 AI 应用检查项目文档和提交物补充 AI 使用台账和输出记录使用了 AI 但结果出错被追责AI 输出未经人工复核查询复核记录建立强制人工复核节点本地部署 AI 服务经常崩溃GPU 显存不足或并发过高查看 nvidia-smi 日志降低并发数升级配置或分批推理AI 模型输出包含版权风险内容未对输出做查重检查生成记录增加输出合规检查环节批处理任务中途失败结果不完整脚本无重试和日志查看任务目录增加重试机制和失败日志接口被非法调用产生违规内容服务暴露在公网且无鉴权检查访问日志限制监听地址增加 API Key 鉴权模型版本混淆输出结果不一致未做模型版本管理查看模型加载路径使用版本化目录或模型注册表AI 工具处理了敏感数据未做数据脱敏检查输入日志增加脱敏流程或使用私有化部署这些问题的共性特点是都不是模型能力问题而是流程和工程管理问题。你的 AI 能力再强如果流程不闭环一样会在责任认定上吃亏。8. 最佳实践与使用建议下面是从技术和责任两个角度总结的最佳实践。8.1 技术层面先小参数测试再上生产。任何 AI 工具第一次使用都要用小规模数据验证输出质量不要直接批处理。保留最小可运行配置。把一套覆盖“模型加载 API 服务 日志 人工复核”的最小配置放在版本控制里新的项目直接复制。输入、输出、日志分开存储。不要把所有文件堆在一个目录按时间或批次建目录。模型版本固定。不要随意升级模型升级前先对比测试并更新台账。批量任务必须加失败重试。网络超时、显存溢出、服务重启都会导致任务失败没有重试机制一次故障就可能造成全批失败。8.2 流程层面建立 AI 使用审批机制。哪些项目能用 AI哪些环节必须人工先列清单再执行。数据脱敏和访问控制并行。不能只依赖脱敏也要限制 AI 工具的访问权限。每个 AI 输出都有对应复核人。这条如果做不到就不要正式使用 AI 产生交付物。定期审计 AI 使用记录。审计不只是查问题也是固定证据链。8.3 合规层面涉及人脸、声音、医疗健康、财务数据等敏感信息时优先使用本地私有化模型避免敏感数据外流。商用前必须检查模型许可证。开源模型不一定都能商用例如某些模型使用非商业许可。涉及版权素材时输入提示词和输出内容都要确认授权。AI 生成的图片、视频、文字如果用于商业发布必须有版权合规审查。AI 辅助决策不能完全自动化。法律、医疗、金融等高风险领域必须保留人工决策节点。记录拒绝使用 AI 的理由。如果某个环节决定不用 AI要在项目文档里写明原因避免事后被质疑。8.4 实际案例模拟假设你是一家软件外包公司的技术负责人客户要求两个月内交付一套合同 OCR 识别系统。你为了效率直接调用了云端通用大模型的 OCR 能力。结果客户的合同里有大量公司名称和金额这些数据被发送到云端发生数据泄露。客户起诉时法院首先会问你为什么没有评估数据合规你为什么没有使用本地 OCR 模型如果你当时做了数据合规检查选择本地部署 OCR 模型并在日志中记录了所有调用即使效果差一点也不构成过失。相反如果你为了追求效果用了云端模型还没有数据隔离协议那问题就严重得多。这个例子说明“用不用 AI”不是核心“用什么 AI、怎么用 AI、有没有留痕”才是核心。9. 总结与下一步“不使用 AI 是否构成过失”这个问题最终会演变成一句话在你所在的行业一个合理谨慎的专业人士是否已经在使用 AI如果答案是肯定的那么你不用 AI 就需要解释如果答案是否定的那么你用 AI 反而需要证明你尽到了更多注意义务。对技术人来说最值得做的三件事建立 AI 使用台账。从今天开始记录每个项目使用了哪些 AI 工具、输出是什么、谁复核了。这是未来最有效的免责证据。为高风险场景设计人工复核节点。无论模型多强都要在关键决策链上保留人工审批。给 AI 调用加日志和数据血缘。没有日志的 AI 系统等于没有刹车和黑匣子的车。下一步建议先在自己团队内部做一个 AI 使用现状盘点当前哪些环节用了 AI哪些环节没有用哪些环节用了但没有日志哪些环节用了但没有人工复核把这张盘点表做出来你就能清楚看到自己和行业标准之间的距离。AI 不应该被当成万能工具也不应该因为害怕承担责任而完全回避。真正聪明的做法是把 AI 放到一个可以被审计、被复核、被追溯的工程框架里。这样无论未来是“不用 AI 被追责”还是“用了 AI 被追责”你都有完整的记录证明自己尽到了合理的注意义务。