簡答:使用生成式人工智慧的開發者要對整個系統負責,而不僅僅是模型的輸出。當人工智慧影響決策、程式碼、隱私或用戶信任時,他們必須選擇安全的應用,驗證結果,保護數據,減少危害,並確保人們可以審查、推翻和糾正錯誤。
重點總結:
驗證:在來源、測試或手動審核確認之前,請勿對已完善的輸出結果表示信任。
資料保護:盡量減少提示數據,刪除標識符,並保護日誌、存取控制和供應商。
公平性:在不同人口統計特徵和背景下進行測試,以發現刻板印象和不均衡的失敗模式。
透明度:明確標註人工智慧的使用,解釋其局限性,並提供手動審核或申訴。
問責制:在發布前,明確部署、事件、監控和回滾的責任人。

您可能還想閱讀以下文章:
🔗 軟體開發人員的最佳人工智慧工具:頂級人工智慧編碼助手
比較頂級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