Shadow AI in the telecom back office

It is the third working day of the month and the billing clerk is preparing the dunning run. The reminder letters should sound patient for long-standing customers and firmer for those who are late every quarter. She exports the list of overdue accounts, opens the chatbot on her personal account and pastes it in: names, postal addresses, open amounts, contract numbers. A few minutes later the letters are drafted and they read well. Nobody asked her to work this way, and nobody told her not to.

Two scenes from a normal week

The same afternoon a customer calls support about a tariff change. He says his old contract promised a free router swap when he upgraded. The colleague in support has the contract PDF and the order history open, and the customer is waiting. She copies the contract into her own chatbot and asks for the clauses on hardware and termination. The answer comes back in seconds, she reads the relevant clause to the customer, and the call ends well.

Both people did good work for the company. Both also moved customer data out of the company’s controls. The dunning list now sits in the chat history of a private account, under whatever retention terms that account has, processed in places the company never assessed, reachable by anyone who gets into that account. The contract, with the customer’s name, address and tariff, sits next to it. There is no record in any company system that either step happened, and when the clerk leaves next year, the history leaves with her.

This is shadow AI at a regional ISP or MVNO. Capable people solve everyday problems with the fastest tool at hand, before the company has decided anything about it.

How common it is

Netskope Threat Labs published its AI report in July 2026, based on usage data from a subset of its customers between June 2025 and July 2026. It found that 56% of AI users use only organisation-managed AI apps, 14% use both managed and personal apps, and 30% use only personal apps (Netskope, 2026). In 2023 nearly all the AI traffic Netskope saw in companies was personal use, and that share fell as companies rolled out managed tools. According to the report, that trend stopped around March 2026 and has since moved slightly the other way. Netskope’s own reading is that shadow AI is here to stay and that organisations have chosen to put guardrails around personal use.

Two points matter when you apply this to your own company. The figures come from companies that already route their traffic through a security platform and can see what their staff use. An operator that has never looked has no reason to assume its own picture is better. And the same report says intellectual property, regulated data and source code account for the vast majority of data policy violations. In a telecom back office, regulated data is the daily material: names and addresses, bank details, call records, identity documents from SIM registrations and port-ins.

What leaves the company

When customer data goes into a personal AI account, the company loses three things at once. It no longer knows where the data is. It no longer controls how long it is kept. And it cannot say who can access it, because access now depends on one employee’s password and whatever settings she chose.

What happens to the data inside the service depends on the vendor and on the tier. Anthropic, to take one example, states that by default it does not use inputs or outputs from its commercial products for training (Anthropic, 2026a), while on its consumer plans this depends on a “Model Improvement” privacy setting the user controls (Anthropic, 2026b). Other vendors draw the line in other places. The same brand name can therefore mean very different data handling, depending on which account someone signed up with.

For Swiss operators there is also the legal side. The Federal Data Protection and Information Commissioner (FDPIC) has stated that the Data Protection Act, in force since 1 September 2023, “is directly applicable to AI-supported data processing” (FDPIC, 2025). A dunning list in a private chat is processing of customer data, with the same duties as any other.

Decide what is allowed, then provide it

A programme for a regional operator has six parts: decide which AI offers and which data are allowed, give people accounts the company controls, check data processing per vendor and tier, train people on their real tasks, name a contact, and revoke access when people leave. None of it needs a large security team. It needs a few decisions, written down, and someone who keeps them current.

Start with the data, because that is what people actually ask about. Five classes cover most of a telecom back office:

• Public: tariff sheets, coverage maps, published terms.
• Internal: process descriptions, letter templates, network change plans without customer data.
• Customer data: names, addresses, contracts, tickets, call detail records.
• Payment and identity data: bank details, dunning status, ID documents from port-ins and SIM registration.
• Secrets: passwords, API keys, router and switch configurations.

Then list the AI offers you approve and, for each, which classes may go in. One page is enough. If the billing clerk can look up in ten seconds whether the dunning list may go into the approved tool, she will look.

Next, set up team or enterprise accounts, connected to the company’s sign-in, so that you can see who uses what and switch it off. Cover the tasks people already do with personal accounts. If the approved tool is harder to reach or less capable than the private one, the private one stays open in the next tab.

For each approved offer, get written answers to the same questions. Are inputs used for training by default? How long are conversations kept, and can an administrator set that? Where is data processed, and by which subprocessors? Is there a data processing agreement? Can an administrator export or delete a user’s history? The answers differ between consumer and business tiers of the same vendor, and they change, so put a date on them and check again when the vendor updates its terms.

Train, answer questions, close accounts

Train people on their real tasks. Take the dunning letters and the contract summary from the scenes above and show how to do exactly those with the approved tool: which fields stay out, how to check the result, where the draft gets saved. Ask billing, support and sales to bring their own examples. People remember the rule for the task they do every week.

Then name a contact: one person whom anyone can ask “may I paste this?” before they do it, and who collects requests for new tools. In a smaller operator this is usually the head of IT or the data protection lead. What matters is that the name is known and the answer comes the same day.

Finally, add AI to the offboarding checklist: company AI accounts closed on the last day, tokens for any agent the person ran revoked, shared histories reassigned. Personal accounts cannot be revoked at all, which is the strongest argument for providing good company accounts in the first place.

Paste less by connecting the systems

Both scenes have the same cause. The information the person needs sits in one system, the tool that helps sits in another, and the clipboard is the only bridge. Approved accounts make that bridge safer. Connecting the approved assistant to the system of record removes the need for it.

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems such as databases and tools (MCP, 2026a). Its authorization guidance recommends authorization whenever a server accesses user-specific data or when “you need to audit who performed which actions”, and it advises least-privilege scopes, split per tool or capability (MCP, 2026b). Applied to the support call, the colleague asks her approved assistant for the hardware clauses in the customer’s contract. The assistant fetches the contract from the system of record under her permissions, nothing is pasted anywhere, and the access is logged.

What METAVSHN does for this

METAVSHN is the system of record for customers, contracts, products, services and invoices at the operators that run on it. Through the METAVSHN CLI, and through MCP for agents that use it, a person and the agent their company approved can look up those records with defined commands. Every request is checked on the METAVSHN side against the identity, role and permissions of the person behind it. Permission hints in the CLI grant nothing on their own. Deleting something or sending something out needs explicit confirmation, and a dry run shows the request before it is sent. The audit log records which agent did what and when. Because the agent works with the person’s own access, removing that access when someone leaves also stops the agent.

The CLI works with any agent that can run commands, so you keep the AI offer you already approved. The agent may still pass returned data to its AI provider, which is why the vendor check described above still applies. The CLI is in early access.

If your billing or support team already copies customer data into chat windows, see how the METAVSHN CLI gives their approved agent the same records, with access checked on every request.

Sources

All sources accessed on 31 October 2026.

1. Netskope Threat Labs, “Netskope AI Report: 2026”, 27 July 2026. netskope.com
2. Anthropic Privacy Center, “Is my data used for model training?” (commercial products), updated 18 August 2026. privacy.claude.com
3. Anthropic Privacy Center, “Is my data used for model training?” (consumer products), updated 16 March 2026. privacy.claude.com
4. Federal Data Protection and Information Commissioner (FDPIC), “Update: Current data protection legislation is directly applicable to AI”, 8 May 2025. edoeb.admin.ch
5. Model Context Protocol, “What is the Model Context Protocol (MCP)?”, July 2026. modelcontextprotocol.io
6. Model Context Protocol, “Understanding Authorization in MCP”, protocol revision 2026-07-28. modelcontextprotocol.io