Toen beveiligingsbedrijf RedAccess apps onderzocht die met AI-programmeertools waren gebouwd en op hun eigen hosting gepubliceerd, vond het er meer dan 5.000 met vrijwel geen beveiliging of authenticatie. De met Wired gedeelde schermen bevatten “allerlei verkoop- en financiële gegevens van uiteenlopende andere bedrijven”. AI-gebouwde apps voor financiële teams kunnen op hetzelfde soort openbare adres belanden, met grootboek, salarissen en nog niet bekendgemaakte resultaten erachter.
Replit-CEO Amjad Masad antwoordde: “Dat openbare apps op internet bereikbaar zijn, is verwacht gedrag.” Wat het mechanisme betreft heeft hij gelijk. Volgens mij ontstond de blootstelling door een zichtbaarheidsinstelling en een overgeslagen controle, en beide liggen binnen het bereik van degene die het hulpmiddel heeft gebouwd.
TL;DR
- Een AI-gebouwd financieel hulpmiddel kan gegevens lekken door zes uitrolfouten, die elk binnen het bereik van de maker liggen: een openbare link, wachtwoorden en sleutels die in code of chatgeschiedenis zijn achtergebleven, databasetoegang op beheerdersniveau, boeken zonder tweede goedkeurder, gegevens die naar externe diensten worden gestuurd en rekenwijzigingen die niemand heeft vastgelegd.
- Iedere fout heeft een oplossing, meestal via dezelfde AI-tool die de app bouwde, en een concrete controle die de werking bewijst, zoals een door de database geweigerde schrijfactie of een oud wachtwoord dat niet meer werkt.
- Houd een financieel hulpmiddel standaard op een privénetwerk, voeg bedrijfslogin toe wanneer mensen buiten finance het nodig hebben en draag het over aan IT wanneer het zonder tweede goedkeurder in het grootboek boekt, met kaartgegevens werkt of cijfers aanlevert voor jaarrekeningen die onder SOX vallen.
- De serverregio bepaalt waar de primaire VPS-opslag van de app staat, maar backups, logs en diensten van derden kunnen elders kopieën aanmaken; of de opzet als geheel aan de regels voldoet, is een aparte vraag. Leg de kaders voor jouw regio voor aan je complianceteam.
Uitrolfouten die financiële gegevens lekken
Een AI-gebouwd financieel hulpmiddel kan gegevens lekken door zes uitrolfouten: het op een openbare link laten staan, credentials in code of chat bewaren, verbinding maken met beheerderstoegang waar alleen-lezen zou volstaan, boeken zonder tweede goedkeurder, financiële gegevens naar externe diensten sturen en berekeningen wijzigen zonder dat dit wordt vastgelegd. Elk daarvan is een standaardkeuze die een demo beloont.
Bij iedere oplossing hieronder hoort een prompt voor de AI-tool die de app heeft gebouwd; pas de velden tussen blokhaken aan voordat je de prompt plakt. De prompts zijn ongeteste startpunten die voor dit artikel zijn geschreven, en als je AI-tool meldt dat hij iets heeft gewijzigd, bewijst dat niets. De controle onder elke prompt is het bewijs. Voer de prompts uit op de code en op een voorbeeld- of synthetische dataset, en plak nooit echte records of actieve sleutels in de chat.
Het hulpmiddel op de openbare link van de AI-bouwer laten
Een kasprognosedashboard dat openbaar op de hosting van de AI-bouwer is blijven staan, kan worden geopend door iedereen die het adres heeft, samen met alles wat het toont: de ouderdom van crediteuren, budget versus werkelijkheid en de kwartaalresultaten nog voordat ze zijn bekendgemaakt. Wireds verslag over de bevindingen van RedAccess beschrijft hoe de onderzoekers zulke apps vonden met eenvoudige Google- en Bing-zoekopdrachten op de domeinen van de AI-leveranciers.
Sommige van die apps vroegen bezoekers alleen om in te loggen met een willekeurig e-mailadres. Een login die elk e-mailadres accepteert, is geen toegangscontrole.
Haal echte gegevens van de hosting van de leverancier. Zolang het hulpmiddel nog niet op een server draait die je zelf beheert (de volgende sectie behandelt waar), bouw en demonstreer je het met een synthetische dataset of met de sandbox of het testbedrijf van je ERP, als dat er een heeft, en nooit met een echte export. Rol opnieuw uit zodra de wijziging is doorgevoerd, want het gehoste adres toont de versie die het laatst is uitgerold.
Maak voor deze app een synthetische dataset die overeenkomt met de tabellen en kolommen die hij leest: [noem de tabellen en kolommen, bijvoorbeeld vendors, invoices, journal_lines].
Gebruik verzonnen leveranciers en klanten, verzonnen bankrekeningnummers en bedragen in [valuta] die zich als echte boeken gedragen: iedere journaalpost balanceert en subadministratietotalen sluiten aan op [de crediteuren- / debiteurencontrolerekening].
Verbind de app met deze gegevens in plaats van een echte export en noem elk gewijzigd bestand of instelling.
Vraag me niet om echte records.
Controleer het resultaat: open het door de leverancier gehoste adres vanuit een afgemelde browser, of vraag een collega buiten finance om dat te doen, en controleer dat het alleen synthetische gegevens, een loginmuur of helemaal niets toont. Doorzoek daarna de gegevensbestanden van de app en de repository op drie leveranciers- of klantnamen uit je echte ERP en verwacht geen treffers. Draai tot slot de proefbalans of de samenvattingsweergave van de app en controleer dat het totaal debet gelijk is aan het totaal credit.
ERP-, bankfeed- en databasecredentials in code of chat laten
Als daar een actieve credential is opgeslagen, kan iedereen die de chatgeschiedenis, de repository of het MCP-configuratiebestand kan lezen, die mogelijk ook gebruiken om het ERP, de financiële database of de bankfeedkoppeling te bereiken. MCP is de connector waarmee een AI-tool zoals Claude rechtstreeks met het ERP of een database communiceert, en het configuratiebestand ervan is nog een plek waar een wachtwoord kan staan.
GitGuardians State of Secrets Sprawl 2026 vond 24.008 unieke secrets die in MCP-configuratiebestanden waren blootgesteld, waarvan 14% verbindingsstrings voor PostgreSQL-databases. In openbare GitHub-commits stelde hetzelfde rapport vast dat commits die Claude Code mede had geschreven secrets lekten met ongeveer tweemaal de basisfrequentie, en het voegt eraan toe dat ook de menselijke factor van cruciaal belang blijft.
Het chatbericht verwijderen maakt de blootstelling niet ongedaan: iedereen met een kopie van de chat, de repository of de geschiedenis ervan heeft de waarde nog steeds. Maak voor elk wachtwoord, elke sleutel of elk token dat ooit op een van die plekken heeft gestaan een nieuwe aan in de beheerconsole van het ERP, de database of de bankfeed, en schakel de oude uit. Dat is wat het roteren van een credential betekent.
De app leest zijn credentials vervolgens bij het opstarten uit omgevingsvariabelen (benoemde instellingen die buiten de code worden bewaard), aangeleverd door de uitrollaag: de tool die de app op je server bouwt en uitvoert. HashiCorp Vault is de volgende stap wanneer meerdere tools secrets delen die vanaf één plek moeten worden geroteerd.
De eigen kopieën van wachtwoorden van het team horen in een wachtwoordmanager die voor mensen is gemaakt, zoals Vaultwarden; de draaiende app leest zijn waarden uit de omgeving. Begin met het opsporen van alle hardgecodeerde secrets in de door AI gegenereerde code.
Audit dit project op hardgecodeerde secrets. Zoek elk wachtwoord, elke API-sleutel, elk toegangstoken en elke verbindingsstring, ook in .env-bestanden, notebooks, MCP-configuratiebestanden en de code die verbinding maakt met [ERP-naam / bankfeedleverancier / financiële database].
Vervang iedere waarde in de code door een benoemde omgevingsvariabele en geef me de lijst met variabelenamen.
Zorg dat geen enkel bestand met echte waarden in de repository wordt gecommit, en noem elke commit in de geschiedenis van de repository waarin een van deze waarden voorkomt.
Toon me alleen de locaties. Geef geen enkele secretwaarde weer.
Controleer het resultaat: probeer het oude wachtwoord of token zelf uit, of vraag IT dat te doen, en verwacht dat het wordt geweigerd. Doorzoek daarna de huidige projectbestanden op de oude waarden en verwacht geen treffers. Een treffer die in de geschiedenis achterblijft, geeft pas geen toegang meer nadat je hebt bevestigd dat de waarde is ingetrokken of verlopen.
De beheerlogin van de maker gebruiken terwijl alleen lezen nodig is
Een dashboard dat de ouderdom van debiteuren toont, mag het grootboek niet kunnen wijzigen. Als het hulpmiddel verbinding maakt met de beheerlogin van de maker, erft het de rechten van dat account. Een geheime Supabase-sleutel, of de oude service_role-sleutel, geeft verhoogde toegang tot de gegevens van het project en omzeilt Row Level Security, dus die hoort niet te worden gebruikt voor gewone alleen-lezentoegang. Een rapport dat voor één ouderdomsoverzicht is gebouwd, legt dan het hele grootboek bloot, inclusief de salaristabellen.
Schrijftoegang maakt dit kostbaar. Symbiotic Securitys scan van 1.072 AI-gebouwde apps met Supabase vond 172 apps waarin iedereen zonder authenticatie records kon verwijderen, 172 waarin iedereen bestaande records kon wijzigen en 39 met tabellen die volledig leesbaar waren voor iedereen met de publieke sleutel.
Geef het hulpmiddel een alleen-lezen credential die beperkt is tot de tabellen die het leest. Maak in het ERP of de database een eigen integratiegebruiker: een apart account voor de tool met leestoegang tot uitsluitend de benodigde rapportobjecten. Activeer in Supabase Row Level Security, de databaseregel die bepaalt welke rijen ieder verzoek mag zien, voor iedere gebruikte blootgestelde tabel, en controleer ook tabelrechten: die bepalen of een rol select, insert, update of delete mag uitvoeren. De rol die een alleen-lezen financiële app gebruikt, hoort geen schrijfrechten te hebben die hij niet nodig heeft. De publiceerbare sleutel mag in browsercode staan als RLS en minimale rechten correct zijn. Geheime en oude service_role-sleutels blijven serverzijdig, uitsluitend voor backendtaken die verhoogde rechten werkelijk nodig hebben en eigen autorisatie afdwingen.
Let op: een publiceerbare Supabase-sleutel of oude anon-sleutel in JavaScript is normaal. Supabases documentatie over API-sleutels zegt dat hij alleen bereikt wat Row Level Security toestaat. De geheime sleutel omzeilt die bescherming en mag nooit naar de browser worden gestuurd.
Noem elke lees- en schrijfactie die deze app uitvoert op [ERP- of databasenaam], gegroepeerd per tabel of object.
Wijzig de app zodat hij alleen [de tabellen die hij nodig heeft] leest en verbinding maakt met een aparte alleen-lezen credential die via een omgevingsvariabele wordt aangeleverd, nooit met mijn eigen login.
Als de app Supabase gebruikt: activeer Row Level Security voor iedere blootgestelde tabel die hij gebruikt. Noem de select-, insert-, update- en delete-rechten voor anon en authenticated. Verwijder voor deze alleen-lezen app de schrijfrechten die niet nodig zijn; als een andere productieapp van een van die rechten afhankelijk is, meld dat dan in plaats van het te wijzigen. Schrijf daarna beleidsregels zodat afgemelde bezoekers niets kunnen lezen en aangemelde gebruikers alleen [regel, bijvoorbeeld rijen voor hun eigen kostenplaats] kunnen lezen, en bevestig dat er geen geheime of oude service_role-sleutel voorkomt in een bestand dat naar de browser wordt gestuurd.
Noem de beleidsregels die je hebt gemaakt.
Controleer het resultaat: probeer met de credential van het hulpmiddel één schrijfactie uit, zoals het bewerken van een testrecord, en verwacht een weigering. Vraag bij Supabase de rijen van een financiële tabel op terwijl je bent afgemeld, en verwacht een leeg resultaat of een foutmelding.
Zonder tweede goedkeurder in het grootboek laten boeken
Een journaalpostimporter die direct boekt, of een generator van betalingsbestanden die rechtstreeks naar de bank verstuurt, maakt degene die hem gebruikt zowel voorbereider als goedkeurder. Eén bug dupliceert een maand aan overlopende posten. Eén gewijzigd veld stuurt een leveranciersbetaling naar de verkeerde rekening. Dat is de doorbreking van functiescheiding die finance tussen twee mensen weigert toe te staan, en software die met een AI-assistent is gebouwd, krijgt daarop geen uitzondering.
De schade blijft niet in de app. Een foutieve batch komt in de boeken terecht, waar het terugdraaien ervan een correctieboeking en een toelichting bij de afsluiting vereist, en als het hulpmiddel boekt onder de eigen login van de maker, draagt elke dubbele boeking de naam van de maker.
Het AI-gebouwde hulpmiddel leest en bereidt voor; boeken en het vrijgeven van betalingen gebeuren in de eigen goedkeuringsworkflow van het ERP, goedgekeurd door iemand anders dan degene die het hulpmiddel gebruikte. Elke boekhoudengine waaraan ik heb gewerkt, behandelt de boeking en de goedkeuring ervan als twee gebeurtenissen met twee eigenaars, en een AI-gebouwd hulpmiddel verdient dezelfde behandeling.
Zet in de praktijk iedere directe boeking om in een conceptboeking of een klaargezette import die binnen het ERP op goedkeuring wacht. Het hulpmiddel doet nog steeds het tijdrovende werk (mapping, validatie, de batch opbouwen), en de goedkeuring blijft in het ERP, naast alle andere goedkeuringen waarvan de afsluiting afhangt. Heeft het ERP geen goedkeuringsstap voor imports, dan wordt de uitvoer van het hulpmiddel een bestand dat een tweede persoon aan de hand van de batchsamenvatting controleert en vervolgens zelf importeert.
Een tool die automatisch moet boeken, betalingsbestanden maken of leveranciersbankgegevens wijzigen hoort bij IT, onder de voorwaarden in de volgende sectie.
Noem iedere plek waar de app [journaalposten / facturen / betalingen] maakt, wijzigt of boekt in [ERP-naam].
Wijzig elk daarvan zodat de app een conceptboeking of een klaargezette import schrijft die in [ERP-naam] moet worden goedgekeurd voordat er iets wordt geboekt. Als [ERP-naam] geen goedkeuringsstap voor imports heeft, maak dan in plaats daarvan een importbestand en boek niets.
Verwijder codepaden die zonder goedkeuring boeken of betalingen vrijgeven.
Maak per batch een samenvatting met rijenaantal en debet- en credittotalen.
Noem alles wat nog direct boekt, zodat ik het kan controleren.
Controleer het resultaat: voer één batch uit met voorbeeldgegevens. Er mag niets als geboekt verschijnen totdat een tweede gebruiker de batch in het ERP goedkeurt. Vergelijk daarna de batchsamenvatting met wat het ERP voor die batch toont: het aantal rijen, het totaal debet en het totaal credit moeten exact overeenkomen. Een verschil van één rij is een mislukte aansluiting, geen afrondingskwestie.
Financiële gegevens naar diensten buiten je eigen controle sturen
Een functie voor afwijkingscommentaar die het volledige grootboekextract naar een AI-API stuurt, levert elke regel aan een derde partij. Twee minder opvallende routes voeren gegevens naar buiten: een analysescript op de pagina, dat elk bezoek aan zijn leverancier meldt, en een fouttracker of log die volledige verzoekinhoud bewaart, waar salarisregels, bankgegevens van klanten en nog niet gepubliceerde cijfers terecht kunnen komen.
Houd bij een intern hulpmiddel dat door finance is gebouwd ongepubliceerde resultaten en salarisgegevens buiten aanroepen naar derden, tenzij de dienst en de exacte gegevensstroom expliciet zijn goedgekeurd via de leveranciers-, beveiligings- en complianceprocedures van je organisatie. Noem voor alle overige gegevens iedere bestemming en stuur per aanroep alleen de benodigde velden. Of een externe dienst ontvangen gegevens opslaat of voor training gebruikt, moet degene die leveranciersovereenkomsten ondertekent controleren aan de hand van de voorwaarden van die leverancier. Als het team wil weten hoe vaak het hulpmiddel wordt gebruikt, houdt een zelfgehoste analysetool zoals Umami die paginaweergaven op je eigen server.
Noem elke plek waar deze app gegevens naartoe stuurt buiten [onze server], inclusief AI-API’s, analysescripts, fouttracking, e-mail, webhooks en logbestanden.
Noem precies de ontvangen velden per bestemming.
Markeer alles met [salarisbedragen / bankrekeningnummers / ongepubliceerde resultaten / klantnamen].
Laat voor elk gemarkeerd onderdeel zien hoe er minder of geen velden kunnen worden verstuurd, en voer de wijziging pas door nadat ik die heb bevestigd.
Controleer het resultaat: activeer elke functie één keer met voorbeeldgegevens die een herkenbaar fictief rekeningnummer en een fictief salarisbedrag bevatten. Doorzoek de fouttracker en de logs op beide waarden en verwacht niets te vinden. Laat de app voor de AI-API-route tijdens die testrun de inhoud van het uitgaande verzoek loggen, doorzoek die log op dezelfde twee waarden en verwacht dat geen van beide voorkomt en dat alleen de velden aanwezig zijn die je hebt goedgekeurd. Schakel die logging daarna weer uit.
Berekeningen wijzigen zonder registratie of aansluiting
In een rekenhulp voor overlopende posten of een validator voor de omzetwaterval is de code de controle. Wijzig één formule en de cijfers die bij de afsluiting terechtkomen, veranderen mee, en zonder versiebeheer kan niemand zeggen wie wat heeft gewijzigd, of wanneer.
Onder een r/ClaudeAI-thread van een CPA-kantoor over interne tools die het met Claude Code had gebouwd, verwoordde een reageerder de grens onomwonden: “‘accountant + claude code’ werkt tot je tegen audittrail-eisen aanloopt. Dat is het echte plafond.”
Leg het huidige gedrag vast voordat je iets wijzigt; zodra de uitvoer is vastgelegd, kan de logica verbeteren zonder dat de totalen ongemerkt verschuiven. Bewaar de code in versiebeheer, dat elke wijziging met auteur en datum registreert.
Schrijf tests die het hulpmiddel op een vast voorbeeldbestand draaien en de resultaten vergelijken met een vastgelegde baseline, zodat de code een aansluiting moet doorstaan voordat een wijziging live gaat. Een vastgelegde test beschermt alles wat hij vastlegt, fouten inbegrepen, dus sluit de baselinetotalen eerst aan op de ERP-totalen voor die periode voordat je erop vertrouwt.
Laat een tweede persoon elke wijziging in de rekenlogica controleren en sluit iedere productierun aan op de eigen totalen van het ERP.
Zet dit project onder versiebeheer als dat nog niet zo is, en noem de bestanden die rekenlogica bevatten.
Schrijf tests die de app op [voorbeeldbestand] draaien en de huidige uitvoer vastleggen: rijaantallen en totalen per [rekening / entiteit / periode].
Toon me de totalen voordat je de vastgelegde uitvoer opslaat, zodat ik ze kan aansluiten op [ERP-naam] voor [periode].
Iedere wijziging van zo’n totaal moet een test laten falen.
Wijzig de rekenlogica niet terwijl je de tests schrijft.
Controleer het resultaat: wijzig opzettelijk één berekening, bijvoorbeeld een afrondingsregel, en controleer dat een test faalt. Draai de wijziging terug en controleer dat alle tests weer slagen.
Standaard privé, bedrijfslogin voor meer mensen, IT voor het grootboek

Echte financiële gegevens blijven nooit op de hosting van de AI-tool staan. Om een AI-gebouwde financiële app veilig uit te rollen voor alleen het financiële team, zet je hem op een server die je zelf beheert en die alleen via een privénetwerk bereikbaar is. Voeg bedrijfslogin toe wanneer mensen buiten het team toegang nodig hebben, en draag hem over aan IT zodra iets uit de onderstaande lijst van toepassing is.
Een VPS is een gehuurde virtuele server waarvan je het besturingssysteem en de softwarestack zelf beheert. Een privénetwerk (in de termen van Tailscale een tailnet) verbindt goedgekeurde apparaten met die server. Om het hulpmiddel van het open internet te houden, moet je openbare inkomende toegang tot de app nog steeds blokkeren, bijvoorbeeld met de firewall van de server, en de app alleen via de VPN- of tailnet-interface beschikbaar maken. Een identiteitsprovider bevat de gebruikersaccounts van het bedrijf, en een reverse proxy is de poortwachter vóór de app die elk verzoek eerst langs de aanmelding stuurt.
| Uitrolniveau | Wie toegang heeft | Geschikt voor | Uitvoeringsomgeving |
|---|---|---|---|
| Alleen privénetwerk | Het financiële team op eigen apparaten | Aansluithulpen, kasprognoses, checklists voor de afsluiting, alles wat nog niet gepubliceerde cijfers toont | Een VPS met een uitrollaag zoals Coolify of Dokku, alleen bereikbaar via Tailscale of WireGuard |
| Bedrijfslogin ervoor | Benoemde mensen in het hele bedrijf, zoals budgethouders en afdelingshoofden | Budget-werkelijkheidsoverzichten, uitgavenaanvragen | Niveau 1 plus een identiteitsprovider (Authentik of Keycloak) achter een reverse proxy (Caddy of Nginx Proxy Manager) |
| IT of engineering is eigenaar | Wie IT bepaalt | Elke tool die voldoet aan een voorwaarde uit de lijst voor overdracht aan IT | Eigen IT-platform |
De eigen hosting van de AI-tool blijft buiten de tabel om de redenen die bij de eerste fout zijn genoemd. Dat geldt ook voor een enterprise-uitrolplatform zoals Northflank, dat past bij grotere organisaties die al budget hebben voor platformleveranciers en de beoordelingen die daarvoor nodig zijn. Dat is meer contract dan een afdelingstool met een handvol gebruikers nodig heeft.
In mijn ervaring is Tailscale de snelst uit te rollen van de twee privénetwerkopties, maar Tailscale host zelf de coördinatiedienst. WireGuard is de volledig zelfgehoste optie.
Mijn reden om het privénetwerk de standaard te maken: een tool die niet vanaf internet antwoordt, kan niet via een zoekopdracht worden gevonden of op zijn loginpagina worden aangevallen, terwijl een loginpagina die de AI-tool heeft geschreven slechts zo goed is als de door AI geschreven code erachter. Als je de app buiten het privénetwerk toegankelijk moet maken, voegt bedrijfslogin er een beheerde authenticatielaag vóór toe; daarom komt die op de tweede plaats.
Wanneer budgethouders toegang nodig hebben, vervang je de eigen login van het hulpmiddel door bedrijfslogin, ook wel single sign-on (SSO) genoemd: mensen gebruiken het bedrijfsaccount dat ze al hebben, dus als dat account wordt gedeactiveerd, worden nieuwe aanmeldingen geblokkeerd. Configureer sessie-intrekking, back-channel-logout of voldoende korte sessieduur, zodat bestaande sessies niet blijven hangen. De prompt gebruikt OIDC, een standaard aanmeldprotocol dat zowel Authentik als Keycloak ondersteunt.
Vervang de eigen login van deze app door bedrijfslogin via [Authentik / Keycloak / onze identiteitsprovider] met OIDC.
Lees de groep van elke gebruiker uit de aanmelding.
Sta [de salarispagina’s] alleen toe voor leden van [groepsnaam], en dwing die regel serverzijdig af voor iedere pagina, iedere export en ieder API-endpoint, niet alleen in het menu.
Weiger ieder verzoek zonder geldige login.
Controleer het resultaat: meld je aan met een testaccount dat niet in de groep zit, vraag de afgeschermde pagina en het bijbehorende export- of API-adres rechtstreeks op en verwacht bij beide een weigering. Deactiveer daarna het testaccount in de identiteitsprovider en controleer dat het geen nieuwe sessie kan starten. Controleer ook dat een bestaande sessie wordt ingetrokken of verloopt binnen de termijn die je hebt ingesteld.
Sommige tools horen helemaal niet bij het team te blijven. Draag het hulpmiddel over aan IT of engineering wanneer een van deze punten geldt:
- Het boekt in het grootboek of een ander bronsysteem zonder dat een persoon de boeking in het ERP goedkeurt.
- Het maakt betalingsbestanden, geeft betalingen vrij of wijzigt leveranciersbankgegevens.
- De uitvoer komt terecht in de jaarrekening van een bij de SEC geregistreerde onderneming, waardoor de tool onder de interne controle op de financiële verslaggeving (ICFR) kan vallen. Bespreek dit met interne audit voordat de tool bij de afsluiting wordt gebruikt; bij uitgevende instellingen die onder SOX Section 404(b) vallen, kan ook de externe accountant de relevante controles testen.
- Het slaat betaalkaartgegevens op, verwerkt of verzendt ze.
- Het beoordeelt de kredietwaardigheid van individuele personen.
- Niemand in het team neemt patches, toegangsreviews en de uitfasering ervan op zich.
De zesde voorwaarde weegt zwaarder dan ze lijkt. Bij zelfhosting beheer je zelf updates, backups en monitoring, en een financieel hulpmiddel dat niemand onderhoudt, is veiliger bij IT. IT is misschien trager; dat is de prijs van de governance die deze voorwaarden vereisen.
Voor niveaus 1 en 2 moeten een server, een uitrollaag, een privénetwerk en, voor niveau 2, een identiteitsprovider allemaal klaarstaan voordat iemand het hulpmiddel opent, en een financieel team zonder engineer moet dat zelf opzetten. Op onze Linux VPS krijg je roottoegang. Coolify en WireGuard zijn beschikbaar als uitrol met één klik; Tailscale installeer je met de officiële installer in één opdracht, terwijl Authentik draait vanuit de officiële Docker Compose-stack. De uren van het team kunnen dan naar de bovenstaande oplossingen gaan in plaats van naar het vanaf nul opbouwen van de uitrolstack. Onze locaties omvatten Frankfurt en Amsterdam in de EU, Londen in het VK en meerdere Amerikaanse steden, zodat je de regio voor de primaire VPS-opslag van de app kunt kiezen; of die keuze aanvaardbaar is, blijft een beslissing van compliance.
Regels om per regio met je complianceteam te controleren
Welke kaders van toepassing zijn, hangt af van welke gegevens het hulpmiddel raakt en waar het bedrijf en de mensen in de gegevens zich bevinden. Een salaristabel met de salarissen van werknemers in de EU en een omzetoverzicht dat de jaarrekening van een in de VS beursgenoteerde onderneming voedt, kunnen onder verschillende kaders vallen.
Niets in dit artikel is juridisch advies. De tabel hieronder noemt kaders om met je complianceteam te bespreken en bepaalt niet of een ervan op jou van toepassing is.
| Waar / Wanneer | Compliancekader | Vraag aan compliance | Bron |
|---|---|---|---|
| VS, bedrijven die aan SEC rapporteren | Sarbanes-Oxley Section 404, interne controle op financiële verslaggeving (ICFR) | Voedt de uitvoer van deze tool de financiële overzichten en hoort hij in onze inventaris van controles? | PCAOBs AS 2201 |
| EU, persoonsgegevens (salarissen, personeelskosten, klantbankgegevens) | GDPR | Wat is onze rechtsgrond voor deze gegevens in deze tool, en voldoen de beveiligingsmaatregelen ervan aan artikel 32? | EDPB-gids voor beveiliging van persoonsgegevens |
| VK, persoonsgegevens | UK GDPR | Wat is onze UK GDPR-rechtsgrond en voldoet de tool aan het beveiligingsbeginsel? | ICO-gids voor gegevensbeschermingsbeginselen |
| Overal waar kaartgegevens betrokken zijn | PCI DSS (industrienorm, zelf geen wet) | Brengt deze tool kaartgegevens binnen de scope, en kan hij kaartgegevens helemaal vermijden? | PCI Security Standards Council over PCI DSS |
| EU, als de tool de kredietwaardigheid van individuele personen beoordeelt (hoogrisicoregels van bijlage III gelden momenteel vanaf 2 december 2027) | EU AI Act, hoogrisicocategorie (AI voor financiële fraudedetectie uitgezonderd) | Is dit een AI-systeem met een hoog risico volgens bijlage III? | AI-Act-pagina van de Europese Commissie; bijlage III van de AI Act |
| EU- of VK-persoonsgegevens die beschikbaar worden gesteld aan een afzonderlijke ontvanger buiten het toepasselijke rechtsgebied, of klantcontracten die vastleggen waar records worden opgeslagen | GDPR hoofdstuk V, VK-regels voor internationale doorgifte, klantafspraken | Mogen deze gegevens op een server in [locatie] staan, en beperkt een klantcontract dat? | EDPB-gids over internationale doorgifte; ICO-richtlijnen over internationale doorgifte |
Voor de SOX-rij geldt: AS 2201 is de PCAOB-norm voor de verklaring van de accountant waarnaar Section 404(b) van de Sarbanes-Oxley Act verwijst, en die norm noemt controles op journaalposten en correcties in het afsluitproces van de financiële verslaggeving aan het einde van de periode als onderdeel van de controles die een accountant beoordeelt bij het aanpakken van frauderisico. Begin buiten deze regio’s bij de eigen website van je nationale toezichthouder voor gegevensbescherming. De locatie van een server bepaalt waar de primaire opslag staat; ze vertelt je niet waar elke backup, log of kopie bij derden zich bevindt, en voldoet op zichzelf aan geen enkel kader hierboven.
Veelgestelde vragen
Is vibe coding veilig voor financiële tools?
Dat kan, zodra de gaten die een demo achterlaat zijn gedicht; ik lees het bewijs eerder als een uitrolprobleem dan als een programmeerprobleem. Een financieel hulpmiddel is riskanter dan een persoonlijk project, omdat het het ERP leest en in de boeken kan schrijven. Zodra het zonder tweede goedkeurder boekt, betalingen afhandelt of met kaartgegevens werkt, hoort het bij IT.
Wat is shadow AI in finance?
Shadow AI omvat AI-tools of AI-gebouwde apps die zonder medeweten of goedkeuring van IT met bedrijfsgegevens worden gebruikt, zoals een aan het ERP gekoppeld prognosedashboard dat IT nog nooit heeft gezien. IBMs Cost of a Data Breach Report 2025 stelde vast dat organisaties met veel shadow AI gemiddeld 670.000 dollar hogere kosten van datalekken hadden dan organisaties met weinig of geen shadow AI, volgens IBMs aankondiging.
Wat moeten we aan interne audit of de externe accountant laten zien?
Breng vier zaken mee voordat het hulpmiddel bij de afsluiting wordt gebruikt: waar het draait en wie er toegang toe heeft, de wijzigingsgeschiedenis met de tests op vastgelegde uitvoer, hoe boekingen in het ERP worden goedgekeurd, en het aansluitingsbewijs waarmee elke batch op de ERP-totalen wordt aangesloten. Wat de accountant vereist, bepaalt de accountant zelf; deze zaken geven iets concreets om te beoordelen.
Wie is verantwoordelijk voor een AI-gebouwd financieel hulpmiddel nadat de maker vertrekt?
Benoem vóór de lancering een verantwoordelijke binnen finance en een technisch contact. Gebruik dienstcredentials in plaats van de eigen login van de maker en laat toegang via bedrijfslogin verlopen. Het deactiveren van het account van een vertrekkende medewerker blokkeert nieuwe aanmeldingen; bestaande sessies worden ingetrokken of verlopen volgens je sessiebeleid. De tool uitfaseren betekent credentials uitschakelen, bewaren wat je bewaarbeleid vereist, de rest verwijderen en de tool afsluiten.
Discussie
Reacties
Log in om mee te praten.