Aini Privacy Policy

Effective date: 2 July 2026
Last updated: 5 November 2026

This Privacy Policy explains how Nishimta AB ("Nishimta", "we", "us") collects, uses, shares, and protects personal data when you use Aini — our AI assistant available through the web app, MacOS app, and browser extension (collectively, the "Service"). It is written to meet the information duties in Articles 13 and 14 of the EU General Data Protection Regulation ("GDPR") and to describe our actual data flows rather than every data flow a policy could theoretically cover. If anything is unclear, write to us at privacy@nishimta.com and we will explain it.

1. Who we are (data controller)

The data controller responsible for the processing described in this policy is:

Nishimta AB
Stockholm, Sweden
Email: privacy@nishimta.com

2. What this policy covers

This policy covers the Aini applications — the web app, MacOS app, and browser extension — together with the APIs, websites, and backend services behind them. It does not cover the third-party tools and data sources you choose to connect to Aini; those remain governed by their own privacy policies. Your use of the Service is governed by our Aini Terms of Service; this policy describes the data processing those Terms refer to.

3. What personal data we collect

We collect only what the product needs to work. Concretely:

Account and profile data. To sign you in, we hold your name, email address, profile-picture address (when present), and a unique account identifier. An account that signs in with Aini's own email and password, or with an emailed sign-in code, is held in our database in Frankfurt, Germany, together with a salted hash of its password and each active sign-in session, including the IP address and browser that session came from; a first or last name you change in the web or MacOS app's personal settings is saved there. An account that signs in through WorkOS is held by WorkOS, which passes us the details above; a name you change is sent to WorkOS so that your account record there is updated, and we keep no separate copy of it beyond your signed-in session. During the pre-launch demo, the app also contains the name, work email address, and profile photograph of its owner, bundled with the app as the Adam Egesa demo persona. All three are bundled into the app's public static files and can be requested without signing in; the photograph is served by Aini rather than fetched from a third-party image host.

Content you create. This is the substance of the product, and it is stored so you can come back to it:

• Conversations — the messages you send to Aini and the responses you receive, including their history.
• Pins — when you pin content in your browser using the Aini extension, we capture the page URL, visible text in the region you selected, and, where you pin a visual region, a bounded screenshot of that region. The extension filters out page code and content that is hidden, transparent, marked as inaccessible to assistive technology, or held in form-draft controls before upload. For a supported Jira board card, we also capture the linked issue key and address. Pins are viewable in the web app, MacOS app, and browser extension. A pin records your selected content and this source information. Separately, so that your saved pins can reappear when you return to a page, the extension sends the address of pages you visit to the Service while you are signed in to look up your pins there; addresses of unpinned pages are not stored as content, though like any request they appear for a limited time in the server logs described under Technical data.
• Rooms and stakeholders — the change-rooms you create, their items and notes, and the stakeholders you add to a room: their name and email address (drawn from your organization's member list, which today is example data apart from one real persona — the owner's, described above) and a free-text note on how each stakeholder relates to the change. Room items can also retain source-system issue metadata, including labels, comments, dates, owner/reporter and implementer/assignee names and identifiers, and before-and-after field values when change history is available. Room items can also carry source- or user-supplied access-group names. We derive and show room-wide combinations of those names to explain which group memberships cover every artifact; this does not itself control who may open the room in Aini.

Attached images. Images you upload, paste, or drop into a conversation can be sent to our AI provider to generate a response. When you post an image to a room's shared channel without addressing Aini, we store its bytes in private Cloudflare R2 object storage in the European Union. A later message addressed to Aini can include that image as context. Our database stores image metadata and the link to its room message; image bytes are stored separately in R2. Other attached images follow the immediate-response path, with type and dimensions retained for a placeholder. Section 8 explains room-image retention. Images sent to the AI provider remain subject to the provider context and retention described in Section 5.

Content you create may itself contain personal data — about you or about other people — depending on what you choose to write, attach, or pin. Please be thoughtful about pinning or uploading material containing other people's personal data, and do not submit special categories of personal data (Article 9 GDPR) unless it is necessary for your use of the Service.

Connection configurations. When you configure an external tool or data source in Aini, we store the settings you enter — such as the workspace URL, a display name, and your chosen options.

When you connect Jira. Atlassian handles your sign-in and consent. We exchange the authorization code for access and refresh tokens, encrypt those tokens in a separate store, and keep the selected site's identifier, address and name. A temporary authorization record binds the attempt to your account and expires after ten minutes. Expired records are removed when you next start authorization; disconnecting removes that connection's tokens and authorization records. Records also disappear when the owning account is erased. Aini's API authorization flow does not itself import Jira issue content.

Organization settings data. The organization-settings pages currently operate on example data scoped to your own account, apart from the one real persona described above; any names or email addresses you enter there are stored as content you create.

Technical data. Our servers keep standard request logs (timestamps, IP addresses, requested web addresses, response codes) for operation and security. Our applications use the small set of cookies and on-device storage described in Section 10. We do not run advertising pixels or session-replay tools, and we do not buy data about you from anyone.

Authentication email records. Hosted authentication emails and delivery feedback pass through Amazon Web Services in Frankfurt when mail is enabled. This includes staff testing; production customer mail activation remains pending. Our database records the message kind, recipient address, provider message identifier, send attempts and outcome, and delivery, bounce or complaint information, including the receiving server's reply when present. These database records contain no message body, sign-in link, token or code.

Web diagnostics. Deployed web builds send browser and server errors and performance measurements to Sentry to help us find faults and slow requests. Reports can include error messages and locations in our code, navigation and request addresses, timing information, the app version and environment, your pseudonymous account identifier, and the identifier of a room you open. We filter HTTP refusal errors and scrub credentials from addresses. Request-body collection and automatic user-information collection are disabled. Error text and diagnostic breadcrumbs, including console messages, can still contain incidental personal data. The connection to Sentry exposes your IP address. We do not record your screen or replay your session.

Extension diagnostics. Release builds of the browser extension send errors and release-health metadata to Sentry to help us find faults. Error reports contain fixed diagnostic text, error types, locations in extension code, the extension version, environment, and which extension component failed. Reports from the extension’s own pages and service worker can include your pseudonymous account identifier; reports from handlers on visited pages exclude it. Error reports exclude visited-page addresses, page content, selections, pins, email addresses, and free-form error text. The connection to Sentry exposes your IP address. Release-health metadata describes extension sessions and crashes; it does not record the page you visit.

4. Purposes and legal bases

We process personal data only where we have a legal basis under Article 6 GDPR:

Where we rely on legitimate interests, we have assessed that they are not overridden by your rights and freedoms; you may object as described in Section 9. If data is required to provide the Service (for example, account data), declining to provide it means we cannot provide the Service to you. We do not process your data for advertising, profiling, or resale under any basis.

5. AI processing — what the AI provider sees

When the new AI service is enabled, we also keep a separate copy of the context it needs to continue your conversation. This can include your messages, selected page context, our instructions, AI replies, tool arguments and results, image references, and model usage. When a conversation grows long, the AI writes a summary of its older part, and that summary replaces the older context in this copy, except the conversation's first message and the context sent with it, which stay. This storage starts only when that service is enabled.

Aini's core function is generating AI responses. To do this, the content of your conversation — including attached images and pins you reference — is sent to our configured AI provider: Anysphere Inc. (Cursor), or directly to Anthropic PBC when the Claude backend is selected. In addition, when you capture a pin, we automatically send the pinned page's address and a short excerpt of the pin — and, when deciding among your open conversations, brief snippets of your recent conversations plus up to six short excerpts from pins already routed into each candidate conversation — to the configured provider to decide which conversation the pin belongs to. We consider no more than ten candidate conversations for one routing decision. You can turn this automatic routing off per website domain in the pins settings.

Pins you capture from supported work tools (for example, a Jira issue) can automatically open a conversation in the matching change-room, with an AI-written summary of the pin as its opener; the same per-domain routing switch controls this. When you chat in a room that came from a supported work tool, a snapshot of that room — its items and notes and the stakeholders you have added, with their names, contact details, and how they relate to the change — is included in what we send to our AI provider, so the response reflects that context. Room tools may also send their inputs and results — including source-system access-group names and, when a proposed stakeholder is refused, that stakeholder's held group memberships plus the items and groups blocking them — through Anysphere to its selected model sub-processors, or directly to Anthropic when the Claude backend is selected. Editing a room's goal or decision in the room panel also automatically sends the edited fields' current values to the configured AI provider, and Aini posts a short acknowledgment into the room's shared conversation (delivered to the room's bound private Slack channel where the room has one — see Section 6). Depending on the backend, tool inputs or results can appear in the raw agent events stored with the conversation.

Aini's backend includes a generated knowledge repository containing requirements, their authors and owners, and a people directory. A copy is stored in each backend application image in Render's Frankfurt region. When the AI runs in local-agent mode, repository-reading tools run inside that backend container; files the agent selects may be sent with your prompt through Anysphere to the selected foundation-model provider, or directly to Anthropic when the Claude backend is selected. The repository copy is not used to store your conversation. Correcting or erasing data in it requires us to regenerate and redeploy the repository and remove retained application-image and rollback copies that contain the old data.

Anysphere acts as our processor under a data processing agreement and engages vetted sub-processors of its own — including foundation-model providers and inference hosts in the United States — under equivalent data-protection obligations (current list at trust.cursor.com/subprocessors). Anthropic acts as our direct processor under commercial terms when the Claude backend is selected; production requires a commercial Anthropic API credential. In optional cloud-agent mode, Anysphere also hosts resumable conversation context; local-agent modes execute repository and room tools in our Render container, but model inference still transmits prompts and selected context to the configured provider. The Claude Agent SDK also writes local session files in that container, which can contain prompts, attached images, and room-tool context. Those files do not currently have an automatic expiry or deletion hook tied to a conversation or account; this cleanup is required before launch. One-shot title and routing requests do not create session files. When you ask us to erase conversations, we delete our database records. Provider-held prompts, completions, and cloud-agent context remain subject to the provider's retention settings and contract terms; we do not currently issue a provider-side deletion request. We do not permit our processors to use your content to train models for other customers, and we do not sell or license your content to anyone.

6. Recipients and processors

When Jira enrichment is enabled, issue content fetched through your Jira connection is stored in the room and sent to the configured AI provider. We retain it only while its purpose and our reporting, refresh and redaction controls remain supported. We may refresh or redact affected Jira content and generated outputs; unrelated user-authored discussion and independent Product Map content are preserved. People named as the issue's assignee, reporter or creator are matched against your organisation's member list. Room roles and AI stakeholder suggestions use matched catalogue identities and contact details, rather than copying those people's raw Jira profile fields. Suggestions can inform the analysis even when automatic stakeholder placement is off.

We use a small, fixed set of service providers (processors under Article 28 GDPR), each bound by a data processing agreement and each receiving only what its role requires:

When you choose to connect Jira, Atlassian receives the authorization code and access token so we can complete authorization and identify the sites you have granted access to. This exchange is part of the connection you request, as described in Section 3.

Conversation records, pins, and connection configurations live in our database in Frankfurt, Germany. Retained room-image bytes live separately in private Cloudflare R2 storage in the European Union. When the Claude backend is selected, session copies can also live on the backend container's filesystem in Frankfurt as described in Section 5. Apart from these processors and the connections you request, we disclose personal data only where the law requires it, to establish, exercise, or defend legal claims, or — in the event of a corporate transaction such as a merger — to a successor bound by this policy. We never sell personal data.

7. International transfers

Some of our processors are US companies, so some processing happens in the United States. For those transfers we rely on:

• the European Commission's adequacy decision for the EU–US Data Privacy Framework (DPF), where the US processor is certified under and participates in the DPF; and
• the European Commission's Standard Contractual Clauses (SCCs) (Art. 46(2)(c) GDPR), supplemented where appropriate by additional safeguards such as encryption in transit, for processors that do not participate in the DPF.

Where a US-headquartered provider hosts data in the EU (Neon, Render, AWS, Sentry, and Cloudflare for retained room images), any access from outside the EU/EEA is likewise covered by SCCs or DPF certification at the entity level.

Nishimta AB itself is a Swedish company and is not a DPF-certified entity; these safeguards apply at the processor level, where the transfer actually occurs. You can request a copy of the relevant safeguards at privacy@nishimta.com.

8. How long we keep your data

• Account, content, and connection data: kept while your account is active. Deleting a conversation in the app archives it — it disappears from your view but its messages are retained until you ask us to erase them. Deleting a pin removes its pin record and routing data. A deletion record with your account identifier, the pin identifier and deletion time remains to prevent the pin from being seeded again. Room content, confirmation messages and audit history remain. Disconnecting a connection removes its credentials and authorization attempts but retains its connection record. Disconnecting Jira does not itself erase imported issue content, matched people or source records; these remain subject to the Jira refresh and redaction limits in Section 6. To have conversations, pins, connections, or your entire account permanently erased, email privacy@nishimta.com and we will delete the underlying database records; residual copies in encrypted backups expire on our backup rotation cycle, no later than 35 days after deletion from the live service. Claude-backend session files do not yet follow that deletion automatically and remain until the container filesystem is replaced or they are removed manually; this is a pre-launch gap. Removing the bundled pre-launch alias name, work email address, and photograph requires a source and client-build update. Copies already committed stay in existing clones and in the repository's history until we rewrite that history; deployment artifacts expire under the relevant provider's retention lifecycle. Data included in the generated knowledge repository also requires a corrected rebuild and removal of retained backend images and rollback copies. For a room with a bound Slack channel, the whole channel-side copy is independent and our deletion does not reach it: the room's messages, and the channel Aini created for it — its name, topic, purpose, and bookmark carrying the room's title, goal description, and deep link, plus its member roster — remain under your workspace's own retention policy (by default, for the workspace's lifetime on paid plans) until a workspace owner or member deletes or archives them in Slack. Our target is to remove those image and rollback copies no later than 90 days after the associated account or contract ends, but we currently have no automated control proving that every retained Render copy is removed within that target. If your account is terminated or closed under our Aini Terms of Service, we delete the associated data after a reasonable wind-down period, with residual backup copies expiring on the same rotation cycle.
• Stored AI context (when enabled): follows the conversation's retention. When we permanently erase your account or conversation after a request to privacy@nishimta.com, we also erase this copy; archiving a conversation does not erase it. Aini also deletes old context when it replaces the AI session, and when it replaces older context with a summary. The target is the contract period plus a 90-day export window; automatic expiry is not yet available.
• Authentication email records: the database purge is configured to clear recipient addresses and receiving-server replies from records older than 7 days and delete records older than 90 days. It runs one minute after the backend starts and then hourly while the backend runs; a stopped backend or failed purge delays removal. AWS delivery-event queues hold the feedback envelope, which can include recipient addresses and message headers. The delivery queue and its consumer dead-letter queue each have a configured retention of 4 days; the separate event-routing dead-letter queue has 3 days. Transfers and retries can extend the total time across these queues. Successfully processed events are deleted earlier.
• Retained room images: images posted to a room's shared channel without addressing Aini expire after 30 days and are then scheduled for deletion from R2. Permanent deletion of their message, room, or account also schedules the image objects for deletion. Cleanup is asynchronous and retries failures; a 30-day R2 lifecycle rule provides an additional deletion backstop. Archiving a conversation does not immediately delete these images. Copies already sent to an AI provider or written to Claude-backend session files follow the separate retention described in Section 5.
• Deletion on request: you can request deletion of your account and data at any time at privacy@nishimta.com.
• Error reports and performance measurements: Sentry retains web and extension error events for up to 90 days and performance traces for up to 30 days under our current trial retention schedule. Its event backups expire 90 days after creation.
• Server request logs: kept for up to 30 days for security and troubleshooting, then deleted; we may keep specific logs longer for the duration of a security-incident investigation, and never beyond 12 months.
• Legal retention and claims: we keep records longer where a law requires it (for example, bookkeeping records under Swedish law), and we may retain minimal account and contract records for up to 10 years after termination where needed to establish, exercise, or defend legal claims (Art. 17(3)(e)) — only those records, nothing more.

9. Your rights

Under the GDPR you have the right to:

• Access your personal data (Art. 15);
• Rectify inaccurate or incomplete data (Art. 16) — you can change your own first and last name directly in the web or MacOS app's personal settings; for anything else, contact us;
• Erase your data ("right to be forgotten", Art. 17);
• Restrict processing in certain circumstances (Art. 18);
• Data portability — receive data you provided in a structured, commonly used, machine-readable format (Art. 20);
• Object to processing based on legitimate interests (Art. 21); and
• Withdraw consent at any time where processing is based on consent (Art. 7(3)), without affecting processing that already happened.

To exercise any of these rights, email privacy@nishimta.com. Exercising them is free of charge. We will respond within one month (extendable by two further months for complex requests) and may need to verify your identity first.

You also have the right to lodge a complaint with a supervisory authority, in particular in the EU/EEA country where you live or work. Our lead supervisory authority is the Swedish Authority for Privacy Protection, Integritetsskyddsmyndigheten (IMY) — imy.se. We would, however, appreciate the chance to address your concern first.

10. Cookies

Aini uses only sign-in cookies, and none of them track you:

• Sign-in cookies (strictly necessary). A signed session cookie that keeps you signed in and secures your session. It holds only a random session identifier that page scripts cannot read. It expires after 7 days unless a session check renews it. Opening another page can trigger a check; activity on the same page does not renew it. Signing out ends the session. Without it, sign-in does not work.

Beyond cookies, the apps keep a small amount of similar on-device storage: the MacOS app keeps your sign-in in the operating system's keychain, the browser extension keeps its session in the browser's extension storage, and the apps remember interface preferences (such as collapsed panels and whether to use light mode, dark mode, or your system setting) in local storage.

That is the complete list. There are no analytics, advertising, or tracking cookies or storage — first-party or third-party. The sign-in cookies are strictly necessary; interface preferences are stored only when you actively use those functions, and you can clear them at any time. On that basis we do not show a cookie consent banner in Aini.

11. Security

We protect personal data with technical and organizational measures appropriate to the risk (Article 32 GDPR):

• Encryption in transit. All traffic between your devices, our services, and our processors uses TLS.
• Protected sessions. Sign-in sessions are carried in a signed session cookie that page scripts cannot read (web app), protected by the operating system's keychain (MacOS app), or kept in the browser's extension storage (browser extension). The apps use short-lived access tokens and rotating refresh tokens.
• Access controls. Production access is restricted to authorized personnel on a need-to-access basis and is logged.
• Processor obligations. Every processor listed in Section 6 is bound by contractual data protection obligations.

No system is perfectly secure. If a personal data breach occurs, we will notify IMY without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to your rights and freedoms. Where a breach is likely to result in a high risk to you, we will also inform you directly (Articles 33 and 34 GDPR).

12. Children

Aini is a professional tool. Under our Aini Terms of Service you must be at least 18 years old (or the age of legal majority where you live) to use it; the Service is not directed to anyone under that age and we do not knowingly collect their personal data. If you believe a child has provided us personal data, contact privacy@nishimta.com and we will delete it.

13. Things we do not do

For the avoidance of doubt:

• We do not sell personal data, and never have.
• We show no advertising and share no data with advertisers.
• We carry out no automated decision-making, including profiling, that produces legal effects concerning you or similarly significantly affects you (Article 22 GDPR). The AI generates content in response to your requests; it does not decide anything about you.

14. Changes to this policy

We may update this policy as the Service or the law changes. When we do, we will update the "Last updated" date above and, for material changes, notify you in the product or by email before the change takes effect. The current version is always available where you accessed this policy; earlier versions are available from us on request.

15. Contact

Questions, requests, and complaints about privacy at Aini all go to the same place:

Nishimta AB
Stockholm, Sweden
Email: privacy@nishimta.com

We read everything sent to that address, and a person will answer you.