Why does Dr. Jonah Tebaa say a stored AI chat is a liability with a clock?
Dr. Jonah Tebaa calls a stored AI chat a liability with a clock because customer conversations holding names, phone numbers, and sensitive health symptoms lose their operational value within weeks while their exposure risk remains constant. In an illustrative composite clinic example where 3,200 WhatsApp chats were held, staff only ever reopened about 600. To resolve this governance gap, he introduces a four-column retention schedule that sorts chats by content sensitivity rather than date.
Most businesses that deploy a customer-facing AI assistant never decide how long its conversations should be stored. The tool decides for them, and the usual answer is forever. Dr. Jonah Tebaa argues that this is a governance gap hiding behind a convenience, and that closing it takes one page of writing rather than a technology project.
A clock nobody set
In his work with service businesses across Lebanon and the Gulf, Dr. Tebaa describes a recurring moment. Someone on the team asks whether old chats can be deleted, and no one can say who chose to keep them. His illustration is a composite clinic whose WhatsApp assistant had stored 3,200 patient conversations over fourteen months. The figures are illustrative, but the pattern, he says, is familiar.
His central claim is that each stored conversation is a liability with a clock. It holds whatever the customer typed: names, numbers, symptoms, images of documents. Its operational value fades within weeks, while the exposure it creates stays constant. In the composite, only about 600 of those 3,200 chats were ever reopened by a person. The remainder, in his phrasing, were risk without a purpose.
Content, not date
Dr. Tebaa objects to the common practice of setting retention by age alone. Two chats from the same week can differ enormously. One asks about opening hours. The other contains a diagnosis. He proposes sorting by what a conversation contains:
- routine questions with no person attached
- personal identifiers such as names, phone numbers and booking details
- sensitive material, meaning health, finance, and photographs of identity documents or payment cards
A chat takes the class of the most sensitive item inside it. That rule keeps the sorting simple enough for a front-desk team to apply.
One row, four answers
The practical instrument in his approach is a retention schedule with one row per data type and four columns of answers. Why is this kept, under a single named purpose? For how many days, and what event ends the period? Who may open it? How is it deleted, and which named person confirms that it happened?
Dr. Tebaa treats a blank cell as a stop sign. If the business cannot state a purpose, a limit, an owner and a witness for a category of data, the category should not yet be stored. He is also specific about the length cell. It should be a number of days with an end trigger, never a phrase such as "as needed."
What the clinic found
Applied to the composite clinic, the schedule left roughly 330 conversations inside their windows, about one in ten, and removed around 2,870. Before deleting, the clinic moved whatever the patient file genuinely required out of the sensitive chats and into the file. The chat, Dr. Tebaa notes, was never supposed to be the record, and that step made the distinction concrete. Checking the 600 chats staff had reopened, the clinic found nearly all of them had been opened within a few weeks of the original conversation. The new windows cost almost nothing that had been used.
He draws a deliberate boundary around this advice. It concerns the content of chats. Records of what an assistant was allowed to do, what it decided and who approved it are a separate keep, with their own owner and their own clock.
Where deletion falls short
Dr. Tebaa cautions that pressing delete in a dashboard is only the visible part. He names three places copies tend to persist: the vendor's backups and logs, spreadsheet exports made for analysis, and staff screenshots shared in group chats. The first calls for a direct conversation with the vendor, including how many days it takes a deleted conversation to leave live systems and backups, and what the vendor retains once the contract ends. The other two call for a short written rule on what staff may export or capture.
He pairs this with a five-line check before launch: the default is delete; no purpose means no storage; identity, health and card images never stay in chat; deletion is tested every quarter; and the customer is told in one line what is kept and for how long. Of these, he regards the quarterly test as the most commonly skipped. A deletion rule that has never been exercised, in his view, is a belief rather than a control.
A caution on scope
Dr. Tebaa is explicit that the day counts in his example are illustrations and that his guidance is not legal advice. Data-protection duties differ across Lebanon and the Gulf states, and he urges owners to check local rules before fixing their own periods. What he asks them to do this week is smaller and more immediate: write the page, fill every cell, and name the person who confirms each deletion. The archive, he suggests, should be something a business chose rather than something it inherited.
