Фабрика важливіша за продукт: AI, SDLC та новий ризик внутрішньої крадіжки

AI змінює розробку програмного забезпечення швидше, ніж більшість компаній встигає змінювати підходи до її захисту.

Протягом багатьох років основну інтелектуальну власність software-компанії було відносно легко визначити. Це вихідний код, архітектура продукту, структура бази даних, внутрішня документація та, можливо, інструменти розгортання.

Коли людина залишала компанію, основне питання було простим: що вона може забрати із собою?

AI-assisted development змінює цю картину.

Код усе ще має велику цінність. Але він більше не є єдиним цінним активом.

Сучасна команда розробки також може мати набір промптів, AI-правил, специфікацій, архітектурних рішень, MCP-конфігурацій, накопиченого контексту, внутрішніх інструментів і workflow, які разом визначають, як саме створюється програмне забезпечення.

Цей набір може бути не менш важливим за сам код.

А в деяких випадках — його може бути простіше забрати.

Від написання коду до побудови фабрики розробки

Розробник, який використовує AI, вже не просто просить модель написати функцію.

Типовий процес може виглядати зовсім інакше.

Розробник отримує бізнес-вимогу. Вона перетворюється на специфікацію. AI-агент отримує цю специфікацію разом із правилами проєкту, coding conventions, архітектурними обмеженнями, API-визначеннями, прикладами та іншим контекстом.

Агент генерує код.

Інший інструмент запускає тести, перевіряє результат або готує наступну ітерацію.

З часом команда накопичує велику кількість інформації про те, як працює цей процес.

Частина її знаходиться в Git.

Частина — у документації проєкту.

Щось може бути у .cursor/rules, інструкціях для агентів, MCP-конфігурації, скриптах, промптах, шаблонах або внутрішніх сервісах.

А щось існує лише тому, що конкретна людина знає, як усі ці компоненти поєднати.

Разом вони утворюють щось більше, ніж просто середовище розробки.

Вони утворюють фабрику розробки.

Продукт — це те, що фабрика виробляє.

Фабрика — це те, як компанія його виробляє.

Незручна частина

Це створює цікаву проблему безпеки.

Уявімо, що інженер залишає компанію.

Традиційно ми думаємо про відкликання його облікових записів, повернення ноутбука, перевірку доступу до репозиторіїв і переконання, що він більше не має доступу до production-систем.

Усе це як і раніше необхідно.

Але що, якщо разом із цим інженер має копії:

• AI coding rules;
• внутрішніх промптів;
• архітектурних специфікацій;
• шаблонів для повторного використання;
• MCP-конфігурацій;
• скриптів для підготовки AI-контексту;
• внутрішніх workflow розробки;
• накопичених інженерних знань, закодованих у файлах проєкту?

У цих файлах може не бути паролів.

Там може не бути даних клієнтів.

Там може навіть не бути вихідного коду.

Але вони можуть містити значну частину накопичених компанією знань про те, як створювати продукт.

І тут традиційне визначення захисту вихідного коду починає виглядати неповним.

Вихідний код — лише один шар

Уявімо двох розробників, які працюють над одним проєктом.

Розробник A має вихідний код.

Розробник B має вихідний код, специфікації, AI-правила, архітектурний контекст, MCP-інтеграції, development scripts і кілька років накопичених знань про проєкт.

Формально вони мають доступ до одного й того самого продукту.

Але їхня здатність відтворити процес його розробки — різна.

Ця відмінність стає ще важливішою, оскільки AI робить розробку програмного забезпечення більш залежною від контексту.

Хороший AI-агент настільки корисний, наскільки корисна інформація, яку він отримує.

Дайте йому звичайний репозиторій — і він зможе створювати звичайне програмне забезпечення.

Дайте йому архітектуру компанії, conventions, бізнес-правила, специфікації, приклади та інструкції з розробки — і він стане значно ефективнішим інженерним інструментом.

Отже, цей контекст стає активом.

Можливо, ми просто ще не звикли ставитися до нього саме так.

Це не лише про крадіжку коду працівниками

Ризик також ширший за навмисну крадіжку.

Інженеру необов'язково свідомо вирішувати вкрасти інтелектуальну власність компанії.

Він може скопіювати директорію проєкту на особистий комп'ютер, щоб продовжити роботу над нею.

Може експортувати набір AI-правил, щоб використовувати їх в іншому проєкті.

Може залишити собі колекцію промптів, вважаючи їх власним інструментом продуктивності.

Може налаштувати AI-сервіс із використанням інформації компанії, не сприймаючи цю інформацію як конфіденційну.

Технічні механізми часто прості.

Складніше визначити, що саме потрібно захищати.

Нове питання про інтелектуальну власність

Це підводить нас до питання, на яке software-компаніям дедалі частіше доведеться відповідати:

Що саме належить компанії?

Тільки вихідний код?

А специфікація, яка пояснює AI-агенту, як реалізувати функціональність?

Правила, у яких закодовані engineering practices компанії?

Внутрішній MCP-сервер, який надає AI-інструментам доступ до специфічних знань компанії?

Колекція промптів, удосконалена після сотень завдань?

Архітектурні рішення, накопичені в репозиторії?

А що щодо комбінації всього цього?

Окремо деякі з цих речей можуть здаватися незначними.

Разом вони можуть перетворитися на дуже ефективний рецепт відтворення процесу розробки компанії.

Фабрика може бути більш мобільною, ніж продукт

Є ще одна важлива відмінність.

Великий програмний продукт може створюватися роками.

Повністю відтворити його з нуля зазвичай складно.

Але окремі частини фабрики розробки можуть виявитися напрочуд мобільними.

Розробник може скопіювати директорію.

Конфігурацію можна експортувати.

Набір інструкцій можна перенести в інший репозиторій.

Колекцію промптів можна скопіювати.

MCP-сервер можна відтворити.

Середовище розробки може піти разом із людиною.

Це не означає, що хтось може просто піти з компанії, забравши весь її бізнес.

Але це означає, що вартість відтворення частини інженерної спроможності компанії може бути значно нижчою, ніж раніше.

Це вже новий сценарій внутрішнього ризику.

Що компанії можуть із цим робити?

Першим кроком, імовірно, має бути не ще одне DLP-правило.

Потрібно визнати, що сам актив, який ми захищаємо, змінився.

Якщо AI є частиною процесу розробки, компаніям варто дивитися за межі репозиторіїв із вихідним кодом і визначити інші компоненти, завдяки яким працює їхня система розробки.

Це можуть бути:

• AI-інструкції та правила;
• специфікації проєктів;
• внутрішні промпти й шаблони;
• конфігурації агентів;
• MCP-сервери та конектори;
• development scripts;
• архітектурна документація;
• внутрішні reusable tools;
• proprietary development workflows.

Не всі ці активи потребують однакового рівня захисту.

Деякі можуть бути публічними.

Деякі можуть належати клієнту.

Деякі можуть бути звичайною інженерною документацією.

Інші можуть бути справжньою інтелектуальною власністю компанії.

Важливо визначати цю різницю свідомо.

Захист фабрики

Відповідь не в тому, щоб закрити розробникам доступ до AI-інструментів.

Більш практичний підхід — розглядати AI-assisted development environment як ще один актив компанії та застосовувати до нього ті самі базові принципи, які ми вже використовуємо для вихідного коду, credentials та інфраструктури.

Є кілька практичних підходів, які варто розглянути.

1. Відокремити розробника від AI-активів компанії

Не все, що потрібно AI-агенту, має постійно зберігатися на комп'ютері розробника.

Корпоративні правила, proprietary prompts, внутрішні архітектурні знання та інший чутливий контекст можна зберігати в контрольованих репозиторіях або внутрішніх сервісах і надавати агенту лише тоді, коли вони потрібні.

Це створює розділення між середовищем розробника та базою знань компанії.

Якщо розробник залишає компанію, відкликання доступу до цих знань може зробити його development environment значно менш корисним поза компанією.

Принцип схожий на той, який ми вже використовуємо для credentials: встановлений інструмент — це не те саме, що постійний доступ до всього, що стоїть за ним.

2. Використовувати just-in-time injection контексту

Деяку інформацію взагалі не потрібно постійно копіювати в AI-інструмент.

Замість цього development platform може надавати необхідний контекст у момент виконання конкретного завдання.

Наприклад, агент, який працює над billing-функціональністю, може отримати відповідні архітектурні правила, API specification, business rules і coding conventions саме для цього завдання.

Інший розробник, який працює над іншим компонентом, може отримати інший набір інформації.

Це зменшує кількість чутливих корпоративних знань, що зберігаються в локальній AI-конфігурації, і спрощує контроль доступу.

Також з'являється корисна точка аудиту: хто, до яких внутрішніх знань, для якого проєкту та коли отримував доступ?

3. Зберігати proprietary knowledge за внутрішніми сервісами

Частину найбільш цінного контексту можна надавати через внутрішні сервіси замість того, щоб копіювати його в кожен проєкт.

Внутрішній MCP-сервер — один із можливих прикладів.

Замість того щоб зберігати всю базу знань у локальному середовищі інженера, агент може звертатися до внутрішнього сервісу за затвердженими архітектурними рішеннями, стандартами компанії, domain rules або іншою proprietary information.

Доступ до такого сервісу можна побудувати на тій самій моделі identity та authorization, яка використовується для інших внутрішніх систем.

Це не робить інформацію неможливою для крадіжки. Користувач, який має право її бачити, потенційно може її скопіювати.

Але проблема змінюється з «усе вже знаходиться на ноутбуці» на «доступ до корпоративних знань контролюється».

Це значно більш керована межа безпеки.

4. Включити AI development environment до offboarding

Традиційний offboarding часто зосереджений на облікових записах і доступі до source-code repositories.

AI-assisted development вимагає ширшого checklist.

Коли інженер залишає компанію, варто перевіряти не лише Git-репозиторії та cloud accounts, а й:

• AI coding-tool accounts та membership в організації;
• доступ до внутрішніх MCP-серверів і knowledge services;
• приватні AI-правила та prompt repositories;
• локальні копії proprietary specifications і контексту;
• API keys, які використовуються development agents;
• agent configurations та automation credentials;
• доступ до AI-моделей або vector stores, розгорнутих компанією.

Мета не в тому, щоб довести, що абсолютно нічого неможливо скопіювати.

Це нереалістично.

Мета — зробити development knowledge компанії централізовано контрольованими там, де це практично можливо, аудитованими там, де це можливо, і такими, доступ до яких можна відкликати, коли він більше не потрібен.

Ці заходи не вирішують проблему повністю.

Але вони вказують на іншу модель безпеки: замість того щоб захищати лише продукт та його вихідний код, компаніям, можливо, доведеться захищати ще й систему, яка виробляє цей продукт.

Питання, яке варто почати ставити

Software-індустрія десятиліттями вчилася захищати застосунки, репозиторії, credentials, інфраструктуру та дані клієнтів.

AI-assisted development додає ще один шар.

Цінним активом може бути вже не лише те, що створює компанія.

Цінною може бути також система, яка дозволяє компанії це створювати.

І ця система може містити знання, які складно побачити, складно класифікувати і напрочуд легко скопіювати.

Тож, можливо, питання тепер не лише в тому:

«Як нам захистити вихідний код?»

А в тому:

«Як нам захистити фабрику, яка його виробляє?»