AI Disclosure
Effective 2026-09-10
inxo — AI Disclosure
Version 2026-09-10.
How inxo uses AI, in plain terms, and what we do about it.
1. What is generated
inxo uses a large language model to do two things: classify an incoming email, and draft a reply to it. Nothing else in the product is model-driven — threading, deduplication, routing, sending and every safety check are ordinary code.
A draft is not sent by the model. It is proposed to a person at your organization, who reads it, may edit it, and approves it. That person is the author.
2. What the model is allowed to produce
When drafting, the model returns one thing: the body text of a reply. It cannot set the recipient, the subject line, the sending address, the reply language, or the AI marking. Those are applied by the Service.
When classifying, it returns a small, fixed set of labels about the incoming message — a category, an urgency, a confidence score and a short internal summary. Those never become part of a reply; they route the message and inform the person reviewing it.
This is a safety property, not an implementation detail. Incoming email is written by whoever sent it, and some of them will try to make your system do something — redirect a reply, quote an internal identifier, add a link. The reason those attempts fail is that the fields they would need to change are not fields the model can write.
3. Machine-readable marking
Messages generated with AI assistance carry machine-readable marking identifying the content as artificially generated, applied by the Service to the outbound message itself, before the message takes either the human-approved or the automatic path. We record which marker was applied, under which scheme and policy version, against the send — so the record reflects what actually went out rather than an intention to mark.
If a required marker cannot be applied, the send fails. It does not go out unmarked.
4. Telling your correspondents
Whether, and how, the person receiving a reply is told that AI was involved is a decision for you as the organization sending it, and it depends on your circumstances.
We have built the capability to attach a human-readable disclosure to outbound messages and reserved it, but we have not yet set a policy for when it is used, because that policy depends on legal advice we have not yet taken. This document will say what the policy is once it exists. We would rather tell you it is open than imply a decision we have not made.
What we can say now: two things count against an ordinary transactional reply needing a human-readable label today. It is a private reply to the person who wrote to you, not text published to inform the public — which is what the relevant obligation targets. And a person read and approved it. We are keeping the capability in reserve regardless, because this is a fast-moving area and we would rather have the switch built than need it and not have it.
5. Automated sending changes this
If you enable automated sending, messages go out without a person reading them. The “a human took editorial responsibility” position above does not apply to those messages, and you should not assume any exemption resting on human review covers them.
Automated sending is off by default, is enabled per workspace, and requires a separate authorship election that says this in its own words.
6. What the model gets to see
To write a reply that fits the conversation, the model receives context drawn from the thread — not just the latest message. It is bounded: there is a size budget per message and for the thread as a whole, and when a conversation exceeds it the newest turns are kept and older ones are dropped, with the message being replied to always retained. So it is a budget-bounded selection from the thread rather than, in every case, the entire history — we would rather describe that precisely than promise “everything”.
It does not receive attachments. Content hidden inside HTML is stripped before the model sees the message, because hidden text is a standard way to smuggle instructions past a human reader.
Where a thread names people other than your correspondent, their names are in that context. We treat that as a disclosure worth stating rather than one to bury.
7. Your knowledge base
If your workspace has a knowledge base — documents you’ve uploaded, FAQ entries, pages we’ve read from your site — drafting searches it. The incoming message becomes a search query, and the passages that match are given to the model alongside the thread, so a draft can answer from what your business has written down instead of guessing. If there is nothing to search, the search cannot run, or it fails, the draft falls back to the thread alone and records that it did — it does not go out looking better-sourced than it is.
Two things about a knowledge base are worth stating plainly, because a knowledge base behaves differently from a thread.
It is shared across every conversation in your workspace, not scoped to one customer. A passage written to help one customer can be matched and used again while replying to someone else. That is what makes it useful — the model can answer from something you wrote once, for anyone who asks something close enough to it — and it is also the thing to know if an entry in your knowledge base ever names a specific person or their details.
A retrieved passage is handed to the model as content, not as instruction — delimited and labelled the same way an incoming email is. We will not tell you that makes it harmless, because it does not. The model writes the reply’s body text, so text that reached your knowledge base — including text put there deliberately to steer a reply — can influence what a draft says, and can put a link or a wrong statement in one. What it cannot reach are the fields the model is never allowed to write: who the reply goes to, its subject, the address it is sent from, its language, and the AI marking. Those are set by us from the conversation, not by anything the model or your documents produced.
So the containment for what a passage can make a draft say is the person who reads it before it goes — which is why the next paragraph is not a nicety.
Because a knowledge base is shared across conversations, any reply written using it is held for a person to review. It is not sent automatically, whatever your automated-sending settings would otherwise allow — a check that happens to read the wording as clean is not the control here; a person seeing the reply before it goes is.
8. What the model is steered away from — and how strongly
The Service works to keep replies from committing you to a fix, promising a timeline, disclosing internal identifiers, or carrying promotional or marketing content. These are not all enforced the same way, and the difference matters to you, so here it is plainly:
- Structural — the system makes it impossible. The recipient, subject, sending address, reply language and AI marking are not fields the model can write, so nothing in an incoming email can redirect a reply or change what it claims to be.
- Checked on the finished text. A final check runs on the exact body about to be sent. On the human-approved path, a finding that the model introduced an internal identifier, a secret or personal data it should not have blocks the send and returns the draft for review. Under automated sending, any finding withholds the message.
- Checked, and you are trusted with the result. A link, phone number or payment or contact detail that a reply repeats back is checked against your workspace’s own known addresses. One that isn’t recognised is recorded on every send. Under automated sending it withholds the message. On the human-approved path it does not block the send — and, today, it is recorded rather than shown to the approver. We are saying so because this is the check that matters most against someone trying to get your system to echo their payment details back to your customer, and “a human is the control” only works if the human is told.
- Steered and measured, with the reviewer as the real catch. Commitments, promised timelines and promotional or marketing phrasing are handled by how the model is instructed, and the instruction itself is verified by our evaluation suite before a model version ships — but they are not blocked by a detector on the human-approved path. The person approving is the control for those.
We would rather tell you which of these is a wall and which is a strong preference than let you assume the wall is everywhere. If you enable automated sending, the third category is running without the control it relies on.
We are closing that gap before automated sending is available to any customer. The no-promotional-content rule is moving from steered-and-measured into a check on the finished text, the same way the internal-identifier and secret checks already work — so a promotional line will be caught the way those are, not merely discouraged. Until that ships, this section describes the control as it actually stands today, not where we expect it to stay.
9. Accuracy
Drafts can be wrong. A model can produce something fluent, confident and false. That is why human approval is the default, why you can edit any draft, and why we describe automated sending as a higher-risk mode rather than an upgrade.
Under automated sending the check described above — a person reading it — does not happen for the messages it covers. Section 5 and the authorship election say what does, and does not, take its place.
10. Model changes
The drafting model is version-pinned. A change of model version re-runs our safety evaluation gate before it reaches production; a model version that fails does not ship.
11. Training
We do not train on your data, and we will not, regardless of what any model provider’s terms say. We will not send your mail to a model provider until that provider’s no-training commitment is executed and in force for the specific model endpoint used — a fail-closed readiness check blocks drafting and classification for a workspace until the provider’s terms are in force for its target, so there is no path by which your mail reaches an endpoint whose no-training terms are not yet executed.