Every time you paste contract text into an AI tool, you hand confidential client data to a third party.
In this article, we present an alternative called as 'Moderation Layer', understand how it works, and what to look for when evaluating legal AI vendors.
A standard commercial contract is one of the most information-dense documents a business produces. A single SaaS agreement or M&A purchase agreement might contain the names of every party and their executives, the exact deal value, indemnification caps, IP assignment terms, termination triggers, and jurisdiction-specific compliance language. That is exactly the kind of data that attorney-client privilege exists to protect.
Now consider what happens when a lawyer or legal ops team pastes that contract into ChatGPT, Gemini, or any LLM-powered review tool with no intermediary privacy layer. The full text, every sensitive data point included, travels to the LLM provider's servers. Three things can go wrong from there.
Training data absorption: Many LLM providers use input data to train and improve their models by default. OpenAI's ChatGPT FAQ has stated that conversations may be reviewed by AI trainers to improve their systems. Once your contract language enters a training dataset, it cannot be recalled. In March 2023, Samsung engineers pasted proprietary semiconductor source code and internal meeting transcripts into ChatGPT across three separate incidents within a 20-day window. That data became part of OpenAI's corpus. Samsung launched disciplinary investigations and eventually restricted employee access to the tool.
Platform breaches and bugs: In the same month as the Samsung incident, OpenAI disclosed a bug that allowed some ChatGPT users to see titles from other users' conversations and, for a small percentage of ChatGPT Plus subscribers, payment-related information including names, email addresses, and partial credit card numbers. The bug was patched, but the incident proved that even the most well-funded AI providers are vulnerable to data exposure events.
Privilege waiver: Sharing confidential client information with a third-party AI tool is, legally, sharing it with a third party. That can compromise attorney-client privilege over the data. The analysis is not abstract. Multiple bar ethics opinions now address this risk head on.
Average breach cost for professional services firms (IBM, 2024)
Of lawyers reported using AI in their practice in 2024
Of law firms had formal AI usage policies in place
The bottom line: using AI for contract work is not optional going forward. But doing it without a privacy architecture is indefensible both ethically and commercially.
A moderation layer is a processing step that sits between the user and the language model. Its entire purpose is to ensure that the LLM never sees raw confidential data while still delivering useful, contextualized analysis back to the user.
The process has three stages: detect, replace, and reverse.
First, the moderation layer scans the contract text and identifies every sensitive entity: party names, individual names, financial figures, dates, addresses, email addresses, phone numbers, and any custom-flagged terms. Second, it replaces each detected entity with a consistent pseudonymized placeholder. Third, after the LLM returns its analysis on the sanitized text, the moderation layer reverses the substitution using a securely stored mapping table, reinserting all original values into the output.
Contract text in Word
→
Local moderation layer detects & anonymizes→
→
Only sanitized text sent to LLM
→
LLM output de-anonymized via mapping table
→
User sees full, contextualized result
The critical word here is pseudonymization, not redaction. This distinction makes or breaks the approach. Here is why.
If you replace "Acme Corp" with [REDACTED], you destroy the relational context the LLM needs to reason about the contract. The model cannot tell which party has which obligation. If three different entities are all replaced with [REDACTED], the analysis becomes incoherent.
Pseudonymization replaces "Acme Corp" with PARTY_A consistently throughout the document. Every reference maps to the same placeholder. The LLM can now determine that PARTY_A has indemnification obligations to PARTY_B, that the liability cap is AMOUNT_1, and that the agreement terminates on DATE_1. The structural and semantic relationships are fully intact. After the LLM returns its analysis, the mapping table swaps the placeholders back. The user sees a complete, fully contextualized result. The AI saw none of the real data.
Let's look at what this actually looks like in a real contract clause.
The LLM can analyze the anonymized version with the same accuracy as the raw version. It can identify the indemnification structure, flag that the liability cap is one-directional, note the notice period requirement, and compare the clause against standard market terms. It just does all of this without knowing who the parties are, how much money is at stake, or who to contact.
A production-grade moderation layer is not a single technique. It combines three detection methods, each covering a different category of sensitive data. Here is how each works, with contract-specific examples.
NER is a machine learning technique trained to identify named entities within unstructured text: person names, organization names, geographic locations, dates, and similar categories. In a contract context, a trained NER model reading the sentence "Pursuant to Section 4.2, Rajesh Mehta of Meridian Technologies shall deliver all source materials to Sarah Chen at Pinnacle Partners by March 15, 2026" will flag five entities:
NER handles the hardest category of sensitive data: names and entities embedded in natural language where no predictable format exists. Open-source NER libraries like spaCy and tools like Microsoft Presidio provide solid baselines. Production-grade legal AI systems fine-tune their NER models on contract-specific language to improve accuracy on entities like law firm names, subsidiary structures, and jurisdiction references that generic models often miss.
Regex handles the structured, format-predictable data that NER models sometimes overlook. Contracts are full of these: monetary values with currency symbols, email addresses, phone numbers, Social Security numbers, EIN/TIN numbers, bank account numbers, and IP addresses.
Regex is deterministic and fast. If a pattern is defined correctly, it catches every match without exception. The limitation is that it only works on data with predictable formats. A company name like "Meridian Technologies" has no universal format, which is why NER handles that category.
This is where legal-specific anonymization diverges from generic PII redaction. Off-the-shelf NER and regex will not flag terms that are sensitive in context but not inherently identifiable: internal project codenames, deal identifiers, specific product names under NDA, proprietary clause language, or department-specific terminology.
A configurable dictionary layer lets InfoSec and legal teams define additional terms that must be anonymized. For example, a pharmaceutical company might flag the codename of an unreleased drug. A technology company might flag a proprietary algorithm name. A law firm might flag specific matter numbers that could identify a client engagement.
Why all three layers are non-negotiable
No single technique catches everything. NER handles names and contextual entities but can miss unusual formatting. Regex catches structured patterns with precision but has no understanding of context. Custom dictionaries fill the gaps unique to each organization. A vendor relying on only one or two of these techniques will have blind spots. The layered approach is what separates a production system from a proof-of-concept.
After detection, the moderation layer builds a mapping table that pairs each original entity with its placeholder. This table is the key to reversibility.
Consistency in the mapping is critical. If "Meridian Technologies" appears 47 times across the contract, it must map to PARTY_A every time. Inconsistent mapping would confuse the LLM and degrade analysis quality. After the LLM returns its output (which references PARTY_A, AMOUNT_1, etc.), the de-anonymization step consults the mapping table and swaps every placeholder back to its original value. The user sees a complete result. The LLM never saw any of the real data.
The mapping table itself must be stored securely within the user's environment or encrypted on the vendor's servers, and it must never be sent alongside the anonymized text to the LLM provider. If it were, the entire exercise would be pointless.
Let's see the full cycle in a complete example.
The LLM can analyze this clause fully: it can flag the non-compete duration, evaluate the geographic scope, note the liquidated damages provision, and compare these terms against market norms. It just does all of this without knowing the real names, the real dollar figure, or the real jurisdictions.
After the LLM returns its risk analysis, the moderation layer reverses the substitution. The user's output reads: "The 24-month non-compete period for David Park is within standard range, but the $2,000,000 liquidated damages clause for NovaBridge Solutions may face enforceability challenges in the United Kingdom, where..." Every original value is restored. The analysis is fully contextualized.
Not all approaches to this problem are equal. Here is how the four most common configurations stack up across the criteria that matter to legal teams.
Two rows in that table deserve special attention. First, "breach impact at vendor" is the blind spot in pure server-side approaches. If the vendor's own infrastructure is compromised, any raw data that was held pre-anonymization is at risk. Client-side and hybrid approaches eliminate this vector entirely because the vendor never handles raw contract text. Second, "InfoSec auditability" matters more than most legal teams realize at the evaluation stage. When a client or regulator asks, "Can you prove that no confidential data left your environment?", you need logs and stored anonymized versions to demonstrate compliance after the fact.
If you are a GC, CLO, or legal ops leader evaluating AI tools for contract work, these are the questions that separate serious vendors from those improvising on privacy.
This is the threshold question. If the vendor cannot draw a clear architecture diagram showing where anonymization happens in the data flow, that is your answer.
Red flag: "We use the enterprise API, so your data is not used for training." A no-training clause is a contractual safeguard, not a technical one. They are not substitutes for each other.
Each model has different trust and exposure implications. Client-side (e.g., inside a Word add-in) means raw data never leaves the user's machine. Server-side means the vendor handles raw data briefly. Hybrid gives you defense in depth.
Best practice: insist on an architecture where raw contract text does not travel to any external server, including the vendor's.
Look for NER + regex + custom dictionaries. A vendor using only regex is missing contextual entities. A vendor using only NER is missing structured patterns. You need all three for contract-grade coverage.
Ask specifically: "Can you walk me through what catches a party name vs. an email address vs. a deal codename in your system?"
Every organization has terms that are sensitive in their context but would not be flagged by generic PII detection. You need the ability to add custom dictionaries, proprietary terms, and category-level rules (e.g., "anonymize all financial figures," "anonymize all jurisdiction references").
This is not a nice-to-have. It is a prerequisite for any enterprise that handles client-specific confidential information beyond standard PII.
Users should be able to preview the exact text that the LLM will receive. This is both a trust mechanism and a quality assurance step. If a sensitive term was missed, the user catches it before the data leaves.
Transparency builds user confidence and provides an additional manual check layer alongside the automated detection.
When a client or regulator asks for evidence that their data was handled properly, you need granular logs: who triggered the analysis, what was anonymized, what was sent, and to which LLM provider.
Stored anonymized versions of documents provide an after-the-fact proof that you can reference during audits or in response to incident inquiries.
The mapping table links placeholders to original values. If it is stored on the same server as the anonymized text, or accessible to the LLM provider, the anonymization is cosmetic.
The mapping table should be stored within the user's environment (or encrypted separately) and should never accompany the anonymized text to any external service.
ContractKen's moderation layer is built directly inside Microsoft Word as an add-in. This is a deliberate architectural choice, not a convenience feature. By running the moderation layer locally within Word, the first and most important stage of anonymization happens on the user's own machine, before any contract data touches an external server of any kind.
Here is the data flow in practice:
Step 1: Local detection and anonymization - When a user triggers AI analysis from within Word, the moderation layer scans the full contract text using a combination of NER, regex, and configurable custom rules. It identifies and replaces all sensitive entities with consistent pseudonymized placeholders. The user can preview the exact anonymized version of the document at the click of a button, a WYSIWYG (What You See Is What You Get) view that shows precisely what text will be sent externally. Nothing leaves the user's machine until the user is satisfied with the anonymization.
Step 2: Server-side validation - The already-anonymized text is sent to ContractKen's server, where a second-pass validation layer checks for edge cases the client-side processing may have missed: unusual entity formatting, misspellings, domain-specific patterns. This step operates on anonymized text only. ContractKen's own servers never see the raw contract.
Step 3: LLM analysis - Only the fully sanitized text, validated by two passes, is forwarded to the LLM for analysis. The model processes the anonymized contract and returns its output.
Step 4: De-anonymization and delivery - ContractKen's moderation layer consults the securely stored mapping table and reverses every placeholder substitution. The user sees a fully contextualized result directly in Word, with all original party names, financial figures, and dates restored.
Three features make this approach especially relevant for enterprise legal teams:
Admin-configurable sensitivity rules. InfoSec teams have the ability to define what words, phrases, and data categories qualify as sensitive, private, or confidential. The system automatically anonymizes standard PII elements and financial information, but administrators can add proprietary terms, custom clause language, and organization-specific identifiers. This means the moderation layer adapts to each organization's specific risk profile rather than applying a one-size-fits-all ruleset.
Granular audit logs. Every AI interaction is logged with full detail: who triggered the analysis, what data was shared, which AI provider received it, and when. The anonymized versions of documents are stored separately to create a complete audit trail. This is not just about compliance in theory. It means that when a client asks, "Can you prove our contract data was protected?", there is a documented, auditable answer.
WYSIWYG anonymization preview. Before any data leaves the user's environment, users can view the actual anonymized version of their document. This serves as both a trust mechanism (users can verify the moderation layer is working) and a quality assurance step (if a sensitive term was missed by the automated detection, the user catches it visually before the text is sent).
Why "inside Word" matters architecturally
Most legal AI tools require users to upload contracts to a separate web application. That means raw contract text travels from the user's machine to the vendor's servers before any anonymization occurs. Even if the vendor anonymizes before calling the LLM, the vendor has already received raw data. By running the moderation layer inside Word itself, ContractKen ensures that the first anonymization pass happens locally. The raw text never enters any external server at all. For legal teams evaluating AI tools against ABA Opinion 512's "reasonable efforts" standard, this architectural difference is the most defensible position available.
Contracts contain party names, deal values, indemnification caps, IP assignments, and personally identifiable information. When you paste this into a public LLM, you risk training data absorption (the provider may use your input to improve its models), platform breaches (OpenAI disclosed a bug in March 2023 that exposed user conversations), and privilege waiver (ABA Formal Opinion 512 warns that sharing client data with third-party AI tools can compromise attorney-client privilege). Samsung's 2023 incident, where engineers pasted proprietary source code into ChatGPT across three separate occasions, remains the most widely cited example of this risk materializing.
A moderation layer is a processing step between the user and the LLM. It scans contract text using NER, regex, and custom rules to identify sensitive entities, replaces them with consistent pseudonymized placeholders (e.g., "Acme Corp" becomes "PARTY_A"), sends only the sanitized version to the LLM, and then reverses the substitution after the model returns its analysis. The LLM never processes actual confidential data, but the user receives a fully contextualized output with all original values restored.
Server-side anonymization processes the contract on the vendor's cloud server before forwarding sanitized text to the LLM. The vendor sees raw data briefly. Client-side anonymization runs locally on the user's machine (for example, inside a Word add-in), so raw text never leaves the user's environment. A hybrid approach runs client-side anonymization first, then server-side validation catches edge cases. The hybrid approach is the gold standard for legal workflows because even the vendor's own servers never handle raw contract text.
No. The key is pseudonymization, not redaction. Replacing "Acme Corp" with "[REDACTED]" destroys context. Replacing it with "PARTY_A" consistently throughout the document preserves every structural and relational relationship the LLM needs. The model can still analyze obligations, risk allocation, liability caps, and clause structure. After analysis, the original values are swapped back. The quality difference is negligible for contract review, risk scoring, and clause extraction tasks.
ABA Formal Opinion 512 (July 2024) requires lawyers to keep client information confidential under Model Rule 1.6 and to make "reasonable efforts" to prevent unauthorized disclosure. The opinion specifically warns that self-learning AI tools create risks of confidential data disclosure, requires informed client consent before using such tools with client data, and states that boilerplate language in engagement letters is insufficient. State bars in California, Florida, New York, New Jersey, and Pennsylvania have issued parallel guidance.
Production-grade systems combine three techniques. Named Entity Recognition (NER) uses ML models to identify unstructured entities like person and organization names. Regular expressions (regex) catch structured patterns like email addresses, phone numbers, monetary amounts, and tax IDs. Custom dictionaries and rules handle domain-specific terms that generic models miss, such as internal project codenames, proprietary product names, and matter identifiers. All three are needed because each covers a different category of sensitive data.
Enterprise plans and API access offer better data handling: OpenAI states that API data is not used for model training, and enterprise agreements include stronger confidentiality terms. However, your data still travels to third-party servers. In a breach, subpoena, or security incident, that data is exposed in full. A no-training clause is a contractual safeguard. An anonymization layer is a technical safeguard. For regulated industries, you need both. With a moderation layer in place, even a complete compromise of the LLM provider's systems exposes only meaningless pseudonymized text.
ContractKen uses a hybrid moderation layer built inside Microsoft Word. The first anonymization pass runs locally within the Word add-in, so raw contract text never leaves the user's machine. A server-side validation pass catches edge cases on the already-anonymized text. Only fully sanitized text reaches the LLM. Users can preview the exact anonymized document before sending, InfoSec teams configure what qualifies as sensitive, and granular audit logs record every AI interaction with full detail. The architecture means that neither ContractKen's servers nor the LLM provider ever handle raw contract data.
.avif)
