简答:使用生成式人工智能的开发者要对整个系统负责,而不仅仅是模型的输出。当人工智能影响决策、代码、隐私或用户信任时,他们必须选择安全的应用,验证结果,保护数据,减少危害,并确保人们可以审查、推翻和纠正错误。
要点总结:
验证:在来源、测试或人工审核确认之前,请勿对已完善的输出结果表示信任。
数据保护:尽量减少提示数据,删除标识符,并保护日志、访问控制和供应商。
公平性:在不同人口统计特征和背景下进行测试,以发现刻板印象和不均衡的失败模式。
透明度:明确标注人工智能的使用,解释其局限性,并提供人工审核或申诉。
问责制:在发布前,明确部署、事件、监控和回滚的责任人。

您可能还想阅读以下文章:
🔗 面向软件开发人员的最佳人工智能工具:顶级人工智能编码助手
比较顶级AI编码助手,实现更快、更简洁的开发工作流程。.
🔗 十大提升开发者生产力的AI工具
提升编码智能度和速度的开发者AI工具排名列表。.
🔗 为什么人工智能会对社会和信任造成危害
解释了现实世界的危害:偏见、隐私、就业和虚假信息风险。.
🔗 人工智能在高风险决策中是否走得太远了?
定义人工智能何时越界:监视、深度伪造、诱导、未经同意。.
为什么开发者在使用生成式人工智能时的责任比人们想象的更重要?
很多软件漏洞都很烦人。按钮失灵,页面加载缓慢,程序崩溃,大家都唉声叹气。.
生成式人工智能问题可能各不相同,也可能很微妙。.
一个模型即使出错,听起来也可能很自信。NIST GenAI 概况:它可以在没有明显预警的情况下重现偏见。NIST GenAI 概况:如果使用不当,它可能会泄露敏感数据。OWASP十大 LLM 应用风险 ;ICO 针对生成式人工智能的八个问题:它可以生成运行正常的代码——直到在生产环境中以某种极其尴尬的方式崩溃。OWASP十大 LLM 应用风险:这就像雇佣了一个热情过头、从不睡觉、并且时不时会以惊人的自信编造事实的实习生。
因此,使用生成式人工智能的开发者的责任远不止于简单的实现。他们不再仅仅构建逻辑系统,而是构建具有模糊边界、不可预测输出和真实社会后果的概率系统。NIST AI RMF
这意味着责任包括:
-
NIST AI RMF模型的局限性
-
保护用户隐私: ICO关于人工智能和数据保护的指导意见
-
减少有害输出NIST GenAI 概况
-
在授予信任之前检查准确性NIST GenAI 配置文件
-
明确人的角色经合组织人工智能原则
-
当人工智能失效时设计备用路径;经合组织人工智能原则;国家网络安全 中心安全人工智能指南
-
以清晰易懂的方式记录系统,符合经合组织人工智能原则
你知道的,当一个工具用起来感觉神奇时,人们就会停止质疑它。开发者可不能掉以轻心。.
开发者在使用生成式人工智能时,怎样的责任才算好的责任?🛠️
真正的责任感并非流于形式,它不是在文章末尾加上免责声明就美其名曰“道德”。它体现在设计选择、测试习惯和产品行为中。.
使用生成式人工智能的开发者应强有力责任的典型
-
有意使用 NIST AI RMF
-
人工智能正被用于解决实际问题,而不是因为听起来时髦就强行塞进产品里。.
-
-
经合组织人工智能原则中的人工监督
-
用户可以查看、更正、覆盖或拒绝输出结果。.
-
-
-
风险控制措施应该尽早建立,而不是事后临时拼凑上去。.
-
-
-
用户能够分辨内容是人工智能生成的还是人工智能辅助生成的。.
-
-
数据保护 ICO针对生成式人工智能提出的八个问题
-
敏感信息会受到谨慎处理,访问权限也受到限制。.
-
-
公平性检查 NIST GenAI Profile ICO 关于人工智能和数据保护的指导意见
-
该系统经过测试,以检测是否存在偏差、性能不均和有害模式。.
-
-
持续监测 NIST AI RMF NCSC 安全 AI 指南
-
发布并非终点,更像是发令枪响。.
-
如果这听起来很多,嗯……确实很多。但这就是当你使用能够大规模影响决策、信念和行为的技术时所面临的情况。经合组织人工智能原则
对比表——开发者使用生成式人工智能的核心职责一览📋
| 责任领域 | 它会影响哪些人 | 日常开发者实践 | 为什么这很重要 |
|---|---|---|---|
| 准确性和验证 | 用户、团队、客户 | 审查输出结果,添加验证层,测试边界情况 | 人工智能可以非常流畅,但仍然可能犯下严重的错误——NIST GenAI Profile |
| 隐私保护 | 用户、客户、内部员工 | 尽量减少敏感数据的使用,清理提示信息,控制日志 | 一旦私人数据泄露,就无法挽回了😬 ICO 针对生成式人工智能的八个问题 OWASP 法学硕士应用十大问题 |
| 偏见与公平 | 代表性不足的群体,所有用户 | 审计输出,测试各种输入,调整保障措施 | 危害并非总是显而易见——有时它是系统性的、悄无声息的。NIST GenAI Profile ICO 关于人工智能和数据保护的指导 |
| 安全 | 公司系统、用户 | 限制模型访问,防御即时注入,对风险操作进行沙箱隔离 | 一个巧妙的漏洞就能迅速摧毁信任;OWASP Top 10 for LLM Applications; NCSC on AI and cyber security |
| 透明度 | 最终用户、监管机构、支持团队 | 明确标注人工智能行为,解释其局限性,记录使用情况 | 人们有权知道机器何时在协助OECD人工智能原则 关于人工智能生成内容标记和标注的实践准则。 |
| 问责制 | 产品负责人、法务、开发团队 | 明确责任归属、事件处理和升级路径 | “是人工智能干的”并不是一个成熟的答案。经合组织人工智能原则 |
| 可靠性 | 所有接触过该产品的人 | 监控故障,设置置信阈值,创建备用逻辑 | 模型会发生漂移,以意想不到的方式失效,并且时不时会出现一些小插曲。NIST AI RMF NCSC 安全 AI 指南 |
| 用户福祉 | 弱势用户尤其如此 | 避免操纵性设计,限制有害输出,审查高风险用例 | 仅仅因为某样东西可以生成,并不意味着它就应该被生成。人工智能原则、美国国家标准与 技术研究院人工智能风险管理框架(RMF) |
桌子略微不平整,没错,但这正契合主题。真正的责任分配也是不均衡的。.
责任始于第一个提示之前——选择正确的用例🎯
开发者最重要的职责之一是决定是否应该使用生成式人工智能。NIST AI RMF
这听起来显而易见,但却经常被忽略。团队看到一个模型,兴奋不已,然后开始强行将其应用到工作流程中,而实际上,规则、搜索或普通的软件逻辑更能有效地处理这些问题。并非所有问题都需要语言模型。有些问题只需要一个数据库和一个安静的下午。.
在建造之前,开发人员应该问:
-
这项任务是开放式的还是确定性的?
-
错误的输出会造成危害吗?
-
用户需要的是创造力、预测能力、总结能力、自动化功能,还是仅仅需要速度?
-
人们会过度信任输出结果吗? NIST GenAI 概况
-
人类真的能够对结果进行有效审查吗?经合组织人工智能原则
-
如果模型出错会发生什么?经合组织人工智能原则
负责任的开发者不会只问“我们能实现这个功能吗?”,他们还会问“这个功能应该这样实现吗?” NIST AI RMF
这个问题本身就能阻止很多华而不实的废话。.
准确性是一种责任,而非加分项 ✅
必须明确一点——生成式人工智能最大的陷阱之一就是把雄辩误认为真理。模型经常会生成听起来流畅、结构严谨且极具说服力的答案。这固然很好,但前提是内容本身是胡说八道,却又被自信所包装。NIST GenAI Profile
因此,使用生成式人工智能的开发者的责任之一就是构建可验证的系统。
这意味着:
-
尽可能使用检索或接地方法NIST GenAI 配置文件
-
将生成内容与已确认的事实区分开来经合组织人工智能原则
-
谨慎地添加置信阈值NIST AI RMF
-
为高风险产出创建审查工作流程经合组织人工智能原则
-
防止模型在关键情况下进行即兴发挥NIST GenAI 简介
-
试图破坏或误导系统的测试提示OWASP Top 10 针对 LLM 应用程序
这在以下领域至关重要:
-
卫生保健
-
金融
-
法律工作流程
-
教育
-
客户支持
-
企业自动化
-
代码生成
例如,生成的代码可能看起来很简洁,但实际上却隐藏着安全漏洞或逻辑错误。盲目复制的开发人员效率低下——他们只是以更美观的形式将风险外包出去。OWASP Top 10 for LLM Applications NCSC on AI and cyber security
该模型可以提供帮助。开发者仍对结果拥有所有权。经合组织人工智能原则
隐私和数据管理不容妥协🔐
事情很快就会变得棘手。生成式人工智能系统通常依赖于提示、日志、上下文窗口、内存层、分析和第三方基础设施。这为敏感数据泄露、持久化或以用户意想不到的方式被重用提供了大量机会。ICO针对生成式人工智能提出的八个问题 OWASP针对LLM应用的十大安全漏洞。
开发者有责任保护:
-
个人信息
-
财务记录
-
医疗详情
-
公司内部数据
-
商业秘密
-
身份验证令牌
-
客户沟通
负责任的做法包括:
-
最大限度地减少输入模型的数据量: ICO针对生成式人工智能提出的八个问题
-
屏蔽或移除NIST GenAI 配置
-
限制日志保留ICO 关于人工智能和数据保护的指导意见
-
控制谁可以访问提示和输出OWASP Top 10 for LLM 应用程序
-
仔细审查供应商设置,遵守NCSC安全人工智能指南
-
隔离高风险工作流程NCSC 安全人工智能指南
-
让用户了解隐私行为: ICO针对生成式人工智能提出的八个问题
在这个问题上,“我们忘了考虑”绝不是小错误,而是会破坏信任的重大失误。.
信任一旦破裂,就会像碎玻璃一样四处蔓延。这或许不是最贴切的比喻,但你明白我的意思。.
偏见、公平和代表性——这些不那么引人注目的责任⚖️
生成式人工智能中的偏见很少像卡通片里的反派那样令人厌恶,它通常比这更难以捉摸。模型可能会生成刻板的职位描述、不公平的审核决策、片面的推荐或文化狭隘的假设,而不会引发明显的警示。NIST GenAI Profile
因此,使用生成式人工智能的开发者的责任包括积极开展公平性工作。
开发者应该:
-
来自不同人口统计和背景的测试提示NIST GenAI 简介
-
NIST GenAI 简介中关于刻板印象和排斥的审查输出
-
NIST AI RMF时纳入多元视角
-
注意不均匀的故障模式NIST GenAI 概况
-
避免假设某种语言风格或文化规范适用于所有人。ICO关于人工智能和数据保护的指导意见
-
创建有害输出的报告渠道NIST AI RMF
一个系统整体运行良好,但某些用户的体验却始终不如其他用户。仅仅因为仪表盘上的平均性能看起来不错,这种现象是不可接受的。ICO关于人工智能和数据保护的指导意见,以及 NIST GenAI 规范。
没错,公平远比一份简洁的清单要难得多。它包含判断、背景、权衡取舍,甚至会带来一定程度的不适。但这并不能免除责任,反而更加凸显了责任的重要性。ICO关于人工智能和数据保护的指导意见
安全如今既是快速设计的一部分,也是工程学科的一部分🧱
生成式人工智能的安全是一个独特的问题。传统的应用程序安全当然仍然重要,但人工智能系统增加了不寻常的攻击面:提示注入、间接提示操纵、不安全工具使用、通过上下文窃取数据以及通过自动化工作流程滥用模型。OWASP Top 10 for LLM Applications NCSC on AI and cyber security
开发人员有责任确保整个系统的安全,而不仅仅是界面安全。NCSC安全人工智能指南
主要职责包括:
-
对不可信输入进行清理OWASP Top 10 for LLM 应用程序
-
限制模型可以调用的OWASP Top 10 for LLM 应用程序
-
限制文件和网络访问NCSC 安全人工智能指南
-
明确划分权限,符合NCSC安全人工智能指南
-
监控滥用模式NCSC 安全人工智能指南
-
限制昂贵或高风险操作的速率OWASP 十大 LLM 应用问题
-
测试对抗性提示OWASP Top 10 适用于 LLM 应用程序
-
当指令冲突时构建安全的备用方案OECD人工智能原则
一个令人不安的事实是,用户(以及攻击者)绝对会尝试开发者意想不到的操作。有些是出于好奇,有些是出于恶意,有些则是因为凌晨两点不小心点错了。这种情况时有发生。.
生成式人工智能的安全与其说是建造一堵墙,不如说是管理一个非常健谈的守门人,而这个守门人有时会被花言巧语所蒙蔽。.
透明度和用户同意比花哨的用户体验更重要🗣️
用户与人工智能交互时,应该了解人工智能的存在。经合组织人工智能原则 关于人工智能生成内容标记和标注的实践守则
不是含糊其辞,也不是晦涩难懂,而是清晰明了。.
使用生成式人工智能的开发者的核心职责之一是确保用户理解:
-
当人工智能被应用时,经合组织人工智能原则
-
人工智能能做什么和不能做什么经合组织人工智能原则
-
是否由人工审核输出结果经合组织人工智能原则
-
他们如何处理数据? ICO针对生成式人工智能提出的八个问题
-
NIST AI RMF抱有多大的信心?
-
如何报告问题或对决定提出申诉OECD人工智能原则 NIST人工智能风险管理框架
透明度不是为了吓唬用户,而是为了尊重用户。.
良好的透明度可能包括:
-
诸如“人工智能生成”或“人工智能辅助”之类的标签;关于人工智能生成内容标记和标注的实践准则
-
经合组织人工智能原则的简明解释
-
可见的编辑历史记录(如适用)
-
关闭人工智能功能的选项
-
必要时升级至人工干预 经合组织人工智能原则
-
欧盟委员会人工智能法案概述:针对高风险任务的简明警告
很多产品团队担心,坦诚会让功能显得不那么神奇。也许吧。但虚假的确定性更糟糕。一个掩盖风险的流畅界面,本质上只是精心包装的混乱。.
即使模型“做出决定”,开发者仍然要承担责任👀
这部分至关重要。责任不能外包给模型供应商、模型卡、提示模板,或是神秘莫测的机器学习领域。经合组织人工智能原则、美国国家标准 与技术研究院人工智能风险管理框架
开发者仍需承担责任。经合组织人工智能原则
这意味着团队中应该有人拥有:
-
模型选择NIST AI RMF
-
测试标准NIST GenAI 简介
-
发布标准NIST GenAI 简介
-
事件响应NCSC 安全人工智能指南
-
用户投诉处理NIST AI RMF
-
回滚程序经合组织人工智能原则
-
经合组织人工智能原则的变化跟踪
对于诸如此类的问题,应该有明确的答案:
-
谁批准部署? NIST GenAI 简介
-
谁负责审查有害输出事件? NIST GenAI 简介
-
谁可以禁用此功能?经合组织人工智能原则
-
谁负责监控回归? NIST AI RMF
-
当系统出现故障时,谁来与用户沟通?经合组织人工智能原则
没有责任感,责任就如同迷雾一般。每个人都以为别人会负责……结果却谁也没负责。.
事实上,这种模式比人工智能出现得更早。人工智能只是让它变得更加危险而已。.
负责任的开发者会为了纠错而开发,而不是为了追求完美🔄
这里有个小小的转折:负责任的人工智能开发并非假装系统完美无缺,而是假定它会在某些方面出现故障,并围绕这种现实进行设计。NIST AI RMF
这意味着要生产以下类型的产品:
-
可审计的 经合组织人工智能原则
-
决策和结果可以稍后进行审查。
-
-
可中断的 经合组织人工智能原则
-
人类可以阻止或纠正不良行为。
-
-
可恢复的 经合组织人工智能原则
-
当人工智能输出错误时,会有备用方案。
-
-
可监控的 NCSC 安全 AI 指南 NIST AI RMF
-
团队能够防患于未然,在灾难发生之前发现问题所在。
-
-
可改进的 NIST GenAI 概况
-
反馈回路是存在的,而且有人会阅读它们。
-
这才是成熟的体现。不是花哨的演示,也不是夸张的营销文案。而是真正的系统,配备防护措施、日志记录、问责机制,并且足够谦逊地承认机器并非万能。NCSC安全人工智能指南 OECD 人工智能原则
因为它不是工具。它只是一种工具。没错,它功能强大。但它终究只是一种工具。.
总结反思开发者在使用生成式人工智能时的责任🌍
使用生成式人工智能的开发者应该承担什么?
构建系统时要谨慎。要质疑系统在哪些方面有益,在哪些方面有害。要保护隐私。要测试是否存在偏见。要验证输出结果。要确保工作流程安全。要对用户保持透明。要确保人类拥有有效的控制权。要在出现问题时承担责任。NIST AI RMF OECD AI 原则
这听起来可能很沉重——也确实如此。但这恰恰是深思熟虑的开发与鲁莽的自动化之间的区别所在。.
使用生成式人工智能的最佳开发者并非那些让模型表演最多花招的人,而是那些理解这些花招后果并据此进行设计的人。他们明白速度固然重要,但信任才是真正的产品。令人惊讶的是,这种老派的理念至今仍然适用。NIST AI RMF
归根结底,责任并非创新的障碍。它反而能防止创新演变成一场耗资巨大、混乱不堪、界面精美却缺乏信任的闹剧😬✨
也许这是最简单的版本了。.
当然,要大胆建设——但要考虑到人们可能会受到影响,因为确实如此。经合组织人工智能原则
常问问题
在实践中使用生成式人工智能的开发者应承担哪些责任?
使用生成式人工智能的开发者的责任远不止于快速交付功能。它还包括选择合适的应用场景、测试输出结果、保护隐私、减少有害行为以及确保系统易于用户理解。实际上,开发者仍然需要对工具的设计、监控、修复以及故障处理等各个方面负责。.
为什么生成式人工智能需要开发者承担比普通软件更多的责任?
传统漏洞通常显而易见,但生成式人工智能的故障可能听起来很完美,但实际上仍然是错误的、带有偏见的或存在风险的。这使得问题更难发现,用户也更容易误信。开发人员正在使用概率系统,因此他们的责任包括在发布前处理不确定性、减少危害并做好应对不可预测输出的准备。.
开发者如何判断何时不应该使用生成式人工智能?
一个常见的出发点是询问任务是开放式的,还是更适合用规则、搜索或标准软件逻辑来处理。开发者还应该考虑错误答案可能造成的危害有多大,以及人类是否能够切实地审查结果。负责任的使用有时意味着完全不使用生成式人工智能。.
开发者如何才能减少生成式人工智能系统中的幻觉和错误答案?
准确性需要精心设计,而非想当然。在许多流程中,这意味着要将输出结果建立在可信来源之上,将生成的文本与经过验证的事实区分开来,并对高风险任务采用审核工作流程。开发人员还应该测试那些旨在混淆或误导系统的提示,尤其是在代码、支持、金融、教育和医疗保健等领域。.
开发者在使用生成式人工智能技术保护隐私和敏感数据时应承担哪些责任?
使用生成式人工智能的开发者有责任尽量减少输入模型的数据量,并将提示信息、日志和输出视为敏感信息。开发者应尽可能移除标识符,限制数据保留时间,控制访问权限,并仔细审查供应商设置。用户也应该能够了解自己的数据是如何被处理的,而不是事后才发现风险。.
开发者应该如何处理生成式人工智能输出中的偏见和公平性问题?
消除偏见需要积极评估,而非臆测。一个切实可行的方法是,针对不同的人群、语言和语境测试提示语,然后审查输出结果,找出是否存在刻板印象、排斥现象或不均衡的失败模式。开发人员还应创建用户或团队举报有害行为的机制,因为即使系统整体看起来强大,也可能持续地让某些群体失望。.
开发者在使用生成式人工智能时需要考虑哪些安全风险?
生成式人工智能引入了新的攻击面,包括快速注入、不安全工具使用、通过上下文泄露数据以及滥用自动化操作。开发者应过滤不受信任的输入,限制工具权限,限制文件和网络访问,并监控滥用模式。安全不仅仅关乎界面,它还适用于围绕模型的整个工作流程。.
为什么在使用生成式人工智能进行开发时,透明度至关重要?
用户应该清楚地了解人工智能何时介入、其功能以及局限性。良好的透明度可以包括使用“人工智能生成”或“人工智能辅助”等标签、提供简明易懂的解释以及提供清晰的人工支持途径。这种坦诚并不会削弱产品,反而有助于用户评估信任度并做出更明智的决策。.
当生成式人工智能功能造成损害或出错时,谁该承担责任?
即使模型给出了答案,开发人员和产品团队仍然要对结果负责。这意味着部署审批、事件处理、回滚、监控和用户沟通等方面的责任必须明确。“模型决定了结果”是不够的,因为责任必须始终由设计和发布系统的人员承担。.
发布之后,负责任的生成式人工智能开发会是什么样子?
负责任的开发工作在产品发布后仍将继续,包括监控、反馈、审查和修正。强大的系统应具备可审计性、可中断性和可恢复性,并设计有应对人工智能故障的备用方案。我们的目标并非追求完美,而是构建一个能够安全地进行检查、改进和调整的系统,以便应对现实世界中出现的问题。.
参考
-
美国国家标准与技术研究院 (NIST) - NIST GenAI 简介- nvlpubs.nist.gov
-
OWASP - OWASP 法学硕士申请十大热门问题- owasp.org
-
英国信息专员办公室 (ICO) - ICO 针对生成式人工智能提出的八个问题- ico.org.uk