ИИ за обслужване на клиенти с проследимост, която може да се провери, а не красива демонстрация

Представете си една събота в единайсет вечерта. Клиент пише на асистента на своя застраховател, своята банка или своя магазин: «Приложено ли е вече плащането ми? Виждам такса, която не разпознавам». Асистентът отговаря любезно, с добро изразяване и с пълна сигурност: «Плащането ви е в процес, не се безпокойте». Не е проверил системата за събиране на вземания, защото няма достъп до нея. Отговорил е с онова, което знае по темата най-общо. В понеделник клиентът звъни на своя служител и повтаря всичко отначало.

Тази сцена не е недостатък на езиковия модел; тя илюстрира риск в проектирането: един асистент може да отговаря гладко и въпреки това да няма достъпа, правата или контекста, нужни за решаването на реален случай. Една демонстрация, със своя чист сценарий, рядко показва този риск.

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

Защо асистентите остават демонстрация

Една демонстрация работи, защото сценарият е чист: тестов клиент, три репетирани въпроса, никаква реална система по средата. Онова, което се случва после, в дейност с десетилетия натрупани системи, има два често срещани начина да се провали.

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

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

Пазарните данни сочат в същата посока, с уговорка за метода. Данни на Gartner: в проучване сред 5728 клиенти, проведено през декември 2023 г., Gartner съобщава, че само 14 % от проблемите с обслужването и поддръжката са били решени напълно в самообслужване; при тези, които клиентите описват като «много прости», цифрата е 36 % [3]. Това е проучване на потребители, а не изходна линия за Мексико или за конкретен сектор; използвайте го като сигнал. Цифрата разграничава отговарянето от решаването; сама по себе си не доказва причината за всяка неуспешна ситуация. При случаите, които изискват справка с актуална информация или започване на процедура, комитетът трябва да провери кои данни и действия са разрешени за асистента.

Какво трябва на онзи, който наистина решава

Когато един асистент престане да е демонстрация и започне да работи, са му нужни пет способности. Четири са технически, а една е на процеса.

1. Идентичност: да знае с кого говори и от чие име действа

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

2. Права: минималното, за конкретното

Асистентът за обслужване няма нужда от достъп до цялата система; нужно му е да проверява статуса на операция на клиент, който вече е идентифициран, и може би да започва ограничен процес. Тази разлика, между «може да вижда всичко» и «може да прави тези три неща за този клиент», отделя един управляем риск от такъв, който на комитет по рисковете би било трудно да приеме. Всяко действие трябва да е определено предварително, с ограничен обхват и, когато е възможно, с възможност да бъде върнато.

3. Данни на клиента: само необходимите, и на показ за титуляра

Тук влиза законът и ще се види по-долу. Основната идея е оперативна: колкото повече лични данни минават през асистента, толкова повече повърхност има за защита. Добре е да се знае какви данни проверява, с каква цел, къде се обработват, кои доставчици участват и колко време се пази разговорът.

4. Дневник: да може да се възстанови всеки разговор

Това е способността, която най-много се подценява и която тежи най-много, когато нещо се обърка. За всяко взаимодействие е важно да може да се възстанови: кой е попитал и как е проверен, какви данни са проверени, какво е отговорил асистентът, какво действие е изпълнил, коя версия на инструкциите и на модела е била активна и кога се е случило. Дневник, който пази само текста на разговора, не стига; онзи, който върши работа, записва и онова, което асистентът е направил в системите. И трябва да е защитен срещу изменение, защото дневник, който някой може да редактира, не е доказателство.

5. Предаване на човек: да се излезе навреме, с контекст

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

Какво казва новият закон за личните данни

Ley Federal de Protección de Datos Personales en Posesión de los Particulares (Федералният закон за защита на личните данни, притежавани от частни лица), който действа днес, е нов закон: публикуван е в Diario Oficial de la Federación (държавния вестник на Мексико) на 20 март 2025 г., заменя този от 2010 г., а действащият му текст включва промяна от 14 ноември 2025 г. Органът, който го прилага, е вече Secretaría Anticorrupción y Buen Gobierno (министерството на борбата с корупцията и доброто управление) [1]. Пет точки от текста са важни за онзи, който управлява ИИ асистент. Резюмираме ги по-долу; приложението им към конкретен процес, канал и сектор трябва да се провери с вашия юридически отдел и отдела по съответствие.

• Уведомление за поверителност в електронните канали (чл. 16). Когато данните се получават по електронен път, уведомлението трябва да се даде в опростената си форма, с основната информация и мястото, където се консултира пълното уведомление. Ако в чат или във WhatsApp се събират лични данни, проверете с юридическия си отдел как се предоставя опростеното уведомление и достъпът до пълното в този процес, и го включете още от първия контакт [1].
• Цел (чл. 11). Обработката трябва да се ограничава до целите на уведомлението; за различна цел е нужно ново съгласие. Ако смятате да използвате повторно разговори, за да обучавате или подобрявате асистента, проверете дали вашето уведомление го предвижда [1].
• Мерки за сигурност и поверителност (чл. 18 и 20). Изискват се административни, технически и физически мерки срещу загуба, изменение или неразрешен достъп, пропорционални на риска и на чувствителността на данните, както и контроли, за да пазят поверителност онези, които участват в обработката [1]. Минималните права и дневникът от предишния раздел са практическата версия на това изискване.
• Автоматизирани решения (чл. 26, фракция II). Титулярът може да възрази, на законно основание, срещу обработка, когато тя е автоматизирана, поражда нежелани правни последици за него или съществено засяга неговите интереси, права или свободи и е предназначена да оценява, без човешка намеса, определени лични аспекти или да анализира или прогнозира, наред с другото, икономическото му положение, надеждността или поведението му; законът изключва случаите, в които обработката е необходима за изпълнение на законово задължение [1]. Ако процесът може да породи нежелани правни последици или съществено да засегне човек чрез автоматизирана обработка, прегледайте с юридическия си отдел правото на възражение. Определете също, като контрол на риска, кои решения изискват човешка проверка.
• Права ARCO и срокове (чл. 2, фр. VII и VIII; чл. 22 до 31 и 58). Титулярът може да поиска достъп, поправяне, заличаване или възражение (acceso, rectificación, cancelación u oposición, ARCO). Отговорникът трябва да съобщи решението си най-късно в срок от двайсет дни от получаването на искането, а законът определя «дни» като работни; може да се удължи веднъж с равен срок, ако обстоятелствата го оправдават. Неизпълнението на искане без основателна причина е нарушение [1]. Добре е чатът да разпознава и да насочва евентуално искане ARCO към механизма от уведомлението за поверителност, да се проверяват самоличността и изискванията (чл. 28) и да се пази датата на получаване; а заличаването не винаги означава незабавно изтриване, защото законът предвижда период на блокиране (чл. 24).

Бележка за предпазливост: законът препраща към своя правилник за няколко процедури, а към момента на написване на статията сборникът на Камарата на депутатите посочваше само правилника, публикуван през 2011 г. и издаден за предишния закон [5]. Затова, освен този закон, потвърдете с юридическия си отдел правилника, вторичните разпоредби и секторната регулация, които са в сила към датата на четене; всяка от тях може да уточни горните задължения.

Жалбите: там, където дневникът става защита

За финансовите субекти, изброени в чл. 3, фракция IX от закона (кредитни институции, финансови дружества с множество цели, популярни и общностни финансови дружества, кредитни кооперации, кредитни съюзи и институции за финансови технологии), добре е да се провери дали процесът на асистента попада в процедурата по уточнения. Ley para la Transparencia y Ordenamiento de los Servicios Financieros (Законът за прозрачност и подреждане на финансовите услуги, чл. 23) казва, че при операции и услуги, сключени чрез масово договаряни договори за присъединяване и до максималните размери, определени от органа (CONDUSEF), когато клиент не е съгласен с движение, може да подаде искане за уточнение в срок от деветдесет календарни дни, считано от датата на среза на извлечението или, когато е приложимо, от датата на операцията или услугата; че субектът трябва да потвърди получаването; и че след като получи искането, има най-много четирдесет и пет дни, за да предаде на клиента заключение (dictamen) с копие на разгледаните доказателства и подробен доклад, който отговаря на всички изложени факти [2]. Списъкът на финансовите субекти в този закон не включва застрахователите: ако сте застраховател, вашият кръг за жалби се определя от Ley de Protección y Defensa al Usuario de Servicios Financieros (чл. 50 Bis изисква от всяка финансова институция, включително застрахователите, специализирано звено за запитвания и рекламации, което трябва да ги приема по всяко средство, улесняващо получаването им, и да отговаря писмено в срок, не по-дълъг от тридесет работни дни) и от застрахователната регулация [4]. Нюансите на всеки вид жалба и на всеки орган са в секторната регулация; добре е вашият отдел по съответствие да ги потвърди.

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

Затова въпросът на комитета не е «колко контакта поема асистентът?». Той е: какво се случва, когато един контакт се превърне в жалба? Разпоредбите на CONDUSEF за специализираните звена вече изискват, по всяко средство за приемане, включително електронното, да се потвърди получаването, да се даде номер и да се посочи срокът за отговор, както и предишните случаи да са на разположение на Комисията в продължение на две години [6]. Тези разпоредби изискват потвърждаване на получаването, номер и срок за отговор, както и съхраняване на предишните случаи и решенията за две години. Останалото е вътрешна цел за обслужване, която е добре да се определи и да се изпробва в упражнения за контрол: да се запише с номер, дата и час, да стигне до правилния човек, без да се загуби казаното, и някой да може да го извлече за минути, а не за дни. Това тежи колкото всеки процент задържане.

Сценарий (илюстративен; не съответства на реален клиент. Сроковете за жалби в застраховането се определят от друга регулация; принципът, да се стигне до преписката с доказателства, е същият). Средна по размер застрахователна компания дава възможност на асистент да съобщава статуса на щети по WhatsApp. Един застрахован пита за претенцията си и получава «в преглед, без висящи неща». Две седмици по-късно подава жалба: казва, че от него е поискан документ и никой не му го е съобщил. Ако застрахователят може да възстанови кой статус е проверил асистентът, в колко часа и с какъв отговор, разполага с елементи да съпостави случая и да обоснове отговора си. Ако пази само общо резюме, преписката зависи от паметта на застрахования и на неговия служител.

Пет въпроса за вашия следващ комитет

1. С каква идентичност действа нашият асистент във всяка система? Ако е споделен акаунт или с широки права, първата констатация вече е налице.
2. Можем ли да възстановим, за минути, всеки разговор? С кого е говорено, какви данни е проверил, какво действие е извършил, коя версия е била активна. Изпробвайте го с разговор, избран на случаен принцип.
3. Къде се намират личните данни, които минават през асистента и кои доставчици участват? Покрива ли нашето уведомление за поверителност тази цел? Всеки доставчик действа ли като обработващ или като трето лице и документирано ли е това? Как бихме открили и съобщили нарушение на сигурността (чл. 19)?
4. Когато един разговор се превърне в жалба или искане ARCO, кой го получава, с какъв номер и за колко време? Как стига с целия контекст?
5. Ако асистентът даде погрешна информация, кой отговаря, как се поправя и как се документира?

Колкото повече отговори са «не знам», толкова по-вероятно е да не липсва по-добър модел, а да се свърже и да се управлява онова, което вече съществува.

Преди да одобрите един случай на употреба

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

От къде да започнете тази седмица

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

Направете същото упражнение с разговор, който асистентът е предал на човек: стигна ли целият контекст?

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

Hábil работи точно там, където един асистент спира да е демонстрация: да свърже ИИ със системите, които вече работят, с идентичност, ограничени права, запис на онова, което прави, и предаване на човек, когато е уместно. Hábil AI е предложението за свързване на възможностите на ИИ със системите на организацията; Nova е виртуалният асистент, насочен към обслужването на клиенти. Когато случаят изисква обработка в инфраструктура под контрола на вашата организация, обхватът, доставчиците и контролите трябва да се определят за този случай. За да решавате кой влиза във всяка система, вижте Контрол на достъпа; за да обедините вашите канали и системи — Обединяване на дейността и каналите.

Първият разговор за диагностика е безплатен: излизате с първо четене на картата на вашите интеграции и на точките, където вероятно се губят пари, време или доказателства. Пишете ни в WhatsApp.