What Happens to Your Data When an AI Pilot or Trial Ends

When an AI pilot or trial ends, nothing happens to your data automatically unless the agreement says so. Files, conversation logs, memory and connected-system access can stay in place at the provider long after the last user logs in. You should require three things in writing: a return of what belongs to you, deletion of the rest, and a confirmation that names what was deleted, where, and when.

Key takeaways

• A pilot creates more data than the files you uploaded: conversations, memory, indexes, configuration, credentials, logs and backups all count.
• Decide for each category whether it is returned, deleted, revoked or retained, and record the reason for any retention.
• Verify a return before you approve any deletion, because deletion cannot be undone.
• Revoke access on your own side. Do not rely only on the provider to close connections to your systems.
• Accept only a written confirmation that lists categories, systems, subprocessors, backups and dates.

Where does your data actually live during a pilot?

A pilot touches more than the documents someone uploaded. Before you can ask for return or deletion, you need to know what exists. Most pilots produce some mix of the following:

• Source material: documents, spreadsheets and exports your team handed to the agent.
• Connected system data: records the agent read or wrote through integrations with email, calendars, a CRM or shared drives.
• Conversation history: prompts, replies and attachments from pilot users, which may contain personal data about customers or employees.
• Memory and indexes: notes the agent kept, plus searchable indexes or embeddings built from your documents.
• Configuration: instructions, workflows, role definitions and tool settings written for your business.
• Access credentials: tokens, API keys, service accounts and permissions you granted.
• Logs and evaluation records: traces, test cases, scores and review notes.
• Backups and copies: snapshots held by the provider or by the subprocessors it uses.

Ask the provider for this inventory in writing, with the location of each category. If they cannot produce it, you have learned something important about how closeout will go. The best moment to ask is before the pilot begins, and the statement of work is the right place to record the answer.

Return, delete, revoke or retain: how do you decide?

Not every category deserves the same treatment. A simple decision guide keeps the conversation with the provider short and specific.

• Source material: return a copy if your own copy is incomplete, then require deletion of the provider's copies.
• Conversation history: return it if you need it for records or review, then delete it. Involve whoever owns privacy decisions, because these logs often hold personal data.
• Memory and indexes: require deletion. Ask for the readable memory notes to be returned, since the index itself is tied to the provider's tooling and is rarely useful elsewhere.
• Configuration: return it. Instructions, workflows and role definitions describe how your business works. Agree in writing who owns them and whether the provider may keep any generic reusable parts.
• Credentials and permissions: revoke them. This is different from deletion, and it should happen first.
• Logs: expect the provider to keep minimal security logs for a stated period. Require them to say which logs, why, and until when.
• Backups: require deletion on the normal rotation, with a stated end date rather than an open-ended promise.

Any retention should come with a named reason and an end date. Retention with no reason is the item most likely to be forgotten.

What should a proper return of your data look like?

A return is not a link to a dashboard. It is a package you can open without the provider's software, and that you can check against the inventory.

Ask for open, documented formats: plain text, common document formats, spreadsheets or structured files that other tools can read. Memory notes should arrive as readable text. Configuration should arrive as files someone else could follow, not as screenshots. Conversation logs should keep timestamps and user identifiers to the extent you agreed, and nothing more.

The package should include a manifest: a list of what was exported, how many items per category, and what was deliberately excluded and why. Then verify it. Open a sample from each category, compare it with what you know should be there, and have a second person confirm. Only after that should you approve deletion. If your team has never tested restoring from an export, the logic in AI agent backup and restore applies directly: an export you have not opened is a hope, not a copy.

Why is deletion harder than it sounds?

Deleting a folder in an interface is easy. Deleting everywhere the data went is not, and the gaps usually sit in five places.

• Derived data: summaries, embeddings and indexes created from your documents can outlive the documents unless they are named in the deletion scope.
• Subprocessors: the provider may pass prompts or files to model vendors, storage services or monitoring tools. Ask for the list, and ask whether each one retains anything.
• Training use: confirm in writing whether your data was ever used to improve any model, and that it will not be. The article on whether your AI provider trains on your company data covers what to ask for.
• Backups and logs: these often follow a separate retention cycle, so the deletion date for them is later than the deletion date for live systems.
• Legal or security holds: a provider may have a genuine reason to keep something. That is acceptable only when stated, scoped and time-limited.

If pilot data includes personal data, privacy law may add duties. Brazil's LGPD, overseen by the [ANPD](https://www.gov.br/anpd/pt-br), and similar laws elsewhere can affect how long data may be kept and what people can ask for. Involve counsel or your data protection lead before you agree to any retention. Governance frameworks such as the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) also treat safe decommissioning of an AI system as part of governing it, not an afterthought.

Access deserves its own attention. When you connect an agent to your tools through a standard such as [OAuth 2.0](https://developers.google.com/identity/protocols/oauth2), the grant stays valid until it is revoked or expires. Revoke it from the admin console of each connected service yourself, remove API keys and service accounts, and check that nothing still holds broader permissions than it needs. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a useful reference for the least-privilege thinking behind this.

What is a practical closeout plan, step by step?

Closeout goes best when it is a short project with an owner, not a favor asked at the end. If the pilot is being stopped early, stopping an AI pilot without wasting the work covers the decision itself. Once the decision is made, this sequence works.

• Step one: name an owner on your side, usually the sponsor or an operations lead, and one named contact at the provider.
• Step two: request the data inventory and the subprocessor list, and compare them with what your team believes was shared.
• Step three: freeze new inputs. Stop pilot users from adding documents or starting new conversations.
• Step four: request the return package and the manifest.
• Step five: verify the package by sampling each category, and record who checked what.
• Step six: revoke access on your side, including tokens, keys, service accounts and any shared folders or mailboxes.
• Step seven: authorize deletion in writing, listing the categories and any approved retention with reasons and end dates.
• Step eight: receive the written confirmation, check it against the inventory, and file it with the pilot records.
• Step nine: hold a short review of what the pilot taught you, so the configuration and lessons you kept are used.

Illustrative scenario: a distribution company ends a pilot in which an agent triaged supplier emails. The operations manager asks for the inventory and finds three things nobody had listed: an index built from supplier price lists, a mailbox grant still active, and conversation logs containing supplier contact names. She requests the instructions and memory notes as readable files, opens a sample of each, then revokes the mailbox grant herself. Only then does she authorize deletion. The provider's confirmation arrives listing the index, the logs, the subprocessor copies and the backup expiry date, and she files it beside the pilot report.

What should a deletion confirmation contain?

A message saying that everything has been deleted is not enough. It tells you nothing you can check. A useful confirmation includes:

• The categories deleted, matching the inventory you received at the start.
• The systems and locations covered, including subprocessors.
• The date of deletion for live systems and the expected date for backups and logs.
• Any retained items, with the reason, the legal or security basis, and the end date.
• A statement about whether your data was used for model training or improvement.
• The name and role of the person confirming, and the date of the confirmation.

If backups expire later, ask for a second short confirmation when that date passes. It costs the provider little and closes the loop. Treat a refusal to name subprocessors or backup timing as a signal worth weighing. The review in red flags when hiring an AI implementation partner can help you place that signal in context.

How does a managed approach handle closeout?

Be Human designs and operates agents with identity, memory, channels, tools and permissions kept under human control. Because a first engagement defines the role, the memory and tools it needs, and the approval boundaries, the same definition serves as the data inventory when a pilot closes. Closeout then follows the plan above: a return of exports and configuration, revocation of access, deletion of the agreed categories, and written confirmation of what was done. Any item that is retained is named with its reason. The scope for each of these is agreed with the client before the work begins, not improvised at the end.

Frequently asked questions

Does the provider have to delete my data when a trial ends? It depends on the agreement and on the privacy rules that apply to the data. Without a written term, deletion may simply not happen, or may happen on the provider's own schedule. Put the return and deletion terms in writing before the trial starts.

Can I get back what the agent learned about my business? You can usually get back the readable parts: memory notes, instructions, workflows and conversation records. The internal index or model state is generally tied to the provider's tooling and is not portable. Ask for the readable material and an explanation of what is not returned.

Should I delete before or after I export? Export first, verify it, then delete. Deletion cannot be undone, so confirm that the package opens, matches the manifest and covers each category before you authorize it.

What if the provider says some data must be kept? Ask what exactly, why, under what basis and until when. A legitimate retention is specific and time-limited, and it appears in the written confirmation. A vague or open-ended retention should be challenged, and escalated to counsel if it involves personal data.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.