Data Security, Confidentiality and GDPR

Version: April 2026
Status: Customer-facing summary document, reflecting the current state of the service.

Purpose of This Document

This document describes how KairoProject currently operates with regard to data security, confidentiality, and the processing of personal data. It presents neither a roadmap nor an improvement history: it sets out the current state of the service and the actual data flow.

Key Definitions

B2B SaaS: software accessible online, provided by subscription to businesses.
Firebase / Firestore: cloud services used to store application data and run certain server-side processes.
Portfolio: a grouping workspace for multiple projects.
Organisation: a shared company workspace accessible to multiple users.
Role: the level of rights granted to a user within a workspace. Examples: owner, admin, member.
Owner: the primary administrator of an organisation, holding the highest rights over that workspace.
Scope: the exact perimeter to which an action or model applies, for example a single user or an organisation.
Server route: a technical entry point used by the application to process an action on the server side.
Admin SDK: a server-side tool providing technical access and control over the database for back-end reserved operations.
Asynchronous job: a process launched in the background, without blocking the user during its execution.
Storage bucket: a file storage area used to temporarily hold exports or imports.
Signed link: a temporary download link, valid for a limited period.
Timestamp: the precise date and time of an action.
Retention: the duration for which a log or piece of data is kept before deletion.
DSAR: a request related to personal data rights, such as access, export, or deletion.
OpenAI: an external service used for certain AI-assisted generation or explanation features.
ML service: KairoProject's internal service dedicated to predictions and model training.
Global model: a shared model, not reserved to a single customer.
Custom model: a model trained exclusively for a single customer workspace or organisation.
Inference: the use of a model to produce an estimate or prediction.
Metadata: technical or descriptive information about a piece of data, such as a date, identifier, model version, or status.
Prompt parameters: context or instruction fields associated with a project to guide certain AI processes.
ETC: Estimated Time to Complete — the estimated remaining work on a task.
Fever: a visual project tracking indicator used to compare progress against buffer consumption.

Overview

KairoProject is a B2B SaaS project management platform. Application data is processed within Firebase / Firestore and through controlled server-side processes. Access is separated between personal workspaces and organisations, with rights verification performed server-side before any read or write operation.

Sensitive operations such as exports, deletions, and GDPR audit logging are processed server-side and are not exposed as direct access to the web client.

Main Data Flow

1. Account and Access Data

User accounts are managed via Firebase Authentication.
Profile data, subscription status, rights, and preferences are stored in Firestore.
Each user can only access their personal workspace or organisations for which they hold a valid right.
Roles are separated between owner, admin, and member.

2. Business Data

Portfolios, projects, tasks, resources, history, and application settings are stored in Firestore.
Access is controlled at two levels:
- by Firestore rules;
- by explicit server-side checks on routes using the Admin SDK.
Deactivated members or users who have merely been invited cannot access an organisation's active data.

3. Data Export

An organisation owner can trigger an export of their data.
The export is processed as an asynchronous job.
The output is stored temporarily in a storage bucket.
The download link is generated as a temporary signed link.

4. Data Deletion

Deletion of an organisation follows explicit confirmation by the owner, then asynchronous server-side processing.
Deletion of a user account automatically triggers — without intentional delay — the purge of associated active data. This purge is initiated upon deletion of the Firebase Auth account and subsequently runs in the background via Cloud Function.
Important GDPR operations are logged with a timestamp, subject identifier, job identifier, and retention date.

5. Backup and Restoration

Application data is stored in Firestore, a managed Firebase / Google Cloud service.
Backup and restoration mechanisms therefore rely primarily on the operational capabilities of this managed infrastructure, rather than on a backup engine proprietary to KairoProject.
KairoProject relies on this infrastructure for data continuity, and complements it with its own export, deletion, and audit logging mechanisms.

Administrator Access

Other customers have no access to a company's data. However, the publisher retains a governed technical administrator access to the infrastructure for legitimate support, maintenance, security, and legal compliance purposes. This access must remain limited, attributed to named individuals, and logged.

AI and ML Data Processing

KairoProject distinguishes between two categories of processing:

generation and explanation processing via OpenAI;
predictive and training processing via the internal ML service (ml-service).

Summary for Customers

KairoProject's ML service has a specific purpose: to help produce more useful estimates and predictions for project management.

It operates at two levels:

a shared model to provide a common prediction baseline;
a custom model where a workspace has its own dedicated model.

In practice, this means:

predictions are not produced opaquely and directly in the browser;
they pass through controlled server-side processes;
a custom model remains tied to its corresponding workspace and is not reused for another customer;
the global model serves as a shared reference, while the custom model allows for better alignment with the customer's specific context.

In other words, this service is designed to be both useful to the customer, technically governed, and compatible with a per-workspace confidentiality approach.

1. When OpenAI Is Used

OpenAI is called server-side for certain assistance, generation, or explanation features.

Depending on the feature used, the following data may be transmitted to OpenAI:

a brief entered by the user to generate a project or plan overview;
contextual information such as domain, constraints, team size, or project objective;
task names or structural elements required for generation;
for delay analysis, a structured project summary, reported issues, resource usage history, and a prediction block already computed by the ML engine.

OpenAI calls are not made directly from the customer's browser to the provider. They pass through KairoProject server-side routes, with input validation, rate limiting, and filtering of permitted models.

2. What Is Never Sent to OpenAI

The internal knowledge assistant (knowledge search / knowledge chat) works from product documentation indexed by KairoProject, not from a company's business data.
Access to a user or organisation scope is verified server-side before any context linked to a given workspace is used.
The OpenAI models that can be invoked are restricted by an allowlist enforced server-side.

3. Persistence of OpenAI Processing

Application routes return the generated response to the client.
The server-side code for these routes does not automatically write the full OpenAI prompt to a dedicated business log.
If a user subsequently injects the result into their project data, that persistence is part of the normal operation of the application.

4. When the Internal ML Service Is Used

KairoProject also uses an internal service dedicated to predictions and model training.

This service may receive, depending on the case:

structural prediction variables, such as the number of active tasks, blocked tasks, cumulative workload, progress, buffer consumption, prediction horizon, and other quantified indicators;
reconstructed exports from a given workspace to train a custom model;
business import files provided by the customer to enrich a custom training run;
for the global model, exports and imports from workspaces eligible to contribute.

The ML service is not freely selected from the client side: calls pass through the KairoProject server, with rights verification and explicit selection of the applicable model.

5. Global Model and Custom Model

KairoProject distinguishes between:

a global model, which is shared;
a custom model, isolated by scope.

The custom model is trained solely on data from the active scope:

users/{uid} for a personal workspace;
organizations/{orgId} for an organisation.

A custom model is only active if the stored metadata matches exactly the active scope. This prevents a customer from inadvertently using another customer's model.

6. What "Anonymisation" Means Here for the Global Model

In the product, the term "global model" means it is a shared model, not tied to a single customer at inference time. The metadata retained at application level for this model is aggregated: versions, row volumes, project counts, numbers of contributing scopes.

However, the global model's training relies on the current exports of contributing workspaces and on their active imports where permitted. "Anonymisation" should therefore not be understood as a promise that all source data would first be transformed into a fully and irreversibly anonymised dataset prior to training. The current meaning is as follows:

the resulting model is shared;
contribution to the global model is controlled by explicit opt-in by the administrator of the relevant workspace (globalContributionOptIn);
the metadata exposed in the application for this model is aggregated;
the custom model remains isolated by customer or workspace.

7. Contribution to the Global Model

A scope's internal data may contribute to the global model according to the policy associated with that workspace.
Data imported by a customer only contributes to the global model if global contribution has been explicitly enabled by the administrator of the relevant workspace.
Contribution is re-evaluated at each global retraining cycle.

8. What Data May Feed the Global Model

When a workspace contributes to the global model, the internal training service may use two categories of data:

reconstructed exports from the portfolios and projects of that workspace;
active training import files for that workspace, where they are permitted to contribute.

In the current state of the product, this may include in particular:

technical scope and project identifiers included in internal exports;
external identifiers for portfolios, projects, tasks, resources, teams, and calendars;
names of portfolios, projects, tasks, resources, teams, and calendars;
portfolio and project descriptions;
project settings relevant to the engine, including certain promptParameters where they exist on the project;
dates, statuses, durations, ETC values, priorities, categories, dependency chains, associated resources, ETC history, and Fever data points;
business import files submitted by the customer for custom or global training, depending on the option enabled.

In other words, contribution to the global model is not currently limited to purely numerical, already-anonymised statistics. The service first reconstructs application exports and then derives the training datasets required.

9. What Data Is Not Sent in This Global Model Pipeline

In the current state of the product, the global model training pipeline does not receive the following categories of data:

passwords or authentication secrets;
Stripe billing data;
GDPR logs, deletion logs, DSAR evidence, and monitoring logs;
internal knowledge base content used for the knowledge assistant;
account-level data such as email address, global role, session settings, or authentication claims, beyond technical identifiers required for the internal export.

10. Concrete Example

Simplified example:

if a customer enables global contribution and creates a project named ERP Group X Migration, with a description containing sensitive business terms, explicit task names, and a CSV import containing task labels and resources, these elements may be included in the internal training pipeline fed to the ML service;
however, another customer does not gain access to this data in plain form within the application: it is not exposed as a shared export or a common screen; it contributes solely to the shared model trained internally.

For a customer wishing to minimise what can enter this pipeline, the most cautious approach is to:

not enable contribution to the global model where that option is not desired for the relevant workspace;
avoid entering unnecessarily identifying, confidential, or strategically sensitive information in project names, descriptions, task labels, or import files where such information is not required for project management purposes.

Automated Controls Currently Applied

Retention and Persistence

Active service data remains stored in application collections for as long as the account, organisation, or associated content exists.
Backup and restoration of the database infrastructure rely on mechanisms operated on Firebase / Google Cloud.
DSAR logs are retained for 12 months.
Organisation deletion logs are retained for 12 months.
Technical organisation deletion jobs are retained for 90 days.
Organisation export jobs are retained for 7 days.
Signed export download links expire after 24 hours.

What This Means for a Customer

KairoProject can today be described as a service:

with serious data separation between workspaces;
with access governed by user, organisation, and role;
with concrete export and deletion mechanisms;
with technical traceability of sensitive operations;
with AI and ML processing routed through the server, not freely exposed;
with a GDPR framework already structured for a customer review or pre-audit.

Supporting Documents

Privacy Policy
Terms of Service
Legal Notice
Cookie Policy
More detailed GDPR and security documentation available on request, depending on the customer or contractual context