inxo — AI Disclosure

Version 2026-10-03. For an organization that accepted an earlier version, this version takes effect on 2026-11-05.

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. Under the EU AI Act (Regulation (EU) 2024/1689), the obligation in Article 50(4) runs to the deployer — whoever uses the system under their own authority to reach their correspondents. That is you, not us. We operate the tool; you decide what goes to whom and why.

A note on vocabulary, because two frameworks are in play and they are not the same scheme. Our data-processing terms call you the controller and us the processor. The AI Act calls you the deployer and calls us the provider of the drafting system we built. The roles happen to land the same way, but they are determinations under different statutes, and neither one settles the other.

A correction, and what changed (3 October 2026). An earlier version of this section said we had built the capability to attach a human-readable disclosure to outbound messages. That was wrong. We have reserved the design for it — a visible line telling the recipient AI was involved — and it is not built, and we have not set a policy for when it would be switched on. We checked the code rather than the intention, and the intention is what the sentence had described. What is built and unconditional is the machine-readable marking in §3; that part was accurate. The rest of this section and §5 are reordered rather than reversed: the reasoning now leads with the point that does not depend on who reviewed a message, which is the one that holds up if we ever publish generated text rather than send it to one person. No obligation of yours, and nothing the Service does, changed with this version.

Our reading of why an ordinary reply does not need a visible label today — and this is our reading, not settled law. Article 50(4) has two separate limbs, and in our view an ordinary transactional reply is outside both:

1. The first limb is about images, audio and video — synthetic media presented as real. A reply made of text is not within it at all, whatever else is true about the reply.
2. The second limb is about text, but only text PUBLISHED to inform the public on matters of public interest. In our reading a reply to the one person who wrote to you is not published, there is no public being informed, and an account question is not a matter of public interest. It fails the first of those before the others are reached.

We put the publication point first deliberately, because it does not depend on who reviewed the message — which makes it the argument to reason from.

Where human review fits, and it is less than it looks. The second limb carries a narrow carve-out for content that has been through human review or editorial control and for which a person or company holds editorial responsibility for the publication. Both halves are required, and “someone read the draft and clicked approve” is not the same thing as holding editorial responsibility for a publication. More to the point, that carve-out sits inside a limb an ordinary reply never reaches — so for day-to-day correspondence it is doing no work at all. We spell this out so that nobody mistakes it for a general rule that human review answers AI-disclosure questions. It does not.

This reasoning is about OUR typical fact pattern — one person, one reply, prompted by something that person wrote to you. If your use differs, it may not transfer: generated text from your workspace posted somewhere more than one person reads, or sent to a large list at once, is a different question, and it is yours to assess on your own facts. Nothing here is legal advice to you, and it is not a substitute for your own assessment.

What is still open, named so you can see the shape of it. Whether we are the provider of the drafting system in the Act’s sense — we think we are, which is why we mark unconditionally — and what would change the reading above, are questions we have reasoned about internally and not yet had ratified by outside counsel. Article 50(1), which is about telling a person they are dealing with an AI system, is the other one; see §5. When these are settled, this document will say so. We would rather tell you which parts are open than imply a completeness we have not earned.

5. Automated sending does not rescue itself on human review

If you enable automated sending, messages go out without a person reading them. So the human-review carve-out described above is unavailable for them, and you should not assume any exemption resting on human review covers them.

What does not change is the argument that was doing the work. Automated sending removes a person from the loop; it does not turn a private reply into text published to inform the public. In our reading an autosent transactional reply sits outside Article 50(4) for exactly the same reason a human-approved one does. We say so because the reverse — treating human review as the thing holding the line — would be a weaker position than the one we actually have, and would mislead you about where the line is.

Article 50(1) is genuinely open for automated sending, and we are not going to pretend otherwise. That provision is about a person being informed they are interacting with an AI system. Where a person at your organization reads and approves each reply, we think the correspondent is dealing with that person. Where nothing is read before it goes, that argument is not available, and whether Article 50(1) reaches asynchronous email at all is not something we are willing to assert either way. It is on the list in §4, and it is a reason to think carefully before enabling automated sending for correspondents in the EU.

Where it would genuinely change, and this is the case to watch. The second limb has two parts, not one: text must be published, and that publication must be to inform the public on matters of public interest. Ordinary correspondence fails the first part. A feature that published generated text more broadly — an automatically published help article, a status page, a public reply in a community, or a broadcast send to a large list — would put us past the first part, but not automatically past the second: whether a particular published text informs the public on a matter of public interest depends on what it says and why, and we are not going to pre-answer that for content that does not exist yet. We ship no such feature today. If we build one, it gets its own assessment before launch, because the answer depends on that feature rather than on this one.

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.