OpenAI 與 ServiceNow 的合作擴展 ChatGPT 在工作場所的角色
OpenAI 與 ServiceNow 於 10 月 28 日擴大合作，將商務操作帶進 ChatGPT，同時讓執行工作繼續受到 ServiceNow 的控制。OpenAI 與 ServiceNow 的合作，將熟悉的對話式介面連接至管理營運工作的系統。其重要之處在於責任分工：員工可以在對話中開始工作，而底層商務平台仍然管控其操作。
這項公告結合了現已可用的外掛程式與較長期的開發路線圖。買家應分辨現時可評估的功能，與計劃在日後推出的能力。把助理連接至公司的紀錄，亦會帶來與讓它摘要文件不同的責任。
核心張力在於介面的便利性與商務流程內的問責性之間。ServiceNow 與 Gemini Enterprise 的獨立整合提供了有用的對照。這些發展共同顯示一種逐漸成形的安排：助理競爭成為員工開始工作的地方，而工作流程平台則繼續負責將工作完成。
OpenAI 與 ServiceNow 的合作現時新增甚麼
根據 OpenAI 的企業工作流程擴展公告，ServiceNow MCP 外掛程式已於 10 月 28 日在 OpenAI marketplace 推出。MCP 即 Model Context Protocol，為 AI 應用程式與外部工具提供標準連接方式。預計增強版外掛程式功能將於 2026 年底前推出。
客戶可將 ChatGPT 連接至自己的 ServiceNow 環境，並選擇開放哪些功能。OpenAI 表示，ServiceNow 用於公開受管控工作流程操作的 Action Fabric 層，會套用現有的商務規則及權限。
這項即時改變讓員工多了一個進入營運系統的入口，而不會把那些系統的權限轉移至對話之中。
這項區別很重要，因為回答與操作會帶來不同後果。錯誤的解釋可能令讀者困惑；錯誤的紀錄更新則可能影響另一個團隊的佇列、報告或後續決策。
因此，對買家而言，這項公告引出一個關於連接範圍的實際問題：哪些要求僅屬資訊性質，哪些要求可以改變商務紀錄？在員工依賴整合前，有效的評估必須清楚展示這條界線。
同樣的區別亦適用於使用者提出要求後所看見的內容。助理可能辨識出合適的操作、提交操作，或收到操作成功的確認。這些狀態應保持可區分，尤其是在另一人必須審批該要求時。
這並不代表對話式介面天生不適合商務工作。它改變了一場有說服力的示範需要證明甚麼。當員工無法判斷所要求的變更是否確實發生，流暢的回應便顯得較不重要。
這項合作亦延續了雙方於 2026 年 1 月 20 日公布的關係。較早前的企業 AI 協議強調在 ServiceNow 內使用 OpenAI 模型，同時涵蓋語音技術及工作流程自動化。
10 月的擴展則新增了反方向的流動。ServiceNow 的功能可從 OpenAI 介面存取，使這項合作不只是向現有應用程式供應模型的安排。
對員工而言，這可令工作起點更具彈性。對管理員而言，這亦增加了一個其行為必須符合組織營運規則的介面。
因此，ServiceNow ChatGPT integration 最適合理解為工作如何開始的一項改變。它是否改善整個流程，取決於對話提出要求後所發生的事情。
評估應追蹤該要求直至最終紀錄。若只停留在吸引人的聊天回應，便會忽略整合中承擔營運責任的部分。
Chat 成為前門，而 ServiceNow 保留執行權
ServiceNow 將新的受管控工作流程外掛程式描述為一種透過 ChatGPT 調查問題及更新紀錄的方式。其公告明確指出，ServiceNow 仍然是操作執行及接受管治的地方。
一個預覽情境涉及值班工程師在協調回應前，檢視已連結的警示、近期變更及受影響服務。這是一種建議中的產品體驗，而非獨立衡量的客戶成果。
這個有用的機制把調查與執行連接起來，同時保留讓其他人可以檢查的商務紀錄。
試想該預覽所暗示的工作流程。工程師需要了解改變了甚麼、哪些服務受影響，以及誰應作出回應。對話可以協助整理調查工作，但事件仍需有負責人及可信的狀態。
整合的價值在於能否在這些階段之間傳遞相關背景。若工程師必須在另一個應用程式中重新建立調查過程，對話帶來的便利便較不重要。
反過來說，若把每個對話結論自動複製至事件紀錄，則會造成另一個問題。工作假設與已確認發現服務於不同目的。可靠的實作應協助使用者保留這個區別。
這正是為何介面問題不能與紀錄保存問題分開。員工需要空間調查不確定的可能性；營運紀錄則需要足夠清晰，讓未參與原始對話的同事理解。
這種責任分工亦有助解釋兩家公司的誘因。OpenAI 有理由讓使用者持續在其介面內工作；ServiceNow 則獲得另一條通往其平台所管治工作流程的途徑。
這些誘因可以一致，而毋須令任何一家公司退居次要位置。助理處理人們表達意圖時所使用的互動；工作流程系統則套用該意圖成為操作所需的組織條件。
對企業買家而言，這種安排挑戰了一個常見的軟件採用假設。員工可能經常使用應用程式的功能，卻無需開啟其傳統介面。使用方式可能改變，但底層營運依賴仍會存在。
這會對只售賣便利性的供應商構成壓力。若助理能提供偏好的介面，底層應用程式便必須透過商務邏輯、可靠紀錄及執行能力來證明其角色。
這是對架構的詮釋，而非已披露的商業成果。公告並未證明採購決策或應用程式使用方式將如何改變。
不過，它確實讓買家有具體方法評估這項提案：由最初問題開始，追蹤一宗事件經過調查、獲授權更新，直至確認完成。
當這條鏈變得更易追蹤時，ServiceNow ChatGPT integration 才值得關注。只有在負責事件的人仍理解發生了甚麼時，較短的對話才有用。
Gemini Enterprise 顯示這是一項分發策略的原因
OpenAI 的擴展消息緊接 ServiceNow 於 10 月 27 日宣布相關 Google Cloud 合作後公布。該項Gemini Enterprise integration同樣把對話式互動連接至 ServiceNow 工作流程。
ServiceNow 描述了 IT、零售營運及客戶關係管理的正式推出整合。電訊整合預計將於 2027 年初推出。公告將 Action Fabric 置於 Gemini Enterprise 與底層工作流程功能之間。
ServiceNow 正把其覆蓋範圍延伸至不同助理，使介面成為分發選擇，而非其平台唯一的所在之處。
這項比較改變了讀者應如何理解 OpenAI 協議。存取商務工作流程固然有價值，但更廣泛的策略並不取決於 ChatGPT 是否成為每位員工偏好的助理。
對 ServiceNow 而言，支援不同介面可讓其在員工從任何地方開始工作時保持相關性。對助理供應商而言，連接至成熟的工作流程平台，提供了進入商務流程的途徑，否則它們便要另行整合。
兩項安排都不代表所有助理提供等同功能。買家不應將共同合作夥伴名稱視為功能覆蓋、管理控制或推出成熟度完全相同的證據。
有意義的比較在於所完成的任務。獲授權的員工能否取得所需資訊、理解建議操作，並驗證結果？不同介面都需要憑自身表現回答這些問題。
這亦將模型競爭與工作流程競爭分開。模型可以提出有用解釋，卻未必有權變更商務紀錄；工作流程系統可執行權限控制，卻未必提供員工偏好的互動方式。
這項合作把兩種功能連接起來，但不會抹去它們的差異。因此，兩個層面仍有競爭空間：助理理解意圖的能力，以及平台執行意圖的可靠程度。
企業架構團隊面對由此而來的協調問題。支援多個助理可以提供彈性，同時亦提升了不同入口之間規則一致的重要性。
審批要求不應因員工轉換介面而變得含糊。同事亦不應收到關於同一營運紀錄互相矛盾的說法。
這些是評估準則，而非任何一項整合已報告的缺陷。它們源於透過多個對話產品公開共用商務功能。
競爭環境亦讓有關取代的說法更趨審慎。助理獲得使用者注意力，並不會自動淘汰維持組織狀態的應用程式。
同時，保留底層工作流程亦不保證能掌握員工關係。介面供應商可以影響人們在哪裏搜尋、調查，以及決定下一步該做甚麼。
OpenAI 與 ServiceNow 的合作正處於這場協商之中。其即時效果是擴大存取；其策略含義則是員工互動的位置與企業執行的位置之間出現分離。
這種分離讓客戶可比較的不只回應質素。他們可以評估權限延續性、結果清晰度，以及其偏好工作環境之間的一致性。
Codex 將合作延伸至建立應用程式
計劃中的 ServiceNow Codex 整合將 OpenAI 的編程代理引入 ServiceNow 的應用程式開發環境 AI Workflow Factory。OpenAI 模型亦計劃用於 Build Agent 及 Autonomous Engineer。
兩家公司預期 AI Workflow Factory 中的 Codex 將於 2027 年推出。他們亦計劃於 2027 年 1 月提供安全功能的搶先體驗，其後於第二季正式推出。
ServiceNow 的 Super Intelligence Control Tower 語音功能預期於 2027 年第一季推出。建議中的體驗可協助用戶描述 AI 用例，並提供風險評估所需資料。
這些計劃將合作關係由執行既有工作，延伸至建立及維護界定該等工作的系統。
對開發人員而言，這與產生一項獨立的程式碼修改不同。商業應用程式的責任不只在於程式碼能否運行；它還必須反映誰可做甚麼，以及請求如何在人與人之間流轉。
因此，ServiceNow Codex 整合的分析價值，在於可取得應用程式的業務背景。當編程助理能處理變更周邊的限制時，便會更有用。
這種實用性仍需評估。產生的變更必須讓負責維護的人員理解，尤其是涉及權限或營運流程時。
成功的示範應把所要求的業務行為，與最終的應用程式行為連結起來。展示代理產生了程式碼，所能證明的遠少於展示應用程式正確處理了預期流程。
安全計劃亦提出了類似的背景問題。找出潛在漏洞，與決定機構應如何處理該漏洞，是相關但不同的任務。
優先次序取決於受影響系統及其營運重要性。補救措施亦需要負責人、合適的變更流程，以及確認根本問題已獲處理。
兩家公司提出的組合之所以相關，是因為它把安全分析與組織背景連結起來。是否能帶來更佳決策，仍有待實際部署及可獨立評估的結果驗證。
語音為同一主題帶來另一種變化。說話可以令提供資料更容易，特別是表格要求的背景分散於多個答案之中時。
然而，更容易的輸入方式並不能證明最終評估正確。用戶仍需檢視系統的理解，並釐清缺失或含糊的細節。
產品路線圖圍繞一個共同理念而連貫：在受管治的環境中，將人類意圖轉化為結構化工作。編程、安全調查及語音評估各自以不同方式實踐此理念。
買家在評估路線圖時應保留這些差異。插件可處理事故更新的證據，並不能證明未來編程或安全整合已準備就緒。
計劃中的功能應納入策略評估，但採購及部署決策仍應與可供評估的特定產品掛鈎。
權限處理授權，而準確性仍是另一個問題
合作夥伴關係對業務規則及權限的重視，回應了企業的重要要求。然而，這本身並不能解答 AI 指導行動質素的所有問題。
一項行動可以獲授權，但仍可能有誤、不完整，或不適合當前情況。
員工可能有權更新多項事故記錄，但系統仍需識別目標記錄，並理解所要求的變更。權限確立授權；並不確立意圖。
這項分別是該方法的分析限制，並非已宣布插件失效的證據。它說明機構應在存取控制以外，同時評估決策質素。
含糊的請求提供了一個有用測試。當多項記錄都符合描述時，員工可能會提及「較早前的事故」。可靠的互動應在作出有重大後果的更新前，先消除含糊之處。
部分完成同樣值得注意。一項請求可能涉及取得資料、提出變更建議及提交更新。若較後階段失敗，員工需要準確了解哪些部分已完成。
這很重要，因為對話式語言可以令未完成的流程聽起來像已經妥善解決。買家應檢視助理的陳述，與營運系統確認狀態之間的連繫。
當行動需要審批時，同一原則亦適用。已提交的請求與已獲批准的變更，是不同結果。介面應清晰傳達此分別，而不應要求用戶自行推斷。
這些是驗收測試的實務問題，毋須假定整合缺乏保障措施。相反，機構應要求供應商展示這些保障措施在真實條件下如何運作。
公開公告強調功能及預期效益，卻沒有提供獨立量度，以證明整合對事故解決、錯誤率或行政工作量的影響。
這些缺失的量度限制了讀者可作出的結論。可用的整合代表有機會評估工作流程，但不代表該工作流程必然改善每個機構的營運。
推出亦帶來知識界線。個人筆記及機構正式記錄都可協助理解問題，但兩者承載的權威不同。
考慮此分別的讀者，可先探索個人知識庫，再決定哪些資料應納入營運流程。
私人觀察可為調查提供參考，而不會成為經核准的組織結論。保持這項分別清晰，有助同事理解哪些資料可以依賴。
因此，更廣泛的挑戰在於整個互動過程的問責性。機構需要知道哪些資料促成建議行動、誰授權該行動，以及業務系統接受了甚麼。
這些要求應由一開始便塑造評估方向。若待員工養成信任對話式確認的習慣後才加入，轉變將更難管理。
OpenAI 與 ServiceNow 的合作提供了一種架構，將協助功能與受管治的執行方式結合。它是否適合某個特定業務，取決於該架構如何清晰處理日常的不確定性。
留意交付、營運證據及各助理之間的一致性
下一階段應透過產品交付及可觀察的使用情況評判。廣泛承諾指明方向，而發布細節及部署證據則界定客戶可依賴的內容。
最有用的訊號涉及能力、問責性，以及員工工作場所中各個接入點的一致性。
第一個訊號是預期於 2026 年底前推出的增強版插件。買家應留意可用行動、管理控制及確認行為的具體文件。
若發布清楚界定這些界線，將加強受控部署的理據。若發布重點只在介面示範，則對營運準備程度提供較少證據。
即使示範令人信服，這項分別仍然重要。預先準備的例子可展示預期體驗；管理員亦需要了解，當請求不完整或權限不同時，產品會如何運作。
第二個訊號是合作公司內部使用的證據。ServiceNow 計劃向所有員工提供 ChatGPT Work 及 Codex，而 OpenAI 表示其內部正使用 ServiceNow 工作流程。
可供使用與實際採用是不同指標。全體員工皆可使用可反映分發範圍，而在相關任務中反覆使用，則更能反映實際價值。
更有用的證據，會把採用情況與可識別的工作流程成果連結起來。讀者應尋找清楚界定的任務，以及如何評估完成程度或質素的說明。
這些結果仍需審慎歸因。部署後的改善，並不會自動揭示新流程中哪一部分帶來成效。
第三個訊號是各助理整合之間的一致性。隨着 ChatGPT 及 Gemini Enterprise 提供 ServiceNow 功能，客戶可比較各個介面如何處理共同的營運要求。
一致的權限及可理解的結果，將支持 ServiceNow 透過不同助理接觸員工的策略。行為出現分歧，則會令管理及員工指引更具挑戰。
ServiceNow 有商業理由令這種方式成功。公司在其季度營運業績中表示，年初至今，正式環境中的代理式 AI 使用量按年增長超過 13 倍。
代理式 AI 是指朝着完成任務採取行動，而非只產生回應的系統。所報告的增長是全公司層面的背景，並非這項新宣布整合的量度。
對讀者而言，含義是要分開看待各個層面的證據。類別增長並不能證明某一特定產品的質素，而具前景的產品亦不能證明整個機構的成果。
OpenAI 與 ServiceNow 的合作值得以務實角度解讀：比較現時可用的工作流程，與團隊已在使用的工作流程。請管理員示範一次獲准的更新、一次含糊的請求、一次被拒絕的行動，以及一次中斷的流程。跟進每個例子至業務記錄。把未來的編程、語音及安全計劃納入評估，同時將當前決策與可檢視的能力掛鈎。然後考慮員工能否以較少重複工作完成任務，並更清楚了解發生了甚麼。哪一項營運流程會受惠於對話式入口，而團隊在依賴它之前需要哪些證據？
