Privacy policy
Senast uppdaterad 2026-10-13Publiceras endast på engelska
Riktra is operated by House of Brattberg AB, a Swedish aktiebolag registered under number 559125-1805, at Banérgatan 3, 521 31 Falköping, Sweden. This policy explains what Riktra stores about people, why, for how long, and who else can see it.
It is written against what the system actually does. The storage and subprocessor tables below are generated from the same inventory the codebase is checked against, so they cannot quietly fall out of date when the product changes.
Riktra has two different roles
This distinction decides who you should ask about what, so it comes first rather than last.
- For your account and our operations — your sign-in details, your beta application, our logs — House of Brattberg AB is the controller. We decide why that data exists, and you can bring any request about it straight to us.
- For your company’s context — its goals, decisions, priorities, ownership — your employer is the controller and Riktra is the processor. We hold that data and serve it back; we do not decide what goes into it. Requests about it go to your employer, and we help them answer.
What Riktra stores
Grouped by what it is. The right-hand columns say how long each thing survives and on what legal basis we hold it.
Your account
What we hold about you as a person using Riktra. We decide why it is held, which makes us the controller for it.
| What it holds | Why | How long | Basis |
|---|---|---|---|
| Email address, full name, preferred language.profiles | Identifies the account and addresses the person in the interface. | Kept until the account is deleted. | Contract — necessary to provide the service. |
| The link between a person and an organisation, plus their role.organization_members | Decides what a person may see and do. Every access rule in the database is derived from this row. | Kept until the membership or the organisation is removed. | Contract — necessary to provide the service. |
| Invitee email address, requested organisation role, inviter and a one-time token hash.organization_invitations | Lets an authorised owner or administrator invite a person without granting access before that person accepts. | Deleted when accepted or revoked. Expired invitations are deleted when another invitation is created for the organisation; no scheduled expiry cleanup is implemented. | Contract — necessary to provide the service. |
| Name, email address, company, company size band, role description, tools in use, and free-text answers about the applicant's situation.beta_applications | Selecting companies for the closed beta. | Kept until the beta programme closes. | Consent — submitted voluntarily to apply for the beta. |
Your company’s context
Everything your company puts into Riktra. Your company decides what goes in and why — it is the controller, and Riktra is the processor acting on its instructions.
| What it holds | Why | How long | Basis |
|---|---|---|---|
| Company context. Personal data appears where a person is named as owner, author or editor.goals | Holds what the company is trying to achieve. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Company context. Personal data appears where a person is named as owner, author or editor.priorities | Holds what matters most right now, in rank order. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Company context. Personal data appears where a person is named as owner, author or editor.decisions | Holds what the company has actually decided. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Company context. Personal data appears where a person is named as owner, author or editor.open_questions | Holds what is still undecided, and who is waiting on it. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Company context. Personal data appears where a person is named as owner, author or editor.responsibilities | Holds who is accountable for what. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Company context. Personal data appears where a person is named as owner, author or editor.working_principles | Holds the working agreements that apply. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Company context. Personal data appears where a person is named as owner, author or editor.context_notes | Holds background a newcomer or an AI needs to act correctly. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Company context. Personal data appears where a person is named as owner, author or editor.system_ownership | Holds which system is owned by whom. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Suggested changes to company context, and which person reviewed them.proposals | Nothing proposed by AI becomes company truth without a person approving it. This table is where that approval is recorded. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Whole-row snapshots of shared company records, and who changed them.entity_versions | Makes every change to shared truth reversible and attributable. History is never rewritten; restoring creates a new version. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Relationships between records, and who created them.entity_links | Connects a decision to the question it settled, and so on. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Which records need a given person's attention.attention_items | Produces each person's view of what needs them now. Derived by fixed rules, not by a model. | Recomputed from current records; superseded entries do not persist. | Determined by the customer organisation as controller. |
| Ingested material — meeting transcripts and pasted text — including whoever took part in it.sources | Lets Riktra propose candidate records from something that was said or written. | The raw text is deleted once its candidates have been reviewed (ADR-010). Failed imports also attempt cleanup when no review is pending; a cleanup failure requires a retry and text may remain until it succeeds. The source reference and its title are kept. | Determined by the customer organisation as controller. |
| Skill definitions and the accounts that authored them.skills | Distributes an organisation's working instructions to AI clients. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
| Previous versions of skill definitions and their authors.skill_versions | Makes changes to distributed instructions reversible. | Kept until the record or the organisation is deleted; deletion of an organisation cascades. | Determined by the customer organisation as controller. |
Your private notes
Visible only to you through Riktra’s application roles. Colleagues, organisation administrators and platform administrators have no application access to your private notes.
| What it holds | Why | How long | Basis |
|---|---|---|---|
| An authenticated person's company or personal export snapshot and captured membership references.data_exports | Provide consistent eligible data downloads and withdraw access when membership is revoked, without exposing another person's private notes or credentials. | Access expires after one hour. Expired snapshots are removed on the next export or operator maintenance; account/company deletion removes applicable snapshots immediately. Downloaded copies are controlled by the recipient. | Contract — customer-requested data export. |
| A person's own private notes about their work.personal_context | Gives one person continuity across AI conversations. Readable only by its owner: not by colleagues, not by organisation administrators, and not by Riktra's own platform administrators. This is enforced by database policy, not by application code. | Kept until the person deletes it or their account is deleted. | Contract — the person's own private workspace. |
| What a person has told Riktra they are focused on.focus_items | Shapes that person's own view only. Never included in organisation-wide retrieval, search, analytics or logs. | Kept until the person deletes it or their account is deleted. | Contract — the person's own private workspace. |
| A revision counter for one person's private context.personal_revisions | Lets an AI client tell whether private context has changed. | Kept until the account is deleted. | Contract — the person's own private workspace. |
| Previous versions of a person's private notes.private_versions | Makes private edits reversible without ever placing private content in the organisation-wide version history. | Kept until the account is deleted. | Contract — the person's own private workspace. |
Running the service
What we need in order to keep Riktra working, secure and debuggable.
| What it holds | Why | How long | Basis |
|---|---|---|---|
| Opaque deleted account/company identifiers, scope and deletion time. No record content.data_erasure_receipts | Reconcile erasure and revoked access before reopening a restored database. | Kept for recovery reconciliation. No automatic expiry is implemented; the operator reviews retention against the verified backup horizon. | Legitimate interest — preventing erased data from reappearing after recovery. |
| Temporary subscription verification tokens, opaque subscription ids and user/organization ownership.revision_subscription_operations | Bound callback verification and prevent revoked or superseded requests from activating subscriptions. | Valid for one minute. Successful activation, failed verification and revocation remove the matching reservation immediately. The minute dispatcher and later owner requests reclaim expired reservations; cleanup may be delayed during outages. User/organization deletion cascades. | Contract (user-requested integration). |
| User-approved revision subscriptions, callback destinations, encrypted signing keys and delivery watermarks.revision_event_subscriptions | Signal changed organization context or skills to the subscriber's chosen AI client, without record content or personal-context events. | Subscriptions expire after 24 hours unless renewed. The minute dispatcher deletes expired subscriptions and subscriptions whose owner lost membership. Revocation and user/organization deletion remove them immediately; cleanup may be delayed during outages. | Contract (user-requested integration). |
| Which accounts administer the Riktra service itself.platform_admins | Grants access to service administration. It grants no access to customer data: the owner-only rules have no administrator bypass. | Kept while the person administers the service. | Legitimate interest — operating the service. |
| Metadata about each AI client call: the account, the tool invoked, and how long it took. No request or response content.mcp_request_logs | Diagnosing failures, enforcing rate limits and reporting organisation-level adoption from existing operational metadata. Riktra deliberately exposes no per-person view of this data — aggregating it across an organisation is what separates 'is this integration healthy?' from monitoring individual employees. | Kept for the lifetime of the organisation. No automatic expiry is implemented today. | Legitimate interest — operating and securing the service. |
| Organization-linked operational metadata: latest skill id, version, canonical digest, fixed server method and response timestamp. No user identifier, client label, skill content, prompt or request arguments.skill_delivery_receipts | Lets organization owners and administrators compare published skill revisions with the latest response produced by Riktra, without claiming client receipt or behavior. | Only latest state per organization, skill and method, until overwritten or the skill or organization is deleted. No automatic expiry is implemented. | Legitimate interest — diagnosing governed instruction delivery. |
| One authenticated web-presence marker per account, organisation and UTC date. It contains timestamps only: no route, content, IP address or browser fingerprint.organization_daily_presence | When the organisation enables optional usage analytics, measures organisation-level adoption, return use and active-member breadth without exposing a named person's activity in the platform console. | Kept for the lifetime of the organisation. No automatic expiry is implemented today. | Legitimate interest — understanding and improving product adoption. |
| A request counter keyed by account identifier and time window. No content.rate_limit_counters | Prevents one account from exhausting shared capacity. | Windows older than a day are removed opportunistically during normal use, not on a guaranteed schedule. | Legitimate interest — securing the service. |
What Riktra does not do
Each of these is a property of how the system is built, not a promise about how we intend to behave.
- No advertising, and no tracking across other sites. Riktra carries no advertising pixels and no third-party fingerprinting, and nothing it collects is sold or shared for marketing. Optional usage analytics is disabled by default. An organisation owner or administrator may enable fixed page categories, interaction counts and extraction measurements. The server checks the organisation preference before sending each event. Record content, search terms, full URLs, raw errors and persistent person identifiers are excluded. Session replay is unavailable: no browser sessions are recorded, and Riktra does not set optional analytics cookies.
- No administrator bypass on private notes. Your personal context and focus items are readable only by you. That is enforced by the database, not by application code, and it applies to your organisation’s administrators and to our own platform administrators equally.
- No employee monitoring. We record which AI tools are called so we can tell whether an integration is healthy. Riktra deliberately provides no view that reports one named person’s activity to anyone.
- No model training on your data. Riktra does not train any model, on your data or anyone else’s.
- No silent changes to your company’s truth. Anything AI suggests is a proposal until a person approves it.
Who else touches the data
Riktra runs on other companies’ infrastructure. These are all of them.
| Who | What for | Where | What they receive |
|---|---|---|---|
| Vercel | Application and MCP hosting | Stockholm (application functions, arn1); global platform operations | Every request to the service, and its server logs. |
| Supabase | Database, authentication and access control | Stockholm (primary database, eu-north-1); international support and platform operations | All stored data, and account credentials. |
| Anthropic | Extracting candidate records from submitted material | United States (workspace); global inference routing | The submitted transcript, meeting title and titles from current company context for extraction and duplicate detection. Processing begins before extracted candidates are screened for sensitivity. No extraction call occurs unless someone submits material. Customer-authorized external AI clients have their own processing terms. |
| Amplitude | Optional usage analytics and AI-usage measurement | United States | Disabled by default for every organisation. If an owner or administrator enables usage analytics, Amplitude receives fixed page categories, button/link click counts and extraction measurements (model, latency, token counts and success). No record content, search terms, full URLs, raw errors or persistent person identifiers are sent. Each event is re-authorised on the server. Session replay is unavailable and no browser sessions are recorded. Operational and security logs necessary to run the service are separate. |
| Resend | Transactional email | Ireland (email sending, eu-west-1); United States (storage and primary processing) | Recipient address and message content for service emails. The sending region does not determine where email content, delivery logs and account records are stored. |
| Operator mailbox and optional sign-in | Global, including United States; Workspace data-at-rest region: No preference | The operator’s Google mailbox receives operational notifications, beta-application messages and service/privacy correspondence. These copies have their own mailbox access and retention boundary. Separately, when a person chooses Google sign-in, Google returns that account’s name, email address and profile picture under its identity-service terms. | |
| Cloudflare | DNS resolution | Global | Domain lookups only. No application data passes through it. |
Data that leaves the EU
Riktra’s application functions and primary database are configured in Stockholm. This does not mean every supplier operation, log or optional integration stays in Sweden. The supplier table describes the processing locations and categories. Service email and operator correspondence also involve providers outside the EU: Resend stores email content and delivery logs in the United States even when email is sent from Ireland, and the operator’s Google mailbox has a separate international processing boundary. The following optional features involve providers outside the EU.
- Transcript extraction. When someone submits a transcript for Riktra to draw candidate records from, the text of that transcript, meeting title and titles from existing company context are sent to Anthropic for extraction and duplicate detection. The submitted material reaches the provider before sensitivity screening of the extracted candidates. This happens when someone submits an import; normal context retrieval makes no extraction call. Do not submit credentials or unnecessary sensitive personal information.
- Signing in with Google. Only if you choose that option instead of an email link or a password.
- Optional analytics. If enabled by your organisation, fixed usage metadata is sent to Amplitude. Customer record content is excluded, and session replay remains unavailable.
Supplier contracts and applicable transfer safeguards govern these services. If your organisation requires EU-only processing, contact us to assess that requirement before use; a Swedish database region alone does not establish it.
AI clients you connect receive the context your authenticated account is authorised to retrieve. Their providers may store or process that data under their own terms. Your organisation chooses and authorises those clients. Disconnecting a client prevents further authorised retrieval; it cannot erase copies already received by that client or provider.
What we ask of the material you submit
Riktra screens submitted material for sensitive content — health, family circumstances, individual performance or pay, private finances, credentials — and withholds candidates it identifies as sensitive from shared company context. That screening is deliberately cautious, but it is not perfect, and it is not a substitute for judgement about what belongs in a transcript you paste in.
The raw text of submitted material is deleted once its candidates have been reviewed. What survives is the records a person chose to keep.
Your rights
Under the GDPR you can ask for a copy of your data, ask us to correct or delete it, ask us to restrict how it is used, object to processing based on legitimate interest, and ask for your data in a portable form. Write to privacy@riktra.com.
Where your employer is the controller — anything in your company’s context — we will pass your request to them and help them answer it.
If you think we have handled your data badly, you can complain to Integritetsskyddsmyndigheten (IMY), Sweden — imy.se. We would rather you told us first, but you are not obliged to.
Security
Application access uses database-enforced row-level security together with authenticated membership and role checks. Private notes have no organisation or platform administrator bypass through those application roles. The service operator and infrastructure providers hold privileged infrastructure access for operating and recovering the service; this is not end-to-end encryption. Controls and tests reduce risk, but cannot guarantee that every application bug is harmless.
Changes to this policy
Riktra is in active development. When what the product does with data changes, this page changes with it — the same inventory that generates the tables above is checked against the codebase on every change, so a new kind of stored data cannot ship without appearing here. Material changes will be announced to account holders by email.