Privacy Policy
Recorded Effective Date: 30 May 2026
Recorded Last Updated: 30 May 2026
Draft prepared: 6 October 2026. Pending activation. Recorded dates concern the preceding version.
Draft revised: 7 October 2026. Activation remains pending.
Non-binding summary. We process account, project and billing data to provide the Service. Contact forms send your message, contact details and any attachments to support. Optional marketing, improvement and training require separate choices. Account settings and support provide routes to withdraw consent and exercise your data rights. This summary is outside the operative notice.
1. Controller and scope
1.1. Igor Tkachenko OwlMeans Software (trading as “OwlMeans Software, JDG”), NIP 6772507251, EU VAT identifier PL6772507251, REGON 527979906, ul. Ariańska 9/5, 31-505 Kraków, Poland; support@owlmeans.com; telephone +48 780 256 571 (“OwlMeans”), controls its website, account administration, billing, security and any separately authorised optional uses. For personal data in customer repositories, projects or hosted applications processed on customer instructions, the customer is controller and OwlMeans processor under the DPA. Organisation administrators can manage access and view authorised organisation records. A generated application’s operator provides its own end-user privacy notice.
2. Data and purposes
| Data | Purpose and GDPR basis for OwlMeans’ controller processing |
|---|---|
| Email, name, identity-provider identifiers, authentication/session records, organisation membership, roles and permissions | Account access and administration: Article 6(1)(b) for an individual’s contract; 6(1)(f) for business-user administration and security. |
| Prompts, stories, source/imported repositories, outputs, project histories, conversion state, traces, usage and deployment/domain metadata | Requested development and support: 6(1)(b), or customer instructions under the DPA; proportionate security and fraud investigation: 6(1)(f). Traces can contain submitted content. |
| Integration tokens, configuration and secrets submitted through designated controls | Authorised integrations and deployment, under the contract or DPA; access limited to the required operation. Ordinary prompts should contain no credentials. |
| Billing country, tax identifiers, payment-provider references, invoices, payments, credit ledger, withdrawal/cancellation declarations and financial consent evidence | Contract performance: 6(1)(b); accounting/tax duties: 6(1)(c); proportionate fraud/dispute evidence: 6(1)(f). Spend-admission records include IP, user agent, operation/channel and project/story references, which may retain a title after deletion. |
| Consent decisions, purpose/text revision, timestamps, language, source and acceptance evidence; preference identifiers | Demonstrating choices and respecting refusal: 6(1)(c), where required, and 6(1)(f) for a limited suppression/evidence record. Optional purposes themselves use 6(1)(a). |
| Connection information such as IP address and browser/device metadata, interaction or challenge signals, verification tokens and security assessment results exposed by the deployed Google reCAPTCHA integration | Bot, fraud and abuse prevention: Article 6(1)(f), subject to necessity, balancing and the separate terminal-access conditions in the Cookie Policy; no optional marketing or own-model-training permission. |
| Inquiry email address, subject and message; optional contact preference, phone number, messenger identifier or proposed call details; attachments and their filenames, types, sizes and embedded content/metadata | Responding to your requested quote, booking discussion, question, issue, payment query or other support request: 6(1)(b) where necessary for your contract or requested pre-contractual steps, or 6(1)(f) for business-contact administration and requested assistance. Rights/complaint handling also uses 6(1)(c) where required. Contact preferences and attachments are optional. |
| Inquiry identifier, widget/topic and topic title, interface language, originating page, linked Terms/Privacy URLs, required-checkbox indication and server receipt timestamp; delivery and security records | Routing and evidencing the request, providing support, preventing abuse and handling claims: 6(1)(b)/(f), or 6(1)(c) for applicable rights/complaint duties. The normal form’s page field contains origin and path, without query string or fragment; paths and attachments can still reveal personal or project information. The timestamp records receipt, not a verified identity or immutable copy of the linked documents. |
| Diagnostic/browser/network records, IP-derived rate-limit keys, security challenge/token records and inquiry delivery/failure logs | Proportionate security, delivery troubleshooting and abuse prevention: 6(1)(f). IP-derived identifiers remain potentially personal data. Optional inquiry-opening measurement uses consent, 6(1)(a), independently of the request. |
| Guest prompt and handoff reference, temporary browser drafts, selected language and cookie choices | Requested handoff and preferences: 6(1)(b)/(f); device-storage rules are described in Cookies. |
2.1. Required data is needed to authenticate, deliver requested work, charge purchases or meet legal duties; refusal may prevent that specific operation. Optional refusal does not prevent core access. Data comes from you, organisation administrators, connected identity/repository/payment services and your interactions. Processing customer application end-users follows customer instructions; we do not obtain optional training permission from their operator’s account checkbox.
2.2. The website and Platform inquiry forms require an email address, subject and message, and selection of an initially unchecked checkbox to accept the inquiry-use Terms and acknowledge this Privacy Policy. That checkbox is not GDPR consent to optional processing or a waiver of rights. It does not create an account, verify ownership of the email address, buy a plan or give marketing, profiling, partner, improvement or model-training permission. The inquiry service uses a single-use anti-bot guest credential rather than the signed-in Platform account credential. The form sends the message and any selected attachments only on submission; opening it already starts the security processing described in the Cookie Policy. Missing required fields can prevent this form’s submission, while the contact channels in section 10 remain available for statutory requests.
2.3. We use contact preferences to discuss the inquiry, rather than to enrol you in unrelated phone, messenger, video or email marketing. A named messenger/video option or an example in the form is not an automatic connection to that service. If a separately agreed reply or call uses an external provider, its identity, relevant data and privacy conditions must be made available before that use. The inquiry service delivers messages to support and does not itself send their contents to an LLM. Inquiry messages, suggestions and attachments are excluded from the optional improvement and own-model-training inputs described below; selecting an improvement topic does not grant reuse permission. Please send only information needed for the request, remove unnecessary file metadata, and arrange a suitable protected channel before sending credentials, special-category data or other people’s confidential/personal information.
3. Recipients and international processing
3.1. Authorised staff, support and professional advisers receive data as necessary. Hetzner is the current sole infrastructure supplier; Mailgun delivers email; Google Tag Manager and Google Analytics provide optional, consent-gated measurement; Sentry provides diagnostics. Depending on their verified configuration, these services receive hosted account/project records, email addresses and message contents, browser/network identifiers and measurement events, or error reports and diagnostic context respectively. Secrets and project content must be excluded from optional measurement and minimised in diagnostic reports. Actual entities, locations, retention and safeguards must be completed in the Subprocessor schedule before this revision activates. Google reCAPTCHA is a separate active security service for bot, fraud and abuse prevention in selected protected workflows. Google receives the connection, device and challenge information exposed by that integration and returns verification or risk-assessment results. Under the applicable Google Cloud terms, Google processes reCAPTCHA Customer Data as a processor for the security service; the actual account entity, contract, locations and retention must be verified. This use is distinct from Google Analytics and Google sign-in and does not authorise advertising, marketing profiling or own-model training. If a security check blocks a requested operation, contact support for assistance.
3.2. Active services also include OpenAI, Anthropic, OpenRouter, Together AI and Hugging Face for the AI/model routes or model access actually selected; GitHub for connected repository/OAuth operations; Google sign-in for authentication; Stripe for payments; and Cloudflare for configured network, domain or security functions. AI inference recipients receive the prompts, permitted context and related request/output data needed for the selected call; model-download services need not receive project content merely because a model is downloaded. Connected identity and repository services exchange authorised identity, permission, token and repository information. Stripe handles payment credentials and relevant transaction information; OwlMeans retains billing references and evidence. Cloudflare receives network/request information and content to the extent its actual service carries it. The schedule distinguishes these services’ roles and actual processing; listing an active service does not mean every project is sent to every supplier. Local/delegated inference uses customer-selected infrastructure for those calls, while Platform authentication and other data may remain remote. Actual account entities, locations, retention and safeguards remain to be completed before activation.
3.3. Processing can involve recipients outside the EEA. Before a restricted transfer, the applicable recipient, destination and lawful safeguard must be established, such as a valid adequacy decision or appropriate contractual clauses with supplementary measures where required. No blanket US adequacy, EU-only hosting or executed-SCC claim is made. Request recipient and safeguard information or copies, with lawful redactions, at support. A customer-selected independent service has its own notice; selection does not waive our obligations.
3.4. In the configured inquiry flow, inquiry text, contact information, routing/receipt evidence and selected attachments pass through the inquiry service on OwlMeans’ Hetzner infrastructure and Mailgun email transport to the designated OwlMeans support mailbox hosted using Google Gmail. Gmail receives and stores that correspondence and its attachments for handling by authorised recipients. Google reCAPTCHA receives its security signals; the form does not deliberately send it the message or attachment contents. Opening the dialog can generate the consent-gated inquiry_dialog_open event with inquiry_widget, inquiry_tab and inquiry_source; these event fields describe the dialog and trigger, rather than your email, message or files. Other Google measurement metadata depends on the separately disclosed tag configuration. The actual Gmail account/service and Google contracting entity, contractual role, authorised mailbox access, locations, retention, DPA and transfer safeguards must be verified before activation. Mailbox and onward handling remain separate from Mailgun delivery; no unverified processing location or retention period is asserted.
4. Retention and security
4.1. Account and project data is retained while necessary for the requested relationship and then removed or returned subject to justified legal holds. Financial, tax, security and consent evidence is retained only for the applicable legal duty or documented claims period. Current payment/consent ledgers and traces do not all have automatic deletion timers; a timer’s absence is not authority to retain indefinitely. Spend-admission evidence has a configured 760-day expiry. Deleting a project does not automatically erase billing, consent or trace evidence. Backups and supplier copies require separate handling; no immediate universal erasure promise is made.
4.2. Guest-prompt server handoff expires after 120 seconds and is single-use; a retrieved browser draft is logically valid for 24 hours, with expired records removed on a later read rather than guaranteed timed physical deletion. A suspended sign-in continuation has a 30-minute logical deadline and is removed when consumed or discarded; that deadline does not schedule physical deletion of other authentication state. Other browser storage follows the Cookie Policy. Measures must be appropriate to risk, including access controls, confidentiality and restricted secret handling. Do not send sensitive or third-party personal data without a lawful basis and appropriate safeguards. No certification or universal encryption guarantee is asserted.
4.3. Authentication and workflow data includes browser-held bearer credentials, session/version/skip markers, redirect state and temporary input. Browser authentication records and some localStorage markers have no automatic expiry; ordinary app sign-out removes the main stored auth record without clearing every marker, ending every provider session or revoking independent API/OAuth credentials. Clearing browser site data and server-side revocation are separate actions. The current manager implementation and current generated-app template cap their app-session validity at 7 days from issuance; revocation, provider-token invalidity or loss of the required server session record can end validity sooner. Existing customer-app versions and deployment settings require their own verification. Integrated OIDC defaults are 1 hour for access/ID tokens and interactions, 60 seconds for authorisation codes and 14 days for sessions/grants/refresh tokens, subject to the actual scope and configuration. Separate Platform connector access tokens default to 90 days; a user-created API token can have a requested expiry up to 366 days or no fixed expiry where omitted, and can be revoked. Expiry or revocation does not itself prove deletion of all associated records. Interface/privacy preferences, prompt/landing values, pseudonymous guest ownership keys and optional event-deduplication state are disclosed in the Cookie Policy, with customer-app and deployment distinctions. Necessary retention must remain proportionate even where no automatic timer exists.
4.4. Pending inquiry records and attachment copies in the dedicated CRM database are configured for removal after the email transport reports successful sending. A seven-day expiry from receipt is the fallback for undelivered records or failed cleanup; database expiry is asynchronous and is not a promise of deletion at an exact instant. Delivered email and attachments, email-provider records, restricted legal/complaint evidence, security logs and backups have separate lifecycles. Correspondence is retained only as needed to resolve the request, maintain an ongoing engagement or meet a documented legal/claims duty, then reviewed for deletion under section 4.1; the CRM’s seven-day expiry does not erase those copies. The form keeps an unsent draft in page memory across closing/reopening and topic changes, without its own localStorage/IndexedDB save; a successful draft clears when its confirmation closes, and page unload or widget removal ends that in-memory state. Closing an unsent dialog alone does not clear it. Rights requests apply to all relevant copies, not only the temporary CRM record.
5. Optional email marketing
5.1. Separate consent permits OwlMeans product news and offers by email. Decline or withdraw through account preferences, an unsubscribe facility or support; service, security and legal emails remain necessary. SMS, phone and push marketing are not included. A retained suppression record prevents further unwanted contact.
6. Optional agent and pipeline improvement
6.1. This separately consented proposed purpose would evaluate eligible prompt text and generated outputs to improve prompts, agent behaviour and development workflows without training OwlMeans model weights. It remains inactive. Imported repositories and files, attached or retrieved content embedded in a prompt, hosted application/end-user data, secrets, sensitive personal data and unauthorised third-party material are excluded. Merely placing excluded material inside a prompt does not make it eligible. Supplier-output permissions, eligibility checks, defined limited retention, access controls and withdrawal enforcement must be established before activation. Essential operational diagnostics and work requested for your own project are separate proportionate purposes; they do not authorise optional reuse for OwlMeans’ independent improvement datasets.
7. Optional training of OwlMeans models
7.1. A distinct opt-in would permit eligible prompt text and generated outputs to train and evaluate OwlMeans’ own models. This proposed use remains inactive. It excludes imported repositories and files, attached or retrieved content embedded in a prompt, hosted application/end-user data, secrets, sensitive or special-category data and content for which you lack authority. Supplier-output restrictions and third-party rights apply even where you consent; output ownership alone does not permit competing-model development. Before activation, the permitted source/provider/model must be recorded and the actual reuse rights, filtering, dataset access, defined retention and deletion controls must be implemented and disclosed. Existing combined training/improvement grants do not authorise either new purpose.
7.2. Refusal does not reduce purchased access. Withdrawal stops future collection and use for this purpose and requires removal from pending training datasets/jobs where applicable. Training already lawfully performed is not retrospectively unlawful. Removing influence from an existing model is not automatically technically possible; models are not presumed anonymous. Requests for erasure and other rights must be assessed separately, including risks of memorisation; necessary remediation cannot be replaced by a blanket exemption. A revised purpose requires a new choice, not migration of an old broad grant.
8. Profiling proposal: inactive
8.1. No permission for personalised offer profiling is sought under this draft. A future proposal would need defined usage/preferences inputs, logic, consequences, retention and a separate opt-in. It would not authorise solely automated legally significant decisions or sensitive-data inference. Neither ordinary account limits nor necessary fraud controls imply marketing profiling consent.
9. Partner-marketing proposal: inactive
9.1. No disclosure for partners’ own marketing is authorised. Before any future proposal, recipients, shared fields, controller roles, destinations and each purpose must be named and separate optional permission obtained. Existing marketing, profiling or training grants cannot supply that permission.
10. Rights and regional provisions
10.1. Contact support to request access, correction, erasure, restriction, portability where applicable, or object to legitimate-interest processing. Object to direct marketing at any time and withdraw consent as easily as it was given. We may proportionately verify identity, and normally respond within one month, explaining any lawful extension or refusal. For customer-controlled application data, contact its operator; OwlMeans assists under the DPA. Complain to UODO in Poland or the competent authority in your EEA residence/workplace; UK GDPR rights apply where in scope.
10.2. Applicable US state laws may provide access, correction, deletion, portability, appeals and opt-out rights for sale, sharing, targeted advertising or certain profiling. CalOPPA privacy-notice duties can apply without meeting the separate CCPA/CPRA business thresholds; other state scopes require their own assessment. Google Ads, partner marketing and personalised marketing profiling are not active Platform purposes. Applicable Global Privacy Control signals must be honoured for covered uses. We do not discriminate for exercising statutory rights. The Service is intended for adults; an age condition alone does not remove obligations if children’s data is actually processed. Children’s use and sensitive-data optional reuse are not authorised. Material notice changes shall be announced; optional new purposes require fresh consent.
10.3. Browser Do Not Track is distinct from Global Privacy Control and is not an optional consent grant. No automatic Do Not Track response has been verified; optional tracking remains governed by cookie choices and applicable opt-out law. Confirmed Google measurement and Sentry diagnostics may involve third-party identifiers as configured and disclosed in the Cookie Policy; their presence does not permit unrelated advertising or tracking across other services.
10.4. The inquiry dialog’s data-deletion topic forwards a request for handling; it does not itself delete an account, project, email or supplier record. A submission receipt indicates queue acceptance, rather than completed delivery or a substantive decision. You may also request rights or report a blocked form using support@owlmeans.com, the postal address or telephone in section 1.1, without signing in, enabling analytics or accepting an optional purpose. No general Terms-acceptance condition limits statutory rights. We may ask only for proportionate information needed to identify the relevant data and requester; do not send passwords or unrelated identity documents.