Understand what Rivya stores, when providers may process prompts, uploads, outputs, and metadata, and how to handle sensitive data.

Use this data processing guide when you need a plain-language view of what happens to prompts, uploads, outputs, history, and provider-routed requests in Rivya.

It explains how Rivya's current product and policy language describes data handling.

It does not replace the binding language in Privacy Policy or Terms of Service.

The Short Answer

Rivya stores the prompts, uploads, outputs, history, and related records needed to run the product and keep the workspace connected.

Rivya also relies on third-party providers for features that are actually enabled and for workflows that you choose to run.

That means:

your data is not only sitting in one isolated page
prompts, supported uploads, outputs, and metadata may be processed by the providers needed to deliver the runnable workflow you asked for
highly sensitive information should not be submitted casually

What Rivya Stores To Run The Product

According to the current Privacy Policy, Rivya may store information such as:

prompts, instructions, and chat messages you submit
uploaded reference media, related file URLs, and upload metadata
generation parameters and workflow settings
model, tool, and workspace selections
output URLs, result metadata, and task status records
chat session history, message history, attachment URLs, and usage metadata
credit settlement and refund records connected to AI runs

Rivya may also collect technical and security information such as session records, IP address, browser and device data, locale settings, and logs used for security and service reliability.

Why Rivya Stores That Information

The current policy says this information may be used to:

create and manage your account
authenticate sign-in and protect account access
provide billing, credits, subscriptions, and payment support
process generation requests, chat requests, uploads, and requested outputs
maintain generation history, chat history, and workspace continuity
send service, billing, support, and newsletter-related communications
investigate abuse, fraud, misuse, or technical failures
improve product quality, reliability, support operations, and user experience

The practical reading is that Rivya stores data because the product is built around saved continuity, billing, and task history, not only one-off outputs.

Which Providers May Process Data

The current policy describes provider categories that apply only when the related feature is enabled or used. Depending on the deployment and your actions, those providers may include:

Stripe when you use billing, checkout, subscriptions, or payment-management features
third-party AI infrastructure selected for a runnable generation, chat, or supported media workflow you submit
the configured email delivery provider when Rivya sends an authentication, account, contact, support, or newsletter email
configured storage providers when an enabled upload or stored-file feature uses them
Google when you choose Google sign-in
GitHub or Discord only when the deployment exposes those legacy sign-in methods and you choose one
infrastructure, hosting, monitoring, or security vendors used to operate the service
an analytics, captcha, affiliate, or support provider only when that specific integration is configured and active in the deployment

The presence of an optional integration in the codebase does not mean that it is active in every deployment or processes every user's data. AI requests routed through third-party AI infrastructure may involve the upstream model or infrastructure providers selected for the runnable workflow you use, but only as part of completing that workflow.

What This Means For Prompts, Uploads, and Outputs

In practical terms:

prompts and chat messages may be processed to generate the response you requested
supported uploads may be processed to complete the runnable generation, editing, or related workflow step you selected
outputs, task records, and history stay connected to your account so the product can support saved continuity

The current policy also notes:

reference files submitted to a supported runnable model are uploaded through Rivya endpoints to the third-party AI infrastructure used for that generation workflow
avatar or stored-file uploads use the storage provider configured for the enabled feature

A visible model or status page does not mean that its processing workflow is currently available. In particular, the documented Audio Isolation and ElevenLabs Sound Effect V2 entries are paused and cannot currently start tasks or accept workflow uploads through Rivya.

How To Think About The Training Question

Rivya's public policy language here focuses on what the product stores and which providers may process requests to operate the service.

It does not create a blanket product promise on this page that every provider has identical retention, review, or secondary-use rules beyond that operational boundary.

If a no-training or no-retention guarantee is critical for your workflow, the safe reading is:

do not assume it from marketing shorthand alone
review the relevant provider terms for the workflow you plan to use
avoid submitting sensitive information until you are comfortable with that processing path

That is a practical caution, not a new legal claim.

Sensitive Data Guidance

The current Privacy Policy says that, if you can avoid it, you should not submit sensitive personal data, confidential material, or protected information unless you have reviewed your own internal requirements and are comfortable with the operational risks of third-party processing.

That is still the safest practical rule.

Retention and Deletion

The current policy says Rivya tries not to keep information longer than needed, but may retain it for real operational, legal, billing, security, fraud-prevention, abuse-handling, support, backup, or provider-side processing reasons.

It also says:

if you delete your account from Settings > Security, account-linked records in Rivya's primary database are generally removed on a cascading basis
some limited records may still be retained where necessary for billing, fraud prevention, abuse handling, legal obligations, backups, provider-side processing, or security logs

That means deletion is meaningful, but not always instantaneous or absolute across every operational layer.

Where To Check Next

If you want the main public hub pages around this question, keep these nearby:

If you want the companion reads that explain the product and the first-session path in plain language, read:

If you want the related trust and policy pages, read:

If you want the execution boundary around uploads and live product scope, read:

Data Review Checklist

Before sending prompts, uploads, or outputs through a provider-backed workflow, check:

Decide whether the input contains confidential, regulated, personal, client, or third-party material.
Confirm whether the task requires upload, or whether a text-only summary would be safer.
Review the provider touchpoint for the selected workflow before sharing sensitive files.
Keep source ownership, consent, and commercial-use rights separate from generation quality.
Use the legal pages for binding terms; use this guide for practical product behavior.

Recheck When Data Sensitivity Changes

Recheck when you add real people, voices, client documents, unreleased brand assets, medical/legal/financial context, or material that should not leave your organization.

Rivya Data and Provider Processing Guide