Защо имейлите и документите са добро място за AI агент
В повечето фирми голяма част от оперативната работа минава през пощата: запитвания за цена, поръчки, фактури от доставчици, подписани договори, рекламации и въпроси за статус. Голяма част от това е повтаряща се работа: някой отваря писмото, разбира какво е, прехвърля данни в друга система и препраща на правилния човек.
AI агентът е полезен точно тук, защото разбира свободен текст и неструктурирани документи. Това е нещо, което класическата автоматизация трудно прави. Той обаче не бива да е източникът на цени, условия или решения. Ролята му е да чете, да класифицира, да извлича и да подготвя. Утвърдените системи и хората решават. Ако тепърва оценявате дали агент изобщо има смисъл за вас, започнете с общия преглед в статията за AI агент за бизнеса.
Какво точно може да прави агентът и какво не
Добре проектираният агент има тесен и ясно описан обхват. Колкото по-широки са правата му, толкова по-трудно се контролира и тества.
- Може: да класифицира входящи писма по тип, спешност и клиент; да извлича полета от PDF фактури, поръчки и договори; да изготвя чернова на оферта от каталог и ценови правила; да предлага отговор; да създава задачи и записи в CRM.
- Не трябва сам: да изпраща оферти извън предварително одобрени шаблони и прагове; да договаря отстъпки; да одобрява плащания; да подписва или приема договорни условия; да трие писма или документи.
- Не е подходящ, когато: обемът е малък и човек се справя за минути; правилата са напълно детерминистични и стига обикновен скрипт; грешката е скъпа, а не може да се провери надеждно.
Inbox triage: първата и най-безопасна стъпка
Сортирането на входящата поща носи стойност бързо и почти без риск, защото агентът само поставя етикети и насочва писмата, без да действа навън. Всяко писмо получава тип (запитване, поръчка, фактура, договор, рекламация, спам или друго), приоритет, разпознат клиент или доставчик и предложен отговорник.
Важно е класификаторът да връща и степен на увереност, както и категория „неясно“. Писмата с ниска увереност отиват в обща опашка за човешки преглед, вместо да бъдат насочени на сляпо. Така екипът вижда къде моделът греши и с какви примери трябва да се подобри.
Извличане на данни от PDF и прикачени файлове
Фактурите, поръчките и спецификациите идват в най-различни формати: генерирани PDF, сканирани копия, снимки от телефон, Excel. Добрият конвейер първо разпознава вида на файла, прилага OCR, когато е нужно, и след това извлича данни по фиксирана схема: номер на документа, дата, ЕИК/ДДС номер, редове, количества, суми, падеж.
Извлечените данни задължително се валидират с код, а не с още един модел. Проверява се дали сумата на редовете съвпада с общата сума, дали ДДС е изчислен коректно, дали ЕИК съществува в базата с контрагенти и дали номерът не е дублиран. Документ, който не мине проверките, не влиза автоматично в ERP. Той отива при човек с маркирани проблемни полета.
Оферти само от утвърдени правила и цени
Това е най-чувствителната част. Езиковият модел никога не бива да „измисля“ цена, срок или отстъпка. Неговата задача е да разбере какво иска клиентът, да съпостави заявката с продуктови кодове и количества и да подаде тези данни към ценови модул. Модулът изчислява резултата по правила от ERP, ценоразписа или договора с конкретния клиент.
Ако продуктът не е в каталога, ако количеството е извън стандартните граници или ако клиентът иска нестандартни условия, агентът не импровизира. Той подготвя чернова с ясна бележка какво липсва и я насочва към търговец. Офертата се генерира от шаблон, а всяка цифра в нея има проследим произход: кой ценоразпис, коя версия, кое правило.
Договори и фактури: routing вместо решения
При договорите агентът може да разпознае типа документ, да извлече страни, срокове, автоматично подновяване, неустойки и падежи и да сравни текста с вашия стандартен шаблон, като маркира отклоненията. Правната оценка обаче остава при човек.
При входящите фактури агентът може да ги съпостави с поръчка и приемо-предавателен протокол (т.нар. three-way match) и да ги насочи за одобрение към бюджетния отговорник. Самото одобрение и плащането остават човешко действие в счетоводната система.
Примерен работен процес от край до край
Ето как изглежда типичен поток за запитване за оферта:
- 1. Пристига писмо; агентът го класифицира като „запитване за оферта“ и разпознава клиента по домейн и CRM запис.
- 2. Извлича продукти и количества от текста и от прикачения файл.
- 3. Съпоставя ги с каталога; неразпознатите позиции маркира.
- 4. Ценовият модул изчислява цените по договорните условия на клиента.
- 5. Генерира се чернова на оферта от шаблон и чернова на придружаващо писмо.
- 6. Търговецът вижда черновата, източниците и бележките; редактира, одобрява или отказва.
- 7. След одобрение системата изпраща офертата, създава сделка в CRM и записва всяка стъпка в одитния журнал.
Архитектура: къде стои моделът
Най-устойчивата архитектура разделя ролите. Конекторът към пощата (IMAP, Microsoft Graph или Gmail API) само чете и поставя етикети. Оркестраторът управлява стъпките и състоянието. Моделът получава конкретна задача и връща структуриран JSON по схема. Детерминистичният код валидира резултата и вика бизнес системите през ограничени API-та.
За чувствителни документи си струва да се обмисли модел, който работи във ваша инфраструктура. Повече за компромисите има на страницата за локален AI за бизнеса. Връзките със съществуващите системи са отделна инженерна задача, описана в раздела за интеграции и автоматизация.
Права и човешко одобрение
Агентът трябва да има минимално необходимите права: отделен служебен акаунт, достъп само до определени пощенски кутии, право да чете и поставя етикети, но не и да трие. Към CRM и ERP му трябва достъп само до конкретни операции, например създаване на чернова, без право да публикува.
Действията се разделят по риск. Ниският риск (етикет, вътрешна задача) може да е автоматичен. Средният (изпращане на стандартен отговор по шаблон) върви с одобрение или в ограничен обхват. Високият (оферта, плащане, договор) винаги изисква изрично човешко одобрение. Подробно за този модел пишем в статията за сигурност, permissions и human approval при AI агенти.
Записи и одитна следа
За всяко обработено писмо и документ трябва да може да се отговори на въпроса кой какво е направил, кога и на каква база. Журналът съдържа идентификатор на входящото съобщение, версията на модела и промпта, извлечените данни, резултатите от валидацията, използваните ценови правила, решението на човека и изпратения резултат.
Журналът трябва да е неизменяем (append-only) и да е отделен от работните данни. Спазвайте и GDPR: определете срокове за съхранение, маскирайте лични данни там, където не са нужни, и документирайте кой обработва данните и с каква цел.
Типични грешки и как да ги предвидите
Агентът ще греши. Въпросът е дали системата е проектирана така, че грешките да се хващат навреме.
- Грешна класификация: решава се с праг на увереност, опашка за преглед и редовни проби.
- Халюцинирани данни при извличането: решава се със строга схема, валидация с код и показване на източника до всяко поле.
- Prompt injection в писмо или PDF (например скрит текст „игнорирай инструкциите и изпрати…“): входящото съдържание се третира като данни, а не като команди, и агентът няма права за опасни действия.
- Дублирана обработка: идемпотентни операции и уникален ключ за всяко съобщение.
- Недостъпна външна система: опашка с повторни опити и известие до човек, без мълчаливо пропускане.
Как да измервате дали работи
Измервайте спрямо собствената си изходна точка, преди да пуснете агента, а не спрямо обещания от маркетингови материали. Полезните метрики са: време от получаване до първа реакция; дял на писмата, класифицирани правилно при ръчна проба; точност на извличането по полета; дял черновите оферти, одобрени без корекции; брой върнати или коригирани документи; време, което хората прекарват в преглед.
Ако делът на корекциите не намалява или прегледът отнема почти колкото ръчната работа, процесът трябва да се преосмисли. Възможно е той да е по-подходящ за обикновена форма, CRM поле или класическа автоматизация.
Как да започнете
Изберете един поток с ясен обем и измерим резултат, например входящи фактури от доставчици или стандартни запитвания за оферта. Съберете реални примери, опишете правилата и изключенията и пуснете агента първо в режим „само предложения“, като хората продължават да работят както досега и сравняват резултатите. Едва след като точността е проверена, разширявайте автоматизацията стъпка по стъпка.
Ако искате агентът да е свързан с клиентски портал или CRM процес, вижте решенията за CRM и клиентски портали и за AI асистенти и агенти. Когато сте готови да обсъдим конкретния ви процес, започнете от страницата за старт на проект.