Как выбрать подрядчика по внедрению ИИ и не потерять бюджет

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

Сергей Езепенко · 13.11.2026 · время чтения 17 мин

С какими задачами вообще идут к внешнему подрядчику

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

Три типовые категории, с которыми приходят чаще всего.

1. Классификация обращений. Заявки, письма, тикеты поддержки, отзывы нужно разложить по темам, срочности, филиалам или типам клиентов. Если в месяц обращений сотни, это делается правилами и руками. Если десятки тысяч и разметка неоднородная — нужна модель, а к ней pipeline: приём, нормализация текста, хранение версий, переобучение на новых примерах.
2. Извлечение данных из документов. Счета, накладные, договоры, анкеты, сканы паспортов. Бизнес хочет получать структурированные поля в учётной системе, а не PDF в папке. Здесь работа — не только модель распознавания, но и обработка брака: повёрнутые сканы, рукописные правки, отсутствующие поля. На практике 20–30% документов требуют отдельного сценария.
3. Прогноз спроса и планирование. Прогноз продаж по SKU, загрузки склада, потребности в сменах. Задача почти всегда упирается не в алгоритм, а в качество исторических данных: сезонность, промо, выбывшие товары, смены ассортимента. Подрядчик, который берётся за прогноз без аудита данных, приносит красивый график и разочарование через месяц.

Внешний подрядчик нужен в первую очередь там, где внутри нет своих ML-инженеров и дата-инженеров. Это не про «нет айтишников» — админы и разработчики CRM обычно есть. Речь о людях, которые умеют готовить датасеты, обучать и валидировать модели, настраивать мониторинг качества и объяснять, почему метрика на проде просела. Найм такого специалиста в штат для одной задачи — дорого и долго: поиск занимает 2–4 месяца, зарплата в рынке — от 250 тыс. руб. в месяц, и после запуска он может заскучать. Подрядчик закрывает компетенцию на время проекта.

Обратная ситуация тоже встречается регулярно. Классификация по десяти категориям, суммаризация писем, простой чат по базе знаний — это задачи на готовых API, где основная работа — интеграция и промпт-инжиниринг. Их дешевле и быстрее решать своей командой разработки, без внешнего контракта. Если подрядчик предлагает обучать модель с нуля там, где хватает вызова готового API, — это повод задать вопросы про смету. Про смежный сценарий — AI-консультант на сайте: как чат-бот увеличивает конверсию в 2-3 раза — полезно прочитать до разговора с подрядчиком, чтобы понимать границы между «ботом» и «моделью».

Пример из практики. Оптовая компания пришла с задачей «автоматизировать разбор заявок от клиентов». В заявках — текст в свободной форме, вложения и Excel-файлы. Внутри была команда из двух разработчиков на 1С и Python. Подрядчик предложил разделить поток: письма без вложений — на готовый API классификации, файлы — на отдельный сервис извлечения полей с ручной проверкой спорных. Проект занял 7 недель вместо заявленных изначально 4 месяцев на «полноценную ML-платформу», и это оказалось дешевле почти втрое.

Чем интегратор ИИ отличается от студии и фрилансера

На рынке под одним словом «подрядчик» стоят три разных типа исполнителей, и разница проявляется не в презентации, а в том, что происходит через три месяца после сдачи.

Интегратор отвечает за внедрение в процессы и поддержку. Его результат — не модель в репозитории, а работающий участок процесса: заявка из формы попадает в модель, результат уходит в CRM, спорные случаи падают на ручную проверку конкретному сотруднику, есть дашборд с качеством и алерты при деградации. В договоре фигурируют SLA на доступность, регламент обновления модели, порядок эскалации инцидентов. Интегратор обычно работает с существующим стеком заказчика — 1С, Bitrix24, amoCRM, собственной ERP — и не требует всё переписать.

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

Фрилансер дешевле, но риск остаться один на один с системой выше. Один ML-инженер или разработчик может собрать прототип за 2–3 недели и за небольшие деньги. Вопросы начинаются при передаче: документация часто минимальная, окружение настроено только на его машине, ключи от API оформлены на него. Если человек уходит в другой проект — а на фрилансе это норма, — поддержка ложится на вашу команду, у которой нет контекста. Это управляемый риск, если у вас есть кому подхватить, и неуправляемый, если нет.

Как выбирать под задачу, а не под вывеску:

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

Отдельно стоит смотреть на формулировки в договоре. «Обучение модели» и «внедрение и сопровождение модели в процессе» — это разные объёмы работ и разные деньги. Про порядок цен полезно свериться с материалом Сколько стоит внедрить ИИ-агента в бизнес в 2026 году, чтобы на переговорах понимать вилки по рынку.

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

Какие кейсы считать подтверждёнными

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

Просите метрику в формате «было — стало — за какой срок». Не «ускорили обработку заявок», а «обработка заявки занимала в среднем 18 минут, стала 4 минуты, замер на выборке 2 000 обращений за март и май». Не «снизили нагрузку на поддержку», а «доля типовых тикетов, закрытых без оператора, выросла с 12% до 41%, при этом CSAT не упал». Конкретная формулировка сразу отсекает половину подрядчиков: у кого-то нет доступа к данным заказчика, у кого-то проект закрыли до сбора статистики, у кого-то метрика считалась «на глаз».

Отдельно уточняйте базу сравнения. Рост конверсии на 30% после запуска чат-бота может объясняться сезоном, изменением рекламного бюджета или переверсткой страницы. Хороший подрядчик сам скажет, какие факторы могли повлиять и как их исключали: контрольная группа, сравнение с аналогичным периодом прошлого года, поэтапный запуск на части трафика. Если в ответ звучит «мы просто сравнили месяц до и месяц после» — это не кейс, а наблюдение. Подробнее о том, как считать эффект от чат-бота на сайте, разобрано в материале AI-консультант на сайте: как чат-бот увеличивает конверсию в 2-3 раза — там как раз про то, какие метрики смотреть и как их не перепутать с сезонными колебаниями.

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

Третий фильтр — отраслевое совпадение. Кейс в вашей отрасли весит больше, чем десять общих. Причина не в том, что технологии сильно различаются, а в том, что подрядчик уже сталкивался с вашими данными: структурой справочников, качеством выгрузок из 1С, ограничениями по персональным данным, привычками сотрудников. В ритейле и в промышленности одинаковый на вид проект по прогнозированию спроса упирается в разные вещи: в первом случае в акции и промо, во втором — в длинный цикл производства и сезонность поставок. Подрядчик, который прошёл этот путь в вашей отрасли, сэкономит вам месяц-полтора на старте. Если отраслевого кейса нет, просите хотя бы кейс с похожей структурой данных и похожим масштабом — и честно спросите, что подрядчик будет делать иначе.

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

Кто реально будет работать над проектом

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

Защита здесь простая: требуйте имена и роли в приложении к договору. Не «команда из пяти сертифицированных специалистов», а конкретно: Иванов — руководитель проекта, 40% загрузки; Петрова — ведущий инженер по данным, 60%; Сидоров — разработчик, 100%. Плюс резюме на полстраницы и указание, какие задачи каждый закрывает. Это не бюрократия: приложение фиксирует состав команды как обязательство, и его изменение требует вашего согласия. Без такого документа фраза «мы усилим проект нужными людьми» означает что угодно, включая замену ключевого разработчика на стажёра.

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

Спросите прямо, кто пишет код и где он сидит. Варианты ответов: штатные разработчики подрядчика, отдельная команда-партнёр, фрилансеры под задачу, генерация через no-code платформу. Каждый вариант имеет свою цену и свои риски. Штатная команда дороже, но предсказуемее по срокам и передаче знаний. Фрилансеры дешевле, но риск смены человека выше, а документация обычно страдает. No-code ускоряет старт, но привязывает вас к платформе и ограничивает кастомизацию. Ответ «мы соберём команду под проект» означает, что команды ещё нет, и сроки старта — вопрос открытый.

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

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

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

Как устроен нормальный пилот и его сроки

Пилот — это проверка гипотезы на ваших данных, а не демонстрация возможностей подрядчика. Нормальный пилот на исторических данных занимает от 4 до 8 недель. Меньше — почти всегда означает, что вам показывают заранее подготовленный демо-кейс на чужих данных. Больше — признак того, что команда не ограничила задачу или параллельно решает несколько несвязанных.

Срок зависит от трёх вещей: объёма и качества данных, сложности метрики и того, есть ли у подрядчика готовый шаблон под вашу задачу. Типовой пилот для чат-бота поддержки или скоринга заявок укладывается в 5–6 недель. Проекты с распознаванием документов или прогнозированием спроса на разнородных источниках — ближе к 8 неделям, потому что первые 1–2 недели уходят только на разбор данных.

Структура пилота, которую стоит требовать от подрядчика:

1. Неделя 1. Аудит данных: какие есть, в каком виде, чего не хватает. Результат — короткий отчёт и список рисков.
2. Недели 2–3. Базовая модель на исторических данных, черновая метрика. Здесь важно увидеть цифры, а не презентацию.
3. Недели 4–5. Доработка, проверка на отложенной выборке, сравнение с текущим процессом (ручная обработка, старые правила, существующий сервис).
4. Недели 6–8. Прогон на реальном потоке в ограниченном объёме, замер метрики по согласованной методике, отчёт с выводами.

Метрику успеха фиксируйте до старта, письменно, в самом договоре или приложении к нему. Формулировка «повысить качество обслуживания» не годится. Нужна измеримая величина и способ замера: например, «доля обращений, закрытых без передачи оператору, — не ниже 40% на выборке из 500 диалогов за последние 3 месяца» или «средняя абсолютная ошибка прогноза спроса — не выше 12%». Отдельно пропишите, кто и на каких данных считает метрику: подрядчик на своей выборке, вы на своей, или обе стороны независимо и потом сверяют. Последний вариант самый честный.

Бюджет пилота — порядка 10–20% от всего проекта. Если подрядчик просит 40–50% на «исследовательскую фазу», это уже не пилот, а полноценная разработка под видом проверки. Обратная крайность тоже плоха: бесплатный или символически платный пилот почти всегда означает, что вы получите маркетинговый отчёт, а не работающую модель на ваших данных.

Пример из практики: компания из сферы логистики закладывала пилот на 6 недель с метрикой «точность распознавания накладных не ниже 92% на отложенной выборке из 2000 сканов». Подрядчик на третьей неделе предложил считать метрику на данных, которые модель уже видела при обучении. Заказчик отказался, настоял на отложенной выборке — и точность оказалась 84%, а не заявленные 96%. Это сэкономило компании бюджет основного этапа: вместо доработки модели пришлось сначала переделывать процесс загрузки сканов.

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

Что должно быть в договоре и кто владеет моделью

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

В договоре фиксируются письменно четыре объекта:

1. Модель (веса, конфигурация, версия). Укажите, передаётся ли она вам в виде файлов или остаётся на инфраструктуре подрядчика.
2. Данные. Кто их собственник, что подрядчик может с ними делать, обязан ли удалить копии после проекта. Особенно важно, если в данных есть персональные сведения.
3. Код. Всё, что написано под ваш проект: пайплайны обработки, интеграции, скрипты обучения. Лицензия на использование — бессрочная, без ограничения по территории и целям.
4. Права на дообучение. Можете ли вы самостоятельно обновлять модель на новых данных без обращения к подрядчику.

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

Штрафы за сроки и условия расторжения — обязательные пункты, даже если отношения с подрядчиком хорошие. Штраф привязывайте к этапам, а не к финальному сроку: задержка пилота на неделю, задержка сдачи в промышленную эксплуатацию, невыполнение согласованной метрики. Разумная практика — 0,5–1% от стоимости этапа за каждый день просрочки с потолком в 10–15%. Условия расторжения описывают, что происходит с уже созданными артефактами и предоплатой: при расторжении по вашей инициативе вы забираете промежуточные результаты, за которые заплатили; при расторжении по вине подрядчика — возврат части средств.

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

Если выбираете между чат-ботом и более сложным агентом, полезно заранее понять разницу в объёме работ и, соответственно, в том, что именно придётся прописывать в договоре: Чем ИИ-агент отличается от чат-бота и что выбрать бизнесу.

Сколько стоит внедрение и из чего складывается цена

Разброс цен на рынке большой: за «внедрение ИИ» называют и 150 тысяч, и 5 миллионов рублей. Разница не в жадности подрядчиков, а в объёме работ. Чтобы сравнивать предложения, нужна смета, разложенная по статьям, а не одна цифра в коммерческом предложении.

Основа оценки — два параметра. Первый — качество данных. Если у вас есть выгрузка заказов за два года с заполненными полями, проект стартует быстрее. Если данные лежат в трёх системах, часть в Excel, часть в переписке менеджеров, а половина заявок без категории, — начинается работа с данными: аудит, очистка, разметка, сведение справочников. Это может занять от трети до половины бюджета проекта. Второй параметр — число интеграций. Каждое подключение к CRM, 1С, телефонии, складской системе — отдельная задача с ограничениями по доступу, форматам и нагрузке. Одна интеграция — это недели, пять — месяцы.

Считать нужно не цену разработки, а стоимость владения за год-два. В неё входят:

1. Разработка и запуск — постановка задачи, подготовка данных, модель, интеграции, тестирование.
2. Разметка и дообучение. Модель деградирует, когда меняются продукты, цены, формулировки клиентов. Разметку новых примеров кто-то делает: либо ваш сотрудник, либо подрядчик по отдельному тарифу.
3. Инфраструктура. Обучение и работа модели требуют вычислительных ресурсов — облачных или собственных серверов. Для задач на десятки тысяч запросов в месяц это порядка 10–30 тысяч рублей, для обработки документов и изображений — заметно больше.
4. Поддержка и мониторинг. Кто-то должен замечать, что качество ответов упало, и реагировать. Это либо ретейнер подрядчика (в среднем 10–20% стоимости проекта в год), либо ставка инженера в штате.

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

Слишком низкая цена почти всегда означает пилот, а не внедрение. За 100–200 тысяч реально собрать прототип на готовой модели: проверить гипотезу на выборке, показать руководству, что подход работает. Но в такую сумму не помещаются интеграции с учётными системами, регламент работы с ошибками модели, обучение сотрудников и поддержка. Через два-три месяца прототип остаётся в статусе «мы попробовали», потому что им никто не пользуется в ежедневных процессах.

Пример из практики: компания заказала классификацию обращений в поддержку за 180 тысяч. Подрядчик обучил модель на выгрузке из почты, точность на тесте — 87%, акт подписан. В работе выяснилось, что обращения приходят ещё через форму на сайте и мессенджер, а формат там другой. Доработка под эти каналы и интеграция с тикет-системой обошлись ещё в 400 тысяч — то есть дешевле не вышло, просто бюджет растянулся на два этапа.

Просить смету нужно в разрезе этих статей, с указанием, что оплачивается разово, а что ежемесячно. Если подрядчик называет только общую сумму, попросите разбивку — это нормальная просьба, и по реакции многое станет понятно. Ориентиры по бюджету для конкретных сценариев есть в материале Сколько стоит внедрить ИИ-агента в бизнес в 2026 году.

Признаки, при которых стоит отказаться от подрядчика

Отказ на этапе переговоров дешевле, чем разрыв договора через три месяца. Ниже — сигналы, которые в сумме дают достаточное основание не начинать.

Обещают точность 99% до анализа ваших данных. Точность модели зависит от задачи и качества выборки, а не от квалификации продавца. До того как подрядчик посмотрел ваши данные, он может говорить только о диапазоне и условиях: «на похожих задачах получалось 85–92%, финальная цифра зависит от полноты разметки». Если вам называют 99% на встрече, не видя ни одной строки ваших данных, — это либо непонимание темы, либо намеренное упрощение. Отдельно уточняйте, что значит «точность»: доля верных ответов по всем классам, полнота по редким категориям, метрика на отложенной выборке. На несбалансированных данных 99% общего качества может означать, что редкий, но важный класс модель не находит совсем. Попросите назвать метрику, метод её замера и что считается ошибкой.

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

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

Дополнительные сигналы, которые стоит проверить: нет ни одного кейса с измеримым результатом (не «внедрили ИИ», а «сократили время обработки заявки с 15 до 4 минут»); не задают вопросов о ваших процессах и данных, а сразу показывают презентацию; торопят с подписанием из-за «заканчивающегося предложения»; в команде нет человека, отвечающего за данные.

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

Автор: Сергей Езепенко, основатель «Системы Поток». Работаю с клиентами с 2018 года, 20 запущенных проектов: стройка, медицина, юруслуги, недвижимость, онлайн-школы.