This document describes transparently how Cyber Chat (Alex) processes and protects data while delivering the security awareness program. It is intended for security managers, DPOs and teams evaluating the service during the purchase phase.
Cyber Chat (Alex) is a cloud service (SaaS) that delivers brief interactive micro-lessons in security awareness through the Alex assistant, directly in the messaging tools already in use in your company: Microsoft Teams, Slack, Google Chat or Webchat. Administrators manage the entire program from the Cyber Awareness area of the console. The data processed is essentially employee training data, used to deliver lessons, grade quizzes and track progress.
The service informs and trains: it does not make binding decisions about employees, accounts, access or content. Quiz correction, outcome and progress are deterministic — no artificial intelligence decides an employee's status.
A European cloud service
Cyber Chat (Alex) is a multi-tenant SaaS service hosted in the European Union (Belgium), on Google Cloud Platform. The managed and elastic infrastructure automatically absorbs delivery peaks (scheduled lesson sends and reminders), without manual intervention.
Each customer's data is logically isolated per tenant: every query and every authorization are scoped to the organization of origin, and resource-level controls verify ownership by company and by user. The only legitimate path between different organizations is the corporate group relationship, subject to explicit control.
There is no software to install on the employee's device. Cyber Chat (Alex) does not include browser extensions, desktop agents or mobile apps, does not require device permissions and does not store data locally. The service does not record keystrokes, does not access the clipboard and does not record the screen: it processes only the messages that the user deliberately sends to the assistant and quiz responses.
Encryption and communication protection
In transit. All traffic travels over HTTPS/TLS: between the console/API and the backend, between the backend and the AI provider, to databases and to messaging platforms. HSTS is active (with preload and include-subdomains), a Content-Security-Policy is set and console and API session tokens (JWT) are signed and verified (RS256) on every request.
At rest. Persistent data resides in a managed relational database, in managed object storage (documents, certificates) and in a managed secret manager, all encrypted at rest by the cloud provider's default encryption.
Secrets and credentials. The service does not manage end-user passwords. Platform and integration secrets reside in a managed secret manager and are loaded at runtime: they are never sent to the client or inserted in code.
Identity and access
End users (employees). They are identified through the identity of their messaging platform (Teams, Slack, Google Chat) or a Webchat session: they do not set any password with LibraCyber. They see only their own progress (My Progress) and lessons assigned to them; they cannot reach databases, backend or infrastructure.
Administrators and APIs. Access is federated to the customer's identity provider (OIDC / OAuth 2.0), with tokens verified on every request. Functions are governed by distinct roles and permissions (for example configuration, dashboard, user management, catalog administration, certificate export), according to the principle of least privilege. Each administrator operates exclusively within their own tenant.
Support access. For support purposes, an authorized LibraCyber operator can act on behalf of a user. This is a tracked capability: the operator's actual identity is always preserved for action attribution.
What data does the service process
At the category level, the service processes the following data:
| Category | Contains personal data? | Notes |
|---|---|---|
| Company configuration | No | Company profile, messaging platform, feature settings; synchronized from the LibraCyber platform. |
| User directory | Yes | Email, first and last name, language and directory/messaging identifiers; synchronized from the customer's directory, not entered here. |
| Lesson content and catalog | No | Lessons, quizzes and learning paths. They can contain personal data only if an administrator inserts it in the lesson text. |
| Progress and certificates | Yes | Quiz scores, status and completion for individual users; the certificate shows the learner's name. |
| Free chat messages | Yes | Employee free messages and assistant responses; only a small recent window of the conversation is retained. |
| Reference documents uploaded (RAG) | Possibly | Company documents uploaded by the administrator to ground free chat responses. |
| Source files for AI generation | Possibly | File uploaded by the administrator for assisted generation of a lesson; processed and then deleted when complete. |
| Operational logs and error traces | Yes | Diagnostic logs and error context. |
By default, the service does not collect special category data (GDPR Article 9) or payment data. The only way sensitive data can enter the system is if an administrator chooses to upload documents or write lesson texts that contain it.
Data enters from four sources: the customer's directory (users, email, names, language — synchronized, not entered here); the messaging platform (employee messages and quiz responses); the administration console (lesson content, configuration and uploaded files); and incoming events from messaging platforms. Administrators see data scoped to their own company; employees see only their own progress and assigned lessons.
Artificial intelligence and data processing
Artificial intelligence is used at four support points: free chat questions and answers, free chat responses grounded in company documents (RAG mode), assisted lesson generation and message language detection. Everything else — lesson delivery, quiz grading, scores, progress, reminders and certificates — is deterministic and AI-free. No AI grades a quiz or decides a user's status.
Inference is performed by an enterprise-grade third-party provider, within a tenant controlled by LibraCyber. Models are used only for inference: LibraCyber does not train or fine-tune any model with customer data. The provider processes prompts to generate the response under data protection contractual terms (DPA). The service's main functions continue to operate even if the AI provider is unavailable, because they do not depend on the model.
What is sent to AI and what is not
| Function | What is sent | What is NOT sent |
|---|---|---|
| Free chat (Classical) | A fixed system prompt, a brief window of recent conversation turns and the user's new message. | No employee identity or personal data. |
| Free chat with documents (Personalized / RAG) | The user's message, excerpts from documents uploaded by the administrator and the preferred language. | No company directory data or data from other customers. |
| AI-assisted lesson generation | Only the file uploaded by the administrator and its text prompt. | No company name, domain or identifier and no employee data. |
| Language detection | The message text alone, to select a supported interface language. | Nothing else. |
In lesson generation, the administrator's email is used only for completion or error notification, never transmitted to the model. The source file is uploaded to a temporary index, dedicated to the single execution, and is deleted at the end of each generation along with the AI resources created for that execution.
NOTE: the text that the employee writes in free chat is transmitted as-is, without filtering of personal data. It is therefore recommended not to enter unnecessary personal or confidential data in the chat.
Human control and configuration
Free chat is disabled unless activated by the administrator, who can set it to Disabled, generic (Classical) or grounded in company documents (Personalized). Assisted generation produces a draft lesson that the administrator reviews and must publish (Deploy) before an employee can see it: there is always a person in the process. AI outputs are content-only, for advisory purposes: they do not block, correct or modify a user's status. The nature of assistant is made clear to the user during the conversation. Because text generated by a language model can be inaccurate, the administrator remains responsible for reviewing generated lessons.
AI protections. System instructions are protected against user attempts to override them (for example "ignore the above", "act as"), so the assistant always maintains its role. Additionally, the provider's content filtering policy applies: a filtered response produces a generic message rather than the blocked content.
Reference documents (RAG). This is the only opt-in content path: the administrator chooses what to upload (up to 20 documents, each up to 100 MB). Documents are scoped to the tenant, used only to ground responses to that company's employees, and are removed from the provider's storage and index when the administrator deletes them. Everything the administrator uploads becomes eligible to appear in a response: do not upload documents that should not be citable to employees.
Data retention and deletion
The observable retention behavior is as follows:
| Category | Retention and deletion |
|---|---|
| User directory | Retained while the user is active; when they leave the synchronized directory they are deactivated (not deleted). |
| Progress and certificates | Retained until an Erase all Learning data operation by an administrator or company deletion. |
| Free chat messages | Only a small recent window of turns per user is maintained; older turns are automatically deleted. |
| Reference documents (RAG) | Retained until the administrator deletes them; removed from the provider's storage and index. |
| Source files for AI generation | Deleted at the end of the generation execution. |
| Operational logs | According to the platform's log retention setting. |
Erase all Learning data is an administrator action that irreversibly deletes the company's certificates and resets progress and attendance for every user; previous raw data is no longer downloadable. Deletion of a company cascades to its users and records.
Data subject rights
The customer is the data controller; LibraCyber is the data processor and supports data subject requests as follows:
- Access and portability: per-user progress is viewable in the console and exportable in CSV format; directory fields come from the customer's directory.
- Rectification: directory fields (name, email, language) are corrected at source and re-synchronized.
- Restriction and objection: an administrator can stop delivery to a user (deactivation) and disable free chat.
- Erasure: deactivation stops processing; the Erase all Learning data operation removes progress and certificates at company level, and company deletion cascades.
The service does not adopt automated decisions with legal or similar effects on employees: GDPR Article 22 therefore does not apply.
Third-party providers (sub-processors)
To deliver the service, LibraCyber relies on a limited set of sub-processors: cloud hosting (Google Cloud Platform, European Union), the messaging platforms chosen by the customer (Microsoft Teams, Slack, Google Chat), a third-party AI provider and services for transactional email sending, error monitoring and usage analytics.
The authoritative and up-to-date list of sub-processors, their respective processing regions and data transfer mechanisms are indicated in the Data Processing Agreement (DPA), which is the binding reference.
Data breach notification
As a data processor, LibraCyber commits to notifying the customer (data controller) without undue delay of any personal data breach, so as to enable the controller to fulfill the obligations set out in GDPR Article 33.
Related functions
- Cyber Chat (Alex) – Awareness Dashboard — monitoring progress and exporting training data in CSV format.
- Cyber Chat (Alex) – Lesson Catalog — assigning and organizing lessons for the company and departments.