Sub-processors

A sub-processor is a company that processes your data, or your customers' data, on our behalf so the service can work. Two kinds appear on our list. The AI vendors receive conversation content: what a caller said, what the business's own knowledge base returned, and what the AI is about to say back. The platform vendors run the service around it: hosting and the database, subscription billing, transactional email, and the telephony carrier that connects a phone call.

One thing that is deliberately not on our list. Where you configure a destination of your own, that destination is engaged by you and not by us. Your own mail server is the long-standing example. The integration outbox behaves the same way: it pushes booking and customer events to endpoints you choose, and those endpoints are your processors, not ours. The same goes for API keys you issue to your own servers. We say what we send and where you told us to send it, and you remain the party who chose the recipient.

No call audio is recorded or stored. A written transcript and a call record are, and the transcript is what passes through the AI vendors.

The sub-processor table on our Security page is built from packages/shared/src/providers.ts, the same registry the running system picks models from. Add a provider in the code and the page gains a row. Change where a model is served from and the page changes with it.

This is not a presentation choice. The previous version of that page was hand-written and had drifted: it listed six vendors, four of them described with a region that was no longer accurate, at a time when the product ran across more vendors than that. A hand-typed list goes stale the moment the product moves, and nobody notices until a buyer checks. Generating it removes the gap between what we run and what we publish.

We hold accounts with more AI vendors than we use. Holding an account changes nothing about where data goes. A model can only serve traffic when two separate things are true.

Because both tables are published, a question like "can you serve my language model from the European Union" gets an answer with a reason attached instead of a flat no.

There is one exception and we would rather name it than hide it. We can list a specific uncertified model as a pilot in our deployment configuration in order to trial it on real traffic. It is a deliberate recorded act, it does not change the certification record, and a model with no adapter can never be piloted, because the pilot flag is a statement about our confidence and not about whether the code exists.

• It must be certified, which means it passed our own measurement suite for the specific role it would serve. Certification is per role and never global. A model measured for chat is not thereby approved for the phone.
• An adapter must exist in our code for that vendor and role. Without one, an assignment would silently fall back to the default, and an operator who believes they moved and did not is worse off than one who was told no.
• The list an account can be offered is also filtered by language fit. A property serving a language a model does not document never sees that model, because on the speech-to-text path an undocumented language is not a graceful degradation. It comes back as a fluent transcript of words nobody said.

Every AI row carries two facts, tracked separately, because they answer different questions and they are routinely different.

Served from is where the request is actually answered. That is the residency question, and it reaches the bytes. Vendor jurisdiction is where the company is incorporated. That is the legal question, and it is what a subpoena, a production order or a court reaches. A Singapore endpoint operated by a company incorporated somewhere else is the normal case, not the exotic one. A page that prints only one of the two is not answering the question your counsel is asking.

One consequence of our own incorporation belongs here. Indonesia has no European Union adequacy decision, so transfers of EU personal data to us rely on Standard Contractual Clauses together with a transfer impact assessment. Indonesia's own personal data protection law, Law 27 of 2022, applies to us directly. Choosing a region for your servers does not change either of those facts.

A related trap is worth publishing because we found it the hard way. A vendor having a region does not mean that vendor serves every role there, and picking a region in a vendor console is not by itself a residency guarantee. One major provider's Frankfurt region carries text models and no speech models at all, and its deployment scope is set per workspace rather than per request, so a workspace left on a global default can route outside the region while the console still names the region.

Next to each origin we publish how we know it. There are four values and they are not decoration.

Publishing "not disclosed" is the deliberate part. Our text-to-speech vendor sits behind a content delivery network, so its serving origin cannot be established from DNS. We could have drawn a plausible region badge for it. That badge would have been an inference wearing the costume of a fact, and for a European buyer that inference is the entire decision. So the registry records the absence, and the page prints the absence. A blank space reads as "fine", which is the exact failure this design exists to prevent.

Note what certification does not cover. That same speech vendor is certified, because certification means we measured its output quality and latency for the role it serves. It says nothing about residency. The two are separate columns for a reason, and reading certified as vetted for residency would be a mistake we do not want anyone to make quietly.

• Measured means we established it ourselves. Our speech-to-text origin is measured: the round trip from our Singapore server is a trans-Pacific distance, not a local one.
• Stated means the vendor documents it and can be held to it.
• Unverified means nobody has read the contract yet. It is an admission of work not done, not an allegation about the vendor.
• Undisclosed means we tried and could not establish it.

Your servers and your database are assigned to one of three regions: Northern Virginia, Singapore or Frankfurt. The AI answer path does not follow that assignment, and we would rather you read that here than discover it in a security questionnaire.

Five models are certified to serve an account today.

Read the consequences plainly. A customer assigned to Frankfurt gets a Frankfurt database and an answer path with nothing in the European Union. A customer assigned to Virginia has their language model and their knowledge base search served from Singapore. There are European rows in our catalogue, a French language model served from the EU and a British speech vendor with an EU endpoint and an on-premises option, and both are uncertified, which means they cannot be assigned to anyone. Being in the catalogue is not being in the path.

If in-region AI processing is a requirement for you, tell us before you sign rather than after, and we will tell you exactly where certification stands for the role you care about.

• Language model for chat and for classification: served from Singapore. Vendor jurisdiction recorded as Alibaba Cloud, jurisdiction unverified.
• Language model for voice: served from Singapore, same vendor.
• Speech to text: served from the United States, measured by us. The vendor is a United States company.
• Text to speech: serving origin not disclosed, vendor jurisdiction unverified.
• Embeddings for knowledge base search: served from Singapore, stated by the vendor. This one is pinned for the life of the data it wrote, because changing it means re-reading every document in a knowledge base.

The operator dashboard carries a model picker, one role at a time. Beside each option it shows where that model is served from and how confident we are in that answer, and an option we will not run for your account is shown with the reason it is blocked rather than quietly left out of the list. A short list that reads as the whole shelf is its own kind of lie. The assignment is stored per property, and the routing seams refuse any assignment that cannot actually run.

So the model serving each role for your account is set with us, and its origin is published here. If you want a specific model, a specific serving region, or a written residency answer for one leg of the path, that is an onboarding conversation and we will tell you whether the answer is yes, no, or not yet measured.

When an assignment is made, it is refused at the point of writing if the model is not permitted to run, not merely hidden from a list. The list is a convenience. The refusal is the guarantee. Both read the same predicate in the same code so they cannot drift into disagreeing.

Beyond the AI layer, a small set of vendors runs the service. They are published by role. The named company for each is given on request at hello@avrosh.com rather than guessed in public.

Card data never reaches us. Our payments provider acts as merchant of record and handles the card. We hold no card numbers, which is also why we make no PCI claim: there is nothing on our side for one to cover.

Some data categories are worth naming explicitly, because a generic inventory hides them. Customer accounts and the contact record, including email addresses and the emailed login codes, sit in the database with the hosting vendor. So does the append-only consent ledger, so do bank-transfer proof images uploaded by your customers, which carry names and bank details, and so do any outbound calling lists and consent attestations you supply. None of those are sent to an AI vendor unless they appear in a conversation.

• Hosting: application servers and the PostgreSQL database, in the region you are assigned.
• Payments: subscription billing, as merchant of record.
• Email: transactional email such as receipts and notifications.
• Telephony carrier: connecting phone calls to and from the AI, by number country.

The reason vendor jurisdiction is published is that a legal order follows the company, not the datacentre. If a government or a law enforcement agency wants data, the question is whose law reaches the company holding it, and that can be a different country from the one serving the request.

Our position, applied to requests reaching us. We require valid legal process and do not disclose data voluntarily. We notify the affected business unless we are legally prohibited from doing so, and where we are prohibited we press for the shortest permissible delay. We push back on requests that are overbroad or that reach beyond what the process actually compels, and we produce the narrowest set of data that satisfies a valid order.

We cannot make the same promise on behalf of a sub-processor. What we can do is publish which company each vendor is, so you can assess that risk with the same facts we have. Whether we publish a periodic count of requests received is still an open decision, listed below.

Three gaps are real today and we would rather write them down than let them surface later.

Our text-to-speech origin is undisclosed, and that leg carries the customer's own words back out. For a European buyer this needs a written statement from the vendor or a different vendor, not an inference from us.

Retention at the language model and embedding vendor is not stated in what we have read, and there is no documented zero-retention option. That matters most in the clinic and dental verticals, where a call transcript can be health data. We hold no HIPAA business associate status and no health-data certification, and we hold no SOC 2 or ISO 27001. If your use produces special category data, tell us before you sign so we can scope it honestly rather than after the fact.

We are also required, as a non-EU company serving people in the European Union, to appoint a representative in the Union under Article 27 of the GDPR. One is being appointed and is not yet in place. Naming that here is more useful than waiting until the page can claim it is done.

Because the table is generated from configuration, a change to our sub-processors is a change to our source code with a date on it, and this site publishes the result on the next deployment rather than when somebody remembers to edit a page. That is the mechanical half.

The human half is deliberately simple today, because we would rather describe a process that exists than promise one that does not. There is no self-serve notification feed. Write to hello@avrosh.com and we add your account to the sub-processor notice list, and we email that list before a new vendor begins processing customer data. If you hold a signed agreement with us, the notice period and any objection right in it govern over this page.

We will not add an AI vendor to the served list silently. A vendor that has not been certified and has no adapter cannot receive data at all, so a new name reaching a live account is always preceded by work we can point at.