Data Security, Confidentiality and GDPR
KairoProject customer compliance document — data flows, security, AI/ML processing, GDPR rights and automated controls.
Version: April 2026 — 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 sets out the current state of the service and the actual data flow, without presenting a roadmap or improvement history.
Key Definitions
| Term | Definition |
|---|---|
| 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 (owner, admin, member) |
| Owner | The primary administrator of an organisation, holding the highest rights |
| Scope | The exact perimeter to which an action or model applies |
| Server route | A technical entry point used to process an action on the server side |
| Admin SDK | A server-side tool providing technical access to the database for back-end operations |
| Asynchronous job | A process launched in the background, without blocking the user |
| Storage bucket | A file storage area used to temporarily hold exports or imports |
| Signed link | A temporary download link, valid for a limited period |
| DSAR | A request related to personal data rights (access, export, or deletion) |
| OpenAI | An external service used for certain AI-assisted 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 |
| ETC | Estimated Time to Complete — the estimated remaining work on a task |
| Fever | A visual project tracking indicator comparing 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, and 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 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.
- 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 rely primarily on the operational capabilities of this managed infrastructure.
- KairoProject complements this with its own export, deletion, and audit logging mechanisms.
Administrator Access
Other customers have no access to a company's data. The publisher retains governed technical administrator access to the infrastructure for legitimate support, maintenance, security, and legal compliance purposes. This access remains limited, attributed to named individuals, and logged.
AI and ML Data Processing
OpenAI
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, contextual project information, task names or structural elements, or for delay analysis a structured project summary and prediction indicators.
OpenAI calls are not made directly from the user's browser to the provider. They pass through KairoProject server-side routes, with input validation, rate limiting, and filtering of permitted models.
What is never sent to OpenAI: The internal knowledge assistant works from product documentation indexed by KairoProject, not from a company's business data. It is restricted to authenticated users. Access to a user or organisation scope is verified server-side before any context linked to a given workspace is used.
Internal ML Service
KairoProject also uses an internal prediction and training service. This service distinguishes between:
- a shared model to provide a common prediction baseline;
- a custom model where a workspace has its own dedicated model.
A custom model remains tied to its corresponding workspace and is not reused for another customer. When the custom model is selected but not yet ready, KairoProject does not automatically fall back to the global model: no prediction is provided until the workspace model is operational.
Contribution to the Global Model
- Contribution to the global model is controlled by explicit opt-in by the administrator of the relevant workspace (
globalContributionOptIn). - When enabled, future data from that workspace may contribute to future global model training runs.
- This setting applies going forward and does not automatically remove data already used in past training runs.
Data that may feed the global model (when contribution is enabled): reconstructed exports from the portfolios and projects of that workspace, active training import files for that workspace where permitted. This may include technical identifiers, names of portfolios, projects, tasks, resources, teams, calendars, descriptions, project settings, dates, statuses, durations, ETC values, priorities, dependency chains, history, and Fever data points.
Data not used in this pipeline: passwords or authentication secrets, Stripe billing data, GDPR logs, internal knowledge base content, account-level data such as email address or authentication claims.
Recommendation for customers wishing to limit this pipeline
Do 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
| Automated control | Current rule |
|---|---|
| User deletion | Purge triggered automatically upon Firebase Auth account deletion |
| Organisation export | Technical retention of 7 days |
| Export download link | Valid for 24 hours |
| Organisation deletion job retention | 90 days |
| Organisation deletion log retention | 12 months |
| DSAR log retention | 12 months |
| Automatic purge of expired logs | Scheduled task every day at 03:00 UTC |
| Public OAuth route protection | Limit of 20 requests per minute |
| Public form protection | Limit of 8 requests per 10 minutes |
| Light public AI protection | Limit of 20 requests per minute |
| Higher-cost public AI protection | Limit of 8 requests per minute |
| Cookies and trackers | No non-essential tracker loaded by default |
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
More detailed GDPR and security documentation is available on request, depending on the customer or contractual context.