Government and law enforcement requests

Avrosh is operated by PT Laras Teknologi International, a company incorporated in Indonesia. That is the entity an order would be served on, and the entity that would have to answer it.

Indonesian law reaches us directly. Indonesia's Personal Data Protection Law, Law 27 of 2022, in force since October 2024, applies to us, and so does Indonesian legal process. A properly issued Indonesian order is one we would have to respond to. We are not going to pretend otherwise on a trust page.

Most of our customers are in the United States and the European Union, so GDPR applies to us under Article 3(2). A United States or EU authority does not hold direct compulsory power over an Indonesian company. In practice it has two routes: mutual legal assistance through Indonesian authorities, or serving one of our sub-processors in that vendor's own country. The second route is the one worth understanding, and it is the next section.

Your counsel will also ask about Article 48 GDPR. An order from a court or an authority outside the EU is not by itself a lawful basis to disclose EU personal data; it has to arrive through a mutual legal assistance treaty or a comparable instrument. We treat that as binding on us. Indonesia has no EU adequacy decision, so transfers of EU personal data to us rest on Standard Contractual Clauses and a transfer impact assessment, and an authority demand does not get to route around either.

One distinction, because the two get conflated. A dispute between you and us is settled by binding arbitration seated in Singapore under SIAC rules, in English, while the contract itself is governed by Indonesian law. The seat and the governing law are different things. That clause exists because an arbitral award is enforceable in more than 170 countries under the New York Convention, to which Indonesia, the United States and every EU member state are party, while an Indonesian court judgment would not be enforceable against us in your country. None of that changes what an authority can compel, which is what the rest of this page is about.

Your application servers and your database live in the region you are assigned: Northern Virginia, Singapore or Frankfurt. Hosting is a sub-processor, and a hosting company is reachable by the authorities of the country it operates in.

The region does not decide where the AI runs, and this is the part a procurement team should hear from us rather than discover later. Every model certified to serve an account today is hosted outside the European Union: the language models and the knowledge base search are served from Singapore, speech to text from the United States, and our speech vendor does not disclose an origin. So the text of a conversation, a call transcript included, passes through vendors in Singapore and the United States whatever region your database sits in. EU-served models exist in our catalogue and are not yet certified, so they cannot be assigned to a business.

That matters here. An authority that cannot compel us may be able to serve one of those vendors directly, and if it does, we may never learn of it. We do not control what a vendor retains and we will not imply an end to end guarantee we cannot give. If retention at a specific vendor is material to you, ask before you sign and we will tell you what we know and what we do not.

The named vendor behind each role, AI and platform alike, is confirmed on request at hello@avrosh.com.

We do not volunteer customer data. Nothing is handed over because an official asked politely, because a request was framed as urgent, or because it arrived from a government address.

To act on a request we need all of the following.

We do not grant standing access, bulk access, direct query access, or an interface of any kind to any authority. There is no such access to grant and we will not build one.

Where the data belongs to one of your customers and we hold it as your processor, our first answer is to direct the authority to you, unless the law requires otherwise. It is your record, you are better placed to answer for it, and the decision should be yours to make.

• Process validly issued by an authority with jurisdiction over us, and validly served.
• The identity of the requesting authority and of the person who signed it.
• The specific account, business, phone number or record sought, and the time period.
• A legal basis we can read, so we can judge whether the demand actually reaches the data it names.

If we receive a request for data belonging to your business or your customers, we notify you. Where it is possible we notify you before anything is disclosed, so that you can seek to challenge it yourself.

We withhold notice only where a court order, a statute, or a valid non-disclosure obligation prohibits it. When such a prohibition expires or is lifted, we notify you then.

We have not fixed a public deadline for that notice. Rather than invent a number that reads well, it is one of the open items listed at the end of this page. If a committed notice window matters to your procurement, tell us and we will settle it in writing with you.

We challenge or seek to narrow a request that asks for more than the matter justifies, that is served on the wrong entity, that lacks a signature or an identifiable issuing authority, or that reaches across accounts rather than the one account under investigation.

We produce the narrowest set of records that answers what was actually ordered. A demand for one booking does not become a handover of a conversation history.

Where we believe an order conflicts with Article 48 GDPR or with the Indonesian Personal Data Protection Law, we say so and ask the authority to use the lawful route instead.

Honesty before the list. Avrosh is not a zero knowledge system. Data at rest is protected by the hosting platform, not by keys that only you hold, so under lawful compulsion we could technically read your business data. Row level security in the database stops one business reading another business's rows; it is not a defence against an order served on us. Say that plainly, or the rest of this page is decoration.

What exists to be asked for, in roughly the order an authority would ask for it:

One configuration deserves a direct sentence. Avrosh ships dental and clinic setups, and a transcript in that setting can amount to health data. We hold no HIPAA business associate status and no health data certification, and we hold no SOC 2 or ISO 27001. If a request touches that material, the notice and the pushback described above matter more, not less.

• Conversation transcripts, chat and phone. The full text of every message. There is no automatic prune, so a conversation from two years ago is still there and is still producible.
• Call records: the caller's phone number, the number dialled, start time, duration, language, the AI's summary and how the call ended. No call audio is recorded or stored. A written transcript and a call record are.
• Customer accounts and the CRM contact record: name, email address, phone number, bookings, waitlist entries, and the login codes emailed to a customer.
• The consent ledger, which is append only and shows what a person agreed to and when.
• Bookings, orders and payment status, including bank transfer proof images your customers upload, which carry names and bank details.
• Client supplied outbound calling lists and the consent attestations recorded against them, where you use outbound calling.
• Property API keys issued to your own servers, and the integration outbox that pushes booking and customer events to destinations you configure.
• The audit log of who did what, which cannot be edited or deleted; a database trigger refuses the change.

Some of the strongest answers we can give an authority take the form: that does not exist here.

None of this is a shield we would offer in order to obstruct a lawful order. It is simply what the system does and does not hold, which is the honest limit on what any order can extract from us.

• The QR chat carries no account, no phone number and no login. Nothing personal is collected on that surface, so a request naming a person cannot be matched to a QR conversation by identity. There is nothing to look them up by.
• No call audio exists, so an order for call recordings returns nothing. None were ever made.
• Card numbers never reach us. Our payments provider is merchant of record and holds the payment instrument.
• Passwords are stored as argon2 hashes. There is no password to produce.
• Where one of your customers has exercised erasure, identifiers are stripped in place, across every branch when branches are grouped, and the business rows that remain carry nothing identifying. We cannot un-erase a record for an authority.
• Categories that are pruned on a schedule are simply gone: platform bookkeeping rows after 14 days, internal error logs after 30 days, soft deleted business and catalogue records after 7 days, and past booking ranges nightly.

We have not written an emergency exception. Until we do, urgency in the framing of a request does not change the rule above: valid legal process, or we do not disclose. If that changes, this page changes with it.

A preservation demand gets the same validity check. In practice preservation asks for very little that is not already true, because conversations, transcripts and call records have no automatic prune and are kept for the life of the account.

That cuts both ways, and it is worth saying to you rather than only to an authority. If your own retention expectations are shorter than the life of the account, that is a conversation to have with us now, not after an order arrives.

We do not publish a transparency count today. Whether we publish one, and how often, is not yet decided.

We would rather write that sentence than let a heading imply a report exists somewhere. If a published count is something you need from a vendor, say so and it will weigh on the decision.

Legal process, and any question about this page, goes to hello@avrosh.com. We do not publish a street address on this site. The registered address of PT Laras Teknologi International appears in the signature block of a signed agreement. Whether service by email is accepted as valid service is not yet settled, so an authority should ask rather than assume.

This page applies to every account, including those governed by the public Terms alone. It is not a protection you have to negotiate into a signed agreement. Where a signed agreement says something different for a particular customer, that agreement governs for them.

An operator side export of your own business content is not self serve yet, so if you want your own copy of what is described above, ask us and we will provide it.