Security & compliance

Layered protection, provable operation

Protecting is not enough: you also have to prove afterwards what happened and what did not. The controls below work independently of each other.

Content filtering before anything is sent

Rules run on the raw text, with four levels of intervention. The stronger effect always overrides the weaker one.

Block

The request is not sent. For example a full card number or a private key.

Warn

The user sees the alert and can deliberately confirm sending.

Masking

The match is replaced with a placeholder: the request can go, the real value cannot.

Log

Every match is recorded, not just the first; rule tuning is based on this.

Scope: the whole organisation, a role, a group or a single user. Admins can test a rule on sample text before activating it. Filtering runs on all outgoing content: the message, the history, the document context and text extracted from files alike.

What the system recognises

Mutually reinforcing detection layers work on the text. The structural ones always run.

By structure · always on

Tax and social security numbers, with checksum validationPayment card numbers, with mathematical validationBank account numbers and IBAN, with format validationPhone numbers and e-mail addressesID card numbers, licence plates, network addresses

By name

Company dictionary

Staff, partners, project and product code names, including inflected forms. Maintained by admins, importable from a list.

Name-recognition language model OPTIONAL

For person, organisation and place names not in the dictionary. The structural layers provide full protection without it.

Encryption

Encryption layers

Envelope encryption: data is protected by a data key, and the data key is wrapped by a master key. The raw data key never touches disk.

LayerImplementation

In transitTLS 1.2 or newer; internal components listen only on the host's internal interface

Full diskCloud-side disk encryption, or disk-level encryption on own infrastructure

Field levelAES-256-GCM on conversation content, the masking store, sensitive log fields and extracted file text

BackupA separate encryption layer; the decryption key does not live on the instance

On top of this, conversations are protected by a key derived per user. Another user's key yields no readable content: this is not merely a permission rule, the wrong key mathematically produces no result.

Access management

Roles and permissions

Whatever is not explicitly allowed is denied. The principle of least privilege applies at every level.

RoleWhat they can do

UserChat, file upload, their own history

Team leadThe same, plus aggregate reports about their team; not others' content

AuditorReading and exporting logs, aggregate reports; does not chat

Company administratorUsers, roles, filtering rules, budgets, retention, branding

ITBS operatorOperations, updates, incident handling; every action is logged

Access to raw conversation content is granted by default only to its own user; every other case requires a separate role, a written justification and is logged.

Provability

Hash-chained event log

The log is not a simple log file, but chained evidence that is sensitive to later manipulation.

Every AI request gets an entry

Who, when, with what filtering result, at what cost and through which endpoint.

Insert only

The application has no update rights, and deletion is prevented by a database-level rule.

Each entry covers the previous one

A single retroactive rewrite breaks the chain, which becomes immediately detectable.

External witnessOPTIONAL

A daily chain seal sent off the instance, as a signed digest. Rewriting the log stays detectable even if the whole instance is taken over.

Compliance

What the platform adds to compliance

Open a row for the details.

GDPRData minimisation

Masking and content filtering: the model only ever sees minimised data. The real value stays on the instance, in encrypted storage.

GDPRData protection by design

A processing chain that is closed by default, masking on by default, encryption everywhere. Protection is not an option, it is the base state.

GDPRData subject rights

Built-in export and deletion, with deadline and status tracking. On deletion the masking entry is removed too, so old logs cannot be reversed either.

GDPRImpact assessment (DPIA)

A pre-filled impact assessment template and processing documentation, together with the data processing agreement.

NIS2Access control

Corporate sign-in from your own directory, enforced multi-factor authentication, role-based permissions and automatic account lockout.

NIS2Incident handling

Emergency shutdown with a single switch, a documented procedure, and evidence from the log for later reconstruction.

NIS2Business continuity

Daily encrypted backup to immutable storage, documented recovery objectives and a quarterly restore test with a written record.

NIS2Logging and monitoring

Hash-chained log, an optional independent witness and continuous availability monitoring.

ISO 27001Controls and evidence for the ISMS

Provides ready, documented evidence for access management, cryptography, operations security, logging and supplier relationship controls. It does not replace the information security management system, but it covers the AI control point in an auditable form.

DORAICT risk and third-party management

AI usage can be registered as an ICT service: a documented provider chain, incident classification and reporting, continuity and restore testing, and an exit scenario for the model provider.

EU AI ACTTransparency and human oversight

The organisation is a deployer of general-purpose AI: the platform logs model calls, documents the model and endpoint used, ensures human override and usage limits, and supports staff notification and the AI-literacy requirement.

The platform does not replace your own compliance programme and does not constitute certification: it adds a provable foundation of technical and organisational controls.

Open cards

What technology cannot solve, and how we handle it

A control system is credible only if it also shows its limits.

The limit

Information paraphrased in the user's own words. Without a recognisable pattern, the filter cannot tell that the data is sensitive.

How we handle it

Staff training, a versioned usage policy accepted at sign-in, live dictionary maintenance and weekly review of missed and false matches.

The limit

A signature, a stamp, a licence plate or a recognisable location in an image. Handwriting and faces are detected; these are not.

How we handle it

The system requires proof, not suspicion: an image may only be sent if it is verified clean. In case of doubt, only the masked text goes out.

The limit

Staff bypassing the platform and using another AI service. The behaviour of the external model is governed by contract, not by our technology.

How we handle it

Network-level blocking and an internal policy against bypassing. Contractual terms: no model training and, where possible, no retention.