Privacy Policy

QuinnAI is an AI operating system for businesses. Your organisation gets its own agent runtime, its own database schema, its own object storage bucket, and its own vector memory namespace. This policy explains what we hold, why we hold it, and how long.

• We do not train models on your data, and we never use one customer’s data to serve another.
• Learning is opt in. An interaction only becomes long term memory when it is flagged contributable, and that memory stays scoped to your organisation.
• Agent prompts and outputs are sent to the model providers your organisation configures. We tell you which ones below.
• You control how long raw interaction logs are kept, from 1 to 365 days.
• Deleting an account stops access and tears down the compute. It does not by itself erase records. Ask us if you need erasure.

This summary is for orientation only. The sections below govern.

Applied Physics Quantum Ltd. operates QuinnAI. We handle two different kinds of data, and our role differs for each.

Data we control

Account and organisation records, sign in activity, waitlist entries, support correspondence, platform audit logs, and usage and cost telemetry. We decide why and how these are processed, so we are the controller.

Data we process for you

Everything your organisation puts into the platform or connects to it: prompts, conversations, knowledge documents, persona instructions, integration content, and revenue data. Your organisation decides why and how these are processed, so we act as a processor on its instructions.

If you are an employee of a customer organisation, your employer is the controller of your work content. Requests about that content should go to your organisation’s owner or admin first. We will help them respond.

Account information

Email address, display name, a hashed password, platform role, organisation memberships with their role and permission grants, active status, and the timestamp of your last sign in. We never store your password itself.

Organisation information

Organisation name and slug, status, settings such as the default learning preference and the retention window, and the identity of whoever invited each member.

Content you provide

Chat messages, one off task prompts, conversation titles, persona instructions and tone, uploaded knowledge documents, skill definitions, and trigger prompt templates.

Agent activity

For every task we record status, timing, the model that ran, token counts and estimated cost, the tools the agent called, any error, and a truncated preview of the prompt and the response so the console can show you the turn. Streaming events for a turn are stored so the transcript survives a refresh.

Credentials for connected services

OAuth access and refresh tokens, API keys, and the scopes granted, held encrypted. We also keep non secret facts about the connected account, such as the email address it belongs to and when it was connected, so the console can show you which account an agent is spending.

Governance records

Audit log entries naming the actor, the action, the subject, and the time. Approval decisions. Notifications generated for you. Spend against your caps.

Waitlist information

If you join the waitlist we store your email address, an optional name, where you signed up from, your position, and any invite code issued to you. We use your IP address in memory only, to rate limit the public form. It is not written to the database.

Email records

For every message we send you we log the recipient, subject, template, and delivery status.

The public site runs no advertising or analytics trackers. We do not buy personal data from brokers, and we do not build advertising profiles.

An agent only sees what your organisation gives it. That is the prompt for the current turn, the persona instructions attached to it, the knowledge documents linked to that persona, prior turns in the same conversation, tenant scoped memory when learning is enabled, and whatever the tools it is allowed to call return.

When an agent calls a connected service it acts on a credential your organisation supplied. Content it reads back, an email thread, a CRM record, a calendar entry, passes through the agent runtime and may appear in the turn transcript and in the task record. Treat anything you connect as in scope for this policy.

Where an integration is configured for per user connections, the agent uses the acting person’s own credential. If the platform cannot resolve exactly who a turn belongs to, it refuses the call rather than spending someone else’s account.

• To run the service: provisioning your agent runtime, executing tasks, routing to models, and calling the tools you have connected.
• To authenticate you and enforce roles, permissions, and approvals.
• To show you what happened: transcripts, task history, audit trails, analytics, and notifications.
• To meter usage and cost, and to enforce the spend caps your organisation sets.
• To keep the platform secure and available, including rate limiting, abuse prevention, and debugging failures.
• To support you when you contact us, and to send service messages such as invites, security notices, and changes to this policy.
• To meet legal obligations and to establish, exercise, or defend legal claims.

Where the law requires a legal basis, we rely on performance of our contract with you, our legitimate interest in operating and securing the platform, your consent where we ask for it, and compliance with legal obligations.

This is the part people ask about most, so it is stated plainly. We do not train, fine tune, or evaluate any model on your data. We do not pool data across customers. Nothing your organisation puts in becomes another organisation’s answer.

Every interaction carries a contributable flag. Your organisation sets the default and any user can override it for a single task.

When contribution is off

Nothing is written to vector memory or to your object storage bucket. The prompt is stripped from the queued job once the task finishes, and the job record is kept for a shorter period.

When contribution is on

The interaction is passed through a sanitizer that redacts private keys, API tokens, JWTs, email addresses, phone numbers, and US social security numbers. The sanitized text is embedded and written to a vector namespace scoped to your organisation, and the raw record is written to your organisation’s own storage bucket under your retention window.

Separately, and regardless of the flag, every agent output runs through governance validation before it is returned. Findings at or above the configured severity block the response. This is a safety control, not a promise that every sensitive string will be caught. Redaction is pattern based and cannot recognise every format.

Turning contribution off later stops new writes. It does not retroactively remove memory already written. Ask us and we will purge a namespace.

Isolation is enforced at every layer rather than by application logic alone.

• Database: each organisation’s records are partitioned by tenant, and every query path is tenant scoped.
• Compute: each organisation gets its own agent runtime in its own Kubernetes pod, with its own credentials and its own network egress policy.
• Object storage: each organisation gets its own bucket. Raw interaction records and knowledge documents are written there, not to a shared store.
• Vector memory: each organisation gets its own namespace. A similarity search cannot reach across it.
• Credentials: the key each agent runtime uses to call back into the platform is unique to that organisation, encrypted at rest, and rotatable.

The platform is model agnostic. A routing layer sends each task to a model chosen for its risk and cost, and your organisation configures which models are in play.

• Anthropic models, when your organisation routes to them.
• OpenAI models, when your organisation routes to them.
• Open source models we host, where the prompt does not leave our infrastructure.
• Any custom endpoint your organisation configures, including a model you run yourself.

When a task runs on a third party model, the prompt and the context assembled for it are sent to that provider and are subject to that provider’s terms and privacy policy as well as this one. Choosing a self hosted model keeps the prompt inside our infrastructure. Your admin console shows which model handled every task.

A short lived title for each conversation is generated from your first message by the same routing layer.

Connecting a service is an explicit act by an admin or, for per user connections, by you. We store the resulting credential encrypted and use it only to perform the actions your agents are permitted to take.

Available connectors include email and calendar providers such as Gmail and Outlook, CRM and business platforms such as Bitrix24, and, for the Growth Command Center, advertising and analytics sources such as Google Ads, GA4, and Search Console, along with call tracking and commerce platforms. Each connector requests the narrowest scopes that let it work, and the scopes granted are shown in the console.

You can disconnect at any time from the console. Disconnecting revokes and deletes the stored credential. Records of what the agent did while connected remain in your task history and audit log.

We are not responsible for how a third party service handles data once it is in that service. Their terms govern there.

If your organisation enables the Growth Command Center, we ingest marketing and sales records from the sources you connect so the platform can attribute revenue.

Those records can contain personal data about your prospects and customers, including names, email addresses, phone numbers, company, deal values, and links to call recordings and transcripts held by your call tracking provider. We store this in your organisation’s isolated schema and use it only to produce the attribution, recommendations, and briefs you asked for.

You are the controller of that data. You are responsible for having a lawful basis to collect it and to send it to us, and for telling the people it describes.

We do not sell personal data and we do not share it for cross context behavioural advertising. We disclose it only in these cases.

Sub processors

Infrastructure and hosting, managed databases, object storage, and email delivery providers, engaged under contract and used only to run the service. A current list is available on request.

Model providers

The providers your organisation routes to, as described above.

Services you connect

The integrations you authorise, only for the actions your agents take.

Within your organisation

Owners and admins can see organisation wide activity, including task history, audit logs, spend, and approvals. Your work in the platform is visible to them.

Legal and safety

Where we must comply with law or valid legal process, or to protect our rights, our users, or the public. We will tell you unless we are legally prevented.

Business transfers

If we are involved in a merger, acquisition, or sale of assets, data may transfer with the business. This policy continues to apply until it is replaced with notice to you.

Raw interaction records

Kept in your organisation’s storage bucket for the retention window your admin sets, from 1 to 365 days, then expired.

Task and conversation history

Kept in the control plane for as long as your organisation is active, so the console can show you your own history, unless you delete it.

Vector memory

Kept while the organisation is active. Purged on request, or when the organisation is erased.

Audit logs

Kept for the life of the organisation. They are the record of who did what, so they are deliberately not user editable.

Account records

Kept while the account exists, and afterwards only as long as needed for legal, accounting, or dispute purposes.

Waitlist entries

Kept until you register or ask us to remove you.

Be aware of what account deletion does and does not do. Deleting an account in the platform console deactivates sign in and tears down the agent runtime behind every organisation that person owns. It stops access and stops spend. It does not erase the database rows, the storage bucket, or the vector namespace, because those remain the auditable record of what happened. If you want genuine erasure, ask us and we will carry it out.

• Passwords are stored as salted PBKDF2 SHA256 hashes, never in plain text.
• Integration credentials and agent keys are encrypted at rest with AES 256 GCM. Agent keys are looked up by hash, so reading the database yields no usable credential.
• Traffic is served over TLS.
• Access inside the platform is role based, and permissions are checked per action rather than per screen.
• Each agent runtime has locked down network egress and its own Kubernetes secret.
• Administrative actions are written to an append only audit log.

No system is perfectly secure. If you believe you have found a vulnerability, write to [email protected] and we will work with you. We will notify affected customers and regulators of a qualifying breach within the timeframes the law requires.

We use no advertising cookies and no third party analytics. The console keeps your session token and active user identifier in your browser’s local storage so you stay signed in. Clearing site data signs you out.

Depending on where you live, you may have the right to access the personal data we hold about you, correct it, delete it, receive a portable copy, restrict or object to certain processing, and withdraw consent. You also have the right to complain to your data protection authority.

To exercise a right over your account data, write to [email protected]. We will verify your identity and respond within the period the law allows. For content inside a customer organisation we act on that organisation’s instructions, so we will refer you to its owner or admin and help them respond.

We do not use your personal data for automated decisions that produce legal or similarly significant effects on you. Agents act inside the permissions and approval rules your organisation configures.

We and our sub processors may process data in countries other than yours. Where data leaves a region that restricts transfers, we rely on an approved transfer mechanism, such as the standard contractual clauses, together with technical measures like encryption in transit and at rest.

QuinnAI is a business product and is not directed at children. We do not knowingly collect personal data from anyone under 16. If you believe we have, tell us and we will delete it.

We update this policy when the product changes. The effective date at the top always reflects the current version. For material changes we will give notice in the console or by email before they take effect.

Privacy questions and rights requests: [email protected]. Security reports: [email protected]. Anything else: [email protected].

Applied Physics Quantum Ltd., [registered address].