Wanneer wordt zelfgebouwde software in het onderwijs een verantwoordelijkheid van de organisatie?

De aanleiding voor dit artikel was een verhaal dat ik thuis aan de keukentafel hoorde. Een bovenschoolse overleggroep komt maandelijks samen om complexe leerlingcases te bespreken. Deelnemers tonen via een tijdspad welke hulp en begeleiding voor een kind is geregeld. Omdat de identiteit van de kinderen voor het overleg niet nodig is, probeert het team die zoveel mogelijk te verbergen. Er wordt daarom bewust niet via een standaard cloudoplossing gewerkt en de casussen worden handmatig uitgewerkt op grote flipovervellen.

Dat werkt, maar het is omslachtig. Tijdens een bijeenkomst ontstond daarom een idee: zelf een compacte app of AI-chatbot maken waarin deelnemers hun gegevens kunnen invoeren en waaruit direct bruikbare overzichten komen. Een van de aanwezigen zag dat de toepassing daarvoor wel echte gegevens zou moeten verwerken en stelde de privacyvraag aan de orde. Er werd besloten om het plan niet door te zetten.

Dat was niet alleen een privacykwestie. Een medewerker kon zelf een bruikbaar hulpmiddel maken en ging ervan uit dat dit kon. Onduidelijk was vooral wanneer zo’n initiatief nog bij de maker ligt en wanneer de organisatie moet aanhaken. Het probleem zat dus niet zozeer in het hulpmiddel zelf, maar in de vraag wie moest beoordelen of ermee verder kon worden gegaan. Misschien was daar binnen de organisatie al een route voor, maar voor de medewerker was die in elk geval niet duidelijk.

Het initiatief was niet het probleem

Een medewerker probeert een omslachtig proces te verbeteren. Dat is precies het soort initiatief dat onderwijsorganisaties nodig hebben. Veel initiatieven zijn klein en overzichtelijk: een leerkracht ordent lesmateriaal, maakt een oefenvorm of gebruikt een tijdelijk hulpmiddel bij de voorbereiding. Zolang anderen er niet afhankelijk van zijn, de maker de uitkomsten zelf controleert en eenvoudig kan terugvallen op de bestaande werkwijze, hoeft de organisatie daar niet automatisch een zwaar traject van te maken.

Een totaalverbod helpt evenmin. Medewerkers blijven praktische problemen oplossen, zeker nu de technische drempel laag is. Als het melden van een initiatief automatisch als voorportaal van een verbod voelt, verdwijnen experimenten uit het zicht. Alles vrijlaten werkt ook niet: dan blijft onduidelijk wie mag besluiten zodra anderen, gegevens of werkprocessen geraakt worden.

De kern is daarom niet of medewerkers zelf software mogen maken. De vraag is wanneer de verantwoordelijkheid niet meer uitsluitend bij de maker kan liggen.

De beslisvraag

Kan dit nog mislukken zonder dat iemand anders daar last van heeft?

Die vraag markeert het omslagpunt. Kan een zelfgemaakte app, tool of ander hulpmiddel uitvallen, stoppen of worden weggegooid zonder dat leerlingen, collega's of werkprocessen daar merkbare gevolgen van ondervinden? Dan kan de maker in beginsel zelfstandig verder.

Is het antwoord nee, of kan de maker dat zelf niet goed bepalen, dan moet de organisatie aanhaken. Dat betekent niet automatisch een uitgebreid traject. Voor een beperkte pilot kan een korte check met duidelijke afspraken genoeg zijn. Maar vanaf dat moment kan de maker niet meer als enige bepalen welk risico de organisatie aanvaardt.

Signalen dat de organisatie moet aanhaken

De beslisvraag is simpel, maar het antwoord is niet altijd direct zichtbaar. Een aantal signalen laat zien dat verantwoordelijkheid waarschijnlijk niet meer uitsluitend bij de maker ligt:

• er worden echte, herleidbare, vertrouwelijke of gevoelige gegevens gebruikt;

• collega's, leerlingen, ouders of andere organisaties gaan de toepassing zelfstandig gebruiken of erop vertrouwen;

• uitkomsten beïnvloeden beoordeling, begeleiding, onderwijsinhoud of andere beslissingen;

• een werkproces wordt afhankelijk van de beschikbaarheid of juistheid van de toepassing;

• accounts, koppelingen, opslagvoorzieningen of externe diensten van de organisatie worden gebruikt.

Eén zwaar signaal kan al genoeg zijn. Meerdere lichtere signalen kunnen samen hetzelfde betekenen. De mogelijke gevolgen bepalen hoeveel betrokkenheid nodig is, ongeacht of de toepassing met AI of op een andere manier is gemaakt.

Drie herkenbare situaties

Het helpt om niet alleen te bepalen óf de organisatie moet aanhaken, maar ook hoe zwaar die betrokkenheid moet zijn.

1. Individuele verkenning of persoonlijk hulpmiddel

De maker onderzoekt een idee voor het eigen werk, zonder anderen afhankelijk te maken of bestaande processen te vervangen. Denk aan het voorbereiden van lesmateriaal, het testen met verzonnen data of het maken van een hulpmiddel waarvan de uitkomsten altijd door de maker zelf worden gecontroleerd.

Proberen, leren en weggooien kan hier zonder afzonderlijke toestemming van de organisatie. Een korte check wordt pas relevant wanneer bijvoorbeeld echte gegevens, externe diensten of andere duidelijke risico's in beeld komen.

2. Pilot

Een pilot betrekt anderen of haakt in op een echt proces, maar blijft beperkt en omkeerbaar. Een leerkracht kan bijvoorbeeld een oefenvorm met leerlingen testen, zelf de uitkomsten controleren en eenvoudig terugvallen op de bestaande werkwijze.

De organisatie haakt hier licht aan. Zij kijkt mee naar de mogelijke gevolgen en spreekt af onder welke voorwaarden de proef kan doorgaan. Meer beoordeling is nodig wanneer gevoelige gegevens worden gebruikt, uitkomsten belangrijke beslissingen beïnvloeden of mensen afhankelijk beginnen te raken.

Een pilot moet bovendien eenvoudig kunnen stoppen. Gegevens moeten kunnen worden verwijderd of overgedragen, accounts moeten afsluitbaar zijn en het oorspronkelijke proces moet weer bruikbaar zijn. Als stoppen niet meer eenvoudig kan, is het initiatief in de praktijk al verder dan een pilot, ook als iedereen het nog zo noemt.

3. Organisatiesoftware

Zodra een hulpmiddel structureel wordt gebruikt of er binnen de organisatie afhankelijkheid van ontstaat, is sprake van organisatiesoftware. Collega's of leerlingen vertrouwen bijvoorbeeld op de werking, gegevens worden herhaaldelijk verwerkt of een werkproces kan niet eenvoudig verder als het hulpmiddel faalt of stopt.

De operationele verantwoordelijkheid kan dan niet vanzelfsprekend bij de oorspronkelijke maker blijven. De organisatie wijst bewust een verantwoordelijke eigenaar aan en regelt wat nodig is voor kwaliteit, beveiliging, toegankelijkheid, ondersteuning, onderhoud en continuïteit.

Wat verandert wanneer de organisatie aanhaakt?

De mogelijke gevolgen bepalen de zwaarte van de beoordeling. Een beperkte oefenvorm zonder persoonsgegevens vraagt om iets anders dan een toepassing die leerlinggegevens verwerkt of onderwijsbesluiten beïnvloedt.

Daarbij is de buitenkant van de software nauwelijks een maatstaf. Zeker met AI kan een initiatief snel ogen als een professionele app. De kwaliteit van toegangsbeheer, testen, foutafhandeling, documentatie en beheer blijft aan die buitenkant onzichtbaar. Betrouwbaarheid blijkt vooral uit wat er gebeurt als de software fouten maakt, uitvalt of niet langer onderhouden wordt.

Ook bij succes veranderen de afspraken. Een geslaagde proef laat zien dat een initiatief waarde kan hebben, maar zegt nog weinig over veiligheid, toegankelijkheid, onderhoudbaarheid en overdraagbaarheid. Zodra gebruik, gegevens of afhankelijkheid groeien, moet de organisatie opnieuw kijken naar de afspraken en het eigenaarschap.

Wat moet je als organisatie minimaal regelen?

Het hoeft niet ingewikkeld te zijn. Medewerkers moeten vooral weten:

• wat zij zelfstandig kunnen doen;

• wanneer zij een initiatief moeten melden;

• bij wie zij terechtkunnen voor een snel besluit.

Daarnaast moet duidelijk zijn wie inhoud, techniek, privacy en beveiliging beoordeelt en wie resterend risico mag accepteren. Niet iedere organisatie hoeft al die kennis zelf in huis te hebben, maar zij moet wel weten wanneer externe expertise nodig is. Het uiteindelijke besluit blijft bij de organisatie.

Een melding mag ook niet uitmonden in maanden overleg, een automatisch verbod of een formulier zonder eigenaar. Zonder duidelijke beslisser en redelijke beslistermijn blijft een goed initiatief alsnog liggen. Dan is er formeel iets geregeld, maar schiet de organisatie er in de praktijk weinig mee op.

De eerste stap blijft simpel

Onderwijsprofessionals moeten ruimte hebben om digitale hulpmiddelen te maken. Zij zien problemen van dichtbij en komen soms tot oplossingen waar leveranciers nooit aan beginnen. Met moderne technieken kan een praktisch probleem bovendien veel sneller worden opgelost dan voorheen.

De eerste toets blijft simpel: kan dit nog mislukken zonder dat iemand anders daar last van heeft?

Ja? Ga vooral verder.

Nee, of moeilijk te bepalen? Laat de organisatie aanhaken en bepaal vervolgens hoe zwaar de beoordeling werkelijk moet zijn.

Zo voorkom je dat verantwoordelijkheid bij de maker blijft liggen terwijl de gevolgen uiteindelijk bij de organisatie terechtkomen.

Dit artikel biedt een bestuurlijk en operationeel kader. De juridische positie hangt af van de toepassing, de arbeidsrelatie, de gebruikte gegevens en de gemaakte afspraken.