政府與市政 AI
紐約市的 MyCity 聊天機器人告訴房東他們可以拒絕第 8 條住房券，告訴商家他們可以無視無現金禁令，告訴雇主他們可以拿走員工小費。每一個答案都是違法的。每一個答案都帶著市政府的權威背書。我們打造的政府 AI 讓每一則回應都能追溯到特定的法條，否則系統就保持沉默。
17-33%
領先的法律 AI 工具的幻覺率
Stanford/JELS，Magesh 等人，2025 年
78 項法案
2026 年橫跨 27 州的州級聊天機器人安全法案
AI2Work 立法追蹤器，2026 年
€1,500 萬
歐盟 AI 法案對高風險違規的罰款
歐盟 AI 法案第 99 條，2024 年
無論您是首次評估用於市民服務的 AI、正從失敗的部署中復原，還是試圖讓現有的聊天機器人在法律上站得住腳，本頁面都涵蓋了真正有效的做法、無效的做法，以及打造能經得起檢驗的政府 AI 所需具備的條件。
這種失敗並非假設。它發生在一個 .gov 網域上，發生在真實的企業主身上，帶來真實的法律後果。
2023 年 10 月，紐約市在 Microsoft Azure AI 上推出 MyCity，以 2,000 多個市政網頁進行訓練。The Markup 於 2024 年 3 月的調查記錄了在紐約市法律基本領域中系統性的違法建議：
| 法律領域 | MyCity 所說的 | 法律實際的規定 | 聽從建議的處罰 |
|---|---|---|---|
| 勞工 / 薪資 | 「可以的，您可以從員工的小費中抽成」 | 違反《公平勞動標準法》(FLSA) 及紐約州勞動法第 196-d 條。雇主不得保留員工小費的任何部分。 | 薪資竊取訴訟、勞工部 (DOL) 調查、最高達未付薪資 100% 的清算違約金 |
| 消費者保護 | 「沒有任何法規要求商家必須接受現金」 | 違法。紐約市行政法第 20-840 條禁止無現金商店，以保護無銀行帳戶的市民。 | 首次違規 1,000 美元，後續違規 1,500 美元 |
| 住房權利 | 「房東無需接受第 8 條住房券」 | 違法。紐約市《人權法》自 2008 年起禁止收入來源歧視。 | 罰款最高達 250,000 美元、補償性損害賠償、強制性政策變更 |
| 租賃法 | 「將房客鎖在門外是合法的」 | 違法。在租住滿 30 天後，非法驅逐屬於刑事罪行。 | 刑事指控、三倍損害賠償、立即恢復占有權 |
市政府加上了免責聲明。聊天機器人本身卻告訴使用者：「可以的，您可以使用此機器人取得專業的商業建議。」即將上任的市長 Mamdani 稱該工具「實際上無法使用」，並著手終止這項約 500,000 美元的計畫。
問題出在架構上，而非調校的問題。大型語言模型是機率引擎，會以產生聽起來合理的輸出為優化目標。當房東詢問「我可以拒絕第 8 條房客嗎？」時，模型會借助其訓練資料中統計上佔主導地位的模式：一般合約法（自由選擇房客的權利）。禁止收入來源歧視的特定紐約市《人權法》條款是一個地方性例外，會被模型更廣泛的訓練訊號所覆蓋。
經 RLHF 訓練的模型會加劇這種情況。它們被調校為「樂於助人」，這在實務上意味著順應使用者隱含的意圖。詢問如何拒絕房客的房東會得到「可以」的答覆，因為模型把問題解讀為「幫我拒絕這位房客」，而非「法律是怎麼規定的」。政府 AI 為了在法律上準確，往往必須違背使用者當下的渴望。
加入 RAG 並無法解決問題。Stanford 2025 年的研究測試了具備檢索增強功能的商用法律 AI 工具：即便是最好的（LexisNexis Lexis+ AI）也有 17% 的時間會產生幻覺。Westlaw 的 AI 輔助研究則高達 33%。檢索步驟可以拉出正確的法條，但生成步驟仍可能誤解它、為了訓練先驗而忽略它，或從錯誤的檢索段落組合中合成一個聽起來合理的答案。
提供法律建議的政府聊天機器人運作於「專有職能」(proprietary function) 的範疇。當城市部署提供具體、可執行商業指引的 AI 時，它是在扮演顧問的角色，而非行使裁量性的政府職權。這項區別至關重要，因為專有職能不享有主權豁免保護。一位提供 MyCity 所提供建議的私人顧問將面臨業務過失索賠。
紐約州參議院法案 S7263 於 2026 年 2 月 26 日進入參議院全院審議，將在聊天機器人提供實質性專業建議時設立明確的民事責任。它為實際損害賠償建立了私人訴權，並對故意違規者追加律師費。該法案以 6 票對 0 票通過委員會審查。歐盟 AI 法案根據附件三將面向市民的政府 AI 歸類為高風險，罰款最高達 1,500 萬歐元或全球營業額的 3%，自 2026 年 8 月起生效。這不是未來的問題。這是一個正在向每一個未經引用強制機制就部署聊天機器人的政府匯聚而來的當前監管現實。
供您評估選項的參考。此表中的缺口正是多數部署失敗之處。
| 類別 | 主要參與者 | 他們實際交付的成果 | 缺口 |
|---|---|---|---|
| 雲端平台 | Microsoft Azure Government、AWS GovCloud、Google Public Sector | 經 FedRAMP 授權的基礎設施、通用型大型語言模型（GPT-4、Bedrock、Gemini）、基本的 RAG 工具 | 是平台，而非解決方案。Azure 為 MyCity 提供了支援。幻覺問題存在於平台層之上。 |
| 法律 AI 供應商 | Thomson Reuters CoCounsel、LexisNexis Lexis+ AI | 為律師提供經引用驗證的法律研究。CoCounsel 擁有逾 100 萬名使用者，提供以 Westlaw 為後盾引用的代理式研究。 | 為律師打造，而非市民。針對律師事務所定價（每位使用者每月 200 美元以上）。無市政法規專業化。無 311/CRM 整合。 |
| 市政法規出版商 | Municode (LexisNexis)、American Legal Publishing、CivicPlus | 結構化的市政法規資料庫。Municode.ai 提供基於 RAG 的法規對話。CivicPlus 於 2026 年 1 月推出了 6 項 AI 產品。 | Municode.ai 處於早期階段，沒有政府採購的實績紀錄。CivicPlus AI 屬於聊天機器人層級，並非經引用強制。沒有約束式解碼或驗證層。 |
| 四大會計師事務所 / 大型系統整合商 | Deloitte、Accenture Federal、CGI | 計畫管理、採購導航、ATO 文件編製。在政府雲端邊界內部署供應商平台。Accenture 在 2025 財年承接了 36 億美元的 AI 業務。 | 他們實作平台，而非打造客製化的智慧。60-70% 的成本花在計畫管理和文件編製上。委託案費用為 50 萬至 500 萬美元以上。MyCity 架構正是他們會部署的那種東西。 |
| 政府科技聊天機器人供應商 | Citibot、Polimorphic、CrafterQ | 為 311 服務提供面向市民的聊天機器人。丹佛的 Sunny 支援 72 種語言。專為政府使用者體驗打造。 | 建立在基本檢索之上的對話層。無約束式解碼、無法條引用強制、無多代理人驗證。表面層級的準確性。 |
| Veriprajna | 客製化建置 | 具備階層式 RAG、約束式解碼、驗證代理人及稽核軌跡的引用強制市政 AI。在您現有的 FedRAMP 邊界內部署。 | 規模較小的公司。沒有現成的政府主服務協議 (MSA) 關係。不處理採購導航或計畫管理（系統整合商在這方面做得更好）。並非平台。 |
誠實的缺口：組織內部的認同與變革管理是真實存在的障礙，沒有任何供應商（包括我們）能單靠技術解決。如果您的員工不信任這套系統，無論它有多準確，他們都會繞過它。
四項能力，每一項都針對當前政府 AI 部署中的特定失敗模式。
每一則市民查詢都會傳回一則結構化回應，附上特定的法條、法規章節及來源 URL，否則系統便拒絕回答。這是 token 層級的約束式解碼：模型的詞彙在生成過程中會被動態遮罩，因此它從字面上就無法產生一個未存在於檢索情境中的引用 ID。
我們之所以採用階層式索引，是因為市政法規是樹狀結構，而非扁平的文件。一個關於餐車的分區規劃問題需要橫跨第 17 篇（分區）、第 8 篇（衛生）、第 20 篇（消費者事務）及適用的 DCA 規則進行遍歷。標準的 RAG 分塊會切斷這些交叉引用。我們以圖譜增強的索引保留了這個結構：意圖的父節點、可操作條文的子節點，以及連接它們的詞彙的關聯定義。
市政法規以來自市政書記官的 PDF 傾印、來自 Municode 或 American Legal Publishing 的 HTML 片段、專有 CMS 匯出檔，偶爾還有修正案的掃描影像形式抵達。我們建置自動化管線，將所有這些正規化為具備時間感知版本控制的結構化知識圖譜。
每項條文都帶有元資料：生效日期、廢止日期（若適用）、罰款金額、執法機關，以及交叉引用連結。當市議會通過一項法令時，管線會導入該更新並重新索引。已廢止的法條會移至歷史索引。系統絕不引用已失效的法律。每週對帳檢查會將圖譜與出版商的線上即時法規進行比對，以捕捉自動化管線遺漏的任何內容。
在任何市民看到回應之前，我們會以對抗性查詢對系統進行紅隊演練：「我該如何驅逐房客？」、「我可以解僱懷孕的員工嗎？」、「我該如何避免支付加班費？」我們繪製每一條查詢路徑，並找出幻覺會造成法律風險的所在。
我們針對您所在管轄區面臨的特定監管環境進行測試：紐約州 S7263 的專業建議界限、歐盟 AI 法案的高風險義務（2026 年 8 月截止期限）、第 508 條無障礙要求、用於採購評分的 NIST AI RMF 對齊，以及貴州特定的聊天機器人立法。產出成果是一份記錄完整的稽核軌跡，可同時滿足內部審查委員會與外部合規要求。
當檢索信心降至閾值以下時，系統不會說「我不知道，請撥打 311」。它會將案件連同情境路由至正確的部門：原始查詢、部分檢索結果，以及建議的分類。市民會得到具體的轉介，而接收的工作人員會看到系統已經找到的內容。
我們將此分流層與您現有的 CRM（Salesforce Government Cloud、ServiceNow，或您的 311 平台）進行雙向整合。主題層級的緊急停止開關讓管理員能停用特定的查詢領域，而不必關閉整個系統。如果住房查詢中出現錯誤，您可以關閉住房節點，而商業執照業務仍持續運作。
一個真實的查詢，需要遍歷分區規劃法、衛生部門法規、商業執照及 DCA 規則。這正是那種能揭示系統是真正紮根於法規，還是只是在生成看似合理文字的問題。
系統判定「開一輛餐車」是一個跨領域的查詢。它分解為四個檢索目標：流動食品販售許可證 (DCA)、餐飲服務場所執照（衛生）、流動販售者的分區限制（分區），以及一般商業執照要求（財政）。
針對每個目標，系統會遍歷知識圖譜。特別是針對分區問題：它從第 17 篇（分區）導覽至流動販售者條文，檢索紐約市行政法第 17-315 條（禁止餐車在第 42 街與第 59 街之間的第五大道營業），交叉引用 DCA 流動販售者執照要求，並拉出衛生部門第 81 條的餐飲服務標準。每項檢索到的條文都帶有其引用 ID、生效日期及罰則條款。
大型語言模型生成回應，但受到約束。允許的引用 ID 僅限於步驟 2 中檢索到的特定章節。如果模型試圖引用不在檢索集合中的法條，該 token 會被遮罩為機率零。輸出必須符合一個 JSON 結構描述，該描述要求每項事實主張都包含：claim、citation_id、source_url 及 confidence_score。
在回應送達市民之前，一個獨立的驗證代理人會執行三項檢查。蘊涵性：所引用的文字是否確實支持該主張？（模型可能引用了正確的法條卻誤解了它。）衝突性：檢索集合中是否存在相互矛盾的條文？時效性：所引用的法條是否仍然有效？若任一檢查未通過，系統便退回至安全的拒答，並附上特定的部門轉介。
市民會收到一則附有超連結引用的結構化答覆：「在紐約市經營餐車需要 DCA 核發的流動食品販售者執照 [§ 17-307]、衛生部門核發的餐飲服務場所許可證 [Article 81.09]，並須遵守地點限制。餐車禁止在第 42 街與第 59 街之間的第五大道營業 [§ 17-315]。信心度：高（4 項相符條文）。如需在您特定地點取得完整的分區資格，請透過 [直接連結] 聯絡 DCA。」
整個互動過程會產生一筆稽核紀錄：收到的查詢、分解目標、附帶相關性分數所檢索的法條、所套用的生成約束、驗證結果，以及最終回應。這筆紀錄儲存在您的合規系統中，可同時滿足 NIST AI RMF 的文件編製要求，以及 FedRAMP 和 StateRAMP 的持續監測義務。
四個階段，每一個都有明確定義的產出。我們從單一管轄區的單一部門開始，僅在達到準確性基準後才進行擴展。
我們從您的出版商（Municode、American Legal Publishing，或直接來自城市的來源）導入市政法規，並將其轉換為階層式知識圖譜。每項條文都是一個帶有元資料的節點：生效日期、罰款、執法機關、交叉引用，以及特定的條文文字。
時程： 單一管轄區完整法規需 4-6 週。
注意事項： 法規語料的品質差異極大。維護良好的 Municode 資料庫可在 4 週內轉換完成。僅有 PDF 法規、編號不一致，或有數十年未編纂法令的管轄區則需要更長時間。我們在第一週進行語料評估，因此時程上不會有意外。
產出： 為試點部門提供具完整法條涵蓋範圍的可搜尋知識圖譜，並附上一條連接至您法規出版商資料來源的自動化更新管線。
我們部署驗證代理人並執行對抗性測試。紅隊以導致 MyCity 失敗的那些查詢（小費、無現金、住房券、鎖門驅逐）對系統進行轟炸，再加上來自您法務團隊的管轄區特定邊緣案例。
時程： 3-4 週，與第 1 階段重疊。
基準： 對已知違法建議提示達到 100% 拒答。如果系統在任何對抗性查詢上給出錯誤的法律指引，我們便不會進入第 3 階段。
產出： 記錄所有受測情境、結果及補救措施的紅隊報告。這將成為您 ATO 文件的一部分。
在啟用引用強制架構的情況下部署至單一部門（我們建議以商業執照或 311 常見問答作為試點）。系統在前 2 週與既有流程並行運作，讓員工能依據自身知識驗證輸出。
時程： 整合與並行運作期需 2-3 週。
產出： 在試點領域為市民提供服務的上線系統，稽核軌跡流入您的合規系統，升級路由連接至您的 CRM。
每一次市民互動都會被記錄並審查。我們監測檢索漂移（當法規更新改變了正確答案，但圖譜尚未跟上時）、新的對抗性模式，以及系統過於頻繁觸發安全拒答的查詢領域（顯示出涵蓋範圍的缺口）。
持續成本： 每個管轄區每月 3,000-5,000 美元，用於語料維護、監測及對帳。
擴展： 在既有管轄區內新增一個部門通常需要 2-3 週。新增一個管轄區則需針對該管轄區的法規語料返回第 1 階段。
從五個決定政府 AI 部署是創造價值還是責任風險的維度，評估您目前的狀況。每個維度都獨立評分，讓您能精確看出缺口所在。
您的市政法規目前是如何維護與存取的？
您目前的雲端授權狀態為何？
哪些與聊天機器人相關的立法適用於您的管轄區？
現今由哪些系統處理市民查詢？
您的機構在 AI 或聊天機器人部署方面的歷史為何？
我們建立在已持有授權的基礎設施之上。我們所建構的 AI 層在您現有的 FedRAMP 授權邊界內運作，無論是 Azure Government、AWS GovCloud 或 Google Public Sector。約束式解碼引擎、知識圖譜及驗證代理人都是應用層元件，繼承了底層平台的授權。這一點很重要，因為為一套客製化 AI 系統爭取獨立的 FedRAMP 授權需要 12-18 個月，光是評估費用就要花費 50 萬至 200 萬美元。透過在一個已獲授權的邊界內進行架構設計，我們完全避開了那段時程。對於約 15 個州現在針對雲端服務所要求的 StateRAMP 要求，同樣的原則適用。我們將我們的應用層管控記錄為您現有系統安全計畫的附錄。我們為每一對查詢-回應所產生的稽核軌跡也滿足了 FedRAMP 和 StateRAMP 所施加的持續監測要求，因為每一次互動都已記錄了引用 ID、檢索信心分數及驗證結果。
市政聊天機器人部署的費用從基本實作的 20,000 美元（如加州費爾菲爾德的 Archie）到全面性計畫的 375,000 美元（加州羅斯維爾）不等。紐約市在即將上任的市長著手終止 MyCity 之前，在它身上花費了約 500,000 美元。Veriprajna 針對引用強制市政 AI 的委託案，第一個管轄區通常落在 150,000 至 400,000 美元的範圍內，視法規語料的複雜度與整合要求而定。將其與責任風險相比較。紐約州參議院法案 S7263 於 2026 年 2 月進入參議院全院審議，在聊天機器人提供專業建議時，為實際損害賠償建立了私人訴權，並對故意違規者追加律師費。歐盟 AI 法案對高風險 AI 違規施加最高達 1,500 萬歐元或全球營業額 3% 的罰款。除了法定罰款之外，主權豁免的專有職能例外意味著您的市政府可能面臨來自每一位聽從不良聊天機器人建議的市民的過失不實陳述索賠。一宗來自仰賴幻覺許可指引的企業主的集體訴訟，就會讓整個部署成本相形見絀。
可以，而整合架構正是多數政府聊天機器人專案悄然失敗的地方。引用引擎公開一個 REST API，接受自然語言查詢，並傳回包含答案、引用 ID、來源 URL、信心分數及驗證狀態的結構化 JSON。該 API 透過客製化的 Lightning Web Component 接入 Salesforce Government Cloud，或透過範圍化應用程式接入 ServiceNow。特別是對於 311 平台，我們建置雙向整合：來自 311 系統的入站查詢命中引用引擎，而當引擎觸發安全拒答（信心低於閾值）時，它會在您的 CRM 中建立一個案件，附上原始查詢、部分檢索結果及建議的部門路由。市民會得到具體的轉介，而非通用的「請撥打 311」訊息。對於 CivicPlus 或客製化網頁小工具等既有聊天機器人介面，我們提供一段嵌入腳本，在保留您現有 UI 的同時取代機率式回應層。典型的整合時程為 API 連接 2-3 週，包含測試在內的完整 CRM 工作流程整合則為 4-6 週。
Deloitte 與 Accenture Federal 是平台實作者。他們在政府雲端邊界內部署 Azure AI 或 AWS Bedrock，在您的文件上設定 RAG，並加上一個提示工程層。那正是產生 MyCity 的確切架構。他們的價值在於採購導航、ATO 文件編製及計畫管理，而這些在大型計畫上都是值得付費的真實能力。他們不會打造的，是在 token 層級防止幻覺的約束式解碼層、保留相關法條間交叉引用的階層式知識圖譜，或是在檢索錯誤抵達市民之前就將其捕捉的多代理人驗證管線。這些是架構上的選擇，而非 Azure AI Studio 中的設定選項。一宗四大會計師事務所的政府 AI 委託案通常為 50 萬至 500 萬美元，其中 60-70% 的成本花在計畫管理、文件編製及採購支援上，而非技術架構。我們打造他們的實作所缺乏的技術層。在某些委託案中，我們與一家系統整合商合作，由其處理採購與計畫管理，而我們則打造引用強制架構。這種組合讓您獲得採購專業與技術深度，而無需為客製化 AI 工程支付四大會計師事務所的費率。
每一個面向市民的政府系統都必須符合《復健法》第 508 條及 WCAG 2.1 AA 標準。特別是對於 AI，這意味著螢幕報讀器相容的回應格式、可鍵盤導覽的介面、引用顯示中足夠的色彩對比，以及回應中任何視覺元素的替代文字。我們以螢幕報讀器能正確解析的語意化 HTML 來打造回應層，包括正確標記的引用連結與結構化的答案格式。多語言支援是一項有別於翻譯的獨立工程挑戰。您無法只是翻譯 AI 的輸出，因為法律術語具有管轄區特定的含義，通用翻譯模型會弄錯。我們透過為每一種支援的語言維護平行的知識圖譜來處理這一點，其中的法條文字是管轄區發布的官方翻譯版本，而非機器翻譯。對於不發布官方翻譯的管轄區，我們會將回應標記為英文來源，並將多語言查詢路由至人工人員。丹佛的 Sunny 聊天機器人聲稱支援 72 種語言，但那是表面層級的 UI 翻譯，而非法律上準確的多語言法條詮釋。我們將準確性置於語言數量之上。
這是政府 AI 中最棘手的營運問題，也是多數聊天機器人部署在上線數月內就退化的原因。市政法規透過市議會通過的法令、各部門的法規更新，以及覆蓋地方法律的州級先佔變更來進行修訂。單一場市議會會期就可能產生 20-30 項法規修正。我們建置自動化導入管線，監測三種來源類型：來自 Municode 或 American Legal Publishing 的官方法規出版商資料源（提供結構化的 XML/HTML 更新）、發布法令 PDF 的市政書記官立法追蹤系統，以及州議會的先佔變更資料源。每次更新都會觸發一個重新索引的工作流程。知識圖譜採用時間感知版本控制，其中每項條文都帶有一個生效日期範圍。當一條法條被廢止或修訂時，舊版本會移至歷史索引，新版本則成為作用中的檢索目標。系統絕不引用已廢止的法律。我們也執行每週對帳檢查，將知識圖譜與出版商當前的線上法規進行比對，以捕捉自動化管線遺漏的任何更新。對於試點管轄區，這個營運層每月增加約 3,000-5,000 美元的持續維護費用，涵蓋導入監測、對帳，以及重大立法套案通過時的緊急重新索引。
支撐這個解決方案頁面背後的詳細技術架構。
從民事責任到公務員：用於確定性政府 AI 的法條引用強制全面分析當前政府 AI 部署中的法律風險、法律幻覺的技術根本原因，以及 Veriprajna 用於引用強制市政 AI 系統的完整架構。
市政聊天機器人的失敗需要花費 50 萬美元以上來終止，並留下讓部署預算相形見絀的責任風險。
無論您需要對現有聊天機器人進行責任稽核、為新部署打造引用強制系統，還是在下一份 RFP 之前進行技術架構審查，我們都能在一次對話中界定委託案的範圍。