Почему ИИ ошибается в финансовых задачах: дело не только в модели

Мне кажется, здесь до сих пор есть большая проблема ожиданий. ИИ часто воспринимают как смесь калькулятора и огромной цифровой библиотеки: будто внутри уже лежат правильные ответы, от бухгалтерских правил до древнего эпоса, а модель лишь находит нужный.

LLM работает совсем не так. В упрощенном виде она генерирует наиболее вероятное продолжение текста с учетом запроса и доступного контекста.

Это ближе не к поиску нужной страницы в энциклопедии, а к построению ответа шаг за шагом. Если в контексте не хватает факта или правила, модель не обязана остановиться на этом месте и может продолжить цепочку наиболее правдоподобным образом.

Поэтому ошибка часто выглядит убедительно: терминология правильная, объяснение логичное, формула знакомая. Но исходная предпосылка может быть неверной.
В финансах это особенно чувствительно: ошибка может попасть не в текст, а в расчет, трактовку операции или нормативный вывод.

Бюджетная задача часто уже хорошо структурирована в самом вопросе. Известны исходные показатели (3 миллиона, 2 сотрудника), период (на год) и сценарий (оптимальный и радужный). Значительную часть финансовой логики человек задает заранее, а модель перебирает варианты по заданным условиям и объясняет результат.

С фактическим учетом дела обстоят иначе. Банковский платеж самим фактом своего существования не сообщает, относится ли он к расходам этого периода, является ли авансом или к какому проекту относится. Этого достаточно, чтобы одинаковая операция по-разному повлияла на управленческий результат.

Если правил нет в исходных данных, ИИ приходится заполнять пробелы предположениями.

В таком случае на первый план выходит: что именно получает ИИ на входе?
Сырые банковские операции, Excel-файл и бухгалтерские документы? Или подготовленный финансовый контекст, где уже определены статьи, проекты и рассчитанные показатели?

Разница принципиальная. В первом случае модели приходится не только анализировать результат. Ей еще нужно определить правила классификации, выбрать данные для расчета и понять, как трактовать получившиеся цифры. Таким образом каждый следующий шаг цепочки зависит от результата предыдущего. Ошибка в начале рассуждений может привести к вполне логичному объяснению неправильного результата в каждом последующем этапе.

Интеграция помогает не потому, что сама LLM внезапно становится точнее. Меняется объем работы, который ей приходится выполнять самостоятельно.

Если финансовая система уже рассчитала выручку, расходы по статьям и показатели по проектам, ИИ получает известную структуру вместо россыпи операций. Его задачей становится анализ этой структуры, а не восстановление управленческого учета с нуля.

И это не наша локальная теория. Microsoft в документации Copilot для Power BI отдельно рекомендует готовить семантическую модель данных к работе с ИИ. То есть заранее описать структуру данных, связи между показателями и бизнес-смысл полей, чтобы ИИ понимал, с чем работает. Без подготовки Copilot может давать менее полезные и неточные результаты. Для этого Microsoft предлагает сокращать доступную AI-схему, задавать бизнес-контекст через AI instructions и использовать проверку для важных вопросов.

Получается показательный сдвиг. Даже у Microsoft задача уже звучит не как «дайте Copilot доступ ко всем вашим данным».

Сначала данные, потом AI
Разобрали, как подготовить финансовый контур внутри 1С и что можно делать с данными дальше.

Хороший источник данных снимает часть проблем, но не меняет природу модели. ИИ может неверно понять вопрос, выбрать не тот показатель или слишком уверенно интерпретировать неполные данные. Microsoft отдельно предупреждает, что ответы Copilot недетерминированы: при одинаковом запросе и одинаковом grounding-контексте результаты могут различаться. Это прямо указано в документации Microsoft по подготовке модели для Copilot.

Отсюда выводим одно рабочее правило: система считает → ИИ анализирует → человек проверяет источник вывода.

Не потому, что человеку нужно пересчитывать все вручную за нейронкой, но важный управленческий вывод должен всегда вести обратно к данным, на которых он основан!

Когда нейросеть подключается к реальному учету, вопрос безопасности становится очень предметным. В контексте могут оказаться платежи, договоры и зарплаты. Это уже не абстрактный «набор данных», а чувствительная часть финансовой модели бизнеса.

Поэтому до подключения внешнего ИИ важно понять три вещи: что именно ему передается, где данные обрабатываются и действительно ли модель должна видеть их в исходном виде.

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

Поэтому принцип безопасности шире: ИИ должен получать только тот объем данных, который нужен для конкретной задачи.

Есть еще одна важная грань безопасности: ИИ только читает финансовые данные или может их менять? Во втором случае нужны уже не только ограничения доступа к информации, но и права на действия, подтверждения и журнал изменений. Риск передачи финансовой информации и проблему плохих исходных данных мы подробнее разбирали в статье «6 проблем AI в управленческом учете».

Его сильная роль начинается там, где финансовый контекст уже подготовлен. AI может быстрее находить отклонения, сравнивать периоды и объяснять готовые показатели. То есть помогать работать с финансовой системой, а не заново создавать ее внутри каждого запроса.

Учетная система отвечает за финансовую модель и воспроизводимый расчет. ИИ - инструмент, и дает новый способ работать с этими данными.

И здесь начинается самое интересное.

Финансовые сервисы уже пошли по разным путям. Adesk развивает встроенного AI-агента. ПланФакт дает внешним агентам доступ к финансовым данным через API. БИТ. ФИНАНС позволяет выбирать модель и уже добавил механизм анонимизации данных перед отправкой в ИИ.

На поверхности все это называется «ИИ в финансовом учете», но архитектура совершенно разная. Где находятся исходные данные? Кто считает показатели? Какой объем информации получает модель? Можно ли заменить сам AI? Это уже не сравнение красивых AI-кнопок, а вполне практический выбор финансовой архитектуры.

Именно этому будет посвящен следующий материал. Разберем Adesk AI, ПланФакт, БИТ. ФИНАНС, Финоко, Финолог и другие решения по документации: как устроен доступ к данным, где стоят ограничения и что остается на стороне клиента.

А после сравнения останется еще один вопрос, особенно важный для компаний, у которых учет уже находится в 1С: нужно ли переносить финансовый контур в другой сервис ради ИИ или можно подключить выбранную компанией модель к уже подготовленным данным и снизить риск ошибок интерпретации? Это будет следующий шаг.

Что почитать дальше

Подробнее о качестве исходных данных и ограничениях контекста — «6 проблем AI в управленческом учете».

А о том, почему сначала нужен сам финансовый контур, а уже после него AI-анализ, — «ИИ в финансовом учете: почему нейросеть не спасет прибыль, если у вас хаос в данных».