Harness і Amazon Bedrock: запит від команди юристів

Спочатку потрібно з'ясувати, який саме Harness потрібен

Я б почав з уточнення терміна Harness, адже без цього архітектуру легко спрямувати не туди. В початковому листуванні запит сформульовано стисло: налаштувати Harness разом з Amazon Bedrock, а потім навчити юридичну команду. Виконавець передає проєкт за white-label моделлю через брак вільних фахівців.

Якщо йдеться про Amazon Bedrock AgentCore Harness, документація Amazon Web Services описує його як керовану оболонку для запуску агентних процесів. У ній можна визначити модель, системний промпт, інструменти, пам'ять і обмеження виконання, а окремі параметри змінювати для кожного виклику. Розгортання та запуск підтримуються через AgentCore CLI і AWS SDK, зокрема boto3.

Для юридичного середовища ключовий шар лежить не в промптах, а в правах доступу. Згідно з документацією безпеки Harness, для виклику InvokeHarness потрібні дозволи bedrock-agentcore:InvokeHarness і bedrock-agentcore:InvokeAgentRuntime для відповідного ARN. Я б окремо перевіряв ролі доступу до сховищ документів, векторних баз і зовнішніх систем, не об'єднуючи їх в одну універсальну роль.

На момент цього розбору, 5 жовтня 2026 року, рекомендації Amazon Web Services також передбачають принцип найменших привілеїв, MFA, журналювання через CloudTrail і TLS 1.2 або новішої версії. Для закритого мережевого маршруту доступний AWS PrivateLink, а ключами шифрування можна керувати через AWS KMS. Особливо неприємна деталь: чутливі дані не можна поміщати в теги та довільні поля іменування, куди легко випадково записати клієнта або номер справи.

Юристам потрібен не чат, а перевірюваний процес

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

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

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

Раніше ми розглядали, чому впровадження LLM потребує суворого контролю доступу, журналювання та поділу робочих середовищ. Ці принципи особливо важливі під час налаштування Harness і Amazon Bedrock для юридичних даних.