推出用於政府服務的 Gemini：Google 將代理程式引入政府機構工作流程

Google 於 10 月 20 日推出用於政府服務的 Gemini，將其工作場所代理程式引入政府運作，同時為具影響性的步驟保留人工審批。其題為「Introducing Gemini for government services」的公告，描述一款把政府機構知識與完成行政工作的工具連接起來的軟件。當中的張力介乎委派執行與公共問責之間：準備文件與授權發布，承擔的是不同責任。

首輪發布為美國聯邦、州及地方政府提供預覽版。Google 點名密蘇里州及衞生與公共服務部為參與機構。這些關係證明早期參與的存在，但並不證明準確度提升、積壓工作減少，或公民服務已有經獨立驗證的改善。

Microsoft 已提供 Copilot Studio 的政府版本，這是其用於建立對話式代理程式的平台。因此，Google 正進入既有的政府自動化市場。更重要的競爭在於營運模式：政府機構會委派多少工作、員工在哪些位置介入，以及事後保留甚麼證據。對公務員、開發者及採購方而言，這項公告將採購討論由產生有用答案，轉向監督跨政府機構系統的工作。

推出用於政府服務的 Gemini 不止於提供答案

Google 正把政府知識、系統存取及受監督行動，打包成政府機構工作流程方案。

AI 代理程式是使用模型及已連接工具來完成獲分配目標的軟件。與獨立助理相比，其重要性來自它在產生答案後能夠執行的工作。

Google 的政府服務預覽版結合可重用的政府指令、系統連接器、合作夥伴代理程式及集中式控制。連接器是讓軟件透過既定介面存取另一個系統的整合工具。Google 表示，存取權限沿用現有設定，並會查詢已連接系統，毋須遷移資料。

該公司列出記錄搜尋及擬議文件遮蓋為支援的工作流程之一。遮蓋是指在資料交予獲授權受眾前，移除應保密的資訊。Google 表示，具影響性的步驟會由人員審批。

這種安排改變了員工與軟件的關係。員工不再只是要求摘要，然後手動組織下一項工作，而是委派一項有明確範圍的工作。實際問題在於，這個範圍能否在整個執行過程中保持可理解。

試想一個涉及往來信件及佐證文件的假設性公開記錄申請。找出相關材料、整理覆核文件包，以及批准披露，分別是不同活動。代理程式可以協助較早階段的活動，而記錄主任則保留對發布的責任。

這項區分很重要，因為中間工作會塑造最終決定。收到不完整文件包的覆核人員，可能永遠看不到會改變其詮釋的文件。最後階段的人手批准，未必能自動修補流程較早時的遺漏。

因此，審批畫面不能只有接受按鈕。一份有用的覆核文件包應展示搜尋範圍、被排除的材料、未解決問題及建議行動。否則，員工是在沒有看到足夠工作過程的情況下，覆核代理程式的結論。

這是對委派式工作流程的分析性推論，而非已報道的預覽結果。公告確立了 Google 的預期設計。政府機構仍需要證據，證明這個設計如何配合其自身文件、權限及例外情況運作。

產品邊界亦值得注意。一個政府方案可包含多項具不同成熟程度的功能。採購方應區分已展示的工作流程、受支援的生產環境配置，以及較廣泛平台介紹中提及的功能。

因此，推出用於政府服務的 Gemini 為 Google 創造了一個具體機會：把受監督的行政流程連同底層模型一併出售。其價值取決於該流程能否應對政府機構日常的複雜性。

這種複雜性包括資料提交不完整、記錄互相矛盾、非常規個案，以及需要澄清的申請。一場具說服力的示範應顯示，當現有證據不足以支持完成工作時，系統如何停止工作並交回員工處理。

政府機構採購方承接不同的評估難題

委派工作令工作流程質素、覆核工作量及例外情況處理，成為採購的核心準則。

Google 的政府代理程式發布公告將該方案定位為建基於其 Gemini 平台的行業套裝。該公司確認密蘇里州及 HHS 為早期用戶，但發布內容未提供量度過的部署成果。

因此，應狹義地理解它們的參與。這支持早期政府機構參與確實存在，但不能證明同一配置適合另一個部門、計劃或司法管轄區。

壓力首先落在政府機構的技術主管及計劃負責人身上。他們必須評估，在計入監督所需工作後，建議的工作流程是否改善服務提供。

生成的草稿看來可以很完整，但亦可能把工作轉移到下游。員工或可減少整理材料的時間，卻要花更多時間核對參考資料、調查例外情況或修正格式。相關衡量標準應涵蓋整項工作。

以假設性的文件接收流程為例，政府機構應檢視自動檢查標記問題後會發生甚麼。申請人會否收到清晰解釋？員工能否修正分類？個案能否保留原有處理次序？

這些問題把內部生產力與市民體驗連結起來。若一個工作流程減少員工處理時間，卻增加不必要的重新提交，工作只是被轉移到別處。若稱之為改善，便需要更全面的核算。

覆核工作量亦影響採用。如果員工必須以與檢查未經協助草稿同等嚴格的程度檢查每項輸出，承諾的產能提升就更難證明。減少準備時間仍有意義，但需要量度。

歷史背景支持審慎評估。GAO 的聯邦 AI 清單發現，部分政府機構報告的生成式 AI 用例，在 2023 至 2024 年間由 32 個增至 282 個。這些數字描述已報告的使用情況，而非經審核的服務改善。

GAO 亦記錄了涉及政策合規、技術資源、預算，以及保持適當使用政策更新的挑戰。其發現關乎一般政府機構的採用情況，並非對此 Gemini 預覽版的評估。

這個區分為採購方提供有用框架。採用增長說明為何打包式政府 AI 受到關注，但單憑採用並不能回答成果問題。政府機構仍需要自身的基準及驗收準則。

對實施合作夥伴而言，壓力亦隨之改變。建立可運作的整合只是交付工作的一部分。必須有人維護指令、記錄變更、處理連接失敗，並協助員工理解何時應升級處理。

最有力的採購論據，應把技術表現與明確行政成果連繫起來。例如減少返工、通知更清晰，或在不變的覆核流程下更快完成。這些是評估目標，而非 Google 公告已確立的成果。

推出用於政府服務的 Gemini 令這些目標更為迫切，因為建議中的產品超越個別起草工作。一旦軟件協調行政步驟，政府機構便必須整體評估由此形成的服務流程。

現有系統成為競爭核心

政府 AI 的競爭日益取決於對機構知識及既有工作流程的受控存取。

Microsoft 提供了一個有用比較，因為政府專用環境已經塑造其代理程式方案。其政府代理程式環境文件說明美國內容駐留、受限制的管理存取，以及政府與商業功能之間的差異。

Microsoft 亦警告，已連接的第三方服務可能不在其政府服務的合規及資料保護承諾範圍內。這項警告說明一個更廣泛的採購問題：整合的邊界與承載它的平台同樣重要。

這並不證明 Microsoft 的方案與 Google 預覽版具備同等功能。採購方需要比較其預定部署所能使用的確切環境、能力及已連接服務。

對已使用既有協作及個案系統的政府機構來說，更換模型供應商只解決部分問題。餘下工作涉及身分管理、文件組織、系統存取及審批責任。

因此，競爭優勢部分取決於能否減少實施的不確定性。政府機構需要知道哪些連接受到支援、哪些需要自訂開發，以及當上游系統變更時由誰維護。

連接器的存在並不能回答所有這些問題。讀取檔案、搜尋檔案庫及更新個案，涉及不同權限及故障模式。採購方應評估其打算授權的操作。

試想一個從多個儲存庫準備個案摘要的假設性工作流程。代理程式需要存取相關記錄，但覆核人員亦需要確信，無法存取的材料沒有在無聲無息中扭曲結果。

明確說明部分來源無法取得，有助覆核人員詮釋摘要。沒有這項警告的流暢答案，可能令人對現有證據以外的內容產生信心。

正是在這裏，政府 AI 代理程式會面對底層知識環境的狀況。不一致的文件名稱、重複指引及不清晰的擁有權，都可能令任何預期檢索可靠機構背景的系統變得複雜。

同一區分亦見於一般的AI 知識庫：個人檢索與全機構存取解決的是不同問題。政府部署則在這項底層知識挑戰上，加上計劃責任及公共問責。

對開發者而言，這會把注意力轉向系統行為。處理過期憑證、無法使用的儲存庫、部分搜尋及中斷的工作，成為使用者體驗的一部分。這些情況應持續向負責監督任務的人員清楚呈現。

對於政府機構而言，這帶來了一個比「哪個助理最擅長撰寫段落」更具體的競爭問題：哪一家供應商能支援預期流程，同時讓存取限制、故障情況及審核責任清晰易明？

Google 的套裝方案讓它能在這個層面競爭。Microsoft 已記錄的政府環境顯示，控制措施和部署邊界已構成市場的一部分。

兩者均不能取代按工作負載而定的證據需求。當平台比較沿着同一項任務，檢視來源存取、準備、審核及獲授權完成流程時，才會變得有用。

人工批准需要證據支持

只有當審核人員能實質質疑建議行動時，人工檢查點才能支持問責。

受監督自動化的承諾聽來直接：軟件準備工作，員工批准結果。其成效取決於員工收到甚麼資訊，以及審核所需時間。

面對冗長資料包的審核人員，需要能找出不確定性的方式。重要遺漏、相互衝突的證據及未解決的例外情況，應在它們影響決策的位置呈現，而不應被流暢的文字掩蓋。

NIST 的生成式 AI 風險概況將幻覺——即以自信方式呈現的虛假內容——列為相關風險。該文件亦指出，生成的解釋及引文本身也可能具誤導性。

該指引提供一般風險視角，並不證明 Gemini 的政府預覽版曾產生某項特定錯誤。相關含意是，即使答案看似有來源支持，仍須進行實質核查。

引文可協助審核人員找到證據，但其存在並不代表該證據支持結論。審核亦需檢查適用性、範圍，以及相反資訊是否改變答案。

在假設的政策問題中，檢索到的段落可能準確描述一般規則，卻忽略與個案相關的例外。結果答案即使看似證據充分，仍可能不適合作出決策。

因此，政府機構應將困難個案與常規個案一併測試。一套有用的評估資料集應包括不完整記錄、相互衝突的指引、無法閱讀的文件，以及需要系統請求協助的情況。

這些是建議的評估條件，而非對已觀察故障的聲稱。其目的在於區分準確完成工作，與證據不足仍持續運作的系統。

同一原則亦適用於文件發布。審核資料包應讓員工在脈絡中檢視建議處理方式。批准孤立標籤所提供的保證，少於檢視周邊文件及建議行動理由。

工作負載亦會影響審核質素。若代理產出材料的速度快於員工評估速度，批准隊列便會成為下一個瓶頸。管理人員需要在衡量準備速度的同時，衡量審核能力。

當員工不同意軟件結果時，亦涉及責任問題。可用的流程應讓他們能拒絕、更正或上報輸出結果，而不會失去已發生事項的記錄。

這些更正可揭示問題源自原始材料、指示、系統存取權限，還是模型行為。若將每次更正都視為個別員工偏好，便會掩蓋改善工作流程所需的資訊。

因此，最有力的質疑角度是具體的。公告描述了旨在支援監督的控制措施，而有意義的監督需要證據說明員工如何在實際工作負載下使用這些控制措施。

為政府服務引入 Gemini，應按這項營運標準判斷。當人工批准能促成知情介入時，才值得肯定；其成效需要評估，而非假設。

問責不止於代理的答案

政府機構需要可辯護的流程記錄，包括變更、例外情況及員工介入。

行政工作流程產生的不只是最終文件，亦包括查閱過的來源、提出的決策建議、所作更正及獲授權行動的歷史。當有人質疑結果時，這段歷史便十分重要。

GAO 的AI 問責框架從管治、數據、效能及監察角度組織監督工作。它提供的框架，比檢查單一答案聽來是否準確更廣泛。

套用到這項公告，該框架意味着持續的管理責任。政府機構需要擁有工作流程，並有方法判斷隨着系統及營運條件變化，流程是否仍然合適。

成功的試點並不能永久解決這個問題。指示可能過時、來源資料庫可能改變，而員工可能發現原有評估遺漏的例外情況。

政府機構應決定由誰負責每項更正。政策專家可維護實質指引，技術團隊則可維護連接；但項目領導層仍必須為行政結果負責。

缺乏這些責任劃分時，維護工作可能落在供應商與部門之間的空隙。即使沒有人承擔保持特定指示最新的責任，系統仍可能繼續運作。

版本歷史在此十分有用。若員工質疑某項輸出，調查人員需要了解當時的指示和可用來源。只檢視最新配置，可能掩蓋較早結果出現的原因。

這是實施層面的含意，並非對已記錄 Gemini 功能的陳述。它描述了政府機構重建受委派工作所需的證據。

準備與授權之間的分野亦須保持清晰。建議、通知草稿及已獲授權的通訊，應有明確狀態。員工應明白軟件何時只是在準備內容，何時已採取行動。

假設的中斷工作流程說明了這個問題。若在準備草稿後連接失敗，使用者應知道是否已有任何內容被儲存、提交或發送。含糊不清會造成可避免的核查和重複工作。

採購團隊亦應檢視政府機構如何退出某個工作流程。單靠匯出文件，可能遺下在其他地方重現流程所需的指示、評估材料及決策歷史。

這並不表示遷移必須毫不費力，而是指買方在令工作流程對營運變得重要前，應了解哪些部分由自己控制，哪些仍依賴供應商。

這些問題把問責與長期採購價值連繫起來。能加快初期部署的套裝方案，仍需要可持續的營運安排。維護、審計支援及變更管理都應納入評估。

對知識工作者而言，後果很實際：監督政府 AI 代理將成為一項獨立責任。員工需要易於理解的證據、清晰權限，以及可靠地報告不確定性的方式。

預覽版發展期間值得關注的事項

下一批有用證據涉及可用性、量度結果及政府機構監督的質素。

第一個訊號是更清晰的部署範圍。在未來數月，留意有關誰可存取預覽版，以及哪些配置支援特定工作負載的詳細說明。

更廣泛的發布，將加強 Google 能超越少數早期合作項目的論據。可用性本身仍會留下效能問題，但會釐清哪些政府機構可直接評估這項服務。

文件應區分已支援的連接與計劃中的連接。它亦應清楚說明功能在哪裏準備資訊、在哪裏提出行動建議，以及員工在哪裏必須介入。

這些區分有助買方避免以普遍的平台承諾，評估僅在有限配置中可用的功能。它們亦令與 Microsoft 及其他供應商的比較更有意義。

第二個訊號是具明確基準的部署結果。一份有用的政府機構報告，應解釋原有流程、已評估的工作負載，以及引入代理後的改變。

完成時間固然重要，但更正所需工作、未解決個案及審核時間同樣重要。包含這些指標的證據，比展示快速生成文件更能支持生產力判斷。

具名政府機構的正面反應可提供背景。說明方法論的已發布評估，則會為判斷另一個政府機構是否應預期類似效益提供更穩固基礎。

結果好壞參半亦具參考價值。若常規個案有所改善而例外情況需要更多工作，買方可評估部署在哪些範圍合理。透明的限制有助建立實用的營運範圍。

第三個訊號是有關監督的證據。留意員工覆寫、任務失敗、存取限制，以及政府機構如何重建輸出背後工作的描述。

這類資訊將加強對建議問責模式的信心。若焦點僅限於成功輸出，核心張力仍未解決：在受委派工作成為行政行動前，誰能發現問題？

應按這個次序評估這些訊號。先確定政府機構可部署甚麼，再檢視它能完成甚麼，然後判斷隨着使用規模擴大，監督是否仍然有效。

對開發者和公共部門買方而言，眼前任務是在擴大其權限前，界定試點必須產生的證據。選擇一個有界限的工作流程，記錄其現有表現，並找出需要員工判斷的環節。要求供應商展示未完成工作和連接失敗的情況，並列出成功完成的案例。要求清楚交代員工審核甚麼、系統記錄甚麼，以及更正如何改變未來行為。為政府服務引入 Gemini，開啟了有關受委派行政工作的具體討論。應將這個討論貫徹到政府機構的實際流程：甚麼會變快、甚麼需要核查，以及甚麼證據支持擴大部署的決定？