How to Sell Internal Business Data for AI Training Without Creating a Compliance and Security Disaster

Quick Answer: how to sell internal business data for AI training safely

Selling internal business data for AI training is feasible, but only if you can prove what the dataset contains, what it explicitly excludes, and how it was derived from systems like email and Microsoft Teams. The Google–Spirit Airlines signal is that buyers will pay for operational context (messages, documents, workflow traces), yet the deal also highlights the core requirement: the dataset must be engineered as a governed product, not dumped from storage.

The real shift: collaboration exhaust is being priced like intellectual property

Google’s $10 million bid for Spirit Airlines’ internal business data (won at a bankruptcy auction) matters because it reframes corporate records as a monetizable AI input even when the originating business is defunct. The package reportedly includes internal corporate information and custom software, but excludes customer and credit card information, which is a strong clue about what buyers actually want: operational decision context without obvious regulated payloads.

For engineering leadership, this changes a practice we used to treat as back-office hygiene: retention and archiving strategy. Once internal email and Teams messages can be valued and transferred, the question is no longer only ‘how long do we keep it,’ but ‘can we produce a bounded, reviewable, non-customer dataset that still represents how the company works.’ That requires a data architecture that can separate collaboration history, operational artifacts, and sensitive identities at export time, not in hindsight.

• Operational realism is scarce: Public internet text explains what businesses are; internal threads and artifacts show how decisions are made across pricing, audits, fraud, revenue, and operations, which is the kind of workflow signal buyers are hunting for.
• Enterprise data is cross-system by default: Email, Teams, spreadsheets, and calendars form one workflow graph in practice, but they live in different storage and permission models, making a ‘single dataset’ a non-trivial engineering product.
• Exclusions must be provable: ‘No customer and credit card information’ is not a promise; it is an auditable claim that requires deterministic filtering rules, sampling-based verification, and traceable lineage back to source systems.
• Custom software becomes part of the dataset: When operational data is paired with internal tools, the buyer can infer processes and controls; teams need to treat internal apps and their logs as part of the data governance surface.
• Bidding pressure will surface your weak spots: A rival bidder (Mercor) pushed the price from $5 million and $7.5 million to $10 million; that kind of market heat increases the temptation to cut corners on review, which is where deals become security incidents.

Our central claim: ‘AI datasets’ fail at governance boundaries, so architecture matters more than the buyer

This week’s signal is not that one airline’s archives are valuable. It is that corporate operational data can now be transacted as an AI asset, and that breaks a common engineering assumption: that internal collaboration content is only an internal risk to be minimized, not a product to be packaged. The right response is to design ‘exportable governance’ into your systems now—classification, lineage, and exclusion proofs—so you can monetize or share data without negotiating your security posture under pressure.

What Google is really buying: organizational behavior encoded in systems, not just documents

In the reported Spirit Airlines package, the headline items are roughly 100 million emails and 500 million Microsoft Teams messages and collaboration records. That scale matters less for ‘more text’ and more for ‘more structure’: who communicates with whom, how decisions move through roles, and how operations interact with planning and marketing. That’s why corporate archives can be useful for AI product development and training without being consumer data.

But for a CTO, the important implication is that collaboration systems are now de facto process engines. Teams messages are not only chat; they are approvals, incident handling, scheduling, vendor negotiation, and policy interpretation. Email threads are not only communication; they are change logs. Spreadsheets and calendars are not only files; they are operational state. If you want to create value from this ‘workflow exhaust,’ you must treat M365-era artifacts as a unified governance domain even when they sit in different stores and permission layers.

• Email as decision lineage: A thread captures rationale, escalation paths, and sign-offs; the AI value is often in the deltas and replies, while the risk is in names, addresses, and embedded attachments.
• Teams as workflow telemetry: Channels and chats encode coordination across departments; the AI value is in coordination patterns, while the risk is that ‘casual’ conversation frequently includes sensitive incident details.
• Spreadsheets as operational truth: They often hold pricing, audits, and performance notes; the AI value is in the structured artifacts, while the risk is that the same file mixes safe operational facts with sensitive identifiers.
• Calendars as process skeleton: Meetings reflect operational cadence and accountability; the AI value is in process timing, while the risk is that meeting titles and attendees can reveal confidential projects.

Why ‘excluding customer data’ is not enough to make a dataset safe

Even when customer and credit card information are excluded, internal corporate records can still contain regulated or highly sensitive content through indirect references. In practice, people paste screenshots, forward external emails, attach exports, or mention identifiers in plain language. From an engineering standpoint, the export boundary must be defined by enforceable detection and removal policies across message bodies, attachments, and metadata, not by a one-time legal statement.

The auction dynamic changes how ‘data readiness’ gets measured

This sale required US Bankruptcy Court approval in the Southern District of New York, with a hearing scheduled for August 19. That detail matters because it highlights the environment where these datasets will increasingly move: time-boxed transactions, legal scrutiny, and adversarial questioning. In those conditions, ‘we think it’s clean’ fails; ‘we can demonstrate what’s inside and how it was filtered’ holds up. Engineering needs to anticipate the audit posture, not just the export mechanics.

• Provenance is the new spec: Buyers and reviewers will ask where the data came from and what transformations occurred; if your pipeline cannot answer that, the dataset is not transaction-ready.
• Metadata can be more sensitive than text: Attendee lists, distribution groups, and channel membership can expose organizational structure; minimizing and sanitizing metadata is a first-class requirement.
• Attachments are the hidden blast radius: Email bodies might be scrubbed while attachments leak identifiers; any export architecture must handle attachments as separate objects with separate policies.
• Custom software is not ‘just files’: Internal tools often embed credentials, endpoints, and operational assumptions; packaging them without a security review turns a data sale into an intrusion blueprint.

If you want ‘AI-grade enterprise data,’ start with a dataset contract, not storage exports

The CTO decision is whether to treat internal archives as something you occasionally dump, or as something you can productize under governance. At Plavno, we push for a dataset contract: a written, versioned definition of scope, exclusions, and permitted use, aligned to concrete system boundaries. That contract is what makes a dataset exportable from Microsoft Teams and email without re-litigating risk every time.

The Spirit-style package reportedly spans marketing, productivity, airline operations, revenue, aircraft operations, audits, fraud, and pricing. That breadth is precisely why an unstructured export fails. Different departments have different retention practices, different sensitivity, and different ‘normal’ communications. Your dataset contract has to reflect that reality by mapping domains to systems and by specifying what kinds of threads and artifacts are out of scope even if they technically sit inside the same tenant.

The engineering work you cannot skip: classification, lineage, and reversible transformations

To make internal business data valuable and safe, we need to think like builders of a regulated data product. Classification is not a label; it is an operational capability across email, Teams, spreadsheets, calendars, and internal tools. Lineage is not documentation; it is the ability to trace every exported record back to its source mailbox, channel, or file store and to explain the filtering applied.

Reversible transformations are the most overlooked part. Buyers want realism, but your org needs the option to prove what was changed and why, especially when exclusions like customer and credit card information are contractual. That implies a pipeline that can reproduce the export deterministically from the same source snapshot, using versioned rules. In practice, teams often jump straight to ‘anonymization’ without capturing the rule versions and exception decisions that made the dataset defensible.

• Classification must be multi-layered: Content, attachments, and metadata behave differently; a ‘safe’ Teams message can point to a file that is not safe, and your policy needs to treat those as separate objects.
• Lineage must survive aggregation: When you merge multiple systems into one dataset, you cannot lose original IDs, timestamps, or permission context, even if you later minimize or hash them.
• Filtering must be versioned: If you claim exclusions, you need to show which rule set produced the dataset and how updates would change inclusion, especially in a legal or bankruptcy context.
• Sampling and review are part of the pipeline: Automated detection will miss edge cases; a defensible process includes structured human review of sampled records tied back to rule outcomes.

Plavno’s perspective: treat ‘AI data readiness’ as a platform capability

We see many organizations funding AI initiatives while leaving the underlying data export and governance as an ad hoc effort owned by a single team. The Spirit–Google signal shows why that breaks: internal business records can be acquired and repurposed for AI, which means your governance posture needs to be durable, repeatable, and legible to outsiders.

Our approach is to build data readiness as part of your AI delivery lifecycle. When we design agentic systems or enterprise assistants, the first production risk is typically not the model—it’s uncontrolled data exposure through retrieval, logging, and feedback loops. That is why our AI consulting work usually starts with data boundaries, retention posture, and the operational controls that will still make sense if the dataset later needs to be transferred, audited, or monetized.

Business impact: your archives now have two prices—market value and breach cost

A $10 million payment for internal business data is not a valuation template, but it is enough to change executive conversations. It puts a visible dollar sign on collaboration data that previously lived in cost centers. That can be good news if you can package a dataset responsibly, or bad news if your archive is a messy mixture of operational context and sensitive material you cannot confidently separate.

The business impact shows up in deal velocity and leverage. If internal corporate records and custom software can be bid on (as they were against Mercor’s competing offer), then data becomes an asset that can be sold, licensed, or used as a bargaining chip in partnerships. At the same time, it becomes easier for boards and auditors to ask why you cannot quantify what is in your own archives. That question forces engineering to operationalize controls that were once ‘best effort.’

1. Inventory what exists across systems: Establish a concrete map of where email, Teams collaboration records, spreadsheets, and calendars live, and which tenants, groups, and mailboxes are in scope for any future dataset.

2. Define exclusion rules in plain language first: Write what must not be included (for example, customer and credit card information) and then implement technical controls that can be tested, versioned, and re-run.

3. Build an export pipeline that preserves lineage: Ensure every exported record can be traced to its origin and filtering decision, so you can answer audit questions without hand-waving.

4. Separate ‘text’ from ‘attachments’ as distinct risk objects: Treat attachments and linked files as their own classification problem rather than assuming message-level scrubbing is enough.

5. Design for external scrutiny: Assume a court, buyer, or regulator will ask how the dataset was created; your process should produce evidence, not just outputs.

How to evaluate your readiness in practice: test the boundary, not the model

When leadership asks whether you should prepare internal data for AI training or product development, the temptation is to evaluate model quality. We recommend evaluating boundary quality first. In a Spirit-like dataset, the buyer value comes from realistic enterprise workflows, but your risk comes from the same realism: identities, internal incidents, sensitive negotiations, and accidental data inclusion.

A practical readiness evaluation looks like a controlled dry run. We select a narrow domain, export from the real systems (email and Teams), and attempt to prove the exclusion claims end to end. The pass/fail condition is not ‘does the dataset look useful,’ but ‘can we demonstrate what was filtered, why it was filtered, and whether the process is repeatable.’ Teams that can do that once can usually scale; teams that cannot will keep redoing the work every time legal or security changes a requirement.

Real-world applications: from enterprise assistants to workflow-aware agents

Even without guessing which Google products will use Spirit’s data, the use case shape is clear: AI systems that understand complex enterprise workflows need examples of how real organizations communicate and operate. Collaboration records across departments like marketing, finance, operations, and management provide the connective tissue that typical public text does not.

In our client work, the nearest practical analog is building assistants and agents that must operate within corporate process constraints. An enterprise assistant might need to summarize internal threads, route tasks, or answer operational questions grounded in internal artifacts. That is exactly where ‘workflow realism’ matters and where data governance matters even more. If your assistant is trained or tuned on internal records, or if it retrieves from them, then your dataset architecture and your runtime access controls are inseparable. This is also why organizations investing in agentic capabilities often benefit from purpose-built delivery, such as our AI agents development, where governance is designed alongside orchestration.

• Workflow understanding beats generic knowledge: Internal records show how pricing, audits, fraud, and operations interact; this is what makes systems useful inside enterprises, but it also increases the need for strict scoping.
• Cross-department context is the differentiator: The value is in how departments coordinate, not in any single document; your dataset must preserve relationships while removing sensitive identity information.
• Custom software adds process clarity: Internal tools can encode the ‘how’ behind operational decisions; exporting them without a security pass risks leaking secrets, but excluding them may reduce dataset utility.
• Collaboration data changes quickly: Teams channels and email patterns evolve; a dataset must be treated as a snapshot with a defined time window, not a living mirror of your enterprise.

Why teams underestimate the ‘custom software’ part of these packages

The Spirit package reportedly includes custom software alongside business data. That detail should make engineering leaders uneasy in a productive way: internal apps are where business logic, integrations, and operational assumptions live. When those assets move, you have to treat them like any external-facing software release—license clarity, removal of embedded secrets, and hardening of documentation—because the buyer can learn far more than what is written in emails.

Risks that will kill the deal (or the product) if you ignore them

The biggest risk is believing that excluding obvious customer data makes you safe. Internal records can still contain sensitive operational, HR, security, or legal content, and they can reveal organizational structure through metadata alone. When a dataset includes hundreds of millions of collaboration records, the long tail of edge cases is where incidents come from, not from the easy-to-detect patterns.

At Plavno, we advise treating the entire effort as a security and compliance engineering project with AI upside, not an AI project with a security footnote. The right owners are not only data scientists; they include security engineering and governance. If you want external confidence—whether for monetization, partnership, or internal AI training—invest in validation workflows and adversarial review. When needed, we pair AI delivery with cybersecurity and penetration testing to pressure-test the boundary assumptions before a dataset ever leaves your control.

Author: Plavno team. Last updated: August 2026. If you are considering monetizing internal business records or using them to train workflow-aware systems, we can help you design the dataset contract, export pipeline, and audit evidence so the project survives real scrutiny.

Summarize this blog post with AI

Chat GPT Perplexity Claude Gemini