Sådan kan økonomiafdelinger sætte AI-byggede apps i drift uden at lække finansielle data

Da sikkerhedsfirmaet RedAccess ledte efter apps bygget med AI-kodningsværktøjer og offentliggjort på værktøjernes egen hosting, fandt det mere end 5.000 med stort set ingen sikkerhed eller autentifikation. Blandt skærmbillederne, som firmaet delte med Wired, var »forskellige salgs- og finansielle poster fra en række andre virksomheder«. AI-byggede apps til økonomiafdelinger kan ende på samme slags åbne adresse med hovedbog, løndata og endnu ikke offentliggjorte resultater bagved.

Replits CEO, Amjad Masad, svarede, at »Det er forventet adfærd, at offentlige apps er tilgængelige på internettet«. Han har ret om mekanismen. Efter min vurdering skyldtes eksponeringen en synlighedsindstilling og en sprunget gennemgang, og begge dele kan personen, der byggede værktøjet, gøre noget ved.

TL;DR

• Et AI-bygget økonomiværktøj kan lække data gennem seks implementeringsfejl, som byggeren selv kan rette: et offentligt link, adgangskoder og nøgler i kode eller chathistorik, databaseadgang på administratorniveau, bogføring uden en anden godkender, data sendt til eksterne tjenester og beregningsændringer, som ingen registrerede.
• Hver fejl har en løsning, og de fleste kan anvendes gennem det samme AI-værktøj, der byggede appen, med en enkel kontrol, som beviser, at løsningen virker, såsom en skriveoperation, databasen afviser, eller en gammel adgangskode, der ikke længere virker.
• Hold som udgangspunkt et økonomiværktøj på et privat netværk, tilføj virksomhedslogin, når personer uden for økonomiafdelingen har brug for det, og overdrag det til IT, når det bogfører uden en anden godkender, berører kortdata eller leverer tal til regnskaber omfattet af SOX.
• Serverregionen bestemmer, hvor appens primære VPS-lager befinder sig, men sikkerhedskopier, logfiler og tredjepartstjenester kan oprette kopier andre steder; om den samlede opsætning overholder kravene, er et særskilt spørgsmål. Tag din regions regelsæt med til dit complianceteam.

Implementeringsfejlene, der lækker finansielle data

Et AI-bygget økonomiværktøj kan lække data gennem seks implementeringsfejl: at lade det ligge på et offentligt link, opbevare legitimationsoplysninger i kode eller chat, bruge administratoradgang, når læseadgang er nok, bogføre uden en anden godkender, sende finansielle data til eksterne tjenester og ændre beregninger uden registrering. Alle er standardvalg, som fungerer godt i en demo.

Hver løsning nedenfor har en prompt til det AI-værktøj, der byggede appen; ret felterne i kantede parenteser, før du indsætter den. Prompterne er uprøvede udgangspunkter skrevet til denne artikel, og at dit AI-værktøj siger, at det har ændret noget, beviser intet. Kontrollen under hver prompt er beviset. Kør prompterne mod koden og et eksempel- eller syntetisk datasæt, og indsæt aldrig rigtige poster eller aktive nøgler i chatten.

At lade værktøjet ligge på AI-byggerens offentlige link

Et cashflow-prognosedashboard, der ligger offentligt på AI-byggerens hosting, kan åbnes af alle, der kender adressen, sammen med alt, det viser: aldersfordeling af kreditorposter, budget mod realiseret og kvartalets resultater, før de offentliggøres. Wireds artikel om RedAccess' resultater beskriver, hvordan forskerne fandt sådanne apps med enkle Google- og Bing-søgninger på AI-leverandørernes domæner.

Nogle af disse apps bad blot besøgende om at logge ind med en vilkårlig e-mailadresse. Et login, der accepterer enhver e-mailadresse, er ikke adgangskontrol.

Fjern rigtige data fra leverandørens hosting. Indtil værktøjet kører på en server, du kontrollerer (næste afsnit beskriver hvor), skal du bygge og demonstrere det med syntetiske data eller dit ERP-systems sandkasse eller testvirksomhed, hvis det har en, aldrig en eksport af rigtige data. Implementer igen efter ændringen, for den hostede adresse viser den sidst implementerede version.

Opret et syntetisk datasæt til denne app, der svarer til de tabeller og kolonner, den læser: [angiv tabeller og kolonner, f.eks. vendors, invoices, journal_lines].

Brug opdigtede leverandør- og kundenavne, opdigtede bankkontonumre og beløb i [valuta], der opfører sig som rigtige regnskaber: hver journalpost balancerer, og underbogens totaler stemmer med [kontrolkontoen for kreditorer / debitorer].

Peg appen på dette datasæt i stedet for en eksport af rigtige data, og angiv hver fil eller indstilling, du ændrede.

Bed mig ikke om rigtige poster.

Bekræft, at det virkede: åbn leverandørens hostede adresse fra en browser uden login, eller bed en kollega uden for økonomiafdelingen gøre det, og bekræft, at den kun viser syntetiske data, en loginbarriere eller ingenting. Søg derefter i appens datafiler og kodearkivet efter tre leverandør- eller kundenavne fra dit rigtige ERP-system; der må ikke være match. Kør til sidst appens saldobalance eller oversigtsvisning og bekræft, at samlet debet er lig samlet kredit.

At efterlade ERP-, bankfeed- og databaselegitimationsoplysninger i koden eller chatten

Hvis aktive legitimationsoplysninger ligger der, kan alle, der kan læse chathistorikken, kodearkivet eller MCP-konfigurationsfilen, muligvis også bruge dem til at nå ERP-systemet, økonomidatabasen eller bankfeed-integrationen. MCP er forbindelsen, der lader et AI-værktøj som Claude tale direkte med ERP eller en database, og konfigurationsfilen er endnu et sted, hvor en adgangskode kan ligge.

GitGuardians State of Secrets Sprawl 2026 fandt 24.008 unikke hemmeligheder eksponeret i MCP-konfigurationsfiler, hvoraf 14% var PostgreSQL-databaseforbindelsesstrenge. I offentlige GitHub-commits fandt samme rapport, at commits med Claude Code som medforfatter lækkede hemmeligheder omkring dobbelt så ofte som basisraten, og den tilføjer, at den menneskelige faktor også fortsat er afgørende.

At slette chatbeskeden ophæver ikke eksponeringen: alle med en kopi af chatten, kodearkivet eller dets historik har stadig værdien. For hver adgangskode, nøgle eller token, der nogensinde lå et af disse steder, skal du udstede en ny i administrationskonsollen for ERP, database eller bankfeed og deaktivere den gamle. Det er, hvad rotation af legitimationsoplysninger betyder.

Appen læser derefter sine legitimationsoplysninger ved opstart fra miljøvariabler (navngivne indstillinger uden for koden), leveret af implementeringslaget, som bygger og kører appen på din server. HashiCorp Vault er næste skridt, når flere værktøjer deler hemmeligheder og har brug for at rotere dem fra ét sted.

Teamets egne kopier af adgangskoder hører til i en adgangskodeadministrator beregnet til mennesker som Vaultwarden; den kørende app læser værdierne fra miljøet. Start med at finde alle hardkodede hemmeligheder i den AI-genererede kode.

Undersøg dette projekt for hardkodede hemmeligheder. Find hver adgangskode, API-nøgle, adgangstoken og forbindelsesstreng, også i .env-filer, notebooks, MCP-konfigurationsfiler og koden, der forbinder til [ERP-navn / bankfeed-leverandør / økonomidatabase].

Erstat hver værdi i koden med en navngiven miljøvariabel, og giv mig listen over variabelnavne.

Sørg for, at ingen fil med rigtige værdier committes til kodearkivet, og angiv hver commit i arkivets historik, hvor en af disse værdier findes.

Vis mig kun placeringerne. Udskriv ikke nogen hemmelig værdi.

Bekræft, at det virkede: prøv selv den gamle adgangskode eller token, eller bed IT gøre det; den skal afvises. Søg derefter i de aktuelle projektfiler efter de gamle værdier; der må ikke være nogen. Et match i historikken giver først ikke længere adgang, når du har bekræftet, at værdien er tilbagekaldt eller udløbet.

At forbinde med byggerens administratorlogin, når værktøjet kun skal læse

Et dashboard, der viser aldersfordeling af debitorposter, må ikke kunne redigere hovedbogen. Hvis værktøjet forbinder med byggerens administratorlogin, arver det kontoens rettigheder. En hemmelig Supabase-nøgle eller den ældre service_role-nøgle giver forhøjet adgang til projektets data og omgår Row Level Security, så den bør ikke bruges til almindelig læseadgang. En rapport til én aldersfordeling eksponerer da hele hovedbogen, inklusive løntabeller.

Det bliver dyrt på skrivesiden. Symbiotic Securitys scanning af 1.072 AI-byggede apps med Supabase fandt 172, der lod alle slette poster uden autentifikation, 172, der lod alle ændre eksisterende poster, og 39 med tabeller, som alle med den offentlige nøgle kunne læse fuldt ud.

Giv værktøjet legitimationsoplysninger med læseadgang begrænset til de tabeller, det læser. I ERP eller databasen betyder det en dedikeret integrationsbruger: en separat konto til værktøjet med læseadgang til de objekter, rapporten behøver, og intet andet. I Supabase skal du aktivere Row Level Security (databasereglen, der bestemmer, hvilke rækker hver anmodning må se) for alle eksponerede tabeller, værktøjet bruger, og også gennemgå tabelrettighederne: rettigheder bestemmer, om en rolle overhovedet må udføre select, insert, update eller delete. Rollen i en økonomiapp med kun læseadgang bør ikke have skriveoperationer, den ikke behøver. En publishable-nøgle kan ligge i browserkoden, når RLS og mindst mulige rettigheder er korrekte. Hemmelige og ældre service_role-nøgler skal forblive på serversiden og forbeholdes backendopgaver, der reelt behøver forhøjet adgang og håndhæver deres egen autorisation.

Bemærk: Det er normalt, at en Supabase publishable-nøgle eller den ældre anon-nøgle er synlig i sidens JavaScript. Supabases dokumentation om API-nøgler siger, at den kun når det, Row Level Security tillader. Den hemmelige nøgle omgår Row Level Security og må derfor aldrig forekomme i noget, der sendes til en browser.

Angiv hver læsning og skrivning, denne app foretager i [ERP- eller databasenavn], grupperet efter tabel eller objekt.

Ændr appen, så den kun læser [de nødvendige tabeller] og forbinder med separate legitimationsoplysninger til læseadgang leveret gennem en miljøvariabel, aldrig mit eget login.

Hvis appen bruger Supabase: Aktivér Row Level Security for hver eksponeret tabel, den berører. Angiv select-, insert-, update- og delete-rettighederne for anon og authenticated. Fjern unødvendige skriverettigheder for denne app med kun læseadgang; hvis en anden produktionsapp afhænger af en af dem, markér den i stedet for at ændre den. Skriv derefter politikker, så besøgende uden login intet kan læse, og brugere med login kun kan læse [regel, f.eks. rækker for deres eget omkostningssted], og bekræft, at ingen hemmelig eller ældre service_role-nøgle findes i nogen fil sendt til browseren.

Angiv de politikker, du oprettede.

Bekræft, at det virkede: brug værktøjets legitimationsoplysninger til én skriveoperation, f.eks. at redigere en testpost; den skal afvises. For Supabase: Anmod om rækker fra en økonomitabel uden login; forvent et tomt resultat eller en fejl.

At lade værktøjet bogføre uden en anden godkender

En journalimportør, der bogfører direkte, eller en betalingsfilgenerator, der sender direkte til banken, gør den, som kører den, til både forbereder og godkender. Én fejl dublerer en måneds periodiseringer. Ét ændret felt sender en leverandørbetaling til den forkerte konto. Det er den manglende funktionsadskillelse, økonomiafdelingen ikke accepterer mellem to mennesker, og software bygget med en AI-assistent får ingen undtagelse.

Skaden bliver ikke i appen. En fejlagtig batch ender i regnskabet, hvor den kræver en korrektionspost og en forklaring ved periodeafslutningen at omgøre. Når værktøjet bogfører under byggerens eget login, bærer hver dubleret post byggerens navn.

Det AI-byggede værktøj læser og forbereder; bogføring og frigivelse af betaling sker i ERP-systemets eget godkendelsesflow, godkendt af en anden end den, der kørte værktøjet. Alle regnskabssystemer, jeg har arbejdet på, behandler posten og dens godkendelse som to begivenheder med to ejere, og et AI-bygget værktøj fortjener samme behandling.

Gør i praksis hver direkte bogføring til en kladdepost eller klargjort import, der venter på godkendelse i ERP. Værktøjet udfører stadig det kedelige arbejde (mapping, validering og batchopbygning), og godkendelsen bliver i ERP sammen med alle andre godkendelser, som periodeafslutningen afhænger af. Hvis ERP ikke har et godkendelsestrin til importer, bliver værktøjets output en fil, som en anden person gennemgår mod batchoversigten og selv importerer.

Et værktøj, der skal bogføre automatisk, generere betalingsfiler eller ændre leverandørers bankoplysninger, hører hos IT under betingelserne i næste afsnit.

Angiv hvert sted, hvor denne app opretter, redigerer eller bogfører [journalposter / fakturaer / betalinger] i [ERP-navn].

Ændr hvert sted, så appen skriver en kladdepost eller klargjort import, som skal godkendes i [ERP-navn], før den bogføres. Hvis [ERP-navn] ikke har et godkendelsestrin for importer, skal du i stedet producere en importfil og ikke bogføre noget.

Fjern enhver kodevej, der bogfører eller frigiver en betaling uden den godkendelse.

Lav for hver batch en oversigt med rækkeantal, samlet debet og samlet kredit.

Angiv alt, der stadig bogfører direkte, så jeg kan gennemgå det.

Bekræft, at det virkede: kør én batch med eksempeldata. Intet må fremstå som bogført, før en anden bruger godkender det i ERP. Sammenlign derefter batchoversigten med det, ERP viser for samme batch: rækkeantal, samlet debet og samlet kredit skal stemme præcist. En forskel på én række er en mislykket afstemning, ikke et afrundingsproblem.

At sende finansielle data til tjenester uden for din kontrol

En funktion til kommentarer om afvigelser, der sender hele hovedbogsudtrækket til et AI-API, sender hver linje til en tredjepart. To mere diskrete veje fører data ud: et analysescript på siden, der rapporterer hvert besøg til leverandøren, og en fejltracker eller log, der gemmer hele anmodningsindholdet, hvor lønposter, kunders bankoplysninger og tal før offentliggørelse kan ende.

For et internt værktøj bygget af økonomiafdelingen skal du holde ikke-offentliggjorte resultater og løndata ude af tredjepartskald, medmindre tjenesten og det præcise dataflow udtrykkeligt er godkendt gennem organisationens leverandør-, sikkerheds- og complianceproces. For alt andet: Angiv alle destinationer, og send kun de nødvendige felter i hvert kald. Om en ekstern tjeneste gemmer eller træner på det modtagne, er et spørgsmål for den, som underskriver leverandøraftaler, og skal undersøges mod leverandørens egne vilkår. Hvis teamet vil kende værktøjets brugsfrekvens, holder et selvhostet analyseværktøj som Umami sidevisningerne på din egen server.

Angiv hvert sted, hvor denne app sender data uden for [vores server], inklusive AI-API'er, analysescripts, fejltracking, e-mail, webhooks og logfiler.

Angiv for hver destination præcis hvilke felter, den modtager.

Markér alt, der indeholder [lønbeløb / bankkontonumre / resultater før offentliggørelse / kundenavne].

Vis for hvert markeret element, hvordan færre eller ingen felter kan sendes, og foretag først ændringen, når jeg har bekræftet den.

Bekræft, at det virkede: udløs hver funktion én gang med eksempeldata med et genkendeligt falsk kontonummer og et falsk lønbeløb. Søg efter begge værdier i fejltrackeren og logfilerne; intet må findes. For AI-API-vejen: Lad appen logge den udgående anmodnings indhold under prøvekørslen, søg efter de samme to værdier i loggen, og forvent ingen af dem og kun de godkendte felter. Slå den logning fra bagefter.

At ændre beregninger uden registrering og afstemning

I en periodiseringsberegner eller en validator af indtægtsfordeling over tid er koden kontrollen. Ændr én formel, og tallene til periodeafslutningen ændres med den; uden versionsstyring kan ingen sige, hvem der ændrede hvad eller hvornår.

I en CPA-virksomheds tråd på r/ClaudeAI om interne værktøjer bygget med Claude Code formulerede en kommentator grænsen direkte: »'regnskabsmedarbejder + claude code' virker, indtil man rammer kravene til revisionsspor. Det er det reelle loft.«

Fastlås dagens adfærd, før du ændrer noget; når outputtet er låst, kan logikken forbedres, uden at totalerne forskyder sig ubemærket. Hold koden i versionsstyring, som registrerer hver ændring med forfatter og dato.

Skriv tests, der kører værktøjet på en fast eksempelfil og sammenligner resultaterne med en registreret baseline, så koden skal bestå en afstemning, før en ændring udgives. En låst test beskytter det, den registrerer, inklusive fejl, så afstem baselinens totaler med ERP-systemets totaler for perioden, før du stoler på dem.

Kræv, at en anden person gennemgår enhver ændring i beregningslogikken, og afstem hver produktionskørsel med ERP-systemets egne totaler.

Læg dette projekt under versionsstyring, hvis det ikke allerede er det, og angiv hvilke filer der indeholder beregningslogik.

Skriv tests, der kører appen på [eksempelfil] og registrerer dagens output: rækkeantal og totaler efter [konto / enhed / periode].

Vis mig totalerne, før du gemmer det registrerede output, så jeg kan afstemme dem med [ERP-navn] for [periode].

Enhver ændring, der ændrer en af disse totaler, skal få en test til at fejle.

Ændr ikke beregningslogikken, mens du skriver testene.

Bekræft, at det virkede: ændr bevidst en beregning, f.eks. en afrundingsregel, og bekræft, at en test fejler. Tilbagefør ændringen, og bekræft, at alle tests består igen.

Privat som standard, virksomhedslogin til flere brugere, IT til hovedbogen

Rigtige finansielle data bliver aldrig på AI-værktøjets hosting. For sikkert at sætte en AI-bygget økonomiapp i drift for økonomiafdelingen alene skal du lægge den på en server, du kontrollerer, kun tilgængelig via et privat netværk. Tilføj virksomhedslogin, når personer uden for teamet behøver det, og overdrag den til IT, hvis noget på listen nedenfor gælder.

En VPS er en lejet virtuel server, hvor du kontrollerer operativsystemet og softwarestakken. Et privat netværk (en tailnet hos Tailscale) forbinder godkendte enheder til serveren. For at holde værktøjet væk fra det åbne internet skal du stadig blokere offentlig indgående adgang til appen, f.eks. med serverens firewall, og kun eksponere den via VPN- eller tailnet-interfacet. En identitetsudbyder opbevarer virksomhedens brugerkonti, og en reverse proxy er portvagten foran appen, som først sender enhver anmodning gennem login.

AI-værktøjets egen hosting er ikke med i tabellen af grundene under den første fejl. Det er en virksomhedsplatform til implementering som Northflank heller ikke; den passer til større organisationer, der allerede budgetterer med platformleverandører og de nødvendige gennemgange. Det er mere kontraktarbejde, end et afdelingsværktøj med få brugere behøver.

Efter min erfaring er Tailscale den hurtigste af de to private netværksmuligheder at udrulle, men Tailscale hoster selv koordineringstjenesten. WireGuard er det fuldt selvhostede valg.

Min begrundelse for at vælge privat netværk som standard: Et værktøj, der ikke svarer fra internettet, kan ikke findes ved søgning eller angribes på sin loginside, mens en loginside skrevet af AI-værktøjet kun er så god som AI-koden bag den. Hvis du skal eksponere appen ud over det private netværk, tilføjer virksomhedslogin et administreret autentifikationslag foran den, og derfor kommer det som nummer to.

Når budgetansvarlige behøver adgang, skal du erstatte værktøjets eget login med virksomhedslogin, også kaldet single sign-on (SSO): Folk bruger den virksomhedskonto, de allerede har, så deaktivering af kontoen blokerer nye login. Konfigurer tilbagekaldelse af sessioner, back-channel logout eller passende korte sessionstider, så eksisterende sessioner ikke fortsætter. Prompten bruger OIDC, en standardloginprotokol, som både Authentik og Keycloak understøtter.

Erstat appens eget login med virksomhedslogin gennem [Authentik / Keycloak / vores identitetsudbyder] med OIDC.

Læs hver brugers gruppe fra loginoplysningerne.

Tillad kun [lønsiderne] for medlemmer af [gruppenavn], og håndhæv reglen på serveren for hver side, hver eksport og hvert API-endpoint, ikke kun i menuen.

Afvis enhver anmodning uden et gyldigt login.

Bekræft, at det virkede: log ind med en testkonto, der ikke er i gruppen, anmod direkte om den begrænsede side og dens eksport- eller API-adresse, og forvent afvisning af begge. Deaktivér derefter testkontoen hos identitetsudbyderen, og bekræft, at den ikke kan starte en ny session. Bekræft også, at en eksisterende session tilbagekaldes eller udløber inden for det konfigurerede tidsrum.

Nogle værktøjer bør slet ikke blive hos teamet. Overdrag værktøjet til IT eller udviklingsafdelingen, hvis noget af følgende gælder:

1. Det bogfører i hovedbogen eller et andet autoritativt registreringssystem uden en persons godkendelse i ERP.
2. Det genererer betalingsfiler, frigiver betalinger eller ændrer leverandørers bankoplysninger.
3. Dets output indgår i regnskaberne for en SEC-registreret virksomhed, hvilket kan bringe værktøjet ind under intern kontrol med finansiel rapportering (ICFR). Tag det op med intern revision, før det bruges ved periodeafslutningen; for udstedere under SOX Section 404(b) kan den eksterne revisor også teste relevante kontroller.
4. Det lagrer, behandler eller overfører betalingskortdata.
5. Det vurderer enkeltpersoners kreditværdighed.
6. Ingen i teamet vil tage ansvar for patching, adgangsgennemgange og afvikling af værktøjet.

Den sjette betingelse vejer tungere, end den ser ud til. Med selvhosting ejer du opdateringer, sikkerhedskopier og overvågning, og et økonomiværktøj, som ingen vedligeholder, er sikrere hos IT. IT kan være langsommere; det er prisen for den styring, disse betingelser kræver.

For niveau 1 og 2 skal en server, et implementeringslag, et privat netværk og for niveau 2 en identitetsudbyder være klar, før nogen åbner værktøjet, og en økonomiafdeling uden en udvikler skal selv etablere det. På vores Linux VPS får du root-adgang. Coolify og WireGuard findes som implementeringer med ét klik; Tailscale installeres med sin officielle installer med én kommando, mens Authentik kører fra sin officielle Docker Compose-stack. Teamets timer kan derefter bruges på løsningerne ovenfor frem for at bygge implementeringsstakken fra bunden. Vores lokationer omfatter Frankfurt og Amsterdam i EU, London i Storbritannien og flere amerikanske byer, så du kan vælge regionen til appens primære VPS-lager; om valget kan accepteres, afgøres stadig af compliance.

Regler, du bør gennemgå med dit complianceteam, efter region

Hvilke regelsæt der gælder, afhænger af, hvad værktøjet berører, og hvor virksomheden og personerne i dataene er. En løntabel med EU-medarbejderes løn og en indtægtsoversigt, der indgår i en amerikansk børsnoteret virksomheds regnskab, kan være omfattet af forskellige regelsæt.

Intet i denne artikel er juridisk rådgivning. Tabellen nedenfor angiver regelsæt, du kan tage op med dit complianceteam, og afgør ikke, om nogen af dem gælder for dig.

For SOX-rækken er AS 2201 PCAOB-standarden for den revisorerklæring, Section 404(b) i Sarbanes-Oxley Act henviser til. Den nævner kontroller med journalposter og reguleringer i periodens afsluttende regnskabsproces blandt de kontroller, en revisor vurderer ved håndtering af svigrisiko. Uden for disse regioner skal du begynde på din nationale databeskyttelsesmyndigheds eget websted. En servers placering bestemmer, hvor dens primære lager ligger; den fortæller ikke, hvor hver sikkerhedskopi, log eller tredjepartskopi findes, og opfylder ikke i sig selv nogen af regelsættene ovenfor.

Ofte stillede spørgsmål

Er vibe coding sikkert til økonomiværktøjer?

Det kan det være, når hullerne fra en demo er lukket; jeg læser evidensen som mere et implementeringsproblem end et kodeproblem. Et økonomiværktøj er mere risikabelt end et personligt projekt, fordi det læser ERP og kan skrive i regnskabet. Så snart det bogfører uden en anden godkender, håndterer betalinger eller berører kortdata, hører det til hos IT.

Hvad er skygge-AI i økonomiafdelingen?

Skygge-AI er AI-værktøjer eller AI-byggede apps, der bruges på virksomhedsdata uden IT's viden eller godkendelse, f.eks. et ERP-forbundet prognosedashboard, som IT aldrig har set. IBM's Cost of a Data Breach Report 2025 fandt, at organisationer med meget skygge-AI i gennemsnit havde omkostninger ved databrud, der var 670.000 USD højere end hos dem med lidt eller ingen, ifølge IBM's meddelelse.

Hvad skal vi vise intern revision eller den eksterne revisor?

Medbring fire ting, før værktøjet bruges ved periodeafslutningen: hvor det kører, og hvem der kan nå det, ændringshistorikken med tests af fastlåste output, hvordan bogføring godkendes i ERP, og afstemningsdokumentation, der matcher hver batch med ERP-totalerne. Hvad revisoren kræver, afgør revisoren selv; dette giver noget konkret at vurdere.

Hvem ejer et AI-bygget økonomiværktøj, når personen, der byggede det, går videre?

Udpeg en ejer i økonomiafdelingen og en teknisk kontakt før lancering. Kør værktøjet med servicelegitimationsoplysninger i stedet for byggerens eget login, og før adgang gennem virksomhedslogin, så deaktivering af en fratrådt medarbejders konto blokerer nye login, mens eksisterende sessioner tilbagekaldes eller får lov at udløbe efter sessionspolitikken. Afvikling betyder at deaktivere legitimationsoplysningerne, beholde det, opbevaringspolitikken kræver, slette resten og lukke værktøjet ned.