How data processing
actually works

You are the controller. These are your clients, your staff and your consents. You decide why the data is processed and you answer for it before the person whose data it is.

We are the processor. We process on your instruction and in your interest. We have no purposes of our own: the data does not go into advertising, is not sold and does not train models.

That is why a separate processing instruction is attached to the contract, as part 3 of article 6 of 152-FZ requires. We hand the template over together with the invoice.

If you installed the agent yourself, there is no processor at all. The program runs on your machine and the data never leaves you, apart from the addresses you enabled with your own keys.

By itself the agent sends data nowhere. Every address appears because the owner of the installation enabled it with their own key.

• To the model provider goes the content of the conversation: the question, the history, memory notes, document texts and images if the model can see. This happens on every reply, otherwise the agent does not think.
• To speech recognition goes the voice recording, if voice is on. By default this is Yandex, inside Russia.
• To the channel goes the agent's reply: Telegram, Discord or a Bitrix24 portal, wherever you talk to it.
• To your own systems goes the work itself: letters, deals, calls, documents.

🔴 About the border. If a foreign model is chosen, the content of the conversation leaves Russia, and that is a cross-border transfer with everything 152-FZ attaches to it: the notification and the legal ground are the controller's duty, that is yours. If that does not suit you, a Russian model is chosen in the settings - GigaChat or YandexGPT - and the agent works just the same.

The full list of addresses the core can ever reach lies in plain text in deploy/egress-allowlist.txt. It is not documentation: the build fails if an address appears in the code that is not on the list, or if the list still names an address the code no longer uses.

Neither your data nor statistics about its processing reach us. The sending code does not exist: usage counters are written to a file on your machine and stay there.

The update check does not run on its own: our server is contacted only by the interclaw update command, and only if updating is allowed by a variable. No installation identifier is sent.

This claim rests not on a promise but on the same outbound-address guard: it does not let a send be hidden inside a long string.

This section exists because a document without it reads as advertising.

• There is no encryption of data at rest. Files are readable only by the service user: the file is 0600, the directory 0700. Anyone who gets administrator rights on the machine reads everything. In the cloud the nightly copy is encrypted before it leaves, but the live disk is not.
• Conversations, notes and the profile have no retention period. They stay until you delete them with a command. There is no automatic cleanup for them, and that is a deliberate design of personal memory, not an oversight.
• Deleted things live on in copies. A note erased with the forget command remains in memory rollback points and in every backup taken before that. To remove it from there the copies have to be deleted separately.
• The log masks secrets but not personal data. Keys and tokens never reach the log, while a name, a phone number and an error text containing an e-mail address do.

This page is updated when the machinery changes, not once a year. What changed and when is in the changelog.