Deep Dive: Architectuur van de Externe Intake-Applicatie & API¶

Datum: 13 maart 2026 Onderwerp: Blauwdruk voor het scenario waarbij de privacygevoelige (red zone) intakeapplicatie buiten BORIS valt en eigendom is van de leverancier van het cliëntsysteem. Hoe verbinden we dit via een data-gescrubte API met de intelligente, maar privacy-gelimiteerde AI van BORIS?

1. De Strategische Keuze: "Privacy by Isolation"¶

Deze denkweg is bestuurlijk en juridisch (avg) gezien de absolute koningsroute. Door BORIS géén eigenaar te maken van de daadwerkelijke naam, adres en BSN-gegevens ("de identificerende schil"), vermijd je het zwaarste privacyrisico rondom LLM's en cloud-architecturen.

We creëren hiermee een Split-Brain Architectuur: * De Formele Kant (Het Cliëntsysteem & Externe App): Bevat PII (Persoonlijk Identificeerbare Informatie), identiteit, BSN, en wettelijker verplichte dossiers. Dit is de 'Kluis'. * De Intellectuele Kant (BORIS / MS365): Bevat patronen, UDS-metadata, Bayesiaanse netwerken en anonieme casuïstiek. Dit is de 'Rekenmachine'.

2. Architecturaal Ontwerp: De "Airlock" API¶

Hoe verbinden we de Kluis met de Rekenmachine zonder de beveiliging te breken? Hiervoor ontwikkelen we de Airlock API Gateway.

A. De Voorkant: De Externe Triage/Intake-Applicatie¶

De leverancier van het cliëntsysteem bouwt/levert het Inwoner-Portaal (bijvoorbeeld een DigiD-beveiligde website of inloop-zuil-app). 1. De inwoner logt in. 2. De inwoner vult gegevens in of beantwoordt vragen (optioneel via de leverancier-eigen functionaliteit). 3. De externe applicatie wijst een Random Hash ID toe aan deze casustransactie (bijv. Casus-XY892KL). Vanaf dit moment mag er in geen enkel AI-pakket meer een herleidbare naam voorkomen.

B. De Middenlaag: De Anonimiserings-Pipeline (The Scrubber)¶

Puur en alleen het Casus-XY892KL record (met de vrije tekst-antwoorden of aangevinkte scores) wordt via een beveiligde API naar het BORIS Cloud/MS365-netwerk geschoten. We laten de PII-scrubber het liefst draaien óp de server van het cliëntsysteem, vórdat het internet op gaat.

On-Premise / Vendor-side Scrubber: De externe applicatie is verantwoordelijk voor het filteren van zinsneden als "Mijn man Henk Jansen" naar "Mijn man [NAAM]".
Payload naar BORIS: De API payload bevat enkel: Random_Casus_ID, Leeftijdsgroep: 30-40, Vrije_tekst_klachten_gescrubt: "...", Historische_trajecten: [GGZ, WMO].

C. De Achterkant: BORIS als "Brain as a Service"¶

BORIS ontvangt de anonieme Payload en doet zijn werk. 1. De Causal Engine (BNS) berekent: "Op basis van geanonimiseerd dossier [XY892KL] is de verwachte utility van Traject A 80%." 2. De VERA/LDF LLM formuleert: "Gezien de financiële stress, vraag de bewoner naar de relatie met de verhuurder." 3. Return Payload: BORIS stuurt dit advies terug over de API naar het cliëntsysteem-dashboard óf naar de professional in MS365 onder vermelding van het Casus-XY892KL label.

3. De Workflow voor de Sociaal Werker¶

Hoe ziet de dag van de professional eruit in deze split-brain setup? Dit kan op twee manieren, afhankelijk van hoe gesloten het platform van de leverancier is.

Scenario 1: De "Side-by-Side" Weergave (Meest reëel)¶

Scherm Links: De medewerker heeft het officiële cliëntsysteem open (Red Zone). Hierin staan de echte naam, het BSN, adres en het officiële zorgplan.
Scherm Rechts / Teams: De medewerker heeft de VERA Dashboard-app open (Yellow Zone). Bovenin VERA staat geen naam, maar Casus XY892KL.
Interactie: De medewerker kijkt links van wie hij de gegevens moet beoordelen, en leest rechts (in VERA) de wiskundige risico-analyse en de methodische adviezen voor dát Specifieke Casus-ID.

Scenario 2: Volledige Integratie via de Leverancier (iFrame/Overlay)¶

Als de leverancier van het cliëntsysteem meewerkt, hoeft de medewerker MS Teams/BORIS niet expliciet te openen. * BORIS levert de "Brain as a Service" API. * De leverancier bouwt een speciaal "BORIS Advies Paneel" in de eigen interface van hun cliënt-software. * De software koppelt 'onder water' de anonieme VERA-output aan het juiste (identificeerbare) cliëntdossier puur ten behoeve van de weergave bij de professional. BORIS zelf leert en ziet nooit de identiteit.

4. Gevolgen voor het Zelflerend Systeem en Kennis Ophalen¶

Dit architectuurmodel heeft gevolgen voor hoe BORIS 'slimmer' wordt. Omdat BORIS geen namen kent en MDO's/overleggen de naam van de cliënt niet mogen vangen, is het in de vorige sectie (Micro-Curatie en Team-sjablonen) beschreven formulier cruciaal.

Wanneer een casus wordt besproken in een Kenniswerkplaats, praat men altijd en uitsluitend over gedrag, traject en uitkomst (metadata). "We zien een vrouw, 30-40, kenmerk autisme en verslaving, we deden X, het resultaat was Y."
Het cliëntsysteem moet bereid zijn om periodiek (bijv. maandelijks) Bata-dumps via de API te leveren aan BORIS: "Hier zijn 500 afgesloten dossiers (UDS-geformatteerd en 100% PII-gescrubt) voor jullie Bayesian Updating trainings-ronde." Hiermee kalibreert het Bayesiaanse systeem zich.

5. Overwegingen en Risico's¶

Vendor Lock-In en Borging: Je bent bij deze architectuur zéér afhankelijk van de welwillendheid, de ontwikkelcapaciteit en het prijjskaartje van de leverancier van het cliëntsysteem om a) dat inlog-portaal te bouwen en b) de API-brug naar jullie MS365 tenant the bouwen/onderhouden. Zorg voor harde SLA's (Service Level Agreements) op the API.
Kwaliteit van de Anonimiseringslaag: Een "NaamScrubber" bouwen is relatief eenvoudig. Het garanderen dat vrije tekst ("Ik woon tegenover de Hema in de Hoofdstraat") niet alsnog de identiteit verraadt, is de uitdaging.
Dataretentie-beleid: BORIS moet direct, door middel van API-status-codes, de ingestuurde data (de input) vergeten na de inferentie-loop, tenzij het doelbewust gecategoriseerd wordt in the 'Bronze Evidence' vector store waarbij élk detail is uitgezeefd.

Door deze architectuur aan te houden, bouw je echter in essentie de meest risicoloze en EU-AI-Act-compliant AI hub binnen the sociale domein van Nederland.