政府機關正面臨採用 AI 的壓力。第 14110 號行政命令《安全、可靠且值得信賴的 AI》要求聯邦機關加速將 AI 應用於任務執行。OMB 備忘錄 M-24-10 和 M-24-18 要求各機關指定首席 AI 長、盤點 AI 使用案例，並建立 AI 治理框架。指令很明確：用 AI 實現現代化，否則就會落後。
但政府有著大多數 AI 平台完全忽視的限制。
機密環境在無網際網路存取的離線網路上運作。FedRAMP 要求雲端服務在機關使用前必須滿足 325 項以上的安全控制措施。FISMA 要求持續監控和年度安全評估。NIST 800-53 Rev. 5 定義了支撐這一切的控制基準。CMMC 則為處理受控非機密資訊（CUI）的國防承包商增加了另一層要求。
大多數 AI 自動化平台都是純雲端 SaaS。它們假設您的資料可以到達它們的伺服器，您的 LLM 呼叫可以穿越公共網際網路。對於相當大比例的政府工作而言，這些假設都不成立。
JieGou 就是為這個現實而打造的。三種部署模式、自帶模型支援，以及專為直接對應聯邦安全框架而設計的合規基礎設施。
離線部署：無需網際網路的 AI
政府機關在各種機密等級中運作，每個等級都有不同的網路限制。JieGou 透過三種不同的部署模式全面支援。
SaaS 用於非機密工作。 處理可公開發布資料的機關可以使用 JieGou 的託管雲端平台。標準網頁控制台、託管基礎設施、自動更新。
VPC 執行代理用於敏感工作負載。 對於受控非機密資訊（CUI）和敏感但非機密的資料，JieGou 的混合模式將控制平面與執行環境分離。網頁控制台和 workflow 編排在 JieGou 的雲端運行。執行代理在您機關的 VPC 或 GovCloud 環境中運行。當 workflow 步驟執行時，代理使用您的基礎設施和 API 金鑰在本地處理。控制平面接收執行元資料——持續時間、token 數量、成功或失敗——但永遠不會看到原始資料。
完全離線的 Docker 部署用於機密環境。 對於 Secret、Top Secret 和 SCI 環境，JieGou 以零外部依賴的獨立 Docker Compose 堆疊或 Kubernetes 部署方式進行部署。自建入門套件包含所有元件：網頁控制台、workflow 引擎、排程、RBAC 和稽核日誌——全部在您的機密網路邊界內運行。
入門套件包含 Ollama 自動探索功能。JieGou 啟動時會探測已知的本地端點（http://ollama:11434、http://localhost:11434、http://localhost:8000）以尋找正在運行的推理伺服器。一旦找到，管理儀表板會顯示一鍵配置橫幅。拉取一個開源模型——Llama 4、Mistral 3、Qwen 3——您就擁有了一個功能完整的 AI 自動化平台，且沒有任何資料離開網路邊界。沒有雲端 API 呼叫。沒有遙測。沒有外部 DNS 解析。沒有任何東西跨越離線邊界。
BYOM：為機密環境自帶模型
政府機關通常無法將資料傳送到商業 LLM API。當您在一個完全沒有網際網路路由的網路上運作時，OpenAI 的資料處理附錄毫無意義。
JieGou 的 BYOM（Bring Your Own Model，自帶模型）架構支援任何 OpenAI 相容推理端點作為一級供應商。配置一個端點 URL、一個模型名稱和一個可選的 API 金鑰。JieGou 的所有功能都可與您的模型搭配使用：recipe、workflow、評比對照（Bakeoff）、批次執行、結構化輸出提取，以及多輪對話。
這意味著您可以運行：
- vLLM 在離線 GPU 節點上服務 Llama 4 Maverick
- Ollama 在獨立工作站上運行 Mistral 3 Large
- SGLang 或 LocalAI 在機關配置的基礎設施上
- 任何 OpenAI 相容端點——您的機關已核准並部署的
認證模型登錄檔追蹤哪些模型已通過 JieGou 完整功能集的測試——工具呼叫、結構化 JSON 輸出、長上下文處理。認證模型在模型選擇器中會顯示綠色徽章。在政府情境下，此登錄檔對應您機關的模型核准流程：只有通過內部安全審查且被核准用於特定機密等級的模型，才應被配置為可用的供應商。
對於使用 JieGou Bakeoff 的機關，您可以在將 workflow 部署到正式環境之前，比較核准模型清單中各模型的品質。將相同的提示詞送入三個核准的模型，並排比較輸出結果，然後選擇同時滿足品質和安全要求的模型。整個評估過程完全在您的網路內進行。
合規基礎設施
JieGou 的平台功能直接對應支撐 FedRAMP 和 FISMA 的 NIST 800-53 控制措施。
RBAC：帳戶管理與最小權限
JieGou 實作了 6 種角色，在 8 個類別中擁有 26 項細緻權限。這對應了兩個關鍵的 NIST 800-53 控制措施家族：
AC-2（帳戶管理）。 每位使用者都有明確的角色（Owner、Admin、Dept Lead、Member、Auditor、Viewer），並具有明確的權限邊界。Auditor 角色專為合規人員而設，他們需要讀取稽核日誌和治理報告，但不具備建立、修改或執行任何操作的能力。部門範圍控管將存取限制在使用者所屬組織單位內的資源。
AC-6（最小權限）。 每次 API 呼叫都會強制執行權限檢查。Viewer 無法執行 recipe。Member 無法管理 API 金鑰。Dept Lead 無法存取其部門以外的資源。使用者在角色明確授予之前擁有零存取權限。SSO 群組對角色的對應從您機關的身分提供者配置使用者，確保角色指派與您的組織架構一致。
合規時間軸：持續監控
JieGou 維護每個重要平台事件的時序稽核日誌：recipe 執行、workflow 運行、角色變更、API 金鑰操作、配置更新、登入事件。每筆記錄都有時間戳記、歸屬使用者，並標記相關的信任服務準則（TSC）類別。
這直接支援 NIST 800-53 下的 CA-7（持續監控）。合規時間軸提供即時、可查詢的平台活動記錄，而非在事後為年度 FISMA 評估重建活動。擁有 audit:read 權限的稽核員可以審查活動模式、驗證存取控制是否正常運作，並識別異常——全部在治理模組中完成，無需管理員存取權限。稽核日誌摘要將 30 天的活動彙整為操作分解和活動排名報告，提供安全控制在評估週期之間有效運作的證據。
SOC 2 證據匯出：加速 ATO 文件準備
授權運營（ATO）套件需要大量文件。JieGou 的 SOC 2 證據聚合器產生結構化報告，涵蓋 8 個類別中的 17 項 TSC 控制措施，可匯出為 JSON：
- 存取審查 — 每位使用者的角色、權限、部門分配、資源存取、最後活動時間
- 加密清單 — 10 項加密控制措施，包含演算法、金鑰大小、範圍和金鑰管理細節
- 供應商登記 — 第三方供應商，包含風險等級、認證和資料存取分類
- 事件應變手冊 — 4 個階段中的 6 個程序，包含嚴重性定義和 SLA
- 合規配置 — 啟用的框架、資料駐留規則、PII 偵測設定
- 稽核日誌摘要 — 30 天事件計數、操作分解、活動排名
每個區塊都包含自己的 generatedAt 時間戳記。報告有版本且為機器可讀格式。對於準備 ATO 套件的機關，這省去了數週的人工證據收集工作。拉取報告，將每個區塊對應到系統安全計畫中的相關 NIST 800-53 控制措施，然後將結構化資料交給您的評估人員。
資料駐留與邊界保護
JieGou 的分類別資料駐留控制支援 SC-7（邊界保護）。九種資料類別——執行結果、元資料、稽核日誌、知識庫文件、LLM 對話、憑證等——每種都可被指派四種駐留模式之一：僅限本地、僅限雲端、雲端同步或雲端脫敏。對於政府部署，關鍵模式是「僅限本地」：資料永遠不會離開您的網路邊界。控制平面接收執行狀態，但永遠不會接收內容。
憑證永久鎖定為「僅限本地」。API 金鑰永遠不會通過外部基礎設施傳輸。
加密：FIPS 140-2 對齊
JieGou 使用 AES-256-GCM 搭配 BYOK（Bring Your Own Key，自帶金鑰）支援來加密靜態資料。客戶 API 金鑰以客戶管理的金鑰加密。所有傳輸中的流量使用 TLS 1.3。對於需要 FIPS 140-2 驗證密碼模組的機關，BYOK 架構允許您使用機關的 HSM 支援金鑰管理基礎設施，維持已驗證的密碼邊界。
政府部門套件
政府機關不會從頭建構自動化——它們需要與營運流程對齊的預建 workflow。JieGou 的部門套件正好提供了這一點。
採購審查。 根據 FAR/DFARS 要求分析招標文件，標記不合規條款，並產生合規檢查清單。包含審批閘門，要求簽約官員簽核後才能分發任何輸出。
合約分析。 從合約文件中提取關鍵條款、義務、截止日期和交付項目。與機關標準範本比對並標示偏差。
事件應變。 對應 NIST SP 800-61 Rev. 2。警報分類、嚴重性分級、應變計畫產生、事後報告和利害關係人通知——搭配升級觸發器，在重大事件時呼叫事件指揮官。
合規報告。 從平台資料產生定期合規報告：控制狀態、發現摘要、補救追蹤。格式適用於 FISMA 季度報告和 POA&M（行動計畫與里程碑）更新。
民眾陳情回覆。 從民眾來函起草回覆信件，套用機關語調和政策指引，並在發送前經由主管審批。
每個套件都配備審批閘門，強制執行政府標準作業程序所要求的審查 workflow。沒有經過具備適當角色和部門範圍的使用者人工授權，任何輸出都不會定案。
立即開始
離線部署、自建模型推理、NIST 800-53 控制措施對應，以及 ATO 就緒的證據匯出——這些不是事後附加的功能。它們是架構決策，而 JieGou 正是建構在這些決策之上。
對於目前使用 n8n 進行 workflow 自動化的機關：n8n 已累計 8 個已公開的 CVE，且其憑證儲存模型存在架構性漏洞。對於政府安全要求——單一 CVE 就會觸發干擾營運的補救時程——這是不可接受的。JieGou 提供直接遷移路徑，搭配 workflow 相容的匯入工具。
在政府產業頁面進一步了解 JieGou 的政府能力。對於需要離線部署的機關，請參閱離線部署指南。如需討論您機關的特定需求，請聯繫我們的團隊安排技術簡報。