What an AI project actually costs in Tunisia in 2026

Search for what an AI project costs in Tunisia and you will get a fast answer. The guides published for Tunisian SMEs this year quote 2 000 to 15 000 dinars for a custom project, a chatbot or an automation, with a return visible around the third or fourth month. Subscription tools are priced separately, at 50 to 200 dinars per user per month.

Those numbers are not dishonest. They describe something real. The trouble is what they describe: a build, delivered once. The number that decides whether a project is worth starting is a different one. It is what the thing costs to run, every month, once it is carrying a process the business depends on.

Here is the arithmetic that shows the gap. A mid-level AI engineer in Tunisia earns roughly 60 000 to 110 000 dinars a year, and a senior one starts around 120 000. The entire published range for a custom project fits inside a single mid-level salary, with room to spare. That does not make the range wrong. It means the range was never priced to include the people who keep the system running.

The pilot is the cheapest phase, and that is the trap

A pilot is cheap because of what it is allowed to ignore.

It runs on data someone cleaned up. It runs at low volume, so the model bill is small. A person sits next to it and checks the output, which is why nobody has to build an automatic check. It does not write into anything that matters, so it needs no change request, no rollback plan and no audit record. A working prototype is a statement that the model can do the task. Everything that makes it expensive is still switched off.

Then the pilot succeeds, and the expensive part begins. That is the moment the questions change. Can we rely on it when we are not watching? What happens when it is wrong? Who finds out? Can we show, eighteen months from now, what it consulted and what it decided?

The uncomfortable consequence for anyone approving a budget: a cheap pilot is not evidence of a cheap system. It is evidence that the inexpensive part is inexpensive. The ITCEQ found that 71% of Tunisian companies stumble when integrating AI, and named limited funding, a shortage of digital skills and resistance to change. All three are symptoms of the same mistake, which is budgeting for the demonstration and then discovering that the operation is a separate purchase.

The four line items that never make it into the quote

These are the costs that appear after the pilot, and they are the reason the project range and the real cost diverge.

Integration. Connecting to a core banking system, an ERP or a claims platform is not a configuration step, and its price is set by the core, not by the model. A read-only nightly batch that nobody has to approve is cheap. A synchronous write into a system with a change committee is not, because every change has to be justified, scheduled and reversed if it goes wrong. Quotes usually say "we will integrate with your existing systems". What that costs depends entirely on how much control you have over the system you are integrating with.

Evaluation. Without a stored set of real cases and the answers a competent person would give, "it works well" is an opinion, and opinions do not survive a steering committee. Building that set is done by the people who know the process, not by the people who write the code, which makes it a scheduling and salary cost rather than a tooling cost. It also has to be rebuilt whenever the underlying process changes.

Provenance. For any process a regulator or an auditor cares about, the system has to record what it retrieved, which version of a document that was, what it was asked and what it produced. Captured while the system runs, this is a small amount of work. Retrofitted onto a system that never stored it, it is a project. This is the line item that turns a successful pilot into an unbudgeted second phase.

The runtime bill, and its shape. This is where the seat-based intuition fails. Model spend does not scale with the number of employees using the system. It scales with what they ask it, how often, and how much context each request carries. Two departments of the same size can differ by an order of magnitude.

Why seats are the wrong unit for a running cost

A licence is a predictable line. You know the headcount, you know the price, you multiply. AI usage does not behave like that, and the per-token price, which is the part everyone quotes, is the easy part to know.

The cost of a single request moves with things that are invisible to a procurement spreadsheet:

• Drafting the same request through a different provider can cut the cost by around 30%, for identical work.
• A repeated request that hits a cache can cost 60% less than the first one.
• Long context, retries and automatic fallbacks all add cost that never appears in a demo, because a demo does not fail.
• Some providers now charge a higher rate during peak hours, so the same task costs more at 10am than at 8pm.

What all of this argues for is one instrumented number, from the first day in production: cost per completed task. Cost per token is a figure nobody can put beside anything else, and cost per user is meaningless when usage is uneven. Cost per completed task is the only number a finance director can compare to the cost of doing the work by hand, and the only one that shows whether the system is getting cheaper or more expensive as it grows.

What to ask instead of the price

The published ranges answer one question. You need three, and they should be budgeted separately.

1. Build. The one-off cost of getting a working version into your environment. This is the smallest of the three over any horizon longer than a year.
2. Run. The recurring cost of inference, infrastructure and support at your real volume. Ask what it becomes at three times the volume, and treat a flat answer as a warning.
3. Own. The standing commitment to keep it accurate and defensible: someone who owns the outcome, a path for escalations, and the evidence an auditor or an inspector would ask for. Whether this is internal headcount or an external partner, it is a recurring line, and it is the line the published ranges leave out entirely.

A vendor who can only answer the first question is selling you a build. That may be exactly what you want, as long as nobody assumes the other two are included.

The three questions worth putting in writing before you sign:

• What does this cost to run at our volume, per month, once it is live?
• What happens to that number when usage triples?
• Who is accountable for the output in month thirteen, when the people who built it have moved on?

If the answers are vague, that tells you more than any budget figure will.

The decision in front of you

The cheapest way to control the total cost of AI is not to negotiate the build down. It is to choose the right first process, because almost every expensive surprise we see is a scoping decision that was made early and never revisited. A process with a handover to a human at every step is a different project, and a different budget, from one that has to run unattended.

That choice is worth an afternoon of honest assessment before anyone writes a proposal. It is also the part of the cost that is entirely within your control.

If you want a starting point, our readiness assessment scores where your organisation actually is, and process automation describes what happens once a first process is chosen.