A Claude Skill that turns an organization’s AI-tool footprint into a preservation-scope inventory: for each tool, where prompts and outputs persist, what deletes them and on what clock, whether an existing legal hold already reaches that data, and which custodian-questionnaire and hold-notice language has to change because of the answer. The bundle ships at apps/web/public/artifacts/ai-data-source-inventory-skill/ and contains SKILL.md plus three reference files, one of which you fill in before the first run.
The Skill is read-only. It places no holds and releases none, because both are legal decisions belonging to a named person.
The gap it closes
Data maps built before 2023 list mail, chat, file shares, and line-of-business systems. The AI layer got added to those same systems without getting added to the map, and the standard responses to that are both wrong in ways that look responsible.
The first is treating AI tools as a security problem that has been handled. A shadow-AI discovery exercise produces a list of apps and a set of blocks, and the list gets filed. That list answers who is using what. It says nothing about what record the usage leaves, which is the only question preservation cares about.
The second is assuming that retention and preservation are the same fact. They are independent, and the interesting rows are where they diverge. Microsoft 365 Copilot chat is preserved by controls most organizations already run — prompts and responses are copied into a hidden folder in the user’s own Exchange Online mailbox, and Microsoft documents that permanent deletion is suspended when that mailbox is under Litigation Hold, a delay hold, an eDiscovery hold, or another retention policy for the same location. So a custodian on a mailbox hold already has their Copilot chat preserved, whether anyone decided that or not. Copilot memory, in the same product, goes the other way: Microsoft states that Purview retention policies and retention labels do not apply to Copilot memory and that no admin control enforces retention on it, while saved and inferred memories stay discoverable through eDiscovery and Graph Explorer. Discoverable and unprotected is the worst pair of properties a data source can have.
When to use
When a hold is going out and the custodian source list predates the AI layer. When opposing counsel serves an ESI request or a Rule 26(f) proposal naming chatbot logs or prompt history. When a defensible-deletion program is about to start deleting and nobody has established what the AI layer copies or leaves behind. When security finishes a shadow-AI sweep and the output needs a records reading rather than a security one.
When NOT to use
A hold is already late. Issue the notice on the broadest defensible scope first, inventory second. An inventory is not a reason to delay a notice.
Fewer than roughly eight AI tools, one identity provider, everything SSO-gated. Read the four admin consoles directly. The schema is overhead at that size.
You need the data collected, not scoped.references/2-retention-behavior-profiles.md records whether an export path exists and who can run it; it does not run one.
You cannot reach any administrative console. Every phase after discovery depends on tenant configuration you must be able to read. Without it the run produces a list of vendor marketing claims that looks like an inventory.
Nobody will fill in Part D. The known-tools registry in references/1-ai-tool-discovery-sources.md is what makes an undiscovered tool report as unregistered. Without it every finding reads the same.
What the skill actually does
Six phases, fixed order, with hard refusals in two of them.
Phase 1 collects from four discovery planes — identity provider grants, spend, endpoint and browser telemetry, and the known-tools registry. They are deliberately redundant because each is blind in a different direction: the identity provider cannot see a tool someone pays for with a personal card, spend cannot see free tiers, telemetry cannot see tenant configuration, and the registry only sees what people wrote down. A tool found by one plane is a different confidence class from one found by three, and the single-plane finds carry the problems, because a tool nobody procured is a tool nobody configured.
Phase 2 refuses on fewer than three planes, or on any plane returning zero records. A zero-record plane renders as COLLECTION FAILED, never as a clean result. The characteristic failure of this work is a tidy inventory of the twelve tools that were easy to find.
Phase 3 builds a retention profile per tool from vendor documentation and tenant configuration only. Every field carries a source_url and a checked_on date; a field missing either renders as unknown rather than falling back to a default, because a plausible default is how an inventory goes wrong quietly. Profiles split by feature, not just by tool — Copilot chat and Copilot memory are two rows with opposite answers.
Phase 4 classifies reachability into four states and this is the design choice that separates the output from a data map. held means an existing control already attaches. retained-not-held means the data exists and is discoverable but no hold mechanism reaches it, so preservation is an affirmative collection task with a date rather than something you place and forget. not-retained means the interaction leaves no durable record — Google states that Vault’s Gemini app support does not apply to Gemini in Google Workspace features embedded in other apps, such as “Help me write” in Gmail and Docs, because those interactions are not retained the same way. vendor-held-only means the record sits solely in vendor systems your holds cannot touch, which is a possession-custody-or-control question for counsel rather than a configuration task for IT.
Then it runs the test backwards, listing which AI sources each existing hold silently sweeps in. Over-preservation is a reportable finding: it inflates review volume and it contradicts any written schedule claiming AI interactions are not preserved.
Phases 5 and 6 derive the questionnaire and notice deltas from references/3-custodian-questionnaire-deltas.md and report, leading with the retained-not-held and vendor-held-only rows because those need a decision this week.
Cost and throughput
Compute is not the budget. The Skill reads exports and vendor documentation; profile write-ups run roughly 600-900 output tokens each, so a 40-tool estate costs well under a dollar in model spend.
The human cost is the whole number, and it is an estimate rather than a measured figure: plan 2-4 hours to pull the four planes if the exports exist, then 15-30 minutes per tool for documentation and tenant verification. A 40-tool footprint is a 10-20 hour first pass, most of it in Phase 3. Part D of the discovery reference persists, so the second run is a diff and costs a fraction of the first. Re-run per matter, and quarterly as standing readiness.
Failure modes
Confusing “retained” with “reachable by a hold.” The team reports coverage that no hold actually produces. Guard:reachable_by_existing_hold cannot be inferred — the schema requires naming the specific control that does the reaching, and vendor-side retention for the vendor’s own purposes does not qualify.
Verifying preservation by looking at the app.Guard: Microsoft states that messages visible in AI apps are not an accurate reflection of whether they are retained or permanently deleted. Phase 4 verification is an eDiscovery search returning a hit count against a known custodian, never a screenshot.
Reading the configured retention period as the deletion date. Microsoft’s own worked example shows a delete-after-one-day policy taking up to 16 days before items stop being returned by eDiscovery, because the timer job runs on a 1-7 day cycle and the SubstrateHolds folder adds at least one more day. Guard: the schema separates policy_period from observed_deletion_lag, and defensible-deletion certifications cite the second.
Assuming a licence means capture. Purview’s retention locations reach ChatGPT, Google Gemini, consumer Copilot, and DeepSeek only when a collection policy with content capture is configured, which requires the Content contains classifiers condition set to All — and Microsoft states it does not include content in files shared with generative AI. Guard: collection-policy state is a per-tool tenant-configuration field, not an org-level assumption.
Treating vendor terms as stable. The preservation order in the New York Times matter required OpenAI to retain output log data that would otherwise have been deleted; that obligation ended on 2025-09-26 and the order was terminated by stipulation on 2025-10-09. Google Vault only gained retention rules and litigation holds for the Gemini app on 2026-06-11. An inventory written either side of those dates is wrong on the other side. Guard: every profile carries checked_on, and anything past the recheck interval renders as unverified and is counted in the report header.
The inventory becomes an HR document the moment it names individuals doing something unapproved, and cooperation collapses. Guard: Phase 1 aggregates to tool and count; custodian-level detail is written to run_dir/custodians/ and referenced by path, never inlined into the report.
vs alternatives
vs an eDiscovery vendor’s AI-source connector. Onna, Exterro, and Reveal sell collection from cloud sources, and when you have a matter and need the data out, a connector beats hand-rolling every time. It solves the adjacent problem. You still need the inventory to know which connectors to buy, and connectors do not exist for the sources with no export path at all — which is where the retained-not-held rows sit.
vs Purview DSPM for AI alone. For a Microsoft-centric estate it is the strongest single discovery plane available, and the bundle uses it as one. Two limits keep it from being the answer: it reports AI app usage rather than what survives that usage, and its reach into non-Microsoft tools depends on the browser plane plus a collection policy that most tenants have not configured.
vs asking IT for the app list. Fastest option, and the answer is the SSO list — which structurally excludes non-SSO and personal-account usage. That excluded population is precisely the one with the worst preservation posture, so the fastest method has its blind spot exactly where the findings are.
vs a spreadsheet. The honest comparison, since it is what most teams do. Fine at ten tools. The parts worth not rewriting are the profile schema with its mandatory source_url, the four-state classification, and the reverse hold test, because those three are what people get wrong when they build the spreadsheet themselves.
---
name: ai-data-source-inventory
description: Turns an organization's AI-tool footprint into a preservation-scope inventory. For each AI tool in use, records where prompts and outputs persist, what deletes them and on what clock, whether an existing legal hold already reaches that data, and which custodian-questionnaire and hold-notice language has to change as a result. Read-only; produces findings, never places or releases a hold.
---
# AI data source inventory
## When to invoke
Invoke when someone has to answer, for a specific matter or as standing readiness work, the question **"where does our AI usage create records, and does our current preservation reach them?"** Concretely:
- A litigation hold is going out and the custodian list was built from mail, chat, and file shares — the pre-2023 source list.
- Opposing counsel serves an ESI request or a Rule 26(f) proposal that names AI tools, chatbot logs, or prompt history.
- The organization is drafting or revising its data map, records retention schedule, or an ESI protocol.
- A defensible-deletion program is about to start deleting, and nobody has checked what the AI layer copies or leaves behind.
- Security or IT has finished a shadow-AI discovery exercise and the output needs a records-and-preservation reading rather than a security reading.
## When NOT to invoke
- **You need the data collected, not scoped.** This produces an inventory and a gap list. Extraction is a different job with different tooling; see `references/2-retention-behavior-profiles.md` §Export path, which records whether one exists but does not run it.
- **A hold is already late.** If preservation should have attached and has not, issue the hold on the broadest defensible scope first and inventory afterward. An inventory is not a reason to delay a notice.
- **Fewer than about eight AI tools, one identity provider, all SSO-gated.** Read the four vendor admin consoles directly. The schema is overhead at that size.
- **You cannot reach any administrative console.** Every phase after discovery depends on tenant-side configuration you must be able to read. Without it the run produces a list of vendor marketing claims, which is worse than no inventory because it looks like one.
- **The real question is whether employees should be using these tools.** That is an acceptable-use and security question. This Skill assumes the usage exists and asks only what record it leaves.
## Inputs
**Required:**
- `org_identity_provider` (string) — `entra`, `okta`, `google`, or `other`. Determines which OAuth-grant export Phase 1 asks for.
- `discovery_exports` (paths) — at least three, one per discovery plane, per `references/1-ai-tool-discovery-sources.md`. Phase 2 refuses to run on fewer.
- `existing_hold_inventory` (path) — the current set of legal holds with their custodians and scoped locations. Without this the hold-reachability test in Phase 4 has nothing to test against.
**Optional:**
- `matter_scope` (string) — custodian list and date range, if the run is matter-driven rather than standing readiness. Narrows Phase 4 to the named custodians.
- `jurisdictions` (list) — drives which retention obligations Phase 5 flags. Defaults to US federal civil.
- `recheck_interval_days` (integer) — how long a vendor retention profile stays valid. Default 90.
## Reference files
- `references/1-ai-tool-discovery-sources.md` — the discovery planes, what each one sees and structurally cannot see, and the fillable known-tools registry (Part C) you complete before the first run.
- `references/2-retention-behavior-profiles.md` — the per-tool profile schema, the four-state reachability classification, and four worked profiles with sources.
- `references/3-custodian-questionnaire-deltas.md` — the questions to add to a custodian interview and the hold-notice clauses that change, with fillable text.
## Method
Six phases, fixed order. Phases 2 and 4 have hard refusal conditions; they are the two places where a plausible-looking run is worse than no run.
### Phase 0 — Pin the run
Write `run_dir/run-meta.json`: who ran it, against which tenant, with which read permissions, and the `recheck_interval_days` in force. An inventory whose own scope is unrecorded cannot be diffed against the next one, and the diff is the entire long-term value.
### Phase 1 — Discover the footprint
Collect from every plane in `references/1-ai-tool-discovery-sources.md`. The planes are deliberately redundant because each is blind in a different direction: the IdP sees OAuth-connected apps and not the tool someone pays for with a personal card; expense data sees paid tools and not free tiers; browser and endpoint telemetry sees usage and not the tenant configuration behind it; the known-tools registry sees what people admit to.
Record each tool once with the union of planes that found it, and keep the per-plane provenance. **A tool found by exactly one plane is a different confidence class than one found by three**, and it is usually the single-plane finds that carry the preservation problem, because a tool nobody procured is a tool nobody configured.
### Phase 2 — Refuse, or proceed
Hard stop if fewer than three planes returned data, or if any plane returned zero records. A plane with zero records is a collection failure and renders in the report as `COLLECTION FAILED`, never as a clean result. This phase exists because the characteristic failure of this work is a tidy inventory of the twelve tools that were easy to find.
### Phase 3 — Build a retention profile per tool
For each tool, fill the profile schema in `references/2-retention-behavior-profiles.md` from **vendor documentation and tenant configuration only**. Model knowledge of a vendor's retention policy is not admissible input here, and the schema enforces it: every field carries a `source_url` and a `checked_on` date, and a field without both renders as `unknown`, not as a default.
The profile answers five questions in this order, because each one is only meaningful if the one before it is answered:
1. **Does the interaction persist at all?** Some AI features retain nothing. Google states that the June 2026 Vault support for Gemini app retention rules and litigation holds does not apply to Gemini in Google Workspace features embedded in other apps, such as "Help me write" in Gmail and Docs, because those interactions are not retained the same way. A feature that retains nothing is a finding, not a gap.
2. **Where does it persist — tenant-side or vendor-side?** This is the field that decides everything downstream. Microsoft 365 Copilot prompts and responses are copied into a hidden folder in the user's own Exchange Online mailbox, which puts them inside a location your existing controls already address. A consumer chatbot account holds its data only on the vendor's systems.
3. **What deletes it, and on what clock?**
4. **Does an existing hold reach it?** Phase 4.
5. **Is there an export path, and who can run it?**
### Phase 4 — Test hold reachability, both directions
Classify every tool into exactly one of four states. The four-state split is the engineering choice that makes this Skill different from a data map, because "we retain it" and "a hold reaches it" are independent facts and the failure modes run in opposite directions:
- **`held`** — an existing hold already attaches. Microsoft documents that permanent deletion of AI-app messages from the SubstrateHolds folder is suspended if the mailbox is under Litigation Hold, a delay hold, another retention policy for the same location, or an eDiscovery hold. A custodian whose mailbox is on hold therefore already has Copilot chat preserved, whether or not anyone intended that.
- **`retained-not-held`** — the data exists and is discoverable, but no hold mechanism attaches to it. Microsoft 365 Copilot memory is the reference case: Microsoft states that Purview retention policies and retention labels do not apply to Copilot memory and that there are no admin controls to enforce retention rules for it, while saved and inferred memories remain discoverable through eDiscovery and Graph Explorer. Preservation here is an affirmative collection task with a deadline, not a hold you place and forget.
- **`not-retained`** — the interaction leaves no record. Document it and move on.
- **`vendor-held-only`** — the record exists solely in vendor systems your holds cannot touch, typically personal or free-tier accounts. This is the row that turns into a possession-custody-or-control question rather than a configuration task, and it belongs in front of counsel, not in front of IT.
Then run the test in reverse. For each **existing** hold, list which AI data sources it silently sweeps in. Over-preservation is a reportable finding: it inflates review volume, it contradicts a written policy that says AI interactions are not preserved, and it is discovered at the worst possible moment when it is discovered by the other side.
### Phase 5 — Derive the questionnaire and notice deltas
Diff the inventory against the current custodian questionnaire and hold-notice text. Emit only the deltas, with the specific tool that motivated each one, using the fillable language in `references/3-custodian-questionnaire-deltas.md`. A generic "do you use AI tools?" question returns a yes and nothing actionable; the questions that work name the tool and ask about the account, because the account type — corporate SSO or personal — is what determines which of the four states the custodian's data lands in.
### Phase 6 — Report
Sort by state, then by custodian count. Each row carries its evidence path so a reviewer reads the vendor documentation rather than arguing with a summary. The `vendor-held-only` and `retained-not-held` rows lead, because those are the two that require a decision this week.
## Output format
`run_dir/report.md`, literally:
```
# AI data source inventory — Contoso Legal Ops
Run: 2026-08-15 | Tenant: contoso.onmicrosoft.com | Planes: 4 of 4 | Tools: 31
Existing holds tested: 7 | Profiles unverified past 90 days: 2
## retained-not-held (2)
### Microsoft 365 Copilot — memory
custodians: 340 (all licensed users) | plane: idp, expense, registry
persists: yes — user Exchange mailbox, hidden folder, item class IPM.Contact,
folder CopilotMemory
deleted by: end user only, in Settings > Personalization. Deleting the source
chat does not delete a saved memory generated from it.
hold reaches it: NO. Purview retention policies and labels do not apply to
Copilot memory; no admin control enforces retention on it.
discoverable: yes — eDiscovery and Graph Explorer. Custom instructions are NOT
discoverable and must be exported by the user.
audit trail: none — memory and personalization actions write no Purview audit
log entries.
action: affirmative collection for the 12 matter custodians, by 2026-08-22.
source: learn.microsoft.com/microsoft-365/copilot/copilot-personalization-memory
checked_on: 2026-08-15
## vendor-held-only (5)
...
## held (19)
...
## not-retained (5)
...
## Over-preservation findings (3)
HOLD-2024-11 sweeps Copilot chat for 43 custodians. Retention schedule
section 4.2 states AI interactions are not preserved. One of the two is wrong.
## Questionnaire deltas (6)
## Notice deltas (2)
## Unverified profiles (2)
```
## Watch-outs
- **The app UI is not evidence of preservation.** Microsoft states plainly that messages visible in AI apps are not an accurate reflection of whether they are retained or permanently deleted, and that deletion timing runs on a timer job. **Guard:** Phase 4 verification is an eDiscovery search returning a hit count against a known custodian, never a screenshot of the chat pane.
- **Deletion lags far behind the configured period.** Microsoft's own worked example shows a delete-after-one-day policy taking up to 16 days before the message stops being returned by eDiscovery, because the timer job runs on a 1-7 day cycle and the SubstrateHolds folder adds a minimum of one more day. **Guard:** the profile schema separates `policy_period` from `observed_deletion_lag`, and defensible-deletion certifications cite the second.
- **Purview does not capture third-party AI content by default.** Retention for non-Microsoft AI apps depends on a collection policy with content capture enabled, which requires the **Content contains classifiers** condition set to **All**, and Microsoft states the capability does not include content in files shared with generative AI. **Guard:** Phase 3 records the collection-policy state as a tenant-configuration field per tool. "We have Purview" is not an answer to whether anything is being captured.
- **Vendor retention terms move, and they move both ways.** The preservation order in the New York Times matter required OpenAI to preserve output log data that would otherwise have been deleted; that obligation ended on 2025-09-26 and the order was terminated by stipulation on 2025-10-09. Google Vault gained retention rules and litigation holds for the Gemini app on 2026-06-11 — before that date there was no native hold. Anthropic retains consumer chats for up to five years in de-identified form in training pipelines when a user has enabled model improvement, and deletes from back-end storage within 30 days when they have not. **Guard:** every profile carries `checked_on`; anything past `recheck_interval_days` renders as `unverified` and is counted in the report header, so staleness is loud rather than invisible.
- **Free and personal-tier usage is the hardest class and the one a procurement-driven inventory misses entirely.** **Guard:** Phase 2's three-plane minimum exists for this; the browser and endpoint plane is the only one that sees an employee using a personal account on a corporate device.
- **An inventory that names individuals doing something unapproved becomes an HR document.** **Guard:** Phase 1 aggregates to tool and count by default and writes custodian-level detail only into `run_dir/custodians/`, which the report references by path and never inlines.
# Reference 1 — Discovery planes and the known-tools registry
Four planes. Each is blind in a specific direction, which is why Phase 2 refuses to score on fewer than three. Read the blindness column before deciding a plane is redundant.
| Plane | What it sees | What it structurally cannot see |
|---|---|---|
| A — Identity provider | Every app a user granted OAuth access to, with scopes and grant dates | A tool used without SSO or OAuth: a personal account, a browser extension with no OAuth flow, a desktop app holding an API key |
| B — Spend | Anything with an invoice, a card charge, or a procurement record | Free tiers, trials, tools inside a bundle already paid for, anything expensed as something else |
| C — Endpoint and browser | Actual usage, including personal-account usage on corporate devices | Tenant-side configuration; usage on personal devices; anything on an unmanaged endpoint |
| D — Known-tools registry | What the organization has written down, with an owner | Everything nobody wrote down — which is the population you are looking for |
## Part A — Identity provider export
**Entra ID.** Enterprise applications, filtered to those with delegated or application permissions granted in the review window. Export application display name, publisher, permission set, consent type (admin or user), and the user-assignment count. User-consented grants matter more than admin-consented ones here: an admin-consented app went through some process, a user-consented app did not.
**Okta.** The OAuth grants report plus the app assignment report. Okta separates these, and the join is on app ID.
**Google Workspace.** Admin console, Security → API controls → App access control, plus the connected-apps report. Note that Workspace marks apps as trusted, limited, or blocked; export the state, not just the name.
Record for every grant: `tool_name`, `publisher`, `consent_type`, `user_count`, `first_grant_date`, `scopes`.
**Do not filter this export to apps whose name looks AI-related.** Most tools that added AI features did so under their existing name and existing grant, and they are exactly the ones with an unexamined retention change.
## Part B — Spend export
Pull from the SaaS management platform if one exists, otherwise from AP and the corporate-card feed. Twelve months minimum, because annual-billed tools appear once.
Match on merchant descriptor rather than product name; descriptors are frequently the legal entity and will not match the product your users know. Record `merchant_descriptor`, `mapped_tool`, `annual_amount`, `owning_cost_center`, `billing_cadence`.
A tool that appears in Part B but not Part A is either non-SSO or API-key-based, and both mean the identity provider will not show you who is using it.
## Part C — Endpoint and browser export
The three sources worth pulling, in descending order of what they tell you:
1. **Browser extension inventory** from managed-browser policy or the endpoint agent. AI extensions are the sharpest signal available for personal-account usage, because an extension installed against a personal account is invisible to Parts A and B and visible here.
2. **Egress or CASB records** for known AI vendor domains, aggregated to domain and user count. Do not pull request bodies; you are counting usage, not reading it.
3. **Microsoft Purview DSPM for AI**, if licensed, for its discovered-AI-app view. Read it as a discovery plane, not as a preservation answer — it tells you an app is in use and says nothing about whether the record it creates survives.
Record `tool_name`, `detection_source`, `distinct_users`, `first_seen`, `corporate_or_personal_account` where determinable, and leave that last field as `undetermined` rather than guessing. An `undetermined` account type escalates the tool one confidence class, because the unresolved case is the expensive one.
## Part D — Known-tools registry (fill this in)
The one file you complete by hand before the first run. Everything discovered in Parts A through C that is absent here reports as unregistered, which is the intended behavior and the whole point of keeping it.
One row per tool you already know about. Replace the example rows.
```csv
tool_name,vendor,plan_tier,account_type,business_owner_email,records_owner_email,approved_date,contains_privileged_content,contains_personal_data,notes
Microsoft 365 Copilot,Microsoft,M365 E5 add-on,corporate-sso,cio@example.com,legalops@example.com,2025-04-14,yes,yes,Tenant-wide. Licensed users only.
ChatGPT Enterprise,OpenAI,Enterprise,corporate-sso,cto@example.com,legalops@example.com,2025-11-02,no,yes,Engineering and marketing workspaces.
Claude for Work,Anthropic,Team,corporate-sso,cto@example.com,legalops@example.com,2026-01-20,no,yes,Commercial terms; not used for training.
Gemini app,Google,Workspace Enterprise Plus,corporate-sso,cio@example.com,legalops@example.com,2026-02-09,no,yes,Vault add-on present.
```
Field notes:
- **`records_owner_email`** is deliberately separate from `business_owner_email`. The person who bought the tool is rarely the person who can answer whether its output is a record, and routing preservation questions to the buyer is how they stall.
- **`contains_privileged_content`** drives Phase 5. A tool where legal staff draft or discuss matters changes both the questionnaire language and the collection procedure, and it is worth over-flagging.
- **`account_type`** takes `corporate-sso`, `corporate-nonsso`, `personal`, or `mixed`. `mixed` is common and is not a cop-out — a tool with a corporate workspace that people also use on personal accounts genuinely lands in two of the four reachability states at once, and the profile splits into two rows.
## Reconciliation
Join all four planes on a normalized tool key. Vendors rename products, so maintain an alias list; the run is not required to resolve every alias automatically, but an unresolved alias must render as its own row rather than being silently merged.
Output `run_dir/footprint.jsonl`, one record per tool, carrying the plane provenance array. The next run diffs against this file, and the diff is worth more than the first inventory: a tool that appeared between runs, with no registry row, is the standing finding this whole exercise exists to produce.
# Reference 2 — Retention profile schema and worked profiles
## The schema
One profile per tool, or per tool-and-account-type where a tool is used both ways. Every factual field carries `source_url` and `checked_on`. A field missing either renders as `unknown` and scores as a gap; it never falls back to a default, because a plausible default is how an inventory becomes wrong quietly.
```yaml
tool: ""
account_type: "" # corporate-sso | corporate-nonsso | personal | mixed
persists: "" # yes | no | partial — some features retain, others do not
storage_side: "" # tenant | vendor | both
storage_location: "" # be specific: the mailbox folder, the Vault service, the workspace
policy_period: "" # what the configured retention says
observed_deletion_lag: "" # how long until it actually stops being returned by search
deleted_by: "" # end user | admin | automatic expiry | never
survives_source_deletion: "" # does deleting the conversation delete the derived artifact
reachable_by_existing_hold: "" # yes | no — and by WHICH control
reachability_state: "" # held | retained-not-held | not-retained | vendor-held-only
discoverable: "" # the actual mechanism, or none
export_path: "" # who can run it and what it produces
audit_trail: "" # yes | no | partial
source_url: ""
checked_on: ""
```
**`reachable_by_existing_hold` may not be inferred.** It must name the control that does the reaching — a mailbox litigation hold, a Vault matter hold, a vendor-side compliance retention setting. "The vendor says they retain it" is not a hold; vendor-side retention for the vendor's own purposes is a policy the vendor can change and is not preservation on your instruction.
## The four states
| State | Meaning | What it obligates you to do |
|---|---|---|
| `held` | An existing hold already attaches to this data | Verify with a search that returns a hit count; then nothing further |
| `retained-not-held` | Data exists and is discoverable, but no hold attaches | Affirmative collection, with a date. This is the state with a deadline |
| `not-retained` | The interaction leaves no durable record | Document the basis; revisit at the recheck interval |
| `vendor-held-only` | Record exists only in vendor systems outside your control | Escalate to counsel as a possession-custody-or-control question |
`retained-not-held` is the state teams collapse into `held`, and it is the expensive mistake, because the data is discoverable — so it will be found — and unprotected — so it can disappear between the hold notice and the collection.
## Worked profile 1 — Microsoft 365 Copilot, chat interactions
```yaml
tool: "Microsoft 365 Copilot — chat"
account_type: "corporate-sso"
persists: "yes"
storage_side: "tenant"
storage_location: "Hidden folder in the Exchange Online mailbox of the user who ran the AI app; mailbox RecipientTypeDetails is UserMailbox. Soft-deleted items move to the SubstrateHolds folder."
policy_period: "As configured. Retention locations are now split: Microsoft Copilot experiences, Enterprise AI apps, Other AI apps."
observed_deletion_lag: "Timer job runs on a 1-7 day cycle; SubstrateHolds holds items a minimum of 1 day. Microsoft's worked example shows a delete-after-1-day policy taking up to 16 days before items stop being returned by eDiscovery."
deleted_by: "Retention policy expiry, or the user deleting the chat, or a request to delete the user's Copilot interaction history."
survives_source_deletion: "n/a for chat itself"
reachable_by_existing_hold: "yes — Litigation Hold, delay hold, eDiscovery hold, or another retention policy on the same mailbox location all suspend permanent deletion from SubstrateHolds"
reachability_state: "held"
discoverable: "yes — eDiscovery, searching the Exchange mailbox location. Item class filter: Copilot activity."
export_path: "Purview eDiscovery export, by the eDiscovery admin"
audit_trail: "yes"
source_url: "https://learn.microsoft.com/en-us/purview/retention-policies-copilot"
checked_on: "2026-08-15"
```
**The consequence people miss:** every custodian already on a mailbox litigation hold has their Copilot chat preserved right now, intentionally or not. Check this before writing a retention schedule that says otherwise.
## Worked profile 2 — Microsoft 365 Copilot, memory
The same product, a different answer, which is why the schema splits by feature and not only by tool.
```yaml
tool: "Microsoft 365 Copilot — memory and personalization"
account_type: "corporate-sso"
persists: "yes"
storage_side: "tenant"
storage_location: "User's Exchange mailbox, hidden folder. Item class IPM.Contact; the memory sits in the CopilotMemory folder."
policy_period: "none — no retention applies"
observed_deletion_lag: "n/a"
deleted_by: "End user only, in Settings > Personalization. Chat-history-derived details drop within 7 days if every source chat is deleted; all chat-history details are deleted after 30 days if the control is turned off."
survives_source_deletion: "yes — deleting the chat does not delete a saved memory generated from it"
reachable_by_existing_hold: "no — Purview retention policies and retention labels do not apply to Copilot memory, and there are no admin controls to enforce retention rules for it"
reachability_state: "retained-not-held"
discoverable: "partial — saved and inferred memories are discoverable via eDiscovery and Graph Explorer. Custom instructions are NOT discoverable and must be exported by the user."
export_path: "eDiscovery plus Microsoft Graph Explorer, by the eDiscovery admin. Custom instructions: the custodian, manually."
audit_trail: "no — memory and personalization actions generate no Purview audit log entries"
source_url: "https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-personalization-memory"
checked_on: "2026-08-15"
```
Three separate problems in one row: no hold attaches, the artifact outlives the conversation that produced it, and there is no audit trail to establish what happened to it. Where a matter turns on what the organization knew, the memory is the part that says what the assistant was told to remember.
## Worked profile 3 — Gemini app in Google Workspace
```yaml
tool: "Gemini app (web and mobile)"
account_type: "corporate-sso"
persists: "yes"
storage_side: "tenant"
storage_location: "Workspace, covered by Google Vault"
policy_period: "As configured — default retention rules, or custom rules by OU or whole domain"
observed_deletion_lag: "unknown"
deleted_by: "Vault retention rule expiry, or the user"
survives_source_deletion: "unknown"
reachable_by_existing_hold: "yes — Vault litigation holds on Gemini app data, by OU or user list, available since 2026-06-11"
reachability_state: "held"
discoverable: "yes — Vault search and export"
export_path: "Vault export, by the Vault admin"
audit_trail: "yes — Vault audit"
source_url: "https://workspaceupdates.googleblog.com/2026/06/google-vault-now-supports-retention-rules-and-litigation-holds-for-Gemini-app.html"
checked_on: "2026-08-15"
```
**Two carve-outs that change the answer.** Vault's Gemini app support requires the Vault add-on and the listed editions — Business Plus, Frontline Standard and Plus, Enterprise Essentials Plus, Enterprise Standard and Plus, Education Fundamentals, Standard and Plus. Below that, there is no native hold. And Google states the support does not apply to Gemini in Google Workspace features embedded in other apps, such as "Help me write" in Gmail and Docs, because those interactions are not retained the same way — a separate row, in state `not-retained`.
## Worked profile 4 — ChatGPT, personal account on a corporate device
The hardest and most common row.
```yaml
tool: "ChatGPT — personal account"
account_type: "personal"
persists: "yes"
storage_side: "vendor"
storage_location: "OpenAI systems, under the consumer terms"
policy_period: "Deleted chats are removed from OpenAI systems within about 30 days; conversations with history disabled are retained about 30 days for abuse review"
observed_deletion_lag: "unknown"
deleted_by: "The individual account holder"
survives_source_deletion: "no"
reachable_by_existing_hold: "no — the organization holds no administrative relationship with this account"
reachability_state: "vendor-held-only"
discoverable: "only through the account holder, or third-party process to the vendor"
export_path: "The account holder's own data export"
audit_trail: "no"
source_url: "https://openai.com/business-data/"
checked_on: "2026-08-15"
```
Where a corporate workspace also exists, that is a **separate profile** in a different state: ChatGPT Enterprise appears in Microsoft's Purview retention location list under Enterprise AI apps, and workspace administrators control retention on the workspace side.
**A caution about assuming vendor-side preservation.** In the New York Times matter, a court order required OpenAI to preserve output log data that would otherwise have been deleted. That obligation ended on 2025-09-26 and the order was terminated by stipulation on 2025-10-09. For a window, consumer chats that users had deleted still existed; after it, the ordinary deletion schedule resumed. Nothing about that order was a control the organization held, and an inventory that recorded "OpenAI is preserving everything" in mid-2025 was wrong by that autumn. Vendor-side retention is not preservation on your instruction — record it as context, never as coverage.
## A note on the two other major vendors
**Anthropic.** Consumer accounts: deleted conversations leave chat history immediately and back-end storage within 30 days; where a user has enabled model improvement, data may be retained in de-identified form for up to 5 years in training pipelines. Commercial products — Claude for Work, Claude Enterprise, Claude for Education, Claude Gov — sit under commercial terms and are not used for model training. Some Claude Platform and Claude Code enterprise customers hold zero-data-retention arrangements by approval. Confirm which of these applies to your contract; the four cases produce four different rows.
**Microsoft, for non-Microsoft AI apps.** Purview's retention locations reach ChatGPT, Google Gemini, consumer Microsoft Copilot, and DeepSeek — but only when a collection policy with content capture is configured, which requires the **Content contains classifiers** condition set to **All**, and which does not include content in files shared with generative AI. Record the collection-policy state per tool as a tenant-configuration field. Absent that policy, the licence is present and the capture is not.
# Reference 3 — Custodian questionnaire and hold-notice deltas
Fillable text. Replace bracketed placeholders with the tools your Phase 3 inventory actually found; a question naming a tool nobody uses trains custodians to skim.
## Why the generic question fails
"Do you use any AI tools for work?" returns a yes, a no, or a shrug, and none of the three tells you which of the four reachability states the custodian's data sits in. The determining variable is almost never whether they use AI — it is **which account** they used, on **whose device**, and whether the output **left the tool**. Ask for those three directly.
## Part A — Questions to add to the custodian interview
Ask per named tool from the inventory, not in the abstract.
**A1 — Account identification.** "For [TOOL], which account do you sign in with — your [COMPANY] account, or a personal account?" Follow-up when the answer is personal or both: "Roughly when did you start, and is any of that work related to [MATTER SUBJECT]?"
*Why it is worded this way:* the answer routes the custodian's data between `held` and `vendor-held-only`, and those two have entirely different next steps. "Both" is a frequent and correct answer; accept it and record two rows.
**A2 — Device.** "Did you use [TOOL] on a [COMPANY]-managed device, a personal device, or both?"
**A3 — Output destination.** "When [TOOL] produced something you kept, where did it go — pasted into a document, an email, a ticket, or did it stay in the tool?"
*Why it matters more than it looks:* output that landed in a document is already inside your ordinary preservation, and the AI tool is then a secondary source rather than the record. This question is what stops an inventory from over-collecting an entire chat corpus to recover text that is sitting in a file share.
**A4 — Uploads.** "Did you upload or attach any files to [TOOL]? What kind?"
*Why:* Microsoft states that content capture for AI interactions does not include content in files shared with generative AI. A prompt referencing an attached document may be captured while the document itself is not, so the file's own location has to be established separately.
**A5 — Persistent instructions and memory.** "Have you set up custom instructions, saved memories, projects, or a custom assistant in [TOOL]?"
*Why:* these are `retained-not-held` in the reference case. Microsoft 365 Copilot custom instructions are not discoverable through eDiscovery at all and must be exported by the custodian themselves, which means this question is the only mechanism that reaches them.
**A6 — Deletion.** "Have you deleted conversations in [TOOL] since [TRIGGER DATE]? Do you have anything set to auto-delete?"
*Why:* asked plainly and without accusation, this surfaces routine hygiene before it becomes a spoliation argument. Record the answer verbatim.
**A7 — Extensions and connectors.** "Do you use any AI browser extensions, meeting notetakers, or assistants connected to your email or calendar?"
*Why:* this is the plane the identity provider misses. Notetakers in particular create a recording and a transcript in a third system that the custodian does not think of as a tool they use.
## Part B — Hold-notice clauses that change
**B1 — Scope clause.** Replace an enumerated list of systems with a formulation that reaches the AI layer explicitly:
> Your preservation obligation covers all information relating to [MATTER SUBJECT], regardless of where it is stored or what created it. This includes prompts you enter and responses you receive from AI assistants and chatbots — including [TOOL], [TOOL], and [TOOL] — whether accessed through your [COMPANY] account or a personal account, and whether on a [COMPANY] device or a personal one. It also includes saved memories, custom instructions, and stored projects within those tools.
**B2 — Anti-deletion clause, extended to derived artifacts.** The standard "do not delete" text assumes deleting the record deletes the record. In this layer that is not reliably true and the notice should say so:
> Do not delete conversations, and do not delete or edit saved memories, custom instructions, or stored project content in these tools. Deleting a conversation does not necessarily delete a memory the tool generated from it, and turning a feature off does not delete what it already stored.
**B3 — Personal-account clause.** The clause counsel should draft rather than copy, because its scope is a legal question about possession, custody, or control and about employee privacy in your jurisdiction. What the inventory contributes is the fact pattern: which tools showed personal-account usage, on how many devices, and for how long. Give counsel that and let them set the ask.
**B4 — Acknowledgement.** Add a per-tool acknowledgement line rather than one blanket signature. A custodian who checks a box next to a named tool has made a specific representation; a signature at the bottom of a page has not.
## Part C — Questions for IT and the records owner, not the custodian
Custodians cannot answer these and asking them wastes the interview.
- Is a collection policy with content capture configured for [TOOL]? Set to **All** classifiers?
- Which retention location covers [TOOL], and what is its period?
- Is the Vault add-on present, and is the edition one that supports holds for the tools in scope?
- Which existing holds already sweep in AI data sources, and for which custodians? (The over-preservation direction from Phase 4.)
- Who can run an export, how long does it take, and has anyone run one?
That last question is the one worth insisting on. An export path documented in a vendor help article and never once executed in your tenant is an assumption, and the moment to discover it does not work is not the week the production is due.
