Your AI Remembers Every Customer Chat. How Long Should It?

A clinic manager in Beirut asked me a question last spring that sounded small. Her WhatsApp assistant had been answering patients for fourteen months, and a junior colleague wanted to know whether the team could delete the old chats. The dashboard showed 3,200 stored conversations. Nobody in the room could say who had decided to keep them, what they were for, or who was allowed to remove them.

This clinic is a composite, and every figure in this article is illustrative. The situation is not invented. I see some version of it in most service businesses that run a customer-facing assistant. Nobody chose to keep the chats. The default setting of the tool chose for them.

The archive nobody decided to keep

Keeping everything feels harmless. Storage is cheap, and a transcript might be useful someday. In my work I hear the same three reasons: "it helps us improve the assistant," "we might need it in a dispute," and "deleting feels risky." Each has some truth in it. None of them names a data type, a time limit and an owner, which is what a purpose needs in order to justify storage.

Every stored conversation carries whatever the customer typed into it: a name, a phone number, a symptom, a salary, a photo of an ID card. The longer it sits, the more ways it can go wrong. It can leak, be requested by a regulator, be copied by a departing employee, or travel to a new vendor with the next contract. Its usefulness to you falls quickly after the conversation ends. Its exposure does not fall at all.

That is what I mean when I say a stored conversation is a liability with a clock. If nobody sets the clock, it runs forever.

In the composite, about 600 of the 3,200 chats were ever opened again by a person. That is fewer than one in five. The other 2,600 were never touched. They were not an asset waiting for a use. They were risk without a purpose.

Sort chats by what they contain, not when they happened

Most retention settings are date-based: delete after a year, or never. Date is the wrong axis. A chat about opening hours and a chat in which a patient describes a diagnosis may both be from last March, yet they should not live for the same length of time.

I sort conversations into three classes by content:

• Routine: prices, opening hours, directions, general questions. Nothing tied to a named person.
• Personal identifiers: names, phone numbers, email addresses, booking details.
• Sensitive: health details, financial details, and images of ID documents or payment cards.

A chat takes the class of the most sensitive thing inside it. One passport photo makes the whole conversation sensitive, however routine the rest of it was.

The four-column retention schedule

For each data type I want one row and four written answers: why we keep it, how long, who can open it, and how it is deleted and who confirms. If any cell is blank, that data should not be stored yet. The "how long" cell must be a number of days and an end trigger, not "as needed."

These numbers are illustrations. Your own purposes and legal duties set your own days. What matters is that every row has a reason, a limit, an owner and a witness.

Worked example: the clinic re-sorts its 3,200 chats

Back to the composite clinic. Over fourteen months it had accumulated 3,200 chats, an average of roughly 230 a month. Sorted by content, they split into about 2,100 routine, 800 with personal identifiers and 300 with sensitive content.

Before deleting anything, the manager did one thing. She asked the team to move whatever the patient file genuinely needed from the sensitive chats into the file itself. The chat was never meant to be the record, and moving the content made that explicit.

Then the schedule above was applied. Routine chats older than 30 days went. Identifier chats more than 90 days past the appointment went. Sensitive chats went once their content had been transferred. About 330 chats remained inside their windows, roughly one in ten, and about 2,870 were deleted.

She then checked the 600 chats that people had reopened. In the composite, nearly all of them were reopened within a few weeks of the conversation. The windows lost almost nothing anyone had actually used.

One boundary matters here. This article is about chat content only. The record of what the assistant was permitted to do, what it decided, and who approved it is a separate, deliberate keep, with its own owner and its own clock. I am not suggesting you delete those.

Three things deletion does not fix

Deleting inside your dashboard is the visible part. Three copies usually survive it.

1. Vendor copies and backups. Your dashboard may remove only your view. The vendor's backups roll over on their own schedule, and some conversation data sits in logs you never see.
2. Spreadsheet exports. Someone exported the chats to analyse them, and the file now lives in an inbox and a shared drive, outside every rule you just wrote.
3. Staff screenshots. A staff member captured a conversation to ask a colleague a question, and it is now in a personal phone and a group chat.

The fix for the second and third is a short written rule on what staff may export and capture, plus a request to clear what already exists. The fix for the first is a conversation with your vendor. I ask two questions:

• When we delete a conversation, in how many days is it gone from your live systems and from your backups, and will you confirm that in writing?
• When our contract ends, what do you retain, for how long, and can you give us a deletion confirmation?

If the answers are vague, the retention schedule you wrote covers only the part of the data you can see.

The five-line check before launch

1. Default is delete.
2. No purpose, no storage.
3. ID, health and card images never stay in chat.
4. Test deletion quarterly.
5. Tell the customer in one line what is kept and for how long.

The fourth line is the one most often skipped. A deletion rule that has never been tested is a belief, not a control. Pick a chat at random, delete it under the schedule, and ask the vendor to show you that it is gone.

You can set this schedule in a week. The harder part is the question the clinic manager's colleague asked, because answering it means admitting that the archive was never a decision.

This is not legal advice. Check your local data-protection rules, which differ across Lebanon and the Gulf states, before you set your own retention periods.

Frequently asked questions

How long should a business keep AI chatbot logs?

It depends on the content, not the calendar. In my work I set short windows: around 30 days for routine questions, about 90 days past an appointment for contact details, and about a week for sensitive text once it sits in the proper record. Each period needs a named purpose and an end trigger. Your local rules may require different numbers.

Is it safe to keep chats "in case of a dispute"?

Rarely, as a blanket reason. A dispute needs specific evidence, such as the booking confirmation or the agreed price, and those can be kept in a proper record with its own owner and limit. Holding every conversation for a possible dispute stores far more personal data than any dispute will ever need.

Does deleting a chat in my dashboard delete it at the vendor?

Not necessarily. Deleting may remove only your view, while backups and logs at the vendor continue on their own schedule. I ask every vendor how many days until a deleted conversation is gone from live systems and backups, and I ask for that answer in writing before launch.

What should an AI assistant do when a customer sends an ID or card photo?

It should not accept the image into the chat. I configure the assistant to say, in one line, that images of ID documents, health records and cards cannot be handled here, and to redirect the customer to a secure channel. If a photo still arrives, it should be removed on receipt, not retained.

Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.