Щоранку ви відкриваєте той самий pull-request review. Частина діфів — від колеги з Портленда, частина — від AI-агента, якого ваша компанія увімкнула минулого кварталу. Код виглядає однаково. Зелений бейдж "Verified" виглядає однаково. Ви тиснете Approve, ковтаєте каву й ідете далі.

Але є нюанс: коли підписаний коміт привозить security hole о другій ночі і спрацьовує пейджер — хтось має відповідати. Підпис на тому коміті вказує на бота. Бота без юридичного імені, без поштової адреси і з абсолютним нулем бажання приєднатися до вашого post-mortem.

Підпис з'явився

Третього квітня 2026 року GitHub запустив криптографічний підпис комітів для свого Copilot cloud agent. Ми розбирали продуктові деталі вчора разом із org runner controls та іншими оновленнями. А ось про що ніхто не поговорив: про юридичну порожнечу під цим усім.

Криптографічний підпис — математичний доказ, що конкретна сутність написала конкретний код — уже був стандартом для живих розробників у серйозних компаніях. Тепер бот отримує ту саму церемонію. GitHub ще раніше додав трейсинг логів сесій 20 березня, прив'язуючи кожен агентський коміт до повної історії розмови. Поєднайте це з контролями раннерів на рівні організації, що вийшли в один день із підписом, і меседж для корпоративних клієнтів зрозумілий: нехай бот комітить. Ми зробили це безпечним.

Запит був відкритий ще з червня 2025, і один ентерпрайз-користувач благав: "У нашій організації >1 500 контриб'юторів, ми не можемо масштабно кожному це пояснювати." GitHub їх почув. Чи відповіли вони на правильне запитання — це вже зовсім інша історія.

Як це працює насправді

Кожен коміт cloud agent тепер несе криптографічний підпис — той самий формат GPG або SSH, що й у людей. На GitHub це виглядає як знайомий зелений бейдж "Verified". Метадані коміту вказують Copilot як автора, а людину, яка поставила задачу, — як співавтора. URL логу сесії сидить у trailer-рядку внизу commit message.

Це розв'язало реальну, набридливу проблему: репозиторії з branch protection rules раніше взагалі не могли використовувати cloud agent, бо непідписані коміти відлітали на воротах. Тепер бот проходить фейсконтроль. Audit trail чистий, захищений від підробки й технічно ідентичний тому, що створює живий розробник.

Технічно ідентичний. Юридично? Ось тут починається комедія.

Діра в підзвітності

Ось де стає незатишно. Криптографічний підпис відповідає на питання що написало код. Він не відповідає — і не може відповісти:

  • Кому належить копірайт? US Copyright Office досі стоїть на позиції, що AI-генерований контент не має людського авторства. Якщо жодна людина "суттєво не брала участь" — копірайту може не бути взагалі. Ваша компанія щойно задеплоїла код, який, можливо, не належить нікому.
  • Хто несе відповідальність за security flaw? Власна документація GitHub про ризики перелічує чотири категорії ризиків і вимагає human review для всіх PR — але містить нуль слів про те, хто реально несе відповідальність. Вони побудували audit trail і забули поставити когось в його кінці.
  • Хто відповідає на incident review? Співавтор — людина, яка написала "fix the login bug" у текстове поле? Рев'юер, що натиснув Approve о 16:47 у п'ятницю? CISO, який увімкнув агента на всю організацію, бо на слайді вендора було написано "productivity"?

Audit trail бездоганний. Accountability trail порожній.

Проблема фрагментації

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

  • GitHub Copilot cloud agent: Криптографічний підпис, Copilot як автор, людина як співавтор, URL логу сесії
  • Claude Code: Додає трейлер Co-authored-by, без криптографічного підпису
  • OpenAI Codex: Аналогічний трейлер співавтора через git hook, без підпису
  • Cursor, Devin: Жодної стандартизованої атрибуції — ваш git log просто каже, що це написали ви

Якщо ваша компанія використовує більше одного з цих інструментів — а більшість використовує — ваша git history тепер містить три-чотири несумісні схеми авторства. Дослідницька стаття, яку представлять на MSR '26 (13–14 квітня 2026), проаналізувала 33 580 pull-реквестів і виявила, що AI-агентів можна ідентифікувати з точністю 97,2% лише за патернами комітів. Машини залишають відбитки, навіть коли себе не ідентифікують. Але жодного крос-платформенного стандарту, як цей відбиток повинен виглядати, не існує.

Ваш compliance-відділ щойно успадкував бардак, про який їм ніхто не доповідав. Прийміть вітання.

Що це означає для вас

Якщо ваша організація використовує GitHub cloud agent — а з цими ентерпрайз-контролями адопшен ось-ось стрибне — у вашому git log вже є підписані AI-коміти впереміш із підписаними людськими комітами. Ваші юридичні плейбуки, compliance-чеклісти, incident-response процедури майже напевно розглядають кожен підписаний коміт як людську відповідальність. Бо до дев'яти днів тому так і було.

Вимоги прозорості за Article 50 EU AI Act набирають чинності 2 серпня 2026 року. Це чотири місяці, щоб з'ясувати, чи бейдж "Verified" від бота задовольняє ті самі регуляторні очікування, що й бейдж "Verified" від вашого senior-інженера. Чотири місяці здаються купою часу — поки не згадаєш, скільки тривав останній перегляд ваших політик.

Нова реальність

Тридцять років git log був записом авторства — хто написав що, коли і (якщо прищуритись до commit message) навіщо. GitHub щойно перетворив його на дещо інше: запис, який включає не-авторство, де підписант є верифікованим, але не підзвітним, ідентифікованим, але не відповідальним, і трейситься до розмови, яку жодна правова система не знає як інтерпретувати.

Підпис справжній. Відповідальність за ним — ні. А ваші політики не наздогнали — але 2 серпня не цікавить ваш бек-лог.