Sonela is an enterprise knowledge AI platform under the software your team already uses. Staff ask in plain words, it finds the answer in your own information, and it answers from that alone. It never changes anything.
Finding before answering is what retrieval-augmented generation (RAG) means, and here it finds three kinds of thing: rows read from your live records by one read-only query, passages from your written material, cited under the answer, and replies from your own systems when a question calls for them. The assistant is one application built on it.
Below: everything it can do, how your data is connected, what happens to a question from the moment it is asked, and the guarantees that keep your data safe.
What the platform connects, how it grounds an answer, how it is governed and where it is delivered: one set of rules and one bill.
Plain English in, read-only SQL out, checked against a grammar that cannot express a write. PostgreSQL, SQL Server, MySQL and Oracle, each shipped only with its full safety-test suite.
Someone can send a picture of the screen with the question, so “why is this line red?” becomes something they can ask. They choose to every time, and you can stop it altogether.
The records your application already loaded for the person asking go with their question, so the assistant answers about the one on screen, counting only what that page loaded. The brief says exactly where it stops.
Your records and your documents, nothing else. Answers never come from what a model remembers about the world, and when your material cannot support one, it says so.
Upload your handbooks and SOPs, and it answers from them. You can start there, with no database connected at all.
Share a Drive folder with a service account you own, or let your own Microsoft app read SharePoint or OneDrive for work or school. Google Docs, Word and Excel files are read hourly, and a file you stop sharing leaves. On Growth and Scale.
Name your public site and it is read in and re-read weekly: same host, up to two hundred pages three clicks deep, robots.txt honoured, and page text never reaches a log.
Add a public Facebook page or Instagram profile and it answers from the latest posts, each with its link, so this week’s opening hours come from where you announced them. On Growth and Scale.
Give it the product feed you already make for Google Shopping or a Meta catalog. Visitors ask by budget, brand or specification, and each product the answer names is drawn under it with its picture, price and availability. On every plan; for shops.
Register an endpoint and say what it is for. When a question calls for it, the assistant calls it and answers from what comes back. A search form your site already has is posted the same way, and the page that answers is read.
Switch a key to knowledge base and it answers on any subject your documents cover, from them alone and in its own voice, with no database, API or document template in reach. On every plan.
Upload a Word file with placeholders. Asked for that document, it fills the values from the conversation, shows every one, and on a plain yes emails the .docx to the person signed in.
Only the template is kept. On Growth and Scale.
Answers arrive word by word, with each step shown while it works. A number after a sentence opens the manual passage it came from, the rows that are the answer sit under it, and “Where did this come from?” shows the rest. One click copies it.
Each key speaks the one you choose of English, German, French, Spanish, Italian and Albanian: buttons, refusals and replies alike, whatever language the question came in. You preview it first, and two markets run two keys.
On the paid plans people press the microphone and say the question, turned into words by Sonela’s own AI provider whichever key answers; a spoken question costs three credits. The answer can be read aloud. Your public assistant takes dictation on Scale.
Offer up to five opening questions. As someone types, it suggests questions taken word for word from your manuals, built with no AI, and where the browser has its own on-device model, the rest of the sentence. One switch turns both off.
Bring your own and your rows reach only the provider you chose, under your own agreement, paid direct. Run on ours and there is nothing to set up — that model cost is ours, which is what those plans price in.
Before the AI model — yours or ours — reads a question, your records or your systems’ replies, the personal details Sonela recognises become placeholders, and the answer gets the real values back. The brief says where it stops.
When the AI provider answering a question cannot, the next one does. On our key we run more than one, so an outage cannot take your assistant down; on your own, add a second key as its backup.
Bring several keys of your own and share conversations between them by the percentages you set. Each conversation keeps the key it was given, and moves only if that key fails.
Colours, name and greeting are set in your dashboard and reach every page carrying your key at once. On Growth and Scale it can open as a sidebar beside the page, and wait in the corner as a circle, a named card or an invitation. Nothing is redeployed and no tag is edited.
Your admin sees what was refused and every change anyone made to the setup. Usage is counts of questions answered, never the conversations. Questions you trust are asked again after each change: how it stays right.
Three put it in front of your staff and carry nearly everything. The fourth answers anyone on your website, deliberately narrower — the table marks every difference.
One script tag, and it appears inside the screens your staff already work in.
For when a vendor owns your app or the release train is long. Nothing to deploy: you list work addresses and an emailed code lets them in.
The same gateway, the same approved schema and the same read-only rules. What it cannot do is send the screen someone is stuck on, or read the page’s own data: our page is not your application. It is the quicker way in, not the better one, and moving to the tag later repeats nothing.
The hosted page works on a phone the day you switch it on: same link, same code, signed in for thirty days. iOS and Android apps wrap that same page.
The same one line, on a key you mark public: it answers your visitors from your published material, never from your database.
You choose which manuals it reads, write a part of your business context for visitors alone, cap the questions it answers in a day, and show it on a share of page loads. The public assistant guide walks through each.
This is the whole change to your app
<script src="https://api.sonela.ai/sonela.js" defer></script>
| Capability | In your app | Hosted page | Phone app | Public site | API |
|---|---|---|---|---|---|
| Questions into SQL | Yes | Yes | Yes | No | Yes |
| Your documents and SOPs | Yes | Yes | Yes | Yes | Yes |
| Reading your website | Yes | Yes | Yes | Yes | Yes |
| Calling your own APIs | Yes | Yes | Yes | Only the ones you open to visitors | Yes |
| Grounded, or it says so | Yes | Yes | Yes | Yes | Yes |
| Your AI key, or ours | Yes | Yes | Yes | Yes | Yes |
| A backup AI | Yes | Yes | Yes | Yes | Yes |
| Load balancing | Yes | Yes | Yes | Yes | Yes |
| Governance and the record | Yes | Yes | Yes | Yes | Yes |
| A picture of the screen | Yes | No | No | No | No |
| Reading the page's own data | Yes | No | No | No | No |
| Answers in your language | Yes | Yes | Yes | Yes | Yes |
| Dictate a question | Yes | Yes | Yes | On the Scale plan | No |
| Documents from your templates | Only where your sign-in names the person | Yes | Yes | No | No |
| Your product catalog | Yes | Yes | Yes | Yes | Yes |
A server of yours asks the same assistant over an API and gets text, tables or a stream back.
It presents a secret key you make in the dashboard, and the key fixes whose records it may ask about, so nothing in a request can widen that. You set each key’s limits and revoke it when you like. Read-only like everything here, on the Growth and Scale plans — the table’s last column is what it carries.
The same API keeps your manuals up to date from your own systems and, for a vendor, adds each new customer as your sign-up flow creates it: the API guide has both.
It is also how the assistant reaches Slack, Microsoft Teams or another app your people work in: a small service of yours carries each question across. Read the integrations guide.
Inside a larger organisation
The team that has to clear a security review before anything new touches the business software. You get the brief your reviewer asks for and a record of every change and refusal — bought with a card, not a procurement cycle.
In a small team
Running a line-of-business app you cannot afford to have answered wrongly. The same product, the same guarantees and the same brief — first-class citizens, not a cut-down tier.
And software vendors, who hand it on across a customer base — a different shape, with a section of its own.
The simplest path is a direct connection: nothing to install, two steps in your dashboard. When your review wants nothing of yours reachable from outside, run the Sonela Gateway instead — the high-security option. The same read-only rules apply either way, and where people meet the assistant is a separate choice: none of the channels changes anything here.
Give us what your database expects at sign-in. We test the connection before we accept it, and there is nothing to install.
On our infrastructure, encrypted, bound to your workspace, and no API of ours reads them back. Your database has to be reachable from the internet for this, and we name no fixed address to allow through a firewall — if yours sits behind one, the gateway below is the way in.
Sonela drafts a manifest of what it can see. Nothing is queried until you approve it.
It reads your schema and drafts the manifest. You hide what shouldn’t be visible, confirm how customers are kept apart — or that the database has one owner — and approve.
One small service, on one server of yours, next to the data it reads. It dials out to us over port 443 and asks whether there is work, so you open no inbound port and nothing connects inward.
You configure what the gateway needs to reach your database on your side, and that stays there; the read-only checks run there too. The schema step is the same, and the gateway reads it from inside your network.
Five stops, in the same order, every time.
In the app they already have open, in the words they would use with a colleague.
It retrieves the passages, posts and pages that bear on the question, rather than guessing at your industry from the outside.
Your data in the shape you approved, the procedures and policies you uploaded, the context you wrote for your workspace — that is the material, and the vocabulary it answers in.
Right then, from your live records — not a copy, not last night’s export.
Only the tables you approved, so a question about anything else has nowhere to go, however well it is put. It sees one customer’s rows — the ones the embed is for — and it can only read them.
The real numbers, or a short table — never a chart to go and read for yourself.
That is the answer. The preview on the home page closes on exactly that exchange, and it is the product working rather than failing.
The conversation lives in the browser tab and goes when the tab does, unless they hand it to your people.
What they said passes through us and the AI provider composing this one answer, and is written down nowhere — not in a transcript, not in a cache another question could reach. The exceptions are theirs to make: reporting an answer offers them a ticked box that sends that one question and that one answer to you, and unticking it reports the answer with no words at all. Where you switch it on, they can also hand the conversation to your people in the same chat, and it is kept for your team until 30 days after it ends.
Exactly what happens to your data, including the parts most vendors leave out.
Your data
Nothing it runs can write to your database.
An allowlist validator refuses anything that isn't a single SELECT. What survives runs under a three-second statement timeout and a cap of 500 rows — on PostgreSQL and MySQL inside a READ ONLY transaction the database engine itself will not let write. And every transaction is thrown away rather than committed — there is no commit in the query code for any path to reach.
Your data
One customer's rows, and never another's.
Every table reference is rewritten into a tenant-filtered subquery before execution. The tenant identity is bound server-side from a verified token — the browser can't assert it, and the model never sees it.
Your data
No question, no answer, no row of yours is written down here — except what a visitor chooses to send you.
Answers grounded in your data are structurally uncacheable. In the assistant's panel, the transcript stays in the visitor's browser.
Our metering stores counts, latency and token totals — never a question, an answer, or a line of SQL. We keep two things, both the visitor's choice: an answer someone reported and chose to send you, that one question and that one reply, read by your workspace and never by us, deleted 100 days later; and a conversation someone handed to your people, read the same way and deleted 30 days after it ends.
Your data
What the gateway needs to reach your data stays inside your network.
Run that way there is nothing for us to store: the field on your workspace holds null, and what we keep is a hash of the gateway's key.
An AI key you bring is encrypted with AES-256-GCM, bound to its own row, and no API we expose reads it back.
Its answers
The rules reach the model before any of your content does.
Everything the workspace supplies — the question someone typed, the procedures you uploaded, the context you set — is handed over under an explicit instruction to treat it as data with no authority to change them.
And it does not have to hold: the read-only grammar and the tenant rewrite run after the model has spoken, so content that talked it into something still cannot write, and still cannot reach another tenant.
Your data
Your server can vouch for who is asking, with a secret that never reaches the browser.
It signs a short-lived token; the assistant refuses to start a session without one. Turn it on and only pages your server has vouched for can open a conversation at all.
Generating the signing secret arms the workspace and breaks nothing that is live; refusing unsigned pages is a separate switch that stays yours. Until you flip it, an anonymous session still answers, held to a per-visitor-address slice of your workspace's own request rate — strangers divide your capacity, never widen it. A vouched session is served at the workspace's full rate, with no per-address slice.
Personal data
The ID numbers Sonela recognises, and the names and contact details your switches mask, reach the AI model — yours or ours — as placeholders, and the real values come back in the answer.
The question, the conversation so far, the rows a query returns and your own systems’ replies — and, on every assistant but a public one, your manuals. Card numbers, IBANs, passwords and ID numbers are masked for every workspace; names, contact details, addresses and company names are switches under Data sources → Personal data in your dashboard, beside a count of what was masked, and a new workspace starts with names and contact details masked.
Another switch decides whether the people asking see the real values or the placeholders. When the assistant looks a record up by a masked value, Sonela fills in the real value itself.
Sonela recognises a value by its format and checksum, its column, or the title or label in front of it: a careful heuristic, not a guarantee. A name in an ordinary sentence with none of those reaches the model as written, and so does a screenshot. The security brief lists where it stops.
| Data | What actually happens |
|---|---|
| The question someone types | Reaches Sonela and an AI provider — the one you chose if you brought a key, one of those we run if you did not, and a second of ours only when the first cannot answer. The ID numbers Sonela recognises in it, and the names and contact details your switches mask, reach the provider as placeholders. Its words are not stored afterwards, unless someone reports the answer to you or hands the conversation to your people. |
| Rows returned by a query | Pass through Sonela's memory to compose the answer, and reach that same provider with their personal details masked the same way. Never written to our disks. |
| An answer someone reports | Reporting an answer offers a ticked box that sends that one question and that one answer to you, so you can put it right; unticked, the report arrives with no words at all. Only your workspace reads them — we count reports and never see the text — and they are deleted 100 days later. You can switch reporting off. |
| A conversation handed to a person | Where you switch it on, someone who asks for a person can carry on in the same chat with your people, told first what is kept. The conversation so far and what either side writes after it are kept for your workspace alone — we never see the text — and deleted 30 days after the conversation ends. |
| How your data is reached | Two ways, and you pick. By us, directly, using the sign-in details you gave us: those sit on our infrastructure, encrypted, and no API of ours reads them back. Or, for the strictest reviews, by the gateway you run, from inside your network — what it needs to do that is configured there and stays there. |
| A screenshot someone sends | Reaches that same provider as it was taken, with the one message it was attached to. Never stored, never logged, and it does not join the conversation. |
| Your AI provider key | If you bring one: encrypted at rest, never returned by any API. On Sonela's key: there is none of yours to hold. |
| Written material you upload | Procedures, notes and policies you give the assistant are kept in your workspace — that is what they are for — and go to the same AI provider with the question. Only your workspace can read them; deleting them, or the workspace, removes them. Google Docs, Word and Excel files you sync from Google Drive are kept the same way, read with a service-account key that is encrypted at rest and never returned; a file you delete or stop sharing in Google Drive is removed at the next hourly sync that reads everything you shared, and any file Google has not confirmed for seven days is removed even if no sync could reach it. Word and Excel files you sync from SharePoint or OneDrive for work or school are kept the same way, read through your own Microsoft app with a certificate whose private key is encrypted at rest and never returned; a file you delete in SharePoint, or that your app may no longer read, is removed at the next hourly sync that reads everything you added, and any file SharePoint has not confirmed for seven days is removed even if no sync could reach it. Posts from public Facebook pages and Instagram profiles you add are kept the same way, the latest ten from each: a scraping provider reads the page for us and is given its address and nothing else of yours. A post you delete from the page is removed within a week, at the page's next full reading, and a page no full reading has confirmed for fourteen days loses its posts. Products from a product feed you add are kept the same way: each product’s name, description, price, availability, link, picture address, brand, product codes, categories and specifications, replaced whole at each reading and deleted with the feed or the workspace. Pictures load from your shop’s own address and are never copied, and the address of the page a visitor has open is used for that one question to find its product and to tell the assistant which page it is asked from, by its path and title and never its query string, then dropped. |
| Chat transcripts | In the assistant's panel, held in the visitor's browser for the conversation. We keep no conversation unless a visitor hands it to your people; a reported answer is one exchange out of one, and nothing either side of it. A signed-in hosted page keeps its last conversation sealed on that person’s own device for up to seven days. |
| Question or answer text in our metering | Never collected — counts, latency and tokens only. |
| Write access to your data | None, by design. There is no code path that writes. |
We are a data processor. Questions and rows transit us and the AI provider that answers; neither is kept, bar an answer someone reports to you, a conversation someone hands to your people, and an answer that read no records, remembered for up to seven days against a hash of its question.
Both switches start on, and both are one click to turn off.
The assistant is more useful when it can see what someone is looking at, and it is more exposed for the same reason. Both of those are true at once, so the decision is yours rather than ours — and a trial that hides its useful half is not a trial.
| Switch | What turning it off does |
|---|---|
| Page screenshots On by default | Once the setting reaches the page, no camera in the composer and the code that would take a picture is never loaded. |
| Reading the page's own data On by default | On a production embed the reader is never installed, so nothing is captured at all, and a page opened before you switched it off is not read either. On, it lets the signed-in assistant answer about the record on screen, from what that page loaded and nothing more. |
Both settings belong to the workspace, and we hold them — a page carrying the assistant cannot quietly restore either.
Every embed in the workspace moves together. Your staff see the guarantees too: a shield in the assistant’s panel opens them in plain words, and when page capture is on, the person being read is told. The security brief sets out exactly where each switch stops, and where it does not.