AUT-0424· Знання та ШІ
Перевірка даних ШІ перед записом у бізнес-систему
Система перевіряє структуру й бізнес-правила результату ШІ, перш ніж дозволити створити або змінити запис.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Інтеграція може прийняти синтаксично коректну, але неповну чи суперечливу відповідь ШІ та без перевірки перенести її в CRM або ERP.
02 / Результат
У бізнес-систему записуються лише результати з потрібною структурою, перевіреними посиланнями та виконаними правилами; інші результати переходять на ручний розгляд.
03 / Процес
ТригерЗовнішня модель або AI-сервіс завершили класифікацію чи витяг полів, що мають створити або змінити запис у бізнес-системі.
Описати схему результату, обов’язкові поля, допустимі значення, правила порожніх даних, посилання на джерело та бізнес-обмеження для цільової дії.
Запросити структурований формат, якщо його підтримує постачальник; інакше розібрати відповідь і перевірити її власним валідатором перед будь-яким записом.
Відхилити відповідь із відмовою, неповним виводом, невідомим значенням або відсутнім джерельним фрагментом; не заповнювати пропуски припущеннями.
Перевірити детерміновані правила: наявність пов’язаного клієнта чи замовлення, узгодженість дат, сум і статусів з первинною системою та межі дозволеної дії.
Направити невідповідність відповідальному з посиланням на оригінал і результат; не запускати автоматичний повтор або запис без виправленої перевірки.
Для результату, що пройшов контроль, створити або оновити запис і повторно прочитати його для підтвердження; ключ ідемпотентності має захищати від повторної події.
Зберігати версії схеми, правил і рішення перевірки; обсяг сирого тексту в журналі обмежити погодженою політикою зберігання.
04 / Реалізація1 варіант
Приклад · Перевірка структури й правил перед записом
AI прочитав лист про зміну адреси доставки та сформував поля клієнта й замовлення. Контроль знаходить замовлення, звіряє поточний статус і перевіряє обов’язкові поля; невідповідний статус іде оператору, валідна зміна записується з підтвердженням повторного читання.
Спосіб реалізації
- Використати вихід, обмежений JSON Schema, якщо це підтримує модель, і додати окремі перевірки посилань на записи, чисел, статусів і повноважень.
- Поставити детермінований валідатор перед конектором запису; відмова, неповний результат або помилка перевірки не повинні викликати зміну даних.
Що потрібно для реалізації
- Власник процесу визначив цільову дію, джерело істини, схему, бізнес-правила та випадки для ручного розгляду.
- Для системи-джерела й цільової CRM/ERP є дозволений спосіб читання, запису та перевірки результату.
- Є контрольні приклади правильних, неповних, суперечливих і відмовних результатів; повторна подія не створює дублів.
- Задокументовані цільова схема, правила та джерела істини.
- Є черга ручного розгляду й спосіб підтвердити фактичний запис.
Обмеження
- Відповідність схемі не підтверджує фактичну правильність, доречність або достатність відповіді моделі.
- Підтримка схем і крайових випадків відрізняється між постачальниками; відмови, обмеження довжини та неповні відповіді треба обробляти явно.
- Перевірки працюють лише для формалізованих правил і доступних джерел; неоднозначні бізнес-рішення лишаються людині.
- Години попередні; тарифи моделі, перенесення історичних записів і налаштування цільової системи не включені.
- Схема перевіряє форму даних, але не доводить правдивість змісту.
- Потрібна перевірка обробки відмов, неповного виводу, повторних подій і змін API.
Що потрібно уточнити (2)
- Чи треба перевіряти або записувати дані в кількох бізнес-системах?
Перелічіть джерела істини та цільові CRM/ERP; уточніть, де створюється головний запис.
- Чи потрібно підтримувати кілька типів документів або редакцій схеми?
Укажіть типи вхідних даних, версії полів і правила сумісності старих результатів.