AI Transparency & Safety Notice
Last updated: 12 September 2025
This page explains, in clear terms, how TringTring uses AI components and how your data flows through our orchestration platform that connects Text‑to‑Speech (TTS), Speech‑to‑Text (STT), Large Language Models (LLMs), diallers/telephony, Meta platforms (e.g., WhatsApp Business), email/SMS gateways and other channels (the “Integrations”).
This notice complements (but does not replace) our Privacy Policy and Data Processing Agreement (DPA). If there is any inconsistency, the DPA prevails for processing we perform as your processor.
What TringTring does (and does not) do with your data
We route and process the data you instruct us to—for example, audio streams, transcripts, prompts, numbers, call/message content and metadata—so that your assistants, agents or automations work across the Integrations you enable.
We do not train TringTring’s own foundation models on your Customer Data.
We minimise data by default. Where feasible, we configure providers to disable retention and model training and to store the minimum necessary logs.
You control which Integrations are used, where possible which region those providers use, and how long Customer Data is kept.
Human access at TringTring is restricted on a need‑to‑know basis for support/security. Access is logged and time‑bound.
What data can reach each Integration?
Below we describe typical data flows. Your actual flows depend on the features you enable and your configuration.
| Integration type | Examples (non‑exhaustive) | Data typically processed | Retention/training at provider |
|---|---|---|---|
| LLM endpoints | Model endpoints you connect via API | Prompts, tool calls, structured state, model outputs | Config‑dependent (many offer “no training / no retention” modes) |
| STT | Speech recognition APIs you configure | Audio snippets/streams, language & timing metadata | Typically transient; check provider settings for retention/training toggles |
| TTS | Voice synthesis APIs you configure | Text prompts, voice selections, prosody settings | Generally transient; may log usage metadata |
| Diallers/Telephony | Plivo (as configured) and carriers | Numbers, call metadata, audio streams/recordings (if enabled) | Carriers may keep logs for legal/operational reasons; recording is your choice and responsibility |
| Meta platforms | WhatsApp Business, Messenger, Instagram | Message content and metadata, template identifiers | Subject to platform policies and retention |
| Email/SMS gateways | Mailchimp and others you enable | Recipient info, message content/metadata | Providers keep delivery logs for deliverability and anti‑abuse |
| Cloud infrastructure | AWS, GCP, Azure, Supabase | Encrypted storage, compute, backups, logs | Regional options vary by your configuration |
Important: Where an Integration allows “no training / no retention”, use those controls if you need them. Some providers may have default retention for abuse/fraud/security that cannot be fully disabled. We disclose known behaviours on our Sub‑processor List and/or in‑product notes.
Recording, monitoring, consent and fair processing
If you record calls or messages, you must provide all required disclosures and obtain consent from participants under applicable law (e.g., two‑party consent jurisdictions), and follow platform rules (e.g., WhatsApp Business templates/opt‑ins). TringTring provides functionality, but you decide when to capture and retain content.
Your controls
Region & retention: choose provider regions where available; set retention or auto‑deletion periods in product (or at the provider).
Training/retention toggles: where a provider offers a no‑training/no‑retention mode, we aim to expose it.
Data export & deletion: export conversation state, logs and recordings; request deletion per workspace/project.
Access management: SSO, MFA, role‑based access controls.
Auditability: admin logs for key events and support‑access trails.
Safety and reliability
Guardrails: configurable prompt templates, tool whitelists, rate limits and content filters.
Testing: allow‑list testing environments and sandbox credentials before production.
Abuse monitoring: anomaly detection on usage patterns to prevent fraud/spam.
Emergency controls: per‑channel kill switches; IP allow/deny lists.
Data we do not want
Please avoid sending special‑category data (e.g., health, biometrics) or other sensitive data unless strictly necessary and lawful. We do not sign HIPAA BAAs by default. For payments, we use Razorpay; we do not store your full card data.
For more details (lawful bases, transfers, rights), see the Privacy Policy and DPA.