Jak mohou finanční týmy nasazovat aplikace vytvořené AI bez úniku finančních dat

Když bezpečnostní firma RedAccess hledala aplikace vytvořené programovacími nástroji AI a zveřejněné na vlastním hostingu těchto nástrojů, našla více než 5 000 aplikací prakticky bez zabezpečení nebo autentizace. Mezi obrazovkami, které sdílela s Wired, byly „různé prodejní a finanční záznamy řady dalších společností“. Aplikace vytvořené AI pro finanční týmy mohou skončit na stejném typu otevřené adresy, za níž je hlavní kniha, mzdy a dosud neoznámené výsledky.

Generální ředitel Replit Amjad Masad odpověděl, že „dostupnost veřejných aplikací na internetu je očekávané chování“. Ohledně mechanismu má pravdu. Podle mého výkladu odhalení způsobilo nastavení viditelnosti a vynechaná kontrola a obojí je v dosahu člověka, který nástroj vytvořil.

Stručně

• Finanční nástroj vytvořený AI může umožnit únik dat kvůli šesti chybám nasazení, které může jeho tvůrce ovlivnit: veřejný odkaz, hesla a klíče v kódu nebo historii chatu, administrátorský přístup k databázi, účtování bez druhého schvalovatele, odesílání dat externím službám a nezaznamenané změny výpočtů.
• Každá chyba má nápravu, většinu lze provést prostřednictvím stejného nástroje AI, který aplikaci vytvořil, a jednoduchou kontrolu potvrzující účinnost opravy, například zápis odmítnutý databází nebo staré heslo, které už nefunguje.
• Ve výchozím stavu udržujte finanční nástroj v soukromé síti, přidejte firemní přihlášení, když ho potřebují lidé mimo finance, a předejte ho IT, pokud účtuje do hlavní knihy bez druhého schvalovatele, pracuje s údaji karet nebo dodává čísla do účetních výkazů spadajících pod SOX.
• Region serveru určuje umístění primárního úložiště VPS aplikace, ale zálohy, logy a služby třetích stran mohou vytvářet kopie jinde; soulad celé konfigurace s požadavky je samostatná otázka. Proberte rámce svého regionu s compliance týmem.

Chyby nasazení vedoucí k úniku finančních dat

Finanční nástroj vytvořený AI může umožnit únik dat kvůli šesti chybám nasazení: ponechání na veřejném odkazu, uchovávání přihlašovacích údajů v kódu nebo chatu, připojení s administrátorským přístupem tam, kde stačí čtení, účtování bez druhého schvalovatele, odesílání finančních dat externím službám a změny výpočtů bez záznamu. Každá z těchto výchozích voleb usnadňuje demonstraci.

Každá následující oprava obsahuje zadání pro nástroj AI, který aplikaci vytvořil; před vložením změňte pole v hranatých závorkách. Zadání jsou neotestovanými výchozími návrhy napsanými pro tento článek a oznámení nástroje AI, že provedl změnu, nic nedokazuje. Důkazem je kontrola pod každým zadáním. Používejte zadání na kódu a vzorové nebo syntetické datové sadě a nikdy nevkládejte do chatu skutečné záznamy ani platné klíče.

Ponechání nástroje na veřejném odkazu platformy AI

Přehled prognózy peněžních prostředků ponechaný veřejně na hostingu platformy AI může otevřít kdokoli, kdo zná jeho adresu, se vším, co zobrazuje: věkovou strukturou závazků (AP), rozpočtem proti skutečnosti, výsledky čtvrtletí před jejich oznámením. Zpráva Wired o zjištěních RedAccess popisuje, jak výzkumníci takové aplikace nacházeli jednoduchým vyhledáváním v Google a Bing v doménách dodavatelů AI.

Některé z těchto aplikací pouze žádaly návštěvníky o přihlášení libovolnou e-mailovou adresou. Přihlášení přijímající jakoukoli e-mailovou adresu není řízením přístupu.

Odstraňte reálná data z hostingu dodavatele. Dokud nástroj neběží na serveru pod vaší kontrolou (následující část vysvětluje kde), vytvářejte a předvádějte ho na syntetické datové sadě nebo v sandboxu či testovací společnosti vašeho ERP, pokud ji má, nikdy na reálném exportu. Po změně ho znovu nasaďte, protože hostovaná adresa poskytuje poslední nasazenou verzi.

Vytvoř pro tuto aplikaci syntetickou datovou sadu odpovídající tabulkám a sloupcům, které čte: [uveď tabulky a sloupce, např. vendors, invoices, journal_lines].

Použij vymyšlené názvy dodavatelů a zákazníků, vymyšlená čísla bankovních účtů a částky v [měna], které se chovají jako skutečné účetnictví: každý účetní zápis je vyrovnaný a součty pomocných knih souhlasí s [kontrolním účtem AP / AR].

Nasměruj aplikaci na tuto datovou sadu místo jakéhokoli reálného exportu a uveď všechny změněné soubory nebo nastavení.

Nežádej mě o skutečné záznamy.

Ověřte, že to funguje: otevřete adresu na hostingu dodavatele v nepřihlášeném prohlížeči nebo o to požádejte kolegu mimo finance a potvrďte, že zobrazuje pouze syntetická data, požadavek na přihlášení nebo vůbec nic. Potom v datových souborech aplikace a repozitáři vyhledejte tři názvy dodavatelů nebo zákazníků z produkčního ERP: neměla by se objevit žádná shoda. Nakonec spusťte předvahu nebo souhrnný přehled aplikace a ověřte, že celkové Má dáti se rovná celkovému Dal.

Ponechání přihlašovacích údajů ERP, bankovní integrace a databáze v kódu nebo chatu

Pokud jsou tam uloženy platné přihlašovací údaje, kdokoli, kdo si může přečíst historii chatu, repozitář nebo konfigurační soubor MCP, je může také použít pro přístup k ERP, finanční databázi nebo integraci bankovních dat. MCP je konektor umožňující nástroji AI, jako je Claude, přímo komunikovat s ERP nebo databází a jeho konfigurační soubor je dalším místem, kde může být heslo.

Zpráva GitGuardian State of Secrets Sprawl 2026 našla 24 008 unikátních tajných údajů odhalených v konfiguračních souborech MCP, z nichž 14% tvořily připojovací řetězce k databázím PostgreSQL. U veřejných commitů GitHub stejná zpráva zjistila, že commity se spoluautorstvím Claude Code odhalovaly tajné údaje přibližně dvakrát častěji než základní úroveň, a dodává, že lidský faktor zůstává zásadní.

Smazání zprávy z chatu odhalení nezvrátí: každý s kopií chatu, repozitáře nebo jeho historie stále má danou hodnotu. Pro každé heslo, klíč nebo token, který se někdy nacházel na jednom z těchto míst, vydejte nový v administrátorské konzoli ERP, databáze nebo bankovní integrace a starý deaktivujte. To znamená rotace přihlašovacích údajů.

Aplikace potom při spuštění čte přihlašovací údaje z proměnných prostředí (pojmenovaných nastavení mimo kód), dodaných nasazovací vrstvou, tedy nástrojem, který aplikaci sestavuje a spouští na vašem serveru. HashiCorp Vault je dalším krokem, když více nástrojů sdílí tajné údaje a potřebují je rotovat z jednoho místa.

Vlastní kopie hesel týmu patří do správce hesel určeného pro lidi, například Vaultwarden; běžící aplikace čte své hodnoty z prostředí. Začněte nalezením všech tajných údajů pevně zapsaných v kódu vytvořeném AI.

Zkontroluj tento projekt na pevně zapsané tajné údaje. Najdi každé heslo, klíč API, přístupový token a připojovací řetězec, včetně souborů .env, notebooků, konfiguračních souborů MCP a kódu připojujícího se k [název ERP / poskytovatel bankovních dat / finanční databáze].

Nahraď každou hodnotu v kódu pojmenovanou proměnnou prostředí a dej mi seznam názvů proměnných.

Zajisti, aby žádný soubor se skutečnými hodnotami nebyl commitován do repozitáře, a uveď každý commit v historii repozitáře, kde se některá z těchto hodnot objevuje.

Ukaž pouze umístění. Nevypisuj žádnou tajnou hodnotu.

Ověřte, že to funguje: vyzkoušejte staré heslo nebo token sami nebo požádejte IT a očekávejte odmítnutí. Potom vyhledejte staré hodnoty v aktuálních souborech projektu: neměla by tam být žádná. Shoda ponechaná v historii už neumožňuje přístup teprve po potvrzení, že byla hodnota odvolána nebo vypršela.

Připojení administrátorským účtem tvůrce, když nástroj potřebuje pouze čtení

Přehled věkové struktury pohledávek (AR) nesmí umožňovat úpravy hlavní knihy (GL). Pokud se nástroj připojuje administrátorským účtem tvůrce, dědí oprávnění tohoto účtu. Tajný klíč Supabase nebo starší klíč service_role poskytuje zvýšený přístup k datům projektu a obchází Row Level Security, takže se nemá používat pro běžný přístup pouze ke čtení. Výkaz vytvořený pro jeden přehled věkové struktury pak odhaluje celou hlavní knihu, včetně mzdových tabulek.

Možnost zápisu z toho dělá nákladný problém. Kontrola Symbiotic Security zahrnující 1 072 aplikací vytvořených AI a využívajících Supabase našla 172, které umožňovaly komukoli mazat záznamy bez autentizace, 172, které umožňovaly komukoli měnit existující záznamy, a 39 s tabulkami plně čitelnými pro každého držitele veřejného klíče.

Dejte nástroji přihlašovací údaje pouze ke čtení, omezené na čtené tabulky. V ERP nebo databázi to znamená vyhrazeného integračního uživatele: samostatný účet vytvořený pro nástroj s oprávněním číst objekty potřebné pro výkaz a nic jiného. V Supabase zapněte Row Level Security (databázové pravidlo určující, které řádky smí každý požadavek vidět) pro každou zpřístupněnou tabulku používanou nástrojem a zkontrolujte také oprávnění tabulek: určují, zda role vůbec smí provádět select, insert, update nebo delete. Role finanční aplikace pouze ke čtení nemá mít nepotřebné operace zápisu. Publikovatelný klíč může být v kódu prohlížeče, pokud jsou RLS a oprávnění s nejmenšími nutnými privilegii nastaveny správně. Tajné a starší klíče service_role zůstávají na serveru a mají být vyhrazeny úlohám backendu, které skutečně potřebují zvýšený přístup a vynucují vlastní autorizaci.

Poznámka: publikovatelný klíč Supabase nebo starší klíč anon viditelný v JavaScriptu stránky je normální. Dokumentace klíčů API Supabase uvádí, že zpřístupňuje pouze to, co dovoluje Row Level Security. Tajný klíč obchází Row Level Security, takže se nikdy nesmí objevit v ničem odesílaném do prohlížeče.

Uveď každé čtení a každý zápis, které aplikace provádí v [název ERP nebo databáze], seskupené podle tabulky nebo objektu.

Změň aplikaci tak, aby pouze četla [potřebné tabulky] a připojovala se samostatnými přihlašovacími údaji pouze ke čtení dodanými proměnnou prostředí, nikdy mým vlastním účtem.

Pokud aplikace používá Supabase: zapni Row Level Security pro každou zpřístupněnou tabulku, se kterou pracuje. Uveď oprávnění select, insert, update a delete pro anon a authenticated. Pro tuto aplikaci pouze ke čtení odstraň nepotřebná oprávnění zápisu; pokud na některém závisí jiná produkční aplikace, upozorni na něj místo změny. Potom napiš zásady, podle kterých nepřihlášení návštěvníci nesmějí číst nic a přihlášení uživatelé mohou číst jen [pravidlo, např. řádky svého nákladového střediska], a potvrď, že žádný tajný ani starší klíč service_role není v souborech odesílaných do prohlížeče.

Uveď vytvořené zásady.

Ověřte, že to funguje: s přihlašovacími údaji nástroje zkuste jeden zápis, například úpravu testovacího záznamu, a očekávejte odmítnutí. V Supabase požadujte řádky finanční tabulky bez přihlášení a očekávejte prázdný výsledek nebo chybu.

Umožnění účtování do hlavní knihy bez druhého schvalovatele

Importer účetních zápisů, který účtuje přímo, nebo generátor platebních souborů, který je posílá rovnou do banky, dělá z člověka spouštějícího nástroj zároveň zpracovatele i schvalovatele. Jedna chyba duplikuje měsíční časové rozlišení. Jedno změněné pole odešle platbu dodavateli na nesprávný účet. To je porušení oddělení povinností, které finance mezi dvěma lidmi nepovolují, a software vytvořený s asistentem AI nedostává výjimku.

Škoda nezůstává v aplikaci. Chybná dávka skončí v účetnictví, kde její zrušení vyžaduje opravný zápis a vysvětlení při uzávěrce, a když nástroj účtuje pod vlastním účtem tvůrce, každý duplicitní zápis nese jeho jméno.

Nástroj vytvořený AI čte a připravuje; účtování a uvolnění plateb probíhají ve vlastním schvalovacím workflow ERP se schválením někým jiným než člověkem, který nástroj spustil. Každý účetní systém, na němž jsem pracoval, považuje zápis a jeho schválení za dvě události se dvěma odpovědnými osobami a nástroj vytvořený AI si zaslouží stejný přístup.

V praxi změňte každé přímé účtování na návrh zápisu nebo připravený import čekající na schválení v ERP. Nástroj dál dělá zdlouhavou část (mapování, validaci, sestavení dávky) a schválení zůstává v ERP vedle všech dalších schválení, na nichž uzávěrka závisí. Pokud ERP nemá schvalovací krok pro importy, výstup nástroje se stane souborem, který druhý člověk ověří proti souhrnu dávky a sám importuje.

Nástroj, který musí automaticky účtovat, generovat platební soubory nebo měnit bankovní údaje dodavatelů, patří IT za podmínek v následující části.

Uveď každé místo, kde tato aplikace vytváří, upravuje nebo účtuje [účetní zápisy / faktury / platby] v [název ERP].

Změň každé tak, aby aplikace vytvořila návrh zápisu nebo připravený import, který musí být schválen v [název ERP] před zaúčtováním. Pokud [název ERP] nemá schvalovací krok pro importy, místo toho vytvoř importní soubor a nic neúčtuj.

Odstraň každou cestu kódu, která účtuje nebo uvolňuje platbu bez tohoto schválení.

Pro každou dávku vytvoř souhrn s počtem řádků, celkovým Má dáti a celkovým Dal.

Uveď vše, co stále účtuje přímo, abych to mohl zkontrolovat.

Ověřte, že to funguje: spusťte jednu dávku ze vzorových dat. Nic se nemá objevit jako zaúčtované, dokud to druhý uživatel neschválí v ERP. Potom porovnejte souhrn dávky s tím, co pro ni ukazuje ERP: počet řádků, celkové Má dáti a celkové Dal se musí přesně shodovat. Rozdíl jednoho řádku je neúspěšné odsouhlasení, nikoli problém zaokrouhlení.

Odesílání finančních dat službám mimo vaši kontrolu

Funkce komentování odchylek, která odesílá úplný export hlavní knihy do API AI, předává každý řádek třetí straně. Data odcházejí také dvěma méně nápadnými cestami: analytickým skriptem na stránce, který dodavateli hlásí každou návštěvu, a systémem sledování chyb nebo logem ukládajícím celá těla požadavků, kde mohou skončit mzdové řádky, bankovní údaje zákazníků a dosud nezveřejněná čísla.

U interního nástroje vytvořeného financemi neodesílejte dosud nezveřejněné výsledky a mzdy třetím stranám, pokud služba a konkrétní datový tok nebyly výslovně schváleny procesem vaší organizace pro dodavatele, bezpečnost a soulad s předpisy. U všeho ostatního uveďte každý cíl a každým voláním odesílejte jen potřebná pole. Zda externí služba přijatá data ukládá nebo používá k trénování, má ověřit člověk podepisující dodavatelské smlouvy podle vlastních podmínek dodavatele. Pokud tým chce vědět, jak často je nástroj používán, samostatně hostovaný analytický nástroj jako Umami uchovává tyto návštěvy stránek na vašem serveru.

Uveď každé místo, kde tato aplikace odesílá data mimo [náš server], včetně API AI, analytických skriptů, sledování chyb, e-mailu, webhooků a souborů logů.

Pro každý cíl přesně uveď přijímaná pole.

Označ vše, co obsahuje [mzdové částky / čísla bankovních účtů / dosud nezveřejněné výsledky / jména zákazníků].

U každé označené položky ukaž, jak odeslat méně polí nebo žádná, a změnu proveď teprve po mém potvrzení.

Ověřte, že to funguje: spusťte každou funkci jednou se vzorovými daty obsahujícími rozpoznatelné smyšlené číslo účtu a smyšlenou mzdovou částku. Vyhledejte obě hodnoty v systému sledování chyb a logách: neměly by tam být. Pro cestu přes API AI nechte aplikaci během tohoto zkušebního běhu zaznamenat tělo odchozího požadavku, vyhledejte v logu stejné dvě hodnoty a očekávejte nepřítomnost obou a přítomnost pouze schválených polí. Poté toto logování vypněte.

Změna výpočtů bez záznamu a bez odsouhlasení

V kalkulátoru časového rozlišení nebo validátoru harmonogramu uznávání výnosů je kód kontrolním mechanismem. Změňte jeden vzorec a změní se čísla vstupující do uzávěrky; bez správy verzí nikdo neřekne, kdo co změnil nebo kdy.

Pod vláknem účetní firmy CPA na r/ClaudeAI o interních nástrojích vytvořených s Claude Code jeden komentující popsal hranici přímo: „‚účetní + claude code‘ funguje, dokud nenarazíte na požadavky na auditní stopu. To je skutečný strop.“

Před jakoukoli změnou zafixujte dnešní chování; po zafixování výstupů lze zlepšovat logiku bez nepozorovaného rozcházení součtů. Udržujte kód ve správě verzí, která zaznamenává každou změnu s autorem a datem.

Napište testy spouštějící nástroj na pevném vzorovém souboru a porovnávající výsledky se zaznamenaným výchozím stavem, aby kód musel projít odsouhlasením před vydáním každé změny. Zafixovaný test chrání vše, co zaznamenává, včetně chyb, proto výchozí součty nejdříve odsouhlaste se součty ERP za dané období, než jim začnete důvěřovat.

Vyžadujte kontrolu každé změny výpočetní logiky druhým člověkem a odsouhlasujte každý produkční běh s vlastními součty ERP.

Zařaď projekt do správy verzí, pokud v ní ještě není, a uveď soubory obsahující výpočetní logiku.

Napiš testy spouštějící aplikaci na [vzorový soubor] a zaznamenávající dnešní výstupy: počty řádků a součty podle [účet / účetní jednotka / období].

Před uložením zaznamenaných výstupů mi ukaž součty, abych je mohl odsouhlasit s [název ERP] za [období].

Každá změna, která změní některý z těchto součtů, musí způsobit selhání testu.

Neměň výpočetní logiku při psaní testů.

Ověřte, že to funguje: úmyslně změňte jeden výpočet, například pravidlo zaokrouhlení, a potvrďte selhání testu. Vraťte změnu a ověřte, že všechny testy opět procházejí.

Soukromá síť ve výchozím stavu, firemní přihlášení pro více lidí, IT pro hlavní knihu

Reálná finanční data nikdy nezůstávají na hostingu nástroje AI. Chcete-li bezpečně nasadit finanční aplikaci vytvořenou AI jen pro finanční tým, umístěte ji na server pod vlastní kontrolou dostupný pouze přes soukromou síť. Přidejte firemní přihlášení, když ji potřebují lidé mimo tým, a předejte ji IT, pokud platí cokoli z následujícího seznamu.

VPS je pronajatý virtuální server, jehož operační systém a softwarový stack máte pod kontrolou. Soukromá síť (tailnet v terminologii Tailscale) připojuje schválená zařízení k tomuto serveru. Aby nástroj nebyl v otevřeném internetu, stále musíte zablokovat veřejný příchozí přístup k aplikaci, například firewallem serveru, a zpřístupnit ji pouze přes rozhraní VPN nebo tailnet. Poskytovatel identity uchovává firemní uživatelské účty a reverzní proxy je strážce před aplikací, který každý požadavek nejprve směruje přes přihlášení.

Vlastní hosting nástroje AI zůstává mimo tabulku z důvodů uvedených u první chyby. Stejně tak podniková nasazovací platforma jako Northflank, která vyhovuje větším organizacím, jež už mají rozpočet na dodavatele platforem a nutné kontroly. To je více smluvních závazků, než potřebuje nástroj oddělení s několika uživateli.

Podle mé zkušenosti se ze dvou možností soukromé sítě rychleji zavádí Tailscale, ale Tailscale sám hostuje koordinační službu. WireGuard je plně samostatně hostovaná možnost.

Proč volím soukromou síť jako výchozí: nástroj, který z internetu neodpovídá, nelze najít vyhledáváním ani napadnout na přihlašovací stránce, zatímco přihlašovací stránka napsaná AI je jen tak dobrá jako kód AI za ní. Pokud potřebujete zpřístupnit aplikaci mimo soukromou síť, firemní přihlášení před ni přidává spravovanou autentizační vrstvu, proto následuje jako druhé.

Když potřebují přístup osoby odpovědné za rozpočty, nahraďte vlastní přihlášení nástroje firemním přihlášením, také nazývaným jednotné přihlášení (SSO): lidé používají svůj stávající firemní účet, takže deaktivace účtu blokuje nová přihlášení; nastavte odvolávání relací, back-channel logout nebo vhodně krátkou životnost relací, aby stávající relace nepřetrvávaly dlouho. Zadání používá OIDC, standardní přihlašovací protokol podporovaný Authentik i Keycloak.

Nahraď vlastní přihlášení aplikace firemním přihlášením přes [Authentik / Keycloak / náš poskytovatel identity] pomocí OIDC.

Čti skupinu každého uživatele z údajů přihlášení.

Povol [mzdové stránky] pouze členům [název skupiny] a vynucuj toto pravidlo na serveru pro každou stránku, každý export a každý endpoint API, ne pouze v menu.

Odmítni každý požadavek bez platného přihlášení.

Ověřte, že to funguje: přihlaste se testovacím účtem mimo skupinu, požadujte přímo omezenou stránku a adresu jejího exportu nebo API a očekávejte odmítnutí obou. Potom deaktivujte testovací účet u poskytovatele identity a ověřte, že nemůže zahájit novou relaci. Také potvrďte, že existující relace byla odvolána nebo vyprší v nastaveném časovém okně.

Některé nástroje by vůbec neměly zůstat u týmu. Předejte nástroj IT nebo technickému týmu, pokud platí kterákoli z následujících podmínek:

1. Účtuje do hlavní knihy nebo jiného primárního evidenčního systému bez schválení člověkem v ERP.
2. Generuje platební soubory, uvolňuje platby nebo mění bankovní údaje dodavatelů.
3. Jeho výstupy vstupují do účetních výkazů subjektu registrovaného u SEC, což může nástroj zahrnout do vnitřní kontroly účetního výkaznictví (ICFR). Proberte to s interním auditem před použitím při uzávěrce; u emitentů podléhajících oddílu 404(b) SOX může příslušné kontroly testovat i externí auditor.
4. Uchovává, zpracovává nebo přenáší údaje platebních karet.
5. Hodnotí úvěruschopnost jednotlivých fyzických osob.
6. Nikdo v týmu nepřevezme odpovědnost za záplaty, kontroly přístupu a vyřazení nástroje.

Šestá podmínka má větší váhu, než se zdá. Při vlastním hostingu odpovídáte za aktualizace, zálohy a monitoring a finanční nástroj, který nikdo neudržuje, je bezpečnější u IT. IT může být pomalejší; to je cena řízení, které tyto podmínky vyžadují.

Pro úrovně 1 a 2 musí být server, nasazovací vrstva, soukromá síť a pro úroveň 2 také poskytovatel identity připraveny dříve, než kdokoli nástroj otevře, a finanční tým bez technika to musí zprovoznit sám. Na našem Linux VPS získáte přístup root. Coolify a WireGuard jsou k dispozici pro nasazení jedním kliknutím; Tailscale se instaluje oficiálním instalátorem pomocí jediného příkazu, zatímco Authentik běží z oficiálního stacku Docker Compose. Čas týmu pak může směřovat do oprav výše místo budování nasazovacího stacku od nuly. Naše lokality zahrnují Frankfurt a Amsterdam v EU, Londýn ve Spojeném království a několik amerických měst, což umožňuje zvolit region primárního úložiště VPS aplikace; přijatelnost této volby zůstává u compliance týmu.

Pravidla k ověření s compliance týmem podle regionu

Které rámce se použijí, závisí na tom, s čím nástroj pracuje a kde jsou společnost a lidé v datech. Mzdová tabulka obsahující mzdy zaměstnanců v EU a harmonogram výnosů vstupující do účetních výkazů společnosti kótované v USA mohou spadat pod různé rámce.

Nic v tomto článku není právní radou. Následující tabulka uvádí rámce k projednání s compliance týmem a nerozhoduje, zda se na vás některý vztahuje.

V řádku SOX je AS 2201 standard PCAOB pro auditorské ověření, na které odkazuje oddíl 404(b) zákona Sarbanes-Oxley, a mezi kontrolami, které auditor posuzuje při řešení rizika podvodu, uvádí kontroly účetních zápisů a úprav provedených při sestavování účetních výkazů na konci období. Mimo tyto regiony začněte na vlastním webu národního regulátora ochrany údajů. Umístění serveru určuje místo jeho primárního úložiště; neříká, kde je každá záloha, log nebo kopie u třetí strany, a samo o sobě nesplňuje žádný z rámců výše.

Časté dotazy

Je vibe coding bezpečný pro finanční nástroje?

Může být, když se odstraní mezery ponechané demonstrací; důkazy chápu spíše jako problém nasazení než programování. Finanční nástroj je rizikovější než osobní projekt, protože čte ERP a může zapisovat do účetnictví. Jakmile účtuje bez druhého schvalovatele, zpracovává platby nebo pracuje s údaji karet, patří IT.

Co je stínová AI ve financích?

Stínová AI jsou nástroje AI nebo aplikace vytvořené AI používané na firemních datech bez vědomí či schválení IT, například přehled prognóz připojený k ERP, který IT nikdy nevidělo. Podle oznámení IBM zpráva IBM Cost of a Data Breach Report z roku 2025 zjistila, že organizace s vysokou úrovní stínové AI měly průměrné náklady na únik dat o 670 000 USD vyšší než organizace s nízkou úrovní nebo bez ní.

Co máme ukázat internímu auditu nebo externímu auditorovi?

Před použitím nástroje při uzávěrce připravte čtyři věci: kde běží a kdo má přístup, historii změn s testy zafixovaných výstupů, způsob schvalování účtování v ERP a doklady odsouhlasení každé dávky se součty ERP. Požadavky určuje auditor; tyto podklady mu dávají něco konkrétního k posouzení.

Kdo odpovídá za finanční nástroj vytvořený AI po odchodu jeho tvůrce?

Před spuštěním určete odpovědnou osobu ve financích a technický kontakt. Spouštějte nástroj se služebními přihlašovacími údaji místo vlastního účtu tvůrce a směrujte přístup přes firemní přihlášení, aby deaktivace firemního účtu odcházejícího zaměstnance blokovala nová přihlášení a stávající relace byly odvolány nebo vypršely podle vašich pravidel relací. Vyřazení nástroje znamená deaktivovat jeho přihlašovací údaje, uchovat to, co vyžaduje retenční politika, smazat zbytek a nástroj vypnout.