By Atul Arya, Founder & CEO, Blackstraw
There seems to be a new AI model or platform every week, each one promising to make businesses faster and smarter. So technology leaders have plenty to choose from. The hard bit is working out which of these will still be standing once they’re inside their own organization.
I’ve sat through more AI demos than I can count, and to be fair, most of them are impressive. Ask the chatbot anything and it has an answer. The automation tool takes some painful process and makes it look effortless on a slide. Then you try it inside an actual company, where the data lives in five systems that were never meant to talk to each other, and the process has been patched so many times that nobody quite remembers why it works the way it does. Change one thing, and three teams feel it.
That’s the part demos skip, and it’s where picking a partner starts to matter. Lots of firms can build you a decent prototype these days. I’d want to know whether they’ll bother to learn how your business runs, and whether they’ll still be around once people are actually using the thing.
Start with what’s broken
In my experience, the conversations that go well start with a lot of questions and very little selling. What are you trying to fix? Where is the current process letting people down? What would make this worth it six months from now?
It sounds obvious, but you’d be surprised how often it gets skipped. Boards want to see something happening with AI, and that pressure often gets ahead of what the business actually needs.
Retail and consumer goods companies with shaky demand forecasts are a good example. The first conversation is usually about generative AI, because it’s on everyone’s mind. Then we look at the data behind their forecasts and end up talking about something else entirely: duplicate records, missing history, spreadsheets nobody owns. Fix those, and even a fairly ordinary forecasting model starts earning its keep. (Automating a badly designed process has the same problem. You just get the mess faster.)
A good partner should be willing to tell you that, even if it means a smaller project for them. Not everything needs AI, and pretending otherwise doesn’t do anyone any favors.
After the pilot
Building a prototype is the easy part. Production is where it gets hard. Pilots tend to run on the best data a company has. Production runs on all of it, including the messy records nobody’s touched in years and the questions nobody thought users would ask.
There are questions nobody really asks during a pilot that suddenly matter a lot afterward. How fast does it respond when the whole company is using it? What happens when it’s wrong? Is it still affordable at full scale? And when it falls over late at night, who actually picks up the phone?
In our own work, the model is rarely the hard part. It’s usually the data feeds and the edge cases, and the handoffs nobody mapped during the pilot. So when you’re talking to a potential partner, ask which projects they’ve actually taken past the pilot. Then ask what went wrong. If they say nothing did, I’d be a little worried. You’ll learn more from that conversation than from any case study they hand you. Anyone can show you what’s possible. I’d be more interested in a system that’s still doing its job on some ordinary Tuesday, six months after launch, without anyone babysitting it.
Fitting in with what’s already there
Almost nobody gets to start from scratch. There’s usually a legacy system nobody wants to touch, and a database someone built a decade ago that somehow still holds everything together. People have built their own workarounds on top of all that, and they’re attached to them.
Put an AI tool into that as a standalone island, and it can easily make more work than it saves. It’s not unusual to see teams copying outputs from the new tool and pasting them into the old system by hand, which rather defeats the point.
So integration needs to come up early. I’d want a partner asking how information actually moves around your organisation, and whether anyone trusts the data by the time it gets where it’s going.
It isn’t only a technology problem, either. If the people who are meant to use the tool can’t see where it fits in their day, they’ll quietly go back to the old way. Nobody announces it. The tool just stops getting opened.
Don’t leave security for later
Things get more serious once an AI system can see customer records or confidential business data. They get more serious again once it can act on that data, and that’s where agents are taking us. CERT-In’s recent advisory on AI agents is worth reading for exactly this reason. An agent can only do as much damage as the access you’ve given it.
Technology leaders need straight answers. I’d start with the basics: where the data is processed, and who can get to it. Then I’d ask what the system is allowed to do on its own, and what still needs a person to approve. Could sensitive information slip out through the way people interact with the model? And if it gets something wrong, what stops a small mistake from turning into a big one?
The answers will look different depending on what the tool does. If it’s summarizing internal documents, you can afford to be a bit relaxed. If it’s approving payments or talking to customers, you can’t.
What I’d push for is having this conversation early. Trying to add security after a system is live is a bit like rewiring a house after people have moved in. It can be done, but it’s slower, messier and more expensive than doing it upfront.
Being straight about what to expect
If I’m honest, very few AI projects go exactly to plan. The data usually needs more work than anyone expected. Integrations take longer. And sometimes you realize halfway through that the first idea wasn’t the right one.
That’s why I’d put a lot of weight on a partner who’s straight with you early about timelines and what could hold things up. Cost too. Ask what it’ll take to keep the system running a year from now, once the project team has moved on.
It also helps to agree up front on what success means. For one business, that might be faster claims processing. For another, it’s forecasts the planners actually trust. Whatever it is, it should be something the business cares about, not a dashboard counting how many queries the AI handled.
What happens after go-live
A lot of teams relax once the system goes live, which is usually just when the real work starts. Data drifts. Priorities shift. Somebody has to keep an eye on performance. And the models underneath will change too, probably more than once.
So before you sign, ask what happens after. When something breaks, who do you call, and how quickly does it get fixed? I’d also want to know whether the partner will still be around in a year, helping the system get better and picking up new problems as they come.
Most companies we’ve engaged with have done the pilots by now. What they want is something that works on Monday morning and is still working a year later. That has less to do with the technology than with who’s building it with you, and whether they stick around when it gets difficult.