Privacy policy

You are about to put your team's conversations, your documents and the keys to systems you run into somebody else's hands. This page is the plain account of what we collect, who else sees it, how long it stays and what you can make us do about it. Where we cannot honestly tell you something, it says so rather than reaching for a comforting phrase.

Last updated 19 September 2026.

Who is the controller

Anypreta s.r.o. is the data controller for the account relationship: what you give us when you sign up, what the payment processor tells us back, the record of your instance, and our own operational log. For those we decide why and how the data is processed, and the rights set out below are exercised against us.

The content inside your workspace is a different matter. Your conversations, your documents, what your agents learn and the files they work on are yours. We hold them to run the instance for you and act on your instructions with them, rather than deciding for our own purposes what goes in or what is done with it: in data-protection terms you are the controller of that content and we are your processor. Where the people whose data you put into a workspace are your staff or your customers, telling them and answering them is yours to do, and our part is to give you the means to act.

The parties engaged in delivering that are set out in the section on who else processes your data: our model provider, which runs the models your agents use and which routes each request on to whichever upstream provider serves it, and our hosting provider, on whose machines the instances run. We will tell you before another is added. Our payment processor is engaged for billing rather than for workspace content, and is our processor for the account data we are the controller of.

If you need this written into a data processing agreement, ask us at info@anypreta.com and we will put one in place.

Our lawful basis for each purpose

The law requires us to tell you which lawful basis under Article 6 of the GDPR covers each thing we do with your data. There are three, and this is all of them.

• Performing our contract with you. Creating your instance, running it, keeping it reachable at the address you chose, signing you in, taking payment and telling you about your own subscription. Without this data there is no instance to give you.
• Our legitimate interests, named rather than left vague. Keeping the service secure, which is why a sign-in session records the browser and the address it was used from, so that you and we can see a session that should not be there. Preventing abuse of the platform and of the model allowance we pay for, which is why a workspace can carry a spending ceiling. And keeping an operational log of what was done to an instance, so that a fault, a bill or a deletion can be accounted for afterwards. In each case the interest is a service that stays up, is not used to harm other people, and can be explained after the fact; the data involved is the least that serves it, and you can object to any of it by writing to us.
• A legal obligation. The invoice and the accounting record behind it are kept because tax and accounting law requires us to keep them, for as long as it requires.

None of the processing above runs on consent. There is no analytics, no profiling, no advertising and no marketing mail anywhere in this service, so there is no processing that waits on your agreement. Where consent does apply is your browser's own permission for notifications, which your browser asks you for and where you can take it back. That absence of analytics is deliberate, and it is why you are not being shown a cookie banner.

What we collect when you sign up

Signing up for a workspace gives us your name, your email address and the subdomain you choose. Where a subscription payment is involved, we also hold what the payment processor tells us: a customer identifier, a subscription identifier, your billing status and the date your current period ends.

Alongside that we keep the state of your instance, when it was created, when it was last seen healthy, the models it is allowed to use, its spending ceiling, and our own operational notes about it. That record is stored as ordinary readable data on our side rather than encrypted, and you should read it as something our staff can see.

Your email address is also written into our own activity log when you sign up. That log keeps the most recent entries and discards the oldest as it fills. It is worth knowing that deleting an instance removes its registry record but does not go back and remove those earlier log lines, so your email address can survive in that log after the instance itself is gone.

The one cookie this website sets

You can read every page of this site, and fill in and submit the sign-up form, without our writing anything to your browser. One thing changes that, and only if you ask for it: choosing a language stores your choice in a cookie called pokrokcloud_lang, so that the next page you open is in the language you picked. It holds two letters, it is never read for any other purpose, and if you never touch the switch it is never set - the site simply follows the language your browser says it prefers.

Beyond that, the only places this service sets a cookie are the sign-in and sign-out handlers of our own staff area.

Nothing on these pages causes your browser to contact another company. There is no third-party script, font, pixel, iframe, beacon or tag manager anywhere on the site, and no setting by which one could be added. Every file a page asks for comes from our own server: an icon, a stylesheet, a small theme script, and the product recordings and their poster images. We use no web fonts, so no request goes to a font service. There is no analytics or telemetry library here; the service that serves this site has no third-party code in it at all.

The one thing that small script does is read a single value your browser may already hold, your light or dark colour preference, so the page paints in the right colours. It can only ever be light or dark, it is never sent to us, it identifies nobody, and no code anywhere in this service even writes it.

Why this website shows no consent banner. The test is not whether data is collected. Consent is required for storing information on somebody's device, or reading information already there, unless doing so is strictly necessary to provide the service that person asked for. Measured against that: the one thing this site writes to your device is the language you chose, which is strictly necessary in exactly the sense the rule means - it exists because you asked for it, and without it the site cannot do the thing you asked. One value is read, the light or dark preference your own browser already holds, and it is read for the single purpose of painting the page you asked for in the colours you chose. It never leaves your browser and identifies nobody. The one cookie this service can set is the staff sign-in described next, which is strictly necessary for a sign-in somebody deliberately asked for. Nothing here is read or stored for analytics, advertising or profiling, so there is nothing to put to you for agreement. Your workspace is a separate service, and what it sets and stores in your browser is set out in the two sections below.

The one cookie this service is capable of setting belongs to our own staff. It is called pokrokcloud_session: a sign-in session for our administration area, issued only when somebody deliberately submits a password form, lasting thirty days, and an authentication token with no analytics, profiling or advertising purpose. It carries no domain attribute, so a browser sends it only back to the exact hostname that issued it and never to a customer's subdomain. We store only a hash of it, never the token itself.

If you go on to payment we hand you to the payment processor's own checkout page, where they set their own cookies under their own policy. No payment script, iframe or button is embedded in any page of ours.

The three cookies inside your workspace

Your workspace is a separate service at your own address, and it does set cookies. There are exactly three, all of them strictly necessary to run it, and none of them used for analytics, advertising, profiling or tracking.

• Your sign-in session, pokrok_session. Issued only by something you do yourself: creating the first account, signing in with a password, or completing single sign-on. It lasts thirty days from last use and is deleted when you sign out. Its value is a random token of which we store only a hash, so a copy of the database yields nobody's session.
• Which workspace you are in, pokrok_ws. It holds a workspace identifier and no personal data, and is kept for a year. On a hosted instance it is only ever set for somebody already signed in, and never given to an anonymous visitor.
• A single sign-on safety token, pokrok_oidc. It exists only during a sign-on handshake, lasts ten minutes, holds an encrypted anti-forgery value, and is cleared as soon as you come back from your identity provider whether the sign-in worked or not.

None of the three carries a domain attribute, so each is bound to the exact address that issued it and a browser will never send your instance's cookies to another customer's. Opening the product without signing in sets no cookie at all. Applications you run inside your own environments may set cookies of their own; we pass those through and keep them inside that application's address, but their contents and purpose are yours rather than ours.

Alongside each sign-in session we record the browser's user-agent string and the address the request came from, so that you can see and end your own sessions. That record lives and dies with the session.

What the product keeps in your own browser

Most of it is preferences: your light or dark choice, your dictation pause setting, whether you have already been offered notifications on this device, and per-environment console preferences. Three of them can contain your own words rather than settings, and we would rather name them than let you find out: unsent message drafts, the last hundred commands typed into an environment console, and the names of any workflow groups you have collapsed.

Drafts stay on your own device, are capped per conversation, and are discarded once they are more than thirty days old the next time a draft is saved in that browser. Until then they sit in your browser's storage, and clearing your browser's site data removes them at any point. The product uses no session storage and no indexed database anywhere.

The product does install a service worker, which is what lets it be installed as an app and receive notifications. It deliberately caches none of your content for offline use. The single thing it stores is a note of which conversation you are currently looking at, so a reply you are watching arrive on screen does not also buzz your phone. It is short-lived, it stays on your own device, and it holds nothing else.

Who else processes your data

Four parties are involved in running the service itself. Others are reached because of something you or your agents set in motion: the push service your own browser nominates if you turn notifications on, the outward tools an agent has been granted, and any service you connect yourself.

• Our model provider, OpenRouter, which runs the models your agents use and routes each request on to whichever upstream provider serves it. What reaches them is described in the next section.
• Stripe, our payment processor, where a paid subscription is involved. What we send is your email address, the price identifier, an internal reference for your instance, and the subdomain you chose. We do not send them your name. Any name, billing address or card detail you type on their checkout page is collected by them directly under their own policy. Card details never touch our infrastructure at all: there is no card field anywhere in our software, because payment happens on their page rather than ours.
• Our hosting provider, on whose machines the instances run.
• Proton, who carry the account notices we send you - that your instance is ready, that a payment did not go through, that something has been stopped. What reaches them is your email address and the text of the notice itself, which names your subdomain. Nothing from inside your workspace is ever put in one.

The encryption of connections to this site and to customer subdomains is operated by us rather than bought from a content delivery network or a proxy vendor, so no such vendor sits in the request path and none is a processor here.

We do not print the hosting provider's name or the country of the machines on this page, because that is exactly the kind of fact that changes without a marketing page changing with it. Ask us at info@anypreta.com and we will tell you what it is on the day you ask.

If you turn on browser notifications, those pass through whichever push service your own browser nominates. The content of a notification is encrypted before it leaves your instance, so the push service carries the message without being able to read it.

We send you notices about your account, and nothing else. There are nine of them, and every one is about your own instance: it is ready, we could not build it, a payment arrived or was declined, your subscription changed, the instance has been stopped, it is close to its storage allowance, it has used its model allowance for the week, or it and its data have been removed. There is no newsletter and no marketing list, and nothing to unsubscribe from - somebody who switched these off would simply not be told their instance had stopped. They go out through the mail provider named in the list above, and carry your email address and the text of the notice, never anything from inside your workspace. Inside your workspace it is different, and deliberately so: a workflow you build can send mail, through an email connector you configure or by speaking to a mail server you name, and what it sends is yours.

What reaches the model provider

The conversation itself. The message history, the tool definitions available to the agent, and the model's own parameters go to the provider on every run.

This is not limited to text. Images, documents and audio attached to a conversation are sent to the provider inside the request, encoded in it, whenever the model in use can accept them. Voice recordings are sent the same way for transcription. Pictures, scans and recordings leave for the provider, not only the words you type.

What does not go with them is any identifier of you. The only headers our software adds are fixed product identifiers, which contain no customer, workspace or user identity, and no per-customer or per-workspace identifier is added to a model request. The instance also asks the provider for its model catalogue when it starts; that request carries no customer data.

Zero data retention is enabled on our provider account. Per the provider's own documentation that stops the underlying model providers keeping the content of prompts and responses. It is worth being precise about what it does not cover: token counts, latency, the model, the provider and the cost are still retained as operational metadata, in-memory caching is not counted as retention, and the setting does not extend to plugins or tools such as web search.

Our software itself sets no data-use, retention or training preference with the provider in either direction. Whether prompts are ever used for training is therefore governed by our agreement and account settings with that provider rather than by anything in the code, and we will not tell you it is impossible when the code cannot evidence that either way.

We cannot tell you that model processing happens inside the EU. Regional routing is not in force on our account: the provider's European endpoint refuses our inference calls. Anyone who tells you otherwise about this service today is wrong.

Transfers, and the countries we cannot name

What goes to the model provider. Regional routing is not in force on our account, and the provider routes each request on to whichever upstream provider serves it, so we cannot tell you which country the models that answer you run in. Treat everything in the section above as capable of leaving the EEA when it is sent for a model to answer: the conversation, the tool definitions, and the pictures, scans and recordings attached to it.

The safeguard for that transfer is not yet documented, and we are not going to print one that does not exist. When one is concluded this page will name it and carry the date it took effect. Until then the accurate statement is the one on this page: the transfer happens, zero data retention is enabled on our account as described above, and no transfer mechanism has yet been concluded to sit behind it. If a documented safeguard is a condition of your buying this, raise it with us before you sign up rather than after.

What goes to the payment processor. Where a subscription payment is involved, they receive your email address, the price identifier, an internal reference for your instance and the subdomain you chose. We cannot tell you from our own knowledge which country they process it in; their own policy is what answers that.

Where the machines your instance runs on are is answered the same way as the hosting provider's name above: ask us at info@anypreta.com and we will tell you what it is on the day you ask.

What goes to the push service. If you turn on browser notifications, they pass through whichever push service your own browser nominates, which may be outside the EEA. The content is encrypted before it leaves your instance, so the service carries the message without being able to read it.

Anything that leaves because you connected a service or granted an agent a tool goes wherever that service is, which is your choice rather than ours.

Services you choose to connect

Beyond the provider above, data leaves your instance only where you send it. If you connect Slack or Telegram, messages flow to and from them using a token you supply. A Discord connection answers slash commands and cannot send anything unprompted. Feeds are fetched from whatever addresses you enter. Single sign-on contacts the identity provider you name. Workflow steps can clone from and push to repositories you name, and can speak to mail servers you name.

Email deserves a note, and there are two separate things here. The product sends and receives through a mailbox you already own and configure: incoming mail is collected from that mailbox rather than delivered to us, and a workflow step can send the same way, through a connector you have configured or by speaking to a mail server you name. We operate no mail service for any of that.

Separately, we send you notices about the account itself - your instance is ready, a payment did not go through, something has been stopped or is close to a limit. Those go out through a mail provider, named in the list above, and they carry your email address and the text of the notice. They never carry anything from inside your workspace. There is nothing to unsubscribe from because none of it is marketing: switching these off would mean not being told your instance had stopped.

Agents also have tools that reach outward. Web search sends the search terms to DuckDuckGo. Four further keyless services handle lookups: Wikipedia, weather and geocoding, currency conversion, and public name lookups, each receiving the term, place or hostname asked about. Fetch tools will retrieve any public address an agent names, so that destination is not a fixed list. None of these is automatic: an agent has only the tools its grant list names.

Where you connect a service, your relationship with that service is yours, and what it does with what it receives is governed by its policy rather than ours.

How long we keep things

• Your account and instance record - your name, your email address, the subdomain, the subscription status, the state of the instance and our own notes on it - is kept for as long as the instance exists, which is not the same as for as long as you subscribe: cancelling stops the instance, and a stopped instance is removed ninety days later, with its data and this record. You can ask us to remove it sooner, and you can ask us to keep it longer, but you have to ask before the ninety days are up. Where an invoice has been issued, the accounting record behind it is kept for as long as tax and accounting law requires, which is longer than the subscription.
• The sign-up line in our own activity log carries your email address, and deleting an instance does not go back and remove it. The criterion is the log's own size: it holds the most recent entries and discards the oldest as it fills, so that line goes when enough newer entries have pushed it out, or sooner if you ask us to take it out.
• Conversations, messages and attachments have no expiry. They stay until somebody deletes them, or until the workspace or the instance is removed.
• Diagnostic traces of model calls record the request and the answer, which means the text of the prompt and the reply. Tracing is on by default in a new workspace. These are deleted after fourteen days by default, and the period is a workspace setting that an administrator can raise or lower. They are also capped by volume, so a busy workspace can lose them sooner.
• Records of tool calls follow the same fourteen day default.
• Records of configuration changes to a workspace are kept for a year, deliberately longer.
• Sign-in sessions expire thirty days after last use and are then removed.
• What agents remember is kept indefinitely unless you set a period. Recorded exchanges have no expiry by default, and an administrator can set one per memory scope, up to ten years. When exchanges do age out, the facts learned from them are kept, with their link to the deleted conversation cleared rather than the fact removed.

Before a trace is stored, credentials are taken out of it: the authorization token is replaced by a short fingerprint, and named credential headers and cookies are dropped. Attachment data is replaced by a note of how large it was rather than kept. The prompts and replies themselves are in there, which is the reason the retention period matters.

What happens when you cancel

Cancelling does not delete anything straight away, and we would rather you heard the rest of it from us too. When the payment provider reports a subscription cancelled or unpaid, normally once the period you have paid for has ended, your instance is stopped rather than removed. Its data is left in place on our servers.

A stopped instance is removed ninety days later, with everything in it. That is a scheduled job. It runs without anybody deciding, it cannot be undone, and afterwards we hold no copy. Take your export before you cancel, or at any point in those ninety days - it is one file from Settings and it is yours to keep.

If you want the workspace kept beyond that, write to us at info@anypreta.com before the ninety days are up and we will keep it. If you want it gone sooner, ask and we will do it.

When an instance is deleted with its data, the deletion is thorough. Its route is removed, its containers are brought down, and its entire directory goes: the database, uploaded documents, container workspaces and any backups, all of which live inside that one folder rather than in shared storage. What sits outside that folder is the activity log described above, which can still carry the email address you signed up with.

Taking a copy with you

A workspace can be exported from Settings at any time. The export controls are shown to administrators, but downloading an export is a read rather than a change, so any member of a workspace can take one, including a read-only member. Be precise about what that file contains, because the default is narrower than people expect.

By default an export does not contain your conversations. What it does contain is the workspace's setup and its knowledge: settings, agents, memory scopes, tool servers, connectors, scheduled tasks, workflows and triggers, along with notes, documents, learned facts and recorded exchanges, plus a manifest of what went in. Conversations, messages, chat attachments, traces, run history and environments come only if you ask for them, which you can do when you take the export.

An export is not a credential backup and should not be kept as one. Provider keys, connector configuration, webhook secrets and stored passwords are stripped where they are recognised, but a credential stored inside a workflow's own settings can survive that pass, so treat the file as sensitive and re-enter credentials after importing. An export never contains account records: user accounts, sessions, API keys and workspace membership are excluded by design, because importing them elsewhere would create people and carry credentials.

One thing an export does not reach: facts, notes and documents a workspace has contributed to shared memory live in a separate store that the export does not read, and that deleting a workspace is explicitly forbidden from dropping.

Your rights, and what we can actually do

Under the GDPR you can ask us for access to your personal data, for it to be corrected, for it to be erased, for processing to be restricted, for a portable copy, and you can object to processing. Write to info@anypreta.com and we will answer. You can also complain to a supervisory authority; ours is the Office for Personal Data Protection in Prague.

Three limits are worth knowing before you rely on them, because they are how the service behaves today rather than how we would like to describe it.

• There is no self-service button that deletes your whole instance. The route is to ask us, and every instance action sits behind our own staff sign-in. Inside your instance you can delete your own conversations, documents and workspaces yourself, one at a time or all at once, and doing so only ever reaches your own.
• A person cannot delete their own account. Deleting an account is an administrator action within your workspace, and an administrator cannot delete their own.
• Deleting an account does not remove everything about that person. It removes the account, its sessions, its conversations and the messages in them. It does not remove the attachment records and stored files from those conversations, and it does not remove what agents have learned about that person in memory. If a request needs those gone as well, tell us and we will deal with it by hand.

Deleting a conversation removes its messages and its attachment records, and deletes the stored file when no other conversation still points at it. A user can also ask for what was learned from a conversation to be erased along with it, which removes the recorded exchanges, the facts and the notes held against it. Anything already contributed to shared memory is held separately and is not removed by that.

Changes to this policy

When this policy changes the new version appears here with a new date at the top, and where the change is material this page says what changed and the date it took effect. We will also write to the address on your account rather than rely on you to notice, and a change to this policy is a person writing to you rather than one of the automatic account notices.