Workeron — риски автономного агентного исполнения: безопасность, ответственность, регуляторика

Подготовлено для кандидата, оценивающего трудоустройство. Дата исследования: 30 июня 2026. Это узкий угол — то, что основной разбор (01–08) затронул слабо: что значит дать AI-агенту доступ к деньгам, почте и CRM клиента с правом действовать, кто за это отвечает, и что требует закон/enterprise-покупатель. Метки: ФАКТ (с источником) / МАРКЕТИНГ (их заявление, не подтверждено) / ИНТЕРПРЕТАЦИЯ (аналитический вывод). По умолчанию скепсис: нет подтверждения = «не подтверждено». Связь с предыдущими артефактами: 06b §4–5 и 06c §6 уже отметили «Trust Layer» (observability + reversibility) как продуктовую дыру №1. Этот документ разворачивает именно security/governance-измерение и доводит его до чек-листа на собес.

0. TL;DR (самое важное)

• Workeron продаёт исполнение в боевых системах клиента (Gmail, Stripe, HubSpot, Slack, Calendly — 12–16 интеграций), а не совет. Их собственное демо — одобрение wire-перевода на $12,400. Это переводит продукт из класса «ассистент» в класс «агент с доступом к деньгам и внешней коммуникации», где цена ошибки — реальный, часто необратимый, ущерб. [ФАКТ — workeron.ai; артефакт 01 §2, 06b §4]
• Класс риска, не отражённый в маркетинге: агент с tool-access по определению — это privilege-escalation surface. Любая успешная prompt-injection через входящее письмо/сообщение = выполнение действия от имени клиента. В 2026 это уже не теория: задокументированы in-the-wild payload'ы, встроенные в веб-страницы и письма, с полностью заданной платёжной транзакцией (получатель/сумма) под Stripe/PayPal. [ФАКТ — Unit42 / Forcepoint / Help Net Security, 2026]
• Approval ≠ обратимость. One-tap approval защищает от несанкционированного действия, но не от санкционированной ошибки (одобрил, не вчитавшись) и не от ошибки в «некритичном» классе, который агент закрыл «тихо в фоне». Деньги по wire и отправленное письмо не отзываются. [ФАКТ — digitalapplied 2026; 06b §4]
• Ответственность размыта. При разовом DFY-оффере «built once, owned forever — we hand you the keys» Workeron операционно перекладывает риск исполнения на клиента после хэндоффа, но юридически в EU с дек. 2026 AI-система трактуется как «продукт» под strict liability (Product Liability Directive 2024/2853). Прежней AI Liability Directive больше нет — её отозвали в окт. 2025. [ФАКТ — IAPP / Bird&Bird / EU 2024/2853]
• Регуляторный дедлайн почти на носу: EU AI Act ст. 14 (human oversight) для high-risk систем применяется с 2 августа 2026 — это 33 дня от даты разбора. HITL для них перестаёт быть фичей и становится обязанностью (если/когда их кейсы попадают в high-risk-сферы). [ФАКТ — EU AI Act, artificialintelligenceact.eu]
• GDPR / data-residency — слепая зона укр./EU-структуры. Команда и бэкер укр./европ. (артефакт 01 §4). Украина НЕ имеет EU adequacy decision → передача персональных данных клиентов команде/инфраструктуре в Украине требует SCC + TIA, иначе незаконна. Для агента, читающего почту и CRM, это данные третьих лиц (контакты, контрагенты клиента), а не только самого клиента. [ФАКТ — EU Commission adequacy list, 2026]
• «SOC2-grade infra» ≠ SOC 2. Это маркетинговая формулировка, а не аттестат (артефакт 01 §2, 08 §6). Для enterprise-продаж 2026 SOC 2 Type II (свежий, <12 мес) + подписанный DPA + immutable audit-log — это «нижний слой стека», без которого сделка не проходит security-review независимо от качества продукта. [ФАКТ — DeepInspect / Telnyx / Comp AI, 2026]
• Для продукта это значит: Trust Layer из 06b/06c (audit-log, undo/rollback, kill-switch, granular approval) — это не «фича-улучшение», а лицензия на enterprise-рынок и на EU-юрисдикцию. Для C-suite-продаж это первый вопрос покупателя, а не последний.
• Для кандидата это значит: здесь нет владельца security/governance (команда 2–10, артефакт 01 §4). Это открытая зона ценности — можно зайти как человек, который строит Trust Layer и compliance-нарратив, и стать незаменимым. Чек-лист на собес — в §8.

1. Риск-поверхность: агент с доступом к ДЕНЬГАМ, ПОЧТЕ и CRM

1.1 Что именно получает доступ (FACT)

• Каналы ввода: Telegram, WhatsApp, Gmail/Email — то есть агент читает входящий поток (включая письма от внешних, неконтролируемых отправителей). [ФАКТ — workeron.ai; артефакт 01 §2]
• Интеграции с правом ДЕЙСТВИЯ (не read-only): Stripe, Gmail, HubSpot, Slack, Linear, Calendly, Asana, ClickUp, Trello, Intercom, Notion, Google Drive, Airtable, Zapier. Это исполнительные коннекторы (пишут/отправляют/инициируют), а не справочные. [ФАКТ — workeron.ai; артефакт 06c §6]
• Демо критичного действия: «Critical actions land in your inbox for one-tap approval» — пример на лендинге — одобрение wire-перевода на $12,400. [ФАКТ — workeron.ai; артефакт 06b §4]
• Авто-исполнение «некритичного»: «The rest closes quietly in the background.» — то есть часть действий выполняется без подтверждения и без видимости. [ФАКТ — workeron.ai]

1.2 Таксономия рисков (ИНТЕРПРЕТАЦИЯ + отраслевые факты)

1.3 Prompt injection — почему это не edge-case в 2026 (FACT)

• Prompt injection вырос на 340% год-к-году и стал самой быстрорастущей категорией атак (OWASP LLM, 2026). [ФАКТ]
• Indirect injection опаснее direct: работает через каналы данных (письма, документы, веб-страницы), которые оператор не мониторит. Это ровно входящий поток Workeron (Gmail/Telegram/WhatsApp). [ФАКТ — Help Net Security, 2026]
• In-the-wild payload'ы с финансовой транзакцией: исследователи нашли встроенные в публичные страницы платёжные инструкции с полностью заданными реквизитами (получатель, сумма, описание) и пошаговой командой агенту с платёжной интеграцией выполнить перевод без подтверждения пользователя; отдельный кейс — маршрутизация AI-действия на Stripe-ссылку. [ФАКТ — Unit42 / Forcepoint, 2026]
• Масштаб успешности: в публичном red-team против развёрнутых агентов — 1.8 млн попыток инъекций, >60 000 успешных policy-нарушений. Retrieved-document injection — самый эксплуатируемый тип в проде. [ФАКТ — atlan.com, 2026]
• Главный тезис: «успешная prompt injection в агенте — это по определению privilege-escalation event» (агент может слать письма, писать в БД, переводить деньги, менять права). [ФАКТ — atlan.com, 2026]

[ИНТЕРПРЕТАЦИЯ] Workeron строит продукт ровно в эпицентре этого риска: агент с исполнительным доступом к деньгам/почте, принимающий неконтролируемый внешний ввод как рабочий канал. Публично у них нет ни слова о защите от injection (sandboxing инструментов, проверка источника инструкции, разделение «данные vs команды», allow-list получателей платежей). Это белое пятно — и одновременно зона, где кандидат может построить ценность.

2. Ответственность и обратимость: «кто виноват, если агент отправил перевод не туда»

2.1 Обратимость — техническая реальность (ФАКТ/ИНТЕРПРЕТАЦИЯ)

• Approval защищает не от той ошибки. One-tap approval блокирует несанкционированное действие. Но он не спасает от: (а) санкционированной ошибки — клиент одобрил, не вчитавшись; (б) «некритичного» действия, закрытого в фоне; (в) injection-команды, которая выглядит легитимной. [ИНТЕРПРЕТАЦИЯ; 06b §4]
• Индустрия 2026 явно различает два слоя: approval-gate и rollback/undo — это разные механизмы. «Action is rolled back or corrected» — отдельная foundational-способность. У Workeron rollback/undo/audit-log публично не заявлены. [ФАКТ — digitalapplied 2026; 06b §4, 06c §6]
• Compensating actions. Для технически необратимого (wire) единственная защита — до-исполнения (dry-run, allow-list получателей, лимиты сумм, second-factor на деньги) + немедленный алерт после. Реактивного «undo» здесь не существует. [ИНТЕРПРЕТАЦИЯ]

2.2 Юридическая ответственность — кто отвечает (ФАКТ)

• DFY-модель перекладывает операционный риск на клиента. «Built once, owned forever… we hand you the keys — no lock-in» (артефакт 01 §3). После хэндоффа агент работает в инфраструктуре/токенах клиента → бытовая логика «клиент сам нажал approve, клиент и владелец». [ИНТЕРПРЕТАЦИЯ]
• Но юридически в EU это не закрывает вопрос. AI Liability Directive отозвана Еврокомиссией (окт. 2025) — специального облегчённого режима для исков к AI больше нет. [ФАКТ — IAPP / Bird&Bird, 2025]
• Зато действует Product Liability Directive (EU) 2024/2853: ПО и AI-системы прямо трактуются как «продукт» под strict liability; транспозиция в нацправо стран-членов до 9 декабря 2026. Под strict liability пострадавшему не нужно доказывать небрежность — достаточно: дефект + ущерб + причинная связь. Для Workeron как поставщика/интегратора агента это означает потенциальную ответственность за дефект исполнения, а не только «клиент сам виноват». [ФАКТ — EU 2024/2853; LegalClarity / Inside Privacy, 2026]
• Договорная сторона. Кто несёт убыток при неверном wire будет определяться контрактом (LoL, indemnity, disclaimers) + применимым правом + DPA. Для enterprise-клиента отсутствие этих документов — само по себе стоп-фактор (см. §4). [ИНТЕРПРЕТАЦИЯ]

[ИНТЕРПРЕТАЦИЯ — вывод §2] «Мы отдали ключи, дальше не наша зона» — слабая позиция и продуктово (доверие), и юридически (PLD strict liability в EU с дек. 2026). Workeron нужен внятный shared-responsibility model: что гарантирует агент/вендор, что — клиент, где границы. Сейчас этого публично нет.

3. Регуляторика: EU AI Act, GDPR/data-residency

3.1 EU AI Act, ст. 14 — human oversight (ФАКТ)

• Содержание ст. 14: high-risk AI-системы должны проектироваться так, чтобы их эффективно контролировал человек (human-machine interface tools), с возможностью мониторить, интерпретировать и переопределять (override) работу системы и с учётом риска over-reliance на её вывод. Меры — встроенные провайдером и/или внедряемые деплоером, пропорционально риску/автономии. [ФАКТ — artificialintelligenceact.eu, Art. 14]
• Дата применения: обязательства для high-risk систем (Art. 6–15) применяются с 2 августа 2026. [ФАКТ — EU AI Act; артефакт 06b §4 указывал ту же дату]
• Применимость к Workeron — нюанс [ИНТЕРПРЕТАЦИЯ]: «универсальный бизнес-ассистент» сам по себе не обязательно high-risk. Но если кейсы клиента попадают в Annex III-сферы (HR/найм — а бэкер позиционирует Workeron как «HR technology», артефакт 01 §4; кредит/финансы; и т.д.), то high-risk-режим и ст. 14 включаются. То есть зависит от того, что именно агент делает у конкретного клиента — и это аргумент за настраиваемый, доказуемый HITL как стандарт, а не опцию.
• Практический смысл: «closes quietly in the background» (авто-исполнение без видимости) прямо конфликтует с духом ст. 14 (возможность мониторить и override). Для EU-клиентов это потенциальный нонстартер в регулируемых процессах. [ИНТЕРПРЕТАЦИЯ]

3.2 GDPR и data-residency (ФАКТ — это слабо покрытая зона)

• Кто и где обрабатывает данные. Команда и бэкер укр./европ. (артефакт 01 §4). Агент читает Gmail и CRM клиента → обрабатываются персональные данные самого клиента и третьих лиц (его контакты, контрагенты, лиды). Workeron в этой схеме — processor/sub-processor. [ИНТЕРПРЕТАЦИЯ]
• Украина НЕ в списке EU adequacy. Адекватность на 2026 имеют UK, Швейцария, Япония, Канада (commercial), Израиль, Ю.Корея, США (под DPF) и др. Украины там нет. [ФАКТ — EU Commission adequacy decisions, 2026]
• Следствие: передача персданных EU-клиента в Украину (команде/инфраструктуре) требует Standard Contractual Clauses (SCC) + Transfer Impact Assessment, иначе трансфер незаконен. Для EU-клиента это прямой вопрос на due diligence. [ФАКТ — Art. 45/46 GDPR; SCC]
• Sub-processors. Агент почти наверняка использует сторонний LLM-API + хостинг. Каждый — sub-processor, которого нужно раскрыть в DPA и покрыть трансфер-механизмом. Где «живут» данные при инференсе — критичный вопрос для EU/регулируемого клиента. [ИНТЕРПРЕТАЦИЯ]
• Data minimization vs «permanent memory». Их «permanent, portable digital memory… never forgets» (артефакт 01 §2) в лоб конфликтует с GDPR-принципами минимизации и storage limitation и с правом на удаление (Art. 17). «Никогда не забывает» — маркетинговый плюс, но compliance-долг. [ИНТЕРПРЕТАЦИЯ]

3.3 Что требуется enterprise-клиенту (ФАКТ — 2026 procurement)

• Стек compliance — снизу вверх: отсутствие нижнего слоя (SOC 2 / ISO) блокирует сделку независимо от верхних (GDPR/HIPAA). [ФАКТ — DeepInspect, 2026]
• SOC 2 Type II — свежий (<12 мес) — минимум для enterprise-деплоя. Type I или его отсутствие → «обращаться с осторожностью». Workeron имеет лишь формулировку «SOC2-grade», аттестата нет (артефакт 01 §2, 08 §6). [ФАКТ — Comp AI / Telnyx, 2026]
• Подписанный DPA — обязателен до того, как вендор начнёт обрабатывать персданные; должен покрывать категории данных, цели, TOMs, процедуры DSR. [ФАКТ — Voiceflow / MindStudio, 2026]
• Immutable audit-log. Регуляторы хотят неизменяемую запись каждого prompt/retrieval/response/human-handoff; в финансах — хранение минимум 7 лет. [ФАКТ — DeepInspect, 2026]
• RBAC, configurable data residency, sub-processor list, pen-test report. Due diligence — не чек-лист «да, есть», а последовательность перекрёстно проверяемых доказательств (сертификат → sub-processor review → DPA → data-flow diagram → pen-test). [ФАКТ — DeepInspect, 2026]

[ИНТЕРПРЕТАЦИЯ] У Workeron на enterprise-воронке (workeron.agency, PoC→Pilot→Scale, артефакт 01 §1) именно этот стек — узкое горлышко. Пока его нет, крупные чеки упрутся в security-review. Это и есть зона, где governance-человек напрямую разблокирует выручку.

4. Что это значит для ПРОДУКТА (Trust Layer как лицензия на рынок)

Связка с 06b §6 (Рекомендация 1 «Trust Layer») и 06c §6 (Артефакты C/D — approval-матрица, incident-рунбук). Здесь — security/compliance-наполнение того же слоя:

[ИНТЕРПРЕТАЦИЯ — главный сдвиг рамки] В 06b Trust Layer обоснован как активационный барьер (доверие → активация). Здесь добавляется второе обоснование: Trust Layer — это лицензия на enterprise-сегмент и EU-юрисдикцию. Без audit-log/DPA/SOC 2 крупная сделка не проходит security-review; без HITL/data-residency она не проходит EU-комплаенс. То есть это не «фича для удержания», а условие доступа к самому прибыльному сегменту (enterprise через .agency, где, по 01 §3, и живёт настоящая маржа).

5. Что это значит для ПРОДАЖ C-suite / enterprise

• Security — первый вопрос, а не последний. Для COO/CISO/CFO «агент трогает наш Stripe и Gmail» — это сразу security-review, а не «приятная деталь». Демо wire-$12,400 одновременно продаёт ценность и взводит страх — без Trust Layer оно работает против сделки. [ИНТЕРПРЕТАЦИЯ; 06b §4]
• Сегментное противоречие обостряется. Founder хочет «just works» (минимум approval); COO/CISO хочет «я вижу и контролирую каждое действие в моём Stripe». «Closes quietly in the background» — антипаттерн доверия для C-suite (06b §1.2, §4). Продавать одну конфигурацию обоим нельзя.
• Чем закрывают возражение C-suite (procurement-язык): SOC 2 Type II report, signed DPA, sub-processor list, audit-log export, data-residency option, incident-runbook с RTO/severity, доказуемый HITL под EU AI Act ст.14, allow-list/лимиты на деньги. Это язык, на котором покупает enterprise (§3.3). [ФАКТ — TrueFoundry RFP / DeepInspect, 2026]
• Trust как нарратив продаж. Для DFY-агентства с нулевым внешним трекшеном (артефакт 01 §4, 08) демонстрируемый Trust Layer — это заменитель отсутствующих кейсов: «у нас нет логотипов, но вот как мы делаем ваши деньги и данные безопасными». Это конвертируется в доверие быстрее, чем анонимные отзывы. [ИНТЕРПРЕТАЦИЯ]

6. Связь с уже отмеченным в 06b / 06c

• 06b §6 Рекомендация 1 «Trust Layer» (audit-log, undo/rollback, dry-run, scoped permissions, kill-switch) — этот документ даёт ей второе, регуляторное обоснование (EU AI Act ст.14 02.08.2026; PLD strict liability 09.12.2026; SOC 2/DPA как enterprise-gate) и добавляет отсутствующий у них слой — защиту от prompt injection (06b/06c её не выделяли как отдельный класс).
• 06b §4 «approval ≠ reversibility» — здесь усилено фактурой 2026: in-the-wild injection с Stripe/PayPal-транзакциями; 1.8M атак / 60k+ успехов.
• 06c §6 Артефакты C (approval-матрица) и D (incident-рунбук) — здесь привязаны к procurement-требованиям (DPA, audit-log retention, severity/RTO) и к юрисдикции.
• 01 §2 «SOC2-grade ≠ сертификация» и 08 §6 — здесь переведено в продажный/юридический риск: для enterprise это блокирующий слой стека, не косметика.
• Новое, чего не было в 01–08: (1) prompt injection как отдельный класс R2/R3; (2) GDPR data-residency для украинской структуры (нет adequacy → SCC); (3) PLD strict liability и отзыв AI Liability Directive как ответ на «кто отвечает»; (4) «permanent memory» vs GDPR-минимизация.

7. Степень уверенности по ключевым тезисам

8. Чек-лист на собес: что обязательно спросить про безопасность

Блок A — обратимость и контроль исполнения

1. Что происходит, когда агент исполнил не то? Есть ли undo/rollback для обратимых действий и immutable audit-log каждого действия (что/когда/по чьему approval)?
2. Что защищает необратимое (wire, внешнее письмо)? Dry-run preview, allow-list получателей платежей, лимиты сумм, hold-окно, second-factor — есть ли что-то из этого?
3. Кто и как определяет границу critical / non-critical для smart-approval — это LLM или жёсткое правило? Можно ли её настраивать и видеть? Есть ли kill-switch?
4. Что именно делает агент в режиме «closes quietly in the background» — видит ли клиент это в реальном времени?

Блок B — prompt injection и доступ 5. Как агент защищён от prompt injection через входящие письма/сообщения (внешний неконтролируемый ввод)? Разделяете ли «данные» и «инструкции»? Исполнит ли агент команду «отправь деньги», пришедшую в теле письма от внешнего отправителя? 6. Какие интеграции по умолчанию read-only, какие — write/execute? Принцип least-privilege на токены? 7. Сколько инцидентов исполнения было за последний квартал и как они разбирались (incident-runbook, severity, RTO)?

Блок C — регуляторика и enterprise 8. Реальный статус SOC 2 — есть ли Type I/II отчёт, кто аудитор, когда; или это пока «SOC2-grade»? Есть ли roadmap? 9. Есть ли шаблон DPA, список sub-processors, и какой data-residency доступен (особенно: где обрабатываются данные EU-клиентов — учитывая укр./EU команду и отсутствие adequacy у Украины)? 10. Как готовитесь к EU AI Act ст.14 (02.08.2026) и PLD strict liability (09.12.2026)? Кто несёт убыток по контракту, если агент инициировал неверный платёж? 11. Как «permanent memory» совмещается с GDPR (минимизация, право на удаление, retention)?

Блок D — кто этим владеет 12. Кто в команде отвечает за security/compliance/governance сегодня? (Гипотеза по 01 §4: при 2–10 людях — никто специально.)

9. Как кандидат может превратить это в свою зону ценности

• Здесь нет владельца Trust/governance. Команда 2–10, pre-seed, нулевой внешний трекшен (01 §4). Security/compliance — незанятая, но блокирующая выручку территория. Это идеальный «вписать себя в роль» вектор. [ИНТЕРПРЕТАЦИЯ]
• Заход 1 — Trust Layer как продукт. Предложить и владеть слоем: audit-log → undo/rollback → anti-injection guardrails → granular approval → kill-switch. Аргумент для них: это активация (06b) + лицензия на enterprise/EU (этот документ) одновременно. Дешёвый MVP — audit-log прямо в чате (как и отметил 06b §6, Effort снижается стартом с лога).
• Заход 2 — Compliance-нарратив под продажи. Собрать enterprise security packet: SOC 2 roadmap, шаблон DPA, sub-processor list, data-residency опция, shared-responsibility model, incident-runbook. Это напрямую разблокирует C-suite-сделки на .agency-воронке (где маржа, 01 §3) и заменяет отсутствующие кейсы доверием.
• Заход 3 — Regulatory readiness как дедлайн-проект. EU AI Act ст.14 — 02.08.2026, PLD — 09.12.2026. Прийти с готовым планом «как мы соответствуем к этим датам» — это конкретный, датированный, измеримый вклад, который легко «продать» фаундерам.
• Личный риск-хедж кандидату: если на вопросы Блока A/B ответы расплывчаты («у нас smart-approval, всё безопасно») и нет ни audit-log, ни anti-injection, ни плана SOC 2 — это сигнал, что продукт трогает деньги клиентов без сетки безопасности, а компания недооценивает экзистенциальный риск инцидента на ранней стадии (06c §6). Тогда это либо огромная зона влияния (если дадут её строить), либо красный флаг (если отмахиваются). Ответы на Блок A/B решают, что именно.

Источники

Объект ревью (внутренние артефакты):

• 01_company_profile_model.md — бизнес-модель §3, продукт/smart-approval/«SOC2-grade»/permanent memory §2, команда/бэкер/локация §4, .ai↔.agency §1
• 06b_lens_pm.md — §4 «approval ≠ reversibility», §6 Рекомендация 1 «Trust Layer», EU AI Act ст.14
• 06c_lens_po.md — §6 риск исполнения, Артефакты C (approval-матрица) / D (incident-рунбук)
• 08_verification_redflags.md — §6 «SOC2-grade» не подтверждено

Workeron (первоисточник):

• workeron.ai — продукт, smart-approval, wire $12,400, permanent memory, «SOC2-grade», интеграции: https://workeron.ai/ — просмотрено 30.06.2026
• workeron.agency — enterprise-воронка, careers: https://workeron.agency/ — просмотрено 30.06.2026

EU AI Act ст. 14 (human oversight; применение 02.08.2026):

• https://artificialintelligenceact.eu/article/14/ — 30.06.2026
• https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14 — 30.06.2026
• https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai — 30.06.2026

GDPR / data-residency (Украина без adequacy → SCC):

• EU Commission adequacy decisions: https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en — 30.06.2026
• Art. 45 GDPR (transfers on adequacy): https://gdpr-info.eu/art-45-gdpr/ — 30.06.2026
• Ukraine data protection overview: https://www.dataguidance.com/notes/ukraine-data-protection-overview — 30.06.2026

Ответственность (AI Liability Directive отозвана; PLD 2024/2853 strict liability):

• IAPP — Commission withdraws AI Liability Directive: https://iapp.org/news/a/european-commission-withdraws-ai-liability-directive-from-consideration — 30.06.2026
• Bird & Bird — proposed EU AI liability rules withdrawn: https://www.twobirds.com/en/insights/2025/proposed-eu-ai-liability-rules-withdrawn — 30.06.2026
• LegalClarity — AI Liability Directive withdrawn / PLD as replacement: https://legalclarity.org/ai-liability-directive-what-it-was-and-why-it-was-withdrawn/ — 30.06.2026

Prompt injection / агентные финансовые риски 2026:

• Help Net Security — indirect prompt injection in the wild (04.2026): https://www.helpnetsecurity.com/2026/04/24/indirect-prompt-injection-in-the-wild/ — 30.06.2026
• Unit42 (Palo Alto) — web-based indirect prompt injection in the wild: https://unit42.paloaltonetworks.com/ai-agent-prompt-injection/ — 30.06.2026
• Forcepoint X-Labs — 10 IPI payloads (Stripe/PayPal): https://www.forcepoint.com/blog/x-labs/indirect-prompt-injection-payloads — 30.06.2026
• Atlan — how prompt injection compromises AI agents 2026 (340% YoY, 1.8M/60k red-team): https://atlan.com/know/prompt-injection-attacks-ai-agents/ — 30.06.2026

Enterprise procurement / SOC 2 / DPA / audit-log:

• DeepInspect — AI vendor due diligence checklist: https://www.deepinspect.ai/blog/ai-vendor-due-diligence-checklist — 30.06.2026
• Comp AI — SOC 2 for AI companies: https://www.trycomp.ai/hub/soc-2-for-ai-companies — 30.06.2026
• Telnyx — SOC 2 for AI agents vendor checklist: https://telnyx.com/resources/soc-2-voice-ai-agents — 30.06.2026
• Voiceflow — AI agent security & compliance (DPA): https://www.voiceflow.com/blog/ai-agent-builder-security-compliance-enterprise-guide — 30.06.2026
• TrueFoundry — enterprise AI platform RFP questions: https://www.truefoundry.com/blog/enterprise-ai-platform-rfp-questions-vendor-evaluation — 30.06.2026

Уверенность и пробелы

Высокая уверенность (первоисточник или ≥2 независимых источника):

• EU AI Act ст.14 содержание и дата 02.08.2026; AI Liability Directive отозвана; PLD 2024/2853 strict liability и дедлайн 09.12.2026; Украина без EU adequacy → SCC; prompt-injection landscape 2026; enterprise-procurement стек (SOC 2 Type II + DPA + audit-log).
• Что у Workeron rollback/undo/audit-log/anti-injection/SOC 2 публично не заявлены (перепроверено по 01/06b/06c/08).

Средняя уверенность / зависит от деталей:

• Попадает ли Workeron под high-risk-режим AI Act — зависит от конкретного кейса клиента (Annex III). Маркетинговое «HR technology» (бэкер) и финансовые действия повышают вероятность, но это интерпретация, не факт.
• Юридическое распределение ответственности при неверном wire — зависит от контракта/юрисдикции/DPA, которых нет публично.

Пробелы / «не подтверждено»:

• Реальная архитектура защиты от injection, sandboxing инструментов, провенанс команд — нет данных (только отсутствие упоминаний).
• Где физически обрабатываются данные клиентов при инференсе (EU/UA/US), какой LLM-провайдер как sub-processor — нет данных.
• Наличие/содержание контрактных LoL, indemnity, DPA, shared-responsibility model — нет данных.
• Реальный статус SOC 2 (отчёт vs «grade»), наличие incident-runbook, retention-политика логов — нет данных (подтверждает 08 §6).
• Юрлицо и страна регистрации (влияет на применимое право и data-residency) — нет данных (01 §4, пробел).