AI moderation for Telegram: test the mistakes before switching it on
Decide whether an AI spam layer fits your community, build a useful test set and evaluate false positives, missed spam and recovery. Includes Defendy’s actual boundaries.
An AI spam layer is worth evaluating when unwanted posts keep changing their wording and your word list is starting to block useful discussion. The decision should depend on which mistakes it makes and how your team will repair them. A removed support request and a missed advertisement have different costs.
Consider a hypothetical community marketplace. Members may sell used equipment, but unsolicited investment pitches are prohibited. Both can contain prices, contact requests and persuasive language. A model may recognize an advertisement without knowing whether that advertisement is allowed. Start by defining the decision you need, then check what information the tool receives.
If your question is whether to ask a model to assess one message, use the ChatGPT moderation guide to decide who owns the final decision and what information may be shared for review.
Match the tool to the problem
“Keep the community healthy” is a goal, not a testable classification rule. “Catch unsolicited promotional invitations while preserving approved listings” gives you something to evaluate.
| Problem | Start here | Human responsibility |
|---|---|---|
| A recurring unwanted destination | Link rules with narrow exceptions | Check legitimate uses of the same site |
| Promotional posts with changing wording | Evaluate text anti-spam, then its AI layer | Review wrongly removed contributions |
| Sarcasm, insults or an ongoing dispute | Behavior rules and moderator review | Read the exchange and choose a proportionate response |
| Moderators disagree about self-promotion | Clarify the community policy | Decide what the community permits |
If your moderators cannot agree on the expected answer, a model cannot settle the policy on your behalf. The guide to contextual toxicity judgments covers the separate problem of judging behavior.
Defendy has two different AI spam workflows
Automatic verification supplements text anti-spam. A local detector runs first. Eligible messages in an intermediate scoring range may receive an additional AI check when that option is enabled and the service is available. Eligibility also depends on message length, newcomer status and internal trust conditions. Not every incoming message is sent to the model.
The current automatic request contains the first 300 characters of the message and the group title. It does not include the preceding conversation or your complete group rules. If that AI request cannot return a usable result, the filter falls back to its local strictness decision. An outage therefore does not necessarily leave a message untouched.
In the Mini App, the controls are under Anti-spam → Text. The AI setting includes a newcomer window of 3, 7, 14 or 30 days; the newcomer-only condition is not editable in the current interface. Availability also depends on service configuration. AI functionality is described as beta, and source implementation is not proof of rollout to every group. See the text anti-spam guide.
The manual /spam command checks a selected message. When enabled, members can invoke it by replying to an eligible message; administrator messages are excluded. This path evaluates the selected text without conversation history. A spam verdict initiates deletion. A person requests the check, but there is no separate approval before that deletion.
The manual path has monthly limits determined by the active configuration. A person with permission to manage the bot can inspect /spamstatus; do not assume that its quota describes automatic verification too. No reply or deletion is not evidence of a successful clean result. Eligibility, limits and service failures can also prevent an outcome. The manual spam-check guide explains the prerequisites.
Build a test set that can disappoint you
Use invented or carefully de-identified examples representative of your community. Include both clear spam and legitimate posts that resemble it:
- offers from unrelated advertisers, phrased in several ways;
- ordinary questions containing words such as “buy,” “discount” or “earn”;
- approved listings and recommendations requested by another member;
- a warning about a scam that quotes part of the pitch;
- a long post whose final sentence changes its meaning;
- the languages, abbreviations and mixed-script text your members actually use.
Label the expected decision and the applicable rule before testing. Have another moderator review uncertain labels. Keep disagreements separate rather than changing the answer key to match the model.
Use a private test group and a consenting non-administrator test participant, with no valuable messages at stake. Record the settings, date, visible action and any available reason. Testing /spam does not establish how the automatic path would treat the same example: the triggers and inputs differ. Cached results can also make repeated identical checks look more consistent than independent evaluations really are.
Read both sides of the error count
A false positive is an allowed message flagged as spam. A false negative is unwanted content that passes. A single accuracy percentage hides the practical burden of both.
Here is a hypothetical calculation, not Defendy performance data. Suppose moderators label 100 examples: 20 unwanted and 80 allowed.
| Moderator label | Flagged as spam | Allowed through |
|---|---|---|
| 20 unwanted messages | 18 correct flags | 2 missed messages |
| 80 allowed messages | 4 false flags | 76 correct passes |
That is 94 correct decisions overall. Yet four of the 22 flagged messages are legitimate, so roughly one in five flags would need correction. Two of the 20 unwanted messages also got through. A small artificial set cannot establish production accuracy, but it can reveal the kind of damage hidden by an attractive headline number.
Keep “check did not complete” as a separate outcome. Do not count silence as a correct pass. Break errors down by category: listings, quotations, languages and newcomer situations. Compare configurations on the same examples, while acknowledging which path actually ran and what your logs can establish.
Decide how to stop and repair a bad rollout
Before using real member messages, name the moderator responsible for appeals and publish a contact route in the rules. If review depends on the moderation log, configure the destination and relevant categories, then verify that a test event arrives. Logging is not a complete transcript by default.
Separate the member action from message deletion. Selecting “nothing” as the text-filter punishment does not guarantee that the post remains: deletion has a separate backend setting that defaults on, and the current text-filter screen does not expose its own deletion switch. Warnings may accompany deletion and may accumulate toward another consequence. A private test group is the safer testing boundary.
If allowed messages are repeatedly affected, pause the responsible control and investigate. Turning off AI alone leaves local classification in place. Correct any mistaken restriction separately, explain the decision and ask the author to repost if necessary. Do not promise automatic restoration of deleted messages.
Also decide whether the data flow is acceptable. Checked text may be sent to the configured model provider. Use no secrets or personal documents in tests. If provider identity or retention is a prerequisite, obtain that information from the operator before proceeding; the current privacy policy identifies those details as awaiting confirmation.
NIST’s AI RMF 1.0, Appendix C discusses clearly assigned human responsibilities and the context lost when complex judgments are modeled. A useful community-level application is to name the person who can correct an automated decision before giving that decision consequences.
Sources and implementation reviewed on 5 October 2026. This article reports no live-chat accuracy test.
