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

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

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

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

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

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

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

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

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

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

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

Пет release gates от пилот до production

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

Approval matrix: не всяко действие носи еднакъв риск

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

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

Evals: тествайте целия workflow, не красивия отговор

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

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

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

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

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

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

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

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

Emergency stop и incident runbook

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

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

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

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

Worked example: renewal agent за B2B service компания

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

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

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

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

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

Следващото решение: production readiness review

Съберете business owner, technical owner и reviewer за 90-минутен production readiness review. Минете през action envelope, eval evidence, approval matrix, permissions, logs, alerts, emergency stop и manual fallback. Резултатът трябва да бъде go, limited canary или no-go с конкретни gaps и owners — не общо „изглежда готово“.

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