Це різні продукти від різних компаній, і всередині кожного працюють різні моделі. Для бізнесу важить саме рівень продукту: що він робить з вашими файлами, що пам'ятає між розмовами, з чиїми правами ходить у ваші системи і де лежать дані після того, як розмова закінчилась.
Коротко
- За словом "ШІ" в розмові про бізнес ховаються три різні речі: модель, продукт і компанія, яка їх випускає. Плутанина між ними коштує грошей і даних.
- Модель - це двигун, який читає текст і пише відповідь. Продукт - усе, що навколо двигуна: вікно чату, робота з файлами, пам'ять, підключення до інших систем, налаштування доступу для команди.
- Одна модель може працювати в кількох продуктах, а один продукт може перемикати моделі. Тому суперечка "хто розумніший" мало що каже про вашу конкретну задачу.
- Для компанії вирішальні правила продукту: як він читає Excel і PDF, що зберігає і де, хто бачить дані, з якими правами працюють підключення.
- Інструмент обирають під тип файлу і процес, перевіряючи його на власному документі, а бренд лишається другорядною ознакою.
"Ми вже на ШІ"
Цю фразу я чую від власників невеликих компаній майже на кожній першій розмові. Далі я ставлю одне уточнювальне питання: на якому саме? І ясність зникає. Бухгалтер звіряє виписки в одному продукті через особистий акаунт. Людина, яка веде закупівлі, розбирає прайси постачальників в іншому, бо колись підписалася на пробний період. Сам власник з телефону ставить питання третьому, бо той вбудований у його пошту. Три набори правил, три місця, де лежать файли компанії, і жодна людина в компанії не може сказати, що з цих файлів уже зберіглося в пам'яті продуктів і хто ще має до них доступ.
Формально компанія справді на ШІ. Фактично в неї три особисті експерименти, які нічим між собою не пов'язані. Коли власник хоче зробити наступний крок, наприклад, підключити модель до обліку чи до CRM, з'ясовується, що підключати нікуди: спільного простору немає, правил немає, і навіть назва "наш ШІ" в кожного співробітника означає свій продукт.
Ця плутанина має коріння в тому, як ми говоримо. Слова "ChatGPT", "Claude" і "Gemini" звучать як три назви одного типу речі, приблизно як три марки кави. Насправді кожна з них позначає одразу кілька рівнів, і для рішень у бізнесі їх треба розвести.
Модель, продукт і вендор: три різні речі
Модель - це навчена система, яка отримує текст, файли чи зображення і пише відповідь. У моделей є свої назви й версії, вони оновлюються кілька разів на рік, і в межах одного продукту вам часто дають вибір між кількома моделями: швидшою, дешевшою чи потужнішою.
Продукт - це те, з чим працює людина. Вікно чату, кнопка завантаження файлу, пам'ять між розмовами, проєкти, підключення до пошти, диска чи облікової системи, налаштування для адміністратора, журнал дій. Саме тут живуть правила, які вас стосуються: скільки сторінок PDF продукт прийме, чи бачить він формули в Excel, що він пам'ятає про вас наступного ранку, чи використовуються ваші розмови для навчання моделей і як це вимкнути.
Вендор - це компанія, яка випускає модель і продукт. ChatGPT - продукт компанії OpenAI. Claude - назва і сімейства моделей, і продукту компанії Anthropic. Gemini - сімейство моделей і продукт Google, який до того ж вбудований у поштові й офісні сервіси цієї компанії. Межі між рівнями розмиваються ще сильніше, коли модель одного вендора з'являється всередині продукту іншого: у великих робочих пакетах адміністратор уже вмикає поруч моделі різних компаній, а інтерфейс, файли і правила доступу лишаються ті самі.
Мені ця конструкція знайома з фінансових ринків. Одна й та сама індексна стратегія продається в десятках фондів. Стратегія однакова, а правила різні: комісії, умови виходу, хто зберігає активи, як часто публікується звіт. Інвестор, який вибирає фонд за назвою управляючої компанії, регулярно отримує неприємні сюрпризи в дрібному шрифті. Досвідчений інвестор читає правила фонду. З ШІ-продуктами працює та сама логіка: бренд на обкладинці розповідає про вендора, а про те, що станеться з вашими даними, розповідають правила продукту.
Сцена з асортиментною матрицею
Добре це видно на історії однієї торгової команди, з якою я працював цієї осені. Закупівлі в них тримаються на асортиментній матриці в Excel: кілька тисяч позицій, кілька аркушів, формули, зведені таблиці, колонки з кодами постачальників. Частина команди працювала з Gemini, бо він був під рукою в робочому середовищі, і на цьому файлі результат виходив слабким. Модель плутала аркуші, губила колонки при зведенні, суми по категоріях не сходилися з тим, що показував сам Excel.
Команда могла піти шляхом, який я бачу найчастіше: влаштувати суперечку, чий улюблений ШІ кращий, і розійтися кожен до свого особистого акаунта. Вони зробили інакше. Взяли той самий файл і те саме завдання, прогнали його через два інші продукти і звірили результат з контрольними сумами. Після цього вирішили перейти на один корпоративний продукт для всієї команди і завели окремий файл "Правила": які аркуші головні, як називаються колонки, які формули лишати без змін, у якому вигляді повертати результат, що робити, коли дані не сходяться. Цей файл тепер підтягується до кожної робочої розмови з матрицею.
Висновок з цієї історії я прошу читати уважно. Він стосується того, як конкретний продукт на той момент обробляв конкретний тип файлу в конкретному процесі. Про бренд у цілому він не каже нічого. Через пів року після оновлень той самий тест може дати зовсім інший результат. Тому рішення приймалося під файл і під процес, а наступну перевірку команда запланувала на момент, коли матриця зміниться або продукт отримає велике оновлення.
Конектор ще не означає права доступу
Друга історія стосується вже не файлів, а підключень. Конектор - це міст між ШІ-продуктом і іншою системою компанії: поштою, диском, CRM, обліком. Через нього модель читає дані сама, без копіювання в чат.
Одна компанія підключала модель до своєї облікової системи обережно, як і годиться: окреме тестове середовище, доступ лише на читання, жодних змін у реальних даних. Під час перевірки співробітник попросив модель підсумувати рахунки за період, і вона це зробила. Проблема була в тому, що самому співробітнику ці рахунки в обліковій системі бачити не дозволено. Конектор ходив у систему під своїм технічним обліковим записом з широкими правами, а розмежування "хто що бачить", так званий список прав доступу, або ACL, залишилося по той бік мосту.
Режим "лише читання" захистив дані від змін і зовсім не захистив їх від перегляду. Для власника це типова пастка: здається, що підключення безпечне, бо модель нічого не може зіпсувати. Насправді питання звучить інакше: з чиїми правами працює конектор, з правами людини, яка ставить питання, чи зі своїми власними. І ця відповідь теж належить до правил продукту та способу підключення, а бренд моделі тут нічого не вирішує.
Що порівнювати, коли обираєте продукт для компанії
Коли мене питають, яку нейромережу вибрати для бізнесу, я перекладаю питання на п'ять практичних вимірів.
Перший - файли. Які формати продукт читає, скільки сторінок чи рядків приймає за раз, чи розуміє аркуші та формули в Excel, що робить зі сканами. Перевіряється це тільки на вашому реальному документі з відомою контрольною цифрою.
Другий - пам'ять. Що продукт пам'ятає між розмовами, де можна подивитися й видалити збережене, чи є робочі проєкти, куди один раз кладуться правила й довідкові файли.
Третій - дані. Чи потрапляють ваші розмови в навчання моделей, де вони зберігаються, хто в компанії адмініструє простір і може забрати доступ у людини, яка звільнилася.
Четвертий - підключення і дозволи. До яких систем продукт вміє підключатися, з чиїми правами, чи є журнал того, що модель прочитала і що зробила.
П'ятий - команда. Чи можна зібрати всіх в одному корпоративному просторі з однаковими правилами, або кожен лишиться у своєму особистому акаунті.
Мій висновок такий: ChatGPT, Claude і Gemini - різні продукти, і вибирати між ними за гучністю бренду чи за черговим рейтингом розумності моделей для бізнесу немає сенсу. Вибирати треба той продукт, чиї правила файлів, пам'яті, даних і доступу підходять під ваш процес, перевіривши це на своєму документі, і тримати всю команду в одному корпоративному просторі. Компанія, яка зробила це один раз, спокійно міняє модель усередині, коли з'являється краща, а компанія з трьома особистими акаунтами щоразу починає з нуля.
Що робити далі
- Зробіть інвентаризацію: хто в команді яким ШІ-продуктом користується, з якого акаунта, особистого чи робочого, і які файли компанії туди вже потрапляли.
- Випишіть два-три процеси, під які вам потрібен ШІ, і типи файлів у кожному: матриця в Excel, договори в PDF, листування з клієнтами, виписки.
- Візьміть один реальний файл з відомою контрольною цифрою і дайте однакове завдання двом продуктам. Порівнюйте результат з контрольною цифрою, а враження від тону відповіді відкладіть.
- Оберіть один корпоративний продукт, заведіть у ньому файл "Правила" для кожного процесу і переведіть туди всю роботу з даними компанії з особистих акаунтів.
- Перед підключенням будь-якої системи з'ясуйте, з чиїми правами працює конектор, і перевірте це на тестовому користувачі, якому частина даних бачити заборонено.
Про цей матеріал
Текст спирається на практику впровадження ШІ в невеликих компаніях і командах, з якими я працюю. Історії з асортиментною матрицею і з підключенням до облікової системи взяті з реальних робочих сесій, усі деталі, за якими можна впізнати компанії, прибрані. Історія з трьома особистими акаунтами узагальнена з типових перших розмов з власниками. Я Михайло Пацан, вісімнадцять років працював на фінансових ринках, а тепер допомагаю підприємцям упроваджувати ШІ і навчаю цього керівників.