AI agent в production: evals, approvals, logs и emergency stop

Пилотът работи, но реална среда променя риска

В demo среда агентът прочита пет документа, предлага следваща стъпка и изглежда убедително. В реална среда същият агент получава достъп до CRM, inbox, project system или billing инструмент, работи върху неочаквани данни и може да повтори грешка стотици пъти. Проблемът вече не е само дали отговорът звучи правилно. Въпросът е дали системата може да предприеме позволено действие, върху правилния запис, в правилния момент и с достатъчно доказателства.

Това ръководство започва след избора на случай на употреба и успешния ограничен пилот. Ако още решавате какво да автоматизирате, първо използвайте рамката за избор на процес. Реална среда gate-ът идва, когато има реални потребители, свързани системи и бизнес отговорник, готов да носи отговорност за резултата.

Агент не трябва да получава общо разрешение „помагай на екипа“. Нужен е action envelope: конкретни входове, позволени инструменти, лимити, точки за одобрение, критерии за спиране и резервен вариант към човек. Колкото по-трудно е да отмените действието, толкова по-малко автономност трябва да има при първия пускане.

Готовност за реална среда не е увереност в модела. Тя е проверима система от ограничения, измерване, отговорност и възстановяване.

Опишете action envelope преди да пишете още prompts

Преди технически пускане опишете работата като договор между бизнеса и системата. Започнете с тригера, целта и definition of done. После разделете инструментите на read, чернова и write. Агент, който трябва да обобщава клиентска история, обикновено има нужда да чете ограничени CRM полета, но не и да променя стойност на сделка, да изтрива бележка или да изпраща имейл.

Запишете и забранените действия. Не оставяйте тези граници само в system prompt: enforce-вайте ги в инструмент слоя, permissions и downstream системата. OWASP препоръчва минимална функционалност и минимални права за инструментите, както и human одобрение за действия с висок ефект. Това означава отделен read инструмент вместо общ CRM administrator token и отделна функция за чернова вместо универсална команда за изпращане.

Action envelope-ът трябва да има отговорник от бизнеса, technical отговорник и проверяващ. Отговорник от бизнеса определя приемливия резултат и цена на грешката. Technical отговорник поддържа интеграциите, логовете и release-а. Проверяващият взема конкретните решения, които не са делегирани на системата. Едно име може да изпълнява две роли в малък екип, но нито една роля не трябва да остава подразбираща се.

• Входове: кои канали, типове записи и data classes са позволени?
• Инструменти: кои са read-only, кои създават чернова и кои променят система?
• Лимити: брой стъпки, retries, записи, стойност и време за един run.
• Изключения: кога агентът спира и създава задача за човек?
• Доказателства: кои версии, инструмент calls, одобрения и резултати се пазят?

Пет release gates от пилот до реална среда

Gate не е документ, подписан веднъж. Модел, prompt, инструмент schema, permissions, knowledge източник и downstream API могат да променят поведението. Версионирайте release package-а и повторете релевантните тестове при всяка съществена промяна.

Матрица на одобренията: не всяко действие носи еднакъв риск

Одобрение не трябва да бъде универсална пауза след всяка стъпка. Това прави агента бавен и учи хората да натискат „Approve“ без проверка. Класифицирайте действията според обратимост, финансов или правен ефект, достъп до данни и видимост за клиента. Следващата таблица е примерен старт, който трябва да адаптирате към вашите системи и risk tolerance.

Одобрение интерфейсът трябва да показва какво точно ще се промени, на какво основание и как действието може да бъде отменено.

Тестове: тествайте целия работен процес, не красивия отговор

Контекстуалните тестове превръщат „работи добре“ в измерима спецификация. Съберете реални, деидентифицирани случаи от процеса и добавете ръчно създадени edge cases: липсващо поле, конфликтни инструкции, prompt injection в документ, timeout от инструмент, дублиран event и заявка извън scope. За всеки случай запишете очакван outcome, позволени инструмент calls и действия, които никога не трябва да се случват.

Измервайте поне задача completion, точност на избрания запис, policy violations, неправомерни инструмент calls, human override rate, latency и cost per accepted outcome. Един общ процент може да скрие критична грешка. Определете hard fail за неразрешено изпращане, изтриване, плащане или достъп до забранени данни, дори средната оценка да е висока.

Тест set-ът трябва да остане versioned asset. Добавяйте потвърдените реална среда incidents и проверяващ corrections като нови тестове, без да превръщате всяка единична аномалия в правило. OpenAI описва тестове като цикъл specify, measure, improve; за бизнеса важната част е да има domain expert, който решава как изглежда приемливият резултат.

• Pre-release: пълен тест set за всяка промяна в model, prompt, инструменти или knowledge layer.
• Canary: ограничен процент реални runs и по-строги одобрение правила.
• Реална среда: continuous sampling, drift signals и сравнение по версия.
• Post-incident: нов regression case, root cause и потвърдена corrective action.

Журнали и traces: достатъчно за решение, не колекция от тайни

Tracing може да покаже model turns, инструмент calls, handoffs, guardrails и custom events. Това е полезно за debugging, но не е автоматично бизнес следа за одит. Добавете собствен correlation ID от тригера до downstream резултата и пазете коя конфигурация е работила: model, prompt, инструмент schema, policy и knowledge version.

Логвайте входен тип и record ID, но не копирайте без нужда пълен документ, prompt или лични данни. Определете срок на съхранение, access и redaction. Проверете и ограниченията на доставчика: например OpenAI отбелязва, че SDK tracing не е наличен при Zero Data Срок на съхранение. Ако не можете да пазите съдържанието, съхранявайте минимални metadata, hashes, decision codes и връзка към контролирания източник record.

Таблото трябва да отговаря на оперативни въпроси: колко runs са успешни, колко чакат одобрение, къде има retries, кои инструмент calls се провалят, колко струва приетият резултат и коя версия създава отклонението. Alert без отговорник и response SLA е само известие.

Emergency stop и incident runbook

Kill switch е оперативен механизъм, не бутон за презентация. Най-бързият stop може да бъде feature flag, изключване на scheduler-а, revoke на service credential или забрана на write инструменти. Изберете механизъм, който спира новите действия, без да унищожава trace-овете и pending одобрения. Тествайте го с човек, който не е построил системата.

NIST препоръчва да има отговорности и критерии за disengage или deactivate, post-deployment monitoring, incident response, recovery и резервен вариант, включително ръчна обработка. Преведено за малък екип: определете кой може да спре агента, кои сигнали са достатъчни, какво става с незавършените runs и как се проверяват вече предприетите действия.

Runbook-ът започва със stop, после contain, assess, recover и learn. Спрете новите runs; ограничете credentials и queues; определете засегнатите записи и хора; отменете или коригирайте обратимите действия; уведомете отговорници; запазете evidence; и едва след regression test вземете ново go/no-go решение.

• Stop тригер: unauthorized action, повторяем critical error, data exposure или рязък volume/cost spike.
• Stop отговорник и backup: конкретни хора с достъп, не общ team alias.
• Manual резервен вариант: кой поема работата и откъде вижда pending items.
• Recovery criteria: конкретни тестове и одобряващ преди повторно включване.
• After-action преглед: root cause, засегнат scope, нов тест и промяна в контрола.

Примерен разбор: renewal агент за B2B service компания

Представете си измислена 40-членна B2B service компания с 120 активни договора. Операции екипът губи време да проверява CRM, договори и project status преди renewal. Агентът трябва да открива договори с renewal до 45 дни, да събира позволени факти, да предлага next action и да създава задача за account отговорник. Той няма право да изпраща имейл, да променя цена или да редактира договор.

Екипът изгражда тест set от 100 деидентифицирани случая: стандартни renewals, липсващи документи, различни валути, спорен scope, приключил клиент и malicious instruction в прикачен файл. Примерните go/no-go прагове са 95% правилно избран next action, 99% съответствие между цитирания факт и източник record и нула неразрешени write attempts. Това са илюстративни прагове, не универсален стандарт; компанията ги задава според цената на грешката.

Първата реална среда седмица работи като canary за 10% от eligible contracts. Създаването на задача е автоматично и идемпотентно; всяко предложение за клиентско съобщение остава чернова. Таблото показва completed runs, missing evidence, duplicate prevention, одобрения и cost per accepted case. Ако има опит за write извън задача creation, агентът се спира автоматично, technical отговорник получава alert, а операции продължава от manual queue.

След две седмици екипът не пита дали агентът е „умен“. Той преглежда доказателства: покрити ли са eligible договорите, точни ли са източниците, намалява ли времето и остава ли control boundary непокътнат. Само тогава може да разшири обема или да предложи ново действие за отделно одобрение решение.

Примерът и числата са илюстративни. Използвайте собствения си обем, risk tolerance, acceptance criteria и cost изходно ниво.

Следващото решение: готовност за реална среда преглед

Съберете отговорник от бизнеса, technical отговорник и проверяващ за 90-минутен готовност за реална среда преглед. Минете през action envelope, тест evidence, матрица на одобренията, permissions, журнали, alerts, аварийно спиране и manual резервен вариант. Резултатът трябва да бъде go, limited canary или no-go с конкретни gaps и отговорници — не общо „изглежда готово“.

1→10 може да включи този преглед в Systems Audit или AI implementation scope: картографираме работния процес и системите, дефинираме release gates, свързваме одобрения и observability и подготвяме измерим backlog за безопасен пускане. Целта е агентът да носи стойност, без да превръща модела в скрит отговорник за процеса.