AI-architectuur voor een bedrijf: ontwerp de kleinste beheersbare productieketen
Een AI-architectuur voor een bedrijf verbindt gebruikers, workflow, bronnen, modellen, integraties, controles, logging en beheer. Ontwerp vanuit de taak en risico’s, niet vanuit een leveranciersdiagram. Beperk componenten en rechten, maak modellen vervangbaar waar dat waarde heeft en test terugvalscenario’s. De beste architectuur is niet de meest geavanceerde, maar de eenvoudigste die kwaliteit, veiligheid en schaal aantoonbaar haalt.
Definitie en afbakening
AI-architectuur beschrijft componenten, gegevensstromen, verantwoordelijkheden en kwaliteitsgrenzen van een AI-oplossing. Zij omvat front-end, orkestratie, modellen, retrieval, tools, identity, security, observability en operationeel beheer. Een logisch ontwerp laat technologiekeuzes open; een fysiek ontwerp koppelt ze aan concrete producten en omgevingen. Beide moeten traceerbaar zijn naar bedrijfs- en risico-eisen.
Het herkenbare bedrijfsprobleem
Architecturen groeien tijdens pilots organisch. Elke fout krijgt een extra model, agent, database of controlelaag. De demo verbetert, maar latency, kosten en beheer nemen toe. Omdat niemand een baseline of verwijdercriterium heeft vastgelegd, blijft iedere component bestaan en wordt leverancierswissel later een kostbaar migratieproject.
Technische waarde ontstaat in een keten
Een technisch gemiddelde is niet genoeg. De activiteit ‘begin met eisen en grenzen’ kan sterk scoren terwijl het risico ‘iedere fout voegt permanent een component toe’ de keten toch onbetrouwbaar maakt.
Stappenplan voor een AI-architectuur voor je bedrijf
1. Begin met eisen en grenzen
Leg taak, volume, latency, kwaliteit, data, risico en beschikbaarheid vast. Koppel de stap ‘begin met eisen en grenzen’ aan meetbare kwaliteit, kosten en een herstelroute.
2. Teken gegevens- en actiestromen
Maak lezen, schrijven, opslag, logging en menselijke besluiten zichtbaar. Controleer voor de stap ‘teken gegevens- en actiestromen’ ook toegang, verwijdering en toekomstige wijzigingen.
3. Kies minimale componenten
Voeg alleen een model, retrievallaag of agent toe als een meetbaar tekort dat vraagt. Laat de stap ‘kies minimale componenten’ eindigen in een expliciet besluit over scope, investering en beheer.
4. Ontwerp identity en rechten
Laat gebruikerscontext en minimale bevoegdheid door de volledige keten werken. Benoem bij de stap ‘ontwerp identity en rechten’ de eigenaar, het bewijs en de grens voor doorgaan.
5. Plan fouten en terugval
Test uitval, onjuiste output, leveranciersproblemen, limieten en handmatige voortzetting. Leg voor de stap ‘plan fouten en terugval’ vast welke data en technische afhankelijkheid de uitkomst bepalen.
6. Bereken lifecycle en exit
Neem ontwikkeling, platform, gebruik, beheer, monitoring, migratie en afbouw mee. Test tijdens de stap ‘bereken lifecycle en exit’ gewone gevallen, uitzonderingen en foutieve invoer.
Beslismodel
| Beslispunt | Centrale vraag | Gewenst bewijs | Handelingsregel | |---|---|---|---| | Begin met eisen en grenzen | Leg taak, volume, latency, kwaliteit, data, risico en beschikbaarheid vast. | Testdata, eigenaar en meetrapport | Doorgaan bij gehaalde grens | | Teken gegevens- en actiestromen | Maak lezen, schrijven, opslag, logging en menselijke besluiten zichtbaar. | Architectuur-, risico- en kostenbewijs | Beperkt testen bij onzekerheid | | Kies minimale componenten | Voeg alleen een model, retrievallaag of agent toe als een meetbaar tekort dat vraagt. | Testdata, eigenaar en meetrapport | Herontwerpen of stoppen | | Ontwerp identity en rechten | Laat gebruikerscontext en minimale bevoegdheid door de volledige keten werken. | Architectuur-, risico- en kostenbewijs | Doorgaan bij gehaalde grens | | Plan fouten en terugval | Test uitval, onjuiste output, leveranciersproblemen, limieten en handmatige voortzetting. | Testdata, eigenaar en meetrapport | Beperkt testen bij onzekerheid | | Bereken lifecycle en exit | Neem ontwikkeling, platform, gebruik, beheer, monitoring, migratie en afbouw mee. | Architectuur-, risico- en kostenbewijs | Herontwerpen of stoppen |
Gebruik dit model niet als automatische totaalscore. Een rode grens voor veiligheid, privacy, rechtmatigheid of kritieke kwaliteit mag niet worden gecompenseerd door lagere kosten. Test de grootste onzekerheid eerst met de kleinste representatieve architectuur. Dat voorkomt dat infrastructuur wordt gekocht voordat waarde en beheerbaarheid zijn bewezen.
Praktijkvoorbeeld met invoer, berekening en uitkomst
Situatie
Een bedrijf vergelijkt een enkel-modelarchitectuur met een multi-agentontwerp voor offertevoorbereiding.
Invoer
Eenvoudige variant kost €55.000 bouw en €2.500 per maand. Multi-agent kost €105.000 en €6.500 per maand. In test stijgt eerste-keer-goed van 84 naar 89 procent bij 6.000 offertes.
Berekening
Meerprijs jaar één is €98.000. Vijf procentpunt kwaliteitswinst betreft 300 offertes. Dat is circa €327 extra kosten per extra eerste-keer-goede offerte vóór gevolgwaarde.
Uitkomst
De organisatie kiest de eenvoudige variant tenzij herstel- of omzetwaarde per extra correcte offerte aantoonbaar hoger is en het extra beheer acceptabel blijft.
Verbinding met de vijf lagen van de ROI-scan
Het risico ‘leverancierswissel is niet getest’ kan daarom een andere oorzaak hebben dan de eerste technische diagnose suggereert.
Lees ook Databronnen koppelen aan AI, AI-security checklist, AI-onderhoudskosten.
Scenario’s en opties
| Scenario | Wanneer passend | Investering | Vereist bewijs | |---|---|---:|---| | Eerst meten | Leg taak, volume, latency, kwaliteit, data, risico en beschikbaarheid vast. | Laag | Nulmeting en afgebakende testset | | Beperkte technische proef | Maak lezen, schrijven, opslag, logging en menselijke besluiten zichtbaar. | Middel | Kwaliteit, rechten, kosten en foutgedrag | | Gefaseerd naar productie | Voeg alleen een model, retrievallaag of agent toe als een meetbaar tekort dat vraagt. | Middel tot hoog | Gehaalde grens, monitoring en beheerbudget | | Niet bouwen of terugschalen | Iedere fout voegt permanent een component toe | Beperkt verlies | Vastgelegd besluit en eenvoudiger alternatief |
Risico’s en beheersmaatregelen
1. Iedere fout voegt permanent een component toe
Maak het risico ‘iedere fout voegt permanent een component toe’ zichtbaar met een vroeg signaal in data, systeem of workflow. Koppel de controle aan de stap ‘ontwerp identity en rechten’, wijs een bevoegde eigenaar aan en bepaal welke overschrijding tot beperking of herstel leidt.
2. Leverancierswissel is niet getest
Maak het risico ‘leverancierswissel is niet getest’ zichtbaar met een vroeg signaal in data, systeem of workflow. Koppel de controle aan de stap ‘plan fouten en terugval’, wijs een bevoegde eigenaar aan en bepaal welke overschrijding tot beperking of herstel leidt.
3. Autorisatie stopt bij de interface en niet bij bronnen
Maak het risico ‘autorisatie stopt bij de interface en niet bij bronnen’ zichtbaar met een vroeg signaal in data, systeem of workflow. Koppel de controle aan de stap ‘bereken lifecycle en exit’, wijs een bevoegde eigenaar aan en bepaal welke overschrijding tot beperking of herstel leidt.
4. De architectuur heeft geen operationele eigenaar
Maak het risico ‘de architectuur heeft geen operationele eigenaar’ zichtbaar met een vroeg signaal in data, systeem of workflow. Koppel de controle aan de stap ‘begin met eisen en grenzen’, wijs een bevoegde eigenaar aan en bepaal welke overschrijding tot beperking of herstel leidt.
Veelgestelde vragen
Wat hoort in een AI-architectuurdiagram?
Gebruikers, systemen, dataflows, modellen, tools, opslag, rechten, controles, logging, externe partijen en terugvalroutes.
Moet je meerdere modellen ondersteunen?
Alleen wanneer continuïteit, kwaliteit, kosten of onderhandelingspositie de extra complexiteit rechtvaardigen.
Wat is een AI orchestration layer?
Een laag die aanvragen, modellen, data, tools, regels en controles coördineert. Niet iedere eenvoudige toepassing heeft een aparte laag nodig.
Hoe voorkom je vendor lock-in?
Gebruik exporteerbare data, gedocumenteerde interfaces, gescheiden bedrijfslogica, contractuele exit en periodieke migratietests waar proportioneel.
Wie is eigenaar van de architectuur?
Techniek beheert het ontwerp; de businessowner blijft verantwoordelijk voor uitkomst en relevante risico-eigenaren keuren grenzen goed.
Bronnen en officiële documentatie
- NIST AI Risk Management Framework
- NIST AI 600-1, Generative AI Profile
- OWASP Top 10 for LLM Applications
- ISO/IEC 42001, AI-managementsystemen
Verder lezen
- AI data readiness beoordelen: is je organisatie klaar voor een betrouwbare implementatie?
- Datakwaliteit voor AI-implementatie: meet wat de use-case werkelijk nodig heeft
- Data governance voor AI: eigenaarschap, toegang en kwaliteit bestuurbaar maken
- Databronnen voor AI inventariseren: van verspreide bestanden naar een beslisbaar overzicht
- Kennisbank voor AI voorbereiden: bronnen opschonen zonder eindeloos dataproject