Internal AI Spending Needs a Kill Date

A company spending heavily on AI and only afterwards building a tool to calculate the return has the sequence backwards. At that point, measurement is closer to an autopsy than product management.

This pattern is becoming more visible as companies add AI software, launch internal assistants and test agent-friendly browsers while product leaders are simultaneously being told to run smaller experiments, question expensive decisions and protect teams from the cost of moving too fast. These are not separate conversations. They point to a basic governance problem: internal technology is still often exempt from the standards we apply to customer products.

For a customer-facing feature, we normally ask whose problem it solves, what behaviour should change and what evidence would justify further investment. For an internal AI initiative, the standard can suddenly become much lower. A senior leader sees a promising demo, a budget is approved and several teams are asked to find uses for it. Adoption is then treated as proof of value, even when usage is driven by management attention, free access or curiosity.

I think every meaningful internal AI investment should have a kill date before it has a business case deck.

A kill date is not a deadline for proving that the technology works. Most of these tools work in some form. It is a date on which the company decides whether the initiative has improved a defined workflow enough to deserve more money and attention. If nobody is prepared to state what would cause the initiative to stop, the organization is not running an experiment. It is making a commitment while borrowing the language of experimentation.

Take an AI assistant introduced for a customer support team. The tempting approach is to buy licenses, offer training and track weekly usage. A better approach starts with one workflow, such as preparing a first response to a recurring category of request. One person owns the operational result. The team agrees what must improve and what must not deteriorate. It also accounts for review time, corrections, escalation and maintenance. After a fixed period, the company expands, changes or stops the initiative.

The distinction matters because internal tools can move costs rather than remove them. A response may be drafted faster but require more checking. A product manager may produce documents faster while engineers spend longer resolving ambiguity. A new assistant may save ten minutes in one task but add another place where employees must search, verify and update information. A usage dashboard will show activity while hiding this redistribution of work.

This is also why ownership cannot sit only with IT, procurement or a central AI group. They can manage security, contracts and technical standards. They cannot decide whether a workflow has become better for the people performing it or for the customer receiving the result. That judgment belongs with the leader accountable for the workflow, supported by the team doing the work.

Small process experiments are useful here because they make weak assumptions cheap to discover. Before connecting an AI tool to every company system, test whether it helps one team make one recurring decision. Before buying broad access, observe whether people return to it once the novelty has faded. Before describing saved time as financial return, decide what the team will do with that time. Capacity only becomes value when it is deliberately reassigned.

Product leaders should be especially strict about this. We cannot argue for evidence-based roadmaps on Monday and support unbounded internal technology spending on Tuesday. Nor should we ask teams to absorb each new tool as if learning, correcting and maintaining it were free.

The practical test is simple. Name the workflow owner, the intended change, the acceptable side effects and the date on which funding will be reconsidered. If those four things cannot be agreed, the company is not ready to scale the initiative. It may not even be ready to start it.