Где таблицы действительно просят помощи

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

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

Почему «прочитать значения» не всегда означает «увидеть расчёт»

В формате Excel формула и её последний рассчитанный результат хранятся отдельно. Документация Microsoft описывает формулу в элементе `f`, а сохранённое значение — в `v`; оно относится к последнему пересчёту. Документация openpyxl поясняет, что режим `data_only` отдаёт сохранённое значение, а не заново вычисляет формулу. Если книгу давно не пересчитывали, такой результат может устареть. Microsoft также указывает, что Excel умеет автоматический и ручной режимы пересчёта.

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

Безопасная схема из пяти частей

1. **Источник и снимок.** Заберите утверждённую версию файла из известного места, сохраните её копию и контрольную сумму. Зафиксируйте время, владельца, имя листа и диапазон. Если книга меняется параллельно, старый снимок нельзя молча записывать поверх новой версии.
2. **Подготовка входа.** Выделите только нужные столбцы и строки. Каждой строке дайте устойчивый ID, отдельно отметьте формульные и защищённые поля. Персональные сведения и лишние листы не отправляйте модели даже в локальном контуре без необходимости.
3. **Предложения модели.** Попросите вернуть структурированный список: ID строки, поле, старое значение, предлагаемое значение, причина и уровень уверенности. Сервер локального вывода, например llama.cpp, поддерживает ограничение формата ответа JSON-схемой. Это помогает парсеру, но не доказывает правильность содержания.
4. **Проверка и согласование.** Детерминированный код проверяет типы, диапазоны, справочники, обязательные поля, допустимые переходы и неизменность формул. Человек видит сравнение «было → предлагается» и принимает либо отклоняет каждую группу правок. Для цены или платёжных реквизитов можно установить отдельный порог и второго согласующего.
5. **Применение и аудит.** Изменения сначала пишутся в копию. Её открывают и пересчитывают в том табличном движке, который использует компания; сравнивают контрольные итоги и формулы, затем публикуют новую версию. Журнал хранит ID исходной версии, запрос, ответ, проверки, решение сотрудника и итоговый файл. Возможность отката проверяют до запуска.

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

Что проверить на пилоте

Возьмите один повторяемый сценарий — например, классификацию 100–200 строк заявок или поиск несовпадений номенклатуры. Это не обещание производительности, а удобный размер контрольной выборки. Включите пустые ячейки, дубли, неоднозначные названия, отрицательные суммы, формулы, ручной режим пересчёта и устаревшую копию файла. Зафиксируйте эталонные решения специалиста до запуска модели.

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

Экономика без магии

Считайте полный процесс. Модельный пример: при 1 000 строк в месяц и 40 секундах ручной проверки каждой строки исходная работа занимает около 11 часов. Если ИИ уверенно предлагает варианты для 70% строк, но на утверждение каждой экономится только 20 секунд, потенциальная экономия — около 3,9 часа в месяц до учёта подготовки данных, проверок и сопровождения. Эти числа — допущения, а не результат внедрения. Подставьте своё время, долю принятых предложений и стоимость ошибки.

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

С чего начать руководителю

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