If you are considering feeding years of employee email into an AI system, the first question is not, ‘Can the model ingest it?’ The useful question is, ‘What behavior should it learn, and where is the evidence that this behavior produced a good result?’

A work archive can expose recurring questions, operating vocabulary, exception paths, and how decisions developed. It can also preserve obsolete policies, abandoned ideas, private material, accidental workarounds, and confident advice that turned out to be wrong. You need to separate those categories before an AI system starts treating all of them as precedent.

Your archive records activity, not ground truth

Google won an August bankruptcy auction, subject to court approval, with a $10 million bid for Spirit Airlines’ internal emails, Microsoft Teams messages, spreadsheets, and other business records for AI training and product development. The bid gives those records an explicit market value. It does not make every record a reliable example of how work should be done.

Email captures what people typed. It rarely captures the entire chain from problem to decision to result. A long thread about fixing an invoice may reveal the participants, the proposed fixes, and the language used inside the company. It may not reveal which explanation was correct, what was agreed on a call, whether the customer accepted the resolution, or whether the process was later redesigned.

Product work makes the gap especially visible. Two versions of a requirements document may differ by only a few sentences even though the discussion between them corrected the team’s understanding of the customer. A project that was wisely cancelled may leave fewer artifacts than a weak project that ran for months. A meeting that prevents an unnecessary feature creates value partly through something that never gets built.

This creates predictable traps when an archive becomes machine-learning data:

• Frequency can look like correctness. A repeated workaround may simply be a recurring failure in the underlying process.
• The last message can look like the final decision. Approval may have happened in a meeting, another system, or a later document.
• Polish can look like quality. A well-written proposal is not necessarily the proposal that produced the best customer or business outcome.
• Volume can look like importance. Some valuable decisions shorten a discussion, remove work, or stop a project before it generates more records.
• Agreement can look like validation. A thread can end because the participants deferred the question, not because the answer was correct.

Test the archive before you discuss models. Select a completed piece of work and ask four questions: What decision was being made? Who had authority to make it? What happened afterward? Would the business deliberately repeat the same approach? If the records cannot answer those questions, they are evidence about activity, not labels for successful behavior.

Choose the job before you choose ‘training’

Teams often use ‘training’ to describe several technically different products. That ambiguity leads to expensive architecture decisions. Searching an archive at query time is not the same as fine-tuning a model. Extracting structured fields is not the same as teaching judgment. Evaluating a model against historical cases is not the same as putting those cases into its parameters.

Business goal	What the archive provides	What is still missing	Sensible starting mechanism
Find a past decision or policy	Searchable messages and documents	Current authority, effective date, and access rules	Permission-aware retrieval with citations
Summarize a customer or operational case	A sequence of communications	Case boundaries, verified facts, and final disposition	Extraction and summarization against the original records
Draft a response in the company’s preferred form	Examples of language and structure	Approved content, current policy, and a quality standard	Retrieval of approved examples plus constrained generation
Predict escalation or another outcome	Signals in conversations	A reliable outcome label, timestamp, and action tied to the prediction	A supervised model only after the labels are validated
Teach decision-making judgment	Partial traces of deliberation	The reasoning, trade-offs, outcome, and counterexamples	A curated case library and evaluations before any fine-tuning

Retrieval is usually the cleaner first test when users need current, traceable facts. The records remain outside the model, can be updated or removed, and can be cited in the answer. Retrieval does not eliminate privacy or authorization risk, but it makes provenance and correction more manageable than encoding a broad archive into model behavior.

Fine-tuning is more relevant when you have a stable behavioral target: a classification scheme, a repeatable transformation, a response format, or a decision pattern backed by validated examples. It is a poor substitute for a current knowledge base. If a policy changes, you should be able to replace the policy record without retraining a model and wondering which version still influences its answer.

Write a one-page use-case contract before authorizing data preparation. It should answer:

• Who will use the system, and what decision will its output change?
• What is the unit of work: a message, thread, customer case, incident, project, or decision?
• What counts as a correct answer, and who can verify it?
• Which error would be unacceptable even if average performance improved?
• How current must the answer be, and which record has authority when records conflict?
• What baseline must the AI approach beat: keyword search, an existing workflow, a template, or a human review?

If the business owner cannot name the ground truth and the action that follows the output, do not train on the archive yet. The unresolved issue is product definition, not model capability.

Turn messages into outcome-linked cases

A message is a storage unit, not a business unit. Training examples should usually be organized around the thing the company was trying to accomplish. Depending on the use case, that might be a resolved support case, a product decision, a sales exception, a financial investigation, or an operational incident.

Build each case in layers so the model does not have to guess which text mattered:

1. Define the trigger. Record the event or question that started the work.
2. Set the boundary. Link the relevant messages, documents, meetings, tickets, and system events. Do not assume one email thread contains the entire case.
3. Identify the decision. Capture what was decided, who approved it, and when it became operative.
4. Attach the outcome. Use the downstream result appropriate to the task, such as whether a case reopened, a decision was reversed, a product was shipped, or the intended customer problem was resolved.
5. Mark time validity. Record which policy, product version, organization structure, or commercial condition applied at the time.
6. Record uncertainty. Separate verified facts from later interpretation. Do not manufacture a clean explanation when the history is genuinely incomplete.

This structure prevents the final artifact from becoming a false proxy for success. An approved document proves that someone approved it. It does not, by itself, prove that the recommendation worked. A courteous response proves that the language was courteous. It does not prove that the answer was accurate or that the recipient’s problem was solved.

A practical quality ladder helps keep those distinctions visible:

• Tier A: outcome-linked cases. The decision, authority, relevant context, and downstream result have been verified. Use these for evaluation and, when appropriate, supervised improvement.
• Tier B: approved artifacts. The final answer or document is known, but its downstream effect is not. These may support retrieval or format guidance, but should not be labeled as successful judgment.
• Tier C: raw conversational records. The material may help discover workflows, vocabulary, and candidate cases. It needs curation before it becomes a behavioral example.
• Tier D: excluded material. The content is outside the approved purpose, carries unresolved rights or sensitivity concerns, or cannot be governed reliably. Keep it out of the pipeline.

Include counterexamples. If the dataset contains only popular decisions or polished final messages, the model cannot learn the difference between an accepted pattern and an effective one. A rejected proposal, corrected answer, reopened case, or superseded policy can be more instructive than another example of the normal path, provided it is clearly labeled.

For historical work, some missing context cannot be recovered. Ask knowledgeable owners to annotate cases, but preserve the distinction between a contemporary record and a retrospective explanation. The honest label ‘outcome unknown’ is safer than a confident story assembled after the fact.

Put rights, privacy, and access controls before data transfer

Work email may contain personal information, confidential negotiations, credentials, security details, legal communications, health or payroll matters, and messages involving customers or partners. It was created for communication and recordkeeping, not automatically for every later machine-learning purpose.

Do not treat possession of an archive as blanket permission to train on everything in it. Ownership, employee notice, confidentiality commitments, privilege, retention duties, sector-specific obligations, and cross-border processing can depend on jurisdiction and contract. Have the appropriate legal, privacy, security, and records owners review the actual use case before copying data into a model pipeline. If that review is incomplete, keep the data in its governed system and use an approved subset or synthetic cases for early technical work.

Your governance gate should require concrete answers, not a general statement that the data is ‘internal’:

• Inventory: Which mailboxes, channels, document stores, time periods, business units, and record types are included?
• Purpose: Which named use case is permitted? Reuse for another model or audience should require a new review.
• Exclusions: Which categories must be removed or separately reviewed, including personal mail, credentials, privileged communications, protected employee matters, and information covered by third-party commitments?
• Access: Will the AI system enforce the source permissions at query time, including changes when a person moves roles or leaves?
• Vendor handling: Will a provider retain the files or prompts, use them to improve its own models, move them across regions, or pass them to subprocessors?
• Retention and deletion: Can a record be removed from the index, derived dataset, cached output, and any trained artifact when policy or law requires it?
• Accountability: Who can correct a mislabeled case, investigate an exposure, suspend the system, and approve a restart?

Redaction is useful but not a complete control. A message can remain identifiable through role, project, timing, customer, or event details after names and addresses are removed. Test redacted cases from the perspective of a colleague who knows the organization. If that person could readily infer the subject, treat the record as identifiable for your risk review.

Preserve provenance with every permitted record: source system, original identifier, timestamp, access classification, policy status, and transformation history. Without provenance, you cannot explain an answer, repair an incorrect label, honor a deletion decision, or distinguish a current rule from a historical one.

Before transferring any archive to an external service, verify the provider’s retention, secondary-training, deletion, regional-processing, security, and exit terms in writing. An irreversible upload can create legal, security, and operational exposure. When those controls are unknown, the safe alternative is a bounded environment under your existing access controls.

Prove incremental value with a bounded pilot

A pilot should answer whether work-email data improves a defined task, not whether a model can produce a plausible response after seeing company language. Plausibility is easy to demonstrate and dangerous to confuse with utility.

1. Bound the workflow. Choose one decision, one user group, an approved data domain, and a named owner. Avoid a company-wide assistant as the first experiment.
2. Measure the existing baseline. Run representative cases through the current process, such as search followed by human review. Record quality, failure modes, and the work required to reach an answer.
3. Compare the smallest viable approaches. Test ordinary search, permission-aware retrieval, retrieval over curated cases, and only then a tuned model if the requirement concerns stable behavior rather than current facts.
4. Split data by complete case and time. Keep all messages from the same case on one side of the training and evaluation boundary. Otherwise, near-duplicate messages can make performance look stronger than it is. A time-based holdout also reveals whether the system mistakes old practice for current policy.
5. Evaluate the whole product behavior. Score answer correctness, provenance, permission fidelity, temporal validity, useful abstention, and the quality of the action a user takes next. Set acceptance and stop criteria before seeing the results.
6. Exercise failure paths. Test conflicting messages, superseded policies, incomplete threads, ambiguous authority, excluded records, and requests from users who lack access. Confirm that an owner can disable the feature and remove its data.

Use human reviewers who understand the task, not only the language. A fluent summary can still select the wrong policy, miss the decisive conversation, or recommend a practice that failed. Ask reviewers to identify the record that supports the answer and the outcome that makes the example worth following.

Stop or redesign the pilot if the system gives confident answers without traceable evidence, exposes content outside a user’s permissions, treats historical policy as current, or fails to beat retrieval and human review on the defined task. A more complex model is not progress when the simpler baseline is equally useful and easier to govern.

Key takeaways

• An email archive is evidence of work, not a labeled record of good work.
• Define the user, decision, ground truth, unacceptable error, and baseline before choosing a model technique.
• Use retrieval first when people need current, source-backed knowledge; reserve fine-tuning for stable behaviors supported by validated examples.
• Package data as outcome-linked cases rather than isolated messages, and label uncertainty instead of inventing context.
• Preserve source permissions and provenance, and require legal, privacy, security, and records review before data leaves its governed environment.
• Expand only when a bounded pilot demonstrates measurable value over the simplest controlled alternative.

Your next approval meeting should not ask whether the company can train on its archive. Bring one workflow, its authoritative records, the outcome that defines success, the people allowed to see it, and a way to reverse the deployment. Once those are concrete, the right role for the archive – retrieval corpus, evaluation set, curated training data, or no role at all – becomes much easier to decide.

References

• Nate Jones’s Substack – Google bid $10 million for an airline’s old work emails to train AI. Much of what made that work matter never showed up in an email.

---