Безопасност на ИИ: защита за растящия бизнес

Надеждната автоматизация започва с ограничени права, проверими задачи и ясен план за действие при грешка.

Преди да дадете на виртуалния помощник право да изпраща оферти, задайте един неудобен въпрос: какво ще стане, ако предложи цена, която никой не е одобрил? „Безопасност на ИИ“ звучи като тема за научна конференция, но за предприемача започва точно тук — при границата между полезния отговор и действието от името на фирмата.

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

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

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

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

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

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

Математическата проверка изисква точен въпрос

В описанието на разговора на Y Combinator с професорите от Станфорд Кларк Барет и Майкъл Кохендерфер присъства автоматизираното логическо доказване. Разделът за доказване на коректността на код започва от 20:35. Темата насочва към важен управленски въпрос: какво точно искаме да бъде гарантирано?

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

Ако разработвате инструмент за издаване на оферти, полезно изискване би било: документ без одобрение да не може да бъде изпратен. Това е далеч по-конкретна задача от „помощникът винаги да взема правилното решение“. Точната граница дава на разработчика ясна цел, а на ръководителя — нещо, което може да поиска да види проверено.

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

Изпитайте неудобните случаи преди клиентите

Другата полезна отправна точка е адаптивното стресово тестване, посочено в програмата от 32:11. Описанието свързва методи за изпитване на авиационни системи с езиковите модели. За малката фирма разумният извод е да търси условията, при които собствената ѝ автоматизация се проваля.

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

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

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

Възложете отговорността преди внедряването

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

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

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

Практическият извод: разширявайте правата след проверка

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

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

Разговор на Y Combinator за научните и инженерните подходи към безопасността на изкуствения интелект с Кларк Барет и Майкъл Кохендерфер.

Правата трябва да следват работата, която действително му възлагате.

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

▶

Гледайте оригиналния епизод в YouTube: Y Combinator.

Източници

• Y Combinator: научни подходи към безопасността на изкуствения интелект — Използвани са предоставените описание и времеви указатели, а не пълен препис. Тематични отправни точки: доказване на коректността на код от 20:35 и адаптивно стресово тестване от 32:11. Практическите предложения са самостоятелни препоръки, а не цитати или приписани на участниците заключения.