aktum / legal / privacy

Privacy and data handling

Draft for legal review. Nothing on this page binds anyone until a lawyer has read it and the founder has published it.

Drafted 9 September 2026 · for the early-access beta

This statement says what Aktum collects, why, where it is stored, who can see it, how long it is kept, and what you can ask us to do about it. It describes the hosted service as deployed, read from the repository; where the repository records no fact, this page says so rather than guessing.

1. Who we are

Aktum is made and operated by Monadial s. r. o., with its registered seat at Majerníkova 3043/54, 841 05 Bratislava, Slovak Republic, company ID (IČO) 47 647 876, tax ID (DIČ) 2024008811, registered in the Commercial Register of the District Court Bratislava III, section Sro, insert no. 144751/B.

For anything about personal data, including a request under section 11, write to [email protected]. For the service itself, write to [email protected]. No data protection officer is appointed; the size and nature of the processing does not require one under Article 37 GDPR.

2. What this statement covers

This statement covers the marketing site at aktum.io, the hosted service at app.aktum.io, and the sidecar you run on your own infrastructure.

The hosted service is an early-access beta that runs as a tenant on a platform operated by Monadial. The sidecar and the workers behind it run on your side; no part of them runs on Aktum’s side.

3. Controller and processor: which one we are

Two roles run side by side, and the difference decides who you ask for what.

We are the controller for the data we need to run the service as a business: your account, your organization’s membership and settings, the early-access requests sent from aktum.io, the operational logs and traces, and the correspondence you send us. Sections 4.1, 4.2 and 4.7 describe it.

We are the processor for what your organization brings into Aktum: the documents in your rooms, the threads, decisions and signoffs, the indexed repository text, the prompts and AI answers. Your organization is the controller for that, decides what goes in, and instructs us through the product. If you are a member of an organization on Aktum and want that data corrected or deleted, ask your organization’s administrators first; we act on their instruction. Section 12 says where the agreement that would normally govern this stands today.

4. What we process

4.1 When you visit aktum.io

No cookies, no analytics. The marketing site sets no cookies, runs no analytics, and stores nothing in your browser. There is no consent banner because there is nothing to consent to.

The early-access form. When you request early access we store the six fields of the form (your name, your email address, your organization, your role, where your repository lives, and the optional sentence about what you would put in the room first), the fact that you accepted the terms of service and this statement, and a timestamp. We store it so a person can read it and reply, and so we know which addresses may open an account during the beta. A confirmation is sent to the address you entered, from [email protected], and a second message goes to it if we let you in. Nothing else is done with it, and it is never sold, shared for advertising, or used to profile you.

The beta access list. If we approve your request, your email address is put on a list of addresses that may sign in during the beta, and it stays there while the beta runs. An address is also added to it when an organization’s administrator invites that address to their organization. Sign-in is refused for an address that is not on the list.

4.2 Your account

Aktum holds your name, your handle and your email addresses; any verified address can sign in to the account. Sign-in is by an email code or a sign-in link, GitHub, Google (where configured), or a passkey; Aktum holds no password for you. A second factor is required for every session. Of your second factors, Aktum holds an authenticator secret encrypted under the service master key, recovery codes shown once and stored as hashes, and for a passkey the public key only. Sessions are listed under your account and each can be revoked; an organization’s security policy sets the session length. The hosted service sets a session cookie, aktum_session, which carries your session; it is HTTP-only and marked secure. A sign-in through GitHub or Google also sets HTTP-only cookies for that sign-in: oauth_state, and oauth_verifier where the provider uses PKCE. Both are cleared when the provider sends you back. These cookies are strictly necessary to sign you in and keep you signed in; there are no others.

4.3 Your organization

Aktum holds the members and their roles, invitations (who sent them, to which address, with which role, and when they expire), the organization’s security policy, its GitHub connection and the repositories declared through it, its enrolled sidecars, and an audit log of administrative actions: invitations, role changes, policy changes, second-factor resets, status changes and the logo.

4.4 Workspace and room content

The documents in your rooms are files in your repository, on the room branch. The margin threads, routed questions and their answers, decisions, approvals, signoffs and the workspace policy are committed to your repository under .aktum/ as readable text. Aktum’s database holds a cache of both for rendering.

Commits that Aktum makes on your behalf carry your name and your email address as the git author, so both appear in your repository’s history. Machine actors commit under the sidecar’s own identity, never as a fabricated person.

Names appear inside the record files as well: a decision names who decided and who dissented, a thread names its author, and the workspace policy names role holders by handle. Those files are in your repository and under your control.

4.5 Indexed repository text

Repository write access exists only through the sidecar on your infrastructure, branch and patch only; repo credentials never leave your side. Indexed repository text is uploaded to Aktum for indexing and review. The backend reads repository content and opens the consent pull request through the GitHub App you installed and can revoke.

What that upload holds: the sidecar sends every text file of a repository snapshot. The body of each file is stored in object storage; the parsed text of markdown files outside .aktum/ is stored in Postgres as document nodes with content hashes. Binary and oversize files are listed, not uploaded, and .aktum/ is never parsed into nodes. A push to the default branch re-indexes. If your repository contains personal data, that data is uploaded with it; what a repository holds is your organization’s decision, not ours.

4.6 AI data

Per-phase provenance files, each naming the prompt it used, the model and the commit, are committed on the room branch. The run itself, its status and its narrative, and every quick-AI answer exist only in Aktum’s database and are not part of the record.

Stated by store: quick-AI answers (ask, explain, rephrase and draft) are stored as generation rows in Postgres. Committed prompt files and phase outputs on the room branch are text files in the indexed snapshot, so their file bodies are in object storage and, for files outside .aktum/, their parsed text is in Postgres. Run state and run narratives are held in Postgres. A prompt is logged only as its length, at debug level. Model keys are read from your sidecar’s environment; the backend does not store them and never logs them.

4.7 Slack, if your organization connects it

Connecting Slack is an organization admin’s choice and is off until they make it. When it is on, Aktum holds the access token Slack issues for that workspace and, for each member who has a Slack account under an email address verified on their Aktum account, the Slack user id it matched. Notifications are sent as direct messages, never to a channel, and the message carries what the notification says: the question, its options, and a link back. When someone answers from inside Slack, Slack sends us that action and we write the decision the same way the product would have. Disconnecting removes the token and stops delivery.

4.8 The sidecar, and what we log

The sidecar you run connects outbound only. It sends a heartbeat, receives its work over an authenticated connection, and reports back what it did and what failed, including error strings; those control events are held in Postgres and are visible to members of your organization on the sidecar’s activity page.

The backend and the sidecar write structured logs. The hosted backend exports traces to the monitoring stack of the platform it runs on. The sidecar exports traces only if you configure an endpoint, and its own logs stay on the machine that runs it. Keys are never logged; a prompt is logged only as its length at debug level; artifact content stays out of info-level logs by convention. Logs and traces carry technical identifiers, and an IP address reaches them through ordinary request handling.

5. Why we process it, and on what legal basis

What	Why	Legal basis (GDPR Article 6)
Account and sign-in data	To create your account, sign you in, and hold the second factor every session requires	Contract, Article 6(1)(b)
Organization data and the audit log	To run your organization’s membership, roles and security policy, and to show administrators what was done	Contract, Article 6(1)(b); legitimate interests, 6(1)(f), for the audit trail
Workspace and room content, indexed repository text, AI data	To provide the product your organization asked for	Contract with your organization, Article 6(1)(b); we act as its processor
Early-access requests and the beta access list	To read your request, reply to it, and decide who may open an account during the beta	Legitimate interests, Article 6(1)(f), in running a closed beta and answering the people who ask for it; and steps at your request before a contract, 6(1)(b)
Transactional email (sign-in codes and links, invitations, address confirmations, second-factor resets)	To let you sign in and be invited	Contract, Article 6(1)(b)
Logs, traces and control events	To keep the service running, find faults, and protect it against abuse	Legitimate interests, Article 6(1)(f)
Answering your privacy request	To do what section 11 requires	Legal obligation, Article 6(1)(c)

We send no marketing email, run no advertising, and build no profiles. If we ever ask for something on the basis of consent, you will be asked plainly and can withdraw it at any time without losing anything you already have.

6. AI and model providers

Aktum operates no model of its own. When a run or a quick-AI request needs a model, the prompt goes from the workers behind your sidecar to the endpoint you configured, under your keys: Anthropic, OpenAI, or any OpenAI-compatible endpoint, with Ollama as the local default. Whether that provider retains what it receives, and for how long, is the provider’s policy under your agreement with it. What Aktum logs about a model call on the deployed build is the prompt’s length, at debug level, and never the key.

We do not use your content to train models, and we have none to train.

7. Where it is stored, and transfers

Object storage. Scaleway object storage in the region nl-ams, in the Netherlands, holds the bodies of indexed files, room uploads, organization logos and avatars.

The database. One database on the Postgres cluster the platform shares among its tenants holds the record cache, the parsed document text, account and organization data, runtime state for runs and generations, and the background job queue. The cluster’s region is not stated here, because the repository does not record it.

Backups and failover. Backups, retention and failover for the database are inherited from the platform and are not documented here.

Email. Two kinds of mail leave the service, both from [email protected] through Scaleway. Account mail: a sign-in code or link, an invitation, an address confirmation, a second-factor reset. Notification mail: a question routed to you, a mention, a signoff asked of you, an approval gone stale, a decision reverted, a run’s outcome, a hold opened or refused, and a change to a signing key. Early-access mail: a confirmation when you send the form, and a message if your address is let into the beta. A routed question’s mail carries the answer options as links, each signed to you and valid for fourteen days, so answering does not require signing in first. The region the mail is sent from is not recorded in the repository.

On your side. The sidecar keeps the git checkout, a local SQLite cache and its own logs on the machine that runs it.

Transfers outside the EEA. Aktum’s own infrastructure is in the European Union. Three things can leave it, each by your choice: your model provider is the endpoint you configure, and it may be anywhere; GitHub, if your repositories are hosted there, processes what it holds under its own terms with you; and Slack, if your organization connects it, receives the notifications we send to it. Where we use a subprocessor outside the EEA, the transfer rests on the European Commission’s standard contractual clauses or an adequacy decision. The subprocessors page names each one and where it sits.

8. Who can see it

Members of your organization, by membership. Reads of documents, threads, locks, the policy, decisions, the export and AI answers are checked against membership on the server; reads of run state, gates and the run narrative, template listings, provisioning state and the current-room read are checked for a signed-in account but not yet for membership. An outsider who reaches your organization’s address sees No access and learns nothing about what exists there.

The people who operate the hosted service. A small number of people at Monadial can reach production in order to run and support the service. They use it to keep the service working and to answer support requests, not to read your work for any other purpose. The formal rule, the approval step and the logging around that access are not yet documented; writing them down is owed work, and this page will say so until it is done.

Subprocessors. The third parties that process customer data are listed on the subprocessors page, each with its purpose and the location the repository states. Your model provider is not among them: that agreement is yours.

Nobody else. We do not sell personal data, we do not share it for advertising, and we disclose it to an authority only where the law obliges us and, where we are allowed to, after telling you.

9. How long we keep it

Some periods are set in the code, and those are exact. The rest are governed by the beta: while your organization uses Aktum we keep what the service needs, and we delete it on request.

• Sign-in codes and links. Single use, and they expire 15 minutes after they are sent.
• Sessions. A session lasts 14 days by default, and an organization’s security policy can shorten it. Revoking a session ends it at once.
• OAuth sign-in cookies. Ten minutes, and cleared as soon as the provider sends you back.
• Invitations. Seven days, then they expire.
• Early-access requests and the beta access list. Kept while the beta runs, so we can reply to you and know who may sign in, and deleted on request or when the beta ends, whichever comes first.
• Account, organization, workspace and AI data. Kept while the account or organization exists. No fixed retention period is set for it in the beta, and none is claimed here.
• Notifications. A record of what was sent, to whom and how it settled, kept while the account exists. A signed answer link in an email expires fourteen days after it is sent.
• Logs and traces. Kept by the monitoring stack of the platform the service runs on; its retention is not recorded in the repository, so no figure is stated here.
• Backups. Inherited from the shared cluster, as section 7 says. A deletion reaches live systems immediately and backups as they age out.

What is in your repository stays there. Deleting your Aktum data does not reach the record committed to your own repository; that is yours, and only you can remove it.

10. How we protect it

Every session requires a second factor. Sign-in secrets are never stored in a form we can read back: authenticator secrets are encrypted under a service master key, recovery codes are stored as hashes, and for a passkey only the public key is held. Repository write access exists only through the sidecar on your infrastructure, and repository credentials never leave your side. Traffic is served over TLS. Reads of your organization’s content are checked against membership on the server, with the exceptions section 8 names. Model keys live in your sidecar’s environment and are never stored or logged by us.

No security certification is held: no SOC 2, no ISO 27001, no penetration test report to show. If you find a vulnerability, write to [email protected]; tell us what you found and how to reproduce it, and we will reply. There is no bounty programme.

11. Your rights

Under the GDPR you have the right to ask us for:

• Access. A copy of the personal data we hold about you, and an explanation of what we do with it.
• Rectification. Correction of anything inaccurate. Your display name, your handle and your email addresses are yours to change in your profile at any time; the handle names you in the record, so only you choose it, and an administrator cannot set it for you. Files already committed to your repository keep the name and handle as they were written, because a commit is history and is not rewritten.
• Erasure. Deletion of your personal data, subject to what we must keep by law. Section 9 says what deletion reaches.
• Restriction. That we stop processing something while a dispute about it is resolved.
• Portability. The data you gave us, in a machine-readable form. The record is already in your repository as readable text, and an export endpoint returns the whole .aktum/ record as files; a second export is byte-identical, file by file. No studio button reaches that endpoint yet, so ask us and we will run it.
• Objection. That we stop processing based on legitimate interests, including anything in section 5 that rests on them.
• Withdrawal of consent, where we ever rely on consent, without affecting what was lawful before.

How to ask. Write to [email protected] from an address on the account, or tell us enough for us to find you. We answer within one month, and we say so if a request is complex enough to need the extension the GDPR allows. We do not charge for this, and we do not require a particular form of words.

If you are a member of a customer’s organization. For the content inside a room, your organization is the controller and we act on its instruction, so send that request to your organization’s administrators; we will help them answer it, and we will tell you if you write to us instead.

Complaints. If you think we have handled your data badly, tell us first and we will try to put it right. You can also complain to the Slovak supervisory authority, Úrad na ochranu osobných údajov Slovenskej republiky, Hraničná 12, 820 07 Bratislava, dataprotection.gov.sk, or to the authority where you live or work.

12. A data processing agreement

No data processing agreement is published yet.

13. Automated decision-making, and children

Aktum makes no decision about you by automated means that produces a legal or similarly significant effect. The product’s own design says the same thing in its own register: machine text is provisional until a named person accepts it, and a question that needs a decision is routed to a person rather than guessed.

Aktum is a tool for organizations and is not directed at children. We do not knowingly collect data from anyone under 16.

14. Changes to this statement

This statement carries a date. A change is a new dated version on this page, and a material change is announced to organization administrators by email before it takes effect.

Monadial s. r. o. · Majerníkova 3043/54 · 841 05 Bratislava · Slovak Republic IČO 47 647 876 · DIČ 2024008811 · District Court Bratislava III, section Sro, insert no. 144751/B [email protected]

draft · 9 September 2026 · not yet reviewed by legal