Un skill Claude qui transforme le parc d’outils d’IA d’une organisation en inventaire de périmètre de conservation : pour chaque outil, où les prompts et les réponses persistent, ce qui les supprime et selon quelle horloge, si une conservation légale en vigueur atteint déjà ces données, et quelles formulations du questionnaire aux dépositaires et de la notification de conservation doivent changer en conséquence. Le bundle est publié dans apps/web/public/artifacts/ai-data-source-inventory-skill/ et contient SKILL.md ainsi que trois fichiers de référence, dont l’un se remplit avant la première exécution.
Le skill est en lecture seule. Il ne pose ni ne lève aucune conservation, car ces deux actes sont des décisions juridiques qui appartiennent à une personne nommément désignée.
La lacune qu’il comble
Les cartographies de données bâties avant 2023 recensent la messagerie, le chat, les partages de fichiers et les applications métier. La couche d’IA s’est ajoutée à ces mêmes systèmes sans s’ajouter à la cartographie, et les deux réponses habituelles à cela sont fausses d’une manière qui a l’air responsable.
La première consiste à traiter les outils d’IA comme un problème de sécurité déjà réglé. Un exercice de découverte du shadow AI produit une liste d’applications et un ensemble de blocages, et la liste est classée. Cette liste répond à la question de savoir qui utilise quoi. Elle ne dit rien de la trace que cet usage laisse, qui est la seule question qui intéresse la conservation.
La seconde consiste à supposer que rétention et conservation sont le même fait. Ils sont indépendants, et les lignes intéressantes sont précisément celles où ils divergent. Le chat de Microsoft 365 Copilot est conservé par des contrôles que la plupart des organisations exploitent déjà : les prompts et les réponses sont copiés dans un dossier masqué de la boîte aux lettres Exchange Online de l’utilisateur, et Microsoft documente que la suppression définitive est suspendue dès lors que cette boîte est sous Litigation Hold, sous delay hold, sous conservation eDiscovery ou sous une autre stratégie de rétention portant sur le même emplacement. Autrement dit, un dépositaire dont la boîte est sous conservation a déjà son chat Copilot préservé, que quelqu’un l’ait décidé ou non. La mémoire de Copilot, dans le même produit, va en sens inverse : Microsoft indique que les stratégies et étiquettes de rétention Purview ne s’appliquent pas à la mémoire de Copilot et qu’aucun contrôle d’administration n’y impose de rétention, tandis que les mémoires enregistrées et déduites restent détectables via eDiscovery et Graph Explorer. Détectable et non protégé est la pire paire de propriétés qu’une source de données puisse réunir.
Quand l’utiliser
Quand une conservation part et que la liste des sources par dépositaire est antérieure à la couche d’IA. Quand la partie adverse dépose une demande ESI ou une proposition au titre de la Rule 26(f) qui nomme des journaux de chatbot ou des historiques de prompts. Quand un programme de suppression défendable s’apprête à supprimer et que personne n’a établi ce que la couche d’IA copie ou laisse derrière elle. Quand la sécurité achève un balayage shadow AI et que le résultat appelle une lecture d’archivage plutôt qu’une lecture de sécurité.
Quand NE PAS l’utiliser
La conservation est déjà en retard. Émettez la notification sur le périmètre le plus large défendable d’abord, et inventoriez ensuite. Un inventaire n’est pas un motif pour retarder une notification.
Moins de huit outils d’IA environ, un seul fournisseur d’identité, tout derrière le SSO. Lisez directement les quatre consoles d’administration. Le schéma est une surcharge à cette taille.
Vous devez collecter les données, pas les délimiter. Le fichier references/2-retention-behavior-profiles.md consigne s’il existe une voie d’export et qui peut l’exécuter ; il ne l’exécute pas.
Vous n’avez accès à aucune console d’administration. Toutes les phases postérieures à la découverte dépendent d’une configuration de tenant que vous devez pouvoir lire. Sans elle, l’exécution produit une liste d’affirmations marketing d’éditeurs qui ressemble à un inventaire.
Personne ne remplira la partie D. Le registre des outils connus dans references/1-ai-tool-discovery-sources.md est ce qui fait qu’un outil non découvert se signale comme non enregistré. Sans lui, tous les constats se lisent de la même façon.
Ce que le skill fait réellement
Six phases, ordre fixe, avec des refus stricts dans deux d’entre elles.
La phase 1 collecte sur quatre plans de découverte : les autorisations du fournisseur d’identité, la dépense, la télémétrie poste de travail et navigateur, et le registre des outils connus. Ils sont délibérément redondants parce que chacun est aveugle dans une direction différente : le fournisseur d’identité ne voit pas un outil que quelqu’un paie avec une carte personnelle, la dépense ne voit pas les offres gratuites, la télémétrie ne voit pas la configuration du tenant, et le registre ne voit que ce que les gens ont écrit. Un outil trouvé par un seul plan relève d’une autre classe de confiance qu’un outil trouvé par trois, et ce sont les trouvailles à plan unique qui portent les problèmes, car un outil que personne n’a acheté est un outil que personne n’a configuré.
La phase 2 refuse de poursuivre en dessous de trois plans, ou si un plan renvoie zéro enregistrement. Un plan à zéro enregistrement s’affiche comme COLLECTION FAILED, jamais comme un résultat propre. L’échec caractéristique de ce travail est un inventaire soigné des douze outils qui étaient faciles à trouver.
La phase 3 construit un profil de rétention par outil à partir de la seule documentation éditeur et de la seule configuration du tenant. Chaque champ porte une source_url et une date checked_on ; un champ auquel il manque l’un des deux s’affiche comme unknown au lieu de retomber sur une valeur par défaut, car une valeur par défaut plausible est la façon dont un inventaire devient faux en silence. Les profils se scindent par fonctionnalité et pas seulement par outil : le chat Copilot et la mémoire Copilot forment deux lignes aux réponses opposées.
La phase 4 classe l’atteignabilité en quatre états, et c’est le choix de conception qui sépare ce résultat d’une cartographie de données. held signifie qu’un contrôle existant s’applique déjà. retained-not-held signifie que la donnée existe et est détectable mais qu’aucun mécanisme de conservation ne l’atteint, si bien que préserver devient une tâche de collecte active assortie d’une échéance, et non un dispositif que l’on pose puis que l’on oublie. not-retained signifie que l’interaction ne laisse aucune trace durable : Google indique que la prise en charge de l’application Gemini par Vault ne s’applique pas aux fonctionnalités Gemini intégrées à d’autres applications Google Workspace, comme « Help me write » dans Gmail et Docs, parce que ces interactions ne sont pas conservées de la même manière. vendor-held-only signifie que la trace n’existe que dans les systèmes de l’éditeur, hors d’atteinte de vos conservations, ce qui constitue une question de possession, de garde ou de contrôle pour les juristes et non une tâche de configuration pour la DSI.
Le test se déroule ensuite à l’envers : il liste quelles sources d’IA chaque conservation existante balaie silencieusement. La surconservation est un constat à rapporter, car elle gonfle le volume de revue et contredit tout calendrier écrit affirmant que les interactions d’IA ne sont pas conservées.
Les phases 5 et 6 dérivent les écarts de questionnaire et de notification à partir de references/3-custodian-questionnaire-deltas.md puis rendent le rapport, en tête duquel figurent les lignes retained-not-held et vendor-held-only, parce que ce sont celles qui appellent une décision cette semaine.
Coût et débit
Le calcul n’est pas le budget. Le skill lit des exports et de la documentation éditeur ; la rédaction d’un profil consomme environ 600-900 tokens de sortie, de sorte qu’un parc de 40 outils coûte nettement moins d’un dollar en dépense de modèle.
Le coût humain est le chiffre entier, et c’est une estimation plutôt qu’une mesure : prévoyez 2-4 heures pour extraire les quatre plans si les exports existent, puis 15-30 minutes par outil entre documentation et vérification dans le tenant. Un parc de 40 outils représente un premier passage de 10-20 heures, l’essentiel en phase 3. La partie D de la référence de découverte persiste, de sorte que la deuxième exécution est un diff et coûte une fraction de la première. Relancez-le par affaire, et chaque trimestre au titre de la préparation permanente.
Modes de défaillance
Confondre « c’est retenu » et « une conservation l’atteint ». L’équipe déclare une couverture qu’aucune conservation ne produit réellement. Garde-fou :reachable_by_existing_hold ne peut pas être déduit ; le schéma impose de nommer le contrôle précis qui réalise l’atteinte, et la rétention côté éditeur pour ses propres besoins ne compte pas.
Vérifier la conservation en regardant l’application.Garde-fou : Microsoft indique que les messages visibles dans les applications d’IA ne reflètent pas fidèlement s’ils sont conservés ou définitivement supprimés. La vérification de la phase 4 est une recherche eDiscovery qui renvoie un nombre de résultats contre un dépositaire connu, jamais une capture d’écran.
Lire la durée de rétention configurée comme la date de suppression. L’exemple chiffré de Microsoft montre qu’une stratégie de suppression après un jour peut prendre jusqu’à 16 jours avant que les éléments cessent d’être renvoyés par eDiscovery, parce que le timer job tourne sur un cycle de 1-7 jours et que le dossier SubstrateHolds ajoute au moins un jour de plus. Garde-fou : le schéma sépare policy_period de observed_deletion_lag, et les attestations de suppression défendable citent le second.
Supposer qu’une licence vaut capture. Les emplacements de rétention de Purview atteignent ChatGPT, Google Gemini, le Copilot grand public et DeepSeek uniquement lorsqu’une collection policy avec capture de contenu est configurée, ce qui exige la condition Content contains classifiers réglée sur All — et Microsoft précise que cela n’inclut pas le contenu des fichiers partagés avec l’IA générative. Garde-fou : l’état de la collection policy est un champ de configuration du tenant par outil, et non une hypothèse au niveau de l’organisation.
Tenir les conditions des éditeurs pour stables. L’ordonnance de conservation dans l’affaire du New York Times obligeait OpenAI à conserver des données de journal de sortie qui auraient sinon été supprimées ; cette obligation a pris fin le 2025-09-26 et l’ordonnance a été levée par stipulation le 2025-10-09. Google Vault n’a obtenu de règles de rétention et de litigation holds pour l’application Gemini que le 2026-06-11. Un inventaire rédigé d’un côté de ces dates est faux de l’autre côté. Garde-fou : chaque profil porte checked_on, et tout ce qui dépasse l’intervalle de revérification s’affiche comme unverified et est compté dans l’en-tête du rapport.
L’inventaire devient un document RH dès l’instant où il nomme des personnes faisant quelque chose de non approuvé, et la coopération s’effondre. Garde-fou : la phase 1 agrège par outil et par effectif ; le détail par dépositaire est écrit dans run_dir/custodians/ et référencé par chemin, jamais inséré dans le rapport.
Face aux alternatives
Face au connecteur de sources d’IA d’un éditeur eDiscovery. Onna, Exterro et Reveal vendent la collecte depuis des sources cloud, et lorsque vous avez une affaire et devez sortir les données, un connecteur l’emporte à chaque fois sur le travail manuel. Il résout le problème voisin. Vous avez tout de même besoin de l’inventaire pour savoir quels connecteurs acheter, et il n’existe pas de connecteur pour les sources dépourvues de toute voie d’export, c’est-à-dire précisément là où se trouvent les lignes retained-not-held.
Face à Purview DSPM for AI seul. Sur un parc centré Microsoft, c’est le plan de découverte le plus solide disponible, et le bundle s’en sert comme de l’un d’eux. Deux limites l’empêchent d’être la réponse : il rapporte l’usage des applications d’IA plutôt que ce qui survit à cet usage, et sa portée sur les outils hors Microsoft dépend du plan navigateur ainsi que d’une collection policy que la plupart des tenants n’ont pas configurée.
Face au fait de demander la liste des applications à la DSI. L’option la plus rapide, et la réponse est la liste SSO, qui exclut structurellement l’usage hors SSO et sur comptes personnels. Cette population exclue est exactement celle dont la posture de conservation est la plus mauvaise : la méthode la plus rapide a donc son angle mort là où se trouvent les constats.
Face à un tableur. La comparaison honnête, puisque c’est ce que font la plupart des équipes. Cela suffit à dix outils. Ce qui mérite de ne pas être réécrit, ce sont le schéma de profil avec sa source_url obligatoire, la classification en quatre états et le test de conservation inversé, car ce sont ces trois éléments que les équipes ratent lorsqu’elles construisent le tableur elles-mêmes.
---
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.
