Un skill de Claude que convierte el inventario de herramientas de IA de una organización en un mapa de alcance de preservación: para cada herramienta, dónde persisten los prompts y las respuestas, qué las elimina y bajo qué reloj, si una retención legal vigente ya alcanza esos datos, y qué lenguaje del cuestionario a custodios y de la notificación de retención hay que cambiar según la respuesta. El bundle se publica en apps/web/public/artifacts/ai-data-source-inventory-skill/ y contiene SKILL.md más tres archivos de referencia, uno de los cuales completas antes de la primera ejecución.
El skill es de solo lectura. No coloca ni levanta ninguna retención, porque ambas son decisiones legales que corresponden a una persona con nombre y apellido.
El hueco que cierra
Los mapas de datos construidos antes de 2023 listan correo, chat, repositorios de archivos y sistemas de negocio. La capa de IA se sumó a esos mismos sistemas sin sumarse al mapa, y las dos respuestas habituales a eso son erróneas de maneras que parecen responsables.
La primera es tratar las herramientas de IA como un problema de seguridad ya resuelto. Un ejercicio de descubrimiento de shadow AI produce una lista de aplicaciones y un conjunto de bloqueos, y la lista se archiva. Esa lista responde quién usa qué. No dice nada sobre qué registro deja ese uso, que es la única pregunta que le importa a la preservación.
La segunda es asumir que retención y preservación son el mismo hecho. Son independientes, y las filas interesantes son aquellas donde divergen. El chat de Microsoft 365 Copilot queda preservado por controles que la mayoría de las organizaciones ya opera: los prompts y las respuestas se copian a una carpeta oculta en el propio buzón de Exchange Online del usuario, y Microsoft documenta que la eliminación permanente se suspende cuando ese buzón está bajo Litigation Hold, un delay hold, una retención de eDiscovery u otra política de retención para la misma ubicación. Es decir, un custodio con retención sobre su buzón ya tiene su chat de Copilot preservado, lo haya decidido alguien o no. La memoria de Copilot, dentro del mismo producto, va en sentido contrario: Microsoft declara que las políticas y etiquetas de retención de Purview no aplican a la memoria de Copilot y que ningún control de administrador impone retención sobre ella, mientras que las memorias guardadas e inferidas siguen siendo detectables mediante eDiscovery y Graph Explorer. Detectable y desprotegido es el peor par de propiedades que puede tener una fuente de datos.
Cuándo usarlo
Cuando va a salir una retención y la lista de fuentes por custodio es anterior a la capa de IA. Cuando la contraparte presenta una solicitud de ESI o una propuesta bajo la Regla 26(f) que nombra registros de chatbot o historial de prompts. Cuando un programa de eliminación defendible está a punto de empezar a borrar y nadie ha establecido qué copia o qué deja atrás la capa de IA. Cuando seguridad termina un barrido de shadow AI y el resultado necesita una lectura de gestión documental en lugar de una lectura de seguridad.
Cuándo NO usarlo
La retención ya va tarde. Emite la notificación con el alcance más amplio defendible primero, e inventaría después. Un inventario no es motivo para retrasar una notificación.
Menos de unas ocho herramientas de IA, un solo proveedor de identidad, todo detrás de SSO. Lee las cuatro consolas de administración directamente. El esquema es sobrecarga a ese tamaño.
Necesitas recolectar los datos, no delimitarlos.references/2-retention-behavior-profiles.md registra si existe una vía de exportación y quién puede ejecutarla; no la ejecuta.
No tienes acceso a ninguna consola de administración. Todas las fases posteriores al descubrimiento dependen de configuración del tenant que debes poder leer. Sin eso, la ejecución produce una lista de afirmaciones de marketing del proveedor con aspecto de inventario.
Nadie va a completar la Parte D. El registro de herramientas conocidas en references/1-ai-tool-discovery-sources.md es lo que hace que una herramienta no descubierta se reporte como no registrada. Sin él, todos los hallazgos se leen igual.
Qué hace realmente el skill
Seis fases, orden fijo, con rechazos duros en dos de ellas.
La fase 1 recolecta de cuatro planos de descubrimiento: concesiones del proveedor de identidad, gasto, telemetría de endpoint y navegador, y el registro de herramientas conocidas. Son deliberadamente redundantes porque cada uno es ciego en una dirección distinta: el proveedor de identidad no ve una herramienta que alguien paga con tarjeta personal, el gasto no ve los planes gratuitos, la telemetría no ve la configuración del tenant, y el registro solo ve lo que la gente anotó. Una herramienta encontrada por un plano pertenece a otra clase de confianza que una encontrada por tres, y son los hallazgos de un solo plano los que traen los problemas, porque una herramienta que nadie compró es una herramienta que nadie configuró.
La fase 2 se niega a continuar con menos de tres planos, o si algún plano devuelve cero registros. Un plano con cero registros se renderiza como COLLECTION FAILED, nunca como un resultado limpio. El fallo característico de este trabajo es un inventario prolijo de las doce herramientas que fue fácil encontrar.
La fase 3 construye un perfil de retención por herramienta únicamente a partir de documentación del proveedor y configuración del tenant. Cada campo lleva un source_url y una fecha checked_on; un campo al que le falte alguno de los dos se renderiza como unknown en lugar de caer a un valor por defecto, porque un valor por defecto plausible es la forma en que un inventario se equivoca en silencio. Los perfiles se dividen por funcionalidad, no solo por herramienta: el chat de Copilot y la memoria de Copilot son dos filas con respuestas opuestas.
La fase 4 clasifica el alcance en cuatro estados, y esa es la decisión de diseño que separa el resultado de un mapa de datos. held significa que un control existente ya se adhiere. retained-not-held significa que los datos existen y son detectables pero ningún mecanismo de retención los alcanza, de modo que preservar es una tarea afirmativa de recolección con fecha, no algo que colocas y olvidas. not-retained significa que la interacción no deja registro duradero: Google declara que el soporte de Vault para la aplicación Gemini no aplica a las funciones de Gemini integradas en otras aplicaciones de Google Workspace, como “Help me write” en Gmail y Docs, porque esas interacciones no se retienen de la misma forma. vendor-held-only significa que el registro vive únicamente en sistemas del proveedor que tus retenciones no pueden tocar, lo que es una cuestión de posesión, custodia o control para los abogados y no una tarea de configuración para IT.
Luego ejecuta la prueba al revés, listando qué fuentes de IA barre silenciosamente cada retención existente. La sobrepreservación es un hallazgo reportable: infla el volumen de revisión y contradice cualquier calendario escrito que afirme que las interacciones de IA no se preservan.
Las fases 5 y 6 derivan los deltas del cuestionario y de la notificación a partir de references/3-custodian-questionnaire-deltas.md y reportan, encabezando con las filas retained-not-held y vendor-held-only porque esas exigen una decisión esta semana.
Costo y throughput
El cómputo no es el presupuesto. El skill lee exportaciones y documentación del proveedor; la redacción de cada perfil consume aproximadamente 600-900 tokens de salida, así que un parque de 40 herramientas cuesta bastante menos de un dólar en gasto de modelo.
El costo humano es la cifra completa, y es una estimación más que una medición: prevé 2-4 horas para extraer los cuatro planos si las exportaciones existen, y luego 15-30 minutos por herramienta entre documentación y verificación en el tenant. Un inventario de 40 herramientas es una primera pasada de 10-20 horas, la mayor parte en la fase 3. La Parte D de la referencia de descubrimiento persiste, así que la segunda ejecución es un diff y cuesta una fracción de la primera. Vuelve a ejecutarlo por asunto, y trimestralmente como preparación permanente.
Modos de fallo
Confundir “se retiene” con “una retención lo alcanza”. El equipo reporta una cobertura que ninguna retención produce realmente. Guarda:reachable_by_existing_hold no se puede inferir; el esquema obliga a nombrar el control específico que hace el alcance, y la retención del lado del proveedor para sus propios fines no califica.
Verificar la preservación mirando la aplicación.Guarda: Microsoft declara que los mensajes visibles en las aplicaciones de IA no reflejan con exactitud si están retenidos o eliminados de forma permanente. La verificación de la fase 4 es una búsqueda de eDiscovery que devuelve un conteo de coincidencias contra un custodio conocido, nunca una captura de pantalla.
Leer el período de retención configurado como la fecha de eliminación. El propio ejemplo trabajado de Microsoft muestra que una política de eliminar-tras-un-día puede tardar hasta 16 días antes de que los elementos dejen de aparecer en eDiscovery, porque el timer job corre en un ciclo de 1-7 días y la carpeta SubstrateHolds añade al menos un día más. Guarda: el esquema separa policy_period de observed_deletion_lag, y las certificaciones de eliminación defendible citan el segundo.
Asumir que una licencia equivale a captura. Las ubicaciones de retención de Purview alcanzan ChatGPT, Google Gemini, el Copilot de consumo y DeepSeek solo cuando hay configurada una collection policy con captura de contenido, lo que exige la condición Content contains classifiers puesta en All, y Microsoft declara que no incluye el contenido de los archivos compartidos con la IA generativa. Guarda: el estado de la collection policy es un campo de configuración del tenant por herramienta, no una suposición a nivel de organización.
Tratar los términos del proveedor como estables. La orden de preservación en el caso del New York Times obligó a OpenAI a conservar datos de registro de salida que de otro modo se habrían eliminado; esa obligación terminó el 2025-09-26 y la orden se dio por terminada por estipulación el 2025-10-09. Google Vault recién incorporó reglas de retención y litigation holds para la aplicación Gemini el 2026-06-11. Un inventario escrito a un lado de esas fechas es incorrecto del otro lado. Guarda: cada perfil lleva checked_on, y todo lo que supere el intervalo de reverificación se renderiza como unverified y se cuenta en el encabezado del informe.
El inventario se convierte en un documento de RR. HH. en el momento en que nombra a personas haciendo algo no aprobado, y la cooperación se derrumba. Guarda: la fase 1 agrega por herramienta y conteo; el detalle por custodio se escribe en run_dir/custodians/ y se referencia por ruta, nunca incrustado en el informe.
Frente a las alternativas
Frente a un conector de fuentes de IA de un proveedor de eDiscovery. Onna, Exterro y Reveal venden recolección desde fuentes en la nube, y cuando tienes un asunto y necesitas sacar los datos, un conector le gana a hacerlo a mano siempre. Resuelve el problema contiguo. Igual necesitas el inventario para saber qué conectores comprar, y no existen conectores para las fuentes que no tienen ninguna vía de exportación, que es justo donde viven las filas retained-not-held.
Frente a Purview DSPM for AI por sí solo. Para un parque centrado en Microsoft es el plano de descubrimiento más fuerte disponible, y el bundle lo usa como uno de ellos. Dos límites impiden que sea la respuesta: reporta el uso de aplicaciones de IA en lugar de lo que sobrevive a ese uso, y su alcance sobre herramientas ajenas a Microsoft depende del plano del navegador más una collection policy que la mayoría de los tenants no ha configurado.
Frente a pedirle a IT la lista de aplicaciones. Es la opción más rápida, y la respuesta es la lista de SSO, que estructuralmente excluye el uso sin SSO y con cuentas personales. Esa población excluida es precisamente la que tiene la peor postura de preservación, así que el método más rápido tiene su punto ciego exactamente donde están los hallazgos.
Frente a una hoja de cálculo. La comparación honesta, ya que es lo que hace la mayoría de los equipos. Sirve con diez herramientas. Lo que vale la pena no reescribir es el esquema de perfil con su source_url obligatorio, la clasificación de cuatro estados y la prueba inversa de retención, porque esas tres son las que la gente hace mal cuando construye la hoja por su cuenta.
---
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.
