Rivya가 무엇을 저장하는지, providers가 prompts, uploads, outputs, metadata를 언제 process할 수 있는지, sensitive data를 어떻게 다룰지 이해하세요.

Rivya에서 prompts, uploads, outputs, history, provider-routed requests에 어떤 일이 일어나는지 plain-language view가 필요할 때 이 data processing guide를 사용하세요.

이 guide는 Rivya의 현재 product와 policy language가 data handling을 어떻게 설명하는지 다룹니다.

The Short Answer

Rivya는 product를 실행하고 workspace continuity를 유지하는 데 필요한 prompts, uploads, outputs, history, related records를 저장합니다.

Rivya는 service의 일부를 운영하기 위해 third-party providers에도 의존합니다.

이는 다음을 의미합니다.

your data가 isolated page 하나에만 있는 것은 아닙니다
prompts, uploads, outputs, metadata는 요청한 workflow를 제공하는 과정에서 process될 수 있습니다
highly sensitive information은 casual하게 submit하지 않는 것이 좋습니다

What Rivya Stores To Run The Product

현재 Privacy Policy에 따르면 Rivya는 다음과 같은 information을 저장할 수 있습니다.

제출한 prompts, instructions, chat messages
uploaded reference media, related file URLs, upload metadata
generation parameters와 workflow settings
model, tool, workspace selections
output URLs, result metadata, task status records
chat session history, message history, attachment URLs, usage metadata
AI runs와 연결된 credit settlement와 refund records

Rivya는 session records, IP address, browser and device data, locale settings, 그리고 security와 service reliability에 사용되는 logs 같은 technical and security information도 collect할 수 있습니다.

Why Rivya Stores That Information

현재 policy는 이 information이 다음에 사용될 수 있다고 설명합니다.

account 생성 및 관리
sign-in 인증과 account access 보호
billing, credits, subscriptions, payment support 제공
generation requests, chat requests, uploads, requested outputs 처리
generation history, chat history, workspace continuity 유지
service, billing, support, newsletter-related communications 발송
abuse, fraud, misuse, technical failures 조사
product quality, reliability, support operations, user experience 개선

실무적으로 읽으면, Rivya가 data를 저장하는 이유는 product가 one-off outputs만이 아니라 saved continuity, billing, task history를 중심으로 설계되어 있기 때문입니다.

Which Providers May Process Data

현재 policy에 따르면 Rivya는 다음과 같은 providers에 의존할 수 있습니다.

billing, checkout, subscriptions, payment-related records를 위한 Stripe
AI generation, chat routing, media uploads, related task processing을 위한 third-party AI infrastructure
account, contact, newsletter-related emails를 위한 Resend
uploaded avatars와 stored files를 위한 S3-compatible storage providers
해당 sign-in methods를 선택한 경우 Google, GitHub, 또는 Discord
service 운영에 사용되는 infrastructure, hosting, monitoring, security vendors
특정 deployment에서 enabled된 경우 optional analytics, captcha, affiliate, support-widget providers

policy는 third-party AI infrastructure를 통해 routed된 AI requests가 사용하는 workflow에 선택된 upstream model 또는 infrastructure providers를 포함할 수 있다고도 설명합니다. 단, 이는 해당 workflow를 complete하기 위한 범위입니다.

What This Means For Prompts, Uploads, and Outputs

실무적으로는 다음과 같습니다.

prompts와 chat messages는 요청한 response를 generate하기 위해 process될 수 있습니다
uploads는 generation, editing, 또는 related workflow steps를 complete하기 위해 process될 수 있습니다
outputs, task records, history는 product가 saved continuity를 지원할 수 있도록 account와 연결된 상태로 유지됩니다

현재 policy는 다음도 note합니다.

AI generation을 위한 reference files는 현재 Rivya endpoints를 통해 generation uploads에 사용되는 third-party AI infrastructure로 uploaded됩니다
avatar uploads는 현재 service에 configured된 S3-compatible storage로 전송됩니다

How To Think About The Training Question

여기서 Rivya의 public policy language는 product가 무엇을 저장하는지, service를 운영하기 위해 어떤 providers가 requests를 process할 수 있는지에 초점을 둡니다.

이 page는 해당 operational boundary를 넘어 모든 provider가 동일한 retention, review, secondary-use rules를 갖는다는 blanket product promise를 만들지 않습니다.

no-training 또는 no-retention guarantee가 workflow에 critical하다면 safe reading은 다음과 같습니다.

marketing shorthand만으로 가정하지 마세요
사용하려는 workflow의 relevant provider terms를 검토하세요
해당 processing path에 comfortable해질 때까지 sensitive information 제출을 피하세요

이는 practical caution이지 새로운 legal claim이 아닙니다.

현재 Privacy Policy는 가능하다면 sensitive personal data, confidential material, protected information을 submit하지 말라고 설명합니다. 단, 자체 internal requirements를 검토했고 third-party processing의 operational risks를 받아들일 수 있다고 판단한 경우는 예외입니다.

이것이 여전히 가장 안전한 practical rule입니다.

Retention and Deletion

현재 policy는 Rivya가 필요한 것보다 오래 information을 보관하지 않으려 하지만, 실제 operational, legal, billing, security, fraud-prevention, abuse-handling, support, backup, provider-side processing reasons 때문에 retain할 수 있다고 설명합니다.

또한 다음도 설명합니다.

Settings > Security에서 account를 delete하면 Rivya의 primary database에서 account-linked records는 일반적으로 cascading basis로 removed됩니다
billing, fraud prevention, abuse handling, legal obligations, backups, provider-side processing, security logs에 필요한 일부 limited records는 여전히 retained될 수 있습니다

즉 deletion은 meaningful하지만 모든 operational layer에서 항상 instantaneous하거나 absolute한 것은 아닙니다.

Where To Check Next

이 question과 관련된 main public hub pages를 가까이에 두고 싶다면 다음을 보세요.

product와 first-session path를 plain language로 설명하는 companion reads가 필요하면 다음을 읽어보세요.

related trust and policy pages가 필요하면 다음을 읽어보세요.

uploads와 live product scope의 execution boundary가 필요하면 다음을 읽어보세요.

Data Review Checklist

prompts, uploads, outputs를 provider-backed workflow로 보내기 전에 확인하세요.

input에 confidential, regulated, personal, client, 또는 third-party material이 포함되는지 결정하세요.
task에 upload가 필요한지, text-only summary가 더 안전한지 확인하세요.
sensitive files를 공유하기 전에 selected workflow의 provider touchpoint를 검토하세요.
source ownership, consent, commercial-use rights를 generation quality와 분리해서 판단하세요.
binding terms는 legal pages를 사용하고, 이 guide는 practical product behavior를 이해하는 데 사용하세요.

Recheck When Data Sensitivity Changes

real people, voices, client documents, unreleased brand assets, medical/legal/financial context, 또는 organization을 떠나서는 안 되는 material을 추가할 때 다시 확인하세요.

Rivya Data and Provider Processing Guide