The best time to discuss ownership is before everyone falls in love with the platform.
That’s true in business relationships. It is especially true when the vendor is receiving company data, client information, internal knowledge, and the processes your team uses to operate.
I described the vendor-exit question this way during a recent discussion:
“In the case of a breakup, who gets the kids and the dog?”
It sounds funny.
The underlying issue isn’t.
Before you implement an AI platform, you should know what information it receives, where that information goes, how long it stays there, who else can access it, whether it is used to train anything, and what happens when you decide to leave.
Otherwise, you may discover that your organization has less control over its data than everyone assumed.
Governance Is More Than an Employee Policy
An employee policy may tell people which tools they are allowed to use.
That is only one part of AI governance.
The organization also needs to know:
“What you’re doing, who you’re working with and how you’re using it.”
That requires an inventory.
Not a mental list.
Not a handful of browser bookmarks.
Not an expense buried inside a credit-card statement.
A documented inventory.
For every AI platform or AI-enabled vendor, identify:
- The vendor and platform
- The internal business owner
- The approved use case
- The people or departments using it
- The information being entered
- Where the information is processed or stored
- The applicable retention period
- Whether the data is used for model training
- Any subprocessors involved
- The process for exporting information
- The process for deleting information
- The vendor terms reviewed by the organization
This inventory does not have to begin as a complicated governance system.
A properly managed spreadsheet is better than an expensive platform nobody maintains.
The important thing is knowing what is happening.
Define Where the Data Goes
Cloud software can make data movement feel invisible.
An employee enters information into a box. A response comes back. The process feels contained.
It may not be.
The information may pass through multiple systems. It may be logged, cached, retained, reviewed, or processed by subprocessors. It may cross geographic boundaries. It may be governed by terms that change depending on whether the account is free, individual, business, or enterprise.
As I put it:
“You need to define where your data goes.”
That needs to be answered before implementation.
What does the vendor receive?
Does it retain the original prompt?
Does it retain uploaded files?
Does it retain the response?
Where is that information stored?
Who are the subprocessors?
What administrative controls are available?
Can retention be disabled?
Can the vendor use the information to improve its own products or models?
A vague answer such as “we take security seriously” is not enough.
That is a marketing statement, not a data-flow description.
Who Benefits From the Learning?
The phrase “AI learns from your data” is often used as though learning is automatically a benefit.
A benefit to whom?
If your company’s information helps improve a public or vendor-owned model, the vendor may be extracting value from knowledge your organization created.
That may not be appropriate.
For regulated, confidential, or contr restricted information, the position may need to be:
“No ability to learn off the data, zero retention.”
For less sensitive information, the organization may decide that limited retention or controlled learning is acceptable.
Even then, the decision should be deliberate.
The contract and technical settings should define whose model benefits, what information is de-identified, what retention applies, and whether the organization can change its decision later.
Don’t assume “de-identified” automatically means risk-free.
Don’t assume a sales presentation overrides written vendor terms.
And don’t assume the settings available today will remain the default tomorrow.
Demand the Big Red Button
When I evaluate a platform handling our information, I want control.
As I said during the discussion:
“I wanted to have the big red button to nuke all my data out of their systems.”
And:
“I want full control over my data. I want to be able to pull it out. I want to be able to torch it.”
That means two distinct capabilities.
First, portability.
Can you export the information in a usable format? This includes more than the source documents you uploaded. What happens to saved prompts, instructions, applications, configurations, outputs, workflow history, and institutional knowledge developed inside the platform?
Second, deletion.
Can you remove the data from active systems? What about backups, logs, caches, and subprocessors? How long does deletion take? Is there a contractual commitment? Can the vendor provide confirmation?
A delete button in the user interface is useful.
A clearly defined deletion right in the agreement is better.
You may need both.
Vendor Offboarding Deserves the Same Discipline as Employee Offboarding
Most mature businesses understand the need to remove access when an employee leaves.
Accounts are disabled. Passwords are changed. Devices are collected. Permissions are reviewed. Company information is returned.
Vendor offboarding deserves the same attention.
When a relationship ends:
Who owns the prompts?
Who owns the configured applications?
Can you move the workflow to another platform?
Can you export the outputs?
Will the vendor continue retaining source information?
What happens to integrations and connected data sources?
Will your organization still be able to reproduce the work?
These questions are much easier to resolve before implementation than during a dispute, price increase, service failure, acquisition, or emergency migration.
Plan the exit while the relationship is still friendly.
AI Exit Rights Are Business-Continuity Rights
Data ownership is not just a privacy issue.
It is an operational-resilience issue.
If a critical business process becomes dependent on one AI platform, the organization needs to understand what happens when that platform is unavailable, changes its model, alters its pricing, removes a feature, modifies its terms, or no longer meets the organization’s needs.
Can the process be moved?
Has the working prompt been documented outside the platform?
Is there a sample target output?
Has the company preserved the underlying source information?
Could another model perform the task?
Do employees understand the process, or do they only understand where to click?
This is another reason to preserve successful prompts and outputs as company-controlled assets.
The application can change.
The organization’s knowledge should survive the change.
Ask Before You Implement
Before approving an AI platform, get clear answers to the following:
- What information will we provide?
- Where will it be processed and stored?
- Which subprocessors may receive it?
- How long will prompts, files, and outputs be retained?
- Will any of the information train or improve a vendor-owned model?
- Can retention or training be disabled?
- Can we export our information and configurations in a usable format?
- How do we delete the information?
- What happens to backups and logs?
- What happens when the agreement ends?
The answers may be different depending on the sensitivity of the data and importance of the process. That is expected.
What should not be different is the discipline of asking.
Control Before Convenience
AI platforms can deliver real value.
They can also create a new form of vendor lock-in built around your own information, prompts, processes, and accumulated knowledge. Don’t wait until the breakup to determine who gets the kids and the dog.
Know where the data goes. Know who can use it. Know how you can retrieve it.
Know how you can delete it. Then implement the platform with your eyes open.
That is not being anti-AI.
It is doing the right things right.
