Privacy Policy

STATUS: DRAFT — FINAL DATA INVENTORY, RETENTION REGISTRY, TRANSFER MECHANISMS AND ACTIVE SUBPROCESSORS MUST BE INSERTED FROM PRODUCTION CONFIGURATION BEFORE PUBLICATION.

SCOPE

This Privacy Policy explains how Solaro Music Production LLC processes personal information in connection with SolaroCall websites, accounts, applications, support, billing, business communications and the SolaroCall AI Phone Agent service. Where SolaroCall processes caller/end-user personal data solely on a business customer’s instructions, the business customer may act as controller/business and SolaroCall may act as processor/service provider for that processing. For account administration, billing, security, fraud prevention, product operations and SolaroCall’s own legal obligations, SolaroCall may process information for its own defined purposes. Roles must follow the actual processing activity, not a blanket label.

INFORMATION CATEGORIES

Depending on features/configuration actually used, SolaroCall may process: - business/account identity and contact information; - user, team, role and authentication data; - subscription, billing references and transaction state (payment card details remain with the authorized payment processor where the implemented payment architecture so provides); - tenant business configuration, services, hours, staff/resources, policies and workflows; - caller identifiers such as phone number and caller-provided name; - conversation/audio data during call processing; - recordings only where the applicable feature/policy authorizes persistent recording; - transcripts, summaries and structured call outcomes where enabled/permitted; - booking/reservation/order/callback/Action Required data; - SMS destination, consent/opt-out and delivery/status data; - customer-provided website URLs and imported/staged business information for entitled Website Import; - support messages and diagnostic information; - device/app/push information; - approximate/structured location or geocoded address data where a configured business workflow requires it; - website analytics, attribution, cookie and advertising identifiers where activated and lawful. Do not state that every category is always collected. Public wording must reflect active features/configuration.

SOURCES

Information may come from: - the customer/business and its authorized users; - callers interacting with the customer’s AI Phone Agent; - integrated services authorized by the customer; - telecommunications/payment/authentication/analytics or other service providers; - websites/content explicitly submitted or authorized for Website Import; - devices/apps and normal website/service interactions.

PURPOSES

Use personal information only for documented purposes such as: - provide/configure/operate the Service; - route/process calls and authorized workflows; - perform bookings/reservations/requests and other tenant-authorized actions; - operate team handoff/callback/notifications; - send permitted SMS reminders/messages; - secure accounts and prevent fraud/abuse; - authenticate users and enforce permissions; - provide support and diagnose incidents; - bill/reconcile subscriptions and payments; - maintain legal/accounting/security records; - improve reliability/quality only under the applicable data-use policy and contractual permissions; - operate analytics/marketing only under the applicable consent/legal basis. Do not claim a broad unrestricted right to train models on customer/caller content unless that use is actually approved, contractually disclosed and lawful. Provider data-use terms must be validated separately. 4.4A LEGAL BASES / ROLE MAPPING For jurisdictions that require a stated legal basis, the final Privacy Policy must map each material purpose/category to the actual applicable legal basis (for example contract/steps at request, legitimate interests where valid, consent where required, or legal obligation). Do not apply one blanket legal basis to every processing activity, and do not rely on consent where the actual product cannot honor withdrawal appropriately. Controller/processor/service-provider roles must be determined per processing activity.

AI / VOICE PROCESSING

SolaroCall uses AI and voice technologies to understand caller requests, generate spoken responses and perform supported workflows. AI systems may make errors. Executable business outcomes depend on authoritative SolaroCall/integrated state, not solely on generated text. The standard launch greeting identifies the caller-facing agent as an AI assistant/AI phone agent and identifies the tenant/business naturally. Applicable local law may require additional AI disclosure. Recording/transcription disclosures/consents are handled separately according to the applicable market/use case.

RECORDING / TRANSCRIPTION

Keep legally and technically distinct: LIVE AUDIO PROCESSING != PERSISTENT AUDIO RECORDING != RUNTIME / TRANSIENT TRANSCRIPTION != STORED TRANSCRIPT != STRUCTURED SUMMARY != HUMAN REVIEW. Persistent raw-audio recording is NOT a universal standard launch default. Unless the applicable versioned jurisdiction/use-case rule is VERIFIED and ACTIVE and every required disclosure, consent, provider, retention, security and entitlement gate passes: PERSISTENT_AUDIO_RECORDING = OFF. A provider-side recording toggle is never legal authority. AI identity disclosure is separate from recording/transcription disclosure and does not automatically satisfy a recording-consent rule. Stored transcript, runtime transcription and summary may have different legal treatment. Public copy must not say “we do not record calls” where a durable transcript or another regulated recording-like activity still requires disclosure under the applicable policy. Exact retention for any stored audio/transcript/summary follows the authoritative RetentionPolicyRegistry and applicable customer/Enterprise policy. No audio/transcript retention duration may be invented.

SHARING / SUBPROCESSORS

SolaroCall may use authorized external providers for AI, voice, hosting/backend, telecommunications, payments, email, authentication, push, storage/media, monitoring, translation, geolocation and analytics according to actual active production configuration. PUBLIC SUBPROCESSOR LIST = only providers that: 1. are actually active in Production; 2. actually receive/process customer/caller personal data for SolaroCall; 3. are verified as acting in the applicable processor/subprocessor role; 4. are approved for that production environment; and 5. have the required contractual/data-processing mechanism where applicable. Technical selection, an account/API key, Dev/Staging use, future fallback status, or appearance elsewhere in V10 does NOT by itself make a provider a public active subprocessor. Payment, telecom/carrier and identity providers may have independent/mixed roles and must not be forced into a “subprocessor” label merely for copy simplicity. Customer-authorized integrations connected to the customer's own account also require role-specific analysis and are not automatically global SolaroCall subprocessors. Privacy/DPA and the public Subprocessor List must read from the same verified production provider-role truth.

INTERNATIONAL TRANSFERS

Where personal data is transferred internationally, use the mechanism required for the relevant transfer, which may include adequacy, applicable standard contractual clauses or other legally recognized safeguards. The final Privacy/DPA must identify the mechanisms actually relied upon for production.

COOKIES / TRACKING

Use one central consent/preference truth tied to the actual Tracking/Tag Integration Registry. Supported/configurable integrations such as GTM, GA4, Google Ads, Meta Pixel and Meta Conversions API are capabilities, not proof that they are active. Where prior consent is required, non-essential analytics/advertising/personalization technologies must not load or transmit until the required consent state exists. Server-side conversion delivery/CAPI is NOT a consent bypass and must obey the same applicable consent/opt-out policy. Where an opt-out regime applies, implement the applicable regional choice and recognized signals such as GPC only when legally triggered. Do not claim “Do Not Sell or Share” is universally applicable, and do not omit it where actual processing/business status requires it. Public provider/cookie information must reflect the real enabled production stack. Do not invent provider usage, cookie names or durations.

DATA RETENTION

The authoritative source is §120.73.2 RetentionPolicyRegistry + actual implementation. Standard current V10 rules: - while an ordinary tenant is active, retain current/future operational data while still needed; - the call that created an appointment, reservation or order, with its details (the caller's number, the address, the AI's note and the notifications), remains visible until the event itself and is erased THE DAY AFTER THE EVENT; - the event itself (its date, time, room or service, number of people and the customer's name) remains visible until the END OF THE MONTH FOLLOWING THE EVENT (the current month and the previous month); - after that, only statistics remain, without any name or number (the number of calls, appointments, orders and similar figures); future appointments and reservations are never erased; - ordinary post-interruption/expiry/cancellation operational data remains recoverable for EXACTLY 30 DAYS, after which it is purged under the active policy if not reactivated. Cancellation is not itself account/tenant deletion, privacy deletion, number release or legal hold. Financial, tax, security, audit, dispute, telecom/KYC/regulatory and other records subject to separate legal/contractual requirements are NOT blindly forced into the 30-day operational purge. Recordings, transcripts, summaries, support, security/auth events, financial/tax records, KYC/regulatory records, audit logs, analytics, backup residual lifecycle and Enterprise custom retention require their own approved policy values. No “common” numeric duration may be invented. Backups are subject to a bounded residual lifecycle and are not a hidden permanent archive.

RIGHTS / REQUESTS

Provide the privacy rights required by the person’s applicable jurisdiction and SolaroCall’s role, including where applicable access, correction, deletion, restriction, objection, portability, consent withdrawal and statutory opt-out mechanisms. Where SolaroCall is processing on a tenant’s behalf, requests concerning tenant-controlled caller data may need to be routed/coordinated with the relevant tenant/controller.

SECURITY

Describe safeguards factually: tenant isolation, access controls, secret management, authentication/MFA where implemented, encryption in transit/at rest where actually implemented, logging/audit, incident response and backup/recovery controls. Never claim an unearned certification.

CHILDREN

SolaroCall account ownership/administration is for business-capable users under the account eligibility policy. The public Privacy Policy should state that SolaroCall is not directed to children as a consumer service. Caller interactions involving minors require the applicable tenant/jurisdiction policy; do not assume every caller is an adult.

CHANGES / CONTACT

Version/effective-date the Privacy Policy. Verified mailing identity: Solaro Music Production LLC 30 N Gould St Ste N Sheridan, WY 82801 United States Publish a Privacy email/route only when a real monitored destination is configured. A logical privacy@solarocall.[domain] alias may be used after activation; do not invent/assume it is active. Privacy requests must have at least one stable public route and, where applicable, support access, correction, deletion, export, objection/restriction and consent withdrawal with proportionate identity verification.