8 signalen dat je zelfgebouwde AI-tool meer aandacht nodig heeft

Laatst bijgewerkt: 05 november 2026

Harmen Visser

Commercieel directeur

TRES

Het gebeurt al in veel organisaties: een medewerker bouwt met AI een handige tool om terugkerend werk te automatiseren. Eerst gebruikt diegene de toepassing alleen, maar een paar maanden later werken collega's er ook mee en wordt de tool gekoppeld aan andere systemen. Wat begon als een experiment, is inmiddels onderdeel van het dagelijkse werk.

Dat is een mooie ontwikkeling. Medewerkers kunnen met AI steeds vaker zelf oplossingen maken voor problemen die ze in hun dagelijkse werk tegenkomen. Maar naarmate een toepassing belangrijker wordt, verandert ook de verantwoordelijkheid die je organisatie ervoor draagt.

Wanneer is het tijd om opnieuw te kijken naar de veiligheid, het beheer en de betrouwbaarheid van zelfgebouwde software?

Een werkende tool is niet automatisch klaar voor dagelijks gebruikt

Stel je voor dat een planner bij een productiebedrijf iedere week gegevens uit het ERP exporteert en dit combineert met een Excelbestand waarin de beschikbare machinecapaciteit staat. Dit kost enorm veel tijd. Hoe mooi zou het zijn als je dit gemakkelijk kunt automatiseren… Met een AI-codingtool bouwt deze planner vervolgens een toepassing die beide bestanden automatisch combineert. De tool werkt goed en bespaart iedere week uren handmatig werk. Een fantastische oplossing, toch?

In het begin is het risico inderdaad beperkt. De planner gebruikt de toepassing zelf en kan altijd terugvallen op zijn oude werkwijze. Als de tool een keer niet werkt, loopt de productieplanning gewoon door. Geen probleem zou je zeggen.

Maar dat verandert wanneer collega's de toepassing ook gaan gebruiken. Er komen nieuwe functies bij en uiteindelijk wordt de tool rechtstreeks gekoppeld aan het ERP. Capaciteitsbeslissingen worden inmiddels op basis van de toepassing genomen. De software is misschien nauwelijks veranderd, maar de gevolgen als er iets misgaat, zijn groot. Tijd om het serieus aan te pakken.

Acht signalen dat je zelfgebouwde software opnieuw moet beoordelen

Iedere toepassing vraagt weer om verschillende maatregelen. Een tijdelijk experiment waarmee één medewerker werkt, is iets anders dan een applicatie waar een hele afdeling dagelijks op vertrouwt. De volgende acht veranderingen zijn aanleiding om opnieuw naar een toepassing te kijken.

1. Meer medewerkers gaan de toepassing gebruiken

Wat begon als een persoonlijke tool, wordt door steeds meer collega's gebruikt. Daarmee wordt het belangrijker dat anderen begrijpen hoe de toepassing werkt. Wie kan erbij? Wie helpt als er iets misgaat? Kunnen collega's hun werk nog doen wanneer de tool tijdelijk niet beschikbaar is?

2. De toepassing blijft langer bestaan dan verwacht

Sommige tools worden gebouwd om één probleem op te lossen of een idee uit te proberen. Maar als een toepassing goed werkt, blijft die vaak in gebruik. En terecht, want waarom zou je afscheid nemen van een tool die goed werkt?

Bij het behouden van de toepassing ontstaan er echter wel weer nieuwe vragen. Wie houdt de software actueel? Worden fouten opgelost? Kan iemand anders het beheer overnemen wanneer de oorspronkelijke maker vertrekt?

3. De toepassing gaat persoonsgegevens verwerken

Een tool die alleen openbare gegevens gebruikt, vraagt om andere maatregelen dan een toepassing waarin klant- of medewerkersgegevens worden verwerkt. Zodra persoonsgegevens in beeld komen, moet je onder andere kijken naar de toegang tot die gegevens, de manier waarop ze worden opgeslagen en de verplichtingen vanuit de AVG.

4. Er komt een koppeling met een belangrijk bedrijfssysteem

Een toepassing die gegevens uit losse bestanden verwerkt, kan relatief eenvoudig blijven. Maar zodra er een koppeling met bijvoorbeeld het ERP of CRM bijkomt, verandert de situatie. Je wilt weten of die koppeling veilig is, wat er gebeurt wanneer de verbinding uitvalt en wie verantwoordelijk is voor het beheer ervan.

5. De toepassing mag gegevens aanpassen of wegschrijven

Gegevens uitlezen is iets anders dan gegevens wijzigen. Een tool die een overzicht maakt van beschikbare voorraad heeft bijvoorbeeld een andere verantwoordelijkheid dan een toepassing die automatisch voorraadstanden aanpast in het ERP.

Als er iets misgaat, kan dat direct gevolgen hebben voor andere processen. Daarom is het belangrijk om te controleren welke gegevens de toepassing mag wijzigen en hoe fouten kunnen worden hersteld.

6. Klanten gaan de toepassing gebruiken

Een interne tool kan soms nog opgevangen worden met een handmatige werkwijze. Wanneer klanten rechtstreeks gebruikmaken van een toepassing, wordt dat lastiger. Dan spelen ook de beschikbaarheid, betrouwbaarheid en beveiliging van de software een grotere rol. Een storing kan immers direct gevolgen hebben voor de dienstverlening.

7. Er wordt belangrijke bedrijfslogica toegevoegd

Misschien begon de toepassing als een eenvoudige rekentool. Later worden er prijsberekeningen, contractafspraken of andere financiële regels aan toegevoegd. Dan wil je zeker weten dat de berekeningen kloppen en dat wijzigingen gecontroleerd worden doorgevoerd. Een fout kan anders gevolgen hebben voor klanten of financiële beslissingen.

8. Er is geen handmatige terugvalmogelijkheid meer

In het begin kan een medewerker vaak nog terugvallen op de oude manier van werken. Op het moment dat de toepassing goed bevalt, wordt de organisatie afhankelijk van de software en verdwijnt de oude werkwijze soms. Dit heeft als consequentie dat het werk stil kan komen te liggen als de toepassing uitvalt.

Hoe bepaal je hoeveel beheer nodig is?

Om te bepalen of een zelfgebouwde tool direct professioneel beheerd moet worden kijken we bij TRES naar twee vragen:

1. Wat zijn de gevolgen als het misgaat?

Denk aan de gevolgen voor medewerkers, klanten, financiën, privacy en belangrijke bedrijfsgegevens.

2. Hoe structureel wordt de software gebruikt?

Is het een tijdelijk experiment of wordt de toepassing een vast onderdeel van het dagelijkse werk?

Die twee vragen vormen de basis van ons Software Responsibility Model. Een tijdelijk prototype met beperkte gevolgen kun je vaak prima gebruiken om te experimenteren. Een toepassing die jarenlang onderdeel blijft van het werk vraagt om duidelijk eigenaarschap en onderhoud. En wanneer software belangrijke bedrijfsprocessen aanstuurt, worden zaken als security, testen, monitoring en herstelbaarheid belangrijker.

De manier waarop je software ontwikkelt en beheert, moet passen bij de verantwoordelijkheid die je eraan geeft.

Waar begin je?

Je hoeft niet direct een uitgebreid beleid op te stellen voor alle toepassingen die medewerkers zelf bouwen. Begin eens met een overzicht. Welke tools, scripts en applicaties hebben medewerkers het afgelopen jaar gemaakt? Wie gebruikt ze? Welke gegevens verwerken ze? En met welke systemen zijn ze verbonden? Kies vervolgens een paar toepassingen uit en stel per toepassing twee vragen:

Wat gebeurt er als deze tool morgen verkeerd werkt of uitvalt?
Wat gebeurt er als we deze tool over twee jaar nog steeds gebruiken?

De antwoorden helpen om te bepalen waar extra aandacht nodig is. Stop vooral niet met het zelf bouwen van software met AI als dit jullie veel mogelijkheden biedt. Deze ontwikkeling maakt het juist gemakkelijker om ideeën uit te proberen en handmatig werk te verminderen. Belangrijk is om op tijd te herkennen wanneer een experiment verandert in software waar je organisatie op vertrouwt.

Snel waar het kan. Beheerst waar het moet.

Wil je weten hoe je bepaalt welke zelfgebouwde software extra aandacht nodig heeft? In onze whitepaper ‘Snel waar het kan. Beheerst waar het moet.’ leggen we het Software Responsibility Model uit, met voorbeelden van vier verschillende situaties.

Download hier de whitepaper