# Инструменты ИИ для бухгалтерии требуют контроля

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

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

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

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

## Доверяйте задаче, а не ярлыку «ИИ»

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

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

Документация Intuit для QuickBooks хорошо показывает разницу. Страница банковских операций с ИИ предлагает соответствия и категории на основе банковского описания и прошлых операций. Review Signals показывают, насколько предложение опирается на историю, а в процессе Ready to post компания все равно задает обязательные поля и проверяет пакет перед проведением. Xero описывает похожую схему: банковские правила, прежние сверки и данные выписки формируют предложения, а бета-версия JAX автоматически сверяет операцию только при высокой уверенности. Это заявления о процессе, а не доказательство правильного бухгалтерского вывода.

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

Уровень полномочий должен зависеть от задачи:

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

## Процент точности скрывает дорогие ошибки

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

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

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

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

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

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

## Проведите границу до подключения счетов

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

Я делю работу на четыре контура. В контур A входят однозначные обратимые действия: импорт банковской ленты только для чтения, обнаружение точного дубля и прикрепление первичного документа. В контуре B находятся стабильные предложения с небольшим влиянием, например отнесение регулярной подписки на уже утвержденный счет в ожидаемом диапазоне суммы. Контур C содержит неоднозначные или существенные операции, которым нужно явное одобрение. Контур D охватывает действия, которые бухгалтерский слой не выполняет никогда: изменение плана счетов, выбор налоговой позиции, проведение нетипичных журналов, отправка платежей и закрытие периода.

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

```yaml
automation_policy:
  auto_post:
    allowed_accounts: [software_expense, bank_fees]
    max_amount: 500
    require_known_vendor: true
    require_source_document: true
  always_review:
    - transfers
    - split_transactions
    - new_vendors
    - sales_tax
    - payroll
    - owner_transactions
    - fixed_assets
    - journal_entries
  stop_conditions:
    missing_bank_days: 1
    duplicate_source_id: true
    closed_period_change: true
```

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

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

## Банковская сверка не сводится к зеленому значку

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

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

Проводите сверку по слоям. Сначала проверьте полноту ленты: начальный остаток с учетом всех загруженных поступлений и списаний должен привести к конечному остатку выписки после известных временных разниц. Затем проверьте связи: платежи должны соответствовать нужным счетам поставщиков, счетам покупателям, поступлениям или переводам, а не только совпадать по сумме. Наконец проверьте классификацию: убедитесь, что связанная операция попала на нужный счет, в нужный период, аналитический разрез и налоговый код. Каждый слой отвечает на свой вопрос.

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

Налоговая служба США проводит близкую мысль в Publication 583. Электронные записи должны оставаться полными, точными, доступными для получения и достаточно подробными, чтобы найти исходные документы. Там же сказано, что сам факт оплаты не подтверждает право на налоговый вычет. Сопоставленная банковская строка доказывает движение денег. Счет, чек, договор и деловая цель объясняют, почему запись уместна.

## Бухгалтер проверяет исключения и документы, а не каждый клик

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

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

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

Для закрытия месяца проверяющему нужен другой пакет:

1. Убедиться, что период каждой банковской и карточной выписки загружен полностью.
2. Проверить расхождения сверки и старые незакрытые позиции.
3. Просмотреть балансовые счета, а не только отчет о прибылях и убытках.
4. Проверить существенные и чувствительные к политике записи вместе с первичными документами.
5. После корректировок закрыть период и сохранить подтверждение.

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

В материалах AICPA и CIMA об ИИ сказано, что ИИ может повышать эффективность и помогать проверять результаты, но не заменяет профессиональное суждение. Именно так и стоит строить работу. Бухгалтер отвечает за политику и схему проверки, а программа собирает документы и сокращает очередь.

## История изменений должна пережить исправление

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

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

Минимальная запись события может выглядеть так:

```json
{
  "event": "booking_reviewed",
  "source_id": "bank_8f31",
  "proposal": {"account": "software_expense", "amount": 2400},
  "decision": "edited",
  "final": {"account": "prepaid_expense", "amount": 2400},
  "reason_code": "annual_contract",
  "reviewer_role": "controller",
  "policy_version": "2026-04"
}
```

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

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

## После ошибки сначала остановите процесс

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

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

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

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

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

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

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

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

## Проверяйте на неудобных операциях до запуска

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

Соберите набор хотя бы из 40-60 обычных и провокационных операций. Включите одного поставщика с двумя вариантами учета, два счета на одинаковую сумму, частичную оплату, одну банковскую строку по нескольким счетам, возврат за вычетом комиссий, перевод между подключенными счетами, кредит-ноту, иностранную валюту, налог с продаж, покупку собственника, годовой договор с предоплатой, основное средство, списание по зарплате и повторный чек. Добавьте пропущенный день банковской ленты и счет, где итог не совпадает с суммой строк.

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

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

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

## Покупайте средства контроля, а не умные ответы

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

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

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

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

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

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

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

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

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

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

## Основатель отвечает за систему, бухгалтер за суждение

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

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

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

Team & AI Audit может разобрать эту работу вместе с остальными процессами команды, но первым результатом все равно должны стать границы и схема проверки, а не обещание убрать бухгалтера. Хорошая автоматизация оставляет бухгалтеру меньше решений, но лучше их готовит, а основателю дает доказательства, что учету можно доверять.

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