Skip to main content
These are the questions security reviews, works councils and IT teams ask most often. Each answer is short and links to the page that explains more.

Data and models

No. For each question, Ainomos first checks which rooms the person may read. It then sends the model the question, the earlier turns of the conversation, the passages it found in those rooms, and the room’s rules and approved decisions. If the chat looks up more before it answers, it does so with the person’s own access. Background work, such as reading an imported document or dreaming, sends the content it works on to the model chosen for that room. A room’s data class decides which models may process its content at all.
No. Ainomos does not train or fine-tune any model. It sends a model only what one task needs, at the moment it needs it. Whether a model provider keeps or uses what it receives is set by your contract with that provider. When an external model answers, Ainomos names the provider and the place of processing. With a model you run yourself, the question does not arise. See models.
Yes. A platform admin can connect any model with an OpenAI-compatible interface, such as one served by vLLM or NVIDIA NIM in your own network, or a hosted one with your own key. Ainomos tests the connection before it adds the model, and you decide which data classes may use it. See connect a model.
Yes. Besides the Ainomos cloud, Ainomos ships as container images and a Helm chart for Kubernetes and OpenShift. Features such as log shipping then run inside your installation and need no cloud service.
In storage your organisation owns, if you connect it. Ainomos always keeps the text of an imported document. To also keep the original file, a platform admin connects S3-compatible storage such as AWS S3, MinIO or Ceph. Without it, Ainomos keeps no original. See file storage.
Its parts and their searchable passages are removed from the memory, together with any machine translations of them. Answers can no longer find or cite it. The import record and its evidence stay, so you can still show that the document existed and who removed it. Evidence records of earlier answers keep naming it as a source. If the original file was kept in your file storage, deleting the document does not remove that file. See documents.

Access and governance

Its members. Ainomos checks membership before every access, and the model never decides it. A membership in one room does not open the rooms beneath it unless your installation is set up that way. People with a reading role, such as Architecture reader or Auditor, can also read decisions across rooms without being members. See rooms and visibility.
Every answer and every governed action writes an evidence record that carries the verified identity of the caller. Where an agent works on behalf of a person, the record names the person and notes the app that triggered it. Where the agent has its own identity, the record names the agent. See audit log.
Not the verified parts. They come from a token your identity provider signed, and Ainomos checks that signature on every call. What an app says about itself, such as its name, can be wrong, which is why Ainomos stores and shows it separately as a statement, never as proof.
No. An agent can propose a draft. A draft does not apply. It becomes binding only when a responsible person approves it. See decisions.
No. The number of open drafts per room and per submitter is capped. Only a decision on a draft makes room for a new one. An inbox nobody can read through any more would get waved through, and the cap prevents that. See inbox.
It says so instead of asserting it. An answer without a sound basis is marked as such, and a missing source is never made up. See reading answers.

Audit and evidence

No. An evidence record stores a fingerprint of the question and of the answer, not the text. The same text always gives the same fingerprint, so you can show that a text matches a record, but the text cannot be read back from it. Log shipping never sends questions or answers either. See audit log.
Not without it showing. Each record carries the fingerprint of the previous record in its room, so a later change breaks the chain. When the installation has a signing key, each record is also signed with Ed25519 as it is written. Ainomos can re-check every chain and signature on request. See audit log.
Yes. Ainomos sends audit events to Splunk, or your SIEM fetches them, as Ainomos JSON or OCSF. Events carry metadata only: who, when, which room, what kind, the outcome. See log shipping.

Running Ainomos

Platform admins see a notice in the app as soon as a system is confirmed down, and the System status page shows what is affected and what to do. By default nobody gets an email. A platform admin chooses the recipients under Alert emails.
Yes. A platform admin sets the name, product name, logo, colours, footer and sign-in page under Branding. See branding and language.
The interface is available in German and English. Each person picks one in the Account menu. Drafts, proposals and rationales that Ainomos writes follow the organisation’s content language, German or English. Chat answers follow the language of the question, and a room can search each question in both languages, so an English question also finds German records. See branding and language.