Data Processing Agreement

Avrosh is operated by PT Laras Teknologi International, a company incorporated in Indonesia. In this agreement, Avrosh means that company.

You are the controller of the personal data in your account: your customers' messages and calls, your bookings, orders, contact records and consent records. You decide what is collected and why. Avrosh is the processor and acts on your instructions. The AI vendors and platform vendors that run underneath us are sub-processors, and they are named below and on the Security and Trust page.

For your own business account and billing data the relationship is different. There Avrosh is the controller, and the Privacy Policy describes that side.

Two laws apply to this processing at the same time. The GDPR applies to us extraterritorially under Article 3(2), because we offer services to people in the European Union. Indonesia's Law 27 of 2022 on Personal Data Protection applies to us because we are an Indonesian company. We do not treat either as optional, and we do not treat the second as a substitute for the first.

If you have no separately signed agreement, this published agreement together with the Terms of Service is the whole of it, and every number in this document is a public default that applies to you. Activation is arranged with us rather than bought from a page: there is no online checkout, so no account exists that we did not open.

If you need a signed copy, we provide one. The signed version carries the company's registered address in its signature block, along with the standard contractual clauses where they are needed.

We have tried not to defer anything important to a document you may never see. Where a signed agreement can change a figure here, the figure printed here is what applies until it does.

We process personal data for one purpose: to run the service you bought. That means answering your customers by phone and by chat from your own data, taking bookings and orders, logging jobs, routing and escalating to your staff, sending the transactional messages you configure, and operating and securing the account itself.

We do not build advertising profiles. We do not sell personal data. We do not use your content or your customers' conversations to train models of our own.

Processing lasts as long as your account exists. One thing worth saying plainly: an unpaid or cancelled subscription does not switch the service off automatically today. An account whose billing status is overdue keeps serving, which means processing continues until you tell us to stop or delete the business. Whether that becomes an automatic cutoff, and after how long, is an open decision listed at the end of this page.

This is the full inventory, not a summary of the interesting parts. Some of it exists only for certain verticals and stays empty for the rest.

Card details are not on this list because they never reach us. Subscription payments are handled by a payments provider acting as merchant of record, so we hold a subscription status, not a card number.

• Business content you enter: your knowledge base, prices, hours, services, menus, photos, policies, room or chair or provider setup, and staff rosters.
• Conversation content from the QR or link chat. That surface carries no account, no login and no phone number, so nothing personal is required to start a conversation. What a customer chooses to type is what we hold.
• Call records and their written transcripts: the caller's number in international format, the time, the duration, the language, a summary, and the text of what was said on both sides.
• Bookings, appointments, orders, service requests, waitlist entries, and the status history behind each of them.
• Contact records in the CRM spine: name, email address, phone number, language, birthday, free-text notes and visit counts. The hotel room chat never creates one; the contact spine belongs to the verticals where a client returns by name.
• Customer accounts: an email address, the one-time login codes emailed to that address, and session tokens. Codes and tokens are stored only as hashes, and no customer password is ever stored because there is none.
• The consent ledger: append-only records of every grant and withdrawal, including the exact wording the person agreed to, the source and the timestamp. Rows cannot be edited or deleted in place, and a correction is a new row.
• Bank transfer proof images uploaded by your customers when they pay by transfer. These carry names, bank names, account numbers and amounts, and they are stored as files on the application storage in your region.
• Staff accounts: name, email address, role grants and an argon2 password hash.
• Calling lists you supply for outbound campaigns, the consent attestation you record against each list, and the do not call suppression list that overrides them.
• API keys you issue to your own servers. Only a hash and a short recognisable prefix are stored. The key itself is shown once at creation and never again.
• The integration outbox: booking and customer events queued for delivery to the destinations you configure.
• Vector embeddings of your content, used for knowledge base search, with a record of which model produced each one.
• Operational records: audit rows, internal error logs, billing counters and call cost units.

We want this stated the same way in every document, because it is the sentence people misremember in both directions.

No call audio is recorded or stored. Audio exists only in flight, long enough to be transcribed and answered.

A written transcript is stored, and so is a call record holding the caller's number, the time, the duration, the language and a summary. A transcript can contain anything the caller said, which in practice can be more revealing than the recording would have been convenient. Treat it as such.

Because no audio is retained, we cannot produce a recording for a dispute, a quality review or a regulator. If your sector requires call recording, Avrosh does not meet that requirement today.

Avrosh ships dental and clinic verticals. A transcript from those verticals can contain health data, which is a special category under GDPR Article 9 and sensitive personal data under Indonesian law. Saying nothing about that would be the worst available option, so here is the position.

We hold no health-data certification of any kind. We are not a HIPAA business associate, we do not sign business associate agreements, and Avrosh must not be used to process protected health information subject to HIPAA. If your regulator requires a signed BAA or in-region processing of health data, we cannot meet that today and you should not sign.

What you should not put in: diagnoses, clinical notes, test results, insurance identifiers or national identity numbers do not belong in a free-text field, a knowledge base article or a booking note. The product does not need them to book an appointment, and every one of them raises the cost of an incident. Where your vertical needs a clinical record, keep it in your clinical system.

What does protect this data: strict per-business isolation enforced in the database rather than the application, a customer chat surface that collects nothing personal by default, credentials stored only as hashes, and built-in erasure that strips identifiers in place. Voucher and confirmation pages for sensitive verticals are served with no-store, no-referrer and search engine exclusion headers so a shared link does not become a public record.

What does not change: a transcript from a clinic passes through the same AI sub-processors as any other transcript, in the regions named below. There is no separate health-data path, and we will not pretend there is one.

We process personal data only on your documented instructions. Your instructions are this agreement, the Terms of Service, and the configuration you set in the dashboard: what you enter, which verticals and modules you enable, which channels you switch on, who you invite, and which destinations you connect.

If we believe an instruction infringes data protection law, we will tell you rather than quietly carry it out.

We do not use your data for our own purposes, and we do not train models on it. What each AI vendor does with the text sent to it is governed by that vendor's own terms. We have not obtained a contractual no-training and zero-retention commitment from every certified vendor, so we will not claim we have. Obtaining and publishing those commitments is an open item at the end of this page.

Everyone with access to your data is bound by confidentiality, and access is limited to the people who need it to operate and support the service.

Platform administration exists and we would rather describe it than let you discover it. A platform-level connection can read across tenants, which is how support, migrations and billing reconciliation work at all. Those actions are written to the audit log.

One honest limit on that: the platform bookkeeping audit rows are pruned after fourteen days to keep the log bounded, so the record of platform access is not indefinite. Business audit rows, the ones that record what happened in your account, are kept.

These are the measures that exist and can be tested, not a target state.

On the truth firewall, the accurate scope matters. It grounds prices, clock times, durations, arrival estimates, bare hours and calendar months against your own data, on every reply. The check on invented names is narrower: it is a pattern over capitalised English phrases ending in words like Rooms, Suites, Villas or Apartments, so it is effectively hotel only. Salon services, dental procedures, menu items and names in any other language are not name-checked today. The grounding and escalation behaviour still applies to them; the specific name check does not.

We hold no SOC 2 report, no ISO 27001 certificate, no HIPAA attestation and no PCI certification.

• Multi-tenant isolation is row-level security enforced inside the database transaction, not an application filter that a query can forget.
• The owner-scoped helper verifies ownership before it sets the tenant context, so a route that forgets its own permission check still fails closed rather than reading another business's rows.
• Operator and staff passwords are hashed with argon2.
• Session tokens, one-time email login codes and property API keys are stored only as SHA-256 hashes. A database dump therefore contains no usable credential.
• Traffic is encrypted in transit with TLS. Data at rest is protected by the hosting platform.
• The customer chat surface collects nothing personal: no account, no login, no phone number.
• Guest session keys are signed, and session creation and lobby traffic are rate limited per address.
• Confirmation and voucher pages for sensitive verticals are served with no-store, no-referrer and search engine exclusion headers.
• No advertising pixels and no third-party ad trackers, on the marketing site or in any customer chat.
• Application containers run as an unprivileged user, and the database is not exposed to the public internet.

What is actually pruned on a schedule today:

Conversations, chat sessions, call records and their written transcripts have no automatic prune. They live for the life of the account and are removed when the business is deleted. We would rather publish that than publish a retention period no job enforces. A committed period, and the job that enforces it, is an open item at the end of this page.

You can ask us to delete specific conversations, calls or contacts at any time and we will do it.

• Platform bookkeeping audit rows: pruned after fourteen days.
• Internal error logs: pruned after thirty days.
• A deleted business, and soft-deleted catalogue rows: permanently purged after seven days.
• Past booking ranges and stale waitlist entries: pruned nightly.
• Delivered integration outbox events: pruned on a schedule.

These are the AI models that can actually be assigned to a business today. The table on the Security and Trust page is generated from the same configuration the running system picks models from, so it changes when the product changes rather than when someone remembers to edit a page.

Beyond the AI layer, a small set of vendors runs the service. They are listed here by role, and the named vendor for each is confirmed on request rather than guessed in public.

Two things you engage yourself, which are therefore not our sub-processors. If you configure your own mail server, mail leaves through your provider under your agreement with them. If you connect integration destinations, the outbox pushes booking and customer events to systems you chose, and what happens after delivery is governed by your agreement with those systems. In both cases we deliver where you told us to.

Before a new sub-processor starts processing your data we will give the account owner at least thirty days' notice by email. You may object on reasonable data protection grounds. If we cannot resolve the objection, you may terminate the affected part of the service and we will refund the unused portion.

• Language model for chat and classification: Alibaba Cloud DashScope, served from Singapore.
• Language model for voice: Alibaba Cloud DashScope, served from Singapore.
• Speech to text: Soniox, served from the United States.
• Text to speech: Fish Audio. The vendor does not disclose a processing region, and we print that rather than guess one.
• Embeddings for knowledge base search: Alibaba Cloud DashScope, served from Singapore.
• Hosting: application servers and the PostgreSQL database, in your assigned region.
• Payments: subscription billing, as merchant of record.
• Email: transactional mail such as receipts and notifications, where you have not configured your own mail server.
• Telephony carrier: connecting calls to and from the AI, by number country.

Avrosh runs in three regions. Your business is assigned to one, and your application servers, your database and your uploaded files live there. The regions are Northern Virginia in the United States, Singapore, and Frankfurt in the European Union.

A region decides where your servers and your database live. It does not decide where the AI runs, and you should hear that from us rather than from an audit. Every model certified to serve an account today is hosted outside the European Union. A customer assigned to Frankfurt gets a Frankfurt database and an answer path with nothing in the European Union. A customer assigned to Virginia gets a Virginia database while the language model and the knowledge base search are served from Singapore. EU-served models exist in our catalogue and are not yet certified, so they cannot be assigned.

Because Avrosh is operated by an Indonesian company, personal data reaches an entity outside the European Economic Area no matter which region your data sits in. Indonesia has no European Commission adequacy decision. Transfers to us therefore rely on the 2021 Standard Contractual Clauses, controller to processor module, together with a transfer impact assessment. We will enter into them with you, and they are attached to the signed version of this agreement. The UK addendum and the Swiss variant are available on request.

GDPR Article 27 requires a non-EU controller or processor offering services to people in the European Union to appoint a representative in the Union. One is not yet appointed. It is being appointed, and the name and address will be published here when it is. We would rather name the gap than let you assume it is filled.

For a customer who holds an account with your business, export and permanent erasure are built into the product and are a click rather than a support ticket. An export returns their contact record, their bookings, their waitlist entries and their full consent history. An erasure strips every identifier in place while leaving the booking rows you need as business records, and where your branches are grouped it leaves no identifying bytes at any branch, not just the one where the request came in.

An operator-side export of your own business content is not self-serve yet. Ask us and we produce a copy, and we aim to return it within thirty days of the request. This is on the build list rather than in the product, and we will not describe it as a button until it is one.

If one of your customers contacts us directly with a request, we do not answer it on your behalf. We confirm receipt, tell them the business is the controller, and pass it to you.

For rectification, restriction, objection and portability, we assist you with information and with access to the data in a usable form. The decision on the request is yours to make.

If we become aware of a personal data breach affecting data we process for you, we will notify you without undue delay and in any case within seventy-two hours. Notification goes to the account owner's email address, so keep it current.

The notification will describe what happened, the categories and approximate number of data subjects and records involved as far as we can establish them, the likely consequences, and the measures taken or proposed. If we do not have the full picture within seventy-two hours we will send what we have and follow up rather than wait.

Notifying your supervisory authority and your affected customers is your decision as controller. We will support it with information and will not make it for you unless you ask in writing.

One fact that belongs here rather than in a footnote: no cyber liability insurance policy is currently in force. There is no insurer and no limit standing behind this company. A loss is met from the company itself, and our contractual liability cap is the figure stated in the Terms of Service. If your risk assessment requires an insured processor, this is the sentence to take to your counsel before you sign, not after.

The whole sub-processor argument turns on whose law reaches which company, so this section has to exist.

We disclose customer data to a government or law enforcement body only where we are compelled by valid legal process that is binding on us. We do not make voluntary disclosures, and we do not provide direct or unfettered access to any database.

If we receive such a request for data we process on your behalf, we will notify you before responding, unless we are legally prohibited from doing so, so that you can seek to challenge it. Where we are prohibited, we will notify you as soon as the prohibition lapses.

We will challenge a request that is overbroad, that is not valid legal process, or that appears to conflict with the GDPR or Indonesian law, and we will narrow what is produced to what the process actually compels.

We do not publish a transparency count today. Whether we begin publishing one is an open decision, and this section will be updated when it is made.

We hold no SOC 2 report, no ISO 27001 certificate, no HIPAA attestation and no PCI certification. Card data never reaches us because our payments provider is merchant of record, which is why PCI scope sits with them rather than with us.

What we offer instead is direct evidence. This agreement, the generated sub-processor table on the Security and Trust page, a completed security questionnaire, and written answers to specific questions from your security or legal team.

You may audit our compliance with this agreement once in any twelve-month period, at your cost, on thirty days' written notice, under a confidentiality agreement, at a time that does not disrupt the service and not during an active incident. Where a recent audit or questionnaire response already answers your question, we may point you to it instead of repeating the exercise. If a regulator requires more, we will meet the regulator's requirement.

We will make available the information reasonably necessary to demonstrate compliance with our obligations as processor. Where the honest answer is that a control does not exist, that is the answer you will get, in the same words this page uses.

Enterprise questionnaires always ask this, so here is what actually exists rather than a target.

A full database dump is taken manually before a schema migration is applied, and it is kept on the server until it is no longer needed. There is no scheduled, tested backup and restore routine in the deployment configuration today, and no documented recovery time or recovery point objective. We will not describe a continuity programme we do not run.

One consequence worth stating: where a pre-migration dump exists, it can still contain data that was deleted afterwards, until that dump is destroyed. We destroy them once the migration they cover is confirmed good.

Putting a scheduled and verified backup routine in place, with a stated frequency, retention and restore target, is an open item at the end of this page. If backup and recovery guarantees are a condition of your purchase, raise it before you sign.

You can ask for an export of your data at any time, and you should ask before you delete anything, because an operator-side export is not self-serve yet.

Deleting a business marks it deleted and it is permanently purged after seven days. The purge is a database function that removes the business and everything hanging off it: conversations and transcripts, call records, contacts and customer accounts, consent history, bookings and orders, uploaded proof images, the knowledge base and its embeddings, staff accounts and their password hashes, and API keys.

We keep no copy after that, except where a pre-migration dump described above has not yet been destroyed, and except where we are legally required to keep something such as billing records for tax purposes. Billing records are held under our own controller relationship, not this one, and they do not contain your customers' conversations.

On termination, and at your choice, we will delete or return the personal data we process for you. Tell us which, in writing, before the account is removed.

This agreement is governed by Indonesian law.

Disputes are resolved by binding arbitration seated in Singapore, administered by the Singapore International Arbitration Centre, conducted in English.

That combination is deliberate, and the reason is worth a buyer's attention. A judgment from an Indonesian court is not enforceable in the United States or in the European Union, and a judgment from a US or EU court is not straightforwardly enforceable in Indonesia. An arbitral award is enforceable in over 170 countries under the New York Convention, to which Indonesia, the United States and every European Union member state are party. Arbitration is what makes this agreement worth something to you if you ever need to enforce it. Governing law and the seat of arbitration are two different things, and we are not conflating them: Indonesian law governs the contract, Singapore is the seat.

Nothing here removes a data subject's rights under the GDPR or under Indonesian law, or your right to complain to your supervisory authority.

If we change this agreement materially, we will update this page and its date, and we will notify the account owner. Sub-processor changes follow the thirty-day notice above.

Write to hello@avrosh.com for a signed copy of this agreement, the standard contractual clauses, a completed security questionnaire, the named platform sub-processor list, an export of your data, or a deletion request.

If something in this document does not match what you find in the product, tell us. Several sentences on this page exist because a claim was checked and turned out to be wrong, and that is the correction we want.