דלגו לתוכן המרכזי / Skip to main content
    All articles
    August 20, 20268 min read

    What Does AI Implementation Actually Cost? A Cost Model for Business Leaders

    Nobody can quote you an AI project price from a one-line brief. But you can model the cost yourself. Here are the five drivers that decide the number.

    Shmulik Davar
    Founder & AI Advisor
    What Does AI Implementation Actually Cost? A Cost Model for Business Leaders

    The short answer

    There is no list price for AI implementation, because almost none of the cost sits in the AI. The cost sits in five drivers: how clearly the problem is scoped, how much has to be built versus configured, how many systems it must integrate with, how many people have to change how they work, and what it costs to run and maintain once it is live. Model those five and you can sanity-check any proposal you receive — including ours.

    The five drivers at a glance

    DriverWhat makes it cheaperWhat makes it expensive
    Scoping clarityOne mapped workflow, one owner, one number"Use AI in support" with no baseline
    Build vs configureConfiguring an existing toolCustom pipelines and fine-tuning
    Integration surfaceRead-only, one or two systems with APIsWriting into legacy systems without APIs
    AdoptionEnablement budgeted with the buildTraining treated as a later phase
    Run and maintainBuilt with your team, lean contextHanded over as a black box

    Driver 1 — Scoping clarity

    The cheapest projects arrive with a workflow already drawn: who does what today, at which step the time or money is lost, and what "better" looks like numerically. The most expensive projects start with "we want to use AI in customer support."

    Ambiguity is not a discount you get later; it is paid for in discovery weeks, rework and abandoned prototypes. If you can't describe the current workflow in five minutes, budget for a short paid discovery phase before anyone quotes a build. It is almost always cheaper than the alternative.

    Cost lever: define one workflow, one owner, one measurable outcome.

    Driver 2 — Build versus configure

    Three very different budgets hide behind the same phrase "AI solution":

    • Configure. An existing tool (a coding assistant, a meeting assistant, an off-the-shelf support copilot) plus rollout and training. Cheapest, fastest, lowest ceiling.
    • Assemble. Existing models and services wired into your own thin application: retrieval over your documents, an agent that follows your process, a review step for a human. Mid-range, where most real value currently lands.
    • Build. Custom pipelines, evaluation harnesses, fine-tuning, or an internal platform other teams build on. Highest cost, justified only when the workflow is genuinely core to the business.

    Most organizations should be doing far more configuring than they think, and far less building.

    Cost lever: ask for a build-vs-buy decision per use case, in writing, with the reasoning.

    Driver 3 — Integration surface

    Integration, not intelligence, is where AI budgets are consumed. Each system the solution has to touch adds authentication, permissions, data mapping, error handling, and someone's approval. A tool that reads a document and returns text is a small project. The same tool writing into an ERP, respecting per-user permissions and leaving an audit trail is a different order of magnitude.

    Legacy systems without an API are the single most common source of overrun. If a system has no clean interface, the honest options are a documented interface layer (for example an MCP server that exposes the system safely, with mock, sandbox and live modes) or keeping a human in that step for now.

    Cost lever: count the systems in scope. Then ask which of them you could keep out of phase one.

    Driver 4 — Adoption

    A solution nobody uses costs 100% of its budget and returns nothing, so adoption is a line item, not a hope. It means enablement sessions for the people whose work changes, written guidance in their language, a feedback loop for the first weeks, and a named internal owner who is measured on usage.

    This is usually 10–30% of a program's effort and it is the part most often cut first. It is also the part that decides whether anything survives the engagement.

    Cost lever: budget enablement in the same proposal as the build, not as a later phase.

    Driver 5 — Run and maintain

    Live AI has ongoing costs that a pilot never reveals:

    • Model usage, which scales with volume and with how much context you send. Prompt and retrieval design change this materially.
    • Monitoring and evaluation — quality drifts as models, data and usage change, so someone has to watch.
    • Ownership — whoever maintains it needs to understand it. Work built with your team costs less to run than work delivered to your team.

    Cost lever: ask what the monthly run cost looks like at 10× the pilot's volume.

    Questions to ask before signing

    1. What exactly is in phase one, and what did you deliberately leave out?
    2. Which parts are configuration and which are custom build?
    3. Which systems do you need to integrate with, and which lack a usable API?
    4. Who owns this internally after go-live, and what training do they get?
    5. What are the estimated monthly running costs at real volume?
    6. What is the kill criterion — the number this has to hit to continue?

    A partner who answers all six plainly is giving you a real estimate. A single flat price with none of these answered is giving you a number.

    Frequently asked questions

    Why won't anyone give me a price from a short brief? Because the brief usually describes the ambition, not the five drivers. Until integration and adoption are scoped, any number is a guess.

    Is a paid discovery phase worth it? When the workflow can't be described in five minutes, yes. It is the cheapest place to find out a use case isn't worth building.

    What is usually the biggest hidden cost? Integration with systems that lack a clean API, followed by adoption work that was left out of the proposal.

    Do running costs matter at pilot stage? Yes. Ask for the monthly cost at ten times the pilot's volume before you commit to scaling.

    Keep reading

    How we scope it

    We start with a short mapping and prioritization phase that produces a scored use-case list, a build-vs-buy call per opportunity, and an integration inventory — so the build phase is quoted against a defined scope rather than an ambition. Pricing depends on scope, so we discuss it directly: info@braightwave.com.

    Turn ideas into action

    If any of this hit home — let's talk about applying it to your team.

    Talk to us