Знакомая ситуация. Клиент звонит и спрашивает, где его заказ. Менеджер открывает CRM, там сделка закрыта. Открывает 1С, там отгрузка не проведена. Пишет на склад в чат и ждёт ответа десять минут. Клиент тем временем ждёт на линии. Ни одна система не соврала. Просто каждая знает свою часть, а целой картины нет ни у кого. Я Антон Баранов, основатель Solaris AI. В этой статье объясню, что мы делаем с данными компании и почему для этого не нужно ничего сносить.
В чём проблема на самом деле
Когда руководитель говорит «у нас нет данных», это почти всегда неправда. Данные есть. В 1С лежат отгрузки, оплаты и остатки. В CRM карточки клиентов и сделки. В почте переписка с обещаниями и условиями. В таблицах планы и отчёты, которые кто-то собирает руками. В телефонии записи звонков. На сайте заявки. В банке платежи. В рабочих чатах договорённости. В папках договоры и спецификации.
Проблема в другом: всё это лежит порознь. Клиент в CRM и контрагент в 1С могут быть одной и той же компанией, но системы об этом не знают. Договор лежит в папке, платёж в банке, а связь между ними живёт в голове бухгалтера. Чтобы ответить на простой вопрос «сколько нам должен этот клиент и что мы ему обещали», нужно открыть четыре окна и потратить полчаса.
Обычный ответ на эту боль: давайте всё перенесём в одну систему. Я видел, чем это заканчивается. Год внедрения, сопротивление сотрудников, часть данных потеряна, а старые системы всё равно остались, потому что без них не работает бухгалтерия. О том, почему внедрение AI в компаниях чаще всего проваливается, я писал отдельно.
Есть другой путь. Ничего не переносить. Оставить каждую систему на месте и построить поверх слой, который читает все записи и собирает из них понятные объекты.
Как это решила армия США
Так работает Palantir, чьё программное обеспечение стоит в армии США. В сентябре 2026 года вышел разбор его архитектуры, и главная мысль оттуда точно описывает ситуацию в любой компании. Армия не обнаружила вдруг, что ей не хватает данных. Данных было огромное количество, но они были разбросаны по существующим системам. Одна служба знает, где техника. Другая знает, исправна ли она. Третья знает, кто допущен с ней работать. Каждая база точна сама по себе, а общей картины нет.
Заменить все базы дорого, разрушительно, а иногда невозможно. Поэтому Palantir подключается к ним, строит поверх общую модель объектов (в их терминах онтологию) и уже на этой модели делает приложения. Пользователь работает с объектом «самолёт» и не думает, из каких строк и столбцов тот собран.
Цифры. Платформа Army Vantage подключила более 180 систем и более 30 000 наборов данных армии США. С помощью платформы офицеры по контрактам нашли более 3,3 млрд долларов зависших обязательств: денег, зарезервированных на бумаге, которые можно было вернуть и направить на другие задачи. Ни одну базу при этом не заменили. Деньги нашлись в тех данных, что уже были.
31 июля 2025 года армия США свела 75 контрактов с Palantir в одно соглашение сроком до 10 лет с потолком 10 млрд долларов. Это потолок, а не гарантированная сумма. Важно другое: слой над данными стал отдельной закупкой. Не системы, не интерфейсы, а именно слой, который делает их понятными вместе.
Сразу про масштаб. Мы делаем то же самое для бизнеса, а не для армии. У типичного клиента не 180 систем, а пять или семь. Но принцип один: ценность лежит не в новых данных, а в связях между старыми. Я не обещаю цифр Palantir. Я обещаю тот же подход.
Три слоя
Схему целиком можно посмотреть на главной странице сайта, здесь разберу каждый слой по отдельности.
Нижний слой: ваши системы и модели
Слева всё, что уже работает: 1С, CRM, почта, таблицы, звонки, сайт, склад, банк, чаты, файлы. Они остаются как есть. Ничего не переносим, никого не переучиваем. Слой их только читает и, где нужно, пишет обратно через API. Бухгалтер продолжает работать в 1С, менеджер в CRM.
Справа модели и ИИ-агенты: разбор документов, оценка лида, прогноз спроса, поиск аномалий, сводки для руководителя. Это инструменты. Без среднего слоя они не знают, что такое клиент или заказ.
Средний слой: объекты
Здесь главная работа. Из записей всех систем собираются объекты, которыми думает бизнес: клиент, сделка, заказ, товар, склад, договор, платёж, сотрудник, поставщик.
Один объект собран из нескольких систем сразу. Клиент это карточка из CRM, переписка из почты, отгрузки и оплаты из 1С, записи звонков. Всё в одной сущности, а не в четырёх окнах.
Объекты связаны между собой. Клиент связан со сделкой и договором. Заказ с товаром и складом. Платёж с договором и заказом. Поставщик с товаром. Эти связи и есть то, чего не хватало: каждая система хранила свой кусок, а слой хранит отношения между кусками.
На объекте видны сигналы. Заказ, у которого горит срок. Платёж, который просрочен. Сделка, по которой три недели нет движения. Сигнал не надо искать отчётом, он висит на объекте.
Что это даёт в живой работе:
1. «Кто и что обещал клиенту» находится за секунды. Обещание из письма, условие из договора и звонок менеджера лежат в одной карточке.
2. Заказ, у которого горит срок, виден раньше, чем позвонит клиент. Срок из договора, остаток на складе и статус отгрузки сходятся в одном месте.
3. Платёж с просрочкой связан с договором и менеджером. Понятно, кому звонить и на что ссылаться.
4. Остаток на складе виден в карточке заказа. Менеджер не пишет кладовщику в чат.
Верхний слой: решения
На объектах работают три вещи.
Аналитика. Дашборды строятся по объектам, а не по таблицам. Не «выгрузка из 1С за квартал», а «все заказы с просроченным сроком по этому клиенту».
Процессы. Действие одной кнопкой. Например «выставить счёт»: ИИ-агент собирает данные из заказа и договора, готовит документ, человек проверяет и подтверждает. Агент предлагает, человек решает.
Интеграции. Результат уходит обратно в 1С и CRM, в чаты руководителей, партнёрам и клиентам через API. Слой не становится ещё одним окном, в которое надо заходить.
Что меняется для руководителя
Первое. Вопрос к бизнесу задаётся один раз и в понятных словах. «Какие клиенты должны нам больше месяца и кто из менеджеров их ведёт» это один запрос к слою, а не задание аналитику на два дня.
Второе. Новая задача не начинается с нуля. Когда модель объектов есть, новое приложение не начинается с согласования доступа к десяткам баз. Оно строится на готовых объектах. Хотите контроль дебиторки, потом контроль сроков поставки, потом сводку по поставщикам: каждая следующая задача дешевле предыдущей, потому что объекты уже собраны.
Третье. Права доступа едут вместе с данными. Два сотрудника открывают одно окно и законно видят разное: менеджер свои сделки, руководитель отдела все. Каждое действие пишется в журнал. Кто что посмотрел и что изменил, видно всегда.
Четвёртое. ИИ-агент работает через разрешённые действия над объектами, а не получает полный доступ ко всем базам. Агент может «выставить счёт» или «напомнить о платеже», но не может «прочитать всю базу 1С». Это принципиально. Модель ИИ взаимозаменяема, сегодня одна, завтра другая. Сложная часть не в модели, а в том, чтобы подключить модель к надёжным данным и ограничить, что агенту можно делать. Интерфейс (карты, таблицы, дашборды) повторить легко, самое трудное находится под ним. Именно по этому признаку я советую проверять любого подрядчика, три правила Palantir описал отдельно.
На этом слое у нас работает цифровое подразделение: управляющий агент в рабочих чатах и агенты по отделам. Без слоя объектов агенты слепые: они видят только ту систему, к которой их подключили. Со слоем они видят бизнес.
Чего слой не делает
Честно про границы, чтобы не было завышенных ожиданий.
Не заменяет системы. 1С остаётся 1С, CRM остаётся CRM. Если вам не нравится ваша CRM, слой не решит эту проблему, он только сделает данные оттуда доступными вместе с остальными.
Не распоряжается деньгами и не подписывает документы без человека. Агент готовит счёт, платёжку или письмо. Подтверждает человек. Это не временное ограничение, а правило.
Не открывает сотруднику то, к чему у него нет доступа. Права настраиваются на объектах по тем же правилам, что действуют в исходных системах. Если менеджер не видит зарплаты в 1С, он не увидит их и в слое.
Не чинит бизнес-процесс, которого нет. Если заказ проходит через пять человек и никто не знает, кто за что отвечает, слой покажет это очень наглядно. Но решение всё равно принимать вам.
С чего начать
Не с «внедрить ИИ во всю компанию». Мы начинаем с одного процесса, где потери считаются в часах и деньгах. Дебиторка, сроки отгрузки, обработка заявок, сверка с поставщиками. Один процесс, понятная метрика, замер до и после.
Условия такие. Пилот на одном процессе стоит от 40 000 рублей разово. Без абонплаты и без оплаты за токены. Запуск от 3 до 5 дней с момента получения доступов. Результат замеряем до и после, чтобы решение о продолжении принималось по цифрам, а не по ощущениям.
Данные компании могут оставаться на вашем сервере. Как устроена своя AI-система на сервере компании, разобрал в отдельной статье.
Дальше, если пилот показал результат, подключаем следующий процесс. Объекты, собранные для первого, остаются и работают на второй.
Частые вопросы
Нужно ли менять 1С или CRM?
Что если данные грязные: дубли клиентов, пустые поля, разные написания?
Где хранятся данные?
Сколько стоит и сколько занимает?
Чем это отличается от обычной интеграции или BI?
Если хотите понять, какой процесс в вашей компании взять первым, напишите в бот @solaris_access_bot. Он пришлёт чек-лист «12 вопросов перед внедрением ИИ» и предложит разбор вашей задачи на 20 минут. За эти 20 минут определим, где лежат ваши данные и какой процесс даст результат первым.