Задача: видеть всех кандидатов, а не каждого третьего
Типовой заказчик — компания с регулярным наймом: десятки вакансий в месяц, на массовые позиции — сотни откликов. Рекрутер просматривает резюме по 20–30 секунд и неизбежно пропускает подходящих; обратная связь кандидатам запаздывает, а «отказ без объяснения» бьёт по бренду работодателя. Задача: автоматизировать первичный отбор так, чтобы каждый отклик был разобран по единым критериям, а рекрутер получал шортлист с обоснованием каждого кандидата.
Скрытое требование — управляемость критериев. «Подходит нам» у разных нанимающих менеджеров различается; скоринг обязан опираться на явные требования вакансии, которые редактируются людьми, а не на «ощущения модели».
Почему это сложно
Первая сложность — разнородность резюме: PDF, сканы, выгрузки джоб-бордов, самописные макеты; в одном документе — и навыки, и опыт, и «около-IT-юмор»; без надёжного парсинга скоринг считать не по чему. Вторая — правовая рамка жёстче, чем в большинстве ИИ-проектов: резюме — персональные данные кандидатов (152-ФЗ), а решение по кандидату не должно опираться на возраст, пол, регион и другие защищённые признаки — это и этика, и действующее трудовое законодательство. Третья — объяснимость: «модель так решила» не работает ни для рекрутера, ни для кандидата, ни для юристов; каждое решение должно раскладываться в критерии. Четвёртая — сроки жизни данных: резюме нельзя хранить вечно «на всякий случай» — нужна политика хранения и удаления.
Архитектура: профиль → матчинг → шортлист
Архитектура контура скрининга резюме (текстовая схема)
Отклики: джоб-борды · почта · карьерный сайт (PDF / DOCX / сканы)
│ OCR для сканов
▼
Парсинг резюме → структурированный профиль (строгий JSON):
опыт по годам и стекам · отрасли · проекты · образование · языки
(защищённые признаки: возраст/пол/регион — НЕ извлекаются)
▼
Матчинг с требованиями вакансии (редактируется нанимающим менеджером):
семантическое сравнение через эмбеддинги + правило «обязательный критерий»
▼
Скоринг с обоснованием: «совпадения по 7 из 9 критериев, гэп — X»
▼
Шортлист + обратная связь кандидату (черновик рекрутеру)
▼
Хранение ПДн: локальный контур · сроки · удаление по регламенту
Модели: локальный LLM (Ollama) — ПДн не покидают контур компании
Инженерное ядро. Парсинг и матчинг идут через структурированные выходы LLM — профиль кандидата это строгая схема, а не «текст о тексте». Семантическое сравнение профилей с формулировками вакансий построено на эмбеддингах русского языка — они ловят «DevOps» и «инженер по эксплуатации инфраструктуры» как близкие сущности. Всё это работает на локальной модели через Ollama: резюме не отправляются во внешние API — это принципиальное требование 152-ФЗ-контура. Фильтры против утечки чувствительных признаков и контроля поведения модели — по практикам «Guardrails-фреймворков для LLM».
Этапы внедрения
| Этап | Что получается | Бюджет | Срок |
|---|---|---|---|
| Аудит процессов найма и ПДн | карта источников откликов, требования вакансий, политика ПДн, план метрик | от 90 000 ₽ | 1–2 недели |
| Пилот на одной роли | скрининг по 2–3 вакансиям одного профиля, сравнение шортлиста с решениями рекрутеров | от 480 000 ₽ | 4–6 недель |
| Промышленный контур | все роли, интеграция с ATS/HRM, обратная связь кандидатам, отчётность | 0,9–1,2 млн ₽ | по ТЗ |
| Сопровождение | обновление критериев, контроль качества матчинга, аудит ПДн-политик | по регламенту | — |
Бюджеты — прайс НЬЮ-ССТ на сентябрь 2026, «от», без НДС (УСН, п. 2 ст. 346.11 НК РФ). Сроки — типовые вилки проектов этого класса.
Типовые метрики «до/после»
Ниже — типовые вилки результатов внедрений ИИ-скрининга этого класса, а не отчёт конкретной компании. Базовая линия замеряется до старта: время первичного просмотра, доля откликов, реально разобранных рекрутером, время выхода на шортлист.
- Время первичного отбора: типовое снижение на 50–80% на массовых позициях.
- Охват откликов: 100% резюме оценены по единым критериям — вместо выборочного просмотра 30–50% потока.
- Время до шортлиста: −30–60%; кандидат получает реакцию в первые дни, а не недели.
- Согласованность оценок: единые критерии устраняют «разброс» между рекрутерами — типовой рост согласованности решений на 20–40%.
- Скорость обратной связи: черновики ответов кандидатам — минуты вместо отложенной ручной рассылки.
152-ФЗ и антидискриминация: рамка, а не приложение
В HR-скрининге правовая рамка определяет архитектуру. Персональные данные кандидатов: обработка на законном основании ( отклик на вакансию), минимизация состава, локальный контур без внешних API, сроки хранения и удаление по регламенту, журнал доступа. Антидискриминационные ограничения: защищённые признаки (возраст, пол, национальность, регион и подобные) не извлекаются и не участвуют в скоринге — модель видит профессиональный профиль, а не человека. И финальная граница: решение о приглашении и отказе принимает человек; система — инструмент приоритизации, юридически значимые коммуникации подписывает рекрутер. Такой контур проще аттестуется, легче принимается командой и кандидатами — и его не стыдно показать юристам.
Об этом разборе. Это обезличенное типовое внедрение из нашей практики проектирования: имена компаний не раскрываются (NDA), метрики даны типовыми вилками класса проектов; фактические значения фиксируются в КП и на приёмке. Скоринг объясним по критериям вакансии — «чёрный ящик» в найме мы не поставляем.