Security & Compliance
How data is processed in our products, what leaves, what is recorded
- Home
- Security & Compliance
The data policy is in your hands
Our products run on the customer's server; the model runs on-premise or at the provider the customer chooses. In local mode no record leaves. Sensitive fields are masked before indexing; every decision is written to the audit log.
Design principles
We build GDPR and KVKK principles into the product's design; compliance is achieved together with the policies of the organisation that deploys it.
KVKK principles
Designed around the data minimisation, purpose limitation and security principles of Law No. 6698: only needed fields are indexed, sensitive fields are masked, processing is logged.
GDPR principles
Data minimisation, auditability and the ability to honour deletion requests: the index stays with the customer and any record can be removed from it.
Encryption in transit
The product UI and API calls run over TLS. Encryption at rest depends on the customer's server policy and is configured together during installation.
Security review
The code is open to independent review; findings from beta customers are prioritised on the roadmap. An independent penetration test is planned and not yet completed.
Data, before and after the model
The same principle at every layer: give the model only what it needs, masked and logged.
Masking
Password, token, key, card and identity fields are masked before indexing; detected from column names and value patterns, and users can mark more columns.
Where data lives
The index and audit log stay on the customer's server. The website demo uses fictional data; on the own-data screen the file stays in the browser.
Permission and audit
The role × risk × threshold policy is enforced at runtime; every permission decision, call and verification is logged with a timestamp.
What reaches the model
No raw table reaches the model; only masked chunks matching the question do. In local mode no external model is used. Data is never used for training.
Against silent failure
Security is not only access; it is the outcome being right.
Read-back and verification
After every write step the record is read again from the source system and compared with the postcondition. HTTP 200 alone is not success.
Front door
Out-of-scope and attack-like requests are classified; they are rejected before any record is read and the user is guided.
Rollback
Steps before an unverified step are compensated in reverse order; the job is not left half done and is handed to a human.
Audit log
Who, what, why, outcome. GDPR/KVKK and internal audit reports are produced from this log; in a real deployment it is written to a durable store.
Identity and permission
The product works with the organisation's existing identity infrastructure; the role matrix becomes policy and human approval is required above thresholds.
Questions about the data policy?
Write to us for details on the deployment model, masking rules and the audit log.