The Honking Goose

When addressing the challenge of preventing misuse of artificial intelligence, it is crucial that safety solutions do not rely solely on AI itself. One common moderation method involves using another large language model, or LLM, to evaluate whether submitted text violates specific guidelines or contains concerning attributes. While this approach can be useful as a final check, AI platforms also need an intermediary layer between user inputs and model outputs. Without that safeguard, AI safety risks becoming dependent on the honor system, especially because large language models are skilled at reshaping language in ways that can obscure intent and avoid clear accountability.

Artificial intelligence platforms may be relatively new, but they are not the first internet technologies to require safeguards against malicious use. Many online platforms already use advanced identity verification systems to confirm user authenticity, along with machine learning tools designed to detect spam, toxicity, and violent content in real time. Importantly, these techniques do not require large language models. That matters because it shows that effective protection can often be achieved through practical, well-established systems rather than overly complicated ones. The goal should be to build safeguards that are robust, straightforward, and capable of supporting a safer and more trustworthy online environment.

Getting started can be challenging, but one strong first step is developing and implementing a text classifier that evaluates both user inputs and model outputs for dangerous content. Creating comprehensive lists of keywords and patterns takes time, but this is an area where large language models can meaningfully improve efficiency. The generated lists may not be perfect, but they can provide a useful starting point, which is far better than inaction.

Here is my attempt at developing a block list for a text classifier.

The first thing people may think is that this is easier said than done. However, creating a text classifier and keyword list to block dangerous prompts and outputs is a quickly achievable task, especially for a small team with access to AI.

A simple text classifier can be deployed effectively at the network edge of AI platforms, such as Cloudflare, which many artificial platforms are already paying for. This means costs would not increase significantly. The approach relies on traditional computer code rather than direct interaction with a large language model, helping protect trust and safety while reducing the financial risks associated with rising and unpredictable inference costs.

When a prompt contains predetermined patterns or keywords, the classifier can immediately flag it, allowing the AI platform to take appropriate action. In my proof of concept, the classifier completely blocks the request. However, alternatives developed by teams with more expertise could direct users to emergency services or crisis lines based on the context of the request, or, in severe cases, notify the user’s emergency contact.

This proof of concept is implemented in JavaScript and runs seamlessly on Cloudflare Workers, the company’s edge computing platform. It requires minimal adjustment while helping protect the services involved. The code was generated by ChatGPT and thoroughly reviewed by me.

export default {
  async fetch(request) {
    if (request.method !== "POST") {
      return new Response(
        JSON.stringify({ error: "Method not allowed" }),
        { status: 405, headers: { "Content-Type": "application/json" } }
      );
    }
    const body = await request.json().catch(() => ({}));
    const text = String(body.prompt || "").toLowerCase();
    const blockedPatterns = [
      /\bsuicid(e|al)\b/i,
      /\bself[-\s]?harm\b/i,
      /\bhurt myself\b/i,
      /\bend my life\b/i,
      /\bkill myself\b/i,
      /\bi want to die\b/i
    ];
    const isBlocked = blockedPatterns.some((pattern) => pattern.test(text));
    if (isBlocked) {
      return new Response(
        JSON.stringify({
          error: "Forbidden",
          message: "This prompt is not allowed."
        }),
        {
          status: 403,
          headers: { "Content-Type": "application/json" }
        }
      );
    }
    return new Response(
      JSON.stringify({
        ok: true,
        message: "Prompt allowed."
      }),
      {
        status: 200,
        headers: { "Content-Type": "application/json" }
      }
    );
  }
};

As a side note, if you ever find yourself in crisis, please reach out to a real person for support. I highly recommend Crisis Text Line, as a disclosure I am a donor to this organization.

Keyword filters, such as the text classifier I wrote, are a useful first step, but they should not be treated as a complete safety system. AI platforms need defense-in-depth: multiple layers of protection that work together to reduce the chance of harmful outputs reaching users. A keyword filter can catch obvious patterns, but it cannot understand every context, every phrasing strategy, or every attempt to bypass moderation. That is why it should be paired with additional safeguards that detect risk across both user inputs and model outputs.

Many of these safeguards already exist outside of large language models. Machine learning systems that detect toxicity, violence, spam, and other harmful content are already widely used across online platforms, and they do not carry the same extreme and unpredictable costs associated with running large language models. These tools can help identify dangerous patterns earlier in the process, before a request reaches the model or before an unsafe response is returned to the user. In this sense, AI safety does not need to rely solely on another AI chatbot judging whether something is dangerous. Traditional classifiers, rule-based systems, and specialized moderation tools can all play a practical role.

Large language models themselves can still support safety by maintaining clear behavioral boundaries. When users misuse an AI platform, or when they appear to need help that the system is not equipped to provide directly, the platform should redirect them to appropriate external resources rather than continuing the conversation as if nothing is wrong. In some cases, a request may need to be blocked entirely. In more serious situations, such as a user describing a medical emergency or mental health crisis, the platform may need to escalate the situation through carefully designed safety systems, such as a trusted contact feature or emergency support in extreme cases.

ChatGPT’s Trusted Contact system provides one possible model for how AI platforms can approach this kind of escalation. Similarly, accounts for younger users that are linked to a parent or guardian can provide a separate safety pathway when additional support is needed. These systems should be designed with care, transparency, and respect for the user’s dignity. Safety should not become an excuse for unnecessary surveillance or overreach. Human rights, privacy, autonomy, and user well-being should remain central to the design of any intervention system.

Automated review can also help flag conversations for human review when a system detects signs of elevated risk. If an emergency is not identified immediately, a later human review could still trigger a supportive follow-up, such as an in-app pop-up, text message, or email with additional resources. This could take the form of a simple “we care about you” system that offers help without being punitive or invasive. The goal should be to create a safety net, not a punishment system.

Users should also have more control over the kinds of content they are exposed to. AI platforms should allow people to opt out of specific categories of content, such as graphic violence, sexual content, or material that may be triggering for someone with a mental health condition. These controls would not replace broader safety systems, but they would give users more agency over their own experience and reduce avoidable harm.

Ultimately, companies developing artificial intelligence systems should consult psychologists, accessibility experts, crisis specialists, human rights experts, and other relevant professionals when designing safety features. Technical safeguards are important, but they are not enough on their own. AI safety has to be built around real human beings, including people in moments of vulnerability, confusion, distress, or crisis. A strong system should not assume that users will always behave perfectly. It should protect them even when they make mistakes, act impulsively, or need help they may not know how to ask for.

In closing, we should not expect artificial intelligence and large language models to solve the compliance, ethical, and safety problems they helped create. Instead, we should return to the same practical techniques that helped keep the internet safer before this technology became widely available: layered safeguards, independent enforcement systems, identity verification, traditional machine learning classifiers, human review, and clear accountability structures.

We cannot allow systems that have already caused real-world harm to decide for themselves whether they will enforce the guidelines we give them. Large language models are exceptionally skilled at language and language-based tasks, which is exactly why relying on them as the primary safety mechanism is risky. They can technically comply with instructions while still ignoring the intent behind them. They can reframe, soften, obscure, or “weasel word” their way around human directives, even when they are capable of understanding what those directives mean.

That is why AI governance cannot be left to AI alone. Safety systems need to exist outside the model, not merely within it. The model can assist, but it should not be the judge, jury, and enforcement mechanism for its own behavior. If artificial intelligence is going to be trusted in society, its safeguards must be independent, layered, and grounded in human accountability rather than delegated back to the same systems that created the risk in the first place.