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:

Liffey stores only the categories above. Payment card data, national identity numbers, health data and special-category personal data under GDPR stay outside the platform.

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 lets Liffey read the content you authorise, at the time of connection and at each sync, and Liffey immediately derives its own representation of it. The live source files stay in your systems.

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 a connected AI tool passing in a document on a member's behalf. Every one of them goes through the same governed ingestion path, 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 1, because a site behind a bot filter will refuse an automated reader on the source address alone. Where a site refuses our reader, or answers with a bot check in place of the page, the page is read a second time through a hosted reader (Apify, listed in section 7). Public forum communities on a reviewed list, which turn automated readers away, are read through the same hosted reader directly. In every case it is sent the address of the public page and returns that page; content from your workspace stays with us. Everything from step 2 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 2 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 2 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, 1 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 runs 2 distinct knowledge layers, and each is used differently:

The Commercial Brain is also indexed for meaning, in the same way as the knowledge base, 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.

Your team reaches the brain through the app, its own AI tools, Slack and the API. Each one is a place your content is read and, in 1 case, leaves our environment. Each route is opened deliberately: an owner installs Slack, and each member connects their own AI tools and API access under their own sign-in, capped by their role.

An owner or admin can also share a single item by link, 1 item at a time, and each link is recorded in your audit log when it is made and when it is turned off: a Commercial Brain component, shared to read; a document, shared for 7, 30 or 90 days or until it is turned off, always opening its current version, with every view counted; the briefing that can accompany a shared document, written for the reader's own AI assistant and live for 30 days, with every read counted; and an item from your Media library, given its own address. Anyone holding a link reads that 1 item alone, and turning a link off ends its address at once. Shared documents and briefings are marked to stay out of search engines. Each view of a shared document is counted by the country and type of device it came from, and each read of a briefing by its country and whether an AI assistant or a browser made it, with no cookie set and no IP address stored.

Where a website draft is prepared for your business, it is published at /website-draft on your workspace address, readable by anyone holding the link and marked to stay out of search engines. That route reads only the draft's own folder and reaches nothing else in your workspace.

Every read through a connected AI tool, Slack or the API is recorded in your audit log with the person, the route and the time. In the app, the pages each member opens are recorded first-party, as described in section 10.

Liffey is built for EU data residency. Your database, application compute, and all AI processing of your content run within the European Union. The 1 service outside it draws new illustrations from a short, general scene description that contains none of your content. 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 in section 2.

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.

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. Board people read the sections and documents an owner has shared with the board. No 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.
• Opted out of AWS service improvement across Liffey's AWS organisation. Liffey applies the AWS AI services opt-out policy at the root of its AWS organisation, so content processed by any AWS AI service, including Amazon Transcribe for dictation, is excluded from AWS service improvement in every Liffey AWS account.
• 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. The same holds where an owner connects your organisation's own model account in settings: inference for your workspace then runs under your agreement with that provider.
• 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. Where Liffey acts on its own initiative, it works downstream 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 where it is switched on for your workspace, an owner's committed change to a component's written page brings that component's presentation into line with it: Liffey rewrites only the slides whose words no longer agree with the page, each change must quote the committed sentence it follows and pass a second, independent check, the version before stays in the file history, and every change is recorded in the audit log. Otherwise a presentation changes when a person saves it or approves a proposed redraft in the owner review queue. 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 published. For a signed copy, email hello@liffey.ai.

Access to your Liffey workspace is controlled at multiple layers. Sign-in uses one-time codes, which removes the most common source of credential breaches and takes the security burden off your team. The full 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 1 calendar month. Where a request is complex or we have received a number of requests simultaneously, we may extend this by a further 2 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 offers a self-hosted deployment: your database and application run entirely inside your own cloud boundary, under your own IAM and network controls.

• 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. Our standard DPA is published, and a signed copy is available from 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. The sub-processors are listed at liffey.ai/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 welcome the chance to resolve any concern directly first, 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 October 2026 and signed off by the Liffey data controller.