Questions and answers

An email address. No card, and no AI key — a trial runs on Sonela's key, on a model we pick, under our agreement with the provider. It lasts 14 days or 320 question credits, whichever comes first.

You do not need your data connected on day one. Start by giving the assistant your own written material — procedures, product notes, policies — and it answers from that, and says plainly that it cannot see live records yet. Bring your operational data in through the gateway when you are ready: it is the same workspace, and everything you set up stays set up.

A platform. Sonela is an enterprise knowledge AI platform powered by retrieval-augmented generation (RAG): for each question it retrieves what can answer — rows read from your live records by one read-only query, passages from your written material, and replies from your own systems — and the model answers from that alone, or says it cannot.

The assistant is the application people talk to, in your software, on a page we host or on your public website. The API, documents filled from your Word templates, product recommendations for shops and a knowledge base on any subject run on the same platform. It never writes to your data, does not search the web and trains no model on your data.

It keeps no transcript on our servers unless a visitor hands the conversation to your people: a reported answer goes to you, an answer that read none of your records may be remembered for up to seven days against a hash of the question, never the question’s words, and a signed-in hosted page keeps its last conversation sealed on that person’s own device.

Yes. We host the assistant on a page of our own instead, and you invite people to it by email address — they sign in with a short code, so there are no accounts or passwords for you to manage. The gateway and the schema you approved are unchanged.

Be aware of what it costs: on our page nobody can send the screen they are stuck on, because our page is not your application. That is the one capability the embedded assistant has and this one cannot. It is the quicker way in rather than the better one, and you can move to the script tag later without setting anything up twice.

Yes, on the Growth and Scale plans. Your server sends a question over an API with a secret key you make in the dashboard, and gets the answer back as text and tables, or as a stream. The key fixes which data source it asks through and whose records it asks about, so nothing in a request can widen either.

You set the limits on each key, rotate it, and revoke it whenever you like. We keep only a hash of it, so nobody can read it back, us included. It is read-only, like everything else here, and a key belongs on a server, never in a web page.

No. Three independent layers stop it: the validator only permits a single read query, that query runs under the engine's own guards — on PostgreSQL and MySQL a READ ONLY transaction it will not let write — and the transaction is rolled back rather than committed. Even a compromised model can't write.

To connect directly, your database has to be reachable from the internet: you give us what it expects at sign-in, and we hold those details encrypted, bound to your workspace.

If your review wants nothing opened at all, run the gateway, the high-security option: it sits inside your network and dials out to us over port 443, so there is no inbound port to open and nothing of yours exposed to the internet. Whatever it needs to reach your data is configured on your side and stays there; what we hold of it is a hash of the gateway's key, plus the schema manifest you approved. The security brief states both paths in full.

Yes — that is exactly what the Sonela Gateway is for. It is one small service you run on one server inside your own network, next to the data it reads. It reaches out to us and asks whether there is work; we do not dial into it.

Everything that matters happens on your side of the firewall: the gateway checks the query, applies your tenant filter, runs it read-only and sends back the rows. Nothing lands on anyone's desk, and there is nothing for your team to install on staff machines.

Yours or ours — it is a choice on each paid plan, and it moves both the price and the included balance of question credits. Bring your own key and your rows reach only the provider you chose, under the agreement you already hold with them.

Run on Sonela's key and your rows reach the provider we run, under our agreement, on a model we pick for cost. Trials always run on our key, so there is nothing to configure to start one.

PostgreSQL, SQL Server, MySQL and Oracle today, Oracle through the Gateway — each shipped only once its full safety-test suite passed. For AI: Gemini, Anthropic, OpenAI, Azure OpenAI, or any OpenAI-compatible endpoint if you bring your own key — or Sonela's key, where we run the provider and choose the model.

Every query is rewritten so each table reference is filtered by tenant before it runs. The tenant identity comes from a token your server signs, never from the browser — so a user editing JavaScript in the page can't reach another tenant's rows.

You are asked exactly once, when you connect: say the database has one owner and the tenant filter is skipped, because there is no second tenant to keep out. Everything else is identical — the read-only guarantees, the approved schema, the metering — and nothing is read from your database until you have answered.

No. We train nothing, and we don't use your data to improve the service for anyone else.

Your rows go to the AI provider that answers the question and no further: the one you chose under your own terms if you brought a key, or one of the providers we run under ours if you did not. We hold accounts with more than one so an outage cannot take your assistant down, and a question reaches a second only when the first cannot answer it.

Less of it, and you decide how much less. Before a question and the records that answer it reach the AI model — the one you chose under your own key, or one Sonela runs under ours — Sonela swaps the personal details it recognises for placeholders: names, the part of an email address before the @, phone numbers, and ID, card and bank account numbers. The model answers with the placeholders, and Sonela puts the real values back before the person asking reads the answer, unless you choose to show placeholders; a card number or an IBAN Sonela recognises stays out of the answer, which says one was removed.

Card numbers, IBANs, passwords and ID numbers are masked for every workspace, whatever its settings. Names, contact details, addresses and company names are switches in your dashboard, and a new workspace starts with names and contact details masked.

Masking is a careful heuristic, not a guarantee: a name in an ordinary sentence with nothing to mark it as one reaches the model as written, and so does a screenshot. The security brief lists where it stops.

It says so. Sonela answers from your own material — a query against your live operational data, or the procedures you gave the workspace — so when neither can support an answer it reports that instead of guessing: a wrong number delivered confidently is worse than no number at all.

It fails out loud. A passing glitch — a rate limit, a bad minute at the provider — is retried first; what survives that is reported as a failure, never as a blank answer and never as a guess. Your Usage screen says which questions failed and names the provider's part in plain words — refused, no capacity, retried — while the widget your staff use says only that the assistant is unavailable, because naming your provider's fault to whoever is on the page would describe your setup to a stranger.

English, German, French, Spanish, Italian and Albanian. Each key speaks the one you choose — its buttons, refusals and replies alike — whatever language the question was asked in, on every channel, so a business serving two markets runs two keys. Your manuals and records are not translated: names, codes and values stay as you wrote them.

Yes, on Growth and Scale. Upload a Word file with placeholders and describe each one.

When someone signed in asks for that document, the assistant fills the values from the conversation, shows every one, and only on a plain yes emails the .docx to the address they signed in with. Only the template is kept. Your public assistant sends no documents, because nobody is signed in there to send one to.

Yes, on Growth and Scale. Share a Drive folder or files with a service account your organisation owns, or let your own Microsoft app read SharePoint or OneDrive for work or school. The files are read every hour, a file that leaves is removed at the next sync that reads everything, and how many you can add depends on the plan.

Yes, if your shop makes a product feed. Give it the feed you already make for Google Shopping or a Meta catalog, and visitors can ask by budget, brand or specification; each product the answer names is drawn under it with its picture, price and a link.

It recommends and links, and never adds to a cart. It is on every plan, the trial included: read the page for shops.

Write golden questions: ones you know the answers to, with what each answer must state, cite or read. They are asked again after each change that can move an answer — the glossary, an approved schema, the manuals, your own AI keys, an access profile, what a key reads — and once a week, with before and after kept side by side. Workspaces that switch it on get a weekly accuracy report by email: how it stays right.

Yes. Each signed-in key reads every manual, lookup and template, or only the ones you tick, so a back-office assistant and a customer portal can read different material in one workspace. What a key does not read never reaches its answers, citations or suggestions, and a change applies from the next question, with no new tag to paste.