Here is a claim that sounds like false modesty from someone who builds AI systems for a living, and is not.
The software is the cheap part.
Not free, and not trivial to get right. But of everything that has to go correctly for an AI rollout to change a company's numbers, the part where a model produces good output is the part that is now largely solved and getting cheaper every quarter. Almost everything that makes these projects fail sits somewhere else entirely.
Two lines from recent conversations get at it better than any framework:
The secret sauce is implementation and integration into a human workforce.
And, from a different call, about companies that had already bought perfectly good technology:
They still need someone who knows how to get their team to use it.
That is the whole teardown. But it is worth being specific about what "implementation" actually contains, because it is not one thing. It is five, and every one of them costs more than the software.
1. Adoption
This is the big one, and it is the one nobody budgets for.
A tool that eight people love and forty people ignore has not changed your business. It has added a line item and a small internal culture war. The failure is rarely that the tool is bad. It is that using it properly requires people to change a habit that currently works, in exchange for a benefit they have not experienced yet.
Real adoption work looks like this: pick the workflow that a specific team already finds painful, install the AI teammate into the channel where that team already talks, and let them watch it do the painful thing well, once. Then get out of the way. Adoption follows demonstrated relief, not training decks.
The counter-example is the all-hands rollout, where everybody gets access on the same Monday and nobody has a reason to be first.
2. Prompting, which is really specification
"Prompt engineering" makes this sound like a trick. It is not a trick, it is specification, and it is a genuine skill that most organisations do not yet have.
The gap between a mediocre and an excellent result from the same model is almost always the quality of the assignment. Not clever phrasing. Context: who the audience is, what a good outcome looks like, what to leave out, what the house style is, which constraints are hard, and what to do when something is ambiguous.
Most companies have never written any of that down for their human staff either. It lives in the head of whoever has been there longest. Getting it out is work, and it is the work that compounds, because a well-specified assignment keeps paying every time it runs.
3. Tool wiring
An AI teammate that cannot reach your systems is a very expensive conversation partner.
The value shows up when it can read the meeting recording, pull the current numbers, check the CRM, look at the actual document, and write the result back into the place your team already looks. Each of those connections is real engineering: authentication, rate limits, data shapes that do not match, systems whose export was clearly designed by someone who never intended it to be read by anything else.
This is unglamorous and it is where a serious chunk of a build actually goes. It is also the part that a category of shrink-wrapped AI products quietly skips, which is why they demo beautifully and then sit unused.
4. Permissions
The moment an AI system can read broadly and act on your behalf, you have created a new class of question, and it is not a technical question. It is a governance one.
Which people can ask it to do which things. Which data it may see for which requester. Whether the answer to "summarise the leadership discussion" changes depending on who is asking. Whether it can act, or only recommend.
Connectors are access paths. They are not a permission system. A connector will happily give a model everything the connecting account could see, which is usually far more than the person typing the request should get. Building the actual boundary is separate work, and skipping it is how a helpful assistant becomes an incident.
5. Leak prevention
Related, but distinct, and this is the one that ends deals.
The concern is not that a model is malicious. It is that information moves in ways nobody intended. Client A's numbers appear in a summary prepared for client B because both sat in the same folder. An internal comment about a person surfaces in a document that leaves the building. A recording that someone consented to for one purpose becomes training material for another.
Preventing that is a design decision made before the first connection, not a policy written after the first mistake. It means scoping what is retrievable, keeping tenants genuinely separate, and being deliberate about what recorded conversations may ever be reused for.
Why this framing matters to a buyer
There is a whole category of AI products sold as digital employees, metered by credits, that will tell you the software is the product. Buy the seat, meet your new team member.
Some of them are good. The category has a structural blind spot, though: it sells you capability and leaves all five items above with you. That is fine if you have an internal team that can do adoption, specification, integration, permissions, and data boundaries. Most 10 to 50 person companies do not, which is why the honest version of the pitch is not "our model is better." It is that the model is increasingly a commodity, and the work of installing it into a specific human workforce is not.
You can see this in what actually changes when it goes well. An event site that had taken three to four months got rebuilt in about a week. That did not happen because a model got smarter that quarter. It happened because the work was specified properly, the system could reach the things it needed, and a person reviewed the output at the right moments.
How to test a vendor on this
If you are evaluating anyone, including us, the useful questions are not about models:
- Which of my systems will this actually connect to, and who does that integration work?
- What happens in week three, when the initial enthusiasm has worn off and two teams have gone back to their old habits?
- Who decides what it may see, and how do I change that later?
- If I ask it something my colleague should not see the answer to, what happens?
- What is the first workflow, and why that one?
A vendor who answers those in specifics is describing implementation. A vendor who redirects to model benchmarks is selling you the cheap part.
Where to start
Before anyone builds anything, we run a two-day audit of how work actually moves through the business: where things queue, which handoffs are held together by one experienced person, and which of those are genuinely delegable. Most of what it surfaces has nothing to do with AI, which is rather the point.
If you want to know where the lever applies in your operation, and where it does not, apply at advisy.com.