Het grootste risico van fast coding ontstaat niet wanneer iemand met AI een toepassing bouwt.
Het ontstaat op het moment dat die toepassing belangrijk wordt voor je bedrijfsvoering, zonder dat iemand het beseft.
En dat moment kan verrassend snel komen.
Van handige tool naar bedrijfsrisico
Neem een salesmedewerker die met AI een toepassing bouwt om offertes en klantgegevens op te volgen.
Aanvankelijk gebruikt hij ze alleen. Daarna ontdekken collega's hoe handig ze is. Enkele maanden later gebruikt het volledige team de toepassing en baseert de salesmanager er zijn rapportering op.
Ondertussen bevat ze klantgegevens, prijsafspraken en commerciële informatie.
Wat begon als een persoonlijk hulpmiddel, is stilaan een belangrijk bedrijfssysteem geworden.
Alleen heeft niemand die overgang bewust gemaakt.
Er is geen verantwoordelijke aangeduid, niemand heeft de beveiliging gecontroleerd en de kennis zit grotendeels bij de maker.
De toepassing is volwassen geworden. De afspraken eromheen niet.
De verborgen kost van goedkope software
Zestien jaar geleden begon ik als zelfstandig softwareontwikkelaar. Ik heb de sector sterk zien veranderen, maar de snelheid waarmee AI vandaag software mogelijk maakt, is ongezien.
Ik gebruik AI zelf dagelijks en zie er enorme opportuniteiten in.
Toch doet deze evolutie me denken aan fast fashion.
Een T-shirt kan er fantastisch uitzien, maar dat zegt weinig over hoe lang het meegaat.
Hetzelfde geldt voor software.
Vroeger betaalden bedrijven soms forse bedragen voor ERP- en CRM-systemen. Niet alleen voor de software zelf, maar ook voor onderhoud, ondersteuning, beveiligingsupdates en contractuele afspraken.
Die contracten garandeerden geen perfect systeem. Maar ze maakten doorgaans wel duidelijk wie je kon aanspreken.
Vandaag kan de ontwikkeling van een toepassing een fractie van vroeger kosten.
Alleen zijn de kosten voor onderhoud, beveiliging en continuïteit niet verdwenen.
Iemand moet die verantwoordelijkheid nog altijd opnemen.
Drie beslissingen die elke bedrijfsleider zou moeten nemen
Volgens mij hoeven bedrijven hun medewerkers absoluut niet af te remmen. Integendeel. Geef mensen de ruimte om met AI te experimenteren en hun werk eenvoudiger te maken.
Maar maak wel drie duidelijke afspraken.
1. Zorg dat je weet wat er gebouwd wordt.
Vraag je afdelingsverantwoordelijken welke zelfgebouwde toepassingen hun teams gebruiken.
Niet alleen officiële softwareprojecten, maar ook die handige tools die iemand zelf in elkaar heeft gezet.
Je hoeft niet elk experiment te registreren. Maar zodra een toepassing gedeeld wordt, bedrijfsgegevens verwerkt of een belangrijk proces ondersteunt, moet ze zichtbaar zijn.
2. Bepaal wanneer een experiment bedrijfskritisch wordt.
Een persoonlijke tool om vergadernotities samen te vatten is iets anders dan een toepassing die offertes berekent of klantgegevens beheert.
Niet elke toepassing heeft dezelfde controles nodig.
Maak daarom een onderscheid tussen persoonlijke hulpmiddelen, toepassingen die een team gebruikt en systemen waarvan belangrijke bedrijfsprocessen afhankelijk zijn.
Hoe groter de impact, hoe duidelijker de afspraken moeten zijn.
3. Duid een verantwoordelijke aan.
Wie beheert de toepassing? Wie heeft toegang tot de gegevens? Wie grijpt in als iets fout loopt?
En misschien de belangrijkste vraag: wat gebeurt er wanneer de persoon die de toepassing gebouwd heeft morgen vertrekt?
Dat hoeft niet altijd een externe IT-partner te zijn. Maar er moet wel iemand zijn die de verantwoordelijkheid draagt en ervoor zorgt dat de kennis niet bij één persoon blijft zitten.
Snel bouwen mag. Blind vertrouwen niet.
Ik geloof dat AI bedrijven enorm veel mogelijkheden biedt. Medewerkers kunnen problemen oplossen waarvoor vroeger misschien nooit budget of tijd beschikbaar was.
Die innovatie moeten we stimuleren.
Maar we mogen snelheid niet verwarren met betrouwbaarheid.
De echte uitdaging voor bedrijfsleiders is niet om elke zelfgebouwde toepassing te controleren.
Het is om te herkennen wanneer een handig experiment verandert in software waarvan het bedrijf afhankelijk wordt.
Want de ontwikkelkosten dalen.
De verantwoordelijkheid blijft.
En misschien is dit een goede vraag voor je volgende managementoverleg:
Welke toepassingen gebruiken onze teams vandaag waar we eigenlijk geen duidelijk zicht op hebben?