IRONSTICK — Декларація GDPR про потоки даних
Відносини із зовнішніми великими мовними моделями
Фактичний, виведений із програмного коду опис кожного шляху, яким дані
залишають IRONSTICK у напрямку зовнішньої LLM, того, що саме передається, у якій формі та
де застосовується шар псевдонімізації. Версія для настільних комп'ютерів Windows. Цей документ
описує виключно поведінку IRONSTICK — те, що постачальник ШІ робить з отриманими
даними, регулюється виключно власними умовами постачальника (умовами та
політиками конфіденційності постачальників, яких налаштував користувач, — Google, Alibaba Cloud,
Moonshot AI, OpenAI та/або Anthropic), з якими користувач повинен ознайомитися окремо.
1. Сфера застосування та кінцеві точки
Зовнішні виклики ШІ всередині застосунку надходять до того постачальника, якого автоматичний каскад
використовує в цей момент. Користувач може налаштувати до п'яти постачальників; кожен
налаштований постачальник використовується автоматично в такому фіксованому, економному щодо витрат
порядку: Gemini (Google) → Qwen (Alibaba Cloud) → Kimi (Moonshot AI) →
ChatGPT (OpenAI) → Claude (Anthropic). Під час кожного запуску програми IRONSTICK
перевіряє, які з них відповідають; якщо протягом дня вичерпується квота чи кредит або
постачальник перестає відповідати, той самий запит повторюється в наступного
постачальника, який потім використовується до кінця дня. Зміст, що передається,
є ідентичним для кожного постачальника (починаючи з розділу 3: псевдонімізація
маршрутизатором, згода, журнал аудиту). Кінцевими точками є:
- Claude:
POST https://api.anthropic.com/v1/messages,
власний API-ключ користувача.
- ChatGPT:
POST https://api.openai.com/v1/chat/completions,
власний API-ключ користувача.
- Qwen:
POST https://dashscope-intl.aliyuncs.com/compatible-mode/v1/chat/completions
(Alibaba Cloud Model Studio, міжнародний регіон), власний API-ключ користувача.
- Kimi:
POST https://api.moonshot.ai/v1/chat/completions
(Moonshot AI), власний API-ключ користувача.
- Gemini (лише Windows): без API-ключа. IRONSTICK керує власним,
незміненим клієнтом командного рядка Google (Google Antigravity CLI) як прихованим локальним
процесом; у клієнті виконано вхід з обліковим записом Google користувача
(власне діалогове вікно входу Google — IRONSTICK ніколи не бачить пароля чи коду), і
він надсилає запит до Google у межах тарифного плану Google AI користувача. Клієнт не отримує
доступу до інструментів чи файлів IRONSTICK; він працює в порожній робочій папці
з приватною папкою профілю всередині каталогу даних, а його локальні
записи розмов і журнали видаляються після кожного виклику.
Gemini через обліковий запис Google є споживчою
послугою, а не каналом обробки за дорученням. Згідно з умовами Google
Antigravity, Google може використовувати взаємодії для вдосконалення своїх продуктів і
технологій машинного навчання, а співробітники Google можуть їх переглядати, якщо
користувач не вимкне цього в налаштуваннях Google Antigravity; для цього шляху не існує
договору про обробку даних. IRONSTICK передає той самий
псевдонімізований зміст, що й на шляхах через API, однак юридичній фірмі, професійні
правила якої вимагають договору про обробку даних з кожним обробником, не слід
налаштовувати Gemini — постачальник, якого не налаштовано, каскад ніколи не використовує.
Для кожного постачальника використовуються три конфігуровані рівні моделей (малий /
середній / великий). Окремим, необов'язковим каналом є
міст до настільного ШІ (розділ 4.9): там дані надходять до власного
локального настільного ШІ користувача (Claude Desktop / Claude Code, ChatGPT Desktop, Qwen
Desktop або Kimi Desktop), тобто до постачальника цього ШІ (Anthropic, OpenAI,
Alibaba Cloud/Qwen або Moonshot AI/Kimi) у межах власної підписки/облікового запису користувача в цього постачальника.
Мости можуть працювати паралельно — той самий локальний сервер MCP може бути зареєстрований
одночасно в Claude, ChatGPT, Qwen і Kimi, і вони можуть одночасно працювати над однією
справою. IRONSTICK не експлуатує жодного власного
сервера; жодні дані ніколи не надходять до виробника програмного забезпечення. Необов'язковий
сервер у локальній мережі фірми (IRONSTICK SERVER, розділ 9) цього не змінює: його
експлуатує сама юридична фірма, на власному обладнанні фірми, у межах
власної мережі фірми — він ніколи не зв'язується з виробником і ніколи не зв'язується з жодним
постачальником ШІ.
Головним перемикачем є власний доступ користувача. Зовнішня
обробка ШІ всередині застосунку існує лише тоді, коли користувач відкрив власний обліковий запис
у постачальника ШІ та ввів власний ключ доступу в конфігурації
(для Gemini: виконав вхід зі своїм обліковим записом Google).
Якщо не налаштовано жодного постачальника, жоден зовнішній виклик ШІ всередині застосунку взагалі неможливий — кожна
функція, описана в розділі 4, у такому разі залишається локальною або просто недоступна. Цей
обліковий запис є прямим договором між користувачем і постачальником; IRONSTICK не
є його стороною. Те саме стосується мосту до настільного ШІ, який вимагає
власної підписки/облікового запису користувача в обраного постачальника настільного ШІ
(Anthropic, OpenAI, Alibaba Cloud/Qwen або Moonshot AI/Kimi). Документи, позначені як секретні, виключаються
з інструментів мосту та чату, з пакета інструкцій для ШІ
та з усіх згенерованих результатів (вкладень, досьє, експортів);
їхня обробка під час реєстрації документів відбувається відповідно до свідомого вибору користувача в момент
реєстрації (розділ 4.1).
Повністю локально (ніщо не залишає комп'ютер): вилучення тексту та OCR,
детермінований локальний рівень чату, глобальний пошук, радар релевантності, аналіз
ланцюжків листів, генерування досьє/PDF, локальний прохід пошуковика для затемнення, а також
формування пакета інструкцій для ШІ.
2. Шар псевдонімізації
Кожен запуск агента всередині застосунку може мати псевдонімізатор, який токенізує вихідний текст,
перекладає аргументи інструментів назад для локального виконання, повторно токенізує результати інструментів
і локально детокенізує остаточну відповідь. Відповідність зберігається лише в пам'яті, по одній
новій відповідності на кожну операцію; вона ніколи не зберігається постійно.
2.1 Що замінюється
| Джерело | Поля | Токен |
|---|
| Записи клієнтів | ім'я, CNP, телефон, e-mail, адреса+місто |
$PARTEI_A$, $CNP_A$, $TEL_A$, $MAIL_A$, $ADRESSE_A$ |
| Особи / суб'єкти | повне ім'я (особи або компанії), CNP |
$PARTEI_B$ / $FIRMA_A$, $CNP_B$ |
| Справи | номер справи, опонент, позивач |
$FALL_A$, $PARTEI_C$… |
| Шаблонний рівень (невідомі значення у вільному тексті) |
номери судових справ (n/nnn/yyyy), 13-значні CNP, IBAN, адреси e-mail,
правдоподібні номери телефонів | ті самі сімейства токенів |
2.2 Що свідомо залишається справжнім
- Дати, час і грошові суми — їх спотворення було визнано більш
небезпечним, ніж їх передання.
- Назви установ (суди, органи влади) — їх немає в
словнику, і вони є публічними органами.
- Невідомі треті особи у вільному тексті — свідки, лікарі, адвокати,
судді чи компанії, які не збережені як записи клієнтів/осіб/справ, не
розпізнаються і передаються у відкритому вигляді. Це задокументована межа
цього підходу.
- Адреси осіб, які не є клієнтами — шаблону для адрес немає; токенізується лише
збережена адреса клієнта.
- Увесь фактичний зміст документів (твердження, діагнози,
виклад обставин) — замінюються лише ідентифікатори, а не сама історія.
2.3 Свідомі винятки зі справжніми іменами
- Вебдослідження щодо осіб (етап 1) та автозаповнення форм для осіб /
установ: вебпошук за
$PARTEI_A$ не має сенсу, тому
справжнє ім'я надсилається за задумом.
- Пошуковик ШІ для затемнення: він отримує текст, який уже було затемнено
локально, і повинен відповісти справжніми іменами невідомих третіх осіб, яких він
знаходить, — для цієї однієї мети псевдонімізацію вимкнено.
- Попередня обробка для читання вголос (TTS): див. 4.6 — речення передаються у відкритому
вигляді.
- Міст до настільного ШІ: необроблені дані за задумом (розділ 4.9).
3. Моменти надання згоди та журнал аудиту
Виклики, що спрямовуються через центральний маршрутизатор, залежать від згоди та журналюються: кожен
раунд моделі записує рядок у локальну таблицю аудиту (T0_AiExtLog) з
повним запитом і відповіддю у токенізованій формі, у якій вони фактично залишили
комп'ютер; відхилені/заблоковані спроби журналюються без корисного навантаження. Діалогове вікно
згоди зазначає рівень моделі та приблизний розмір запиту, а одне схвалення охоплює
поточний сеанс екрана (для реєстрації документів: поточний запуск програми).
Потоки з автоматичною згодою (без діалогового вікна): фонове
сортування пошти (безперервна робота), аналітичний запуск монітора даних
та пошуковик ШІ для затемнення (увімкнення його перемикача є згодою). Вони
все одно псевдонімізуються (за винятком передбачених відповідей пошуковика для затемнення зі справжніми іменами)
і все одно підлягають аудиту.
Потоки в обхід маршрутизатора: функції ШІ текстового редактора,
попередня обробка для читання вголос і виклик ШІ для корекції File→Markdown
звертаються до API безпосередньо. Вони псевдонімізуються (виняток: читання вголос),
але не показують власного діалогового вікна згоди та не записують рядків у журнал
аудиту. Використання користувачем цих функцій (натискання кнопки ШІ,
запуск генерування, запуск читання вголос з увімкненим перемикачем ШІ) є
моментом надання згоди.
4. Потоки даних за окремими сценаріями використання
4.1 Реєстрація документів
Вилучення тексту та OCR виконуються локально. Якщо налаштовано API-ключ, IRONSTICK запитує
згоду один раз за запуск програми, після чого виконуються до чотирьох типів викликів (усі псевдонімізовані, усі
підлягають аудиту):
- Визначення основного документа (малий рівень): необроблений текст OCR фрагментами
не більше 2 000 символів, максимум 8 викликів — лише для сканів низької якості.
- Корекція OCR (малий рівень): текст документа, обмежений 16 000
символів.
- Класифікація (середній рівень): текст документа, обмежений 16 000
символів, а також системні списки: повний список справ (номер справи,
ім'я клієнта, опонент — токенізовані), пул відомих імен, обмежений 2 000
символів (токенізований), а також списки кодів типів установ і типів документів
(нетокенізовані позначення). Резервний варіант: малий рівень, 8 000 символів, без
списків.
- Контекстуалізація під час збереження (малий рівень): метадані документа та
повний текст, обмежений 30 000 символів, а також індексний рядок (ID, дата, назва ≤120
символів) кожного активного доказу того самого клієнта — використовується для обґрунтування
перехресних посилань. Виконується також для документів, позначених як секретні (свідоме рішення
користувача).
4.2 Монітор пошти (сортування)
Призначення справи спочатку відбувається детерміновано (номер справи або відомий реєстраційний номер,
знайдений у темі/фрагменті, — без виклику ШІ). В іншому разі виконується один виклик малого рівня на
кожен лист, що містить рівно: ім'я та адресу відправника, тему та збережений
фрагмент попереднього перегляду (жорстко обмежений 1 500 символів) — ніколи не повний текст листа —
а також повний список справ (токенізований) як контекст для зіставлення. Відповідь: пріоритет +
номер справи. На екрані пошти це залежить від згоди, що надається один раз за сеанс; у
фоновому режимі це виконується без діалогового вікна (увімкнення монітора є
згодою). В обох режимах — псевдонімізація та аудит.
Жодних пікселів відстеження. Відкриття листа в моніторі ніколи не призводить до звернення
до сервера відправника: зображення, на які посилається інтернет-адреса (включно з
невидимими пікселями відстеження), не завантажуються і відображаються як заповнювачі (плейсхолдери) з
повідомленням, тож відправник не може дізнатися, коли, як часто чи з якої адреси
лист було прочитано. Відображаються лише зображення, вбудовані в сам лист.
4.3 Аналіз осіб (вебдослідження)
Три етапи після згоди, що надається один раз за сеанс:
- Етап 1 — пошук: локальні пошукові системи опитуються безпосередньо; додатково
викликається серверний інструмент вебпошуку постачальника зі справжнім
ім'ям особи у відкритому вигляді (неминуче для пошуку; журналюється у відкритому вигляді).
- Етап 2 — резюме сторінок (середній рівень): для кожної сторінки — ім'я особи
(токенізоване), URL та вміст сторінки, обмежений 8 000 символів.
- Етап 3 — синтез профілю (великий рівень): ім'я та місто (токенізовані),
а також кожен зібраний текст сторінки, обмежений 6 000 символів на джерело.
Результат зберігається локально з достовірністю «не підтверджено». Пов'язані
кнопки автозаповнення у формах осіб/установ так само надсилають введене
ім'я у відкритому вигляді (задокументований виняток).
4.3a OSINT-перевірка сторони (osint_entity)
OSINT-перевірка сторони — це фіксована процедура, яку застосунок виконує
самостійно, коли підключений ШІ викликає її з ім'ям, містом, округом, країною та
зазначенням фізичної/юридичної особи:
- Матеріали справ: повнотекстовий пошук імені в локальній
базі даних — суто локально, ніщо не залишає комп'ютер.
- Інтернет: фіксований список пошукових запитів надсилається до публічних
пошукових систем Google, DuckDuckGo та Qwant. Кожен запит складається з
пошукового терміна мовою країни сторони, а також справжнього
імені сторони у відкритому вигляді і, для деяких запитів, міста чи округу
(неминуче для пошуку). Жоден зміст справ, клієнтів чи документів не
передається. Пошукові системи бачать ці запити так само, як запити будь-якого користувача браузера.
- Gemini (лише якщо налаштовано): якщо користувач налаштував Gemini через
вхід у Google, до Google надсилається рівно один запит (prompt) — прохання
знайти все про названу сторону з названої країни, — що містить
справжнє ім'я та країну у відкритому вигляді і нічого іншого.
Результат повертається ШІ, що здійснив виклик, як підготовлений, неперевірений профіль.
Ніщо не записується до основних даних: кожна знахідка проходить контрольний шлюз
монітора даних (розділ 4.5) і приймається лише тоді, коли
користувач її схвалює. Оцінюються лише загальнодоступні джерела.
4.4 Щоденний протокол
Сам екран є локальним. Імпорт довільного тексту спочатку запускає локальний
синтаксичний аналізатор; лише якщо не знайдено жодного маркера формату протоколу, резервний механізм ШІ
нормалізує необроблений текст: вставлений текст надсилається повністю (переривання понад 200 000
символів), малий рівень, залежить від згоди, псевдонімізований, підлягає аудиту. Збережені
протоколи залишають комп'ютер лише як результати інструментів чату/мосту
(обмежені витяги) або в складі пакета інструкцій для ШІ (розділ 5).
4.5 Монітор даних
Фаза 1 (e-mail ↔ основні дані) є повністю детермінованою. Фаза 2 надсилає один
виклик малого рівня (псевдонімізований, підлягає аудиту, без діалогового вікна, обмежений новими
вхідними документами), що містить: усі збережені основні записи установ та осіб/суб'єктів
власника (ID, імена, контактні дані, CNP — токенізовані, якщо вони є
в словнику; назви установ — у відкритому вигляді), усі імена сторін зі справ, а також дедупліковані фрагменти контактних ділянок (±~100 символів
навколо маркерів адреси/телефону/податкових даних) з повних текстів вхідних документів, обмежені
загалом 130 000 символів. Відповідь завжди стає лише пропозицією, яку
користувач повинен прийняти в моніторі.
4.6 Текстовий редактор (допомога ШІ в тексті)
- Переробка виділеного фрагмента: виділене речення/абзац/розділ (з
розміткою) а також перші 6 000 символів усього документа як контекст
та інструкція користувача — середній рівень, псевдонімізовано.
- Структура/Зміст: фактично весь документ як індексований список рядків
(короткі рядки повністю, довгі рядки скорочені до 80 символів), обмежений 40 000
символів — середній рівень, псевдонімізовано.
- Попередня обробка для читання вголос: під час читання документа вголос кожне
речення надсилається окремо до малого рівня у відкритому вигляді для розгортання
скорочень і чисел — без псевдонімізації (ідентифікаційні
номери мають повертатися незмінними, щоб бути правильно прочитаними). Штампи файлів і маркери
посилань спочатку локально видаляються. Запуск читання вголос є моментом надання
згоди.
Жоден із викликів текстового редактора не показує окремого діалогового вікна
згоди і не записує рядків у журнал аудиту (обхід маршрутизатора, див. розділ 3).
4.7 Перевірка Red/Blue Team та резюме діалогу (API)
До підготовки документів належать ще два потоки через API. Red/Blue Team: якщо користувач
увімкнув цю функцію для активного постачальника (перемикач поруч з API-ключем; потрібен збережений
ключ), кожен офіційний документ, переданий через
deliver_file — як із чату всередині застосунку, так і з мосту до настільного
ШІ, — ще раз прочитується тим самим постачальником у ролі адвоката протилежної сторони
(середній рівень). Передається: текст проєкту, дата та юрисдикція
справи; псевдонімізація через маршрутизатор і аудит, як і для кожного виклику маршрутизатора;
без окремого діалогового вікна — перемикач є згодою; щонайбільше два раунди на
файл, після другого раунду файл передається в будь-якому разі, із доданим для користувача
звітом рецензента. Резюме діалогу: у тривалих сеансах чату
старша частина діалогу (лише запитання користувача та остаточні відповіді
моделі, ніколи не результати інструментів) стискається активним постачальником
(малий рівень, у фоновому режимі) до резюме обсягом 2 000 символів, яке замінює необроблену
історію; воно зберігається в зашифрованому вигляді в проміжному сховищі і щоразу
перезаписується.
4.8 Чат ШІ (зовнішній, API)
Згода один раз за сеанс чату; середній рівень з автоматичним переходом до
великого рівня (тоді весь контекст надсилається повторно); псевдонімізовано; кожен раунд
підлягає аудиту. Кожен хід передає: системний запит (статичні правила), актуальний
контекст графічного інтерфейсу (поточний екран, відкрита справа/клієнт, включно з ім'ям клієнта — токенізоване),
до 10 записів пам'яті ШІ відкритого клієнта, найновішу частину діалогу,
обмежену 6 000 символів, а також резюме старших ходів обсягом 2 000 символів
(4.7) і список проміжних файлів чату. Кожен інструмент, який викликає модель,
повертає свій результат у розмову через API — включно з повними текстами документів
(обмеженими 10 000 символів на елемент; більші результати записуються до
зашифрованого проміжного сховища і зчитуються частинами), текстами листів і
витягами зі щоденного протоколу. З вересня 2026 року чат використовує той самий рівень
інструментів і ті самі шлюзи передання, що й міст до настільного ШІ (4.9): перевірку
процесуальних документів, Red/Blue Team (4.7) і передання через діалогове вікно експорту —
те, що залишає систему, є шаблоном, придатним для подання. Локальний рівень чату
відповідає на рутинні запити без будь-якого передання даних.
Окремої згадки заслуговують два допоміжні інструменти. get_weather
отримує поточні дані про погоду для названого місця від сервісу Open-Meteo, що не є LLM
(розділ 7), — цьому сервісу передається лише назва місця / його координати,
ніколи не дані справ чи осіб. get_my_location
відповідає виключно на основі останнього локально збереженого знімка безпеки
(розділ 8): запит ШІ не ініціює жодного нового зовнішнього запиту —
він лише зчитує те, що вже є на диску. Як і в разі кожного інструмента, те, що ці інструменти
повертають, надходить назад у розмову зі ШІ, тобто до постачальника ШІ.
4.9 Міст до локального настільного ШІ (Claude Desktop / Claude Code / ChatGPT
Desktop / Qwen Desktop / Kimi Desktop) — НЕОБОВ'ЯЗКОВІ додаткові модулі
Кожен доступ до настільного ШІ є необов'язковим модулем, що придбавається окремо.
Він існує лише там, де юридична фірма придбала та встановила відповідний
модуль мосту; без жодного модуля розділ мосту в конфігурації залишається
заблокованим, локальна кінцева точка ніколи не запускається, і жоден із потоків,
описаних у цьому розділі, не може відбутися. Той самий локальний STDIO-сервер MCP може бути
зареєстрований у Claude Desktop/Claude Code, ChatGPT Desktop,
Qwen Desktop та/або Kimi Desktop — описаний нижче механізм є ідентичним для всіх; відрізняється лише
постачальник-одержувач.
Цей канал передає необроблені, непсевдонімізовані дані
справ. У цьому і полягає його призначення: власний сеанс настільного ШІ користувача готує
шаблони, придатні для подання, і тому потребує справжніх імен і номерів.
- Настільний ШІ (Claude Desktop/Code, ChatGPT Desktop, Qwen Desktop або Kimi Desktop)
підключається через локальний міст до запущеного застосунку;
кінцева точка HTTP прив'язується лише до 127.0.0.1 (localhost є межею доступу;
збережений токен додатково не перевіряється).
- Під час першого доступу до даних за запуск програми IRONSTICK показує блокувальне модальне вікно
згоди; відмова блокує канал на 10 хвилин. Після схвалення канал
залишається відкритим до кінця запуску програми.
- Понад 170 інструментів — з них понад 100 інструментів читання — надають доступ до хронік, повних текстів, листів e-mail,
щоденних протоколів, строків, основних даних, цілих справ (частинами) та форматів
виведення; документи, позначені як секретні, виключено. Шляхи запису проходять через контрольний шлюз
(пропозиції щодо основних даних/зв'язків потрапляють до монітора даних;
запропоновані ШІ зміни до прив'язаних до справи нотаток з інструкціями для ШІ відображаються як
червоно-зелене порівняння (diff) всередині IRONSTICK і застосовуються лише після того, як користувач явно
їх прийме, — рішення повідомляється ШІ) або є явними (передання до
текстового редактора, доставлення файлів, навігація — лише за окремого
дозволу). Той самий принцип контрольного шлюзу охоплює два новіші шляхи запису:
записи хроніки ніколи не записуються ШІ — він лише ПОПЕРЕДНЬО ЗАПОВНЮЄ форму
реєстрації, яку користувач заповнює до кінця і зберігає сам; а виправлений ШІ повний текст
документа (повторне сканування OCR, наступний пункт) замінює збережений повний текст лише після того,
як користувач побачив повний текст у діалоговому вікні підтвердження і зберіг його.
- Виправлення через повторне сканування OCR (локально) та передання PDF (з ініціативи користувача).
Якщо збережений повний текст обрізаний або зіпсований старим запуском OCR, ШІ може
запросити нове сканування: користувач обирає сторінки, повторне сканування виконується локально
(без нового зовнішнього одержувача), і обидві версії тексту розміщуються в локальному
проміжному просторі; усе, що ШІ з них зчитує, надходить до його постачальника, як і будь-який
інший результат інструмента. Як абсолютно крайній захід — лише після такого повторного сканування і
лише в межах жорстких обмежень, що забезпечуються мостом (≤ 10 MB, ≤ 90 сторінок), —
ШІ може попросити користувача передати йому оригінальний PDF-файл: IRONSTICK
лише відкриває запис; користувач сам зберігає PDF через значок скріпки
і перетягує його в чат настільного ШІ. Це передає документ
як файл (включно зі штампами, підписами та зображеннями) постачальнику цього ШІ —
це відбувається виключно внаслідок власної свідомої дії користувача, ніколи
автоматично, а документи, позначені як секретні, від самого початку виключено з усього
каналу повторного сканування.
- Локальний проміжний простір ШІ (мінімізація даних). Будь-який виклик інструмента може перенаправити
свій повний результат до локального, тимчасового проміжного файлу (
to_scratch);
ШІ тоді отримує лише шлях до файлу та короткий попередній перегляд (≈1 200
символів) замість повного тексту. Локальні інструменти редагування
(пошук/заміна/вставлення/порівняння/нормалізація) переробляють ці файли на комп'ютері
користувача, а інструменти доставлення/оновлення використовують їх за шляхом — таким чином великий обсяг змісту
може транспортуватися та перероблятися взагалі без передання постачальнику
ШІ. Повні вивантаження справ (dump_case_to_scratch)
і протокол початку сеансу, що створюється одним викликом, так само записуються безпосередньо в цю
локальну область; до постачальника надходять лише ті частини, які ШІ згодом зчитує.
IRONSTICK додатково стежить за актуальністю цих файлів і анулює їх,
коли змінюються базові дані. Проміжна папка розташована всередині папки
даних і зберігається між сеансами (вона є робочим контекстом ШІ);
файли, до яких не зверталися, видаляються через 180 днів, і жоден новий зовнішній одержувач не
виникає.
- Проміжне сховище є зашифрованим сховищем (з вересня 2026 року).
Кожен файл у проміжному сховищі зберігається зашифрованим за AES-256, з тим самим
виведенням ключа, що й для бази даних і сховища документів. Читання та запис
відбуваються лише через шлюз IRONSTICK; файл у відкритому вигляді, поміщений у сховище
будь-яким іншим шляхом (інструментом файлової системи настільного ШІ, ручним копіюванням),
відхиляється, видаляється, і про нього повідомляється ШІ як про порушення правил; файли залишають
сховище лише через діалогове вікно експорту IRONSTICK, ніколи не до папки завантажень.
Разом із зашифрованою базою даних, сховищем документів і файлом конфігурації
це закриває останню прогалину на локальному комп'ютері: жодні дані справ не зберігаються
незашифрованими на диску користувача — навіть робочі файли ШІ. Скопійований
диск, загублений накопичувач чи архів резервної копії в чужих руках дають лише
шифротекст.
- Результати інструментів доставляються до клієнта настільного ШІ користувача, а звідти
до його постачальника: Anthropic для Claude (у межах підписки Claude
користувача та умов Anthropic), OpenAI для ChatGPT (у межах підписки ChatGPT
користувача та умов OpenAI), Alibaba Cloud/Qwen для Qwen
Desktop (у межах облікового запису Qwen користувача та умов Qwen) або Moonshot AI для Kimi
Desktop (у межах облікового запису Kimi користувача та умов Moonshot AI). IRONSTICK не записує
рядків журналу аудиту для трафіку мосту; верхня панель показує по одному пульсуючому логотипу для кожного
активного ШІ (знак Claude, знак ChatGPT, знак Qwen, знак Kimi) — одночасний доступ
можливий, і про кожен сигналізується окремо. Сам міст веде
суто локальний діагностичний журнал своїх викликів інструментів — позначка часу, назва інструмента,
успіх/невдача та розмір відповіді, ніколи не будь-який зміст — у простому файлі
поруч із програмою мосту. Цей журнал нікуди не передається і слугує
лише для усунення несправностей.
- Спільна пам'ять ШІ зберігає локально узагальнені висновки (≤1 000 символів кожен,
прив'язані до клієнта/справи, з автоматичним закінченням строку дії); її зміст видимий для кожного
каналу ШІ і передається щоразу, коли ці канали його зчитують.
- Взаємна перевірка між настільними ШІ відбувається через IRONSTICK, а не безпосередньо
між постачальниками: один ШІ залишає робочий продукт (наприклад, проєкт) у
локальному, короткочасному буфері обміну (прості файли на комп'ютері користувача,
що видаляються після закриття завдання і повністю стираються під час кожного перезапуску застосунку) та
нотатку до завдання; інший ШІ зчитує його, коли користувач йому це доручає. Це не створює
жодного нового зовнішнього одержувача — усе, що зчитує ШІ, який виконує перевірку, передається
до його власного постачальника точно так само, як і будь-який інший результат інструмента вище, у межах умов
цього постачальника. Зміст ніколи не переходить від одного постачальника до іншого.
5. Пакет інструкцій для ШІ (експорт ZIP)
Формування пакета відбувається локально і не передбачає жодного виклику ШІ. Воно створює
Markdown у відкритому вигляді (без псевдонімізації), призначений для завантаження
користувачем до зовнішньої LLM на його вибір. Зміст:
| Файл | Зміст |
|---|
| Справи | усі справи обраного клієнта зі сторонами, статусом та
індексом ID доказів (без повних текстів) |
| Суб'єкти | усі особи/суб'єкти всієї юридичної фірми (не
лише цього клієнта), включно з CNP/CUI, датою народження, повними контактними даними, професією,
транспортним засобом — а також збережені аналітичні блоки (оцінка, вразливості,
місця проживання, фінанси, соціальне оточення, джерела) |
| Установи, строки | усі установи; активні строки з
номерами справ та ім'ям клієнта |
| Пошта | 100 останніх листів e-mail у масштабі всієї фірми: відправник,
одержувач, тема, імена файлів вкладень, фрагмент ≤500 символів (без повних
текстів листів) |
| Щоденний протокол | останні 10 днів, у масштабі всієї фірми, включно з хронологією
справ за цей період |
| За кожною справою | одне досьє на справу: повна хроніка з
повними текстами документів (бюджет ~170 KB на файл, далі компактна форма), ідентифікатори клієнта та
сторін, включно з CNP; а також усі фонові нотатки до справи без обмежень |
| Файли інструкцій | п'ять документів з робочими правилами — без персональних даних |
Що відбувається, коли цей ZIP передається сторонній LLM:
користувач особисто передає у відкритому вигляді значні частини всієї
юридичної фірми — особи клієнтів з національними ідентифікаційними номерами, профілі третіх осіб,
включно з чутливими оцінками, метадані кореспонденції в масштабі всієї фірми та матеріали
справ — цьому постачальнику. З цього моменту дані обробляються згідно з умовами
стороннього постачальника (використання для навчання, зберігання, юрисдикція) повністю
поза контролем IRONSTICK. IRONSTICK показує попередження про конфіденційність перед
експортом (один раз за запуск програми) і пропонує експорт також до Google Drive, що
додатково розміщує файли в Google. Користувач діє як контролер, що здійснює передання,
відповідно до GDPR і повинен забезпечити правову підставу (наприклад, ст. 6, правила професійної
таємниці) перед завантаженням.
Документи, позначені як секретні, виключено зі строків, щоденних протоколів і досьє
справ.
6. Зведена матриця
| Потік | Що залишає систему (форма) | Псевдонімізовано | Власне діалогове вікно згоди | Журнал аудиту |
|---|
| Реєстрація документів (4 виклики) | текст OCR/документа ≤30k, списки справ/імен | так | так — один раз за запуск програми | так |
| Сортування пошти (екран) | Від/Тема/Фрагмент ≤1.5k + список справ | так | так — один раз за сеанс | так |
| Сортування пошти (фоновий режим) | те саме | так | ні (перемикач монітора = згода) | так |
| Дослідження осіб, ет. 1 | справжнє ім'я (вебпошук) | ні — за задумом | так — один раз за сеанс | так (у відкритому вигляді) |
| Дослідження осіб, ет. 2/3 | тексти сторінок ≤8k / ≤6k на джерело | так | та сама згода | так |
| Автозаповнення осіб/установ | введене ім'я (вебпошук) | ні — за задумом | так — один раз за сеанс | так (у відкритому вигляді) |
| Імпорт ШІ до щоденного протоколу | вставлений необроблений текст ≤200k | так | так | так |
| Монітор даних | основні записи + контактні ділянки ≤130k | так (назви установ у відкритому вигляді) | ні (обмежений фоновий режим) | так |
| Текстовий редактор: переробка / структура | виділений фрагмент + 6k контексту / рядки документа ≤40k | так | ні (кнопка = згода) | ні |
| Попередня обробка для читання вголос | кожне речення, у відкритому вигляді | ні | ні (запуск = згода) | ні |
| Перевірка Red/Blue Team (API) | текст проєкту + дата + юрисдикція, за раунд (макс. 2) | так | ні (перемикач = згода) | так |
| Резюме діалогу (API) | старші ходи діалогу (лише користувач/асистент) | так | ні (частина згоди на чат) | так |
| Корекція ШІ File→Markdown | перетворений текст | так | ні | ні |
| Пошуковик ШІ для затемнення | уже затемнений текст; відповіді містять справжні імена третіх осіб | вимкнено — за задумом | перемикач = згода | так |
| Чат ШІ (зовнішній) | запит + контекст інтерфейсу + пам'ять + 6k останнього діалогу + 2k резюме + результати інструментів ≤10k/елемент | так | так — один раз за сеанс | так |
| Міст до настільного ШІ (Claude Desktop/Code, ChatGPT Desktop, Qwen Desktop, Kimi Desktop) | необроблені результати інструментів (повні дані справ) | ні — за задумом | так — один раз за запуск програми, блокування на 10 хв у разі відмови | ні (на боці застосунку) |
| ZIP з інструкціями для ШІ | експорт даних фірми у відкритому вигляді (завантаження з ініціативи користувача) | ні | попередження один раз за запуск програми | н/з |
7. Зовнішні сервіси, що не є LLM (для повноти)
Незалежно від будь-якої LLM, такі функції звертаються до зовнішніх сервісів з
мінімально необхідними даними: перевірка номерів (EU VIES, EORI, GLEIF, торговельні
реєстри — номер, що перевіряється), геокодування адрес (OpenStreetMap
Nominatim — адреса), прямі вебзапити пошуку осіб (ім'я), IMAP (Ваш поштовий сервер) та
необов'язкові експорти до Google Drive (експортовані файли). Жоден із них не залучає
постачальника ШІ.
Ще два сервіси отримують так само мінімальні дані:
- ipwho.is (геолокація за IP) — один раз під час кожного запуску програми, у межах
локального знімка безпеки (розділ 8), IRONSTICK запитує в цього сервісу
публічну IP-адресу комп'ютера та приблизне місцезнаходження (місто, країна, інтернет-провайдер).
Вихідний HTTPS-запит не містить жодного персонального корисного навантаження —
як і будь-який вебсервер, сервіс бачить лише IP-адресу, з якої
надходить запит. Відповідь зберігається виключно локально і нікуди більше
не передається.
- Open-Meteo (погода) — на запит інструмент ШІ для погоди
(
get_weather, розділ 4.8) запитує поточні дані про погоду для
названого місця. Передається лише назва місця / його координати — ніколи
дані справ, клієнтів чи осіб.
Жоден із цих сервісів не залучає постачальника ШІ.
8. Локальне зберігання, цілісність і контроль користувача
Незалежно від описаних вище каналів ШІ, щодо всіх
даних, які зберігає IRONSTICK, діє таке:
- Виключно локальне зберігання. Увесь набір даних — база даних, файли
документів, медіафайли, транскрипти, конфігурація — зберігається в одному каталозі даних за
шляхом, який визначає користувач. IRONSTICK не потребує хмарного облікового запису і не експлуатує
жодного сервера; виробник ніколи не зберігає копії будь-яких даних користувача. Якщо юридична фірма використовує
необов'язковий IRONSTICK SERVER (розділ 9), цей сервер також є власним
пристроєм фірми у власній мережі фірми — щодо доступу виробника нічого не змінюється.
- База даних зашифрована під час зберігання (AES-256). База даних — записи
про клієнтів, справи, хроніку, листи e-mail, строки, текст транскриптів і
пам'ять ШІ — зберігається зашифрованою за AES-256, кожна сторінка окремо і
з печаткою цілісності для кожної сторінки. Ключ виводиться застосунком під
час виконання і ніколи не записується на диск чи до конфігурації, тож файл бази даних,
отриманий з носія або з архіву резервної копії, без IRONSTICK нічого не дає.
Це технічний захід у розумінні ст. 32 GDPR, який
застосовується без будь-якого налаштування користувачем і не може бути вимкнений.
- Документи зашифровані під час зберігання (AES-256). Сховище документів —
оригінальні PDF, скани, зображення, аудіо- та файли транскриптів — зашифроване
у той самий спосіб, файл за файлом, з печаткою цілісності, що виявляє зміни.
Читання відбувається через єдиний шлюз, який розшифровує запитаний файл
у тимчасову робочу копію і видаляє ці копії, коли
застосунок закривається або запускається. Резервні копії та пакети справ містять документи
в зашифрованому вигляді. Обмеження, викладені прямо: робочі копії
поточного сеансу зберігаються у відкритому вигляді в тимчасовій папці (на Android ця
папка розташована в спільному сховищі); експорти та вихідна пошта за задумом є відкритим текстом;
а шифрування захищає від читання носія поза
IRONSTICK, а не від уповноваженого користувача застосунку.
- Контроль доступу під час запуску (TOTP). Після прийняття
ліцензійного ключа застосунок не показує нічого, крім запиту коду, доки користувач
не введе поточний шестизначний одноразовий код на основі часу із
застосунку-автентифікатора (RFC 6238). Секрет, що лежить в основі кодів, виводиться з
ліцензійного ключа під час виконання і ніколи не записується на диск; зберігається лише
несекретний відбиток підтвердженого налаштування, щоб QR-код
знову відображався після зміни ключа. Повторні неправильні коди спричиняють дедалі довше
очікування. Мости до настільного ШІ не отримують жодних даних справ, поки застосунок
заблоковано. Відновлення здійснюється за допомогою ліцензійного ключа, що робить ліцензійний ключ
головними обліковими даними інсталяції — відповідальність за його зберігання несе
оператор. Файл конфігурації (API-ключі, облікові дані e-mail,
доступ до сервера) зберігається зашифрованим за AES-256 за тим самим механізмом, що й
документи, і розшифровується лише в пам'яті.
- Місце зберігання під контролем користувача. Шлях до даних обирається під час
встановлення і може бути змінений будь-коли — зокрема на знімний носій, наприклад
зашифрований USB-накопичувач чи зашифрований зовнішній диск. Застосунок просто
слідує налаштованому розташуванню; шифрування носія (наприклад, засобами шифрування дисків
операційної системи) перебуває в руках користувача і
рекомендується для портативних носіїв. Один наслідок, який слід свідомо зважити: якщо
обраний каталог даних розташований у папці, що синхронізується з хмарою (наприклад, Google
Drive), увесь набір даних включно з файлом конфігурації з ключем доступу до ШІ
та обліковими даними e-mail синхронізується з цим хмарним постачальником
згідно з власними умовами постачальника — розміщення там каталогу даних є
рішенням і відповідальністю користувача.
- Синхронізація пристроїв без будь-якої хмари. Необов'язкова
синхронізація Windows ↔ планшет Android відбувається через пряме
кабельне USB-з'єднання — жоден сторонній сервіс не залучається, передання
перевіряються контрольними сумами, а перед заміною бази даних обов'язково створюється
резервна копія. Документи, позначені як секретні, взагалі ніколи не передаються на
планшет.
- Знімок безпеки під час запуску (локальний журнал входів). Під час кожного запуску
програми IRONSTICK у фоновому режимі фіксує знімок комп'ютера, на якому
він працює: ім'я хоста, операційна система, RAM/CPU, локальна IP-адреса, браузер
за замовчуванням, виявлені запущені інструменти віддаленого доступу та похідний
показник безпеки — а також, один раз за запуск, публічна IP-адреса та приблизне місцезнаходження
(місто, країна, інтернет-провайдер), отримані від сервісу геолокації за IP ipwho.is (розділ 7).
Знімок зберігається виключно локально в базі даних (таблиця
T9_LoginLog) і нікуди не передається. Строк зберігання автоматично обмежується
максимум 6 місяцями та максимум 1 000
записів (щоденне очищення), і користувач може будь-коли переглянути журнал
у конфігураторі (картка «Журнал входів»).
- Відбитки цілісності кожного зареєстрованого файлу. У момент
реєстрації кожен збережений файл отримує криптографічний відбиток змісту
(SHA-256 для документів і медіафайлів; застарілий відбиток MD5 для аудіофайлів
транскриптів), що фіксується в базі даних поруч із записом. Тому будь-яку пізнішу зміну
збереженого файлу можна виявити, порівнявши файл із його
зафіксованим відбитком, а експорти e-discovery (EDRM) містять ці відбитки,
щоб одержувачі могли незалежно перевірити файли. Це робить маніпуляцію
очевидною; як і будь-який механізм відбитків, він фізично не запобігає змінам
файлів на диску — він робить їх доказовими.
- Резервне копіювання на розсуд користувача. Вбудована функція резервного копіювання записує
повну копію даних (повну резервну копію або резервну копію лише даних) у вигляді одного ZIP-
архіву до будь-якого місця призначення, обраного користувачем, і відновлює дані з такого архіву
на вимогу. Як часто створюються резервні копії, де вони зберігаються, як довго вони
зберігаються і чи додатково шифруються архіви — повністю
рішення користувача (база даних і файли документів усередині кожного архіву в будь-якому разі
зашифровані за AES-256) —
IRONSTICK не встановлює жодного розкладу і нікуди не передає резервні копії.
- Згенеровані документи належать користувачеві. Користувач може будь-коли генерувати
документи — процесуальні документи, листи, досьє, списки, експорти — і
завантажувати їх: вони записуються до локальної папки «Документи» або, якщо
користувач розмістив каталог даних у папці Google Drive чи явно
обирає Google Drive як місце призначення, до власного облікового запису Google Drive користувача.
Роль IRONSTICK закінчується створенням файлу. Усе, що відбувається зі
згенерованим документом після цього, — друк, подання до суду, надсилання e-mail,
завантаження до будь-якого сервісу, передання третім особам — здійснюється користувачем і
належить виключно до сфери відповідальності користувача.
Розподіл відповідальності. Оскільки IRONSTICK зберігає
все локально і передає дані лише шляхами, задокументованими в розділах
1–7, — кожен з яких або псевдонімізований, або залежить від згоди, або ініціюється
свідомою дією користувача, — оператор юридичної фірми є єдиним
контролером даних: він обирає носій даних та його шифрування, керує резервними копіями і
зберігає їх, вирішує, які функції ШІ увімкнено, надає або не надає кожну
згоду і самостійно вирішує, що робити з кожним документом, експортом чи резервною копією,
які створює програмне забезпечення. Згенерований ШІ зміст — проєкти, резюме, оцінки,
класифікації — завжди є пропозицією, яку користувач повинен професійно
перевірити, перш ніж покладатися на неї чи надсилати її. Цей документ існує для того, щоб кожне
з цих рішень могло бути ухвалене з повним знанням фактичних потоків
даних.
9. Необов'язковий сервер у локальній мережі фірми (IRONSTICK SERVER)
Юридичні фірми з кількома робочими місцями IRONSTICK можуть експлуатувати необов'язковий
IRONSTICK SERVER — службу координації, що працює на власному
Synology NAS фірми, у межах власної локальної мережі фірми. Для цілей цієї
декларації вирішальними є такі факти:
- Жодна зовнішня сторона не залучається. Сервер є власним
пристроєм фірми. Він приймає з'єднання лише з приватних (локальних) мережевих адрес
і ніколи не ініціює жодного з'єднання з інтернетом — жодної телеметрії, жодних
перевірок оновлень, жодного контакту з виробником. Виробник програмного забезпечення не має жодного
доступу.
- Жодної участі ШІ. Сервер не передає трафіку ШІ, не зберігає ключа
ШІ і ніколи не взаємодіє з жодним постачальником мовних моделей. Усі канали ШІ,
описані в розділах 1–6, залишаються суворо в межах окремого робочого місця;
на шар псевдонімізації, шлюзи згоди та журнал аудиту
присутність сервера не впливає.
- Що зберігає сервер — усе це на NAS, під контролем
фірми: (a) спільні пакети справ — лише справи, які користувач явно
відкрив для колег; документи, позначені як секретні, за задумом виключено, і вони
ніколи не потрапляють на сервер; (b) центральна правова бібліотека — публічні
тексти законів у форматі Markdown, кожен з ім'ям користувача, який його додав, посиланням на
джерело та датою перевірки; (c) записи обліку робочого часу — за користувачем, днем і
справою: номер справи, ім'я клієнта та хвилини, що повідомляються кожним робочим місцем у
фоновому режимі; (d) загальні показники присутності за користувачем і днем, похідні від
сигналів активності сеансу; (e) метадані подій справ — надання доступу, відкликання,
початок/закінчення підписок та експорти, кожне з датою, часом і IP-адресою
в LAN; (f) журнал безпеки з адміністративними подіями та подіями входу,
включно з IP-адресами в LAN; (g) пакети передання справ — коли користувач
передає право власності на справу колезі, повна справа переміщується як один
архів через проміжну зону сервера («spool»); пакет видаляється з
сервера після того, як одержувач підтвердив імпорт, а документи,
позначені як секретні, передаються лише після явного додаткового
підтвердження власника (інакше передання переривається); (h) центральне
приймання сканів (необов'язковий Central Scan App): реєстр номерів справ
і відображуваного імені кожного користувача (що повідомляються робочими місцями як
матеріал для зіставлення — ніколи не зміст справ) та проміжна черга
документів для кожного файлу, яка утримує відскановану вхідну пошту, адресовану одному користувачеві, доки
робоче місце цього користувача не отримає і не підтвердить її, після чого серверна
копія видаляється; розпізнавання тексту та зіставлення з одержувачем відбуваються локально на
робочому місці сканування, без будь-якого ШІ; (i) записи подій резервного копіювання —
кожне робоче місце повідомляє про свої події резервного копіювання та відновлення даних (вид, ім'я
файлу, розмір, час, IP-адреса в LAN), тож адміністратор може бачити для кожного користувача, коли
було створено останню резервну копію, і нагадувати користувачам, які відстають; (j) загальний
для фірми довідник сторін («мережа суб'єктів») — основні записи про
осіб і компанії, установи, зв'язки між ними та
аналізи осіб, що ведуться робочими місцями, разом із чергою
пропозицій змін, якими обмінюються користувачі. Див. наступний пункт.
- Загальний для фірми довідник сторін. Щойно робоче місце
підключається до сервера, його основні дані про сторони (хто є хто: імена,
ідентифікатори, контактні дані, зв'язки, аналіз осіб) завантажуються
автоматично і дзеркально відтворюються на кожному іншому робочому місці тієї самої фірми,
щоб кожен адвокат бачив, з ким фірма вже має справу, а фірма
отримувала загальне для фірми уявлення про конфлікти інтересів. Кожен запис має рівно одного
власника — користувача, який першим його вніс; усі інші користувачі мають копію
лише для читання і можуть лише надіслати пропозицію зміни, яку власник приймає або
відхиляє в моніторі даних. Якщо з власником неможливо зв'язатися протягом 48 годин,
право власності переходить до користувача, який вніс пропозицію. Зміст справ не є частиною
цього довідника — документи, хронологія, кореспонденція та призначення
справ і надалі регулюються явними діями з надання доступу та передання,
описаними тут. Обмін залишається в межах фірми (один контролер), ніколи
не залишає локальну мережу і не залучає жодного постачальника ШІ: виявлення дублікатів
і порівняння полів виконуються як звичайна програмна логіка на робочому місці,
що надсилає дані; сервер лише зберігає та пересилає. Фірмам слід згадати цей
внутрішній обмін даними про сторони та аналізами осіб у своєму реєстрі
діяльності з обробки.
- Лише свідомі дії — щодо змісту справ. Зміст справ потрапляє
на сервер виключно через явну дію з надання доступу чи передання,
підтверджену користувачем; тексти правової бібліотеки — лише після того, як користувач прийме
запис у моніторі даних; відсканована вхідна пошта — лише після того, як офісний працівник
перевірив документ і натиснув «надіслати» обраному одержувачу. Описаний вище довідник
сторін є єдиним свідомим винятком: він синхронізується у
фоновому режимі без підтвердження кожного окремого запису. Записи про час, присутність, події та
резервне копіювання є операційними метаданими, що створюються самою багатокористувацькою роботою,
і видимі для адміністратора фірми у веб-адмініструванні.
- Статус контролера. Фірма, що експлуатує сервер, залишається єдиним
контролером даних. Адміністратор контролює схвалення реєстрацій, може припиняти
підписки, видаляти записи правової бібліотеки та деінсталювати пакет —
у такому разі каталог даних сервера залишається під контролем адміністратора на
NAS.
- Повні імена клієнтів у записах обліку часу. Огляд обліку робочого часу
показує робочий час за справою та за клієнтом, а це означає, що імена клієнтів
зберігаються на NAS. Це залишається в межах власної інфраструктури фірми та її
чинного режиму конфіденційності — однак фірмам слід включити NAS до свого
переліку технічних і організаційних заходів (контроль доступу в DSM,
шифрування томів, політика резервного копіювання), точно так само, як і для будь-якого офісного файлового
сервера.
Додаток — Типове застереження для Вашого повідомлення клієнтів про конфіденційність (пропозиція)
Наведений нижче текст є пропозицією формулювання, яку юридична фірма, що використовує IRONSTICK,
може скопіювати до власного повідомлення клієнтів про конфіденційність. Його написано так, щоб він точно відповідав
описаним вище потокам даних, — він не обіцяє більшого захисту, ніж програмне забезпечення
фактично надає. Він свідомо уникає посилань на статті нормативних актів, щоб його
можна було вставити в повідомлення будь-якої структури.
Перш ніж вставити цей текст — контрольний список для адвоката:
- Забезпечте наявність договору про обробку даних з кожним постачальником ШІ, якого Ви
налаштували, називайте в застереженні лише тих постачальників, яких Ви фактично використовуєте, і
перевірте речення про навчання та зберігання на відповідність умовам, які Ви фактично
підписали. Наведене нижче застереження не охоплює Gemini через обліковий запис Google
(споживча послуга без такого договору, розділ 1) — якщо Ви налаштуєте цей
шлях, він потребує власного формулювання і, як правило, явної згоди
клієнта.
- Залишайте речення в квадратних дужках про робочий простір ШІ лише тоді, коли Ви справді використовуєте
міст до настільного ШІ (Claude Desktop/Code, ChatGPT Desktop, Qwen Desktop
або Kimi Desktop); в іншому разі видаліть його.
- Це застереження охоплює потоки всередині застосунку, описані в цьому документі. Воно
не охоплює пакет інструкцій для ШІ (розділ 5) — завантаження цього експорту
до будь-якого сервісу ШІ є окремим рішенням і, як правило, вимагатиме явної згоди
клієнта.
- Якщо Ви вимкнули окремі функції ШІ в конфігураторі, відповідно скоротіть
перелік цілей — описуйте саме те, що Ви використовуєте, не більше.
- Це пропозиція формулювання, а не юридична консультація. Перед використанням перевірте її на відповідність
професійним правилам Вашої адвокатури та місцевій практиці захисту даних.
Українська
Обробка справ із застосуванням ШІ. Наша юридична фірма використовує програмне забезпечення
для ведення справ IRONSTICK, яке містить функції із застосуванням ШІ. Для цих функцій
окремі дані з Вашої справи можуть передаватися зовнішньому постачальнику послуг
ШІ (залежно від доступності: Alibaba Cloud, Moonshot AI, OpenAI або Anthropic, через їхні програмні інтерфейси), який обробляє
їх від нашого імені на підставі договору про обробку даних. Ми використовуємо ці функції для:
класифікації та реєстрації вхідних документів, визначення пріоритетності вхідної електронної пошти,
перевірки наших записів на наявність невідповідностей, підготовки та перевірки юридичних
документів, а також правового аналізу та досліджень.
Захисні заходи. Перш ніж будь-що буде передано, програмне забезпечення
замінює прямі ідентифікатори, що зберігаються в нашій системі, — імена, персональні
ідентифікаційні номери, номери телефонів, адреси електронної пошти, поштові адреси,
номери справ і банківські реквізити — нейтральними заповнювачами (плейсхолдерами) на нашому власному комп'ютері.
Таблиця, що пов'язує заповнювачі зі справжніми даними, ніколи не залишає нашого офісу, а
відповіді постачальника перетворюються назад локально. Передається лише те, чого потребує конкретна
функція, у межах фіксованих обмежень обсягу. Невелика кількість функцій
технічно потребує справжніх даних — наприклад, публічне вебдослідження за ім'ям
особи або функція читання вголос; ми використовуємо їх лише шляхом свідомої
окремої дії. [Необов'язково — видаліть, якщо не використовується: Для підготовки судових документів
ми додатково використовуємо робочий простір ШІ, у якому дані справи обробляються без
заміни заповнювачами; цей канал використовується виключно під нашим безпосереднім
наглядом.]
Постачальник. Згідно з умовами постачальника, що застосовуються до нас, зміст,
переданий через програмний інтерфейс, не використовується для навчання моделей ШІ
і зберігається лише протягом обмеженого строку. Обробка може відбуватися за межами
Європейської економічної зони; у такому разі передання захищене
гарантіями, погодженими в нашому договорі про обробку даних з постачальником. Те, що
постачальник може робити з даними, регулюється цим договором, а не
власним розсудом ШІ.
Ваш вибір. Наш професійний обов'язок збереження конфіденційності залишається
незмінним: понад те, що описано тут, жодні дані не залишають нашої юридичної фірми.
Обробка ґрунтується на дорученні, яке Ви нам надали, та на нашому законному
інтересі в ефективному і точному веденні Вашої справи. Ви можете будь-коли заперечити проти
використання функцій із застосуванням ШІ; якщо це можливо, ми тоді
вестимемо Вашу справу без них. За Вами також зберігаються всі Ваші передбачені законом
права у сфері захисту даних, зокрема право на доступ, виправлення, видалення та подання скарги
до наглядового органу.
Цю декларацію виведено з вихідного коду застосунку
(псевдонімізатор, зовнішній маршрутизатор, журнал аудиту та шлях передання даних кожної функції),
і вона відображає фактичну поведінку описаної версії, що постачається. Обробка
самим постачальником ШІ — зберігання, використання для навчання, субобробники, юрисдикція —
регулюється виключно умовами постачальника — посилання на умови та
політику конфіденційності кожного постачальника наведено у відповідному розділі конфігурації
ШІ (Google Antigravity: antigravity.google/terms; Alibaba Cloud:
alibabacloud.com/help/en/legal; Moonshot AI: platform.kimi.ai/docs/agreement;
OpenAI: openai.com/policies). Щодо сервісів Anthropic ознайомтеся з
їхніми чинними редакціями: Commercial Terms of Service
(anthropic.com/legal/commercial-terms),
Usage Policy
(anthropic.com/legal/aup) та
Privacy Policy
(anthropic.com/legal/privacy).
IRONSTICK← Головна сторінка