GCs and legal operations leaders are under pressure to adopt AI and CLM platforms. The tools themselves are increasingly capable. The question that consistently goes unanswered is whether the organisation's contract infrastructure is ready for them.
- Four meaningfully different tool categories — general-purpose LLMs, legal-specific AI, DMS and ECM platforms, and CLM platforms — are routinely conflated, each with different capabilities, costs, and appropriate use cases.
- Five maturity stages define where an organisation actually stands, from email-only handling through to active lifecycle management. Most organisations are at Stage 3 or below.
- Three named failure modes — the Repository Illusion, the Approval Trap, and the Process Mirroring Trap — explain why tool investments consistently underdeliver.
- The Microsoft Copilot ecosystem is actively marketed as a contract management solution. Understanding why it maps to Stage 3, not Stage 4, is a prerequisite for any technology evaluation.
- CLM pricing models — per-user and per-document — can lock in the dysfunction they are supposed to resolve before anyone questions it.
- Six internal evaluation questions should precede any vendor conversation. The most overlooked: whether the organisation has documented its legal positions clearly enough for any AI tool to apply them.
The question everyone is asking is the wrong one.
GCs and legal operations leaders across industries are asking variants of the same question: should we be using AI? Which tool is best? Do we need a contract lifecycle management system, or is ChatGPT sufficient?
These questions are not wrong in themselves. They are wrong as starting points. Choosing an AI tool before understanding your organisation's contract infrastructure is like specifying a building's HVAC system before you have a floor plan. The tool is a solution. The question is what, precisely, you are trying to solve.
What these tools actually are
The confusion starts with the category. "AI in legal" encompasses at least four meaningfully different types of tools, each with different capabilities, costs, and appropriate use cases.
General-purpose LLMs — Claude, GPT, Gemini. Conversational, document-capable, and genuinely useful for drafting, summarising, reviewing a contract placed in front of them, and answering questions about a clause. No workflow, no persistent memory, no integration with your systems. They operate across languages without the restrictions that affect many purpose-built legal tools.
Legal-specific AI — Harvey, Spellbook, CoCounsel, Legora. Models fine-tuned on legal corpora with workflow wrappers designed for how lawyers actually work. Better legal reasoning and stronger workflow integration; still largely task-level rather than systemic. Several run on a mix of models — Spellbook uses GPT, Claude, and other LLMs; Legora is built primarily on Claude. The meaningful distinction is workflow depth and legal domain tuning, not the underlying model.
Document Management Systems and ECM platforms — SharePoint, Box, Google Drive, OpenText, DocuWare. Increasingly layered with AI search and metadata capabilities that can look, from the outside, like contract management. They are not. This category warrants more attention than it typically receives.
CLM platforms — Ironclad, Leah (formerly ContractPodAi), Icertis, Agiloft, DocuSign CLM, Contracts 365, Luminance. Workflow and repository systems with varying degrees of AI capability. More heterogeneous than the label suggests.
Point solutions — Kira/Litera, Relativity, Westlaw Precision, Lexis+ AI. Narrow use case, deep capability: contract extraction and analysis, eDiscovery, legal research.
DMS and ECM platforms are not CLMs
Before proceeding, one category error warrants direct attention: the belief that a Document Management System or Enterprise Content Management platform is sufficient to serve as a CLM. A DMS stores, organises, and retrieves documents — version control, folder structure, access permissions, search. An ECM platform extends this with workflow routing, records management, content capture, and compliance features. The distinction between DMS and ECM matters operationally but not strategically. Both answer the same question: where is the document, and who approved it? Neither answers the question that matters for contract governance.
| Question | DMS / ECM | CLM |
|---|---|---|
| Where is the contract? | Yes | Yes |
| What does it say? | Partial — search only | Yes |
| What does it require? | No | Yes |
| What needs to happen next? | No | In principle |
| Was it acted on and recorded? | No | Rarely |
Storage and workflow routing are not management. The organisation that believes its SharePoint environment is managing its contracts has not made an IT mistake. It has made a governance mistake.
A specific variant of this error deserves attention. Microsoft markets the combination of SharePoint, Teams, Power Automate, and Copilot as a contract management approach — and the positioning is persuasive. Copilot adds genuine task-level value: it can summarise a contract placed before it, flag risks, and suggest revisions. But it responds to what is put in front of it, not to obligations the organisation has not thought to look for. SharePoint with Power Automate routing is Stage 3 — organised storage with an approval workflow — and adding Copilot keeps it there. A proper Microsoft-native CLM, properly configured, reaches Stage 4. The ecosystem alone does not.
Not all CLMs are the same
The CLM category conceals significant variation that buyers discover too late.
The first dimension is workflow-first versus AI-native. Many established CLM platforms were built as process and repository systems. AI capability was added later, often through acquisition. DocuSign CLM acquired SpringCM in 2018 for CLM workflow, Seal Software in 2020 for AI analytics, and Lexion in 2024 for further AI capability. The result is a platform assembled layer by layer, where the AI features that move an organisation toward genuine content visibility are licensed separately from the base system. The CLM label on the invoice does not tell you what the system is actually doing.
The second dimension is ecosystem dependency. Contracts 365 represents a distinct sub-type: a CLM built entirely within Microsoft 365, using SharePoint as the document repository and integrating natively with Teams, Outlook, Word, and Dynamics 365. For deeply Microsoft-invested organisations, this reduces implementation friction significantly. The trade-off is scope: a Microsoft-native CLM operates within the constraints of that ecosystem, which works well for many organisations but may limit flexibility for complex, multinational portfolios.
The third dimension is language coverage. The gap between what a CLM can do in English and what it can do in other languages rarely appears in vendor demonstrations. Extraction and summarisation handle most languages reasonably well. Review and revision — redlining, playbook application, negotiation assistance — are generative tasks that many systems deliver reliably only in English. The language limitation matters most for organisations with both domestic and international operations. International systems perform well in English but typically deliver limited capability elsewhere; regional systems address the local context but may lack depth for cross-border operations. Neither currently serves both needs fully. Treat a vendor's general claim of multilingual support as the starting point for that conversation, not the end of it.
Where your organisation actually stands
The maturity stages below are defined not by what system you have purchased, but by what question you can answer.
All contracts move via email from initiation through execution. Storage lives on individual hard drives or shared folders. There is no consolidated record of what contracts exist, let alone what they contain. The defining characteristic: you cannot find your contracts reliably. Everything else follows from that.
A designated shared space exists for storage. The organisation knows where contracts go when executed. Contents remain opaque — not interrogable, obligations not surfaced, everything upstream still happens via email.
A well-maintained DMS or ECM platform — metadata, search, folder discipline — that the organisation believes constitutes contract lifecycle management. The contracts are findable. What they require is not. A subtler version: a CLM purchased but used as a document store, because the AI module was not licensed or the workflow features were never adopted. Stage 2 is defined by what the system does, not by what it cost.
An internal e-approval or BPM system has been added. Contracts go through email-based drafting and negotiation, enter the approval system for sign-off, return to email for counterparty execution, then are stored. This is the stage most organisations are at. The setup feels like governance. Someone approved it. There is a process record.
What the approval system captures is authorisation — that a decision was made. It does not capture content — what was actually decided. Two risks follow: content blindness (if negotiation continues via email after internal approval, the approved version and the executed version may not be the same document) and obligation invisibility (post-signature management reverts to manual tracking — calendar reminders, institutional memory, whoever owns the relationship).
A CLM implemented over an unchanged approval workflow inherits the same blind spot. The workflow design problem must be addressed in parallel with — not after — any CLM implementation.
Contracts are stored in a genuinely interrogable system. The organisation can surface obligations, identify upcoming renewals, and answer: what does this contract require us to do next month? Stage 4 is defined by operational capability, not technology purchase. The test: can the organisation produce a list of obligations falling due in the next ninety days? Many organisations with CLMs cannot. They are functionally at Stage 2.
Obligation visibility is connected to workflow, accountability, and a closed loop of recorded action. A renewal alert triggers a defined decision process, routes to the right owner, captures the decision made, and records what was done. No current CLM platform reliably delivers this. Vendors are actively building toward it — agentic AI and obligation management features launched as recently as late 2025 describe this as their destination, not their current capability. Stage 5 requires process design, clear ownership, and governance discipline that must be built alongside — and often before — the technology.
The decision framework
The right starting point is a function of two variables: where the organisation sits on the maturity curve, and the volume and duration profile of its contracts. Three patterns deserve emphasis before using the framework.
Extraction before platform. For organisations at Stages 1, 2, and 3, the most common error is evaluating CLM platforms before establishing what contracts exist and what they contain. AI extraction — using a general-purpose LLM or purpose-built tool to analyse an existing archive — is the necessary prior step. Without it, a CLM is a workflow system with nothing meaningful to work on.
Volume is qualitative, not numerical. The framework uses descriptive categories — ad hoc, recurring, high throughput — rather than thresholds. A company with forty highly complex cross-border agreements faces different requirements than one with two hundred standard NDAs. The relevant variable is whether contracts are a volume workflow where delays and errors carry direct business cost.
Long-duration contracts change the calculus at every stage. A contract that will outlive the people who signed it creates obligation risk that manual tracking cannot manage. Institutional memory evaporates when the relationship owner moves on.
Before you call a vendor
Most CLM evaluations begin too late — the organisation already has momentum from vendor demonstrations, procurement timelines, and stakeholder buy-in before the foundational diagnostic work has been done. The internal evaluation that should precede any vendor conversation answers six questions.
The actual answer to the original question
Is a general-purpose LLM sufficient? For most tasks, yes. For task-level work — drafting, reviewing, summarising a contract in front of you — Claude, GPT, or Gemini performs well, costs a fraction of purpose-built legal tools, and operates across languages without the restrictions that affect many CLM AI layers.
The gap is not capability. It is system. A general-purpose LLM can tell you what a contract says. It cannot tell you what all your contracts say, track obligations across a portfolio, enforce the workflow that follows, or record what was done.
If the problem is a task — draft this, review that, summarise this clause — a general-purpose LLM solves it today at low cost and without implementation risk.
If the problem is a system — knowing what your contracts require across a portfolio, managing negotiation workflows at volume, tracking obligations that will outlive the people who signed them — then a CLM is the right category. But only if the organisation is at a maturity stage where a CLM can do meaningful work, has selected a tier that includes the AI functionality it needs, has verified that the system performs in the languages its contracts use, has calculated what meaningful adoption actually costs, and has done the work to document the positions and playbooks the system needs to apply.
Implemented at Stage 1, 2, or 3 without addressing the foundation first, a CLM does not skip the infrastructure problem. It sits on top of it, underused, while the organisation pays enterprise software prices for what is functionally an expensive document store.
The organisations that get the most from AI in legal operations are not the ones that bought the most sophisticated tools. They are the ones that understood where they were before deciding where they were going.
Working through any of these questions?
CloudVista works with legal teams and compliance functions to assess contract infrastructure, design governance workflows, and evaluate technology decisions. There are several ways to reach us — we would be glad to connect.
This article is for informational purposes only and does not constitute legal advice. The regulatory landscape and market data described reflect publicly available information as at the date of publication and are subject to change. Readers should obtain appropriate professional advice before taking or refraining from any action in reliance on the information contained in this article. CloudVista Consulting LLC accepts no responsibility for any loss or damage arising from reliance on this material.
企業在評估 AI 與 CLM 平台時，面臨的不只是工具選型問題，而是一個更根本的問題：現有的合約管理基礎架構，是否已達到足以讓工具發揮效用的成熟程度？
- 市場上的「法律 AI」工具，涵蓋通用型大型語言模型、法律專屬 AI、文件管理與企業內容管理平台，以及 CLM 平台等四種性質截然不同的類型，各自具備不同的功能範疇、成本結構與適用情境。
- 合約管理成熟度可分為五個階段，從完全仰賴電子郵件到主動生命週期管理。多數機構實際上處於第三階段或以下。
- 三個典型失效情境——儲存庫幻覺、審批陷阱、流程複製陷阱——說明了為何工具投資一再未能達到預期效益。
- 微軟 Copilot 生態系被積極行銷為合約管理解決方案。理解為何它對應於第三階段而非第四階段，是任何技術評估的必要前提。
- CLM 的定價模式——按用戶或按文件計費——可能在任何人質疑之前，便已鞏固了原本應當解決的結構性問題。
- 六個內部評估問題應先於任何供應商對話完成。最常被忽略的一個，是機構是否已將法律立場文件化，清晰到足以讓 AI 工具直接套用。
在法務管理的決策討論中，企業往往從錯誤的問題出發。
法務長與法務運營主管面臨的，往往是同一類詢問：法務部門是否應導入 AI？何種工具最為適合？有必要建置合約生命週期管理系統（CLM），還是 ChatGPT 便已足夠應對？
以上問題本身並無不妥，問題在於它們不應作為起點。在評估現有合約管理基礎架構之前便著手選擇工具，猶如建築圖說尚未定案便指定設備規格。工具是解決方案；首要任務，是清楚界定需要解決的究竟是什麼。
工具類別概覽
市場上的法律 AI 工具，涵蓋至少四種性質截然不同的類型，各自具備不同的功能範疇、成本結構與適用情境。
通用型大型語言模型（如 Claude、GPT、Gemini）：具備對話能力，可協助起草文件、摘要整理、審閱合約條款及回應法律問題。此類工具不具備工作流程管理功能，也無跨工作階段的記憶或系統整合能力；但其多語言處理能力，較各類專用法律工具更為靈活。
法律專屬 AI（如 Harvey、Spellbook、CoCounsel、Legora）：以法律語料庫為基礎進行訓練，並配備專為法律工作設計的操作介面，在法律推理上表現較為精準，也更符合法律人員的工作習慣，但整體仍屬任務層次工具，尚未具備系統性管理能力。部分工具採混合模型架構——Spellbook 同時調用 GPT、Claude 及其他大型語言模型，Legora 則主要建構於 Claude 之上。真正的差異在於工作流程深度與法律領域的專業調校，而非底層模型本身。
文件管理系統與企業內容管理平台（如 SharePoint、Box、Google Drive、OpenText、DocuWare）：此類平台陸續加入 AI 搜尋、工作流程與元資料管理等功能，外觀上與合約管理工具相近，但兩者有本質差異。這個類別在實務中引發的混淆，遠比通常所認知的更為普遍。
CLM 平台（如 Ironclad、Leah [前身為 ContractPodAi]、Icertis、Agiloft、DocuSign CLM、Contracts 365、Luminance）：以工作流程管理與文件庫為核心，AI 功能程度參差不一，內部差異遠比其名稱所呈現的更為複雜。
點解決方案（如 Kira/Litera、Relativity、Westlaw Precision、Lexis+ AI）：功能集中於特定應用領域——合約資料擷取與分析、電子閱覽、法律研究——功能深度高，但適用範疇有限。
DMS 與 ECM 平台不等同於 CLM
在深入探討之前，有一個常見的類別混淆值得特別說明：認為文件管理系統（DMS）或企業內容管理平台（ECM）足以承擔合約生命週期管理的角色。這並非少數例外，而是企業實務中相當普遍的誤解。DMS 的核心功能在於文件的儲存、整理與調閱——版本控管、資料夾結構、存取權限、搜尋功能；ECM 平台在此基礎上延伸，涵蓋審核流程路由、文件記錄管理與法規遵循功能。兩者在操作層面的區別有其意義，但在治理層面則無關緊要——回答的都是同一個問題。
| 問題 | DMS / ECM | CLM |
|---|---|---|
| 合約在哪裡？ | 是 | 是 |
| 合約說了什麼？ | 部分——僅限搜尋 | 是 |
| 合約要求履行什麼義務？ | 否 | 是 |
| 下一步應採取什麼行動？ | 否 | 原則上可以 |
| 行動是否已執行並留有記錄？ | 否 | 鮮少如此 |
合約儲存與審核流程路由，不等同於合約管理。企業若認為 SharePoint 環境或 ECM 平台正在管理其合約，所犯的不是 IT 層面的錯誤，而是治理認知上的錯誤。
微軟的生態系是一個值得特別關注的案例。微軟積極將 SharePoint、Teams、Power Automate 與 Copilot 的組合定位為合約管理解決方案，且定位本身頗具說服力。Copilot 在任務層次確實能提供實質幫助：可摘要呈交給它的合約、標記潛在風險，並提出修訂建議。但 Copilot 的運作方式，是回應被放在它面前的內容，而非主動識別機構從未想到要追蹤的義務。SharePoint 搭配 Power Automate 審核路由，對應第三階段——有條理的儲存環境加上簽核工作流程——加入 Copilot 並不改變其本質。在適當配置下，完整的微軟原生 CLM 平台可達到第四階段；但單靠微軟生態系本身，無法實現。
CLM 平台的內部差異
CLM 類別內部存在相當大的差異，而採購方通常在決策完成後才發現這一點。
第一個面向是工作流程優先架構與 AI 原生架構的差異。許多成熟的 CLM 平台，最初以流程管理與文件庫為核心，AI 功能是後續加入的，通常透過收購取得。DocuSign CLM 是典型例子：2018 年收購 SpringCM 取得 CLM 工作流程功能，2020 年收購 Seal Software 取得 AI 驅動的合約分析能力，2024 年再收購 Lexion 進一步強化 AI 功能。這種逐層累加的架構，意味著真正能提升合約內容可視性的 AI 功能，往往需要在基礎授權之外另行購買。發票上標注的 CLM，並不代表系統實際發揮了 CLM 的功能。
第二個面向是生態系依附性。Contracts 365 代表一種截然不同的子類型：完全建構於微軟 365 環境的 CLM，以 SharePoint 作為文件庫，並與 Teams、Outlook、Word 及 Dynamics 365 原生整合。對於深度使用微軟生態系的機構，這大幅降低了導入門檻。代價是功能範疇受限於微軟平台框架，對於複雜的跨國合約管理可能有所侷限。
第三個面向是語言覆蓋能力。供應商展示中鮮少呈現的，是英文功能與其他語言功能之間的落差。合約資料擷取與摘要屬於模式辨識型任務，大多數現代系統的跨語言表現尚可；但逐條審閱與修訂——紅線標記、談判手冊套用、議約協助——屬於生成型任務，許多系統只能在英文環境下可靠執行。這項語言限制，對同時管理本地與跨境業務的機構影響最大。目前市場上無論哪一端的系統，都無法同時滿足兩種需求。供應商聲稱支援多語言，應視為對話的起點，而非評估的終點。
合約管理成熟度框架
以下五個階段，以「能回答什麼問題」作為定義標準，而非以「採用了哪套系統」作為依據。
所有合約均透過電子郵件處理，從發起到簽署執行皆是如此。文件若有儲存，也僅散落在個人電腦或共用資料夾中。核心問題：無法可靠地找到合約。其他問題皆由此衍生。
已建立合約存放的指定位置，機構知道合約簽署後應歸檔至何處，但合約內容仍屬不透明——系統無法進行實質內容查詢，履約義務無從呈現，而存檔環節以上的所有流程仍透過電子郵件進行。
機構已建置完善的 DMS 或 ECM 平台，並認為這等同於合約生命週期管理。合約確實找得到，但合約要求履行的義務仍無從追蹤。另一種更隱蔽的情形是：CLM 系統已購置，卻主要作為文件存放空間使用——可能是 AI 模組從未取得授權，或工作流程功能從未被業務團隊實際採用。第二階段的定義在於系統實際發揮的功能，而非採購金額。
機構在第二階段的基礎上，增設了內部電子簽核或 BPM 系統。合約經由電子郵件起草與談判，進入簽核系統完成內部審批，通常再透過電子郵件送交對方簽署，最後歸檔存查。這是多數機構所處的階段。
這樣的設置看起來具備治理機制——有人核准了，有流程記錄在案。但簽核系統記錄的是授權決定的事實，而非決定的內容。這個階段有兩項特有風險：其一是內容盲區——簽核記錄告知某份合約已獲核准，卻無法確認最終版本的實際內容；其二是義務追蹤缺失——簽核系統的設計目的不在追蹤合約執行後的履約義務，簽署後的管理仍回到人工處理模式。
在未調整簽核工作流程的情況下導入 CLM，等同於繼承了同樣的盲區。工作流程的設計問題，必須與 CLM 導入同步處理，不能留待事後補救。
合約存放於可進行實質內容查詢的系統中。機構能跨合約進行搜尋、呈現履約義務、掌握即將到期的合約，並能回答：這份合約要求我方在下個月完成什麼？判斷標準不在於機構是否擁有 CLM，而在於能否立即產出未來九十天內到期義務的完整清單。許多擁有 CLM 的機構做不到這一點，實質上仍停留在第二階段。
義務可視性與工作流程、責任歸屬及行動記錄形成完整的管理閉路。到期提醒不只是通知，而是觸發一套明確的決策流程，指派給適當的負責人，記錄決定內容，並保存執行記錄。目前尚無任何 CLM 平台能可靠地實現這個階段。供應商正積極朝此方向發展——2025 年底推出的代理型 AI 功能與義務管理能力，是以此為目標，而非當前已有的能力。第五階段需要流程設計、清晰的責任歸屬，以及必須與技術系統同步建立——通常還應先於技術系統建立——的治理紀律。
決策框架
合適的起點取決於兩個變數：機構在成熟度曲線上的實際位置，以及合約的數量規模與期限特性。在使用框架前，有三點值得特別關注。
資料擷取先於平台導入。對處於第一至三階段的機構而言，最常見的錯誤是在尚未釐清合約數量與內容之前，便急於評估 CLM 平台。AI 擷取——透過通用型語言模型或專用工具分析現有合約存檔——是必要的先行步驟。
合約量應以定性描述，而非數字門檻作為判斷標準。框架採用描述性分類——零散案例、定期業務、高量作業——而非設定具體數量門檻。擁有四十份高度複雜跨境供應合約的機構，與擁有兩百份標準保密協議的機構，面對截然不同的工具需求。
長期合約在每個階段都會改變評估邏輯。一份期限將超過簽署人任期的合約，會形成人工追蹤無法有效管理的義務風險。負責該合約關係的人員離職後，相關的業務脈絡與機構記憶也隨之消散。
聯繫供應商之前
多數 CLM 評估啟動得過早——在完成基礎診斷工作之前，機構便已受到供應商展示、採購時程與內部共識的推動而向前走。以下六個問題，構成在接觸任何供應商之前應完成的內部評估。
回到最初的問題
通用型大型語言模型是否已足夠？對多數任務而言，答案是肯定的。任務層次的工作——起草文件、審閱合約、摘要整理——通用型 LLM 表現優異，費用遠低於各類專用工具，且多語言處理能力較許多 CLM 的 AI 功能更為靈活。
差距不在能力，而在系統。通用型大型語言模型能告知某份合約的內容，卻無法掌握整個合約組合的整體狀況、追蹤跨合約的履約義務、執行後續工作流程，或留存行動的執行記錄。
若問題屬任務層次——起草這份文件、審閱這份合約、摘要這個條款——通用型大型語言模型即可在今日以低成本解決，且無需承擔導入風險。
若問題屬系統層次——掌握合約組合的整體義務狀況、管理大量的合約談判工作流程、追蹤期限將超過簽署人任期的合約義務——則 CLM 才是合適的解決方案類別。但前提是：機構必須處於 CLM 能發揮實質作用的成熟度階段、選擇確實涵蓋所需 AI 功能的授權方案、確認系統能在合約實際使用的語言環境下有效運作、誠實估算全面導入的真實成本，並完成談判立場與作業手冊的前置準備工作。
在未先解決基礎架構問題的情況下，於第一至三階段導入 CLM，並不能跨越基礎缺口。系統將疊加於原有問題之上，使用率低落，機構卻支付企業級軟體的費用，實際上只是擁有了一套昂貴的文件存放空間。
從 AI 與 CLM 導入中獲益最多的機構，不是購置最精密工具的機構，而是在決定下一步之前，已清楚掌握自身實際所在位置的機構。
正在思考上述任何問題？
雲蔚管理顧問協助法務團隊與法規遵循職能，評估合約管理基礎架構、規劃治理工作流程，並提供科技選型的決策支援。歡迎透過多種管道與我們聯繫。
本文僅供參考，不構成法律建議。文中所述監管情況及市場數據反映截至發布日期之公開資訊，相關內容可能隨時變動。讀者在依據本文資訊採取或放棄任何行動前，應尋求適當的專業意見。CloudVista Consulting LLC 對因依賴本文而造成的任何損失或損害概不承擔責任。