Есть одна очень простая и неприятная история из практики.
Конструкторское бюро отправляет сборочный чертёж нового узла во внешний ИИ-сервис с вполне невинной целью:
«Да мне только техтребования на английский перевести».
На этом месте обычно кажется, что ничего страшного не произошло.
Но проблема начинается уже в момент, когда конструкторская документация покидает защищённый контур предприятия. Что дальше происходит с конкретным файлом и как именно сервис его обрабатывает — предприятие уже не контролирует.
Поэтому правило у нас простое:
Если документ нельзя отправить конкуренту на личную почту — его нельзя загружать в публичный веб-интерфейс нейросети.
Но возникает закономерный вопрос: а почему инженеры вообще туда лезут?
Потому что альтернатива часто выглядит так.
Технолог берёт PDF или скан сложной детали и несколько часов вручную переносит в 1С:ERP марку стали, термообработку, допуски, шероховатость, посадки, требования ГОСТ и ещё пару сотен параметров.
Четыре часа работы ради того, чтобы перепечатать цифры из одного окна в другое.
Причём ошибка в одной цифре — это уже не просто опечатка. Неправильный материал или допуск может уйти дальше в технологический процесс и превратиться в очень дорогую ошибку.
Поэтому мы пошли не по пути «запретить всем ChatGPT», а по пути дать инженеру такой же удобный инструмент, но внутри периметра предприятия.
В проекте АИСТ это выглядит так:
локальная VLM-модель работает на сервере предприятия, без необходимости отправлять документацию во внешнее облако;
система распознаёт штамп, таблицы, параметры и специальные требования;
в 1С:ERP формируется черновик данных;
технолог не перепечатывает сотни строк, а проверяет результат, сверяет критические параметры и подписывает его.
И главное:
ИИ не управляет станком и не принимает производственных решений.
Он просто забирает у инженера тупую перепечатку цифр.
Потому что инженер должен заниматься технологией, а не изображать человека-сканер.
Кейс проекта АИСТ и как устроен локальный контур КТПП: 👉 https://naumovai.ru/cases/aist/