Агентът вече е пред касата: какво се случва във вашите системи, когато купува машина

Клиент казва на своя ИИ асистент: «Купи ми черните маратонки, размер 27, и да пристигнат в петък». Асистентът отваря онлайн магазина, избира продукта, попълва адреса за доставка и стига до екрана за плащане. Там спира и пита клиента: «Потвърждавам ли?». Клиентът докосва един бутон. Поръчката влиза във вашата система.

Погледнете тази сцена от страната на вашата компания. До бутона онзи, който е посетил магазина ви, не е бил човек. А след бутона вашата дейност трябва да събере плащането, да фактурира, да изпрати, да съгласува и, ако нещо се обърка, да отговаря за покупка, която никоя от вашите системи не е видяла да се ражда по обичайния начин.

Това вече не е лабораторна хипотеза. Тази статия е за онзи, който отговаря за продажбите, финансите, операциите или технологиите в банка, финтех, застрахователна компания, търговска верига или регулирана компания. Тя ви предлага да оставите настрана модния въпрос — ще купуват ли агентите сами? — и да си зададете по-полезен: какво се случва в моите системи, когато до касата стигне машина? Според ролята въпросът се променя: за търговеца това са каталогът, поръчката, CFDI и връщанията; за издателя — лимитите, съгласието и оттеглянето; за придобиващата банка или платежния процесор — приемането, сигналите и спорът; за регулираната компания — упълномощаването, проследимостта и данните.

Какво се случи и какво не

В края на септември 2026 г. Shopify документира (на 28 септември), че ИИ агентите, които работят в браузър, вече могат да ползват четири инструмента на екрана му за плащане: да отидат до магазина, да прочетат състоянието на поръчката, да актуализират данните за изпращане и доставка и да изпратят поръчката. Тези инструменти работят вътре в същия уеб checkout, който ползва човек, и със същото състояние, което вижда интерфейсът [1].

Нюансът е важен: инструментът, който изпраща поръчката, го прави след потвърждението на купувача [1]. Според документацията контролът се връща на човека и когато се изисква допълнителната проверка 3D Secure, стъпката, с която банката издател проверява, че картодържателят наистина е този, който плаща [1].

С други думи: в потока, който Shopify документира, агентът подготвя, а човекът потвърждава; други схеми, като AP2, вече предвиждат автономни покупки при предварително упълномощаване от клиента [7]. Да се говори за «да купуват сами» в този случай би било преувеличение. Истината е по-неудобна и по-близка: в потока, документиран от Shopify, агентът вече стига до вратата на плащането, без магазинът да му отваря специална врата: според Shopify тези инструменти не предоставят нов интерфейс и не изискват настройка от страна на търговеца [1].

Съобщени са още два факта и е добре да се третират като това, което са. Според изявления на говорител, цитирани от GeekWire, Amazon блокира Muse, агента за пазаруване на Meta, наред с другото защото той не се представя, когато разглежда магазина [2]. Infobae съобщи, че Adidas би направила нещо подобно, без потвърждение от компанията [2]. Нито един от двата случая не доказва пазарна тенденция.

Един факт от контекста, за да не се надува очакването. В проучване на Visa и Harris Poll от май 2026 г. в Съединените щати (2065 потребители; въпросът за плащанията е зададен на подизвадка от около 1030 души) 23 % са казали, че се доверяват на генеративния ИИ да извършва плащания от тяхно име [3]. Това е проучване на доставчик на платежни услуги, в друга държава, и не измерва обем на покупките. При нашия преглед към 17 октомври 2026 г. на сайтовете и съобщенията на протоколите и мрежите, цитирани тук, не намерихме публични данни за обема на реалните транзакции, извършени от агенти. Което съществува, е инфраструктурата, а това е, което вие трябва да прегледате.

Пет неща, които вашата компания трябва да реши

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

1. Идентичност: отваря ли вратата, или я блокира?

Много филтри срещу автоматизиран трафик не разграничават събирането на цени от сайта (scraping) от клиент, подпомогнат от агент: третират и двамата като бот. Това защитава сайта ви от събиране на цени и от атаки, но може и да отхвърля, без да знаете, реални клиенти, които купуват чрез асистент.

Visa и Mastercard вече документират механизми за идентифициране на агенти. Протоколът на Visa за доверен агент (Trusted Agent Protocol) позволява на търговеца да различи легитимен агент от бот чрез криптографски подписи, свързани с търговеца и с целта на посещението, с кратък срок на валидност и неповторяеми [4]. Той се опира на отворен стандарт за подпис на HTTP съобщения, RFC 9421 [5]. Mastercard пък обяви, че рамката ѝ за приемане на Agent Pay изисква агентът да бъде регистриран и проверен преди всяка транзакция [6].

Което нито една от тези части не решава вместо вас, е политиката: кои агенти влизат, с какви лимити на справки и на сума и кой поддържа списъка. И двете възможности имат цена. Блокирането на всички може да загуби продажби, които вече са били сключени. Отварянето без критерий излага каталога, цените и наличностите ви на масови справки. Определете кой във вашата организация е собственик на това решение.

2. Упълномощаване: кой каза «да» на това плащане?

Когато купува човек, упълномощаването е на екрана: въвежда, потвърждава, банката го валидира. При агента това зависи от схемата. Има потоци, в които купувачът продължава да потвърждава в checkout, като този на Shopify и този на протокола на OpenAI и Stripe [1][9]. Но при делегираните или предварително упълномощените схеми разрешението е дадено преди това, на друго място, и вашата компания има нужда от доказателство, че е дадено.

Протоколите подхождат към този проблем с подобни идеи. AP2 на Google използва подписани «мандати»: разрешение на клиента с правила — таван на цената, срок на валидност — и одобрена кошница, които се стремят да оставят проверима следа от упълномощеното [7]. Visa съчетава платежен токен, създаден за агенти, с подсилена проверка на картодържателя чрез passkey (ключ за достъп) [8]. Протоколът на OpenAI и Stripe използва ограничен платежен токен, който не разкрива картата на клиента и оставя търговеца отговорен за продажбата [9].

За една компания се появява трети вид удостоверителни данни (credential), които не са нито картата на клиента, нито неговият портфейл: токен с ограничена сума, търговец и срок, в ръцете на програма. При потоците, които ползват ограничени удостоверителни данни, уточнете с платежния си процесор или с придобиващата банка как се приемат, валидират и отчитат; механизмът зависи от протокола и от платежния маршрут. За банката издател въпросът е друг: как представя на клиента това, което неговият агент може да харчи, и как оттегля това разрешение.

3. Спорове: кой отговаря, когато агентът сгреши?

Помислете за chargeback (оспорване на плащане от картодържателя) с нова причина: «не съм поръчвал това; моят агент сгреши». Грешка на клиента ли е, на търговеца, на платформата на агента или на издателя? Протоколите се стремят да запазят доказателството за първоначалната инструкция: AP2 със своите мандати [7] и Visa с онова, което нарича «търговски сигнали» за разрешаване на спорове [8].

Но доказателство не е критерий. При нашия преглед към 17 октомври 2026 г. на публикациите на CNBV, Banxico и CONDUSEF (банковият регулатор, централната банка и органът за защита на потребителите на финансови услуги в Мексико) не открихме мексиканско правило, което изрично да възлага отговорността за грешка на агент; това не е изчерпателен правен преглед. Прегледайте договорите с мрежите и с придобиващата банка и приложимите задължения, преди да определите политика. Дотогава защитата на вашата компания зависи от онова, което можете да докажете: каква инструкция е получена, от кой агент, с какво разрешение и какво е показал вашият магазин в този момент. Какво доказателство да се пази и колко дълго, според приложимата политика за съхранение, трябва да се реши днес, защото възстановяването му след първия спор може да се окаже невъзможно.

4. Данъчни данни: на кого се издава фактурата?

Тук е най-местният проблем и най-лесният за подминаване. В Мексико CFDI 4.0 (електронната данъчна фактура) изисква данни за получателя: неговия RFC (данъчен номер), името или фирменото му наименование, данъчния му режим и пощенския код на данъчния му адрес [10]. Човек ги въвежда във формуляр или профилът му вече ги има. Агентът може да не ги носи.

Без данните на получателя не може да се издаде именна CFDI по време на checkout (заверка — timbrado: заверката на CFDI от упълномощен доставчик). Тогава вашият екип има три пътя и трите струват: да поиска данните от клиента след това, със затруднението и закъснението, които това носи; да приложи политика на последваща фактура; или да включи операцията в общата фактура (factura global), която се прилага за операции с широката публика при условията на правило 2.7.1.21 от Resolución Miscelánea Fiscal (годишните данъчни правила на Мексико) [14] и не замества именната CFDI, когато клиентът я поиска. Нито един от източниците, които консултирахме, не решава кой е данъчният получател на покупка, направена чрез агент. Това е отворен въпрос и е добре да се отговори на него, преди случаите да се умножат.

5. Измами: как се различава легитимна покупка от открадната?

Моделите за риск, които защитават един търговец, се хранят, до голяма степен, със сигнали от човек: устройството, навигационният модел, часът, ритъмът на писане. Когато участва агент, тези сигнали може да липсват: трафикът идва от програма, а моделите, калибрирани за човешки трафик, може да се нуждаят от повторна проверка.

Това налага преглед на правилата, решаване кога се иска допълнително човешко потвърждение и включване на новите сигнали, които предлагат мрежите. И налага нещо по-основно: да се знае, че поръчката е дошла от агент. Ако този факт не остане записан в поръчката заедно с това кой е упълномощил, съгласуването и защитата при chargeback стават ръчен труд. Същото важи за връщанията: уточнете с придобиващата банка по кой маршрут се връщат.

Протоколите, по слоеве

Имената се множат — ACP, UCP, AP2, Visa, Mastercard — и е лесно да се повярва, че трябва да се избере един. Те не се състезават за едно и също: всеки решава различен слой. И са в различни етапи на зрялост, които е добре да не се бъркат.

Една компания може да се озове да говори няколко от тези протоколи едновременно. Затова полезният въпрос не е «кой да приемем?», а «какво трябва да е решено в моите системи, за да говорят който и да е от тях?».

Общото между тях е онова, което е за вас: каталог, цени и наличности, които една машина може да пита през интерфейс и без човек по средата; поръчка, която записва произхода си; и досие за това кой какво е упълномощил.

Сценарий: онлайн магазин с 10 000 поръчки на месец

Илюстративен сценарий, с измислени цифри, за да се покаже ефектът. Не описва никоя компания.

Един онлайн магазин получава 10 000 поръчки на месец. Допуснете, че 3 % започват да идват чрез агенти: 300 поръчки. Дотук малка цифра. Сега допуснете, че една пета от тези клиенти поиска фактура, а агентът не е донесъл данъчния режим и употребата на документа: това са 60 фактури, които не могат да бъдат заверени в момента.

Ако на всяка отделя 15 минути един аналитик, това са 15 часа ръчен труд на месец, които преди не съществуваха. Ако процентът на агентите се качи на 10 %, тези часове стават 50. И не сме броили нито един chargeback, нито едно връщане заради поръчка, неразбрана от агента, нито едно съгласуване, което не открива от кой агент е дошло плащането.

Урокът от примера не е цифрата: сценарият позволява да се оценят часовете, закъсненията на приключването и липсващите доказателства.

Какво е добре да направите тази седмица

Не ви е нужен проект, за да започнете. Нужно е да отговорите на пет въпроса с подходящите хора на една и съща маса:

1. Трафик. Колко от онова, което вашият сайт отхвърля като бот, би могло да е агент на клиент? Ако днес не го измервате, това е първият отговор.
2. Политика на вратите. Кой решава кои агенти влизат, с какви лимити и каква е цената на всяко решение?
3. Доказателство. Когато поръчка дойде от агент, какво остава записано: кой е упълномощил, какво е било показано, какво е било събрано?
4. Фактуриране. Какво прави вашият данъчен отдел с поръчка без данни за получателя и кой уведомява клиента?
5. Отговорност. Ако агентът сгреши, кой поема разхода: клиентът, вие, издателят или платформата, и къде е записано това?

За да престанат отговорите да бъдат мнение, е добре да измерите три неща, които вашият екип може да събере днес, без чужди цифри:

• Трафик, отхвърлен като бот. Какъв процент от посещенията, които вашият сайт блокира или подлага на допълнителна проверка (challenge), отговаря на модели, които биха могли да са агент на клиент? Кой го преглежда и колко често?
• Цена за възстановяване на фактура. Колко време и колко души са нужни днес, за да се издаде наново фактура, когато поръчката е дошла без пълни данъчни данни? Умножете го по броя поръчки, които биха могли да дойдат така.
• Цена на един chargeback. Колко ви струва днес да обработите един chargeback от край до край — време, комисиона, стока и доказателства — и колко повече би струвало, ако причината беше «моят агент сгреши»?

Ако два или повече от отговорите са «не знам» или «зависи кой отговаря», това не е провал на екипа ви: това са въпроси, които допреди няколко месеца никой не е имал причина да си задава. Променило се е, че ритъмът вече не се задава само от вътрешния ви график: задава го екосистемата.

Има и техническа част, за която вече има ръководство. Един агент да може да пита каталога ви, да повтаря заявка, без да дублира поръчка, и да получава грешки, които разбира, не е тема само на checkout: това е свойство на вашите интерфейси. Разработихме я в статията API, готови за ИИ агенти.

Какво прави Hábil

Проблемите по-горе имат нещо общо: случват се в съединението между системите. Поръчката се ражда в един канал, плащането в друг, фактурата в трети, а съгласуването в четвърти, и на никой от тях не му е работа да знае, че купувачът е бил агент. Hábil се занимава с това съединение: интегрира съществуващи системи с цел операциите да оставят следа за това кой ги е упълномощил и новият канал да не налага пренаписване на предишните.

Ако вашата компания мисли как да приеме — или как да ограничи — ИИ агентите, страницата Hábil AI обяснява какво правим с тях, а статията API, готови за ИИ агенти описва какво е нужно на вашата система, за да я използва един агент под контрол.

Следващата стъпка е проста: пишете ни в WhatsApp. В първия разговор, безплатен, ви казваме къде вероятно се губят пари, време или доказателства в интерфейсите на вашата дейност и дали си струва задълбочена диагностика, с договорен обхват.