In 2026, the issue isn't really "doing AI" anymore, but **delivering an AI capability** that integrates with your tools, respects your constraints (GDPR, security, AI Act), and above all **produces a measurable gain** (time, revenue, quality, risk). This is exactly where most projects...
In 2026, the issue is no longer really about "doing AI", but about delivering an AI capability that integrates with your tools, respects your constraints (GDPR, security, AI Act), and above all produces a measurable gain (time, revenue, quality, risk). This is exactly where most artificial intelligence development projects are decided, and where they fail.
This guide gives you an operational overview of the steps, real costs (TCO), and classic pitfalls for an SME or scale-up.
In a company, "AI development" covers several very different realities. Clarifying the type of solution avoids overestimating (or underestimating) effort, costs, and risks.
AI Solution Type | What it is | Frequent Examples | When it is relevant |
|---|---|---|---|
Generative AI (LLM) | A language model that produces text, code, summaries | Internal assistant, drafting, classification, extraction | When the work is mostly textual and repetitive |
RAG (AI + sources) | LLM + document retrieval (source of truth) | Assistant on document base, support, procedures | When reliability depends on your up-to-date documents |
Agent (actions) | LLM that plans and executes tooled actions | Support triage, CRM updates, multi-tool workflows | When you have repeatable and reversible actions |
"Classic" ML | Predictive/statistical models on structured data | Scoring, churn, simple forecasts | When you have historical data and need a score |
Augmented Automation | Workflows + rules + AI (hybrid) | Email routing, pre-filling, QA | When you want control and a quick ROI |
In the majority of SME/scale-up contexts, the best results come from a hybrid approach: a bit of determinism (rules, controls), an AI layer (LLM), sources (RAG), and actionable integrations.
To go further on production patterns, you can read: AI Integration in Enterprise: API, RAG, and Agent Patterns.
A successful AI project looks more like a mini-product than an experiment. The classic mistake is to start with the model or the tool, instead of starting with the workflow and measurement.
A good scoping often fits on one page, but it must be explicit:
Job-to-be-done: what precise task, at what frequency, for which role.
Main KPI: minutes saved per file, first contact resolution rate, processing time, conversion rate, error rate, etc.
Baseline: where you are today (otherwise, you won't prove anything).
Scope: what the AI does, and what it does not do.
Risk level: sensitive data, impactful decisions, audit requirements.
Field tip: if you can't formulate the KPI and the baseline in 30 minutes, you are not ready to develop. Start with a mini-audit.
Useful resource: AI Audit: Express Checklist for Quick Wins.
AI is probabilistic. Therefore, your product must define:
What constitutes an acceptable response (format, tone, length, sources).
What constitutes a failure (uncertainty, lack of sources, incoherence).
When and how we escalate to a human.
The level of traceability expected (logs, citations, justification).
Without a contract, you will judge the solution based on "feeling", and the team will exhaust itself in endless iterations.
The real work often hides here.
Source of truth: where the correct content lives (Notion, Drive, CMS, helpdesk, ERP, CRM).
Quality: duplicates, versions, obsolete pages, lack of structure.
Access: who has the right to read what (and how the AI respects these rules).
Personal data: minimization, legal basis, retention periods.
On compliance, keep a simple principle: governance proportionate to the risk, but never "we'll see later".
References: CNIL (GDPR guides), and the European framework AI Act (official text on EUR-Lex).
A robust AI architecture, even minimal, must answer four questions:
Where does the orchestration live (backend, gateway, platform)?
How does the AI retrieve reliable context (RAG, databases, APIs)?
How does the AI act (tools, internal APIs, reversible actions)?
How do we observe and control (logs, costs, tests, guardrails)?
If you use model APIs, the design must also anticipate variable costs and quotas.
Read: AI APIs: Guide to Pricing, Quotas, and Hidden Costs.
A useful prototype is not a shiny demo, it is a system that:
Runs on a representative set of cases (real, varied examples).
Produces scorable outputs (quality, accuracy, time, cost).
Logs what matters (prompts, sources, latency, errors, escalations).
It is also here that we decide the pattern: simple assistant, RAG, or agent.
The pilot must be short, controlled, and linked to a KPI. Examples of common controls:
Scope limits (domains, authorized intents).
Human-in-the-loop on sensitive actions.
Monthly API budget (caps, alerts).
Degraded modes (fallback, deactivation, alternative routing).
Without an explicit go/no-go decision, AI projects become a permanent cost line.
The production launch is often the most underestimated step:
Runbook: who does what in case of incident, rollback, support.
MCO (Operational Maintenance): updating sources, evolving prompts, drift.
Continuous evaluation: regular tests, quality monitoring.
Training: authorized uses, best practices, limits.
On agents, the run and guardrails part is even more critical: Autonomous Agents in Enterprise: Guardrails and Validation.
Step | Expected Deliverable | Passage Criteria |
|---|---|---|
Scoping | Use case, KPI, baseline, scope | Measurable KPI + sponsor + business owner |
AI Contract | Quality rules, failures, escalation | Defined and testable failure cases |
Data | Sources, rights, data rules | Controlled access + minimized data |
Prototype | Testable version + logs | Stable score on test set |
Pilot | Limited deployment + guardrails | KPI moves in real life (even modestly) |
Production | Runbook + monitoring + budget | Clear MCO/ownership + controlled costs |
In artificial intelligence development, the right reasoning is not "how much does the AI cost?", but how much does the AI capability in production cost.
We talk about TCO (Total Cost of Ownership): build + integration + run + adoption.
Item | Why it exists | Signs of underestimation |
|---|---|---|
Product Scoping | Without KPI/baseline, no credible ROI | "We'll see if it works" |
Data + Access | Quality and rights determine reliability | Obsolete docs, vague permissions |
Integrations | The AI must act within the workflow | Copy-paste, no tooled actions |
API Usage (variable) | Tokens, latency, quotas | Context explosion, no cache |
Evaluation and Observability | Measuring quality, costs, incidents | No logs, no reproducible tests |
Security and Compliance | AI = new attack surface | No prompt injection review, no DPIA when necessary |
Maintenance | Sources, prompts, models evolve | No owner, no ritual |
Adoption/Training | An unused AI has a negative ROI | "The teams aren't hooking on" |
Without getting into misleading ranges, you can estimate an order of magnitude by answering these questions:
Volume: how many requests per day/week, and by how many users.
Complexity: simple Q&A, multi-source RAG, multi-step agent.
Risk level: sensitive data, need for audit, impacts.
Integration level: read-only, or actions (CRM, ERP, helpdesk).
Run: who maintains sources, tests, incidents.
Then you split the project into two envelopes:
Setup costs: scoping, dev, integrations, security.
Recurring costs: API usage, observability, maintenance, support, continuous training.
If you use APIs, the most important point is to treat costs as a system to be managed, not as an invoice to be endured. The article AI APIs: Guide to Pricing, Quotas, and Hidden Costs details concrete levers.
Reduce context (summaries, clean chunking, useful citations).
Implement caching on frequent requests.
Route models (small model by default, large model on complex cases).
Batch asynchronous tasks when possible.
Set caps, alerts, and quotas per team.
The tool is rarely the problem. The real issue is the flow: where the AI intervenes, with what data, and what action it triggers.
Fix: Map 1 process, 1 owner, 1 KPI, and integrate from V1.
Without a baseline, you will have "enthusiastic feedback" but no proof. And you won't know how to arbitrate.
Fix: Measure beforehand (average time, volume, quality, error rate) over a short period.
A demo that works on 3 examples is worth nothing. A pilot, however, must survive the variety of reality.
Fix: Build a representative test set, then pilot on a limited group.
A RAG on a poorly maintained document base amplifies confusion instead of reducing support.
Fix: Define which sources are authorized, who maintains them, and how versions are managed.
Attacks like prompt injection, exfiltration via context, or unwanted actions exist.
Fix: Guardrails, filtering, secret isolation, action validation, and dedicated tests. Useful reference: OWASP Top 10 for LLM Applications.
If the user has to copy-paste or redo the task afterwards, you kill adoption.
Fix: Integrate at the right place (CRM, helpdesk, back-office), even minimally.
Without logs, you don't know how to fix. Without cost metrics, you don't know how to scale.
Fix: Observability from V1 (latency, error rate, cost per action, escalations).
The more autonomy increases, the more risks and operational debt rise.
Fix: Start with low autonomy, previewed actions, confirmations, and rollback.
If everything is coupled to a single model or platform, every evolution becomes costly.
Fix: Orchestration layer, stable contracts, planned reversibility.
Even an excellent AI fails if teams don't know when to use it, nor when to be wary of it.
Fix: Targeted training + usage charter + rituals (feedback, improvement, updates).
On structuring (roles, light governance), you can rely on: AI Organization: Roles, Governance, and Responsibilities.
Custom development is not always the answer. For an SME, the goal is to maximize ROI while minimizing risk.
Situation | Buy (tool) | Assemble (tools + integrations) | Build (custom) |
|---|---|---|---|
Standard need | Often the fastest | Useful if you need to connect 2-3 systems | Rarely necessary |
Sensitive data / strong constraints | Sometimes impossible | Possible with gateway and controls | Often justified |
Actionable integrations | Limited depending on the tool | Very relevant | Relevant if complex integrations |
Business differentiation | Low | Medium | High |
Traceability requirement | Variable | Good if well designed | Excellent if designed for it |
To decide rationally, this resource is useful: Custom AI Development: Criteria for a Rational Choice.
A sponsor and a business owner identified.
A frequent use case, close to cash (cost or revenue).
A main KPI, a baseline, and a definition of "success".
Identified sources of truth, with access rules.
An assessed risk level (GDPR, security, impacts).
An integration strategy (where the AI acts in the workflow).
A reproducible test plan (set of cases).
A run plan (maintenance, incidents, budget, monitoring).
An adoption plan (training, rules, feedback loop).
If you are looking for "artificial intelligence development", you are probably looking for one thing: avoid paying for a demo, and obtain an AI capability that holds up in production.
The most robust path for an SME or scale-up is generally:
A KPI-oriented scoping.
An instrumented prototype.
A short and controlled pilot.
Industrialization with guardrails, observability, and a runbook.
If you want to accelerate without burning budget, Impulse Lab supports this type of approach via AI opportunity audits, adoption training, and custom web and AI development (with integration into your tools). Recommended starting point: Strategic AI Audit: Mapping Risks and Opportunities or get in touch at Impulse Lab.
Our team of experts will respond promptly to understand your needs and recommend the best solution.
Got questions? We've got answers.
Leonard
Co-founder
