An AI chatbot is software that reads what a person typed or said, works out what they meant, and writes a reply in ordinary language rather than picking one a human wrote in advance. That is the whole definition. The harder question, and the one this piece answers, is not what an AI chatbot is but where yours came from.
Our position: in 2026 almost nobody decides to deploy their first AI chatbot. It arrives. It ships switched on inside a licence you renewed, it gets bought by one team for one channel, it gets built by two engineers in a fortnight, it gets borrowed by an employee with a personal account, or a partner runs one that speaks in your name. By the time anyone asks "should we have a chatbot", the answer is that you already have several, and not one of them has a named owner. On Microsoft's own Q&A forum in November 2025, an administrator called Nidhi Priya wrote that she could not find Copilot listed anywhere in her tenant's licence inventory and asked, plainly, "from where we are using the free version of Copilot". She was not confused about the technology. She was trying to locate a chatbot her company was already running.
The short answer: An AI chatbot generates its reply instead of retrieving it, which is why the useful first move is not choosing one but writing down the five arrival routes and six facts for every chatbot already answering in your name.
Last updated: July 30, 2026.
The five ways an AI chatbot enters a company, and the six facts a register has to hold for each one.
One disclosure before the argument starts. We have not run a controlled trial of the register described here inside a customer's estate, and we are not going to pretend otherwise. Every vendor fact below was fetched from the vendor's own live documentation or pricing page on 30 July 2026 and is quoted with its source. Everything else is reasoning you can check.
What an AI chatbot is, and why the definition is not your problem
An AI chatbot is a program that holds a conversation by generating each reply at the moment it answers, using a language model, rather than selecting a reply from a finite set a person wrote earlier. That single property, generation instead of retrieval, is what separates it from the decision-tree bots that dominated 2016 to 2022. It is also the property that creates every governance question in this article, because a sentence nobody wrote in advance is a sentence nobody reviewed in advance.
Most explainers stop here and move on to benefits. That is a mistake, because the definition is doing more work than it looks. Three things follow from it directly.
First, the answer set is open. A rule-based bot can only say what is in its script, so its worst possible output is knowable in advance. An AI chatbot's worst possible output is not. We worked through what that means for liability in our earlier analysis of chatbots versus conversational AI, and the short version is that an open answer set moves the review problem from before deployment to after it.
Second, the quality of the answer depends far more on what the chatbot can read than on which model it runs. A very good model reading the wrong document gives a confident wrong answer. A mediocre model reading the right document usually gives a usable one.
Third, and least discussed, an AI chatbot produces a permanent artefact by default. Every exchange is a record. Microsoft's documentation states that for Copilot Chat, "both the prompt and response are logged and stored in Exchange for auditing/eDiscovery", per the Copilot Chat privacy documentation. That is a feature, and it is also a discovery surface that did not exist in your business two years ago.
None of these three consequences depends on which chatbot you bought. They apply to every AI chatbot in your estate, including the ones you did not buy.
They also apply regardless of what the thing is being used for. The standard list of AI chatbot use cases runs to nine or ten items in most explainers: customer support, lead qualification, internal helpdesk, onboarding, email triage, document lookup, appointment booking, and so on. That list is fine and it is not where the risk lives. Two chatbots doing identical customer-support work can differ enormously in blast radius depending on which documents they can reach and whose account they read them under. So we are going to spend the rest of this piece on provenance and permissions rather than on a wider catalogue of AI chatbot use cases, which you can get anywhere.
The five arrival routes: bundled, bought, built, borrowed, brokered
An AI chatbot enters a company along one of five routes, and the route predicts almost everything that will later go wrong with it. Naming the route takes about a minute per bot and is the cheapest diagnostic in this article. We call them the five arrival routes, and they are alliterative on purpose so that the framework survives being repeated in a meeting without the slide.
| Route | How it arrived | Who chose it | Typical first sign |
|---|---|---|---|
| Bundled | Included in a licence you already pay for, usually default on | Your vendor | Users mention a feature nobody announced |
| Bought | A team purchased a chatbot product for one channel | A department head | An invoice line with a per-resolution unit |
| Built | Engineers connected a model to a document store | An internal team | A Slack channel with a bot in it |
| Borrowed | An employee uses a personal chatbot account for work | The employee | Pasted output with a distinctive house style |
| Brokered | An agency, BPO or reseller runs a bot that speaks as you | A supplier | A widget on your site you cannot log into |
Bundled is the route that grew fastest and gets discussed least. Microsoft's own management guide states that Copilot Chat "is available at no extra cost" for a long list of licences including Microsoft 365 Business Basic, Business Standard, Business Premium, E3, E5, F1, F3, and Office 365 E1 through E5, and that it "is pinned by default for most users who are eligible", per Microsoft's Copilot Chat management documentation. Google's Workspace price list, fetched the same day, shows a "Gemini AI assistant in Gmail" and "Chat with AI in the Gemini app" inside Business Starter, its cheapest paid tier, listed at $7.00 per user per month before promotional discounting, according to Google Workspace pricing. Zendesk's pricing FAQ says its AI agents "are included in every Suite and Support plan", per Zendesk pricing. Three widely deployed business platforms now include an AI chatbot in the tiers most of their customers already buy. No procurement process was involved, because there was nothing to procure.
Bought is the route most people picture when they hear the phrase AI chatbot. One team, usually support or marketing, buys a product for one channel. It has an owner, a contract and a bill, which makes it the easiest route to govern and the one that needs the least attention.
Built is the route with the widest variance. A capable pair of engineers can wire a model to a document store in a fortnight, and the result is often better than anything you can buy, because it reads your actual content. It is also the route where the corpus boundary is set by whoever wrote the retrieval query, which is a governance decision made in a code review by someone who did not know they were making it. We wrote about that failure mode in detail in our analysis of retrieval governance.
Borrowed is the shadow route. An employee opens a consumer chatbot in a browser tab and pastes in work. There is no invoice, no admin console and no log. It is the same phenomenon we covered in our piece on shadow AI, and the reason it belongs in a chatbot register rather than a separate security spreadsheet is that from the customer's point of view there is no difference between a sanctioned bot and a borrowed one. The output arrives on your letterhead either way.
Brokered is the route almost every register misses. A marketing agency installs a chat widget. A BPO answers your tier-one queue with its own AI agent. A reseller embeds a bot in a portal your customers reach through your domain. The bot speaks as you, the transcripts live somewhere you have never seen, and the contract that governs it was signed before anyone imagined it would contain a language model.
Routes are not equally risky, and they do not fail in the same way. Bundled chatbots fail on scope and disclosure. Built chatbots fail on corpus. Borrowed chatbots fail on data egress. Brokered chatbots fail on liability. Bought chatbots, the ones with a real owner and a real contract, mostly fail on cost. Sorting your estate by route sorts your remediation list at the same time.
How an AI chatbot works, in the detail a register needs
An AI chatbot works in four moves: it captures the message, converts it to a numerical representation the model can process, optionally retrieves supporting material from a document store, and then generates a reply token by token, conditioned on the conversation so far. That is enough mechanism for a governance decision, and more mechanism than most people asking "how do AI chatbots work" are given.
Retrieval is the part worth dwelling on. It is where the chatbot touches your business. When a bundled chatbot answers from the public web only, its blast radius is embarrassment. When it answers from your document store, its blast radius is whatever that store contains. Microsoft draws exactly this line in its own product: Copilot Chat "is not grounded in organizational content like files, emails, or chats as part of the chat experience", but the same page then lists four ways a user can feed organisational content in anyway, including pasting it, uploading a file, and using Copilot Chat inside Outlook where it can reach "emails, calendar, meetings, chats, and limited file content". The default boundary and the reachable boundary are different things, and only one of them is in the marketing copy.
Next, what leaves the building. The same Microsoft page states that when web grounding is on, the chatbot generates a short search query and sends it to Bing, that Microsoft "acts as an independent data controller" for those queries, and that "web search queries sent from Copilot Chat to Bing are not EUDB-compliant". Read that carefully. Inside one product, under one licence, prompts sit inside a service boundary with contractual protections while a derived fragment of the same prompt leaves under a different legal relationship. No amount of reading the chatbot's marketing page would tell you that. It took reading the documentation.
For a stage-by-stage walkthrough of what happens between a customer's sentence and the answer, including the record step most explainers omit, see our six-stage trace of a single conversational turn. The register only needs the four moves above.
What an AI chatbot is not
An AI chatbot is not an agent, it is not a search engine, it is not a knowledge base, and it is not a compliance control. Confusing it with any of these produces a specific, predictable mistake, so it is worth being precise about each.
It is not an agent. An agent changes something outside the conversation: it issues the refund, updates the record, sends the email. A chatbot answers inside the conversation. The moment a chatbot gets write access it stops being a chatbot in every way that matters for risk, which is the argument we make at length in our piece on where write access draws the line. Vendors blur this deliberately because "agent" prices higher. Your register should not.
It is not a search engine. A search engine returns documents and leaves judgement to the reader. An AI chatbot returns judgement and hides the documents, or shows them as citations the reader rarely opens. When the retrieved material is thin, a search engine returns few results and an AI chatbot returns a confident paragraph. The failure is silent in one case and obvious in the other.
It is not a knowledge base. It reads one. If the underlying content is stale, contradictory or wrong, the chatbot will state the stale, contradictory, wrong thing fluently. Deploying a chatbot over a neglected corpus does not fix the corpus; it publishes it.
It is not a compliance control. This one causes real damage. A chatbot that says "I cannot help with that" is not a policy boundary, because the instruction telling it to say that lives in the same channel as the user's input. Prompt injection sits at number one on the OWASP Top 10 for LLM Applications, with sensitive information disclosure at number two. A refusal written in the system prompt is a preference. A refusal enforced at the connection is a control.
The Bot Register: six fields, one sitting
The Bot Register is a single table with one row per AI chatbot and six columns, and the point of it is that every column is a question with a factual answer rather than an opinion. If a column cannot be filled in, that gap is the finding. A first pass across a mid-sized company takes an afternoon.
| Field | The question it answers | What "filled in" looks like |
|---|---|---|
| Route | How did this chatbot arrive? | One of: bundled, bought, built, borrowed, brokered |
| Owner | Which named human is accountable, and what identity does it run as? | A person plus a service account or app registration, not a team name |
| Corpus | What can it read, at its widest reachable boundary? | Named systems and scopes, not "our knowledge base" |
| Reach | Can it read, say, or do? | Read-only, speaks on our behalf, or takes actions |
| Transcript | Where do conversations go, for how long, and who is the controller? | A system, a retention period, and a legal role |
| Disclosure | Does it tell people it is AI, and who bears that duty? | Yes or no, plus provider or deployer |
A few notes on filling it in, because the columns are less obvious than they look.
Route is the only column you can complete from memory, and it should be filled first, because it tells you which of the other five columns will be hard. Bundled chatbots make Owner hard. Built chatbots make Corpus hard. Brokered chatbots make Transcript hard.
Owner has two halves and both are required. The named human is the person who answers when the chatbot says something wrong. The identity is what the chatbot authenticates as when it reads your systems, and it is the half almost everyone omits. A chatbot with no distinct identity is running as somebody's account, which means its access is that person's access, and it keeps that access after they change roles. We have argued that non-human identities need an owner, a scope and an expiry date exactly like human ones, and the argument is set out in our piece on non-human identity.
Corpus must record the widest reachable boundary, not the intended one. The Microsoft example above is the model: the default is web-only, the reachable set includes anything a user can paste or open in Outlook. Write down the reachable set. That is the one that will show up in an incident.
Reach is a three-value field on purpose. Read means it can see data. Say means its words commit you. Do means it changes state in a system. Most chatbots sit at Say and are governed as though they sit at Read, which is the single most common category error we see discussed in this space.
Transcript needs three facts, not one. Where the conversation is stored, how long it is kept, and whether the vendor is acting as processor or controller for each hop. Those three facts are rarely on the same page of a vendor's site, and sometimes not on the site at all. When you cannot find them, that is a procurement question, not a research failure.
Disclosure is a yes/no plus a role, and the role matters more than people expect. It is treated in its own section below.
Two practical points, because a framework that falls over on first contact is not worth the afternoon.
Which row to fix first. Sort by Reach, then by audience. Any chatbot at Say or Do that talks to customers goes to the top, regardless of route. Below that, anything at Say pointed at employees. Anything at Read over a public corpus goes to the bottom and usually stays there. This ordering matters because most estates produce a register with twelve rows and capacity for two projects, and the instinct is to start with the row that felt most alarming rather than the one with the widest blast radius.
When a supplier will not answer. For brokered chatbots you will often ask where transcripts live and get nothing useful back. Do not leave the cell blank and move on. Write "requested, no answer, [date]" in it. That converts a technical unknown into a commercial fact with a timestamp, which is the form it needs to be in when it reaches a contract renewal or a due-diligence questionnaire. A dated non-answer is evidence; an empty cell is not.
A worked register entry: the chatbot inside Microsoft 365
Here is one row, filled in end to end, for a chatbot that a very large number of companies are running right now without having chosen it. Every fact comes from Microsoft's own live documentation, fetched 30 July 2026. Nothing here is inferred.
| Field | Entry for Microsoft 365 Copilot Chat |
|---|---|
| Route | Bundled. Included at no extra cost with M365 Business Basic/Standard/Premium, E3, E5, F1, F3, Office 365 E1 to E5, Teams and others |
| Owner | Unassigned by default. Appears as an entitlement, not a licence line, so it has no obvious budget holder |
| Corpus | Public web via Bing by default. Reachable set adds pasted text, uploaded files, ContextIQ file selection, open documents in Word/Excel/PowerPoint agents, and in Outlook: email, calendar, meetings, chats, OneDrive and frequently visited SharePoint files |
| Reach | Say. It writes and it can generate Word, Excel and PowerPoint files, but it does not act in third-party systems without an added agent |
| Transcript | Prompts and responses logged and stored in Exchange for auditing and eDiscovery, inside the tenant, under existing retention policy. Derived Bing search queries leave under a separate relationship where Microsoft is an independent data controller, and are not EU Data Boundary compliant |
| Disclosure | Provider-side. Microsoft designs the interface; the deployer inherits the surface rather than the duty for Article 50(1) |
Two entries in that table deserve a second look.
The Owner row is empty for structural reasons, not because anyone was careless. When Nidhi Priya went looking in the admin centre, the reason she found nothing is that Copilot Chat is an entitlement attached to licences rather than a product with its own SKU. There is no line item, so there is no cost centre, so there is no owner. The register catches this in one pass, which is the entire justification for having one.
The Transcript row contains two different legal relationships inside one product. Prompts and responses stay inside the Microsoft 365 service boundary under the Data Protection Addendum with Microsoft as processor. Derived web queries go to Bing where, in Microsoft's words, Microsoft "acts as an independent data controller". If your data map says "Microsoft 365, processor", it is incomplete, and it was incomplete before you had an opinion about AI.
There is a third fact that belongs in the notes column rather than a field: you cannot fully switch this one off with a single toggle. Microsoft's guidance states that the pinning setting "no longer governs the Microsoft 365 Copilot app" for tenants outside the EEA and Switzerland as of 28 January 2026, that Copilot Chat "can't be unpinned from the navigation for all tenants worldwide", and that even when unpinned, "users can still access it from https://m365.cloud.microsoft/chat". Removing access requires a combination of Integrated Apps controls, Teams app policies and Edge group policy, and the same page adds that Microsoft "doesn't recommend and cannot support" network-level blocking. In March 2026 a user on the same Q&A forum, posting as tm, described spending "many hours" trying to disable it and was told by Microsoft staff that the behaviour is by design (question 5812873).
That is the practical meaning of the bundled route. The decision available to you is not whether to have this AI chatbot. It is how to govern one you already have.
What each arrival route costs, at July 2026 list prices
The price of an AI chatbot is easy to find and almost never the number that matters, because four of the five arrival routes hide the cost somewhere other than the chatbot's own line item. All figures below were fetched from vendors' own pricing pages on 30 July 2026 and are list prices in US dollars.
| Vendor | Unit | List price | Route it usually represents |
|---|---|---|---|
| Microsoft 365 Copilot Chat | Included with qualifying licences | No extra cost | Bundled |
| Google Workspace Business Starter | Per user per month, Gemini assistant included | $7.00 list | Bundled |
| Zendesk AI agents | Per automated resolution, included in every Suite and Support plan | Usage-based | Bundled |
| Intercom Fin | Per resolved outcome | From $0.99 | Bought |
| Salesforce Agentforce | Per conversation | $2.00 | Bought |
| Salesforce Agentforce Flex Credits | Per 100,000 credits | $500 | Bought |
| Salesforce Foundations | Entry tier | $0 | Bundled |
Sources, in order: Microsoft Copilot Chat management guide, Google Workspace pricing, Zendesk pricing, Intercom pricing, and Salesforce Agentforce pricing.
Two structural observations about that table.
Those billing units are not comparable. Intercom bills per resolved outcome, Salesforce bills per conversation, Zendesk bills per automated resolution, and Microsoft and Google bill per seat regardless of whether the chatbot is used at all. A conversation that ends in escalation costs $2.00 at Salesforce's list price and nothing at Intercom's, because Intercom charges for outcomes. Any spreadsheet comparing these numbers side by side without normalising the unit is producing fiction. This is a genuine buyer trap and it is not an accident of presentation.
Caveats sit on the pricing pages themselves. Salesforce's page states in plain text that it "is provided for information purposes only and is subject to change", and offers three separate buying models: pre-purchase, pre-commit and pay-as-you-go. Intercom shows "from $0.99 per Fin outcome" with a leading "from", which is a floor and not a price. Treat every figure above as a starting point for a negotiation rather than a quote.
One cost appears in none of these tables: the routes with no invoice. A borrowed chatbot costs nothing and can cost everything. A brokered chatbot appears inside an agency retainer as a line called "support". A built chatbot appears as engineering time that was already being spent. Three of the five routes are invisible to finance by construction, which is why an inventory built from the accounts payable ledger will always undercount your chatbot estate.
The bundled AI chatbot is a pricing model, not a gift
When a vendor includes an AI chatbot at no extra cost, that is a distribution strategy with a predictable second act, and planning for the second act is cheaper than reacting to it. This is not cynicism. It is the observable pattern across the market in 2026.
Zylo's 2026 SaaS Management Index, which measures actual application spend across its customer base, reports that the average company now manages 305 SaaS applications, that artificial intelligence was the fastest-growing application category in 2025 with a 181% expansion in the number of apps within portfolios, and that organisations spend an average of $1.2M on AI-native applications, per Zylo's published statistics. Set that against the free-tier facts above and the strategy is legible: seed usage at zero, then price the tier where the value concentrates.
Expect three moves, in order:
- Free tier, narrow corpus. The bundled chatbot answers from the public web, or from a thin slice of your data. It is genuinely useful and genuinely limited. Microsoft's Copilot Chat is precisely this: web-grounded, with organisational content reachable only through four specific user actions.
- Paid tier, wide corpus. The upgrade is not a better model. It is permission to read your own data. Microsoft's own documentation makes this explicit: access to full work data through semantic indexing "is only available for users with the Microsoft 365 Copilot license". You are paying for retrieval scope.
- Usage-based tier, at the point of action. Once the chatbot can do things rather than say things, the unit changes to conversations, resolutions or credits, and the bill becomes a function of volume rather than headcount.
Now the governance consequence, which is the interesting part. Every step in that ladder widens the corpus or the reach, which means every commercial upgrade is also a scope change. In most companies the upgrade is a renewal conversation handled by procurement and the scope change is never reviewed by anyone. If your register records Corpus and Reach as fields, an upgrade automatically becomes a register edit, and a register edit is reviewable. That is the whole mechanism, and it costs nothing to install.
There is also a version of the free tier that is not a ladder at all. Salesforce's pricing page lists Salesforce Foundations at $0 with Agentforce Builder and Agentforce Coworker included. That is a genuine free entry point. It is also five minutes of clicking away from a bot in production with a $2.00-per-conversation meter running, which is a different kind of hazard: not a hidden cost, an unsupervised one.
Disclosure: who is on the hook after 2 August 2026
From 2 August 2026, Article 50 of the EU AI Act requires that people be told when they are interacting with an AI system, and the duty falls on the provider who designs the system rather than the company deploying it. That distinction decides who has work to do, and most readers guess it the wrong way round.
The European Commission's own FAQ states that "providers of AI systems that directly interact with people must design and develop those systems in such a way that the individuals concerned are informed", that the disclosure must be made "in a clear and distinguishable manner and in accordance with accessibility requirements", and that no notification is required where "it is obvious they are interacting with an AI system", an exemption to be read narrowly, according to the European Commission's transparency FAQ. The obligation bites where four conditions hold together: the thing qualifies as an AI system, it enables a genuine two-way exchange, it communicates directly rather than through an intermediary, and it interacts with natural persons.
Map that onto the five arrival routes and the picture sorts itself out quickly.
| Route | Who designs the interface | Practical disclosure position |
|---|---|---|
| Bundled | The vendor | Provider duty sits with the vendor; you inherit their wording and should check it says what you would say |
| Bought | The vendor | Same, but you usually control the greeting text, so you can make it worse |
| Built | You | You are the provider. The duty is yours, in full |
| Borrowed | Nobody in your organisation | No interface exists to disclose on; the risk is elsewhere |
| Brokered | Your supplier | Contractually murky. The customer sees your brand |
Built is the route that catches people out. A chatbot written in-house by two engineers makes your company the provider of an AI system that interacts directly with natural persons, and the disclosure obligation attaches to the thing they built, not to a vendor. That is not an onerous requirement, and satisfying it takes a sentence in the interface. It is only a problem if nobody knows the obligation exists, which is exactly the state a Built chatbot with no register entry is in.
Brokered catches people out for the opposite reason. The supplier is the provider, the customer sees your logo, and the contract signed three years ago says nothing about AI. We set out the wider deployer obligations, including the ones that arrive later, in our guide to EU AI Act compliance for deployers.
A fair objection at this point: if the duty sits with the provider on four routes out of five, why is any of this your problem? Because the duty and the exposure are different things. The regulator may pursue Microsoft over an interface Microsoft designed, and your customer will still come to you about the sentence your chatbot said in your brand voice, your contract with the agency will still be silent on it, and your auditor will still ask you to demonstrate that you knew which of your customer-facing surfaces were AI. The register answers that last question in one screen. That is what an afternoon buys: not compliance, which is a longer piece of work, but the ability to answer "which of these is AI, who owns it, and what can it see" without opening an investigation.
One honest caveat. The provider/deployer split is cleaner in the regulation than it will be in practice, because a company that heavily customises a bought chatbot may find itself treated as a provider. Where the customisation is substantial, get advice rather than relying on the table above. We are describing the structure of the obligation, not giving legal advice on your specific deployment.
The corpus is the real decision, not the model
Which model an AI chatbot runs on is the most discussed and least consequential choice in a deployment. What the chatbot is allowed to read decides answer quality, decides the size of a leak, and decides whether the thing is useful at all. Model choice mostly decides latency and unit cost.
The mechanism is simple. A language model with no retrieval answers from its training data, which does not contain your refund policy. Give it retrieval over your policy documents and it answers correctly. Give it retrieval over your entire intranet and it answers correctly most of the time, and occasionally answers a junior contractor's question using a document about redundancies. Nothing about the model changed between those last two sentences. The corpus changed.
This is where permission inheritance bites. Human permission systems were designed on the assumption that finding a document requires knowing it exists. Retrieval removes that assumption: the chatbot searches everything it can reach, every time, and surfaces the most relevant match. A folder that was safe because it was obscure is no longer safe. Sensitive information disclosure ranks second on the OWASP Top 10 for LLM Applications, immediately below prompt injection, and permission-blind retrieval is the most common way an ordinary deployment produces it.
Three corpus questions worth asking before any AI chatbot goes live, in this order:
- Whose permissions does retrieval run under? If the answer is "a service account with broad read access", every user of the chatbot effectively has that access through the conversation. If the answer is "the asking user's own permissions", you have the right architecture and a slower system.
- What is in scope that nobody has read in two years? Stale content is the most reliable source of confidently wrong answers, because nothing in the pipeline knows the document is obsolete. A last-reviewed date in the metadata, used as a retrieval filter, removes a whole class of failure for very little work.
- What would this corpus produce in the worst plausible question? Not the worst imaginable one. The worst plausible one, asked by an ordinary employee with an ordinary motive. If the honest answer makes you uncomfortable, the corpus is too wide, and no model swap will fix it.
Stanford's 2026 AI Index reports that documented AI incidents rose to 362, up from 233 in 2024, per the 2026 AI Index Report. The same report puts organisational AI adoption at 88%. Incidents are growing alongside adoption rather than instead of it, which is what you would expect if the binding constraint were deployment discipline rather than model capability.
Five failure modes, each traced to an arrival route
Chatbot failures look varied from the outside and are quite repetitive from the inside. Each of the five below traces back to a specific arrival route and to a specific empty column in the register, which is a useful property: it means the register predicts the failure rather than merely recording it afterwards.
1. The chatbot invents a policy. In April 2025 Cursor's front-line support bot told users that logins were restricted to a single machine. No such policy existed. Users cancelled subscriptions and the story reached the front page of Hacker News with 1,511 points. A Cursor developer's correction, quoted on that thread, called it "an incorrect response from a front-line AI support bot". Route: Bought. Empty column: Reach, recorded as Read when the true value was Say.
2. Nobody can turn it off. The bundled chatbot is switched on for every seat, the toggle that used to hide it no longer applies, and the documented removal procedure spans four different admin surfaces. Route: Bundled. Empty column: Owner. When no one owns it, no one has done the four-surface work, and the default stands.
3. The answer is right and the source is confidential. Retrieval runs under a broad service account, an employee asks a reasonable question, and the reply quotes a document they should not have seen. Route: Built. Empty column: Corpus, recorded as the intended boundary rather than the reachable one.
4. The transcript is somewhere you did not expect. A customer exercises a data subject access request. The conversation is in your helpdesk, and a derived fragment of it is with a search provider under a different legal relationship, and the agency's version of the widget kept its own copy. Route: Brokered, usually compounded by Bundled. Empty column: Transcript.
5. Nobody disclosed anything. The in-house bot greets customers in a friendly first person and never says it is software. This was survivable in 2024. From 2 August 2026 it is a regulatory finding in the EU. Route: Built. Empty column: Disclosure.
That pattern is worth stating plainly, because it is the argument for doing the register at all. In every one of these five, the failure was not caused by the model being weak. It was caused by a fact about the deployment that nobody had written down. Writing it down is not sufficient to prevent the failure. It is, reliably, the step that was missing.
When leaving the AI chatbot exactly as it is beats governing it
Sometimes the right answer is to record the chatbot in the register, mark it low-risk, and do nothing else. Governance effort spent on a bot that cannot hurt you is effort not spent on one that can, and a register that triggers a project for every row will be abandoned within a quarter.
Leave it alone when all four of these hold:
- Reach is Read and the corpus is public. A bundled chatbot answering from the open web, used by employees to draft text, has a blast radius of embarrassment. It is worth an acceptable-use line in a policy and nothing more.
- The volume is genuinely small. A widget handling forty conversations a month does not justify a governance workstream. Revisit it when the number changes, and set the threshold now so the revisit actually happens.
- The vendor's defaults are stricter than the ones you would write. Microsoft's enterprise data protection commitments for Copilot Chat, to take the documented example above, are tighter than what many mid-sized companies would have specified for themselves. Improving on a default that already exceeds your own standard is possible, and it is rarely the best use of the next two weeks.
- The alternative is a shadow deployment. Removing a sanctioned chatbot that people rely on converts a governed use into a borrowed one. The work moves to a personal account where you have no logs at all. This is the trade-off that banning tends to lose.
There is a broader version of this point. The most common failure of AI governance programmes is not permissiveness. It is scope: an inventory becomes a control framework becomes a review board, and eighteen months later the review board is the reason three business units are using consumer chatbots in secret. The register is deliberately six columns and one afternoon. Keep it that size.
Where this analysis is uncertain
Several things in this piece are less settled than the confident register table implies, and it is worth being specific about which.
We have not tested the register in the field. The framework is derived from vendor documentation, published incidents and the failure patterns we see discussed publicly. We have not run it as a controlled exercise across a customer estate and measured how long it takes or what it catches. Treat the "one afternoon" estimate as an argued position rather than a measured one.
The five routes are a classification, not a taxonomy with hard edges. A chatbot built in-house on a vendor's platform is partly Built and partly Bundled. An agency-run bot on software you licensed is Brokered and Bought at once. The routes are useful because they predict which column will be empty, and a bot that straddles two routes usually has both columns empty. That is a feature of the frame, not a contradiction of it.
Vendor facts move quickly. Every price and capability statement here was fetched on 30 July 2026 and several of the underlying pages carry explicit change notices. Microsoft's pinning behaviour changed twice in eighteen months, on different dates for EEA and non-EEA tenants. Anything in this article that a vendor controls should be re-checked before it is used in a decision.
The Article 50 provider/deployer split is untested in practice. The regulation is clear and enforcement history is nil, because the obligation only starts to apply on 2 August 2026. How regulators treat a heavily customised bought chatbot is not yet known.
We could not verify some sources a reader would expect. Reddit is not reachable from our research environment, so community discussion that would ordinarily inform the failure-mode section is under-represented, and the practitioner voices here come from Hacker News and Microsoft's Q&A forum. The YouTube Data API returned a quota error on the day of writing, so this article carries no video. Both are absences, and we would rather name them than let them read as editorial choices.
The layer a chatbot fleet implies
Once you have filled in a Bot Register you will notice that five of the six columns are not chatbot questions at all. Owner, corpus, reach, transcript and disclosure are questions about identity, access, logging and policy, and they have the same shape whether the thing asking is a chatbot, an assistant, a workflow or an agent. That is the layer LeapForce builds: one controlled place where every AI surface identifies itself, gets checked against policy, and leaves a record, so that the register stops being a spreadsheet somebody maintains by hand and becomes a query against a system. Our gateway rollout model is deliberately sequenced for this, and its name is the whole method: observe first, enforce second, optimize third, starting with visibility on one team's traffic before any rule is written. To be straight about the boundary: LeapForce does not sell a customer-service chatbot and will not replace Intercom, Zendesk or Copilot Chat, and per our published build status, automatic discovery of unmanaged AI use and packaged compliance evidence are roadmap items rather than shipping capabilities today.
Frequently asked questions
An AI chatbot is software that holds a conversation by generating each reply at the moment it answers, using a language model, instead of selecting from a fixed set of replies a human wrote in advance. That one property, generation rather than retrieval of pre-written text, produces both its usefulness and every governance question attached to it, because the answer set is open and cannot be fully reviewed before deployment.
An AI chatbot captures the message, converts it into a numerical representation, optionally retrieves supporting documents from a connected store, and then generates a reply conditioned on the conversation so far. The retrieval step is the one that matters commercially: it decides whether the chatbot answers from the public web or from your systems. Microsoft's Copilot Chat, for example, is grounded in web data by default and reaches organisational content only through specific user actions such as uploading a file or using it inside Outlook.
A rule-based chatbot matches input against patterns a person wrote and returns a scripted reply, so its worst possible output is knowable before launch. An AI chatbot writes the sentence itself, so its worst possible output is not knowable in advance. Practically, the rule-based bot fails visibly when a question falls outside its script, while the AI chatbot fails invisibly by answering confidently and wrongly. That difference decides how you test each one: scripts get coverage testing, generated answers get monitoring.
More than it thinks, and the count is rarely on any inventory. Zylo's 2026 SaaS Management Index puts the average company at 305 SaaS applications, with artificial intelligence the fastest-growing category in 2025 at 181% growth in apps within portfolios. Because Microsoft, Google and Zendesk all now include an AI chatbot by default in tiers most companies already buy, a mid-sized business typically has several bundled chatbots plus whatever individual teams bought or built. Counting them is the point of the register.
At July 2026 list prices, the bought route runs from $0.99 per resolved outcome at Intercom to $2.00 per conversation at Salesforce Agentforce, with Salesforce also selling Flex Credits at $500 per 100,000. The bundled route appears to cost nothing because it is inside a seat licence such as Google Workspace Business Starter at $7 per user per month. Those units are not comparable: outcome-based pricing charges only for successful resolutions, conversation-based pricing charges for escalations too. Normalise the unit before comparing any two quotes.
Safety depends on the corpus and the transcript path, not on the vendor's security page. Ask two questions: whose permissions does retrieval run under, and where does the conversation go. Permission-blind retrieval is the common failure, and sensitive information disclosure ranks second on the OWASP Top 10 for LLM Applications, behind prompt injection. Also check every hop: Microsoft states that Copilot Chat prompts stay in the Microsoft 365 service boundary while derived Bing search queries leave under a separate relationship where Microsoft is an independent data controller.
Partially, and it takes more work than one toggle. For Microsoft 365 Copilot Chat, the documentation states that the pinning setting no longer governs the Microsoft 365 Copilot app for tenants worldwide as of 28 January 2026, that users can still reach it directly on the web after unpinning, and that full removal requires Integrated Apps controls, Teams app policies and Edge group policy together. Microsoft also states it does not recommend and cannot support network-level blocking. Plan for governing it rather than removing it.
In the EU, from 2 August 2026, Article 50 of the AI Act requires that people be informed they are interacting with an AI system, unless that is obvious, an exemption the European Commission says should be read narrowly. The duty sits with the provider that designs the system. If you bought or inherited the chatbot, the vendor carries it and you should check their wording. If you built the chatbot in-house, you are the provider and the duty is yours in full, satisfied by one clear sentence in the interface.
It varies by vendor and by tier, so read the specific product's documentation rather than the company's general privacy page. Microsoft states plainly that Copilot Chat "prompts and responses aren't used to train the underlying foundation models" and that prompts and responses are logged in Exchange for auditing and eDiscovery. Other vendors default differently on lower tiers than on enterprise ones. This is a per-product, per-tier fact and belongs in the Transcript column of your register alongside the retention period.
The observable pattern is redistribution rather than replacement, and the mechanism is billing units. Zendesk bills per automated resolution and Intercom bills per resolved outcome, which means both vendors only earn when a human is not involved, and both still ship human escalation as a first-class path. What changes is the mix of work: routine questions get absorbed, and the human queue concentrates into exceptions, judgement calls and anything where a wrong answer commits the company. Those cases take longer and need more experienced people, not fewer.
A named person with budget authority over the channel it serves, paired with a distinct machine identity the chatbot authenticates as. Both halves are required. Without the named human, no one does the work when the chatbot says something wrong. Without the distinct identity, the chatbot runs under someone's personal account, inherits that person's access, and keeps it after they move roles. Ownership recorded as a team name rather than a person tends to behave like no owner at all, because there is nobody the question lands on.
We estimate an afternoon for a first pass in a mid-sized company, and we should be honest that this is an argued figure rather than one we have measured in the field. The Route column fills in from memory. Owner and Reach take a conversation each. Corpus and Transcript are the slow ones, because the facts sit in vendor documentation rather than in your own systems, and for brokered chatbots they may require asking a supplier. Empty cells are the output, not a failure of the exercise.
Ready to Govern Your AI?
Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.
Comments