Data protection, privacy and security

Liffey is your business's commercial brain. It connects to your business documents, files, and knowledge sources, indexes them into a secure knowledge base, and makes them available to an assistant that your team can query in plain language.

We hold the following categories of data on your behalf:

We do not hold payment card data, national identity numbers, health data, or any special-category personal data under GDPR.

You can connect external sources to Liffey: documents, folders, websites, email threads, and third-party platforms such as Google Drive, Microsoft 365, Slack, or GitHub. Connecting a source does not give Liffey permanent access to your systems. We read the content you authorise at the time of connection and at each sync, then immediately derive our own representation of it. The live source files themselves are never stored by Liffey.

What we do store is a derived version: the text we extracted and a numerical representation (embedding vector) of each passage. This derived version lives in your workspace's knowledge base in our EU database. It is used exclusively to answer your team's queries; it is never shared with other customers or used to train AI models.

Content reaches your knowledge base by routes you control: connecting a system, uploading a document, adding a web page, forwarding to your workspace address, and, since August 2026, a connected AI tool passing in a document on a member's behalf. Every one of them arrives on the same governed path described below, so redaction, chunking, retention and the audit record apply identically whichever route was used. A connected tool needs write permission to add anything, its role is checked on that call as on every other, and what it adds appears in your Connected Sources list as its own entry, attributed to the member, with the same archive and purge controls as a document somebody uploaded by hand.

The ingestion process works as follows:

1. Liffey reads the content of the source using the access you have authorised.
2. The readable text is extracted (parsing PDFs, Word documents, spreadsheets, and so on where applicable).
3. The text is split into overlapping passages of approximately 500 words.
4. Each passage is converted into an embedding vector (a compact numerical representation of its meaning) using an EU-hosted AI model.
5. The passage text and its embedding vector are stored in your workspace's EU knowledge base. The original file is not retained.

Public websites are a special case at step one, because a site behind a bot filter will refuse an automated reader on the source address alone. Where that happens, the page is read a second time through a hosted reader (Apify, listed in section 7). It is sent the address of the page and returns the page; content from your workspace stays with us. Everything from step two onwards is the same pipeline.

When a member asks Liffey a question, the question itself is converted into an embedding vector, and the most semantically relevant passages are retrieved from the knowledge base. Those passages, together with your Commercial Brain content, are sent to the AI model in-EU to generate an answer. Liffey applies a recency weighting so that more recently added content is preferred when sources conflict or overlap.

Removing connected sources and extracted knowledge

You are in full control of what stays in your knowledge base. At any time you can remove a connected source. When you do, you choose between two outcomes:

Individual documents within a source can also be archived or purged independently through the Knowledge Base section of your settings, giving you document-level control without disconnecting the entire source.

Who can use a connected source

A connected source uses your authorisation to read your account, so control over it stays with you. Only the person who connected a source can browse the original system or pull new content from it, and only they can change what it indexes. No other member, including a workspace owner, can use your connection to reach into your account and pull anything you have not approved.

Once content has been approved and indexed, it becomes part of the shared knowledge base and every member can read it through Liffey, which is the purpose of a shared brain. What stays restricted to you is the act of reaching back into the original source.

You control two settings per source: whether it refreshes automatically each day, and whether teammates may trigger a refresh on demand. A teammate refresh only re-reads the content you already approved; it can never browse your account or widen what is indexed.

Web pages the assistant adds for you

When a member references a specific public webpage in a conversation, the assistant can fetch that single page and add it to the workspace's Web Links, exactly as if the member had added it by hand. The same pipeline and the same guards apply: HTTPS only, one page at a time, never a crawl, and requests that resolve to private or internal network addresses are refused, on the initial request and on every redirect hop, with size limits on what is fetched and indexed. A fetch can only happen inside a live conversation, in direct response to a member: there is no background browsing and no scheduled fetching. The assistant is instructed to fetch only pages the member has raised, and its behaviour is checkable after the fact: every fetch, including refused and failed attempts, is recorded in the audit trail as an assistant action attributed to the requesting member, every added page appears in your Connected Sources like any other Web Link, and any of them can be archived or purged at any time.

Liffey operates two distinct knowledge layers. Understanding the difference is important for assessing how your data is used:

Since August 2026 the Commercial Brain is also indexed for meaning, in the same way the knowledge base always has been, so a question phrased in your own words reaches the component your team wrote rather than only the material around it. It is a derived index over content you have already authored and approved, held in the same EU database and scoped to your workspace on every query exactly as everything else is.

Neither layer is shared with other customers: every record carries a workspace identifier and is scoped to it on every query. Core customers run on a dedicated database instance holding no other customer's data; enterprise self-host runs entirely inside your own cloud boundary.

Everything above describes data coming in. This section describes how your team reaches it, because each route is a place your content is read and, in one case, leaves our environment. Every route is off until an owner turns it on.

Every read through any of these routes is recorded in your audit log with the person, the route and the time.

Liffey is built for EU data residency. Your database, application compute, and all AI processing run within the European Union. The full picture:

Source systems you choose to connect (Google Drive, Microsoft 365, Slack, GitHub, and so on) are governed by their own terms of service. Liffey reads only what you authorise, processes the content in-EU, and stores only the extracted text and embeddings as described above.

Customer isolation is tiered to match how you use Liffey. Trial and entry workspaces run in a shared EU database with row-level isolation enforced and verified on every request. Core customers run on a dedicated database instance: their own database, storage, backups, and encryption key, with no other customer's data in it (live today). Enterprise customers can run the same platform self-hosted, with the database inside their own cloud boundary. Layer by layer, the isolation each tier provides:

Operator access is identical on every tier: none standing; explicit, time-boxed, audited elevation only (see below).

Every tier is protected by the following controls:

• Row-level tenant isolation. Every record in the database carries a workspace identifier. Every query and API request is scoped to that workspace and verified before execution.
• Isolated content storage. Each workspace's Commercial Brain and knowledge base live in per-workspace records in the EU database, scoped by a workspace identifier on every row. Content is never held in a shared file system.
• Encrypted credentials. Access tokens for connected sources are encrypted with AES-256-GCM at the application layer (in addition to database-level encryption at rest) using a key held separately from the data. A database breach alone cannot expose your credentials.
• Invite-only access. Your workspace is accessible only to email addresses you explicitly invite. Sign-in uses one-time codes sent to verified email addresses (no passwords). There is no self-sign-up.
• Role-based permissions. Owners can edit and approve changes to the Commercial Brain. Members can query and contribute. Neither role can see data from another workspace.
• Personal-identifier redaction at ingestion. Every workspace can enable PII redaction: email addresses, phone numbers, and bank identifiers are replaced with typed placeholders at the moment content enters the platform, before anything is stored, indexed, or processed by AI. Redacted identifiers therefore never exist in the database, in search embeddings, or in model context. The redaction rules are deterministic patterns, enumerable on request for audit.
• No standing operator access (break-glass). Liffey platform operators hold no standing access to your workspace. Operator access requires an explicit, time-boxed elevation with a stated reason; every grant and its reason are recorded in the audit log and expire automatically. There is no silent administrative route into your data.
• Append-only audit log. Every significant action (brain edits, source connections, member changes, AI commits, operator access grants) is logged with the actor, timestamp, and before/after state. Immutability is enforced at the database layer: the application's database role is not permitted to modify or delete audit records.

Liffey uses foundation AI models to power the assistant. The following commitments apply:

• Your data is not used to train AI models. Anthropic and AWS operate under enterprise terms that prohibit using customer inputs to train or improve their models.
• Zero data retention at the AI layer. Prompts and responses are processed in memory and are not stored by the AI provider.
• AI processing stays in the EU. Both the inference model and the embedding model are served from AWS Frankfurt (eu-central-1). Your prompts and retrieved knowledge are processed in-EU and are not sent to US AI infrastructure.
• Query expansion. To improve search quality, Liffey generates alternative phrasings of your question before retrieving knowledge (multi-query RAG). These alternative phrasings are generated using a lightweight AI model and are treated with the same data handling as the original query.
• These commitments describe the AI processing Liffey performs. Where you connect your own AI tool (section 3a), that provider processes what it reads under your own agreement with them, so the terms that apply there are the ones you hold. Connecting a tool stays a per-person, per-tool decision for that reason, visible and revocable in your settings.
• Liffey proposes; your team decides. The assistant can draft content and suggest updates to the Commercial Brain, and an owner approves every one of them before it enters the authoritative layer. Two things it does on its own initiative, and both stop short of that layer. It can fetch a public webpage during a member's conversation, which is stored as a normal, audited, removable knowledge source (see section 2). And since September 2026, where a component's written body has moved on and its slides still make the previous argument, an hourly pass drafts a replacement deck and files it in the same owner review queue, so a person approves a diff rather than finding a rewrite. Committing to the Commercial Brain stays with your owners.

Liffey uses the following sub-processors to deliver the service. All are under data processing agreements consistent with GDPR:

The complete, current sub-processor list and our standard Data Processing Agreement (DPA) are available on request at hello@liffey.ai.

Access to your Liffey workspace is controlled at multiple layers. We have deliberately avoided passwords: they are the most common source of credential breaches and they put the security burden on your team. Instead, Liffey uses the following model:

Infrastructure security

• Encryption in transit. All connections use TLS 1.2 or higher.
• Encryption at rest. The EU database is encrypted at rest by the hosting provider (Neon). Source credentials are additionally encrypted at the application layer with AES-256-GCM.
• Least-privilege service accounts. Each internal service (database, AI inference, email) has its own isolated credentials scoped only to what it needs. A breach of one service account cannot be used to access others.
• Audit logging. All significant actions are logged immutably. Logs are used for security review, incident response, and customer-requested audit trails.
• Backups. The database has continuous point-in-time recovery. Backups are stored within the EU.
• Source disconnection. When you remove a connected source, you can choose to archive (retain the extracted knowledge, hide the source) or purge (delete the source record, the extracted items, and all knowledge chunks). Purge is irreversible.

Under GDPR and applicable data protection law, you have the following rights in relation to your data:

To exercise any of these rights, contact hello@liffey.ai. We will acknowledge your request within 72 hours and respond fully within one calendar month. Where a request is complex or we have received a number of requests simultaneously, we may extend this by a further two months; if so, we will notify you within the first month and explain the reason for the extension.

We retain your data for as long as your workspace is active. Specific retention periods:

For enterprise customers with the strictest data residency or isolation requirements, Liffey has designed a self-hosted deployment tier: your database and application run entirely inside your own cloud boundary, under your own IAM and network controls. Packaging this into a repeatable, supported install is the remaining build.

• Data held entirely inside your own cloud boundary, under your control.
• Client-controlled IAM and network access, with no publicly reachable database.
• Optional customer-managed encryption keys.
• The option to bring your own AI provider account (BYOK), so inference runs under your own contract.
• A documented shared-responsibility model for what Liffey operates and what you control.

To discuss whether a self-hosted deployment fits your requirements and timeline, contact hello@liffey.ai.

In the event of a confirmed security incident affecting your data, Liffey will notify affected workspace owners within 72 hours of becoming aware of the incident, consistent with our GDPR obligations. Notifications will describe the nature of the incident, the data affected, the likely consequences, and the measures taken or proposed. Contact hello@liffey.ai to report a suspected security issue.

We maintain a documented incident-response runbook covering severity classification, the GDPR breach-assessment test, the 72-hour notification clock, evidence preservation, and post-incident review. It is available to customers on request.

Liffey processes personal data on the following lawful bases under Article 6 of the GDPR:

Liffey is the data processor acting on your instructions. You, as the customer, are the data controller for the commercial data you bring into the platform. This means you determine the purposes and means of processing your data; we process it only as directed by your use of the service and by our Data Processing Agreement. A standard DPA is available on request at hello@liffey.ai.

All core processing (database, compute, AI inference, and embeddings) takes place within the European Union. No personal data or commercial content is transferred to the United States or other third countries as part of the standard service. The hosted reader described in section 2 is sent the address of a public web page and nothing from your workspace, and it is listed in section 7 with the rest.

Where you choose to connect optional third-party sources (such as Google Drive, GitHub, or Slack), those providers may process data in the United States. Liffey reads only the content you specifically authorise and immediately processes and stores it in-EU. The transfer of data to those optional connectors is covered by Standard Contractual Clauses (SCCs) under Article 46(2) GDPR, entered into between Liffey and each relevant sub-processor. A list of those sub-processors and the SCCs in place are available on request.

If you have specific requirements around international transfers, such as a prohibition on any third-country processing, please contact us at hello@liffey.ai to discuss the enterprise dedicated deployment option, which can be configured to eliminate optional-connector transfers entirely.

Liffey operates inside certified environments: a client completed ISO 27001 certification with Liffey in their approved toolchain, with this architecture reviewed as part of that process.

Liffey is built on infrastructure and AI providers that are independently certified to the leading security and privacy standards. Every layer that stores or processes your data, the database, compute, AI inference, and email, is operated by a provider audited to SOC 2 Type II and ISO 27001:2022:

We can share sub-processor SOC 2 reports and ISO certificates on request, subject to any NDA requirements from those providers. Contact hello@liffey.ai.

Ongoing operational assurance

• Dependency vulnerability scanning. Automated scanning for known vulnerabilities runs on every change to the production branch and on every pull request, plus a weekly schedule, with automated weekly dependency update proposals.
• Quarterly access reviews. Member access, operator elevation history, and connected-source ownership are reviewed quarterly across the whole platform, with findings recorded; the first review was completed in August 2026.
• Runbooks. The incident-response runbook is available to customers on request; the key-rotation runbook is documented and maintained.

The Liffey service is a business-to-business platform intended for use by organisations and their authorised employees. It is not directed at individuals under the age of 16 and we do not knowingly process personal data of children. If you believe a person under 16 has been added as a workspace member in error, please contact hello@liffey.ai and we will remove that access immediately.

If you believe we have not handled your data in accordance with applicable data protection law, you have the right to lodge a complaint with the relevant supervisory authority. Liffey is based in Ireland. The relevant authority for Ireland is:

Data Protection Commission (DPC)
21 Fitzwilliam Square South, Dublin 2, D02 RD28, Ireland
www.dataprotection.ie

If you are based in another EU member state, you may also contact your local supervisory authority. We would, however, appreciate the opportunity to address any concern directly before a formal complaint is made. We would appreciate the opportunity to resolve any concern directly; please contact us at hello@liffey.ai.

We may update this document as our infrastructure, certifications, or practices evolve. Material changes will be communicated to workspace owners by email before they take effect. The current version is always available at this URL. Last reviewed September 2026 and signed off by the Liffey data controller.