Готовност на данните за AI: ръководство за мениджъри

„Данните ни не са готови за AI“ е най-често повтаряното изречение в подготвителните разговори и почти винаги е неточно. Данните не са готови или неготови по принцип. Те са годни или негодни за определено приложение, при определени условия, за определен период.

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

1. Предназначение: определете решението или задачата

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

Предназначението има и правно значение. Регламент (ЕС) 2024/1689 изгражда класификацията и задълженията върху предназначението, а изискванията към управлението на данните за системите с висок риск са пряко обвързани с него.

2. Инвентаризация: проследете реалния път на данните

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

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

3. Основание: разграничете възможното от допустимото

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

Ако данните идват от външен източник или се споделят с друга организация, приложими могат да бъдат и Регламент (ЕС) 2022/868 относно управлението на данни и Регламент (ЕС) 2023/2854 относно данните. Договорът с доставчика на системата не отменя нито един от тях.

4. Необходимост: използвайте минимума, който върши работа

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

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

5. Качество: определете годност за това използване

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

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

6. Представителност: знайте кой и какво липсва

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

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

7. Проследимост: всеки съществен изход да сочи към източник

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

8. Оценка: създайте актив за тестване, който се използва повторно

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

Функциите Map и Measure на NIST AI Risk Management Framework предлагат структура за това какво се описва и какво се измерва, приложима и извън задължителния регулаторен обхват.

9. Отговорност: направете готовността непрекъсната

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

Концепцията за развитието на изкуствения интелект в България до 2030 г. поставя капацитета и данните в центъра на националния подход — на ниво организация същият извод означава хора, назначени да поддържат тези активи, а не проект с краен срок.

Историческите данни носят историческите решения

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

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

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

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

Едностранично решение за готовност

Резултатът не е „готово“ или „неготово“. Той е изречение с обхват: годно за прототип само за четене върху одобрени документи, но не и за запис в клиентско досие; годно за един екип и един език, но не и за цялата организация. Обхватът е контрол — и е единственият контрол, който може да бъде въведен, преди да е похарчен бюджет.

Какво тази проверка не може да направи

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

Ако искате структурирана оценка на това дали вашите данни поддържат конкретно AI приложение, започнете с безплатната диагностика.

Тази публикация е адаптирана от английския оригинал. При различие английската версия е меродавна.