Tag Archives: x1 enterprise

November 10, 2026 · 10:20 AM

Purview’s Limits Are Your Cost and Risk Problem

By Chas Meier

Last week, John Patzakis explained why Microsoft Purview eDiscovery is getting worse and why the reasons are structural: a multi-tenant architecture that must throttle heavy workloads, a 2 GB per hour indexing ceiling that has not moved since 2024, no service level commitment for search times, and a finite pool of compute that Microsoft has told investors it allocates to its highest-value opportunities, with Copilot first in line.

That post was about the cause. This one is about the consequence, and it is a consequence that reaches well beyond legal operations. When the tool at the front of your eDiscovery workflow cannot filter reliably, the organization’s answer is almost always the same: collect everything and sort it out later. Every gigabyte that leaves your environment that way is a gigabyte you pay to process, host and review, and a gigabyte that now sits somewhere you do not control, at exactly the moment attackers are becoming faster and better equipped than they have ever been.

The argument below is simple. Purview’s limits drive over-collection. Over-collection drives cost. Cost and copies drive risk. And the risk curve is about to steepen.

When Filtering Fails, Over-Collection Becomes the Default
In principle, Purview lets you search before you collect. In practice, the service providers and enterprise teams we speak with tell us that targeted collection in Purview has become something they plan around rather than rely on.

  • Searches stall or time out.
  • Indexing runs at 2 GB per hour, so a 500 GB custodian set takes more than ten days to index before a search can be trusted.
  • Partially indexed items that exceed parsing limits quietly fall outside keyword results.
  • Exports are capped at 2 GB per hour per mailbox with daily tenant-level limits, and anything still running after seven days is cancelled.

Faced with a deadline and a toolset that cannot be trusted to narrow the data defensibly, legal teams do the rational thing: they widen the net. Rather than risk a motion over an under-inclusive search, they pull entire mailboxes, entire OneDrive accounts, entire Teams channels, and push the filtering downstream to a processing platform or a service provider where the tools actually work. One provider described it to us as “collect the custodian, not the matter.”

This is not a failure of judgment by the legal team. It is the predictable response to a collection tool that cannot do its job at enterprise scale. But it means that the single most effective cost and risk control in eDiscovery, culling data before it ever leaves the enterprise, is being abandoned at the very step where it matters most.

Not a Purview User? You Probably Are One Anyway
Many organizations read our Purview posts and conclude they do not apply because the legal team never logs into the Purview portal. They use a service provider, or a collection toolkit from their review platform vendor, or a connector that “just pulls from Microsoft 365.” That conclusion is usually wrong.

Look under the hood of most Microsoft 365 collection workflows and you find Purview. Many third-party connectors and service provider toolkits are built on Microsoft’s eDiscovery search and export APIs, which means they inherit the same index, the same 2 GB per hour ceilings, the same tenant-level export caps and the same throttling. Some tools run a Purview search and export in the background and present the result in their own interface. Others collect whole mailboxes through Graph or EWS precisely because the Purview search path is too slow and unreliable to filter with, which is over-collection by design. Either way, Purview’s limitations are shaping what gets collected from your tenant, even if nobody on your team has ever opened it.

If you are not sure which category your workflow falls into, that is worth finding out. Ask your provider or your platform vendor two questions:

  1. Does your Microsoft 365 collection depend on Purview’s index or Microsoft’s eDiscovery APIs?
  2. What percentage of the data you collect from our tenant is ultimately produced?

If the first answer is yes and the second answer is in the low single digits, you are an indirect Purview user, and you are paying for it.

The Volume Does Not Disappear. It Moves Downstream.
Data that is not filtered at collection does not go away; it flows into the next stage of the workflow. Whole-custodian collections land on a service provider’s processing infrastructure or in a hosted review platform, where the filtering that should have happened inside the enterprise is finally performed, at a per-gigabyte price. The industry has become very good at absorbing that volume, which is part of why the problem is so easy to ignore. Processing gets faster, hosting gets cheaper per unit, and analytics get better at culling. But none of that changes the fact that the data has already left.

The numbers compound quickly:
• A matter with 20 custodians and an average of 30 GB per custodian across email, OneDrive and Teams produces 600 GB of exfiltrated data before a single document has been reviewed.
• A targeted in-place search would have narrowed that to 5%; the other 570 GB is pure overhead: ingested, processed, deduplicated, and hosted for the life of the matter, and then for years afterward.
• Multiply that across every matter, investigation and regulatory request in a year and the over-collection tax on a mid-size enterprise runs into the hundreds of thousands of dollars, and for a large one, well into the millions.

Service providers see the other side of this. Their platforms are filling with data that nobody needed, and their clients are increasingly asking why the processing and hosting line items keep growing when case counts are flat. The honest answer: the collection tool upstream stopped doing its job.

Every Exfiltrated Gigabyte Is Both a Cost and a Risk
The cost side is visible on the invoice. Processing, hosting, review, productions and long-tail storage all scale with volume, and over-collection inflates every one of them. What is harder to see is that the same volume is also the organization’s single largest self-inflicted security exposure.

Consider what an eDiscovery collection actually is: a curated copy of your most sensitive communications, deliberately assembled, stripped of the access controls that protected it in the source system, and shipped to a third party. Executive email. Board materials. Privileged legal advice. Customer data, employee data, trade secrets, M&A deliberations. A whole-custodian collection does not just include the documents relevant to the matter; it includes everything that custodian ever touched. And it is now sitting on a service provider’s processing server, in a hosted review platform, in a law firm’s document management system, on an export drive, and in whatever backups each of those parties keeps.

Each copy is a new attack surface governed by someone else’s security program, someone else’s patch cycle and someone else’s employees. Law firms and eDiscovery vendors are high-value targets precisely because they aggregate the crown jewels of many clients in one place, and the breach record of the last several years bears that out. When one of those copies is compromised, the breach notification obligations, regulatory exposure and reputational damage belong to you, not to the vendor, and they attach to all of the data that was collected, not just the small fraction that was ever relevant.

Over-collection, in other words, turns a legal cost problem into an enterprise security problem. The 95% of the collection that was never responsive was never worth that risk.

The Next 12 to 24 Months: AI on the Other Side of the Wall
If the risk calculus above were static, over-collection might be a tolerable inefficiency. It is not static. The same generative AI wave that is consuming Microsoft’s compute capacity is also arming the people who want your data.

AI has collapsed the cost and skill required to run a sophisticated attack. Phishing campaigns are now fluent, personalized and generated at scale. Vulnerability discovery and exploit development that once took skilled teams weeks can be accelerated by models that reason over code. Reconnaissance against a target’s vendors, employees and infrastructure is automated. Agentic tooling allows a single operator to run many intrusion attempts in parallel and adapt to defenses in real time. Security researchers and government agencies have been warning for the past year that AI-enabled intrusion is moving from proof of concept to routine practice, and the trend lines for breach frequency, ransomware payouts and time-to-exploit all point the same way.

Over the next 12 to 24 months, we expect frequent, aggressive and automated attacks to become the baseline rather than the exception, and we expect the organizations that aggregate other companies’ sensitive data, including eDiscovery service providers, review platforms and law firms, to remain among the most attractive targets. Vendors will keep investing in defenses. But a defender has to be right every time, and AI has made the attacker’s job dramatically cheaper.

The only exposure you fully control is the amount of data you send out in the first place. Every copy you do not create is a copy that cannot be breached.

Now Is the Time to Be Proactive
The organizations that will be in the strongest position two years from now are the ones that treat eDiscovery collection as a data governance and security decision, not just a legal workflow step. That means three things.

  • Limit exfiltration. Search, cull and validate inside your own environment, and collect only what is potentially responsive. The goal is to move the filtering step back to where it belongs, before the data leaves, so that what reaches a provider or a review platform is the matter, not the custodian.
  • Limit unnecessary cost. Every gigabyte you keep inside the enterprise is a gigabyte you do not pay to process, host, review and store. Targeted in-place collection is the single largest lever available to reduce eDiscovery spend, and it is a lever that most Microsoft 365 organizations are not currently pulling because their tooling does not let them.
  • Remain in control of your data. Run eDiscovery and governance on infrastructure you control, with search methodology you can test and document, indexes you own, and no dependence on a shared tenant’s throttling policies or a cloud provider’s capacity priorities. Control means being able to answer a court, a regulator or a board with confidence about what you searched, what you collected and where it went.

Waiting for Purview to improve is not a strategy. Last week’s post explained why its limitations are architectural and why Microsoft’s own capacity constraints make relief unlikely. Meanwhile the cost of over-collection accrues on every matter, and the risk of each unnecessary copy grows with every advance in offensive AI. The time to change the workflow is before the next large matter, not after the next breach.

How X1 Enterprise Is Different
X1 Enterprise was built for exactly this problem: search and collect in place, so that only what matters ever leaves. The differences from a Purview-dependent workflow are architectural, not cosmetic.

In-place indexing you own. X1’s patented distributed micro-indexing technology indexes Microsoft 365 data where it lives, across Exchange, OneDrive, SharePoint and Teams, alongside endpoints, file shares and other cloud sources. X1 does not use Purview’s index or Microsoft’s eDiscovery search APIs, so there is no 2 GB per hour ceiling, no tenant-level export cap, no seven-day cancellation and no throttling inherited from every other tenant on the platform.

Compute you control. X1 runs on infrastructure the customer controls, on premises or in the customer’s own cloud. Your eDiscovery and governance jobs are never queued behind Copilot or anyone else’s workload, and performance is predictable because it is yours.

Search that meets the courts’ standard. Full Boolean, proximity, wildcard and stemming queries execute consistently across email, files and Teams chat, with the ability to iteratively test, refine, validate and document search methodology before anything is collected. That is the “advanced and thoughtful” search the Kim v. Cushman & Wakefield court said Teams data requires, and the validation Special Master Favro found missing in native Microsoft 365 tools.

Targeted collection, not whole-custodian export. Because the search runs in place and can be trusted, only potentially responsive data is collected. Filtering moves back to the front of the workflow, where it cuts downstream volume, cost and exposure at the source. Collected data can be uploaded directly into Relativity for review.

Defensibility by design. Preservation, search and collection are logged and reportable, so you can show a court or a regulator exactly what was searched, when, with what criteria, and what was collected.

AI where the data lives. The same in-place architecture powers X1 AI In-Place, allowing organizations to apply AI classification directly to data in its source location for early case assessment, privilege and sensitivity identification, and information governance, again without exporting the data to do it.

Talk With X1
If your Microsoft 365 collections are coming back as whole custodians, if your processing and hosting invoices keep growing while your case count does not, or if you have never asked how much of the data you send out is actually responsive, we would like to talk.

Contact X1 to schedule a live demonstration of X1 Enterprise against a Microsoft 365 environment. Better still, bring us a recent matter. We will run a targeted in-place search on your own data and show you how much volume, cost and risk you could have kept inside the enterprise.

The next large matter is coming, and so is the next wave of attacks. Collect less, spend less and keep control of your data.

Leave a comment

Filed under AI In-Place, Best Practices, Cloud Data, Corporations, Cybersecurity, Data Governance, ECA, eDiscovery, eDiscovery & Compliance, Enterprise AI, Enterprise eDiscovery, ESI, GDPR, Information Governance, Information Management, m365, MS Teams, OneDrive

Tagged as , , , , , , , , , , ,

July 7, 2026 · 10:13 AM

Kim v. Cushman & Wakefield: A Federal Court Confirms That Email Search Terms Don’t Work for Microsoft Teams

By John Patzakis

Blog header about the Kim v. Cushman & Wakefield case, discussing a federal court ruling on email search terms and their ineffectiveness for Microsoft Teams. Includes graphics of a gavel, documents, and message bubbles.

A recent decision out of the Central District of California should be required reading for any legal team that includes Microsoft Teams as data source in their discovery plan. In Kim v. Cushman & Wakefield U.S., Inc., 2026 WL 1353455 (C.D. Cal. Apr. 24, 2026), the court held that search terms that may be appropriate for email may not be sufficient for shorter, less formal communications on a collaboration platform like Teams.

The plaintiff, Ms. Kim, alleged pregnancy discrimination after being terminated upon her return from maternity leave. The defendant asserted the termination was part of a reduction in force; Ms. Kim alleged that rationale was pretextual. The discovery dispute arose when it emerged that the defendant had not searched Microsoft Teams at all—even though, as one of the defendant’s own witnesses testified, Teams was one of the primary communication methods used at the company. To its credit, upon discovering the gap, defense counsel immediately ran the existing email search terms against Teams and produced 47 pages of messages, two of which proved relevant to the pretext analysis.

That partial cure satisfied no one. The plaintiff demanded a nearly indiscriminate search of “all reasonably likely repositories,” while the defendant maintained it had already run the terms against Teams and “there’s nothing left.” The court’s response: “Neither position is quite right.”

The Teams Ruling: Keyword Searches Alone Are Not Enough
The heart of the opinion is the court’s recognition that rerunning email-oriented search terms against Teams data is structurally flawed. The defendant’s terms all required “Connie Kim” as an anchor—e.g., “Connie Kim” NEAR “terminat!”. As the court explained:

“It is arguable whether that may work well enough even for emails, but it cannot work for MS Teams chats about transition planning among managers who might say ‘the Smartsheet’ or ‘Brooke’s workload’ without mentioning Plaintiff by name. Keyword searches alone, without more advanced and thoughtful search techniques, will be inadequate for Teams data—a medium where conversations are shorter, more informal, and less likely to include full names than email.”

The court also underscored the certification obligation that attaches once a party elects to search: “An objecting party that elects to search and produce—rather than move for a protective order—undertakes an obligation to search reasonably. See Fed. R. Civ. P. 26(g)(1)(B).” And the Rule 26(b)(1) proportionality analysis weighed in the plaintiff’s favor as to Teams, since the messages already produced confirmed that relevant communications existed in that repository.

Notably, the court declined to dictate methodology, holding that how the defendant fulfills its supplemental search obligation— “whether through custodian-based collection, refined keyword queries, or technology-assisted review—is Defendant’s choice, so long as the search is reasonable and the production is complete.” The court also traced the root cause to a pro forma Rule 26(f) conference: had the parties conducted a substantive ESI conference identifying repositories, custodians, and communication platforms at the outset, the Teams gap would have been caught months earlier.

In his excellent writeup of this case, Michael Berman of E-Discovery LLC consulted eDiscovery expert Tom O’Connor of the Gulf Coast Legal Technology Center, who raised a critical practical question: what tool was actually used for the search? O’Connor explained that while keyword searches inside Teams work, Teams supports only basic keyword matching and a few command-style filters. Per O’Connor, the native “Teams search indexes chat differently than email,” in that it:

• “Prioritizes exact word matches;
• Does not index message metadata as richly as Outlook;
• Often misses partial-word matches; and
• Returns fewer results when the term is too specific.”

In other words, even well-crafted Boolean terms can silently underperform when run against Microsoft’s native Teams index.

Why Kim Illustrates the Case for X1 Enterprise
The Kim decision validates what we have long argued at X1: when addressing MS 365 data for eDiscovery, the search methodology applied to it must be purpose-built. As we detailed when we launched our advanced MS Teams support, X1 Enterprise enables a targeted, iterative search and collection of Teams data in-place, with the ability to target individual custodians and specific messaging threads—displacing any need to mass download channels—plus unified search across Teams, OneDrive, SharePoint, Mail, laptops, and file shares, and one-click upload into Relativity for review.

Critically, X1 does not rely on the limited native Microsoft Teams index that O’Connor describes. X1’s patented technology builds its own full-featured index of Teams data, enabling precisely the “more advanced and thoughtful search techniques” the Kim court demanded. That includes detailed Boolean queries with nested operators, proximity, and wildcard/stemming support that execute consistently across both email and chat data—so counsel is not forced to choose between Outlook precision and Teams looseness. X1 also includes the ability to search on emojis, which is critical for Teams and other chat platforms, where a reaction emoji may be the entire substance of a manager’s response to a message about a “transition plan.”

X1’s patented in-place search and classification capabilities extend this further. Through the X1 API, organizations can programmatically execute searches and apply AI-driven classification models directly where the data lives—before anything is collected. Applied to the Kim fact pattern, that means counsel can iteratively test and refine looser, Teams-appropriate search terms against live data, measure the results, and classify what comes back—building a defensible, documented search methodology of exactly the kind the court invited when it referenced “refined keyword queries” and “technology-assisted review.” And because it all happens in place, the proportionality benefits are built in as only potentially responsive data is collected.

The lesson of Kim is straightforward. Courts now expect parties to identify collaboration platforms like Teams at the Rule 26(f) stage, to search them with techniques suited to informal chat data, and to do so reasonably and completely. Meeting that expectation requires solutions designed for the job.

Learn more about the X1 Enterprise Platform, or contact our sales team to schedule a live demo.

Leave a comment

Filed under Best Practices, compliance, Corporations, Data Audit, Data Governance, ECA, eDiscovery & Compliance, Enterprise eDiscovery, Enterprise Search, ESI, Information Access, Information Governance, Information Management, law firm, m365, MS Teams

Tagged as , , , , , , , , , ,

June 16, 2026 · 10:11 AM

Why X1’s AI In-Place Architecture Is a Genuine Departure from Legal AI’s Status Quo

By John Patzakis

X1 AI In-Place Architecture — AI hub connecting to distributed enterprise data sources including Microsoft 365, email, cloud, and endpoints

The legal technology market has a buzzword problem. Terms like “AI-powered,” “intelligent review,” and “automated analysis” have been applied so broadly—and so inconsistently—that they have largely lost their ability to signal anything meaningful about how a product actually works. Against that backdrop, X1’s announcement last week of AI In-Place for X1 Enterprise represents a genuinely different approach to applying AI within enterprise legal and compliance workflows. The reason for this basis is X1’s unique architecture.

To understand why, it helps to start with the dominant model that most legal AI tools share. The overwhelming majority of AI-enabled eDiscovery and governance platforms are built on a collect-first assumption: data must be moved out of its native environment—copied, ingested, centralized in a vendor-controlled repository—before any AI model can be applied to it. This is not an incidental design choice; it reflects the fundamental architecture of how most of these platforms were built, long before AI became part of the product story. The result is what practitioners have come to call the “prompt wrapper” problem: an AI interface sits in front of a conventional data pipeline, and the underlying mechanics—the cost, the risk, the latency—remain largely unchanged. A large language model with a “middleware” workflow does not solve the structural problem of what happens to sensitive data before the AI touches it.

X1’s AI In-Place architecture inverts that assumption. Rather than requiring data to travel to an AI system, X1’s patented distributed micro-indexing technology deploys AI models directly into lightweight micro-indexes at the data source itself—across Microsoft 365 environments, file shares, cloud repositories, and endpoints. The AI executes where the data lives, and the data does not move. The implications run across multiple dimensions: data never leaves the enterprise perimeter, security policies and endpoint controls remain intact throughout the process, and the computational overhead and massive AI token costs associated with large-scale data ingestion is avoided entirely. For matters involving a terabyte of data or more—where centralized collection is not merely expensive but operationally infeasible—this architectural distinction is not incremental. It changes what is actually possible.

The workflow mechanics reinforce the point. AI models are deployed into X1’s distributed micro-indexes behind the firewall, execute against enterprise data in place, and surface AI-enriched insights—tags, classifications, risk scores—into a central console without the underlying data ever being collected or copied. That means targeted collection decisions, early case assessment, and information governance actions can be driven by AI-informed analysis conducted across the full enterprise data landscape, not just against a subset of data that has already been moved. The distinction matters because the scope of analysis in the collect-first model is constrained by collection costs; in the in-place model, analysis scope is no longer tethered to collection volume. Investigations and governance programs can, in principle, cast a much wider net analytically while actually reducing the volume of data that requires review.

Mandi Ross, CEO of Insight Optix, offered a perspective that cuts to the core of what makes this architecture commercially significant: “Enabling AI directly where the clients’ data resides fundamentally changes the economics, speed, and risk profile of enterprise data discovery, investigations and compliance workflows. With X1 Enterprise AI In-Place, we can deploy AI models, pre-trained or customized for specific matters, data queries, or compliance requirements—securely within client environments, dramatically accelerating time to insight without sensitive information being collected, duplicated, or centralized outside their control.”

Ross identifies three dimensions the in-place approach changes: economics, speed, and risk. On economics, a significant lever is the reduction in review population size—AI-informed pre-collection filtering means fewer documents proceed to human review. Additionally, costs associated with collection and processing, including expensive AI token utilization, are all but eliminated. On speed, running analysis in situ, without waiting for collection and ingestion cycles, compresses time to first insight—critical in time-sensitive investigations and regulatory responses. On risk, data that does not move cannot be breached in transit, does not reside in vendor infrastructure outside the client’s control, and does not generate the compliance exposure of large-scale cross-boundary transfers. Her comment reflects what experienced practitioners understand but marketing language tends to obscure: the most consequential question about any legal AI tool is not what the AI does, but what happens to the data before and during its operation.

The enterprise deployment model reflects design discipline that distinguishes AI In-Place from retrofitted solutions. Organizations retain centralized governance over AI usage while processing remains local under existing security policies and endpoint controls. AI capabilities are fully optional and configurable at the data source level—important for organizations operating across multiple jurisdictions with differing regulatory requirements—and customer data is never used to train, fine-tune, or enrich underlying AI models, addressing a standard due diligence concern in enterprise AI procurement.

The practical use case implications are significant across several domains. In legal and eDiscovery contexts, in-place TAR and pre-collection analytics allow AI-informed decisions about what to collect before collection begins, directly reducing review volumes and costs. In information governance, AI-driven classification and policy enforcement can operate continuously across the full enterprise data estate rather than against periodic snapshots, enabling more responsive and defensible governance programs. In security and investigations, real-time insider risk detection at petabyte scale—across endpoint and cloud environments simultaneously—becomes feasible where centralized architectures make it impractical. In each case, analytical scope is no longer constrained by collection logistics.

Most legal AI products apply AI to data after it has already moved through the conventional collection pipeline. AI In-Place asks a more fundamental question: whether the pipeline itself should be reconceived. We will demonstrate it live on Wednesday, June 24—for those evaluating enterprise AI in legal, compliance, or governance contexts, it is worth seeing what a genuinely different architecture looks like in practice.

Register for the June 24 AI In-Place™ Product Tour →

Leave a comment

Filed under Best Practices, Cloud Data, Corporations, Cybersecurity, Data Audit, Data Governance, ECA, eDiscovery & Compliance, Enterprise AI, Enterprise eDiscovery, Enterprise Search, ESI, GDPR, Information Access, Information Governance, Information Management, m365, MS Teams, OneDrive, SharePoint

Tagged as , , , , , , , , , , , , , ,

May 19, 2026 · 8:33 AM

De-NISTing in eDiscovery: A Costly Provision That Shouldn’t Be in Model Orders in the First Place

By John Patzakis

A model eDiscovery order I recently came across from a federal district court issued by a respected judge included a provision requiring parties to de-NIST their files in the course of eDiscovery production. On its face, this may seem like a reasonable technical requirement to some practitioners. But this provision reflects a fundamental misunderstanding of how proportional, targeted eDiscovery collection should work — and it points to a broader problem in our industry that deserves some attention.

For those unfamiliar with the term, de-NISTing refers to the process of filtering out known, irrelevant system files from a forensic collection using the National Institute of Standards and Technology’s reference database of known file signatures. The NIST database catalogs hundreds of thousands of known operating system files, executables, DLL files, and other system-generated data that have no evidentiary value whatsoever. De-NISTing removes these files from a collection so that reviewers are not burdened with wading through mountains of irrelevant system data. The reason you need to de-NIST in the first place is because you collected a full-disk image — capturing everything on the drive, relevant or not.

And that is precisely the problem with requiring de-NISTing in a model eDiscovery order. As I have written extensively, including in our recent white paper on proportionality in eDiscovery, courts have consistently held that full-disk imaging is not the appropriate default for civil litigation collections. Going all the way back to Deipenhorst v. City of Battle Creek in 2006, courts have warned that imaging a hard drive results in the production of massive amounts of irrelevant — and potentially privileged — information. More recently, in Motorola Solutions v. Hytera Communications Corp., the court emphasized that forensic examination of a party’s computers “is no routine matter” and that courts must use caution to avoid unduly impinging on privacy interests. A model order that presupposes full-disk imaging by requiring de-NISTing is, at minimum, inconsistent with this well-established body of case law.

The 2015 amendments to Federal Rule of Civil Procedure 26(b)(1) established a clear six-pronged proportionality framework for eDiscovery, requiring parties and courts to weigh factors including the importance of the issues at stake, the amount in controversy, the parties’ resources, and whether the burden or expense of proposed discovery outweighs its likely benefits. Courts have taken these amendments seriously and have consistently limited overbroad discovery requests on proportionality grounds. A blanket model order requirement to de-NIST implicitly endorses a collect-everything methodology that runs counter to the proportionality principles embedded in Rule 26(b)(1) and the extensive case law that has developed around it.

So how does a provision like this end up in a model court order? The answer, I believe, lies in the undue influence that certain eDiscovery service providers have had on collection practices and, ultimately, on the drafting of court orders and guidelines. Some service providers have a clear financial incentive to collect as much data as possible, since their fees are calculated on a per-gigabyte basis — meaning the more data collected, processed, and hosted, the higher the bill. This volume-based business model has shaped industry “best practices” in ways that favor over-collection, and that mindset has quietly seeped into the thinking of some federal judges and the model orders they issue. What gets dressed up as technical diligence is, in many cases, simply an artifact of a business model that profits from excess.

If you are conducting a properly scoped, targeted eDiscovery collection that is consistent with the principles of proportionality — as the Federal Rules and overwhelming case law require — there is simply no reason to de-NIST. A targeted collection does not reach system files, executables, DLLs, or other non-user-generated data in the first place. You are collecting potentially relevant ESI from identified custodians, scoped by search terms, date ranges, file types, and data sources. You never touch the data that de-NISTing is designed to filter out, which means the entire de-NISTing step — and its associated cost and processing time — is unnecessary overhead born entirely of an overbroad collection methodology.

This is precisely the approach built into X1 Enterprise, which enables legal and IT teams to conduct targeted, remote collections across large numbers of custodians without ever capturing the system-level data that necessitates de-NISTing. X1 Enterprise collects only the user-generated, potentially relevant ESI within defined parameters, preserving full metadata integrity and maintaining a documented chain of custody — satisfying every requirement for forensic soundness without the bloat, expense, and proportionality concerns of full-disk imaging. In an era where courts are increasingly scrutinizing eDiscovery costs and demanding proportionality, practitioners and judges alike should be asking not how to manage the mess created by over-collection, but how to avoid creating that mess in the first place.

Leave a comment

Filed under Best Practices, Case Law, Cloud Data, Cybersecurity, Data Audit, Data Governance, eDiscovery, eDiscovery & Compliance, Enterprise eDiscovery, GDPR, Information Governance, Information Management

Tagged as , , , , , ,

February 12, 2026 · 10:15 AM

Navigating Legal and Compliance Risks When Corporations Expose Sensitive Data to AI

By Kelly Twigger and John Patzakis

Implementing AI within a corporate environment is no longer a matter of “if” but “how.” We recently addressed these challenges in our webinar, “Navigating Legal and Compliance Risks in AI,” where our panel of experts discussed the strategic transition required to build a robust risk mitigation framework. While the efficiency gains of AI—such as automating workflows and surfacing deep insights—are compelling, introducing sensitive enterprise data into these models without a tactical plan can lead to unintended consequences. These risks range from the dilution of trade secrets to complex eDiscovery obligations and substantial regulatory exposure under the GDPR.

To leverage AI safely, counsel should focus on the following grounded strategies for risk management.

Protect Trade Secrets
Under federal law, trade secret status is contingent upon the owner taking “reasonable measures” to maintain secrecy. This is a rigorous standard; if proprietary information—such as source code or high-value technical data—is fed into an unsecured AI model without strict access controls, a company risks losing its legal protections entirely.

  • Review the Judicial Standard: In Snyder v. Beam Technologies, Inc., the 10th Circuit affirmed that failing to use confidentiality protections or allowing information to reside on unsecured devices can defeat trade secret status.
  • Maintain Active Safeguards: Courts emphasize that consistent and active safeguards are required to maintain secrecy. Lax internal controls during AI interactions can be cited as evidence that “reasonable measures” were not maintained.
  • Implement No-Prompt Zones: Establish “No-Prompt Zones” for your organization’s most sensitive intellectual property. By isolating core IP from third-party cloud models, you maintain a defensible record of “reasonable measures” that can withstand scrutiny in litigation.

Manage the eDiscovery Paper Trail
AI interactions—both the prompts submitted by employees and the responses generated by the tools—are considered discoverable Electronically Stored Information (ESI). These records are part of the corporate record and are subject to subpoena and legal holds.

  • Understand the Technical Reality: Microsoft has confirmed that Microsoft 365 Copilot interactions are logged through the Purview unified audit log, making them searchable, preservable, and producible via eDiscovery tools.
  • Assess Scope of Exposure: Because these chats are treated no differently than emails, they may inadvertently expose privileged or damaging material if not managed properly.
  • Map Information Logs: Update your legal hold workflows to specifically include AI conversation logs and audit trails. Mapping where these logs live before litigation arises ensures a more controlled and cost-effective discovery process.

Navigate GDPR and Data Privacy
Processing customer or employee data through AI models requires strict adherence to the GDPR principles of data minimization, purpose limitation, and lawfulness. Feeding sensitive data into AI models without a clearly articulated lawful basis—such as consent or legitimate interest—can result in significant administrative fines.

  • Meet Compliance Requirements: European authorities require organizations to demonstrate compliance by documenting purposes, limiting data inputs, and ensuring appropriate safeguards are in place.
  • Identify Special Categories: The GDPR is particularly restrictive regarding health information or data revealing racial or ethnic origin, requiring specific exemptions for processing.
  • Conduct Privacy Impact Assessments: Perform mandatory Privacy Impact Assessments (PIAs) for any AI tool that touches personal data. Documenting the purpose and necessity of the processing is critical for maintaining regulatory standing during an audit.

Leverage In-Place AI Functionality
A critical strategy for reducing risk is shifting where the AI processing occurs. Rather than routing data through external, third-party cloud-hosted AI services, organizations should consider prioritizing workflows where AI is applied in-place within the corporate network or controlled enterprise environment.

  • Secure the Data Perimeter: By keeping data and AI processing behind the organization’s own security firewall, you materially reduce the risk of trade secret leakage and data exfiltration.
  • Minimize Third-Party Footprint: Applying AI in-place narrows the scope of discoverable third-party records, as the interactions remain within your internal infrastructure rather than residing on a vendor’s servers.
  • Establish Full Governance Control: This model provides counsel with direct control over privacy, retention, and audit obligations—essentially giving you the “kill switch” for data that you simply do not have with external cloud vendors.

Tactical Governance and Ethical Oversight
Counsel must navigate the professional and technical nuances of AI deployment to ensure long-term stability.

  • Ensure Professional Competence: The ethical duty of technological competence requires attorneys to understand the limitations of the tools they use. AI should be treated as a “junior associate”—capable of great speed but requiring diligent human verification of all output.
  • Apply Risk-Based Tiering: Not all AI use cases carry the same weight. We recommend a tiered approach:
    o Tier 1 (Administrative): Low-risk tasks involving non-sensitive data.
    o Tier 2 (Internal/Marketing): Standard communications requiring routine oversight.
    o Tier 3 (High-Value/Restricted): High-stakes processing involving PII, health data, or proprietary IP, requiring senior legal sign-off and strict data handling protocols.
  • Execute Proactive Vendor Vetting: Move from consumer-grade tools to enterprise solutions that offer SOC 2 Type 2 attestations. Ensure contracts explicitly prohibit the vendor from using your data to train their global models.

In light of these risks, corporate counsel should take a proactive, structured approach to AI governance. This includes implementing data classification and usage controls to prevent sensitive trade secrets from being exposed to AI systems without safeguards; establishing clear policies governing AI prompts, outputs, retention, and eDiscovery treatment; and conducting privacy impact assessments to ensure personal data processing complies with GDPR and similar regulations. In addition, counsel should carefully evaluate AI deployment models and consider workflows in which AI models are deployed in-place within the corporate network or controlled enterprise environment, rather than routed through third-party cloud-hosted AI services. Keeping data and AI processing inside the organization’s security perimeter can materially reduce trade secret leakage risk, narrow the scope of discoverable third-party records, and provide greater control over privacy, retention, and audit obligations—while still allowing the enterprise to realize the benefits of advanced AI capabilities.

For a deeper dive into these strategies and more case studies, you can watch the full session here.

1 Comment

Filed under Best Practices, compliance, Corporations, Cybersecurity, Data Governance, ECA, eDiscovery & Compliance, Enterprise AI, Enterprise eDiscovery, ESI, GDPR, Information Governance, Records Management

Tagged as , , , , , , , , , , , ,