HBR 這篇文章解決了大部分商業世界的一個基本問題：如何運用生成式人工智能進行企業轉型，甚至看得到獲利模型？投入人工智能的風險與回報值不值得企業投資？或者是更直接的問題，短期內如何找到它最佳的工作應用方法。
企業這些考量相當實際，背後都是感覺人工智能的重要性好像被媒體誇大了，但實際影響的任務與工作卻不十分明確。作者群來自於 MIT 的安德魯．麥卡菲（Andrew McAfee）等人，他們提供一些簡單的企業評估標準，從工作、技能與應用場景切入。初期他們認為領導者應將生成式人工智能視為與電力、蒸汽機和網際網路類似的通用技術。雖然這些技術的全部潛力需要幾十年才能實現，對於生成式人工智能來說，只需要短短幾年內，就能對整個經濟產生成效和競爭。
作者之一丹尼爾．洛克（Daniel Rock）從更實際的研究成果，看出生成式人工智能對工作的影響。出發點是 ONET 工作技能資料庫：自 1998 年以來 ONET 一直由美國政府負責維護和更新，包括近 1000 種職業，並將每種職業細分為其組成任務－通常為 20 到 30 細項。例如，根據 O*NET資料，放射科醫生有 30 項不同的任務，包括「執行或解釋診斷成像軟體的結果」和「為放射科病人規畫治療計劃」等等。研究人員在 OpenAI 選定人員的協助下，解決 2 個問題：
- 在生成式人工智能的幫助下，每個 O*NET 工作中的哪些任務可以以至少兩倍的速度完成，而且品質不會明顯下降？
- 在這些「公開」的任務中，除了生成式人工智能之外，哪些任務還需要至少一個系統才能提高生產率？
研究團隊也向 OpenAI 的 GPT-4 LLM 提出了同樣的兩個問題，並將其答案與人們的答案進行了比較。
答案大同小異。80% 的美國員工至少有 10% 的工作會接觸到生成式人工智能，19% 的員工裡，有一半以上的工作會接觸到生成式人工智能。但是並不意味著這些任務將會或應該被自動化。在許多情況下，生成式人工智能的最佳用途是提高人類員工的生產力或創造力，而不是取代傳統人力。
軟體工程師就是一個很好的例子。他們已經大量使用 GitHub Copilot 這樣的 LLM 來編寫程式碼初稿，但他們仍然需要抓蟲；與管理人員、工程人員和技術人員協商，以明確軟體應用的目標；培訓初階工程師；以及執行許多其他不適合生成式人工智能的任務。隨著 LLM 在編寫代碼方面的進步，軟體工程師們將有更多的時間和精力投入到其他任務中。
文章同時提出三個企業應用場景，也相當值得參考。
第一是對於知識工作者來說，有多少時間用於寫作報告、分析資料與獲得特並內部知識？這些知識工作都能夠依靠 LLM 進行重整之外，另外一個就必須要看職務的性價比。是的，公司為每個職位進行薪資的支出總額必須要重新估算。但這不是要找出裁員名單，而是要重新定義這些職位還能夠如何大幅提升生產力。
第二場景是 LLM 能夠取代什麼樣的系統，如果現成系統需要大量人工運作時間製作或是整理圖表，不如將這些系統整合到 LLM 裡面。因為大部分的生成式人工智能需要資料與經驗的積累，一旦獲得關鍵資料，將能涵蓋大部分業務流程，而不是單個業務。像是客服單位應用生成式人工智能累積大量經驗，將會轉換成為「提升客戶經驗」的組織，而不是天天診斷故障等相對價值過低的工作。
比較危險的是利用一些機密來訓練生成式人工智能。因為某些片段在生成式人工智能系統下，可能會編造出假訊息，造成誤判、混淆和隱私問題。但企業並不能因為這些副作用而放棄運用，像是Stable Diffusion 和 Midjourney 等新型圖像應用，都曾因侵犯版權而被起訴。排除知識風險是資料運用上不可迴避的問題，許多待法院判定的灰色地帶，則能夠以法律行動主動為客人規避索賠風險，就像 Open AI 或 Adobe 保證解決法律問題的作法。
最後，就像是採用電力、蒸汽機與網際網路等新科技，生成式人工智能無疑的產生過度樂觀或是悲觀的判斷。不管使用甚麼樣的資料，偏差值永遠存在。與其說是生成式人工智能幫助人們建造，不如說是測試假設並獲得理解，企業應該要經歷過反覆驗證（不是仔細規劃卻規避風險）才是重點。
全文仍有一些案例與細節，值得永久保存。
