ИИ-налоговый консультант: учимся на отказах

Человек, который ищет ИИ-налогового консультанта, обычно хочет меньше налоговой рутины, а не ещё одно окно чата. Ему нужна программа, способная собрать документы, понять бухгалтерские записи, подготовить декларацию и ясно показать, где всё ещё требуется решение.

Рынок движется именно в эту сторону. 5 августа 2026 года Basis представила комплексную налоговую платформу, которая охватывает сбор данных, подготовку и проверку, а бухгалтер подключается там, где требуется профессиональное суждение. 20 августа Thomson Reuters описала ИИ-ориентированную подготовку налогов как переход от ручной сборки каждой декларации к проверке готового первого прохода.

Я согласен с этим направлением. Однако выражение «ИИ-налоговый консультант» всё ещё может означать два совершенно разных продукта. Один отвечает на вопросы убедительным языком. Второй строит декларацию из доказательств, выполняет расчёт через настоящую налоговую логику, передаёт точный пакет официальному валидатору и останавливается, если факты или правила не позволяют идти дальше.

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

Что такое ИИ-налоговый консультант?

ИИ-налоговый консультант не является одной функцией. Это рабочий процесс как минимум с четырьмя разными обязанностями:

1. собрать доказательства из документов, бухгалтерских записей и прошлых деклараций;
2. перенести их в типизированные налоговые поля и детерминированные расчёты;
3. выполнить проверки согласованности и официальные правила;
4. показать проверяемый результат, отделив открытые вопросы от подтверждённых фактов.

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

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

Разделение также не даёт слову «консультант» превратиться в вводящее в заблуждение обещание. Программа может готовить, сверять и поднимать вопросы. Индивидуальный налоговый совет требует фактов, профессионального суждения и ответственности, которых нет у общего диалога. Эта статья о границе программы, а не о налоговой консультации.

Почему чата недостаточно для подготовки налогов?

Чат хорошо запускает работу. Пользователь может сказать: «Подготовь декларацию по НДС за прошлый квартал». Система определит период, соберёт операции и объяснит, каких данных не хватает. Ошибка начинается тогда, когда сама переписка становится учётной записью.

Для налоговой подачи нужны устойчивые идентификаторы, периоды, суммы, налоговая обработка, ссылки на источники и воспроизводимый расчёт. Нужен и точный статус: проект, проверено, подтверждено, отправлено или отклонено. Ничто из этого не должно меняться из-за иной интерпретации следующего сообщения.

Рынок приходит к тому же выводу. В августовском описании Thomson Reuters отдельно стоят сбор, подготовка, проверка и подача. Basis заявляет, что её агенты завершают первый проход, а бухгалтер может изучить каждый шаг и контролировать каждое решение. Это важнее улучшенного поля ответа, потому что единицей работы становится проверяемая декларация, а не сообщение.

У вопроса «Можно ли подать декларацию через ИИ-ассистента?» в Германии похожий ответ. Наш разбор ELSTER и MCP показывает, почему последний шаг не сводится к обычному вызову инструмента. Подача должна пройти официальный путь проверки, использовать обязательную инфраструктуру передачи и отделять подтверждение от подготовки.

Чему учат отказы в производственном процессе?

Norman записывает коды правил, которые возвращаются, когда официальный валидатор отклоняет предварительную проверку или отправку налогового отчёта. Производственный цикл классифицирует каждый результат до того, как он повлияет на процесс. Он определяет, может ли податель исправить структурированные данные, нужно ли менять наше сопоставление или ответ пока остаётся неизвестным.

Это различие принципиально. Отказ не означает автоматически ошибку модели, пользователя или продукта. Это свидетельство от системы, которая решает, допустима ли структура декларации. Категория «неизвестно» остаётся явной: мы не превращаем любой ответ в успокаивающее объяснение.

Именно это разделение стало главным уроком. Полезная система должна по-разному обрабатывать два класса ошибок:

• недостающий или противоречивый пользовательский факт становится конкретной задачей у нужного поля;
• неподдерживаемое сопоставление становится инженерной находкой и регрессионным тестом;
• незнакомый отказ сохраняет блокировку, а не превращается в догадку;
• исходный ответ официального валидатора остаётся основанием следующего действия.

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

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

Что должен автоматизировать налоговый ИИ-процесс?

Правильная граница видна лучше, если разделить обязанности.

Система должна автоматизировать повторяющуюся сборку, а не скрывать неопределённость. Она может сверять известные итоги, находить недостающие документы, заранее заполнять стабильные поля и создавать короткую очередь проверки. Она не должна придумывать налоговый номер, выбирать между конфликтующими правовыми трактовками или незаметно менять уже подтверждённый пакет.

Тот же стандарт мы использовали, когда проверяли, может ли ИИ подготовить полную годовую отчётность GmbH. Значимым тестом было не объяснение годового закрытия. Важным стало совпадение готовых сальдо до цента с результатом, который профессионал подготовил и подал.

Где человек должен остаться в процессе?

Фраза «человек в контуре» слишком расплывчата, если продукт не называет человека, шаг и доступные ему доказательства.

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

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

Граница может сдвигаться по мере накопления доказательств. Узкий повторяемый случай заслуживает больше автоматической обработки после тестов на истории и наблюдения в производстве. Новая юрисдикция, форма или необычная операция остаётся в консервативном режиме, пока её ошибки не изучены. «Автономность» должна описывать измеренное покрытие, а не общий переключатель.

Как оценивать налоговую ИИ-программу?

Начните с завершённых исторических случаев, включая те, которые привели к исправлениям. Уберите финальный ответ и попросите продукт собрать доказательства, подготовить декларацию и назвать блокировки. Затем сравните результат с тем, что действительно было проверено и подано.

Измеряйте как минимум пять показателей:

• долю подтверждённых полей, которые дошли до проекта без изменений;
• недостающие доказательства, найденные до проверки;
• ложные подтверждения, при которых система продвинула бы неверный результат;
• отказы официального валидатора и ясность их маршрутизации;
• время проверяющего на реальные решения, а не на восстановление контекста.

Проверьте и восстановление после ошибки. Показывает ли система точный пакет, который не прошёл проверку? Создаёт ли исправление новое состояние проверки? Доказывает ли повторная попытка, что не возникнет дублирующая подача? Сохраняются ли поданные доказательства после изменения текущей бухгалтерии?

Инвестиционный мотив уже заметен. В обзоре исследования за август 2026 года Thomson Reuters сообщила, что 57 процентов налоговых специалистов назвали ИИ главным технологическим приоритетом. Важнее требования к доверию: 94 процента хотели опоры на авторитетные источники, а 90 процентов требовали объяснимого и защищаемого обоснования.

Такому стандарту должен соответствовать ИИ-налоговый консультант. Продукту не нужно звучать как специалист. Он должен выдавать первый проход, который специалист или ответственный податель сможет проверить, валидировать и подтвердить с меньшими усилиями. Наш цикл работы с отказами показал, что официальное «нет» не является краевым случаем, который следует сгладить. Это доказательство, и производственная налоговая автоматизация становится лучше только тогда, когда учится на нём.