inxo — AI Disclosure

Version 2026-09-15.2.

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 inventing facts. 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. Links and email addresses a reply repeats back are checked against your workspace’s own known addresses; phone numbers are not — we hold no list of your numbers, so any phone number the check spots is flagged. Anything not recognised is recorded on every send. Under automated sending it withholds the message. On the human-approved path it does not block the send — it is shown to the person approving, on the approval screen, above the reply. What they are told is what kind of thing was found and roughly where it came from, not the value: the screen might say the reply contains a web link the check did not find in the conversation text it was given. Four limits, because they change what that notice means and what it does not reach. (1) The check reads a bounded, trimmed slice of the conversation and does not look at replies you have already sent, so “not found in the conversation” is not the same as “new” — a link from one of your own earlier replies is flagged the same way. (2) It reads the HTML version of the draft, including where its links point, while the approval screen shows the plain-text version, so what was flagged may be behind a link rather than sitting in the text you can see. (3) The notice describes the draft as it was when the check last ran. If you edit the draft the check runs again as you approve, and the screen tells you the earlier notice is out of date — but a destination your edit introduced is recorded at that point and the message goes; it does not come back to you as a fresh notice first. (4) These are pattern matches, and patterns miss things: an unusually written phone number, or a link in a shape the check does not recognise, is not flagged at all. We describe this one in more detail than the others because it is what stands between someone trying to get your system to echo their payment details back to your customer and your customer acting on them, 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, inventing a fact the model was not given, and — when you have left the default in place — promotional content, are handled by how the model is instructed, and the instruction itself is verified by our evaluation suite before a model version ships. They are not blocked by a detector on the human-approved path. The person approving is the control for those, and an instruction is a strong preference, not a wall: a reply that breaks one of these can reach the approver.

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.

A correction, and what changed (15 September 2026). An earlier version of this section said we were moving the no-promotional-content rule into a check on the finished text, “the same way the internal-identifier and secret checks already work”. We are not doing that, and this paragraph replaces that commitment. We looked at what such a check could actually do and concluded it would not do the job we implied. Wording does matter — it is part of how these rules decide whether a message is commercial at all. What a check on wording cannot do is tell you whether sending it was lawful, because that also turns on something no email contains: whether your recipient asked to hear from you, or whether an exemption applies. So a check that fired correctly would still not tell you the reply was compliant, and one that fired wrongly would stop you answering an ordinary question. And a check precise enough to be worth having is not available in either direction: loose enough to flag “we also offer a Pro plan” and it flags ordinary support answers about plans and pricing; tight enough to leave those alone and it does not flag that sentence at all.

What we did instead. Replies stay transactional by default — they answer what was asked and nothing else — and that is how every workspace starts. If you want your replies to be able to mention your own products, plans or pricing, that is now a setting you control, in Settings, alongside your voice. Turning it on changes exactly one instruction and leaves every other one in place — in particular, the model is still instructed not to invent an offer, a price, a discount, or a link it was not given. Be clear about what that is worth: like the default itself, it is an instruction, not a detector (see the third category above), so it can be broken and reach the person approving. What does not depend on the model behaving is the destination check — a link to somewhere your workspace has not listed is flagged the way any other unrecognised destination is, and under automated sending it withholds the message.

One thing we cannot do for you, said plainly. If a message is commercial, the rules in most places also require it to identify the sender and to offer a way to opt out — and in the EU and the UK that requirement is stricter, because they have no equivalent of the US test that treats a reply answering a question as transactional. inxo has no way to guarantee either of those appears in your replies. We do not attach a footer: there is no mechanism in the product that adds text to a reply after the model has written it, and we are not going to add one, because it would land on the ordinary transactional replies too — where no opt-out is required and one would make a plain answer read as marketing. What we hand to Microsoft is the body as it stood when it was authorised, character for character — the text the person approving saw on the human path, the text the draft held when your agent approved it under automated sending, and your own configured wording for an automatic acknowledgement, which nobody reviews per message because you wrote it in advance. What inxo adds rides as a header, outside the message, never inside it. (The subject is the one thing the server sets rather than carries: it uses the conversation’s own subject, adding “Re:” if it needs one. The model does not choose it — though the conversation’s subject did, of course, come from the correspondence itself.) You can put such wording in your workspace voice, but that is an instruction the model follows, the same category as everything else in the third group above, and it can be dropped without anything noticing. So: if your replies need to carry that wording to be lawful where your recipients are, this setting is not safe for you to turn on unless a person reads every reply.

We are telling you this is your decision rather than making it for you because you know something we do not: who your recipients are and what they have agreed to. Whether a message counts as commercial is governed by law that differs by country — Canada and the EU/UK treat it more strictly than the US does — and under the Terms the content you direct through the Service is yours. The honest position is that we give you the safe default, the switch, and this explanation, not a filter that would imply a protection it cannot provide.

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.