There is a workflow doing the rounds that is genuinely useful and also easy to get wrong: export your search terms report, paste it into ChatGPT or Claude, and ask the model to find the negative keywords. Done well it turns an hour of squinting at rows into a few minutes of reviewing a sorted queue. Done badly it floods a shared negative list with confident, unverified blocks that quietly strangle good traffic. The difference is entirely in the guardrails, and almost none of the "just ask AI" guides put any in.
This post is the guardrailed version. It is vendor-neutral — the model you use barely matters — and it assumes you have the Google Ads UI open and can export a report. The core idea is that a general-purpose LLM is a fast classifier for data you already have, not a source of negatives it invents from your product description. Get that distinction right and the rest follows.
What the model can and cannot do
The direct answer: an LLM with no access to your account cannot find your negatives, because it cannot see which queries took your money. If you only describe your business and ask for negative keywords, you get a generic starter list — "free," "jobs," "cheap," "DIY" — that has no connection to your actual spend. One prompt guide is candid about this, noting that ChatGPT does not see your actual search queries, so it cannot replace the search terms analysis. That generic list is not useless as a day-one seed, but it is not mining your account.
The workflow that works is the inverse. You do the analysis — you pull the search terms report with cost and conversions attached — and the model classifies the real list. Now it is reading evidence instead of guessing, and its job is narrow and well-suited to a language model: read each term, decide whether it matches what you sell, and group the irrelevant ones by why they are irrelevant. That is triage, and triage is exactly what a model is good at and a human is slow at. Keep the model on the data side of that line and it earns its place; let it generate negatives from nothing and you are back to a borrowed list.
Prepare the export so the model can rank waste
Open the search terms report at the account or campaign level, set a window long enough that a zero in the Conversions column is meaningful — 30 to 90 days for most accounts — and include the columns that carry signal: search term, cost, clicks, conversions, and conversion value. Download it, or copy the rows directly. The cost and conversion columns are not optional decoration; they are the only thing that lets the model separate a term that burned a lot of money with nothing to show from one that spent two cents. Without them it can only judge relevance by wording, and relevance without cost is how you end up negating cheap harmless terms while the expensive leaks sit untouched.
Two honesty caveats about the data itself. First, the search terms report is privacy-thresholded, so low-volume terms never appear even when they took spend — the export is the visible head of your waste, not all of it, and no model can classify rows it was never shown. Second, pasting account data into a third-party model sends that data to the vendor. Generic commercial queries are usually fine, but check your own policies before uploading anything that could contain personal or sensitive information, and strip or redact it if in doubt. The model cannot un-see what you give it.
Prompt for a review queue, not a finished list
The prompt should ask the model to do three things and stop: classify each term as relevant, irrelevant, or ambiguous; group the irrelevant ones by intent category (jobs, informational, DIY, wrong product, competitor, location mismatch); and for each proposed negative, suggest a match type and flag any term it is unsure about. Ask it to sort by the cost behind each term or group so the expensive waste rises to the top. One worked example has the model turn the list into negative keywords grouped into clear categories, with a recommended match type for each — that grouping is the useful output, because it lets you fence a whole category at once instead of rubber-stamping terms one by one.
Crucially, tell the model to produce an ambiguous bucket and to put anything borderline in it rather than forcing a verdict. The terms that cost you money are rarely the obvious junk — those you would have caught anyway. The dangerous ones are the queries that could be a buyer or could be a tyre-kicker depending on context the model does not have, and a model instructed to be decisive will guess. A model instructed to flag uncertainty hands you a short list of real decisions. That ambiguous bucket is not a failure of the model; it is the part of the job that was always going to need a human, and it belongs in a review queue, not a negative list.
Verify before anything reaches a negative list
Never paste the model's output straight into a shared negative list. An LLM is a confident classifier, and confidence is not accuracy: it will tag a term as irrelevant that is actually a product line you sell under an unfamiliar name, or propose a tidy broad negative that happens to block a converting query. Treat every proposed negative as a claim to check. Sort your own export by cost, find the terms the model flagged, and confirm they genuinely have no conversions and no assisted value before you block them — a zero-conversion term can still have assisted a conversion credited elsewhere, and negating it then costs you money rather than saving it.
The failure mode to picture concretely: the model sees "used" across a batch of queries, decides your store sells new goods, and proposes a broad negative on "used." You bulk-add it. Three weeks later you notice the campaign targeting people searching "trade in used X for new X" — high-intent buyers — went dark, because a broad negative blocks any query containing all its terms. That is not a hypothetical edge case; it is the ordinary consequence of trusting a classifier that cannot see your margins. Verification against real spend and conversions is the step that separates a time-saver from a slow-motion self-inflicted wound, and it is the step every "automate it with AI" pitch skips.
Set the match type, and add the variants yourself
Once a negative survives verification, you still have to decide how it should match — and this is another place the model will quietly mislead you. Negative keywords do not behave like positive ones: they block strings, not meanings, and they do not expand to close variants. A negative on "recruiter" does nothing for "recruiters," "recruiting," or the misspelling "recruter." So a suggestion list that contains the singular form only is incomplete by default, and the model will not point that out unless you ask.
The fix is to make variant generation an explicit step. After you have your verified list, ask the model to expand each entry into its singular and plural and the common misspellings visible in your export — this is the one task where an LLM is genuinely better than a human, because it will enumerate forms you would forget. Then choose the match type deliberately: phrase or exact for precise blocks where a broad negative would over-reach, broad only when you are confident every query containing those words in any order is waste. Decide the level too — a one-off junk term belongs at the campaign or ad group level, while a universal exclusion belongs on an account-level shared list. The model can draft all of this; the choice stays yours.
Where LLM triage fits in the bigger workflow
LLM triage is one instrument, not the whole panel. It pairs naturally with an n-gram analysis: the n-gram pass is a statistical count that surfaces the high-cost words worth fencing with a single negative, while the LLM pass reads meaning and catches the scattered one-off queries that share no common token. Run the n-gram pass first to fence the obvious recurring waste cheaply, then let the model triage what remains. Doing it the other way round works too, but you will spend model effort on terms a word count would have caught in seconds.
Keep sight of when to stop. Each pass through the export has a declining return — the first one finds the terms carrying most of the waste, and later passes turn up smaller and smaller leaks until the time spent exceeds the money saved. That is the same curve that governs all negative mining, and it is worth knowing where negative-keyword mining stops paying off before you build a weekly ritual around pasting exports into a chat window. Used as a triage accelerator on a cadence that matches your spend, an LLM is a real efficiency gain. Used as an oracle that decides what to block, it is a faster way to make the mistakes that over-negating always made — now at scale, and with the comforting illusion that a machine checked them.