There’s a quiet crisis happening in IT leadership across Australia right now. Every executive committee meeting has at least one AI agenda item, and the unspoken rule is that the CTO should sound enthusiastic. Push back, and you’re suddenly “blocking innovation.” Stay quiet, and you’re approving projects you know will fail.

I’ve been in this job long enough to have said yes to AI initiatives I shouldn’t have. The ones that burned 14 months and seven figures before quietly disappearing from quarterly reports. I’ve also said no, sometimes loudly, and survived. Here’s what I’ve learned about distinguishing the two.

The Three Questions That Filter Out 60% of AI Pitches

When something lands on my desk with the word “AI” in the title, I run it through three questions before doing any deeper analysis.

First, what would success measurably look like, and who’s going to own that measurement six months from now? If the answer involves words like “productivity gains” or “better insights” without a baseline number attached, the project isn’t ready. It’s an idea, not an initiative.

Second, what data feeds this thing, and is that data actually fit for the purpose? About half the AI proposals I see assume our data is cleaner, more complete, or more recent than it actually is. The proposer hasn’t talked to anyone who works with the data day-to-day.

Third, what happens when the model gets it wrong? Not theoretically wrong—specifically wrong, on a Tuesday at 3pm, in front of a customer or a regulator. If nobody on the project team has a clear answer, the risk profile hasn’t been thought through.

Roughly 60% of proposals fail at least one of these. The Australian Information Industry Association reported in early 2026 that around 70% of enterprise AI pilots don’t reach production. My three-question filter is essentially trying to prevent us from joining that statistic.

The Politics of Saying No

The harder part isn’t the technical assessment. It’s saying no without becoming the obstruction story in someone else’s narrative.

I’ve found three things help. The first is timing. If you’re going to push back on an AI project, do it early and in writing. The longer a project has been alive, the more politically expensive it becomes to question it. By the time it’s in front of the steering committee, you’re not assessing a proposal—you’re attacking a stakeholder’s work.

The second is offering an alternative. “No” feels like a wall. “Not this, but here’s a smaller experiment that would actually answer the question we’re trying to answer” feels like collaboration. Even if the alternative gets ignored, you’ve established that you’re not the obstacle.

The third is being explicit about what you’d need to see for a yes. Sometimes the proposal genuinely has merit, but the supporting case is half-baked. Saying “I’d support this if we had a defined success metric, a data quality audit, and an identified business owner” gives the team a path forward without committing the company.

If you want outside help building that supporting case—or just a second opinion on whether a vendor’s promises hold up—it’s worth involving people who do this work full-time. We’ve worked with Team400 on a couple of evaluations where having a Microsoft AI consulting view from outside the room genuinely changed how we framed the project to the board.

The “But Everyone Else Is Doing It” Trap

The single weakest argument for an AI project, and the most common one I hear, is that competitors are doing something similar. This argument has a specific weakness: it assumes the competitors’ projects are working.

They’re often not. The successful AI implementations get press releases. The failures get quietly written off in the next earnings cycle. If you’re benchmarking against publicly announced AI initiatives, you’re benchmarking against marketing, not against results.

I’ve had this conversation in board meetings more than once. “Company X just announced they’re using AI for customer service.” Yes, they announced it. Have they renewed the contract? Have their customer satisfaction scores moved? Are their service costs down? Nobody’s asking those questions, but they’re the only ones that matter.

When to Actually Say Yes

I don’t want to give the impression that I reject everything. I’ve championed several AI initiatives that produced real value. The pattern in the ones that worked: small initial scope, a specific operational problem rather than a strategic vision, an internal owner who actually wanted to use the thing, and a hard deadline for evaluating whether it was working.

A document classification system we rolled out last year hit ROI in seven months. It wasn’t sexy. It wasn’t on the keynote slide. It just worked, because everyone involved was honest about what success looked like.

The Career Calculation

There’s a real career risk to being the CTO who says no to AI. I’m not going to pretend otherwise. The risk of saying yes to bad projects is slower and quieter—it shows up as missed deadlines, mounting costs, and eventual quiet failures.

The risk of saying no is faster and louder. You get labelled, sometimes unfairly. But here’s the thing: the CTOs I’ve seen lose their jobs over AI haven’t lost them for being too cautious. They’ve lost them for being publicly associated with expensive failures.

Pick your risk. I’d rather defend a measured assessment than explain a $3M write-off.