Hoe wij AI-systemen bouwen

Het probleem met AI in productie

AI-systemen zijn grillig. Vraag een taalmodel om JSON te genereren en je krijgt de ene keer een perfect object, de andere keer een halve zin met wat accolades. Dat is leuk voor een demo, maar onbruikbaar in productie.

Wij hebben daar lang mee geworsteld. Tot we drie dingen ontdekten die het verschil maken.

1. Dwing structuur af

De oude manier: je vraagt een LLM om JSON met bepaalde velden en hoopt dat het klopt. Vervolgens schrijf je tientallen regels code om te checken of alle velden aanwezig zijn, of de types kloppen, of de waardes binnen bereik vallen. Defensieve code voor elke edge case die je kunt bedenken.

Onze aanpak: we definiëren vooraf exact wat we verwachten met Pydantic models.

class AnalysisResult(BaseModel):
    score: int = Field(ge=1, le=10)
    opportunities: List[Opportunity] = Field(min_length=3, max_length=3)
    summary: str

Het model moet nu output leveren die aan deze specificaties voldoet. Geen vage JSON meer, maar getypeerde objecten waar je IDE mee kan werken. Als de output niet klopt, krijg je een foutmelding — niet een subtiele bug die drie weken later opduikt.

Dit klinkt als een detail, maar het verandert alles. Opeens kun je AI-output behandelen als betrouwbare data. Je code wordt korter, je tests simpeler, je nachten rustiger.

2. AI is niet altijd het antwoord

Er is een vreemde reflex in de industrie om overal AI tegenaan te gooien. URL valideren? AI. Twee getallen optellen? AI. Een datum formatteren? AI.

Dat is duur, traag en onnodig. Een regex valideert een URL in microseconden. Een LLM doet er honderden milliseconden over en kost je geld per aanroep. Plus: de regex geeft altijd hetzelfde antwoord. Het taalmodel niet.

Ons principe is simpel: logica waar het kan, AI waar het moet. Bij onze Website Quickscan bijvoorbeeld gebruikt AI de content-analyse — daar is het briljant in. Maar de URL-validatie, het HTML-parsen, de data-opslag? Gewoon code. Sneller, goedkoper, betrouwbaarder.

Het resultaat is dat onze AI-kosten alleen gaan naar waar het écht waarde toevoegt. De rest doet gewone software, zoals het hoort.

3. Eigenaarschap over je stack

Vendor lock-in is een reëel risico. Je bouwt een systeem op een cloud-dienst, en twee jaar later verdubbelen ze de prijzen of verdwijnt de feature die je nodig hebt. We hebben het zien gebeuren.

Daarom kiezen we waar mogelijk voor open source: Crawl4AI voor web scraping, FastAPI als backend framework, PostgreSQL voor data, Pydantic voor validatie. Geen lock-in, volledige controle, en een community die de code blijft onderhouden.

Voor hosting werken we met soevereine cloud providers. OVHcloud voor Europese data, Azure Nederland waar nodig, of volledig on-premise als de situatie dat vraagt. Data blijft waar het hoort te blijven.

Voor een juridische klant betekende dit: opslag en AI-processing via Azure's Europese endpoints, en een volledig open source codebase. GDPR-compliant zonder concessies aan functionaliteit.

Waarom dit ertoe doet

Deze drie principes — gestructureerde outputs, selectief AI-gebruik, en soevereine technologie — zijn geen academische idealen. Ze komen voort uit projecten die faalden en projecten die slaagden.

Het verschil tussen een AI-demo en een AI-systeem in productie zit hem in dit soort keuzes. De demo mag grillig zijn. Het systeem waar je bedrijf op draait niet.