Коли компанія з безпеки RedAccess шукала застосунки, створені інструментами ШІ для програмування та опубліковані на власному хостингу цих інструментів, вона знайшла понад 5 000 застосунків практично без захисту чи автентифікації. Серед екранів, якими вона поділилася з Wired, були «різноманітні записи про продажі та фінансові записи багатьох інших компаній». Застосунки, створені ШІ, для фінансових команд можуть опинитися за такою самою відкритою адресою, за якою містяться головна книга, зарплатні дані та ще не оголошені результати.
Генеральний директор Replit Амджад Масад відповів, що «доступність публічних застосунків в інтернеті є очікуваною поведінкою». Щодо механізму він має рацію. На мою думку, розкриття сталося через налаштування видимості та пропущену перевірку, і обидва чинники перебувають у межах можливостей людини, яка створила інструмент.
TL;DR
- Фінансовий інструмент, створений ШІ, може допустити витік даних через шість помилок розгортання, кожна з яких підконтрольна розробнику: публічне посилання, паролі та ключі в коді або історії чату, адміністративний доступ до бази даних, проведення записів без другої особи для погодження, надсилання даних зовнішнім сервісам і незадокументовані зміни розрахунків.
- Для кожної помилки є виправлення, більшість із них можна виконати через той самий інструмент ШІ, що створив застосунок, і проста перевірка, яка підтверджує результат: наприклад, запис, який база даних відхиляє, або старий пароль, який більше не працює.
- За замовчуванням тримайте фінансовий інструмент у приватній мережі, додайте вхід через корпоративний обліковий запис, коли він потрібен людям поза фінансовою командою, і передайте його ІТ, якщо він проводить записи в головній книзі без другої особи для погодження, торкається карткових даних або постачає цифри до фінансової звітності, на яку поширюється SOX.
- Регіон сервера визначає розташування основного сховища VPS застосунку, але резервні копії, журнали та сторонні сервіси можуть створювати копії деінде; відповідність усієї системи вимогам є окремим питанням. Обговоріть нормативні рамки свого регіону з фахівцями з дотримання вимог.
Помилки розгортання, що спричиняють витоки фінансових даних
Фінансовий інструмент, створений ШІ, може допустити витік даних через шість помилок розгортання: розміщення за публічним посиланням, зберігання облікових даних у коді або чаті, адміністративне підключення там, де вистачило б читання, проведення записів без другої особи для погодження, надсилання фінансових даних зовнішнім сервісам і зміну розрахунків без запису про це. Кожен із цих стандартних варіантів зручний для демонстрації.
Кожне виправлення нижче супроводжується запитом для інструмента ШІ, який створив застосунок; замініть поля в квадратних дужках перед вставленням. Ці запити написані для статті як неперевірені початкові варіанти, і повідомлення інструмента ШІ про зміну нічого не доводить. Доказом є перевірка під кожним запитом. Виконуйте запити на коді зі зразковим або синтетичним набором даних і ніколи не вставляйте в чат реальні записи чи чинні ключі.
Розміщення інструмента за публічним посиланням платформи ШІ
Панель прогнозу грошових коштів, залишену публічною на хостингу платформи ШІ, може відкрити кожен, кому відома адреса, разом з усім її вмістом: аналізом строків кредиторської заборгованості (AP), порівнянням бюджету з фактом, результатами кварталу до їх оголошення. Матеріал Wired про знахідки RedAccess описує, як дослідники знаходили такі застосунки простими пошуками в Google і Bing за доменами постачальників ШІ.
Деякі з цих застосунків лише просили відвідувачів увійти з будь-якою електронною адресою. Вхід, який приймає будь-яку електронну адресу, не є контролем доступу.
Приберіть реальні дані з хостингу постачальника. Поки інструмент не працює на сервері під вашим контролем (наступний розділ пояснює, де), розробляйте та демонструйте його на синтетичному наборі даних або в пісочниці чи тестовій компанії вашої ERP, якщо вона є, але ніколи на реальному експорті. Після зміни повторно розгорніть застосунок, бо адреса хостингу показує останню розгорнуту версію.
Створи для цього застосунку синтетичний набір даних, що відповідає таблицям і стовпцям, які він читає: [перелічи таблиці та стовпці, наприклад vendors, invoices, journal_lines].
Використовуй вигадані назви постачальників і клієнтів, вигадані номери банківських рахунків та суми у [валюта], які поводяться як справжні облікові дані: кожен бухгалтерський запис збалансований, а підсумки допоміжних регістрів збігаються з [контрольним рахунком AP / AR].
Налаштуй застосунок на цей набір даних замість будь-якого реального експорту та перелічи всі змінені файли або налаштування.
Не проси в мене реальні записи.
Переконайтеся, що це спрацювало: відкрийте адресу на хостингу постачальника в браузері без входу або попросіть це зробити колегу поза фінансовою командою та переконайтеся, що там лише синтетичні дані, вимога входу або взагалі нічого. Потім пошукайте у файлах даних застосунку й репозиторії три назви постачальників або клієнтів із вашої робочої ERP: збігів не має бути. Нарешті, відкрийте оборотно-сальдову відомість або зведення застосунку й перевірте, що загальний дебет дорівнює загальному кредиту.
Зберігання облікових даних ERP, банківського підключення та бази даних у коді або чаті
Якщо там зберігаються чинні облікові дані, будь-хто, хто може прочитати історію чату, репозиторій або файл конфігурації MCP, може також використати їх для доступу до ERP, фінансової бази даних чи інтеграції банківських даних. MCP є з’єднувачем, що дає інструменту ШІ, як-от Claude, змогу безпосередньо взаємодіяти з ERP або базою даних, а його конфігураційний файл є ще одним місцем, де може опинитися пароль.
Звіт GitGuardian State of Secrets Sprawl 2026 виявив 24 008 унікальних секретів, розкритих у конфігураційних файлах MCP; 14% із них були рядками підключення до баз даних PostgreSQL. У публічних комітах GitHub той самий звіт виявив, що коміти зі співавторством Claude Code розкривали секрети приблизно вдвічі частіше за базовий рівень, і додав, що людський чинник також залишається критичним.
Видалення повідомлення з чату не усуває розкриття: кожен, хто має копію чату, репозиторію чи його історії, усе ще має значення. Для кожного пароля, ключа або токена, що коли-небудь був у одному з цих місць, створіть новий в адміністративній консолі ERP, бази даних або банківської інтеграції та вимкніть старий. Саме це означає ротація облікових даних.
Після цього застосунок під час запуску читає облікові дані зі змінних середовища (іменованих налаштувань поза кодом), які надає рівень розгортання, тобто інструмент, що збирає та запускає застосунок на вашому сервері. HashiCorp Vault є наступним кроком, коли кілька інструментів використовують спільні секрети й потребують їх ротації з одного місця.
Власні копії паролів команди мають бути в менеджері паролів для людей, наприклад Vaultwarden; запущений застосунок читає свої значення із середовища. Почніть із пошуку всіх жорстко заданих секретів у коді, створеному ШІ.
Перевір цей проєкт на жорстко задані секрети. Знайди всі паролі, ключі API, токени доступу й рядки підключення, зокрема у файлах .env, блокнотах, конфігураційних файлах MCP та коді підключення до [назва ERP / постачальник банківських даних / фінансова база даних].
Заміни кожне значення в коді іменованою змінною середовища та надай список назв змінних.
Переконайся, що жоден файл із реальними значеннями не потрапляє до комітів репозиторію, і перелічи кожен коміт в історії репозиторію, де з’являється одне з цих значень.
Покажи лише місця розташування. Не виводь жодного секретного значення.
Переконайтеся, що це спрацювало: спробуйте старий пароль чи токен самі або попросіть ІТ і очікуйте відмови. Потім пошукайте старі значення в поточних файлах проєкту: їх не має бути. Збіг, що залишився в історії, перестає давати доступ лише після підтвердження, що значення відкликане або строк його дії минув.
Підключення з адміністративним обліковим записом розробника, коли потрібне лише читання
Панель аналізу строків дебіторської заборгованості (AR) не повинна мати змоги змінювати головну книгу (GL). Якщо інструмент підключається з адміністративним обліковим записом розробника, він успадковує його привілеї. Секретний ключ Supabase або застарілий ключ service_role надає підвищений доступ до даних проєкту й обходить Row Level Security, тож його не слід використовувати для звичайного доступу лише на читання. Тоді звіт для одного аналізу заборгованості розкриває всю головну книгу, включно із зарплатними таблицями.
Можливість запису робить це дорогим. Перевірка Symbiotic Security 1 072 застосунків, створених ШІ та заснованих на Supabase, виявила 172 застосунки, які дозволяли будь-кому видаляти записи без автентифікації, 172, які дозволяли будь-кому змінювати наявні записи, і 39 із таблицями, повністю доступними для читання кожному власнику публічного ключа.
Надайте інструменту облікові дані лише для читання та лише потрібних таблиць. В ERP або базі даних це означає окремого користувача інтеграції: обліковий запис, створений для інструмента, з доступом на читання до потрібних звіту об’єктів і ні до чого іншого. У Supabase увімкніть Row Level Security (правило бази даних, яке визначає, які рядки може бачити кожен запит) для кожної доступної ззовні таблиці, яку використовує інструмент, і перевірте також дозволи таблиць: вони визначають, чи може роль узагалі виконувати select, insert, update або delete. Роль фінансового застосунку лише для читання не повинна мати непотрібних операцій запису. Ключ для публічного використання може бути в браузерному коді, якщо RLS і дозволи найменших привілеїв налаштовані правильно. Секретні та застарілі ключі service_role залишаються на сервері й мають бути зарезервовані для завдань бекенду, які справді потребують підвищеного доступу та забезпечують власну авторизацію.
Примітка: ключ для публічного використання Supabase або застарілий ключ anon у JavaScript сторінки є нормою. Документація Supabase щодо ключів API пояснює, що він дає доступ лише до дозволеного Row Level Security. Секретний ключ обходить Row Level Security, тому ніколи не має з’являтися в тому, що надсилається браузеру.
Перелічи всі операції читання й запису цього застосунку в [назва ERP або бази даних], згрупувавши їх за таблицею або об’єктом.
Зміни застосунок так, щоб він лише читав [потрібні йому таблиці] та підключався з окремими обліковими даними лише для читання, переданими через змінну середовища, ніколи з моїм власним обліковим записом.
Якщо застосунок використовує Supabase: увімкни Row Level Security для кожної доступної ззовні таблиці, до якої він звертається. Перелічи дозволи select, insert, update і delete для anon та authenticated. Для цього застосунку лише для читання прибери непотрібні дозволи запису; якщо від одного з них залежить інший робочий застосунок, познач це замість зміни. Потім створи політики, за якими відвідувачі без входу не можуть нічого читати, а користувачі після входу можуть читати лише [правило, наприклад рядки свого центру витрат], і переконайся, що жоден секретний або застарілий ключ service_role не з’являється в жодному файлі, надісланому браузеру.
Перелічи створені політики.
Переконайтеся, що це спрацювало: з обліковими даними інструмента спробуйте одну операцію запису, наприклад редагування тестового запису, і очікуйте відмови. Для Supabase запитайте рядки фінансової таблиці без входу й очікуйте порожнього результату або помилки.
Проведення записів у головній книзі без другої особи для погодження
Імпортер бухгалтерських записів, який проводить їх напряму, або генератор платіжних файлів, який надсилає їх прямо до банку, робить користувача одночасно укладачем і погоджувачем. Одна помилка дублює нарахування за місяць. Одне змінене поле спрямовує платіж постачальнику на неправильний рахунок. Це порушення розподілу обов’язків, якого фінансова служба не допускає між двома людьми, і програма, створена з помічником ШІ, не отримує винятку.
Шкода не залишається в застосунку. Помилкова партія потрапляє в облік, де для її скасування потрібні коригувальний запис і пояснення під час закриття періоду; а якщо інструмент проводить записи під власним обліковим записом розробника, кожен дубльований запис містить його ім’я.
Інструмент, створений ШІ, читає та готує; проведення записів і дозвіл платежів відбуваються у власному процесі погодження ERP, який виконує інша людина, ніж та, що запустила інструмент. Кожна облікова система, з якою я працював, розглядає запис і його погодження як дві події з двома відповідальними, і інструмент, створений ШІ, заслуговує на такий самий підхід.
На практиці перетворіть кожне пряме проведення на чернетку запису або підготовлений імпорт, що чекає погодження в ERP. Інструмент і далі виконує рутинну частину (зіставлення, перевірку, формування партії), а погодження залишається в ERP поряд з усіма іншими погодженнями, від яких залежить закриття періоду. Якщо ERP не має етапу погодження імпортів, результат інструмента стає файлом, який друга людина звіряє зі зведенням партії та сама імпортує.
Інструмент, якому потрібно автоматично проводити записи, створювати платіжні файли або змінювати банківські реквізити постачальників, слід передати ІТ за умовами наступного розділу.
Перелічи всі місця, де застосунок створює, змінює або проводить [бухгалтерські записи / рахунки / платежі] у [назва ERP].
Зміни кожне так, щоб застосунок створював чернетку запису або підготовлений імпорт, який потрібно погодити в [назва ERP] до проведення. Якщо [назва ERP] не має етапу погодження імпортів, натомість створи файл імпорту й нічого не проводь.
Видали всі шляхи виконання коду, які проводять записи або дозволяють платіж без цього погодження.
Для кожної партії створи зведення з кількістю рядків, загальним дебетом і загальним кредитом.
Перелічи все, що досі проводить записи напряму, щоб я міг це перевірити.
Переконайтеся, що це спрацювало: запустіть одну партію зі зразкових даних. Ніщо не має з’явитися як проведене, доки другий користувач не погодить це в ERP. Потім порівняйте зведення партії з тим, що ERP показує для неї: кількість рядків, загальний дебет і загальний кредит мають збігатися точно. Різниця в один рядок є невдалою звіркою, а не проблемою округлення.
Надсилання фінансових даних сервісам поза вашим контролем
Функція коментарів до відхилень, яка надсилає повну витяжку головної книги до API ШІ, передає кожен рядок третій стороні. Дані виводять і два менш помітні канали: скрипт аналітики на сторінці, який повідомляє постачальнику про кожне відвідування, та трекер помилок або журнал, що зберігає повні тіла запитів, де можуть опинитися зарплатні рядки, банківські реквізити клієнтів і ще не оприлюднені цифри.
Для внутрішнього інструмента, створеного фінансовою командою, не надсилайте ще не оприлюднені результати й зарплатні дані стороннім сервісам, якщо сервіс і конкретний потік даних не були явно схвалені через процес вашої організації щодо постачальників, безпеки й дотримання вимог. Для всього іншого перелічіть усіх одержувачів і надсилайте в кожному виклику лише потрібні поля. Чи зберігає зовнішній сервіс отримане та чи навчається на ньому, має з’ясувати той, хто підписує угоди з постачальниками, перевіривши власні умови постачальника. Якщо команда хоче знати частоту використання інструмента, самостійно розміщений інструмент аналітики на кшталт Umami зберігає ці перегляди сторінок на вашому сервері.
Перелічи всі місця, де застосунок надсилає дані за межі [нашого сервера], зокрема API ШІ, скрипти аналітики, відстеження помилок, електронну пошту, вебхуки та файли журналів.
Для кожного одержувача точно перелічи поля, які він отримує.
Познач усе, що містить [суми зарплати / номери банківських рахунків / ще не оприлюднені результати / імена клієнтів].
Для кожного позначеного елемента покажи, як надсилати менше полів або не надсилати жодного, і внеси зміну лише після мого підтвердження.
Переконайтеся, що це спрацювало: запустіть кожну функцію один раз зі зразковими даними, що містять упізнаваний вигаданий номер рахунку та вигадану суму зарплати. Пошукайте обидва значення в трекері помилок і журналах: їх не має бути. Для каналу API ШІ налаштуйте запис вихідного тіла запиту в журнал під час цього тестового запуску, пошукайте ті самі два значення й переконайтеся, що жодного немає, а наявні лише схвалені поля. Потім вимкніть таке журналювання.
Зміна розрахунків без запису про це та без звірки
У калькуляторі нарахувань або валідаторі графіка визнання доходу код є засобом контролю. Змініть одну формулу, і цифри для закриття періоду зміняться разом із нею; без контролю версій ніхто не скаже, хто, що й коли змінив.
У коментарях до гілки бухгалтерської фірми CPA в r/ClaudeAI про внутрішні інструменти, створені з Claude Code, один учасник прямо окреслив межу: «„бухгалтер + claude code“ працює, доки не натрапиш на вимоги до аудиторського сліду. Це і є справжня межа».
Зафіксуйте сьогоднішню поведінку перед будь-якими змінами; коли результати зафіксовано, логіку можна покращувати без непомітного відхилення підсумків. Зберігайте код у системі контролю версій, що записує кожну зміну з автором і датою.
Напишіть тести, які запускають інструмент на фіксованому зразковому файлі та порівнюють результати із записаним еталоном, щоб код проходив звірку перед випуском будь-якої зміни. Зафіксований тест захищає все записане, включно з помилками, тож перед довірою до еталону звірте його підсумки з підсумками ERP за цей період.
Вимагайте, щоб друга людина перевіряла будь-яку зміну логіки розрахунків, і звіряйте кожен робочий запуск із власними підсумками ERP.
Додай проєкт до системи контролю версій, якщо цього ще не зроблено, і перелічи файли, що містять логіку розрахунків.
Напиши тести, які запускають застосунок на [зразковий файл] і записують сьогоднішні результати: кількість рядків та підсумки за [рахунок / організація / період].
Перед збереженням записаних результатів покажи мені підсумки, щоб я міг звірити їх із [назва ERP] за [період].
Будь-яка зміна, що змінює один із цих підсумків, має спричиняти провал тесту.
Не змінюй логіку розрахунків під час написання тестів.
Переконайтеся, що це спрацювало: навмисно змініть один розрахунок, наприклад правило округлення, і перевірте, що тест не проходить. Скасуйте зміну й переконайтеся, що всі тести знову проходять.
Приватна мережа за замовчуванням, корпоративний вхід для більшої кількості людей, ІТ для головної книги
Реальні фінансові дані ніколи не залишаються на хостингу інструмента ШІ. Щоб безпечно розгорнути фінансовий застосунок, створений ШІ, лише для фінансової команди, розмістіть його на контрольованому вами сервері, доступному лише через приватну мережу. Додайте корпоративний вхід, коли застосунок потрібен людям поза командою, і передайте його ІТ, якщо виконується будь-яка з умов нижче.
VPS є орендованим віртуальним сервером, операційною системою та програмним стеком якого керуєте ви. Приватна мережа (tailnet у термінах Tailscale) з’єднує схвалені пристрої з цим сервером. Щоб інструмент не був доступний у відкритому інтернеті, усе одно потрібно заблокувати публічний вхідний доступ до застосунку, наприклад серверним брандмауером, і надати його лише через інтерфейс VPN або tailnet. Провайдер ідентифікації зберігає корпоративні облікові записи, а зворотний проксі є охоронцем перед застосунком, який спершу спрямовує кожен запит через вхід.
| Рівень розгортання | Хто може отримати доступ | Для чого підходить | На чому працює |
|---|---|---|---|
| Лише приватна мережа | Фінансова команда на власних пристроях | Помічники звірки, прогнози коштів, контрольні списки закриття періоду, усе, що показує ще не оприлюднені цифри | VPS із рівнем розгортання на кшталт Coolify або Dokku, доступний лише через Tailscale або WireGuard |
| Корпоративний вхід перед застосунком | Визначені працівники компанії, наприклад відповідальні за бюджети та керівники відділів | Подання бюджету порівняно з фактом, запити на витрати | Рівень 1 плюс провайдер ідентифікації (Authentik або Keycloak) за зворотним проксі (Caddy або Nginx Proxy Manager) |
| Відповідальність ІТ або інженерної команди | Ті, кому ІТ надасть доступ | Будь-який інструмент, що відповідає умові зі списку передачі ІТ | Власна платформа ІТ |
Власний хостинг інструмента ШІ не входить до таблиці з причин, наведених у першій помилці. Так само не входить корпоративна платформа розгортання на кшталт Northflank, яка підходить більшим організаціям, що вже закладають у бюджет постачальників платформ і потрібні перевірки. Для інструмента відділу з кількома користувачами це зайві договірні зобов’язання.
З мого досвіду, серед двох варіантів приватної мережі Tailscale розгортається швидше, але Tailscale сам розміщує сервіс координації. WireGuard є повністю самостійно розміщуваним варіантом.
Чому я обираю приватну мережу за замовчуванням: інструмент, що не відповідає з інтернету, не можна знайти пошуком або атакувати на сторінці входу, тоді як сторінка входу, написана ШІ, надійна лише настільки, наскільки надійний створений ШІ код за нею. Якщо застосунок потрібно відкрити за межами приватної мережі, корпоративний вхід додає перед ним керований рівень автентифікації, тому він іде другим.
Коли відповідальним за бюджети потрібен доступ, замініть власний вхід інструмента корпоративним, також званим єдиним входом (SSO): люди використовують уже наявний корпоративний обліковий запис, тому його вимкнення блокує нові входи; налаштуйте відкликання сеансів, back-channel logout або достатньо короткий строк життя сеансів, щоб наявні не зберігалися надовго. Запит використовує OIDC, стандартний протокол входу, який підтримують Authentik і Keycloak.
Заміни власний вхід застосунку корпоративним через [Authentik / Keycloak / наш провайдер ідентифікації] з використанням OIDC.
Зчитуй групу кожного користувача з даних входу.
Дозволь [зарплатні сторінки] лише учасникам [назва групи] та застосовуй це правило на сервері до кожної сторінки, кожного експорту й кожної кінцевої точки API, а не лише в меню.
Відхиляй кожен запит без чинного входу в систему.
Переконайтеся, що це спрацювало: увійдіть із тестовим обліковим записом, що не належить до групи, напряму запитайте обмежену сторінку та адресу її експорту або API й очікуйте відмови в обох випадках. Потім вимкніть тестовий обліковий запис у провайдері ідентифікації та переконайтеся, що він не може почати новий сеанс. Також перевірте, що наявний сеанс відкликано або він спливає в налаштований строк.
Деякі інструменти взагалі не повинні залишатися в команди. Передайте інструмент ІТ або інженерній команді, якщо виконується хоча б одна умова:
- Він проводить записи в головній книзі або іншій основній системі обліку без погодження людиною в ERP.
- Він створює платіжні файли, дозволяє платежі або змінює банківські реквізити постачальників.
- Його результати використовуються у фінансовій звітності організації, зареєстрованої в SEC, що може включити інструмент до внутрішнього контролю фінансової звітності (ICFR). Обговоріть це з внутрішнім аудитом до застосування під час закриття періоду; для емітентів, на яких поширюється розділ 404(b) SOX, зовнішній аудитор також може перевіряти відповідні засоби контролю.
- Він зберігає, обробляє або передає дані платіжних карток.
- Він оцінює кредитоспроможність фізичних осіб.
- Ніхто в команді не візьме відповідальність за виправлення безпеки, перевірки доступу та виведення інструмента з експлуатації.
Шоста умова важливіша, ніж здається. За самостійного розміщення ви відповідаєте за оновлення, резервні копії та моніторинг, а фінансовий інструмент, який ніхто не підтримує, безпечніше передати ІТ. ІТ може діяти повільніше; це ціна управління, якого вимагають ці умови.
Для рівнів 1 і 2 сервер, рівень розгортання, приватна мережа та, для рівня 2, провайдер ідентифікації мають бути готові до першого відкриття інструмента, а фінансова команда без інженера мусить налаштувати це самостійно. На нашому Linux VPS ви отримуєте root-доступ. Coolify і WireGuard доступні для розгортання одним натисканням; Tailscale встановлюється офіційним інсталятором однією командою, а Authentik працює з офіційного стека Docker Compose. Тоді час команди можна витратити на виправлення вище замість побудови стека розгортання з нуля. Серед наших локацій є Франкфурт і Амстердам у ЄС, Лондон у Великій Британії та кілька міст США, що дозволяє обрати регіон основного сховища VPS застосунку; прийнятність вибору залишається питанням дотримання вимог.
Правила для обговорення з фахівцями з дотримання вимог за регіонами
Застосовні нормативні рамки залежать від того, чого торкається інструмент і де перебувають компанія та люди, представлені в даних. Зарплатна таблиця з оплатою працівників ЄС і графік доходів, використаний у фінансовій звітності компанії, що котирується у США, можуть підпадати під різні рамки.
Ніщо в цій статті не є юридичною консультацією. Таблиця нижче перелічує рамки для обговорення з фахівцями з дотримання вимог, але не визначає, чи застосовується до вас будь-яка з них.
| Де / коли | Нормативні рамки дотримання вимог | Питання фахівцям з дотримання вимог | Де прочитати |
|---|---|---|---|
| США, компанії, які звітують перед SEC | Розділ 404 Sarbanes-Oxley, внутрішній контроль фінансової звітності (ICFR) | Чи використовуються результати цього інструмента у фінансовій звітності та чи має він входити до нашого переліку засобів контролю? | AS 2201 PCAOB |
| ЄС, персональні дані (зарплата, витрати працівників, банківські реквізити клієнтів) | GDPR | Яка наша законна підстава для цих даних у цьому інструменті та чи відповідають його заходи безпеки статті 32? | Посібник EDPB із захисту персональних даних |
| Велика Британія, персональні дані | UK GDPR | Яка наша законна підстава за UK GDPR та чи відповідає інструмент принципу безпеки? | Посібник ICO щодо принципів захисту даних |
| Усюди, де залучено карткові дані | PCI DSS (галузевий стандарт, що сам по собі не є законом) | Чи включає інструмент карткові дані до сфери застосування та чи може він узагалі уникнути роботи з ними? | PCI Security Standards Council про PCI DSS |
| ЄС, якщо інструмент оцінює кредитоспроможність фізичних осіб (за чинним графіком правила високого ризику з Додатка III застосовуються з 2 грудня 2027 року) | EU AI Act, категорія високого ризику (ШІ для виявлення фінансового шахрайства є винятком) | Чи є це системою ШІ високого ризику за Додатком III? | Сторінка Європейської комісії про AI Act; Додаток III AI Act |
| Персональні дані ЄС або Великої Британії, доступні окремому одержувачу поза відповідною юрисдикцією, або клієнтські договори, які визначають місце зберігання записів | Глава V GDPR, британські правила міжнародної передачі даних, ваші угоди з клієнтами | Чи можуть ці дані перебувати на сервері в [місце розташування] та чи обмежує це якийсь договір із клієнтом? | Посібник EDPB щодо міжнародної передачі даних; Рекомендації ICO щодо міжнародної передачі даних |
У рядку SOX AS 2201 є стандартом PCAOB для аудиторського підтвердження, на яке посилається розділ 404(b) закону Sarbanes-Oxley; він включає засоби контролю бухгалтерських записів і коригувань у процесі підготовки фінансової звітності наприкінці періоду до засобів, які аудитор оцінює під час розгляду ризику шахрайства. Поза цими регіонами почніть із сайту національного регулятора із захисту даних. Розташування сервера визначає місце його основного сховища; воно не повідомляє, де знаходиться кожна резервна копія, журнал або стороння копія, і саме по собі не забезпечує відповідність жодній із рамок вище.
Часті запитання
Чи безпечний вайб-кодинг для фінансових інструментів?
Він може бути безпечним, коли усунуто прогалини, що залишаються після демонстрації; я вважаю наведені докази радше проблемою розгортання, ніж програмування. Фінансовий інструмент ризикованіший за особистий проєкт, бо читає ERP і може робити записи в обліку. Щойно він проводить записи без другої особи для погодження, обробляє платежі або торкається карткових даних, його слід передати ІТ.
Що таке тіньовий ШІ у фінансах?
Тіньовий ШІ означає інструменти ШІ або створені ШІ застосунки, що використовуються з даними компанії без відома чи схвалення ІТ, наприклад підключену до ERP панель прогнозів, якої ІТ ніколи не бачило. За повідомленням IBM, звіт IBM Cost of a Data Breach Report за 2025 рік виявив, що організації з високим рівнем тіньового ШІ мали середні витрати на витік на 670 000 доларів вищі, ніж організації з низьким рівнем або без нього.
Що показати внутрішньому аудиту або зовнішньому аудитору?
До застосування інструмента під час закриття періоду надайте чотири речі: де він працює й хто має доступ, історію змін із тестами зафіксованих результатів, порядок погодження проводок в ERP та докази звірки кожної партії з підсумками ERP. Вимоги визначає аудитор; ці матеріали дають йому конкретний предмет оцінювання.
Хто відповідає за фінансовий інструмент, створений ШІ, після відходу його розробника?
До запуску призначте відповідального у фінансовій команді та технічну контактну особу. Використовуйте службові облікові дані замість власного входу розробника й надавайте доступ через корпоративний вхід, щоб вимкнення корпоративного облікового запису працівника, який пішов, блокувало нові входи, а наявні сеанси відкликалися або спливали відповідно до вашої політики сеансів. Виведення інструмента з експлуатації означає вимкнення його облікових даних, збереження того, чого вимагає політика зберігання, видалення решти та зупинку інструмента.
Обговорення
Коментарі
Увійдіть, щоб долучитися до обговорення.