Security by design
Private company knowledge, kept private.
Paměť reads the most sensitive material a company holds: its emails, its contracts, its decisions. This page sets out how it is designed to keep that material where it belongs, what depends on your deployment, and which questions you should ask us before you trust us with it.
- EU data storage
- GDPR-conscious
- Access-controlled
- Enterprise-ready
04The answer
By design, built only from records the asking person may already open. Sources attached, so it can be checked.
Our position
Your company’s knowledge remains your company’s knowledge.
Paměť is built around the principle that private company information should remain private.
Those two sentences are easy to write. The rest of this page exists to show what they mean in practice: where records are stored, who can see what, what is kept, what is deleted, and what we will put in writing.
01
Not training data for anyone else
Your records exist to answer your company’s questions. They are not used to train models for other customers.
02
Not visible across companies
Each company’s memory is kept separate from every other company’s. Isolation options depend on deployment configuration.
03
Not kept beyond what you agree
Designed so that retention and deletion follow the terms agreed with you, not what happens to be convenient for us.
Principles
Four principles that come before any feature.
Every control on this page follows from one of these four. They decide what Paměť will and will not do with your records, and they are the standard we expect you to hold us to.
- 01
Data ownership
The records Paměť reads belong to your company, and so does everything it derives from them. You can ask for it back, and you can ask for it gone.
In detail
- 02
Private by default
Designed so that nothing is shared, surfaced or retained unless a rule you control says it may be. The default answer to “can this be seen?” is no.
In detail
- 03
Permission-aware
A person receives answers built only from records they may already access in the source system. Paměť is designed to inherit your permissions, not to replace them.
- 04
European hosting philosophy
Built in Prague for European companies, with European hosting as the design assumption. The specific hosting arrangement is agreed with you as part of deployment.
In detail
Controls in detail
Nineteen topics, stated plainly.
Security pages tend to be either vague or boastful. This one tries to be neither. Each topic says what the architecture is designed to do, what depends on your deployment configuration, and where you should ask our team for detail.
- By design
- Part of how Paměť is built. Not optional.
- Deployment-dependent
- Available depending on the deployment configuration you choose.
- On request
- Detail we describe to your team on request, rather than on a marketing page.
Where knowledge lives
The first question any CIO asks is where the data goes. The honest answer starts with a design assumption and ends with a deployment agreement.
- Deployment-dependent
EU data storage
Designed for European hosting: company knowledge is intended to be stored and processed within the EU. The specific storage location is confirmed as part of your deployment configuration.
- By design
European hosting philosophy
Paměť is built in Prague for European companies. European hosting and GDPR-conscious handling are the starting assumptions of the architecture, not options added for the European market.
- By design
Data ownership
Your records, and the index, links and answers derived from them, remain your company’s property. Ask our team about export and hand-back at the end of a contract.
- Deployment-dependent
Tenant isolation
Each company’s memory is kept separate from every other company’s. Isolation options, from logical separation to dedicated environments, depend on deployment configuration.
Who can see what
No new permission model. Paměť is designed to follow the access rules your systems already enforce, and to let your administrators narrow them further.
- By design
Access controls
Architecture includes access controls at the workspace, source and record level, so that a connected system does not become an open one.
- By design
Permission-aware retrieval
Designed so that retrieval is filtered by the asking person’s permissions before an answer is composed. The intent is simple: a person only receives answers built from records they may already access.
- Deployment-dependent
Authentication
Designed to support sign-in through your existing identity provider, including single sign-on, so that leaving the company means leaving Paměť. Available methods depend on deployment configuration.
- By design
Employee access controls
Designed so that administrators decide which people and groups may use Paměť, and which sources each group’s questions may draw on. Access can be narrowed without touching the source systems.
- Deployment-dependent
Administrative controls
Architecture includes an administrative layer for connected sources, users, retention rules and logs. The range of self-service controls depends on deployment configuration.
Data protection
In transit, at rest and inside the connectors. We do not name algorithms or providers on a marketing page; we describe them in the security overview, on request.
- By design
Encryption in transit
Architecture includes encryption of data moving between your systems, the connectors and Paměť. Protocol details are documented in the security overview.
- By design
Encryption at rest
Architecture includes encryption of stored data, including indexes and derived records. Key management options depend on deployment configuration.
- By design
Secure integrations
Connectors are designed to be read-only and scoped to the permissions you grant. Credentials for connected systems are handled with the same care as the records they open. Ask our team about your specific systems.
- Deployment-dependent
Backup practices
Designed to support regular backups under the same isolation and encryption principles as live data. Backup frequency, location and retention are agreed as part of deployment.
Lifecycle
Company memory should be long-lived. That is not the same as keeping everything forever.
- By design
Data minimisation
Paměť is designed to read what it needs to answer questions and no more. Sources, folders and mailboxes can be excluded, and connectors need no broader scope than the questions require.
- Deployment-dependent
Data retention
Retention rules for indexed records, questions and logs are designed to follow what is agreed with you. Default retention periods depend on deployment configuration.
- By design
Data deletion
Designed so that a record removed from a source system can be removed from the memory as well, and so that a full deletion can be carried out at the end of a contract. Ask our team about deletion timelines and written confirmation.
- By design
GDPR-conscious architecture
Data minimisation, purpose limitation, retention and deletion are design considerations, not afterthoughts. Architecture is designed to support data-subject requests. Data processing terms are available on request.
Oversight
Trust is easier to grant when you can check it.
- Deployment-dependent
Auditability
Architecture is designed to support logging of access, questions and administrative actions for review. What is logged, and for how long, depends on deployment configuration.
- On request
Incident response
Security controls can include an incident response process with defined roles, notification steps and post-incident review. Ask our team for the current process description.
Specific controls, hosting locations and any independent assessment depend on the deployment configuration you choose. Nothing on this page should be read as a certification. Ask our team for the details that apply to your environment.
How permissions flow
The answer knows who is asking.
Paměť does not invent a permission model. It is designed to inherit the one your systems already enforce, and to apply it before an answer exists, not after.
- IdentityWho is asking, verified
- Source permissionsWhat they may open today
- Retrieval filterOnly those records are searched
- AnswerFrom permitted records, with sources
Filtered before, not redacted after
Designed so that records a person cannot access are never candidates for the answer. There is nothing to redact, because it was never retrieved.
Inherited, not duplicated
Designed to read permissions from the source systems rather than copy them into a second model that could quietly drift out of date.
Revoked access, revoked answers
Designed so that when access is withdrawn in a source system, the record stops contributing to that person’s answers. Propagation timing depends on connector configuration.
In practice
Same question. Two colleagues. Two answers.
In the demo workspace, Anna Nováková works on the Novatek account and can open its folder. Lucie Horáková leads a different project and cannot. Paměť is designed so that the answer each of them receives is built only from what they could already open, and so that it does not confirm the existence of records outside a person’s permissions.
What did we quote Novatek for the warehouse automation project?
Can open the Novatek folder
Answer
Quotation Q-2025-0914 was sent on 14 Sept 2025: WMS implementation, ERP integration and a 24-month support package, with a proposed timeline of about twelve weeks from signature.
1 source
No access to the Novatek folder
Answer · No accessible record
Nothing among the records you can open describes a quotation to Novatek for warehouse automation.
0 sources
Illustrative scenario built from the fictional demo workspace. It shows the design principle; the exact behaviour in your environment depends on the permissions your source systems expose and on connector configuration.
Questions to ask any vendor
Ask these of every vendor. Including us.
If you are evaluating any tool that will read your company’s records, these questions are worth asking. Our answers are below, in the same careful language we use everywhere else on this page.
- 01
Where is our data stored, and who can reach it?
Our answer
Paměť is designed for European hosting, so company knowledge is intended to stay within the EU. The exact storage location, and which of our people can access it under which conditions, is agreed with you as part of deployment and described in the security overview. Ask our team for the version that applies to your environment.
- 02
Is our data used to train models for other customers?
Our answer
No. Your records exist to answer your company’s questions. Paměť is built around the principle that they are not used to train models for anyone else, and we will put that in writing.
- 03
Can an employee see something through the tool that they could not see in the source system?
Our answer
Paměť is designed to prevent exactly this. Retrieval is filtered by the asking person’s permissions before an answer is composed, so a person only receives answers built from records they may already access. Paměť is also designed not to confirm the existence of records outside a person’s permissions.
- 04
What happens when someone’s access is revoked, or they leave the company?
Our answer
Designed to support sign-in through your existing identity provider, so that removing a person there removes them from Paměť. When access to a source is withdrawn, the affected records are designed to stop contributing to that person’s answers. How quickly changes propagate depends on connector configuration; ask our team about the timing for your systems.
- 05
How is our data encrypted?
Our answer
Architecture includes encryption in transit and encryption at rest, including indexes and derived records. We do not publish algorithm names or key management details on a marketing page; they are documented in the security overview, which we share on request.
- 06
Is our data isolated from other customers?
Our answer
Each company’s memory is kept separate from every other company’s. Isolation options, from logical separation to dedicated environments, are available depending on deployment configuration.
- 07
Can we get our data out, and can we have it deleted?
Our answer
Both. Data ownership is a principle of the product: your records and everything derived from them remain yours. Export and full deletion at the end of a contract are designed into the offboarding process, and the timelines and written confirmation are agreed contractually. Ask our team about the details.
- 08
What do you log, and can we see it?
Our answer
Architecture is designed to support logging of access, questions and administrative actions for review by your administrators. Exactly what is logged, how long logs are kept and how they are made available depends on deployment configuration.
- 09
What happens if there is a security incident?
Our answer
Security controls can include an incident response process with defined roles, notification steps and post-incident review. We describe the current process to your team on request rather than summarising it here.
- 10
Which certifications do you hold?
Our answer
We do not display certification badges, audit dates or assessment claims on this site, and we would rather say so plainly than imply something. Ask our team about the current status of independent assessment and which documentation we can share with your security and legal teams.
Copy this list into your vendor questionnaire. If an answer here is not specific enough for your review, ask our team for the written version.
Documentation on request
The detail lives in documents, not badges.
We do not display certification badges, audit dates or provider logos on this site. What we can do is put the relevant documents in front of the people who need to read them.
Tell us who will be reading and what they need to decide. Some documents are shared under a non-disclosure agreement.
Security overview
For CIOs, CISOs and IT leadsHow Paměť is built, which controls the architecture includes, and which depend on deployment configuration. The place where protocols and providers are named.
Ask our teamData processing terms
For DPOs and legal teamsThe contractual basis for processing your company’s records: roles, purposes, sub-processing, retention, deletion and how data-subject requests are handled.
Ask our teamArchitecture summary
For architects and security engineersHow the connectors, the knowledge layer and the answer layer fit together, and where your data sits at each stage from source system to cited answer.
Ask our team
What this page does not claim
Ask us the hard questions.
Bring your CIO, your DPO and your most awkward scenario. We would rather have the security conversation early, in detail, and with the people who will hold us to it.
- EU data storage
- GDPR-conscious
- Access-controlled
- Enterprise-ready