Connecticut CART Act audio provenance: does it reach your TTS app?

Since October 1, 2026, Connecticut's CART Act has required covered providers to include provenance data in audio, image and video content that their generative AI systems create or materially alter. "Covered" is narrow, though: a provider whose system has more than one million monthly users and is publicly accessible to consumers for personal use. A small app that calls a text-to-speech or music API is usually not that provider, but it may still be asked by a customer how its audio is traced.

This post reads the law firm summary below, then lays out what Sume's TTS, STT and Music jobs give you as a record. It is not legal advice, and Sume's docs do not state a compliance position under the CART Act, so ask counsel before you rely on any of this.

Source: Connecticut's AI legislation, part 2, Davis Polk (read 2026-10-03).

What does the CART Act require for AI audio?

Per the Davis Polk summary, the requirements take effect October 1, 2026. Covered providers must include provenance data in any audio, image or video content created or materially altered by their generative AI system. The data is meant to identify authenticity and modification history. Providers must also use commercially and technically reasonable methods to make that data difficult to remove or alter, while letting consumers assess whether content was created or altered by generative AI.

Two limits matter for builders. Purely business-to-business uses are excluded, as are video games, and government agencies are excluded. And unlike California's broader framework, the summary says Connecticut does not require providers to offer a free AI detection tool. The Connecticut Attorney General has exclusive enforcement authority under the state's Unfair Trade Practices Act, with no private right of action; the summary does not give a monetary penalty for these violations.

Is an app built on a TTS or music API a covered provider?

The test in the summary is about the generative AI system and its user count, so the first question is who operates the system. If you ship a consumer app with your own generation system and more than a million monthly users, you are in the territory the law describes. If you call an API for a few thousand customers, or sell only to businesses, you are probably outside it, but the summary is a secondary source and the statute's definitions decide. Treat "probably" as a prompt to ask a lawyer, not as an answer.

The practical risk for smaller teams is indirect. A platform you publish to, or an enterprise buyer, may ask for provenance proof on audio you generated, and a record you can produce quickly is cheaper to build now than to reconstruct later.

What does a Sume audio job record, and what does it not embed?

Every Sume TTS, STT and Music request is a job. The jobs docs describe status, result and events endpoints, and a job belongs to a workspace and to the member whose key created it. A completed TTS or Music job returns a Sume-hosted audio artifact on media.sume.com with a job id, so you can tie any file back to the request that made it. On the Music Router, job.request.routed_model also names the engine that ran, such as lyria-3.5.

What the docs do not say is that Sume embeds a C2PA manifest or its own watermark in audio. The Music Router docs and the OpenAPI reference describe artifacts and metadata, not embedded provenance. So treat a Sume job record as an audit trail you keep next to the file, not as provenance data inside the file. Provider-side marks may exist, and that is a question for the provider's own documentation (see the SynthID post linked below).

What should you log today?

Keep a small ledger per delivered audio file. The point is that you can answer three questions on request: what made this, when, and what happened to it afterwards.

• The Sume job id, the model id you sent, and for music the routed model from the job record.
• The submitted transcript or prompt, or a hash of it, plus the voice or avatar selector you used.
• The artifact URL at the time of generation and the date you generated it.
• Every edit after generation: Timeline audio concat or split jobs and any external editor, with the new file's id.
• The disclosure wording you published with the audio, where a platform or customer requires one.

Does editing the file change the answer?

Yes. Timeline audio joins and slices are ffmpeg runs on Sume's worker, and the docs describe the output as a new durable file, WAV by default or MP3 on request. Sume's docs do not say whether any embedded mark would survive a join or an MP3 encode, so do not assume it does. If a customer needs provenance on the final file, add it at the last step of your own pipeline, after the final edit, and log which tool did so.

Sume does not offer a detection API or a provenance-signing step. If you need one, it comes from a separate tool, and the ledger above is what you hand a reviewer in the meantime.