Conversational AI Platforms: Who Keeps the Transcript?

A conversational AI platform is the software that holds a multi-turn conversation with a person, understands intent, and acts on it. The part buyers miss: you also take custody of the transcript, and retention is decided at four hops, not one.

Our position is that transcript custody, not feature depth, is the dimension that decides whether a conversational AI platform survives contact with your legal team. Every buyer's guide we crawled scores platforms on natural language understanding, omnichannel reach, CRM integration and deployment time. None of them asks the question that a data protection officer asks in the first ten minutes: where does the conversation go, who can read it, how long does it live, and can you prove it was deleted. That gap is not cosmetic. It is where the deals die.

A practitioner on Hacker News put the sharp end of it plainly while describing a rollout of AI features on a mental-health platform: "I'm paying very close attention in particular to meeting transcripts" (Ancapistani, 2 April 2025). He was not worried about intent accuracy. He was worried about the artifact the system produces. A written record of a private conversation is both the product's value and its largest liability.

The short answer: Score a conversational AI platform on transcript custody before you score it on conversation quality, because the stateful conversation features you are buying, meaning session memory, thread history and quality scoring, are exactly the features that vendors cannot operate under zero data retention.

Last updated: July 30, 2026.

The custody chain: one conversation, four systems that each decide independently how long to keep it.

What a conversational AI platform is, and what you take custody of

A conversational AI platform is the software layer that runs a multi-turn dialogue with a person across one or more channels (web chat, voice, SMS, WhatsApp, email), interprets intent with natural language understanding (NLU), keeps context across turns, and connects to back-end systems so the conversation can resolve rather than just answer. The category label covers a wide spread of ambition, from a help center widget, through a virtual assistant embedded in a product, to a voice agent that takes payment card details over the phone.

The product you evaluate is the dialogue. The artifact you acquire is the transcript. Every turn a person types or speaks becomes a stored record, and in a conversational setting that record is unusually rich: people volunteer things to a chat window that they would never enter into a form. A support conversation about a declined payment contains a card fragment. A benefits conversation contains a health condition. A voice call to a restaurant contains a name, an address, and a card number. That is precisely what a California plaintiff alleged in the case we come to below.

Three properties make conversation transcripts a different governance problem from documents or database rows.

They are unstructured, so redaction cannot be schema-driven; you have to detect sensitive content in free text as it arrives. They are cumulative, because the platform's value proposition is that it remembers, which means the store grows and the retention clock keeps restarting. And they are multi-party: the person on the other end never signed your vendor's terms and in many cases did not know a vendor was in the call at all.

That third property is the one that converts a procurement question into a legal one.

The question every buyer's guide skips

We crawled the frequently-asked-questions blocks of the four highest-ranking buyer's guides for "conversational AI platform" on 30 July 2026: Lindy, Retell AI, GetVoIP and Infobip. Between them they answer more than two dozen reader questions. Not one asks how long the platform keeps the conversation, where it is stored, who at the vendor can read it, or whether it is used to improve the vendor's models. The closest any of them gets is GetVoIP's "What security certifications should I look for?", which is a question about paperwork rather than about data. Conversational AI platform security, as those pages use the phrase, means a list of certifications, SOC 2 and ISO 27001 among them, held by the company. It says nothing about what happens to a specific sentence a customer typed.

This is not a complaint about other people's articles. It is a description of where the buying process breaks. The evaluation is run by the team that owns the customer experience, using criteria published by the vendors, and it hands a shortlist to a security review that was never given a chance to shape the criteria. The review then asks questions the shortlist cannot answer, and the pilot stalls. Not because the platform was bad, but because nobody scored the dimension that turned out to be binding.

There is some survey support for that reading, with a caveat we will state rather than hide. Rasa's 2026 State of Conversational AI Report found 60% of respondents ranking "black box" concerns or compliance as their single biggest challenge, and 66% requiring on-premise or own-cloud deployment control. The caveat: it is a vendor survey of 30 enterprise leaders, which is a small sample from an interested party. Treat it as a directional signal from people who sell to this buyer, not as a measurement.

Three sources a reader would reasonably expect here are missing for a boring reason: Gartner, Cisco's data privacy benchmark study and ISO's own page for ISO/IEC 42001 all returned 403 to our requests, so nothing from them is cited. The evidence in this article is regulation, case law, and vendor documentation we read directly, each with the date we read it.

The custody chain: four hops a transcript takes

A single customer conversation is not held in one place. In a typical enterprise conversational AI platform stack it exists, simultaneously, in four systems that each make their own retention decision, under their own contract, in their own jurisdiction.

Hop one: the platform's own conversation store. This is what the vendor calls conversation history, threads, or memory. It is the feature you paid for. It is also, in most SaaS defaults, retained until you delete it.

Hop two: the model provider. The platform sends the turn to a model. That provider has its own retention policy for abuse monitoring, its own regional footprint, and its own list of which of its endpoints can be operated with retention switched off. Your contract with the platform does not necessarily bind this hop; the model provider is a sub-processor whose terms you inherit, and the platform's marketing page almost never describes it.

Hop three: the retrieval and grounding subsystems. If the assistant looks something up in a knowledge base, a web search, a maps lookup or a vector store, that subsystem may log the derived query. Some of these logs cannot be disabled, as we show below.

Hop four: the analytics, QA and warehouse layer. Conversation quality scoring, agent coaching, intent-gap analysis, the BI warehouse, the SIEM. This hop is usually configured by a different team than the one that negotiated the contract, and it is where transcripts most often end up somewhere nobody wrote down.

The reason the chain matters more here than in other AI categories is that a conversational system passes the whole conversation through every hop on every turn. A document-processing pipeline hands over one file once. A chat assistant re-sends the accumulated history on each turn to preserve context, which means each hop sees the full transcript repeatedly, and each hop's retention window applies to the full transcript rather than a fragment.

Ask a vendor "do you retain conversations?" and you will get an answer about hop one. That answer is true and nearly useless.

The statefulness tax: why memory and zero retention fight

Here is the mechanism that no buyer's guide explains, and it decides your conversational AI data retention posture more than any contract clause does. It is visible in the model providers' own documentation rather than inferred.

Zero data retention is normally offered for stateless calls. You send a request, you get a response, nothing persists. The moment a platform uses a provider's stateful conversation primitives, meaning server-side threads that hold the dialogue so the platform does not have to resend it, retention becomes structural rather than a setting.

OpenAI's data controls documentation, read on 30 July 2026, states this in a table. Abuse-monitoring logs are retained for up to 30 days by default across the platform, and eligible customers can apply for Modified Abuse Monitoring or Zero Data Retention, subject to prior approval. But the eligibility is per endpoint:

Source: OpenAI platform data controls, read 30 July 2026.

Read the shape of that, not the individual rows. The stateless completion endpoints can be run with zero retention. The endpoints named after conversations and threads, which are the ones a conversational AI platform exists to use, cannot. Their retention is "until deleted," and deletion is an action somebody has to take.

That is the statefulness tax. A platform that gives you a persistent conversation thread with server-side memory is, by construction, running on primitives that hold the conversation. You can still get to a low-retention posture, but only by rebuilding the memory yourself: keep the transcript in your own store, resend the context each turn through a stateless endpoint, and accept the extra tokens and latency that come with it. That is an architecture decision, and it is one you make at evaluation time or not at all. Budget for it properly: resending accumulated context on every turn multiplies input tokens as the conversation grows, and it shifts your latency budget, which voice channels forgive least. Providers reconcile the two pressures with caching rather than storage. Google documents that its published Gemini models cache customer inputs and outputs in memory by default, project-isolated, with a 24-hour time to live, and states that this does not violate zero data retention because nothing is written at rest. Whether your own auditor accepts that distinction is a question worth asking before you rely on it.

The same pattern shows up on the voice side with a different clock. Google documents that session resumption for its live conversational API is disabled by default and, when a developer enables it, caches text, video and audio prompt data along with model outputs for up to 24 hours so the caller can reconnect (Gemini Enterprise Agent Platform and zero data retention, read 30 July 2026). Reconnect-after-a-dropped-call is a feature every voice deployment wants. It has a retention price, stated honestly in the documentation, and invisible in any comparison table.

This is also where an honest note belongs: we have not run a controlled test of these settings across vendor accounts. Everything in this section comes from reading the vendors' own published documentation on 30 July 2026 and reporting what it says, with links so you can check the current version. No LeapForce engineer sat in an admin console and measured deletion latency, and we are not going to imply otherwise.

What the model providers actually commit to

Because hop two is the one buyers cannot see, here is what four major providers published on conversational AI data retention as of 30 July 2026. Every row is from the vendor's own documentation, linked, and dated. These terms change, and a table without a date is worth nothing.

Two of those clauses deserve to be read twice.

Bedrock's documentation states plainly that the obvious-looking switch is not the switch: store=false does not guarantee zero retention, because some models retain data for safety review regardless, and in that case the data is retained but not retrievable by you. It also documents that certain models require retention as a condition of access. One Claude release requires you to opt in to sharing retained traffic with the provider for abuse detection and potential human review, and certain OpenAI models retain classifier-flagged traffic for up to 30 days. A conversational platform that lets you pick a model has therefore given you a control that can silently change your retention posture.

Anthropic's commercial documentation is the clearest example of a default that surprises people. For Team and Enterprise plans, its help centre states that data is retained indefinitely unless an administrator sets a custom retention period, and the minimum period you can set is 30 days. On the consumer side, Anthropic documents that a deleted conversation leaves back-end storage within 30 days, but that if a conversation was flagged by automated trust-and-safety systems, inputs and outputs are kept for up to two years and classification scores for up to seven. That is the asymmetry to internalise: the conversations most likely to be sensitive are the conversations most likely to be flagged, and flagged conversations outlive your deletion by years.

Nothing in the paragraph above is a criticism of these vendors. Their documentation is more specific and more honest than most of the conversational platforms built on top of it. The problem is the layer in between: your platform inherits these terms, resells you an abstraction over them, and rarely tells you which of them it selected on your behalf.

What the law already decided for you

Some of the transcript questions are not yours to answer. Four bodies of law are already binding or shortly will be, and they land differently on conversational systems than on other AI.

You have to say it is AI. Article 50(1) of the EU AI Act requires providers to design systems intended to interact directly with natural persons so those persons are informed they are dealing with an AI system, unless that is obvious to a reasonably well-informed observer (Article 50). The obligation applies from 2 August 2026 under Article 113, and the 2026 Digital Omnibus, which pushed several high-risk deadlines into 2027 and 2028, did not move it. Only the Article 50(2) watermarking requirement got a grace period to 2 December 2026 for systems already on the market. Breach of Article 50 sits in the fine bracket of up to €15,000,000 or 3% of worldwide annual turnover (Article 99(4)(g)). In the United States, the same disclosure instinct appears in state law: California, Colorado and Utah all require consumer-facing bots to disclose in certain circumstances that the consumer is not talking to a human, per Wilson Sonsini's analysis. Our earlier analysis of EU AI Act obligations for deployers works through how the deployer duties differ from the provider ones.

Emotion inference on employees is already prohibited in the EU. Article 5(1)(f) prohibits placing on the market or using AI systems to infer emotions of a natural person in the workplace or in education institutions, except for medical or safety reasons (Article 5). That prohibition has applied since 2 February 2025, and the penalty ceiling for prohibited practices is up to €35,000,000 or 7% of turnover. Read that against the feature list of almost any contact-centre conversational platform, which will happily sell you agent sentiment scoring and emotion analytics on your own staff's calls. Customer-side emotion recognition is a transparency obligation under Article 50(3); employee-side emotion inference in the EU is a different and much shorter conversation.

The vendor's "we learn from your conversations" claim is a litigation exhibit. On 11 August 2025 the U.S. District Court for the Northern District of California declined to dismiss a California Invasion of Privacy Act class action against ConverseNow Technologies, a vendor providing AI voice ordering to restaurants. The plaintiff alleged that her phone order to a Domino's location was routed through the vendor's servers, where her name, address and card details were recorded without her knowledge. The court adopted the "capability" test for third-party status and held the vendor was not merely an extension of the restaurant, because, in the court's reasoning as summarised by Wilson Sonsini, the plaintiff had plausibly alleged the vendor uses caller data to improve its own services, pointing to the vendor's own website and privacy-policy language about a self-learning system that processes millions of live conversations. The court also rejected the argument that a pizza order carries no reasonable expectation of privacy, since payment and identity details were shared.

That decision inverts a marketing claim into a risk. "Our model gets better with every conversation" is a selling point in a demo and an allegation of independent purpose in a complaint. Wilson Sonsini's own recommendation is to either disable and contractually prohibit use of recorded conversations for product improvement and AI training, or to disclose in the announcement that the agent is operated by a third party, while noting that some courts may require both.

Retention is not open-ended, and you cannot contract out of responsibility. GDPR Article 5(1)(e) requires personal data to be kept in identifiable form no longer than necessary for the purpose (storage limitation). And the European Data Protection Board's ChatGPT taskforce report of 23 May 2024 is explicit that controllers should not transfer enterprise risk to data subjects. It names, as an example of what not to do, a terms-and-conditions clause making data subjects responsible for their own chat inputs. That is close to the standard posture of conversational platform terms. Enforcement in this area is real rather than theoretical: Italy's Garante closed its ChatGPT investigation with a €15 million fine and an order to run a six-month public information campaign (press release).

For a fuller treatment of how these obligations are being argued in the privacy community, this 78-minute panel from the Computers, Privacy and Data Protection conference, published in June 2026, is the most directly on-point recording we found. It puts a regulator, two academics and a practising lawyer on what happens to intimate conversational data that is logged, mined, read by employees, requested by law enforcement, or pulled into discovery.

The Transcript Trace: six questions, one afternoon

Call this the Transcript Trace. It is six questions, all six C's, and you can get through them in an afternoon with a vendor solutions engineer, your own architect, and the platform's documentation open. It is deliberately answerable before procurement, because after procurement the answers stop being negotiable.

1. Capture — what enters the transcript, and what is stripped before it is written? Ask for the redaction point, not the redaction feature. Detection that runs after the turn is stored is a cleanup job; detection that runs before egress is a control. Ask what happens to card numbers spoken aloud on a voice channel, where there is no field boundary to key on. Our analysis of inline data-loss prevention at the gateway covers why the placement of that check decides whether it is worth anything.

2. Copies — how many systems hold one? Make the vendor draw the four hops. Name the model provider, the grounding subsystem, the analytics store, the warehouse and the SIEM. Then ask which of those you can enumerate yourself six months from now without asking them. If the answer requires a support ticket, you do not have custody.

3. Clock — what is the retention default per copy, and can you set it? Defaults matter far more than maximums. "Retained indefinitely unless you configure otherwise" and "deleted after 30 days unless you configure otherwise" are the same feature set and opposite risk profiles. Ask specifically for the retention of flagged or moderated conversations, which is routinely longer than the general default and routinely omitted from the summary.

4. Custody — who at the vendor can open a specific conversation, under what process, and is that access logged? This is the question with the highest information yield and the lowest chance of being asked. Azure's documentation describes a real process: flagged content goes to a store, authorised employees reach it through secure workstations with just-in-time manager approval, and for EEA deployments the reviewers are in the EEA. That is a good answer, published. Compare it with what your shortlisted platform can tell you about its own support engineers.

5. Country — where is it stored, and separately, where is it processed? These are different commitments and vendors document them separately. OpenAI's regional endpoints, for instance, list storage and processing as distinct columns, with several regions offering in-region storage while processing happens elsewhere, and the EEA endpoint requiring modified abuse monitoring or zero retention to get in-region processing. A residency requirement written as "data stays in the EU" will not survive that distinction; write it as storage and processing separately.

6. Certainty — what can you prove afterwards? Four proofs, and they are the ones an auditor or a plaintiff's lawyer will want. Can you export one complete conversation, in order, with a defensible claim that nothing is missing? Can you show the AI disclosure was made, on that channel, at that time? Can you show a deletion actually happened rather than that a delete button was pressed? Can you show what the system refused to do, not only what it did? Our work on audit trails for agent actions argues that the last of those is the one most platforms cannot produce, because refusals are not events in most logging designs.

Score each question red, amber or green and carry the sheet into the security review as the first artifact rather than the last. A vendor that answers all six in writing has told you more about its engineering maturity than any demo will.

Four custody postures, scored

The shortlist question is not which vendor. It is which posture you are buying, because the posture caps what any enterprise conversational AI platform on your list can do for you. Four exist in practice.

Posture A — Vendor-retained SaaS

What it is. The platform holds the conversation store, calls a model provider under its own contract, and runs analytics on your transcripts. This is the default configuration of nearly every product sold as a conversational AI platform.

Best for. Low-sensitivity, high-volume conversations where the content is transactional: order status, store hours, appointment reminders, password resets on non-privileged accounts.

What you get. Fastest time to live, usually days to a few weeks. Best conversational quality, because the vendor tunes guardrails and intent models on aggregate traffic. Full feature surface: memory, quality scoring, intent-gap reports, coaching.

What you give up. Enumeration. You cannot list every copy of a transcript without the vendor's help, which means you cannot answer question two of the Trace on your own.

Verdict. Correct for most first deployments and wrong for anything that touches payment, health, employment or credit decisions. The failure mode is not a breach; it is discovering at month five that the training-use clause you accepted is the clause your regulator asks about.

Posture B — Vendor SaaS with retention negotiated off

What it is. The same product, with retention suppressed at each hop: zero retention or modified abuse monitoring at the model provider, minimum retention at the platform, analytics restricted to metadata.

Best for. Regulated conversations you still want to run on a commercial platform: insurance servicing, banking self-service, HR case intake.

What you get. Most of the speed of Posture A with a defensible retention story, and a written record of what you turned off.

What you give up. Features, and more than vendors admit. Server-side conversation memory usually goes, because the endpoints that provide it are frequently not zero-retention eligible. Voice session resumption goes. Quality scoring on transcript content goes. And the negotiation itself takes calendar time: zero-retention controls at OpenAI, modified abuse monitoring at Azure, and abuse-monitoring exceptions at Google are all documented as requiring application and approval, not a toggle.

Verdict. The best value in the set for most regulated buyers, and the posture that most often gets skipped because it is invisible on a pricing page. Ask for it in the first call, not after the pilot.

Posture C — Your tenant

What it is. The platform orchestrates, but the model calls run against endpoints in your own cloud subscription and the transcript store is yours. The vendor sees metadata and configuration, not conversation bodies.

Best for. Organisations with an existing cloud landing zone, a data residency mandate written into contracts, or a works council that will ask who reads employee conversations.

What you get. Enumeration and residency you can prove from your own console. The retention clock becomes your setting rather than a negotiation.

What you give up. Integration work, and a longer path from decision to production. Grounding and retrieval subsystems may still log outside your tenant. Google's documentation is explicit that certain grounding services store derived queries with no option to disable, so "in my tenant" is a claim about the main path rather than the whole path. Verify each subsystem separately.

Verdict. The strongest position per unit of effort for a mid-size regulated deployment, provided somebody owns the boring work of checking the peripheral subsystems.

Posture D — Your infrastructure

What it is. Self-hosted platform, self-hosted or dedicated models, transcripts never leaving infrastructure you operate.

Best for. Data that cannot leave a jurisdiction or a network by law or contract; classified, clinical or sovereign workloads.

What you get. Complete custody, and an answer to every Trace question that does not depend on a vendor's word.

What you give up. Model quality, feature cadence and cost efficiency, in that order. You also acquire an operations burden that is easy to underestimate: model upgrades, evaluation, capacity for peak conversation volume, and a latency budget that voice makes unforgiving. Our comparison of SaaS and own-cloud AI deployment sets out the sequence we think works, and it is a sequence rather than a one-time choice.

Verdict. Right for a narrow set of workloads and over-specified for most. If the reason you want it is "we do not trust the vendor's retention story," Posture C usually gets you the same protection for a fraction of the operating cost.

Choose which: an explicit decision path

Run these in order and stop at the first one that fires.

If the conversation can contain payment card data, health information, or anything that would trigger a breach notification, do not start at Posture A. Start at B and design the redaction point before you design the dialogue. The ConverseNow case involved a pizza order; the aggravating facts were the card number and the address, not the pizza.

If a regulator, a contract, or a works council requires that data stay in a jurisdiction, go to Posture C and write the requirement as two commitments, storage and processing. A single-sentence residency clause will be satisfied by a vendor whose documentation cheerfully distinguishes the two.

If you need server-side conversation memory and you also need zero retention, accept that you are building the memory. Keep the transcript in your store, resend context each turn against a stateless endpoint, and price the extra tokens. This is Posture B or C with an architecture note, and it is the single decision most likely to be made by accident.

If the deployment is employee-facing and any part of the platform scores emotion or sentiment on staff, resolve Article 5(1)(f) before anything else. In the EU that is a prohibition with a 7%-of-turnover ceiling, not a configuration preference.

If none of the above fires, take Posture A, and set a review date. Write into the pilot plan the date on which you re-run the Trace. Conversation scope creeps: a bot that started on store hours ends up taking account numbers within two quarters, and the posture that was right at launch is wrong by then.

If you already have a conversational AI platform in production, run the Trace anyway, and run question two first. Enumeration is the answer that decays fastest: the analytics integration somebody added in month four, the warehouse sync, the new grounding source. Then question three, because retention defaults are frequently changed by the vendor and inherited silently. Fix what the two answers reveal before you touch anything about the dialogue. Retrofitting a redaction point is real work but it is bounded; discovering an undocumented transcript copy during an incident is not.

If you cannot get written answers to questions three, four and five, the vendor is not shortlistable regardless of how the demo went. Not because the answers are necessarily bad, but because a vendor who cannot describe its own retention defaults in writing does not have them under control.

What custody costs, and what getting it wrong costs

We are not going to print platform prices we have not fetched, so what follows is a list of cost lines to add to your model rather than amounts to put in the cells. That is a real limitation and we would rather state it than fill the table with plausible-looking figures. The lines matter because these four are the ones a business case for a conversational AI platform routinely omits, and three of them land on teams that were not in the room when the licence was signed.

Against that, the cost of being wrong has become measurable rather than hypothetical. A CIPA claim against a conversational AI vendor survived a motion to dismiss in August 2025 on facts as ordinary as a phone order. An Article 50 disclosure failure carries an administrative fine ceiling of €15,000,000 or 3% of worldwide turnover from 2 August 2026. A prohibited-practice finding under Article 5 carries €35,000,000 or 7%. Italy's regulator has already issued a €15 million fine in this product category. And the operational cost that arrives first, long before any of those, is a stalled pilot: a security review that cannot be passed with the platform you selected, and a re-procurement six months into a roadmap.

One more asymmetry is worth pricing. Retention costs money in storage and risk; short retention costs money in capability. Quality scoring, intent-gap analysis, and the coaching reports that justify the platform to the contact center director all need transcript bodies. A team that sets retention to the legal minimum and then asks why the analytics dashboards are empty has discovered the tension the hard way.

So do not set one retention policy. Set a body-or-metadata split per data class, and write it down before procurement: which conversation classes keep full bodies and for how long, which keep metadata only, and which keep nothing beyond an outcome code. A payments dispute thread probably needs bodies for the length of the chargeback window. A store-hours enquiry needs an intent label and nothing else. Getting that split on paper is what lets you say yes to the contact center director's quality-scoring request without saying yes to indefinite retention across the whole estate. It is also the artifact that stops the conversation from collapsing into a single all-or-nothing switch.

When the vendor-retained default is still right

The honest counter-position: for a large share of deployments, Posture A is the correct answer and the governance work described above is over-engineering.

If the conversation genuinely cannot contain personal data beyond a name and an order reference; if the channel is a public website widget rather than a voice line; if the vendor's terms already say your traffic is not used for training; if the retention default is finite and documented; and if nobody in the business would notice the difference between a 30-day and an indefinite window, then negotiating a custody posture buys you nothing except delay. The pilot that ships in two weeks and answers 40% of contacts teaches you more about your intent taxonomy than a six-month architecture exercise will.

There is also a case where the incumbent contact center suite beats a specialist conversational AI platform outright on exactly this dimension. If your transcripts already live in a suite you have a data processing agreement with, whose retention you have already configured, and whose residency you have already argued through legal, adding an AI layer inside that boundary is a smaller custody change than introducing a new vendor with a better bot. The best conversational quality on a new custody chain can be worse for the organisation than adequate quality on a chain you have already governed. Buyers routinely underweight that, and vendors never raise it.

And a specific case where our own framing does not help: a genuine emergency. If a support queue is on fire and a bot deflects 30% of contacts starting Monday, deploy it Monday under Posture A, restrict its scope hard, and run the Trace in week three. The framework is for choosing, not for stalling.

Where LeapForce fits, and where it does not

LeapForce does not build a conversational AI platform. We do not sell a chatbot, a voice agent, or a contact center suite, and if you are choosing between the products in those buyer's guides, we are not on the list.

What we build is the layer underneath the question this article is about: one controlled layer for every AI tool, connector, model and agent, so that the custody answers exist in one place instead of being reconstructed per vendor. In gateway terms that means the request lifecycle our AI Gateway describes, running Identify, Check, Protect, Route, Execute and Record in order, puts the identity, the policy check, the sensitive-data handling and the record on the same path as the model call, rather than in four systems owned by four teams. Our published rollout model for that is deliberately unglamorous: observe first, enforce second, optimize third. Point one team's traffic at the gateway in observe mode before writing a single rule, because you cannot set a retention policy for traffic you cannot yet see. On the record side, our Observability and Audit approach treats prompt and response bodies as a policy decision per data class, retained or truncated or redacted or dropped, with audit entries written append-only and integrity-chained so that alteration is detectable. Per-capability build status is disclosed on those pages; read the labels rather than assuming everything described there ships today.

That is the whole bridge. If you are buying a conversational AI platform, buy the best one for the conversation and use the Trace to pick your posture. The governance layer is a separate decision, and it is a reasonable one to defer until you are running more than one AI surface.

Honest limits and open questions

Four places where this analysis is thinner than we would like.

We have not tested any of it. Every vendor fact here comes from published documentation read on 30 July 2026. We did not open accounts, set retention modes, delete conversations and measure when they disappeared. Documentation and behaviour can diverge, and where they do, only a test will tell you. If you run that test, the deletion-latency number is the one worth publishing.

Vendor terms change faster than articles. One of the pages we cite carried an "updated over 4 weeks ago" stamp on the day we read it, and none of them promise stability. Treat every row in the provider table as a pointer to a live page rather than as a fact with a shelf life, and re-read them at contract renewal. If a row here disagrees with the vendor's page when you check, the vendor's page is right and we are stale.

Case law is unsettled and jurisdiction-bound. The ConverseNow ruling is a denial of a motion to dismiss by one district court, and it adopted one of two competing tests for third-party status. Wilson Sonsini's own summary notes that courts have split between that "capability" test and an "extension" test under which a vendor acting for a party is not a third party at all. Which test a court picks decides the case, and no appellate settlement of that split is cited in the material we read. So the ruling tells you the risk is live. It does not tell you how the risk resolves, and none of this is legal advice.

We have no good data on how often this actually kills a deal. The claim that conversational AI pilots stall at the security review is consistent with the survey signal we cited and with the shape of the buyer's guides, but the survey is 30 respondents from a vendor and the buyer's-guide observation is an absence rather than a measurement. If someone has run a proper study of where conversational AI procurement fails, we have not found it. Until then, treat the mechanism as well-evidenced and the frequency as unquantified.

Two open questions we would like answered by people closer to them than we are. First, whether "flagged conversation" retention windows of up to two years for content and seven for classification scores, as documented in one case above, are defensible under storage limitation when the flag was a false positive. Second, whether the "capability" test survives on appeal, because if it does, every conversational platform whose marketing promises it learns from your traffic has a structural problem that no configuration setting fixes.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.