The AI Tools Nobody Remembers Approving

Marketing teams have spent the last two years adding AI tools faster than they can account for them. A recent piece in AI Journal made the case that better data discipline has to come before better tools, and that argument holds. But there’s a second gap sitting right behind it. Even with clean data, most marketing teams still can’t say who owns a given AI tool, what happens when it produces something wrong or which tools anyone on the team actually opens anymore. 

The average enterprise marketing team now runs somewhere between 30 and 90 tools in its stack, and a growing share of those are AI-driven. Tools get added during a pilot, a conference demo or a single urgent campaign, and then they stay. Nobody schedules the conversation about whether they should. 

The piece nobody owns is the lifecycle. The pitch deck that got a tool approved and the onboarding call where someone learned which buttons to press both happen before the real work starts. What comes after is different. It includes who’s accountable when the tool is wrong, whether the tool is still earning its subscription six months in and who decides when it’s time to turn it off. 

I’ve run this process across 29 service lines while moving an agency into dedicated AI-native proprietary systems, because the failure it prevents is common across marketing teams. Teams that skip the lifecycle fail quietly, carrying tools nobody remembers approving and paying for licenses nobody uses, and finding ownership gaps only after something has already gone out the door wrong. None of what follows requires a platform or a vendor. It’s five checks any marketing team can run against its own stack this quarter. 

Check One: Named Ownership 

Every AI tool in active use, bought or built, should have one named person attached to it, not a department, not a shared inbox. That person answers for how the tool is configured, who has access and what it’s allowed to touch. If you can’t produce that name in under a minute for a tool your team uses weekly, you don’t have ownership. You have a login. 

This matters more than it sounds. When a generative tool produces a claim that shouldn’t have gone in an ad, or a personalization engine sends the wrong offer to the wrong segment, someone has to catch it and fix the setup that let it happen. Without a name attached, that job falls to whoever notices first, usually the person with the least context and the least authority to act. 

Check Two: A Documented Failure Mode Before Adoption 

Before a tool goes live, someone should write down, in a few sentences, what its most likely failure looks like and what happens when it occurs. Skip the hypothetical worst case and write down the boring, likely one, and let the chatbot example follow. A chatbot answers a question it shouldn’t, a content generator produces something off-brand at scale, or an automated bidding tool overspends on a channel that isn’t converting. 

Most teams skip this because it feels like betting against the tool before it’s had a chance. It’s closer to a seatbelt. Writing the failure mode down before adoption means the response is already decided when the failure happens, instead of being improvised in a Slack thread while a bad output is still live. 

Check Three: Versioned Changes You Can Reverse 

AI tools change their own behavior in ways traditional software doesn’t. A model update, a prompt template edit or a new default setting can shift outputs across every campaign the tool touches, often without an obvious changelog. If your team can’t say what changed and when, or can’t roll a tool back to its last known-good configuration, you’re flying blind the next time something breaks. 

This doesn’t require enterprise version control. A shared log with a date, what changed, who approved it and how to revert it covers most marketing teams’ needs. The test is simple. If a tool starts producing worse output next Tuesday, can someone identify what changed and undo it within an hour? 

Tools a team builds itself need this even more. An in-house agent or automation usually calls a model the team doesn’t control, so the first line in the log should be which model version it runs on, pinned to a specific release. When a scheduled reporting job loses its connection and runs anyway, it can overwrite its last good output with blank data. With no version history to roll back to, the record is then gone. 

Check Four: Usage Data, Not Survey Enthusiasm 

Ask a team if they like a tool and you’ll get an opinion shaped by the training session and how recently anyone complained about it. Pull the usage data instead, such as how many campaigns the tool touched last quarter, and the answer is often a different story. Enthusiasm and usage diverge more often than teams expect. 

Every tool renewal decision should be backed by actual usage data. Look at seats activated versus seats paid for, frequency of use by the people who were supposed to rely on it and outputs that made it into a live campaign versus outputs that got quietly discarded. If a tool has three engaged users out of the twenty licenses you’re paying for, that’s the number that should drive the renewal conversation, not the case someone made for it at rollout. 

For tools a team builds, usage data has to include run data: how often it ran, how often it succeeded and whether anyone used the output. For example, a content QA automation can return an error on every single run for weeks without anyone noticing, because nothing downstream breaks loudly enough to raise a flag. A seat count would never surface that. A run log does. 

Check Five: A Sunset Review Where Removal Is the Default 

Most software reviews start from the assumption that the tool stays unless someone builds a case against it. Flip that assumption for AI tools. Set a review date at adoption, six or twelve months out, where the tool is removed by default unless someone actively makes the case to keep it, backed by the usage data from check four. 

This is the check teams resist most, because removing a tool feels like admitting the original decision was wrong. It usually isn’t. Tools that were right for a six-month pilot are often wrong for a permanent line item, and a sunset review that defaults to removal is the only mechanism that catches that shift before it becomes three years of unused licenses. 

The sunset review matters most for tools a team builds itself. Agents, automations and scheduled jobs come with no invoice and no renewal date, so nothing on the calendar ever forces the question. They keep running, and keep costing compute and attention, long after the campaign they were built for has ended. Give every internal build the same review date a purchased tool gets, and count its runs and failures the same way the team would count seats. 

Where None of This Is Worth It 

Not every tool needs this much structure. A single-purpose utility that never touches customer data or customer-facing output, and costs little enough that nobody would notice if it vanished, doesn’t need a named owner or a sunset review. Building that governance around a $20-a-month grammar checker wastes more time than the tool could ever cost you. 

The lifecycle earns its overhead when a tool touches customers or brand-facing output, or when it costs enough to run or unwind that walking away isn’t free. A generative tool writing ad copy that ships without human review clears that bar easily. An internal tool that summarizes meeting notes for one person’s use probably doesn’t. Teams that apply the same five checks to everything end up resenting the process and abandoning it within a quarter, which defeats the purpose entirely. 

Building the Habit 

None of these checks are complicated on their own. What’s hard is doing them on a schedule, before the pressure of a launch date makes ownership and failure modes feel like someone else’s problem. A marketing team that can name an owner, describe a failure mode, reverse a change, read its own usage data and default to removal has a functioning lifecycle. Most marketing teams have none of these five in place, and it isn’t for a lack of talent or effort. 

It’s because nobody had assigned the work of asking. Data discipline gets a tool ready to be useful. A lifecycle is what keeps it useful or removes it before it quietly stops being worth the seat.