Roar AI Cloud

Who we are

Roar AI Cloud is a platform for companies. It does two things: it gives your employees one key that reaches every major AI model, and it hosts the internal apps they build. This policy explains what we do with the information that passes through it.

The service is operated by [LEGAL: registered entity name], registered at [LEGAL: registered address], company number [LEGAL: company registration number].

We handle two different kinds of information, and our role differs for each. For the people who sign up, sign in and administer an account, we decide what is collected and why — that is described below. For everything a customer’s own employees and apps send through the platform — prompts, files, app databases, the visitors their apps serve — we act only on that customer’s instructions. We do not decide what their apps collect, and we do not use it for our own purposes. [LEGAL: confirm the controller / processor characterisation and the wording it needs]

What this policy covers

It covers:

this website, roar-ai.com, including the documentation
the console, where administrators and employees manage models, keys, spend and apps
the gateway API that serves model requests
the hosting service, and the apps and databases it runs

It does not cover the websites and apps that our customers build — those belong to the customer, who is responsible for their own privacy notice. It also does not cover what a model provider does once a request reaches them; that is set out in Prompts and model providers below.

What we collect

Signing in

We hold your name, your email address and whether you are an administrator or an employee. Accounts are created by invitation, or by a request an administrator approves — there is no anonymous sign-up that reaches a live account.

Signing in is by a link emailed to you, valid for fifteen minutes. We do not store a password, because there is none. A signed-in session records the IP address and browser user-agent it was created from, so that you can see and end your other sessions, and expires after thirty days.

Your company’s account

The company name, a contact, the country it operates from, its billing currency, spend limits and budgets, its credit balance and its invoices. The country is asked at onboarding and is used to place infrastructure and set the default currency.

API keys

A key is shown to you once, at creation. We store only a one-way hash of it and a short display prefix such as roar_live_a1b2, so the key itself cannot be recovered from our database — not by us, and not by anyone who obtains a copy of it. Alongside it we keep the key’s name, what it is allowed to do, its spend cap and when it was last used.

A record of each API call

Every request through the gateway writes one usage record. It holds the model requested, the endpoint and hostname called, the number of tokens in and out, how long it took, the HTTP status, what it cost and what it was billed, whether it was answered from cache, which routing policy applied, and — on a failure — an error code and a short message with secrets stripped out. Where a trusted network edge tells us, it also holds the two-letter country the call came from, which is used to decide where to serve traffic from and never for billing.

This record does not contain the text of the request or the answer. That is a separate, optional store, described next.

Prompt and response content

So that your team can look at their own call history and debug it, the platform can store the request and the answer for each call. This is the most sensitive thing on the platform, and it is treated that way:

it is a per-company setting, on by default, and an administrator can switch it off — with it off, no content is written at all;
it is encrypted before it is written, with AES-256-GCM, so the database never holds a readable prompt;
it expires automatically — seven days by default — and a scheduled job deletes what has expired;
a body larger than 64 KB is replaced with a marker rather than stored.

Apps you host with us

When you deploy an app we hold what is needed to build and run it: the repository it comes from and the permission you granted to read it, the build settings and build logs, its domains, and its environment variables and connection strings. Environment variables and credentials are encrypted at rest and are never written to our logs.

Each app gets its own database on our servers in your region. Its contents belong to you. We do not read them, and we do not use them for anything other than running, backing up and restoring your app at your request.

Traffic to your hosted apps

So that you can tell why an app is slow or broken, we keep one row per request it served: the time, the method, the path, the status code, how long it took, how many bytes went back, which hostname was used and the request id our edge assigned.

We deliberately do not collect the visitor’s IP address, their browser user-agent, or the page they came from. Not hashed, not shortened — those fields do not exist in our database, so they never leave the machine that served the request. This is a stricter line than most hosting platforms draw, and it is drawn on purpose: our customer is a company whose apps serve other people, and storing those people’s addresses would make us a processor of their personal data for a field nothing in the product displays. The path does keep its query string, because a path that cannot tell two requests apart is not worth keeping; it is length-limited when it arrives. Alongside it we keep counters — requests, errors, response times — in five-minute buckets.

Administrative actions

Changes made through the console and the admin API are recorded: who acted, what they did, the result, and a summary of the request with secrets excluded. This is what lets us answer “who changed this” after the fact.

Getting in touch

If you use the request-access form on this site we collect your name, email address, company, phone number and what you told us you want to build, and pass it to the people who will reply to you. If you email or message support, we keep that correspondence.

Why we use it

To run the service. Route a request to a model, build and serve an app, keep a database available.
To meter and bill it. Usage records are what an invoice is made of, which is why they are kept longer than anything else.
To show you your own account — spend, budgets, which key is being used, which app is failing.
To keep it secure and available — detect abuse, enforce spend caps, investigate an incident, restore from backup.
To support you when you ask us something, and to reply to a sales enquiry you sent us.
To comply with the law, including keeping financial records for as long as we are required to.

We do not sell personal information. We do not train models on your prompts, your app data or your files, and we do not share them with anyone except as set out below.

[LEGAL: the legal bases relied on, and the statute they come from, for each purpose above]

Where it is stored

Where your data lives is a setting, not a promise in a document. Roar AI runs its own servers in the markets it serves — Sri Lanka, India and Singapore today — alongside a central control plane held with a cloud infrastructure provider.

Each company chooses one of three levels:

Flexible — the default. Any healthy route, wherever it is.
In-region processing — the gateway and the privacy guardrails must run inside your own country. Once a request has been screened there, it may go on to a model provider abroad.
In-region only — the model must be in your country too. The router refuses the request rather than sending it across a border, which is the point: it fails instead of quietly falling back.

Given that setting, the rest follows a single rule — data lives where the request was served.

Accounts, companies, keys, budgets and usage records are held centrally, so there is one login and one bill.
Your apps and their databases run on our servers in your region, one database per app.
Prompt and response content is stored encrypted where the request was served: centrally for a flexible company, in-country for one pinned to a region, under a key held in that region.

If you need a market we do not yet operate in, ask us before you rely on it rather than after — [LEGAL: the process and contact for a residency request, and any commitment attached to it].

How long we keep it

Prompt and response content — seven days by default, then deleted automatically. A company that needs a longer audit trail can be given one; a company that wants none can switch the store off entirely.
Traffic logs for your hosted apps — seven days. The five-minute counters behind the charts — ninety days.
The administrative audit log — ninety days.
Usage records — kept for the life of the account by default, because they are the evidence behind every invoice and the history behind every chart.
Account and company records — for as long as the account is open.
App data and app databases — until you delete the app. Deleting it removes the database with it.
Backups — see How we protect it. [LEGAL: backup retention window, once the operations team confirms it]
Invoices and financial records — [LEGAL: statutory retention period for financial records].

When an account closes we delete or anonymise what we no longer need, keeping only what the law requires us to keep.

We use a small number of suppliers to run the platform. Each gets only what its job needs, and none of them is permitted to use it for their own purposes. By category:

Model providers — receive the content of a request when it is served by an external model. See the next section.
Cloud infrastructure and object storage providers — host the central control plane and hold encrypted backups.
Source-code hosting and container registries — where your app’s code is read from and its built image is kept.
Network and edge providers — carry traffic to your apps and terminate TLS.
Email delivery — sends sign-in links, invitations and account notices.
Payment processing — takes payment. Card details go to the processor, not to us; we never see or store a card number.
Advertising and analytics — on this marketing website only. See Cookies.

We may also disclose information where the law requires it, or to establish or defend a legal claim. If the business is ever sold or reorganised, account data may transfer with it; you would be told before that changed anything about this policy.

[LEGAL: decide whether to name each supplier individually. A privacy policy normally does; the product is white-label and the marketing design rules forbid naming our infrastructure vendors on a customer-facing page, so this is a legal call rather than an engineering one]

Prompts and model providers

When one of your employees calls a model, the text of that call has to reach whoever runs the model. Some models run on our own hardware; most are run by the companies that built them. Which one served a given request is a decision the platform makes on your behalf, using the routing policy your company has set.

Two controls sit in front of that. A company can require that requests only go to private, self-hosted models, in which case nothing leaves our infrastructure. Or it can leave external models available and turn on guardrails: before a request leaves for an external provider, the platform scans it for personal data and credentials — email addresses, card numbers, national ID numbers, API keys, private keys, plus any pattern you add — and then redacts what it found, blocks the request, or reroutes it to a private model. Which of those happens is your setting.

Once a request reaches an external provider, what that provider does with it is governed by their terms, not ours. If that matters to you, the private-only and in-region settings above are the controls that make it a question you do not have to ask.

Cookies and tracking

The console sets one cookie, and it is the one that keeps you signed in. It is scoped to the console’s own hostname, is not shared with this marketing site, and is not used to track you. There is no way to use the product without it.

This marketing website carries the Meta advertising pixel, on roar-ai.com including these documentation pages. It records that a page was viewed and sets cookies that let Meta measure and attribute our advertising. It does not run in the console or against your hosted apps. You can limit it with your browser’s cookie settings, a tracker blocker, or the ad-preference controls Meta provides.

[LEGAL: whether a cookie-consent banner is required for the markets this site is advertised in, and whether the pixel must be gated behind it — there is no consent mechanism on the site today]

How we protect it

We describe what we do, not what we have been certified to do. We hold no security certification and make no compliance claim in this document.

Secrets are encrypted at rest with AES-256-GCM — your environment variables, your app database credentials, our provider credentials, and stored prompt content. The encryption is authenticated, so tampering is detected rather than decrypted.
API keys are never stored. What is stored is a one-way hash, computed with a secret the database itself does not contain, so a key cannot be read back out of it.
The server decides what you may see, never the browser. Every request is scoped to the company it came from before any data is read, and a request for something belonging to another company is answered as though it does not exist.
Traffic is encrypted in transit, and our own servers talk to each other over a private network rather than the public internet. The machines that hold customer data accept no administrative connection from the public internet at all.
Backups are encrypted so that the machine making them cannot read them. The key that opens a backup is held offline by an operator and exists on no server, which means a stolen server or a stolen backup bucket yields ciphertext. Restoring is a deliberate two-person act, not a button.
Prompt logs are not backed up at all. They are a short-lived debugging trail, not a system of record, and leaving them out of backups removes any question of prompt content outliving its retention window or leaving its region.

No system is perfectly secure. If we become aware of a breach affecting your data we will tell you [LEGAL: breach notification deadline and the regulator to be notified].

Your choices and your rights

Some of this you can do yourself, today, from the console:

turn prompt and response storage off for your whole company, so nothing is written;
revoke or delete an API key, and see when each one was last used;
delete an app, which deletes its database with it;
end your other signed-in sessions;
as an administrator, remove an employee from your company.

Beyond that you can ask us for a copy of the personal information we hold about you, ask us to correct it, ask us to delete it, or object to a particular use. Write to us at the address in Contact and we will reply within [LEGAL: response deadline for a data request].

If you are an employee of a company that uses Roar AI, your account belongs to that company. Ask your administrator first — they can act on most of the above immediately. Where we hold the data only on your employer’s behalf, we will refer your request to them rather than act on it ourselves.

[LEGAL: the statutory rights that apply and where they come from, whether a data protection officer or local representative is appointed, and which regulator a complaint goes to]

Children

Roar AI Cloud is sold to companies and is built for their employees. It is not directed at children and we do not knowingly collect information from anyone under [LEGAL: minimum age]. If you believe a child’s information has reached us, tell us and we will delete it.

Changes to this policy

We will update this page when what we do changes. The date at the top is the date of the current version. If a change materially affects how we handle your information, we will tell account administrators by email before it takes effect rather than relying on you to notice.

Contact

Questions about this policy, or a request about your own data, go to [LEGAL: privacy contact email], or by post to [LEGAL: registered address].

If you are not yet a customer and want to talk to someone, get in touch — we are in Colombo.

[LEGAL: governing law and the jurisdiction whose courts apply]