Retention and Deletion for AI Meeting Notes

Nobody picks a retention period until somebody asks for one

The adoption path for an AI notetaker is almost always the same. One person tries it on a call. It is obviously better than typing while listening, so it spreads sideways through the team. Six months later a large share of the company's customer calls, planning sessions, one-on-ones, and vendor negotiations exist as searchable text inside a tool that nobody has written a policy for.

Then a question arrives from outside the normal workflow. A customer asks what happens to the recording of their call. A candidate asks whether the interview notes are kept. Legal asks what would be in scope if a dispute went to discovery. Somebody leaves the company and asks for their one-on-one history to be removed. Every one of those questions has the same shape: how long do you keep this, and what happens when someone wants it gone.

The honest answer, for most teams, is that nobody decided. There is no retention period because a retention period was never set, and the absence of a decision quietly resolves to the most aggressive possible policy: keep everything, forever, at full fidelity. That is not a neutral default. It is the one setting a team would almost never choose deliberately.

This is worth fixing before someone forces the issue, and not primarily for the reason people expect.

Forever is a retrieval bug before it is a legal one

The compliance argument for deletion is well rehearsed and mostly persuasive. It is also not the argument that gets a retention schedule written, because compliance risk is abstract until it is acute. The argument that actually lands with operators is that an unbounded archive degrades as a memory system.

Work memory is valuable because retrieval returns the thing you needed. A pile of every sentence ever spoken at the company is not that. When a search for a pricing decision returns the current policy, the superseded version from two quarters ago, and an exploratory conversation that never became a decision, all with roughly equal confidence, the operator has to re-adjudicate history before they can act. The archive has shifted cost onto the reader rather than removing it.

Stale context is worse than missing context in one specific and dangerous way: missing context announces itself. You search, find nothing, and go ask someone. Stale context arrives looking exactly like current context, with the same formatting and the same apparent authority, and it is only wrong about time. A team that has been burned once by acting on a superseded decision starts distrusting the whole system, and a memory system nobody trusts is a memory system nobody uses.

So retention is not a tax on the useful thing. It is part of the useful thing. Deciding what expires is how you keep the recall precise, and the legal argument and the quality argument happen to point in exactly the same direction, which is a rare and convenient alignment.

What the rules actually ask for

For teams operating under the GDPR, the relevant text is shorter and less exotic than the compliance discourse around it suggests. The storage limitation principle in Article 5(1)(e) requires that personal data be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed. The neighbouring data minimisation principle in Article 5(1)(c) requires that the data be adequate, relevant and limited to what is necessary in relation to those purposes.

Notably, neither line hands you a number. There is no statutory ninety days. The obligation is to tie the period to the purpose, and then, under the accountability requirement in Article 5(2), to be able to demonstrate that you did. Recital 39 makes the practical expectation explicit: time limits should be established by the controller for erasure or for a periodic review, ensuring that the period for which the personal data are stored is limited to a strict minimum.

Article 30(1) then pushes it into writing. Among the things a record of processing activities must contain is, where possible, the envisaged time limits for erasure of the different categories of data. That phrasing rewards a policy that distinguishes categories rather than one blanket number, which is also what produces a better memory system.

Article 17 supplies the other half. The data subject has the right to obtain erasure without undue delay on several grounds, including that the data is no longer necessary for the purposes for which it was collected, or that consent has been withdrawn and no other legal basis applies. Article 17(2) adds the part teams routinely underestimate: where the data has been made public, the controller must take reasonable steps, including technical measures, to inform other processors that erasure has been requested, covering links to and copies or replications of that data.

None of this is legal advice, and the specific answer depends on the jurisdictions a team operates in and the purposes it has actually documented. But the structural demand is clear enough to design against: categories, periods tied to purposes, written down, reviewed, and a deletion path that reaches copies.

Captured context does not have one half-life

The single biggest improvement most teams can make is to stop treating the output of a meeting as one artifact. It is at least four, and they have wildly different value curves and different risk profiles.

Raw audio and video are the highest-risk, fastest-decaying tier. They carry tone, background conversation, and every incidental disclosure that nobody meant to record, and their marginal value over a good transcript collapses within days of the meeting. A tool that discards them by default is making the right trade rather than cutting a corner. Driffle transcribes audio in real time and discards it, retaining the resulting text and the notes you write, not the raw recording.

Verbatim transcripts are the next tier. They are genuinely useful for a short window, when someone needs the exact phrasing a customer used or wants to check what was actually promised. After that window their value drops sharply while their volume and sensitivity do not. A transcript is the tier where a defined, relatively short period does the most good for the least cost.

Structured notes and summaries hold their value considerably longer, because they are already the compressed form. Decisions, commitments, and their owners hold value longest of all, and often need to outlive both the meeting and the person who made them, which is the entire premise of institutional memory. A decision record with a date, an owner, and the reasoning is the artifact you most want in two years and the one that costs the least to keep.

• Raw audio and video: shortest period, highest sensitivity, fastest value decay
• Verbatim transcripts: short defined window for exact phrasing and disputes
• Notes and summaries: medium period, the compressed and most reusable form
• Decisions, commitments, and owners: longest period, the institutional memory

A retention schedule you can actually operate

A schedule fails when it is too clever to run. The version that survives contact with a real team is short enough to fit on one page, expressed in categories rather than individual tools, and owned by a named person with a calendar reminder.

Start by writing down the categories from the previous section and, for each one, the purpose that justifies keeping it. Purpose first, then period, in that order, because a period without a stated purpose is the thing you will be unable to defend later and also the thing you will be unable to revise sensibly. If you cannot articulate what a category is for, that is the finding, and the period should be short.

Then handle the exceptions explicitly rather than by accident. Some meetings need a longer period because of contractual or statutory obligations. Some need a shorter one because of what they contain: interview notes, performance conversations, and anything involving employee relations deserve their own line rather than inheriting the general default. Legal hold has to be able to override the schedule, and if it cannot, your schedule will eventually delete something it should not have.

Finally, set a review cadence and treat it as real. Recital 39's framing of erasure or periodic review is a useful reminder that a schedule is not a one-time artifact. Purposes change, tools change, and a policy written for a five-person team stops fitting at fifty. An annual review with the owner named is enough for most teams and is dramatically better than the alternative, which is a policy document that describes a company that no longer exists.

Deletion has to reach the copies

The gap between a deletion policy and actual deletion is where most of the real exposure lives. Removing a record from the primary store while its derivatives survive elsewhere produces something worse than no deletion at all: a team that believes the data is gone and behaves accordingly.

The copies are rarely hidden, just unglamorous. Search indexes and vector embeddings derived from the text. Exports somebody generated for a board pack. Summaries pasted into a project tracker, a shared doc, or a chat channel. Automated digests that forwarded the content into email. Backups, which by design resist deletion and are the reason a same-day promise on backups is usually a false one.

This is exactly the ground Article 17(2) covers when it requires reasonable steps, including technical measures, to inform other processors that erasure has been requested, including with respect to links to and copies or replications of the data. Read as engineering guidance rather than legal text, it says: know where the derivatives went, and have a mechanism that reaches them.

It also means deletion promises should be specific about mechanism and honest about timing. Driffle removes individual notes immediately, and full-account deletion clears the data within 30 days including backups, with a receipt shown for the deletion. The thirty-day window for backups is not a hedge to be embarrassed about; it is what deleting from backups actually takes, and a vendor claiming instantaneous erasure everywhere is either not counting backups or not telling you about them.

The four ways this goes wrong

Retention by vibes is the most common failure. There is no written schedule, so the effective policy is whatever each tool's default happens to be, which differs per tool and changes silently when a vendor updates their terms. The tell is that nobody can answer the retention question without opening a settings page.

The overcorrection is the second failure, and it usually follows the first by about a week. Somebody gets alarmed, a thirty-day delete-everything rule goes in across the board, and six months later the team cannot reconstruct why a pricing decision was made or what was actually promised to a customer in a renewal call. Aggressive deletion is not automatically the conservative choice; it just moves the risk from disclosure to amnesia. The tiering exists precisely so that decisions can outlive transcripts.

The third is the shared-record problem, and it is genuinely hard. A one-on-one contains two people. A customer call contains your team and theirs. When one participant asks for erasure, the record is not cleanly theirs to remove, and a naive implementation either refuses the request or destroys someone else's legitimate record. Deciding in advance how you handle partial erasure in a shared artifact is much easier than deciding it while someone is waiting for an answer.

The fourth is treating consent and retention as the same control. They are not. Consent governs whether you may capture at all; retention governs how long you keep what you captured. A team can be scrupulous about announcing capture and still hold every transcript indefinitely, and that combination is common enough to be worth naming. Announcing capture is a courtesy at the start; a retention period is the commitment that follows it.

What to ask before you standardise on a tool

Most evaluations of meeting tools compare summary quality and integrations, which are the easiest things to demo and the least durable basis for a decision. Retention behaviour is harder to demo and much harder to change once a year of company context lives inside the tool. These questions are worth asking early, of every vendor on the list.

Ask them in writing, and treat a vague answer as an answer. A vendor that cannot tell you what happens to raw audio, or that answers the deletion question with a marketing sentence about being secure, has told you something useful about how much thought has gone into the part you cannot see.

• What happens to raw audio and video, and how soon, by default rather than on request
• Which retention periods are configurable, at what granularity, and by whom
• What deletion actually removes, including search indexes, embeddings, and exports
• How long deletion takes to reach backups, stated as a number rather than a posture
• Whether a deletion receipt or audit record is produced and who can see it
• How a single participant's erasure request is handled inside a shared record
• Whether content is used for model training, what the default is, and how to change it
• Whether a bot joins the call, since a bot creates a second copy in a second system

Capture design decides how hard retention is

There is a structural point underneath all of this. How a tool captures determines how many places the data ends up, and therefore how hard the retention and deletion problem is for the rest of its life.

A meeting bot that joins the call as a participant creates a recording artifact in the conferencing platform's world as well as its own. That is a second system with its own retention behaviour, its own admin, and its own deletion path, and reconciling the two is the team's problem rather than the vendor's. Capture that does not join the call as a bot removes that second copy from the picture entirely, which is a retention benefit before it is a UX one.

The same logic applies to whether capture is continuous or deliberate. A tool running in the background collecting whatever it sees produces an archive full of material nobody intended to keep, and every line of that archive is now subject to whatever schedule you write. Driffle never auto-joins meetings, auto-records, or runs in the background: you hit a button and it works, you close it and it stops. Less incidental capture means a smaller archive, which means a retention schedule that is easier to write and a deletion path that is easier to actually execute.

The takeaway for anyone about to write their first schedule: decide the categories, tie each period to a stated purpose, make sure decisions outlive transcripts, verify that deletion reaches the derivatives, and name an owner and a review date. That is a one-page document, and it does more for the quality of a team's work memory than another round of tuning summary prompts.