Praktische technologie boven hype

De IT-wereld verandert snel. Nieuwe cloud-platformen, AI-oplossingen en SaaS-diensten verschijnen in hoog tempo. Veel van deze oplossingen bieden voordelen, maar brengen ook nieuwe afhankelijkheden en risico's met zich mee.

Denk aan:

• vendor lock-in
• beperkte controle over data
• stijgende operationele kosten
• te veel functionaliteit
• privacyvraagstukken
• complexe softwareketens die steeds moeilijker beheersbaar worden

Wij geloven daarom niet in een one-size-fits-all aanpak.

Soms is een Europese leverancier de betere keuze. Soms is een cloudoplossing logisch. En soms is een lokale of self-hosted oplossing juist het meest passend.

Technologie moet aansluiten op de organisatie — niet andersom.

Privacy en transparantie als uitgangspunt

Organisaties krijgen steeds vaker te maken met vragen rondom:

• gegevensbescherming
• data locatie
• compliance
• AI-gebruik
• afhankelijkheid van buitenlandse platformen

PaTech Solutions kijkt daarom bewust naar:

• transparante technologie
• Europese hosting waar passend
• open standaarden
• oplossingen waarbij organisaties grip houden op hun eigen digitale omgeving

Niet vanuit ideologie, maar vanuit praktische en duurzame IT-keuzes.

AI moet beheersbaar blijven

Kunstmatige intelligentie biedt enorme mogelijkheden, maar roept tegelijkertijd nieuwe vragen op.

Waar wordt data verwerkt? Welke modellen worden gebruikt? Welke informatie verlaat de organisatie? Hoe afhankelijk wordt een organisatie van externe AI-platformen? Betaal ik niet met mijn data?

Wij onderzoeken en implementeren daarom ook lokale en hybride AI-oplossingen, waarbij organisaties meer controle houden over:

• data
• infrastructuur
• kosten
• prestaties
• integraties

Denk bijvoorbeeld aan lokale LLM's, AI-workstations, self-hosted AI-assistenten, retrieval- en knowledge-systemen, en AI-workflows die binnen de eigen infrastructuur draaien.

Duurzame architectuur

Een goede technische oplossing moet niet alleen vandaag werken, maar ook over enkele jaren nog logisch, onderhoudbaar en betaalbaar zijn.

Daarom kijken wij niet alleen naar functionaliteit, maar ook naar:

• beheerbaarheid
• schaalbaarheid
• beveiliging
• energieverbruik
• documentatie
• automatisering
• toekomstige uitbreidbaarheid

Complexiteit toevoegen is eenvoudig. Complexiteit beheersbaar houden is de echte uitdaging.

Waar wij waarde aan hechten

Er zijn grofweg twee soorten MKB-organisaties op dit moment. De ene wil "iets met AI" maar weet niet waar te beginnen. De andere gebruikt AI eigenlijk al — via tools die medewerkers zelf hebben aangezet, vaak zonder beleid, zonder overzicht en zonder dat iemand de risico's bewaakt. Voor allebei is het startpunt hetzelfde probleem: geen helder beeld van waar je staat.

Een AI Readiness Scan lost dat op. In twee weken krijg je een nuchtere nulmeting: waar staat je organisatie écht, welke kansen leveren daadwerkelijk iets op, en — net zo belangrijk — welke risico's loop je nu al zonder het te weten. Geen hype; een concreet actieplan dat je meteen kunt uitvoeren.

Wat is het?

Geen implementatietraject en geen verkooppraatje, maar een gestructureerd onderzoek naar de mate waarin jouw organisatie klaar is om AI en automatisering zinvol én verantwoord in te zetten. We kijken naar mensen, processen, data, techniek en risico's — en vertalen dat naar een prioriteitenlijst.

Wat we onderzoeken

• Organisatie & draagvlak — zijn mensen klaar voor verandering?
• Processen & herhaalwerk — wat kost nu onnodig veel tijd?
• Data & kwaliteit — is je data bruikbaar voor AI?
• Infrastructuur — welke systemen praten al met elkaar?
• Security & privacy — AVG, EU AI-Act en "shadow AI" in kaart.

AI die al onder de radar draait

Bij veel bedrijven wordt AI allang gebruikt — ChatGPT voor offertes, een AI-plugin in de mailbox, een tool die klantdata verwerkt. Meestal zonder afspraken. Dat heet shadow AI, en het is risicovoller dan het lijkt: bedrijfs- en klantgegevens belanden ongecontroleerd bij externe diensten, niemand weet welke tools waar draaien, en er is geen beleid dat aangeeft wat wel en niet mag. De scan brengt dit gebruik in kaart — vaak de eerste keer dat een organisatie het volledige plaatje ziet.

De risico's van géén beleid: AVG, AI-Act en je bedrijfsvoering

Zonder AI-beleid stapelen de risico's zich op, en die zijn niet vrijblijvend:

• AVG (privacy): verwerkt een AI-tool persoonsgegevens zonder grondslag, of buiten de EU, dan overtreed je de AVG. Boetes lopen op tot €20 miljoen of 4% van de wereldwijde jaaromzet, met daarbovenop meldplicht bij datalekken en aansprakelijkheid richting je klanten.
• EU AI-Act: sinds 2024 van kracht en gefaseerd van toepassing. Verboden toepassingen mogen al niet meer (boetes tot €35 miljoen of 7% van de omzet), en sinds begin 2025 geldt een AI-geletterdheidsplicht — je moet kunnen aantonen dat medewerkers voldoende kennis hebben van de AI die ze gebruiken. Voor risicovollere toepassingen komen er stapsgewijs strengere eisen bij.
• Bedrijfsvoering: los van boetes raakt het je continuïteit — reputatieschade bij een incident, verlies van klantvertrouwen, en het risico dat je een tool moet uitzetten waar processen inmiddels van afhankelijk zijn geraakt.

De scan vertaalt dit naar een concreet beeld: welke tools raken de AVG, waar zit je blootstelling aan de AI-Act, en wat pak je als eerste aan.

Wat je na twee weken hebt

• Een readiness-score die laat zien waar je staat.
• De 3–5 kansen met de hoogste tijd- en kostenbesparing — vaak op plekken die je niet verwacht.
• Een overzicht van je huidige AI-gebruik en de risico's (AVG, AI-Act, shadow AI), helder benoemd en geprioriteerd.
• Een geprioriteerde roadmap die je zelf kunt oppakken, of samen met ons.

Lite of Deep?

Voor kleinere organisaties geeft de Lite Scan in één week een snel overzicht met een stoplichtmodel en de top 3 kansen. De Deep Scan gaat dieper op alle vijf onderdelen in en levert een 90-dagenroadmap. Wil je de nadruk op compliance, dan verdiept de Security-module het AVG- en AI-Act-beeld.

Voor wie is het zinvol?

Voor elke MKB-organisatie die AI serieus neemt. Nog niet begonnen? Dan voorkomt de scan dat je start bij de verkeerde dingen. Al (informeel) aan de slag? Dan krijg je grip op wat er draait en dek je de risico's af vóórdat ze een probleem worden.

Wat is Honcho?

Honcho is een zelf te hosten geheugenlaag voor AI-assistenten, ontwikkeld door Plastic Labs. Het koppelt aan een AI-gateway (zoals Hermes) en slaat sessieberichten op in PostgreSQL. Op de achtergrond verwerkt de deriver die sessies naar observaties, en consolideert Dream die observaties naar peer-representaties — een samenhangend beeld van de gebruiker, opgebouwd over tijd.

De Honcho API is uitgebreid en goed gedocumenteerd via Swagger UI. Maar voor dagelijks gebruik wil je niet elke keer curl-commando's typen om te zien wat je AI heeft onthouden.

Het dashboard

Het Honcho Memory Dashboard is een lichtgewicht Python webapplicatie — één bestand, geen externe dependencies buiten de standaardbibliotheek. Het draait als een lokale webserver op poort 8080 en biedt een overzichtelijke interface voor de vier Honcho-datalagen.

Overzicht

De startpagina toont in één oogopslag:

• Queue-status — hoeveel sessies staan er klaar voor verwerking, hoeveel zijn al verwerkt
• VRAM en modellen — welke Ollama-modellen zijn geladen, hoeveel GPU-geheugen is in gebruik
• Peer-samenvatting — een preview van de representaties van alle bekende peers

Sessies

Een lijst van alle opgeslagen sessies, klikbaar naar de volledige berichtconversatie. Berichten zijn gepagineerd en tonen peer-ID, tijdstip en tokencount. Vanuit de sessiepagina kun je een sessie verwijderen of een reeks berichten verwijderen (bijvoorbeeld om gevoelige informatie te wissen).

Geheugen

Alle observaties en conclusies die Honcho heeft opgeslagen, gefilterd op observer en observed. Zo zie je exact wat de deriver heeft geëxtraheerd en wat Dream heeft afgeleid. Een semantische zoekfunctie maakt het mogelijk om gericht te zoeken in het geheugen.

Peers

De volledige peer-representatie per gebruiker, inclusief de context per observer. Zo zie je niet alleen wat het systeem over jou denkt, maar ook vanuit welk perspectief — wat jij hebt verteld versus wat de AI heeft afgeleid.

Installatie

Het dashboard is losstaand te gebruiken — het enige wat nodig is een werkende Honcho-instantie en Python 3.

# Download het script
curl -O https://github.com/patech-solutions/honcho-dashboard/raw/main/honcho-dashboard.py

# Starten (standaard: Honcho op localhost:8000, dashboard op :8080)
python3 honcho-dashboard.py

# Of met aangepaste instellingen
HONCHO_URL=http://localhost:8000 \
HONCHO_WORKSPACE=mijn-workspace \
DASHBOARD_PORT=8080 \
python3 honcho-dashboard.py

Bereikbaar op http://localhost:8080.

Als je Honcho draait via Docker Compose is het eenvoudig toe te voegen als systemd user service zodat het automatisch start:

[Unit]
Description=Honcho Memory Dashboard
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/python3 /pad/naar/honcho-dashboard.py
Environment="HONCHO_URL=http://localhost:8000"
Environment="HONCHO_WORKSPACE=mijn-workspace"
Environment="DASHBOARD_PORT=8080"
Restart=always

[Install]
WantedBy=default.target

Waarom geen Swagger UI?

Honcho levert Swagger UI mee op /docs. Dat is handig voor API-exploratie, maar onpraktisch voor dagelijks gebruik: je moet endpoints kennen, JSON handmatig samenstellen en resultaten interpreteren.

Het dashboard heeft een ander doel: snel antwoord geven op praktische vragen.

• Wat weet mijn AI-assistent over mij?
• Zijn er hallucinaties in de deductieve conclusies?
• Welke sessies zijn al verwerkt, welke staan nog in de queue?
• Hoeveel GPU-geheugen is in gebruik?

Dat zijn vragen die dagelijks opkomen bij actief gebruik van een lokale AI-stack. Het dashboard maakt ze beantwoordbaar zonder technische omwegen.

Open source

Het dashboard is beschikbaar op GitHub onder een MIT-licentie. Bijdragen zijn welkom — of het nu gaat om nieuwe features, bugfixes of ondersteuning voor andere Honcho-configuraties.

Geschikt voor iedereen die Honcho gebruikt als geheugenlaag voor een lokale of self-hosted AI-assistent.

De stack

Alles draait self-hosted op een Windows-werkstation met WSL2, een NVIDIA GPU met 12 GB VRAM en 32 GB RAM.

Component	Rol
Ollama	Lokale LLM-inferentie op de GPU
qwen3:14b	Het taalmodel (~9,3 GB VRAM, Q4_K_M)
Hermes	Agent gateway via Matrix chat
Honcho	Persistente geheugenlaag (Docker)
nomic-embed-text	Embedding model voor semantisch zoeken (~0,6 GB VRAM)

Het model communiceert via Matrix — dezelfde open standaard als Element. Je chat gewoon in een berichtenapp, de rest gebeurt op de achtergrond.

Wat is Honcho?

Honcho is een open source geheugenlaag voor AI-assistenten, ontwikkeld door Plastic Labs. Het slaat geen losse berichten op als platte tekst, maar bouwt gestructureerde kennis op over de deelnemers in een gesprek — peers genaamd.

Deriver — verwerkt sessieberichten na 15 minuten inactiviteit en extraheert observaties. Automatisch, zonder dat je iets hoeft te doen. De observaties zijn concreet en feitelijk: "pascal gebruikt Vikunja voor taakbeheer", "pascal geeft de voorkeur aan bondige antwoorden".

Dream — consolideert observaties naar peer-representaties via inductieve en deductieve redenering. Pas als een collectie 50 expliciete observaties heeft bereikt en er 30 minuten inactiviteit is geweest (minimaal 4 uur na de vorige cyclus). Dream bouwt een samenhangend beeld op van wie de gebruiker is en wat er toe doet.

Het resultaat: bij elke nieuwe sessie wordt automatisch relevante context geladen, zonder dat je het hoeft te vragen.

Wat hebben we getest?

We hebben een gestructureerd testprotocol uitgevoerd over twee dagen:

1. Contextopbouw — feitelijke informatie aanleveren in vijf prompts: identiteit, technische stack, werkwijze, lopend project, afsluiting
2. Wachten — 15 minuten voor de deriver, daarna uren voor Dream
3. Verificatie — in een nieuwe sessie testen of de informatie correct is onthouden, zonder hallucinaties

De hallucination check is bewust streng: we vragen naar informatie die niet is aangeboden (leeftijd, woonplaats). Als het model die verzint, is het direct afgekeurd.

Resultaten: deriver

De deriver werkt. Na een enkelvoudige contextsessie had het model in de volgende sessie toegang tot alle aangeboden informatie — correcte naam, rol, bedrijf, tools, werkwijze en stijlvoorkeur.

De hallucination check slaagde: "Hoe oud ben ik en waar woon ik?" — het model antwoordde correct dat dit niet bekend is, en somde op wat het wél wist.

Twee bijzonderheden:

• Stijl wordt direct toegepast. Na "ik prefereer bondige, directe antwoorden" paste het model dat toe in hetzelfde bericht. Geen herhaling, geen uitleg. Gewoon korter.
• Context sijpelt soms door. Als eerder testprotocol-materiaal nog actief in VRAM zit, kan dat nieuwe prompts kleuren. Lost zich op naarmate de sessie vordert — geen structureel probleem.

Resultaten: Dream

Dream heeft alle vier collecties verwerkt. De expliciete observatielaag is betrouwbaar — wat daadwerkelijk is aangeboden, staat er correct in.

De deductieve laag is kwetsbaarder. We zagen hallucinaties in de pascal→atlas collectie: verzonnen deadlines, een niet-aangeboden compliance-audit als prerequisiet, en een fictieve VRAM-rapportage. Geen van die details waren aangeboden.

Wat is er aan de hand? Dream maakt geen onderscheid tussen twee typen observaties:

• Feitelijke gebruikersuitspraken ("Pascal gebruikt Gitea voor versiebeheer")
• Intentie-uitspraken van de AI zelf ("Atlas is van plan een rapport te leveren")

De deriver extraheert beide kanten van het gesprek. Als de AI suggestieve of vooruitblikkende antwoorden geeft, worden die als gelijkwaardige feiten opgeslagen. Dream's deductieve redenering bouwt daar bovenop — en voegt specificiteit toe die er niet in zat.

Dit is een procesbeperking, geen modelprobleem. Dream heeft geen verificatiestap. Een groter model zou conservatiever zijn, maar het structurele risico blijft bij speculatieve invoer.

Mitigatie is simpel: houd contextsessies feitelijk. Stel geen open vragen die de AI aanzetten tot plannen of aankondigingen. De expliciete observatielaag blijft dan betrouwbaar.

Na Dream was de context bij verificatie aantoonbaar rijker dan na de deriver alleen. Het model noemde spontaan de evaluatiedoelen van qwen3:14b bij een vraag over communicatiestijl — een verband dat niet expliciet was gelegd, maar correct was afgeleid.

De VRAM-grens

De volledige stack — qwen3:14b plus nomic-embed-text — past nét binnen 12 GB VRAM. Er is geen ruimte meer voor een groter model, parallelle inferentie, of uitgebreidere context.

Dat is de harde grens van deze hardware. Wie meer kwaliteit, nauwkeurigheid of specialisatie wil, moet investeren in meer hardware of overstappen op externe API's. Die keuze heeft een prijs: API-gebruik betekent data buiten eigen beheer — een afweging die voor veel organisaties relevant is zodra privacy, gegevensbeheer en digitale soevereiniteit een rol spelen.

Een bijzonderheid van WSL2: ondanks OLLAMA_KEEP_ALIVE=-1 geeft WSL2 GPU-geheugen terug aan het host-OS na langere inactiviteit. ollama ps kan het model nog als geladen rapporteren terwijl Windows Performance Monitor 0 GB toont. Na een lange pauze is een cold start van 1-3 minuten reëel.

Conclusie

qwen3:14b met Honcho deriver en Dream is geschikt als persoonlijk AI-assistent voor dagelijks gebruik, met drie randvoorwaarden:

1. Contextsessies zijn feitelijk — geen speculatieve plannen of vooruitblikkende vragen
2. Na Dream: gebruik expliciete persoonsverwijzingen ("Wie is Pascal?" i.p.v. "Wie ben ik?")
3. Reken op cold starts na langere inactiviteit

Het is geen onfeilbare codeerassistent, geen duizendpoot en geen honderd procent correcte agent. Die combinatie bestaat trouwens nergens — het is een utopie, ongeacht het hardware-budget. Maar als persoonlijk assistent die context opbouwt, feitelijke vragen beantwoordt en meedenkt bij onderzoek, documentatie en scripting: het werkt.

Self-hosted, lokaal, geen data buiten de deur. Dat was het doel.

Als IT-architect werk je dagelijks met principes, beslissingen en requirements. Je weet hoe het hoort: alles gedocumenteerd, traceerbaar, onderling verbonden. Maar in de praktijk belanden die afspraken in een Word-document op een netwerkshare die niemand meer opent, in losse Confluence-pagina's zonder structuur (of aan elkaar gelinkt met een opzet waar weken aan energie ingestopt wordt), of erger — alleen in de hoofden van de mensen die ze hebben gemaakt.

We hadden hetzelfde probleem bij PaTech Solutions. We gebruikten Outline als wiki, maar het miste de structuur die hoort bij een echte Architecture Repository: typering van items, review workflows, relaties tussen beslissingen en principes, een audit trail. We zochten naar tooling die dat bood zonder de enterprise-prijskaart van MEGA, Alfabet of BiZZdesign.

Die tooling bestond niet in het segment dat voor ons interessant was. Dus bouwden we het zelf.

Wat we nodig hadden

Een Architecture Repository is geen complexe applicatie. De kernfunctie is simpel: gestructureerde opslag van architectuurafspraken, met de mogelijkheid om ze te verbinden, te reviewen en te exporteren.

Vijf entiteitstypen doen het meeste werk:

• Principes — de leidende uitspraken die je architectuur sturen
• Requirements — functionele en niet-functionele eisen
• Beslissingen (ADRs) — Architecture Decision Records, met context, keuze en gevolgen
• Uitzonderingen — bewuste afwijkingen op principes, tijdgebonden en verantwoord
• ArchiMate-modellen — visuele representaties van de architectuur

Wat we ook nodig hadden: een review workflow. Beslissingen moeten niet door één persoon worden genomen. Er moet iemand zijn die accordeert, en dat proces moet zichtbaar zijn in het systeem — niet in een e-mailketen.

Hoe we het bouwden

We kozen bewust voor een lichte technologiestack: TypeScript, Fastify, React, PostgreSQL. Geen framework-overhead, geen vendor lock-in, volledig op Europese servers. De applicatie is opgebouwd als een gehoste SaaS — per klant een eigen instantie, eigen database, volledig geïsoleerd.

De eerste versie draaide intern bij PaTech Solutions binnen een paar weken. We gebruikten het zelf om de architectuurprincipes, ADRs en uitzonderingen die we tot dan toe in Outline bijhielden te structureren. Dogfooding op zijn best, of een walk the talk.

Wat we al snel merkten: de structuur dwingt je tot betere architectuurbeslissingen. Als je een uitzondering moet vastleggen met een verloopdatum en een verantwoordelijke eigenaar, denk je er twee keer over na voordat je er een aanmaakt. Als een ADR pas in productie gaat na review door een approver, worden beslissingen explicieter.

Wat Atlas nu kan

• Vijf entiteitstypen met velden die aansluiten op enterprise architectuurstandaarden
• Review workflow met approver-rollen
• Relaties tussen items — een requirement gekoppeld aan het principe dat hem rechtvaardigt
• Audit trail op alle mutaties
• Importeren en exporteren (JSON/CSV)
• Gebruikersbeheer met rolgebaseerde toegang
• OIDC/SSO integratie voor organisaties met een eigen identity provider

Waarom we het als product aanbieden

We hebben iets gebouwd dat werkt, dat we zelf gebruiken, en waarvan we zeker weten dat meer architectuurteams het nodig hebben.

De doelgroep is niet de grote onderneming met een BiZZdesign-licentie en een dedicated EA-afdeling. De doelgroep is het architectuurteam van een paar personen bij een gemeente, een consultancybureau of een scale-up dat serieus met architectuur bezig is maar niet de middelen heeft voor enterprise-tooling. Of MKB-bedrijven waarbij wij al diensten leveren.

Met Atlas heb je een werkende, hosted Architecture Repository — inclusief hosting in Europa, dagelijkse backups en updates. Geen eenmalige licentie, geen implementatieproject, geen consultants die je uitleggen hoe je het moet gebruiken.

Probeer het zelf

De demo-omgeving staat open en is gevuld met voorbeeldcontent. Vul hem niet met jouw echte data — het is een gedeelde omgeving die regelmatig wordt gereset.

Wil je een eigen instantie, heb je vragen over hoe Atlas past bij jouw architectuurpraktijk, of heb je ideeën over features? Neem contact op via het contactformulier of bekijk de productpagina op atlas-ar.nl.

Vraag een team waarom een systeem is gebouwd zoals het is gebouwd, en je krijgt zelden een goed antwoord. De beslissing zit in iemands hoofd, in een oude Slack-draad, of nergens meer. Met AI-ondersteunde ontwikkeling wordt dat probleem groter, niet kleiner: een architectuurkeuze die vroeger een vergadering en een week nadenken kostte, wordt nu in een paar minuten voorgesteld, besproken en geïmplementeerd. Sneller is goed — tenzij niemand meer kan navertellen waaróm iets zo is gebouwd zodra het schuurt, of een auditor ernaar vraagt.

Wat is een ADR?

Een Architecture Decision Record is een kort, gedateerd document per architectuurbeslissing: wat is het besluit, welk probleem lost het op, welke alternatieven waren er, en wat zijn de consequenties. Geen langdradig ontwerpdocument — een paar alinea's die over een jaar nog steeds uitleggen waarom iets is zoals het is.

We schreven eerder al over waarom we ons eigen Architecture Repository (Atlas AR) bouwden — dit artikel gaat over de andere kant: hoe we het zelf, dagelijks, gebruiken.

Dit doen we zelf, dagelijks

Onze eigen infrastructuur en producten — waaronder Atlas AR — groeien voor een groot deel met AI-ondersteuning: architectuurvoorstellen, code en configuratie komen mede tot stand met AI-assistenten naast een mens die beslist. Precies daarom hebben we er een harde regel van gemaakt: elke architectuurbeslissing krijgt een ADR, ongeacht of een mens of een AI-assistent het voorstel deed. Geen beslissing gaat door zonder vastgelegde rationale — ook niet als de implementatie tien minuten kostte.

De volledige cyclus — niet alleen het besluit vastleggen

• Ontwerpfase — toetsen aan wat er al staat. Voordat er iets nieuws wordt bedacht, wordt eerst gekeken naar de bestaande Principes en Requirements in het architectuurregister. Een nieuw ontwerp begint niet bij nul; het moet passen bij — of expliciet afwijken van — wat al is vastgelegd.
• Besluit — het ADR zelf. Het besluit wordt kort vastgelegd: keuze, alternatieven, consequenties. Niet verstopt in een chatgeschiedenis. Uitgebreidere ontwerpkeuzes krijgen een apart ontwerpdocument; het ADR blijft beknopt en verwijst ernaar.
• Bouw — controle en validatie tijdens het implementeren. Ook tíjdens het bouwen wordt getoetst aan de vastgelegde principes en requirements, niet alleen vooraf. Een wijziging die onderweg een principe zou schenden, gaat niet stilzwijgend door — die wordt óf aangepast, óf expliciet vastgelegd als tijdelijke, beargumenteerde uitzondering met een eigenaar en een einddatum.
• Guardrail voor mens, AI én automation pipelines. Dit register functioneert als guardrail voor iedereen en alles dat aan het systeem werkt — een mens die code reviewt, een AI-agent die een wijziging voorstelt of doorvoert, en een geautomatiseerde pipeline die een wijziging test en deployt, toetsen allemaal aan dezelfde vastgelegde principes en requirements. Een pipeline neemt diezelfde requirements gewoon mee in de tests — een wijziging die een vastgelegde eis schendt, faalt de build, in plaats van dat het pas bij een latere review opvalt. Niet als bureaucratie, maar als het geheugen dat een los gesprek nooit heeft — en dat, eenmaal geautomatiseerd, niemand meer kan overslaan.

Het resultaat: een architectuurregister dat een half jaar later nog steeds antwoord geeft op "waarom is dit zo?" — ook als degene die het besluit nam (mens of AI-sessie) allang niet meer beschikbaar is om het te vragen.

Waarom dit met AI-ontwikkeling belangrijker wordt, niet minder

De reflex is om te denken dat AI-snelheid en governance elkaar bijten — meer discipline betekent minder snelheid. In de praktijk is het omgekeerde waar: zonder vastlegging bouw je razendsnel een systeem op dat niemand meer kan uitleggen, en dat is precies waar AVG- en AI-Act-audits, of gewoon een nieuwe collega, vastlopen. Een lichtgewicht ADR kost een paar minuten; het ontbreken ervan kost je maanden later een archeologische zoektocht.

Wat dit oplevert voor klanten

Deze manier van werken is niet alleen intern beleid — het is de reden dat Atlas AR bestaat als product: een lichtgewicht architectuurregister waarmee MKB-organisaties hetzelfde kunnen doen zonder de overhead van enterprise-tooling. En het is exact het soort structuur dat we terugzien bij de AI Readiness Scan: organisaties die AI al gebruiken maar geen enkel besluit hebben vastgelegd, lopen tegen dezelfde risico's aan die deze manier van werken juist voorkomt.