AI project done right: the three patterns that hold up

A well-built AI project is recognizable by three choices made before the first line of code is written: an architecture pattern suited to the need — direct model calls, RAG, or agents —, an investment in data quality greater than the one devoted to model selection, and a staged progression that validates before it industrializes. A poor start costs months of delay and tens of thousands of francs. A good start doesn't show: the project keeps evolving without drama for years.

Three patterns cover most projects

The apparent diversity of AI projects boils down, in practice, to very little. In 2026, three architecture patterns cover the vast majority of enterprise AI projects: direct API calls to a model, RAG that grounds answers in internal documents, and agents that execute multi-step tasks. Identifying which one fits your use case is the single most consequential technical decision of the scoping phase.

Direct API calls are the simplest pattern: the model is queried through its programmatic interface, and business logic is built around it. No dedicated infrastructure, cost proportional to usage, a working prototype in a few days. It suits moderate volumes and generic tasks — summarization, classification, standard content generation. Its weakness: dependence on a single vendor, in a market where price-performance ratios shift constantly. The fix is well known and inexpensive — an abstraction layer that isolates business logic from the vendor, so you can switch without rewriting the application. This precaution looks superfluous in the first month; it's worth its weight in gold the first time you change models.

RAG — Retrieval-Augmented Generation — has become the standard as soon as the system needs to know your data. Company documents are indexed as vectors; for each question, the most relevant segments are retrieved and fed to the model, which answers based on them, with citable sources. This is the structural answer to hallucinations: grounded in verified documents, the system stays factual — and can admit when it doesn't know. I detail the mechanics and conversational uses in can a chatbot really serve your customers?.

Agents form the next level of complexity: a system capable of using tools — search, calculations, API calls, databases — and planning a sequence of actions. This is the pattern for multi-step workflows: checking a status in one system, deciding, updating another system. Its power comes with two trade-offs: demanding debugging, and a high running cost — dozens of model calls for a single task. I reserve it for cases where the automated value clearly justifies that bill.

Why your data matters more than the model

The most common mistake is to focus attention on model selection — which vendor, which version, which benchmark — when data quality disproportionately determines the quality of the outcome.

Three lines of reasoning support this hierarchy. First, on projects grounded in company data — the majority of serious projects — the gap between the leading models on the market is modest compared with the gap produced by the state of the indexed documents: a clean data set on an average model regularly beats a messy data set on a top-tier model. Second, investment in data is cumulative: cleaned and structured documents serve every subsequent use, whereas the choice of model has to be revisited with every market shift. Third, projects that get stuck almost always share the same trait — an underestimated data-preparation effort, discovered too late.

FiscalDoc reminded me of this on a small scale. The value of this local application doesn't come from the model running underneath it: it comes from the structure — cleanly defined Swiss tax categories, a strict naming convention, a database indexed for search. The model is interchangeable. The structure is the asset.

The five costliest mistakes

Some mistakes recur with a regularity that warrants a list — here it is, in decreasing order of damage:

1. Starting with fine-tuning. Additional model training is rarely necessary as a first move: a well-built RAG produces equivalent results for a fraction of the cost. It's only justified for a very particular style or vocabulary that RAG doesn't cover.
2. Neglecting the data. The previous point already showed the mechanism; this is the most consequential mistake.
3. Skipping systematic evaluation. Without a reference set — a few dozen human-validated question-answer pairs — there's no way to measure progress. It's the best-return investment in the whole project.
4. Underestimating production costs. A lean prototype can become expensive once exposed to real users; the forecast — users, frequency, request size — belongs in the scoping phase, not on the first bill.
5. Building a monolith. Search, model, cache, interface, and evaluation welded into a single block make any evolution risky. A modular architecture costs little upfront and preserves the ability to replace one component without touching the others.

Where to start? The progression that works

For a Swiss SME, the difference between projects that succeed and those that stall largely comes down to sequencing. First the exploration phase: a direct model call, a precise and measurable use case, a few weeks. Its modesty is its strength — contained investment, immediate learnings, a real margin for error. Then the enriched prototype: a RAG built on your data, systematic evaluation, first internal users, over a few months. Finally production, with what makes it durable: organized user feedback, continuous prompt improvement, ongoing maintenance of the document base.

Agents and any eventual fine-tuning come after the production launch, based on real observations — never on assumptions. This discipline of waiting separates projects that build value from those that stack up complexity. It's the progression I apply in my custom solutions, and it holds regardless of the provider: a project that claims it can skip the exploration phase deserves your skepticism.

Where does your data go? Three levels of sovereignty

As soon as a project touches data covered by the FADP^[1] or sector-specific obligations, the question of data location belongs in the scoping phase. Three approaches structure the practice, in order of increasing constraint. Contractual non-retention commitments, negotiable with major vendors for their enterprise offerings, cover most cases where data is sensitive without being critical. Hosting on Swiss or European infrastructure guarantees data never leaves the jurisdiction — the path for explicit regulatory or contractual requirements. Deploying open models on controlled infrastructure, finally, keeps everything inside the company, at the cost of real technical skill and hardware investment — FiscalDoc is the proof of concept at the scale of a single person: an open-source model on my Mac, zero data leaving the building.

For strictly regulated sectors — finance, healthcare, government — a formal risk analysis during scoping avoids costly course corrections midway through.

At bottom, sound AI architecture isn't expertise out of reach for non-technical decision-makers; it's a discipline: the right pattern for the right need, data before the model, modularity before speed, sovereignty addressed explicitly. This framework fits into the broader approach I describe in What should a Swiss SME do about AI in 2026? — and it holds up project after project in my engagements.

Key takeaways

— Three patterns cover most AI projects in 2026: direct API calls, RAG grounded in your documents, multi-step agents — scoping starts with this choice. — Data quality outweighs model choice: a clean data set on an average model beats a messy data set on a top-tier model. — Progress in stages — exploration, evaluated prototype, monitored production — and reserve agents and fine-tuning for after launch.

FAQ

Should I train a model on my company's data? Rarely, and never as a first move. A well-built RAG — your documents indexed, retrieved, and fed to the model for every question — delivers equivalent results for a fraction of the cost and effort. Fine-tuning is only justified for a very specific style or vocabulary, after pushing RAG to its limits.

Which model should I choose to get started? Less decisive than people think. The gap between the leading models on the market is modest compared with the effect of your data quality. The sensible choice: a mainstream model, behind an abstraction layer that lets you switch without rewriting the application — the market moves too fast to lock yourself in.

How long before a first useful result? A well-scoped exploration phase — a precise use case, a direct model call — delivers its lessons within a few weeks. The prototype grounded in your data then takes a few more months, evaluation included. Be wary of promises of full deployment in fifteen days, as well as of projects that plan eighteen months before the first user test.

How do I guarantee my data stays in Switzerland? Three levels exist, in order of increasing constraint: contractual non-retention commitments with the model vendor, hosting on Swiss or European infrastructure, or deploying an open model on your own infrastructure. The right level depends on the actual sensitivity of the data processed — it's a scoping decision, not a technical detail.

Is an AI project taking shape at your company? The AI Usage Diagnostic: sixty minutes to map your real workflows, identify what deserves a custom build, what stays in SaaS, and what doesn't need AI at all. Book a diagnostic

Sources

[1] Federal Act on Data Protection (FADP), revision of 25 September 2020, entered into force on 1 September 2023. www.fedlex.admin.ch/eli/cc/2022/491/fr [↩]

Jérôme Deshaie is CEO and founder of MCVA Consulting SA, an augmented agency based in Valais. Fifteen years serving major international brands, now working directly with Swiss SMEs. Background.