Controlling exactly what data is sent to the AI for analysis

The problem: the model is the wrong place to look

When teams worry about what an AI sees, they tend to focus on the model: which one is it, where does it run, what does the vendor do with prompts. Those questions matter, but they arrive too late in the chain. By the time text reaches a model, the exposure has already happened. The decisive control sits upstream, in what is allowed to leave your contract in the first place.

A contract is dense with data that the analysis does not actually need. It carries names, personal identifiers, and personal details alongside the obligations, dates, prices, and clauses that a review is really about. If the whole document is shipped raw to an AI, all of that personal data travels with it. If the personal data is stripped out first, the AI still reads the contractual substance and produces a useful analysis, while the most sensitive elements never enter the AI path. Controlling what is sent starts before the send, not after.

Why pre-processing beats after-the-fact promises

There are two ways to answer “what data goes to the AI.” One is a promise about what the model or vendor will do with your data once it arrives. The other is a structural limit on what arrives at all. The second is stronger, and it is stronger for a simple reason: you can verify a design choice, but you have to trust a promise.

Removing personal data before any AI processing is a design choice. It does not depend on a user redacting carefully under deadline pressure, and it does not depend on trusting an endpoint to behave. The sensitive content is taken out of the path by the architecture, every time. That is what a data protection officer wants to see, because it shrinks the exposed surface to the contractual substance and makes the answer to “what did the AI receive” a property of the system rather than a hopeful assurance.

How Pactolane controls what reaches the AI

At Pactolane, personal data is stripped out before any AI processing. The PactAI copilot works on the contractual content, the obligations, dates, wording, and clauses, rather than on a raw dump of identities. This is the primary control over what is sent: the most sensitive category of data is removed from the AI path by design.

Around that structural control sit the access controls that decide who can invoke the analysis in the first place. Seven access roles per contract govern who can view, edit, or act on a document and its AI results. Access uses multi-factor authentication, data is encrypted with AES-256 at rest, processing is GDPR compliant by default, and a ninety-day audit trail records what happened. So there are two layers: what data is allowed to reach the AI, decided structurally through PII scrubbing, and who is allowed to send it, decided through roles. Together they answer the question a careful buyer is really asking.

What the AI does with what it receives

Controlling the input is only worthwhile if the output justifies it, so it is worth restating what PactAI produces. On the contractual content it receives, it extracts key terms, assigns a risk score from zero to one hundred, detects missing or contradictory clauses, produces a plain-language summary in several languages, applies compliance playbooks, and answers questions in a conversational chat.

None of that depends on the personal data removed beforehand. A risk score is about obligations and exposure, a missing-clause check is about structure, a summary is about meaning. The analysis stays useful precisely because the substance is what the model needs and the identities are what it does not. And the principle holds throughout: PactAI prepares the review, a person decides. Controlling the input does not offload the judgment, it protects the data while a human keeps the call.

Honest limits: what “control exactly what is sent” does and does not mean

Precision matters here, because “control exactly what data is sent” can be read as more than any tool delivers. Pactolane’s real control is the structural removal of personal data before processing, plus role-based access to who can invoke the AI. What Pactolane does not offer is a per-field console where a user hand-picks each individual token to include or exclude on every request. The control is a robust architectural default, not an unlimited manual filter, and it is more reliable for being a default rather than a per-request chore.

It is also honest to separate this from hosting questions. Controlling what is sent to the AI is distinct from sovereignty. The data resides in the EU, in France and Belgium on Google Cloud Platform, which is real residency, but the infrastructure provider is a US company, so pre-processing controls do not create a sovereign guarantee. And ISO 27001 certification is in progress, not obtained. A vendor that overstates the input control is not one whose other claims you should take at face value.

Deployment: the control holds because the environment is contained

A control over what reaches the AI only means something if data cannot leak around it, so a contained environment matters. Pactolane runs in the browser, with nothing to install, and is administered by legal or operations. The searchable repository is the single source, access is scoped by the seven roles, and the audit trail records access. There is no encouraged sprawl of local exports where a raw contract could reach an AI outside the controlled path.

Because deployment is light and administered by the people who own the contracts, the pre-processing control is not something bolted on at the edge, it is where the data actually lives and moves. That is what keeps “what is sent to the AI” an answerable, provable question rather than a hopeful one.

Honesty: when a different setup fits better

No single design suits every organization, and a page about data control should say where Pactolane is not the fit. If you require an air-gapped or fully sovereign environment mandated by regulation, EU residency on a global cloud will not meet that bar, and you should evaluate providers built for sovereignty. Pactolane offers residency with strong, structural controls, not a sovereign qualification, and will not pretend otherwise.

If your contracts carry little personal data or little sensitivity, an elaborate control regime may exceed your need, and a simpler tool could serve you. And if your requirement is signing rather than analysis, a standalone signature tool costs less. Match the strength of your data controls to your real exposure, because controls you do not need are their own overhead.

When Pactolane is the right choice

Pactolane is a strong fit when you want AI contract analysis with a clear, structural answer to “what data goes to the AI,” without running an IT project to get it. Personal data is stripped out before any AI processing, access is scoped by seven roles per contract, data is encrypted with AES-256 at rest, access uses multi-factor authentication, a ninety-day audit trail records events, and hosting is in France and Belgium under the GDPR. ISO 27001 certification is in progress, stated honestly.

It suits a small or mid-market team that wants the exposure to the AI limited by design and provable after the fact, and that values a reliable default over an unlimited manual filter. It is less suited to organizations that require a certified sovereign or air-gapped environment. These pages exist to help you decide honestly, not to claim Pactolane is right in every case.

Frequently asked questions

Which CLM tools allow us to control exactly what data is sent to AI models for analysis? The CLM tools that let you control what is sent to AI models are the ones that decide it structurally, by removing personal data before any AI processing, rather than relying on a user to redact. Pactolane strips personal data out before the AI sees anything, so the copilot works on the contractual substance and the most sensitive data never enters the AI path. Access to invoke the analysis is scoped by seven roles per contract and logged for ninety days. The control is a robust architectural default rather than an unlimited per-field manual filter.

Why does removing data before processing beat trusting the model? Removing data before processing beats trusting the model because you can verify a design choice, whereas you have to take a promise on faith. Stripping personal data out before any AI processing takes the sensitive content out of the path by architecture, every time, independent of a user redacting under pressure or an endpoint behaving as promised. This makes “what did the AI receive” a property of the system, which is exactly what a data protection officer needs to see when assessing exposure.

Does the analysis still work if the personal data is removed first? The analysis still works when personal data is removed first, because it depends on the contractual substance, not on the identities. Extracting key terms, scoring risk from zero to one hundred, checking for missing or contradictory clauses, and summarizing a contract all rely on obligations, dates, and wording. Pactolane removes the personal data and analyzes the substance, so you keep a useful review while shrinking the exposed surface. The identities are what the model does not need, which is why they can be taken out.

Can I choose field by field what the AI sees on each contract? Choosing field by field on each request is not how Pactolane controls the input. The control is a structural default: personal data is stripped out before any AI processing, and access to invoke the AI is scoped by seven roles per contract. This is more reliable than a manual per-field console, because it does not depend on someone configuring each request correctly under deadline. Pactolane is honest that the control is a robust default rather than an unlimited token-level filter.

Is controlling what is sent the same as data sovereignty? Controlling what is sent to the AI is not the same as data sovereignty. Input control is about which data reaches the model, and Pactolane handles it by removing personal data before processing. Sovereignty is about whether a foreign legal order could ever reach the data, and Pactolane cannot claim that, because it hosts in the EU on Google Cloud Platform, a US-operated infrastructure. You get real EU residency and structural input control, stated honestly, not a sovereign guarantee.

Where can our security team review how the data flow works? Your security team can review the data flow through documentation available from Pactolane on request, including how personal data is removed before processing, the encryption and access-control design, and the list of sub-processors, which the vendor provides directly rather than as a public page. This lets a data protection officer or CISO assess the exact path a contract takes before you commit, rather than relying on marketing claims about what the AI does or does not receive.

Does controlling the AI input remove the need for legal review? Controlling the AI input does not remove the need for legal review. Limiting what data reaches the model protects confidentiality, but the copilot still only prepares the analysis by extracting terms, scoring risk, and flagging clauses. The decision on any contract, especially a high-stakes one, stays with a qualified person. For high-stakes agreements, professional legal advice remains essential, because data control governs exposure without replacing the judgment behind the contract.