Trustbird bouwen: waarom voorstellen en besluiten gescheiden blijven

Een risico beschrijven is iets anders dan dat risico accepteren. Een beleidsdocument opstellen is iets anders dan het vaststellen. Zodra software beide stappen afhandelt zonder duidelijk verschil, wordt onduidelijk wie waarvoor verantwoordelijk is. Als medeoprichter van Trustbird vind ik dat een wezenlijke productvraag: welke werkzaamheden kan software voorbereiden, en waar moet een persoon bewust een besluit nemen?

Trustbird brengt cybersecurityrisico’s, maatregelen, leveranciers, verantwoordelijkheden en bewijs samen. Het platform moet organisaties helpen om verbanden te zien en hun beveiligingswerk bij te houden. AI past daarin als hulp bij het ordenen en uitwerken van informatie. De verantwoordelijkheid voor de organisatie blijft bij de mensen die ermee werken.

Een grens die ook in de software bestaat

In juli werkte ik aan de toegangslaag van de onderliggende Laravel-code. Daarbij zijn controles aangescherpt op de organisatie waartoe een persoon, rol of recht behoort. Ook degene die een recht toekent, moet binnen de juiste organisatie vallen. Een onbekend recht wordt expliciet geweigerd. Stilzwijgend een deel van een opdracht uitvoeren zou verbergen dat de aangevraagde wijziging niet klopt.

Dat werk laat zien waarom een begrijpelijke interface alleen onvoldoende is. Een scherm kan zorgvuldig om toestemming vragen, terwijl een andere ingang dezelfde handeling alsnog uitvoert. Toegangsregels moeten daarom gelden op de plek waar gegevens veranderen. Tests die ongeldige combinaties proberen, horen bij die grens. Ze controleren niet alleen of een toegestane handeling werkt, maar ook of een verboden handeling wordt geweigerd.

Een voorstel krijgt een eigen levensloop

In de verdere ontwikkeling van Trustbird is die scheiding ook voor AI uitgewerkt. Het team heeft voorstellen apart vastgelegd, met de gebruikte invoer, het model, de promptversie en het moment waarop het voorstel ontstond. Een beslissing krijgt vervolgens een eigen beslisser en tijdstip. Daardoor blijft zichtbaar wat de software heeft aangeleverd en wat een persoon daarvan heeft overgenomen.

De vaststelling vereist in de gebouwde beslislaag een persoon die in het gebruikerspaneel is ingelogd. Een achtergrondtaak of AI-koppeling kan die stap niet namens zichzelf uitvoeren. Die beperking maakt de route langer dan rechtstreeks opslaan als definitief resultaat. Daar staat tegenover dat de betekenis van goedkeuring behouden blijft. Voor een product dat verantwoordelijkheden en bewijs bijhoudt, hoort dat bij de kern.

Onzekerheid moet ergens terechtkunnen

Een tweede obstakel is onvolledige informatie. Zonder bruikbare invoer heeft een AI-beoordeling weinig grond. De ontwikkelde beoordelingsroute roept het model dan niet aan. Bij een te lage opgegeven zekerheid ontstaat een taak voor menselijke beoordeling. Zo krijgt het ontbrekende oordeel een vervolg, in plaats van dat het ongemerkt als afgerond werk wordt behandeld.

Zo’n zekerheidsscore bewijst niet dat een oordeel klopt. De kans zit voor mij vooral in het zichtbaar maken van twijfel en het organiseren van de volgende stap. Dat vraagt ook iets van het product: een gebruiker moet kunnen begrijpen welke informatie ontbreekt en waarom een voorstel aandacht vraagt. Anders verplaatst automatisering het uitzoekwerk slechts naar een onoverzichtelijke takenlijst.

Van technische regel naar productwaarde

Als developer en ondernemer kijk ik daarom naar de samenhang tussen functies. Sneller tekst produceren heeft beperkte waarde als later niemand kan achterhalen waarop die tekst berust. Een voorstel wordt bruikbaar wanneer de bron, de verantwoordelijkheid en de vervolgstap duidelijk zijn.

De kans voor Trustbird ligt in minder voorbereidend werk met behoud van een duidelijk besluitproces. Dat vraagt soms meer technische aandacht voor rechten, statussen en herkomst dan voor de generatie zelf. Voor mij zijn dat geen bijzaken. Ze bepalen of een AI-functie past in het dagelijkse werk van een organisatie.