A pale azure scene: silk flowing under a wide frosted glass plaque carrying the EU Artificial Intelligence Act mark.
Security & compliance · EU AI Act

Transparency
by construction.

The assistant tells people AI is answering, shows where every answer came from, and is contractually kept away from the uses the Act calls high-risk. Your deployer duties arrive already discharged.

The articles that matter, and where each lands.

The Act asks three things of a system like this: that people know they are talking to an AI, that the organisation deploying it keeps its people AI-literate, and that high-risk uses are kept out. Each one is a mechanism here, not a memo.

Article 50 · Disclosure

Every conversational surface — web chat, sign-in, invitations, messaging channels, the CLI — discloses that answers are AI-generated and cited. Not a setting that can be switched off.

Article 4 · AI literacy

The in-product help centre serves as the deployer's literacy resource: how answers are produced, what citations mean, what the assistant refuses and why.

Annex III · High risk

Deployments are contractually excluded from high-risk uses; the product is a knowledge engine over business documents, and the terms keep it that.

Human oversight

Answers cite their sources or decline; nothing executes actions. A human reads, verifies against the passage, and decides.

The EU flag on a stone facade. A person working through documents at a laptop. A law library aisle with a ladder. Two colleagues reading one screen together.
The conduct

Every answer's conduct, by construction.

Disclose: the surface says AI is answering. Ground: only the asker's permitted documents feed the answer. Cite: numbered sources, or an honest “I don't have that.” Defer: no actions executed — a human verifies and decides. Oversight is the workflow, not an add-on.

See it in the demo
The conduct of every answer as a rail — disclose, ground, cite, defer — under the EU AI Act plate, with the ‘You are talking with AI’ disclosure and high-risk uses excluded contractually.
The boundary

What the assistant is, and refuses to become.

A knowledge engine over your own documents: it reads them, grounds every answer in them, cites the source, and answers. It does not profile people, score candidates, evaluate employees, or trigger actions in other systems. Where a corpus contains people, GDPR mechanisms — export, erasure, records — run underneath every answer. And the boundary is contractual as well as technical: the terms exclude Annex III uses, so the system your counsel reviewed is the system your teams get.

The terms
The knowledge engine answering questions on one side; behind a dashed fence, the Annex III uses it is excluded from — profiling, scoring, evaluating, triggering actions — unwired and never built.
In writing

The position, in writing.

The position paper is readable in the trust library beside the architecture overview it depends on — request forms never gate the reading. Signed copies, the answered questionnaire and the architecture record land on your own thread from a standing account request, the day each exists.

Read the position
Three records — the architecture record, the data-processing agreement, the security questionnaire — wired to the account desk, landing with the reviewer on their own thread.

For your counsel's file.

The position and the records it rests on, readable right here — the EU AI Act measures, the architecture record, the GDPR mapping and the data-flow note.

Certifications & frameworks Read it here

EU AI Act: position & measures

Transparency by construction: AI-interaction disclosure on every surface, an AI-literacy resource in the product, high-risk uses contractually excluded.

Article 50
Every conversational surface (web chat, sign-in, invitations, messaging channels) discloses that answers are AI-generated and cited.
Article 4
The in-product help centre serves as the deployer's AI-literacy resource: how answers are produced, what citations mean, what the assistant refuses and why.
Annex III
Deployments are contractually excluded from high-risk uses; the product is a knowledge engine over business documents, and the terms keep it that.
Human oversight
Answers cite their sources or decline. Nothing executes actions; a human reads, verifies against the cited passage, and decides.
Technical documentation Read it here

Security & architecture overview

One client, one deployment, one boundary, what that means concretely: containers, database, credentials, the AI boundary and the audit chain.

Tenancy

Each client runs their own complete instance: application, worker, database and document store in isolated containers on a machine that serves no other client. There is no shared platform, no pooled database, no cross-tenant anything, isolation is the deployment model, not a configuration option.

Data at rest

Store
One PostgreSQL database per deployment: documents, search index, conversations, audit log, job queue.
Credentials
Connector and channel secrets are write-only after entry: accepted, used for syncing, never displayed again, and redacted from every API response.
Webhooks
Every messaging platform's signature scheme is verified; unsigned or mis-signed calls are rejected before any processing.

The AI boundary

Indexing (reading and preparing documents for search) runs entirely inside the deployment. Generation follows the deployment's configuration: the fullest posture is a self-hosted deployment that answers entirely on its own hardware, where nothing leaves the boundary at all. Deployments using the Naxis AI service send the question and the permission-filtered excerpts (zero-retention terms, see sub-processors); the model never sees documents the asking person cannot see, because permission filtering happens before the request leaves.

In every configuration: your data is not used to train models, and nothing is retained after the answer returns.

Permissions

Access is group-based and settled before a question is even considered, everywhere the assistant answers, never in any one surface. Accounts activate by invitation link; administrators never see or set a password. Channel guests receive nothing until groups are explicitly opened to them.

The audit chain

Every consequential event, questions, answers with their citations, administrative actions, syncs, erasures, lands on an append-only, hash-chained log. Verification recomputes the whole chain on demand from the console; a broken link is impossible to hide. Rows cannot be edited or deleted; retention prunes whole aged spans and records that it did.

Updates

Releases are versioned images; deployments install them in a quiet window after a safety backup and roll back on their own if the health check fails. What changed in each release is shown in the console in plain language.

Request to see

An account action, the request files under your Naxis account, and the answer arrives on its thread.

Certifications & frameworks Read it here

GDPR: how a deployment complies

The rights articles as product mechanisms: export, erasure, records of processing, each one built in, none of it paperwork after the fact.

Every Naxis deployment is a single-tenant system processing only the client's own documents, on infrastructure the client chooses. GDPR compliance is implemented as product mechanisms, not policies:

Art. 15 · access
Self-service "Export my data" for every signed-in person (JSON, complete), plus an administrator subject-access export for any subject the deployment knows.
Art. 17 · erasure
Hard delete, everywhere: a person's conversations, or a single document, are removed from the store and the search index in one action. Erasure is itself recorded in the audit log; no tombstone data remains.
Art. 28 · processing
Each deployment is contracted under a Data Processing Agreement including the sub-processor notice procedure (see Legal documents below).
Art. 30 · records
The deployment generates its own record-of-processing manifest from the configuration that actually runs (retention values, sub-processors, technical measures), so the paperwork cannot drift from reality.
Retention
Conversation and audit retention are explicit, configurable values enforced by a nightly job; the live values are shown read-only in the admin console.

The generated manifest for a specific deployment is available to its administrator at any time; a sample is in Technical documentation below.

Request to see

An account action, the request files under your Naxis account, and the answer arrives on its thread.

Technical documentation Read it here

Data flow & residency

What leaves the deployment, what never does, and where things physically live.

Never leaves
Documents at rest, the search index, conversation history, the audit log, user accounts and permissions.
Leaves per answer
With self-hosted AI: nothing. With the Naxis AI service: the question plus the permission-filtered excerpts needed to answer it, under zero-retention terms. Nothing else, no identifiers.
Residency
Managed hosting runs in EU data centres. Self-hosted deployments run wherever the client puts them, the product has no home-calling dependencies for its core function.
This website
Loads no third-party scripts; visit measurement is a first-party server log described in the privacy notice, with two first-party cookies only: the strictly-necessary account session and a random visit-measurement identifier. The product itself sets exactly one strictly-necessary session cookie. The interactive demo records usage under an explicit opt-in (see the privacy notice).
Request to see

An account action, the request files under your Naxis account, and the answer arrives on its thread.

Signed copies and the answered questionnaire land on your own thread from a standing account request; the full trust library carries the rest.

The AI Act, answered for deployers

Does the EU AI Act apply to a company using AI on its own documents?

Yes, as a deployer you carry transparency and AI-literacy duties. Naxis Assistant is built so those duties are already discharged in the product: every surface discloses the AI interaction (Article 50), and the in-product help centre serves as the literacy resource Article 4 expects.

Is a company knowledge engine a high-risk AI system?

Answering questions over business documents is not an Annex III high-risk use, and deployments are contractually excluded from being turned into one. The product answers questions; it does not score people, filter candidates, or decide anything about persons.

How do people know they are talking to an AI?

Every conversational surface says so: web chat, sign-in, invitations, messaging channels, even the CLI. Disclosure is not a setting that can be switched off.

What keeps a human in charge of the outcome?

The assistant cites its sources or declines, it never executes actions. A human reads the answer, opens the cited passage, verifies, and decides. Oversight is the workflow, not an add-on.

Where is this position written down for our records?

The position paper is readable in the trust library, and the architecture overview it depends on can be requested as a signed document from your account.

Double productivity now

Live demo

Notes from the build.

30 Jul 2026 · 8 min read

Shadow AI: your people are asking someone else about your company

Every paste into a consumer chatbot is a question your own systems could not answer fast enough. Security vendors sell detection, which reads the app and never the question. What the 2026 breach data actually shows, how far Microsoft's new Shadow AI controls really reach, and why the only fix that scales is making the company answerable.

25 Jul 2026 · 8 min read

Naxis vs Glean: enterprise platform or private knowledge engine?

Glean is Google for your company: it finds where things are stored. Naxis is the private knowledge engine that knows what is actually true right now. Different machines, different questions, different prices. An honest way to choose, and the Glean alternative for companies of 5 to 200 people.

All posts →