Право на ремонт с 2027 года: как производителю организовать выдачу технической документации

С 1 марта 2027 года изготовитель обязан передавать сервисам и продавцам техническую документацию для ремонта. Разбираем, что это означает для ИТ-процессов производителя

С 1 марта 2027 года вступает в силу Федеральный закон от 26.07.2026 № 266-ФЗ, который меняет статью 6 Закона РФ «О защите прав потребителей» [1]. Изготовитель обязан обеспечить организациям и ИП, которые занимаются торговлей, ремонтом и техническим обслуживанием, доступ к информации и технической документации, необходимой для обслуживания и ремонта товара, а также к документации с изменениями, если такие изменения появляются [1][3]. Обязанность действует не только во время производства товара, но и после снятия его с производства — в течение срока службы товара, а если срок не установлен — в течение 10 лет с момента передачи товара потребителю [1].

Порядок, сроки предоставления документации и её состав должно установить Правительство РФ отдельным постановлением [1][3]. На момент подготовки материала подтверждённого проекта такого постановления в открытых источниках найти не удалось — это значит, что часть деталей (форматы, сроки ответа, перечень документов) появится позже, но готовиться к их появлению нужно уже сейчас.

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

В чём проблема и кому она касается

До сих пор передача технической документации сервисным организациям чаще всего была вопросом коммерческих отношений: производитель сам решал, с кем делиться схемами, руководствами и прошивками — обычно только с официальной сервисной сетью. С 2027 года это становится законодательной обязанностью, причём круг получателей явно не ограничен «авторизованными» партнёрами: в законе говорится об организациях и ИП, которые ведут торговую деятельность, ремонт и техническое обслуживание [5][7].

Тема касается:

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

Ключевая практическая сложность в том, что задача — не «выложить документы куда-нибудь», а выдавать нужную версию нужному адресату с доказуемой историей: кто запросил, что получил, когда и на каком основании.

Что именно меняется в законе

Кто обязан выдавать документацию

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

Кому положена документация

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

Как долго действует обязанность

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

• пока товар производится;
• после снятия с производства — в течение установленного срока службы товара;
• если срок службы не установлен — в течение 10 лет со дня передачи товара потребителю [1].

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

Что пока не определено

Порядок, сроки ответа на запрос и точный состав документации должно установить Правительство РФ [1][3]. Пока подзаконный акт не опубликован, нельзя точно сказать:

• в каком формате (бумажном, электронном, через портал) должна выдаваться документация;
• в какой срок производитель обязан ответить на запрос;
• распространяется ли обязанность на программное обеспечение и прошивки в полном объёме или только на часть данных;
• какая ответственность предусмотрена за нарушение новой нормы — отдельного состава об этом в КоАП РФ на момент подготовки статьи не обнаружено.

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

Какие категории технических материалов могут потребоваться сервисам

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

• руководства по ремонту и обслуживанию (service manual);
• электрические и монтажные схемы;
• перечни и коды запасных частей, спецификации совместимости;
• диагностические коды ошибок и инструкции по диагностике;
• версии встроенного программного обеспечения (прошивки) и инструкции по их обновлению;
• сертификаты и данные о партии/серии выпуска, если они влияют на процедуру ремонта;
• бюллетени технического обслуживания и извещения об изменениях в конструкции.

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

Нужен ли отдельный партнёрский портал

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

Отдельный портал имеет смысл, если у производителя:

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

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

Отдельный вопрос — в какой форме организовать сам каталог документации внутри портала. Здесь часто рассматривают два не взаимоисключающих варианта:

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

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

Как подтверждать статус сервисной организации

Закон не описывает механизм проверки статуса получателя — это тоже, вероятно, будет уточнено подзаконным актом. Но в России уже есть готовые инструменты, которые логично туда встроить:

• проверка организации по ЕГРЮЛ/ЕГРИП — базовая проверка, что запрос действительно исходит от существующего юридического лица или ИП, а не от анонимного адреса;
• машиночитаемая доверенность (МЧД) — если документацию запрашивает не руководитель, а сотрудник, его полномочия можно подтвердить МЧД, зарегистрированной в реестре ФНС; статус доверенности проверяется по QR-коду, уникальному идентификатору или ИНН представителя [12][13][14];
• указание вида деятельности — соответствие ОКВЭД или иных признаков тому, что организация действительно занимается торговлей, ремонтом или обслуживанием;
• договор или заявка с приложением подтверждающих документов — для случаев, когда автоматической проверки недостаточно и нужна ручная модерация.

Практический вывод: подтверждение статуса — это не разовая проверка при регистрации, а процесс, который должен переживать смену сотрудников заявителя (МЧД как раз для этого и придумана — она позволяет отзывать полномочия конкретного человека, не трогая доступ организации в целом) [13].

Разграничение доступа к открытым и чувствительным материалам

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

1. Открытые материалы — общие руководства пользователя, базовые инструкции по эксплуатации. Их можно публиковать без регистрации.
2. Материалы для подтверждённых сервисных организаций — схемы, коды ошибок, процедуры ремонта, спецификации запчастей. Выдаются после проверки статуса организации.
3. Чувствительные материалы — данные, которые могут быть связаны с безопасностью, интеллектуальной собственностью или содержать сведения, которые сам производитель не обязан раскрывать по новому закону (например, детали проприетарных алгоритмов прошивки, если это не входит в объём обязательной документации). Такие материалы либо не выдаются вообще, либо выдаются на основании отдельного соглашения.

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

Как вести версии инструкций, схем и прошивок

Задача версионирования технической документации в России не новая — она давно решена в инженерной практике через ГОСТ 2.503, который устанавливает правила внесения изменений в конструкторские, технологические и программные документы [11]. Стандарт описывает, в частности, извещения об изменении (ИИ), предварительные извещения (ПИ) и листы регистрации изменений (ЛР) — по сути, это готовый процессный шаблон для того, чтобы связать изменение документа с датой, причиной и областью действия [11].

Для цифрового процесса выдачи документации это значит, что не нужно изобретать структуру версионирования с нуля — стоит переложить уже принятую в инженерной практике логику (документ → изменение → извещение об изменении → новая версия) на структуру базы данных или PIM/DMS-системы, а не ограничиваться простым «файл1.pdf, файл2\_new.pdf» в общей папке.

Практический минимум для версионирования:

• у каждого документа — уникальный идентификатор, не зависящий от имени файла;
• явное поле «версия» и дата вступления версии в силу;
• связь версии с конкретными моделями/партиями, к которым она применяется;
• история изменений, доступная хотя бы для внутреннего аудита.

Как отзывать устаревшую версию

Отзыв версии — это не просто удаление файла с сайта. Если документ уже был выдан партнёрам, то:

• нужно понять, у кого из партнёров он может находиться на руках (для этого и нужна фиксация факта выдачи, см. ниже);
• нужно явно уведомить, что версия отозвана и какая версия пришла на замену;
• нужно решить, что делать с уже выполненным по старой версии ремонтом — это скорее юридический и сервисный вопрос, но ИТ-система должна как минимум сохранять историю, какая версия действовала в конкретный период.

Практически это реализуется через статус документа («действующий», «отозван», «заменён на …») и обязательное уведомление подписчиков раздела, к которому относится документ, а не через тихое исчезновение файла из каталога.

Как связывать документ с моделью, серийным номером и датой выпуска

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

• диапазоном серийных номеров или партий, к которым он применим;
• датой начала и (если есть) окончания выпуска этой конфигурации;
• версией аппаратной части и версией прошивки, если они меняются независимо друг от друга.

Это классическая задача для PIM-системы (Product Information Management) или связки PIM с MDM (Master Data Management): модель товара становится «мастер-записью», к которой привязываются версии документов, а серийный номер или партия — атрибутом, по которому можно однозначно выбрать нужный набор документации. Без такой связки высок риск, что сервисный центр получит формально «правильный», но фактически неприменимый к конкретному изделию документ.

Как фиксировать факт выдачи документа

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

• кто запросил документ (организация, представитель, основание полномочий — например, номер проверенной МЧД);
• какой именно документ и какой версии был выдан;
• дата и способ выдачи (скачивание с портала, отправка по защищённому каналу, электронная почта);
• к какой модели, серийному диапазону и товару относится выдача.

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

Российская специфика и международный контекст

В Евросоюзе аналогичная логика уже реализована директивой (EU) 2024/1799 о праве на ремонт, которая обязывает производителей обеспечивать доступ к запчастям, ремонтной информации и программным инструментам для независимых мастерских, и Регламентом об экодизайне устойчивых продуктов (ESPR, (EU) 2024/1781), который вводит требования к ремонтопригодности отдельных категорий товаров [9][10]. Европейский экономический и социальный комитет отдельно отмечал полезность единой национальной платформы, агрегирующей информацию о ремонте, но подчёркивал, что условия её работы и обновления нужно детально прописывать [15].

Российское регулирование устроено иначе: это точечное изменение статьи 6 Закона «О защите прав потребителей», без отдельного «закона о праве на ремонт» и без пока принятых требований к ремонтопригодности самого товара (как в европейском Ecodesign) [1]. Прямых аналогий с европейским подходом проводить преждевременно — по крайней мере до выхода российского подзаконного акта, который определит операционные детали. Но сам принцип «документ + подтверждённый получатель + версия + журнал выдачи» универсален и не зависит от юрисдикции.

Отдельная российская специфика — уже сложившаяся инфраструктура подтверждения полномочий (реестр МЧД на базе ФНС) и требования к защите персональных данных при регистрации представителей сервисных организаций на портале — это отдельный контур соответствия 152-ФЗ, который нужно учитывать при проектировании личного кабинета партнёра.

Практические этапы внедрения

1. Инвентаризация документации. Понять, что из технической документации вообще существует в структурированном виде, а что нужно собрать заново у разработчиков, контрактных производителей или архивов.
2. Классификация материалов. Разделить документы на открытые, доступные подтверждённым сервисам и чувствительные — с фиксацией правил в регламенте.
3. Выбор канала выдачи. Оценить, достаточно ли защищённого раздела на существующем сайте или нужен отдельный партнёрский портал с личными кабинетами.
4. Проектирование модели данных. Связать документ с моделью, версией, серийным диапазоном и датой выпуска — как правило, на базе PIM/MDM-системы или интеграции с уже используемой ERP/PLM-системой.
5. Механизм подтверждения статуса. Настроить проверку организации (ЕГРЮЛ/ЕГРИП) и, при необходимости, полномочий представителя через МЧД.
6. Процесс версионирования и отзыва. Определить внутренний регламент по аналогии с логикой ГОСТ 2.503 — кто утверждает изменение, как оформляется извещение, как уведомляются держатели предыдущей версии.
7. Журнал выдачи и аудит. Настроить логирование фактов выдачи документов, доступное для последующей проверки.
8. Пилот на одной товарной линейке. Прежде чем разворачивать процесс на весь ассортимент, стоит обкатать его на одной категории товаров и скорректировать по итогам.

Ограничения, ошибки и риски

• Ожидание финальной определённости от закона. Не стоит откладывать проектирование процесса до выхода постановления Правительства — операционную часть (классификацию документов, версионирование, журнал выдачи) можно и нужно строить уже сейчас, подстраивая под требования постановления по мере их появления.
• Смешение архива с рабочей папкой проекта. Документация должна храниться так, чтобы быть доступной в течение всего срока службы товара, а не только пока модель актуальна для отдела разработки.
• Отсутствие проверки полномочий представителя. Без механизма вроде МЧД компания рискует либо выдать документ неуполномоченному лицу, либо, наоборот, необоснованно отказать легитимному запросу.
• Отзыв документа без уведомления получателей. Если версия отозвана, но никто из ранее получивших её сервисов об этом не узнал, риск ошибки при ремонте не снижается, а работа по отзыву становится формальностью.
• Игнорирование связки «документ — серийный номер». Без привязки к партии/серийному диапазону сервис может получить документ, который относится к другой модификации товара.

Как выбрать между готовым сервисом и разработкой

Для компаний с небольшим количеством моделей и ограниченным кругом сервисных партнёров зачастую достаточно организационных мер и простого защищённого раздела на сайте — без полноценной разработки. Отдельный портал, интеграция с PIM/MDM или доработка существующей PLM/ERP-системы оправданы, когда:

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

Не стоит обещать, что сложная разработка обязательно потребуется всем — многое зависит от масштаба конкретной компании и ассортимента.

Как может помочь «Пятый фактор»

Задачи, которые встают перед производителем в рамках нового закона, — это, по сути, классическая связка интеграции и автоматизации: нужно соединить учётную систему (ERP/PLM/1С), хранилище технической документации, механизм подтверждения статуса контрагента (в том числе проверку МЧД) и портал или личный кабинет для сервисных организаций в единый процесс с журналом выдачи. Похожая логика — соединение внешних систем, проверка полномочий и организация защищённого обмена данными — уже встречалась команде «Пятого фактора» в проектах интеграции с внешними API и государственными системами.

Команда «Пятого фактора» может изучить существующую у производителя документацию и процессы её выдачи, оценить, достаточно ли доработки существующего сайта или нужен отдельный партнёрский портал с базой знаний и личным кабинетом, и помочь с разработкой, интеграцией с PIM/MDM или технической консультацией по организации журнала выдачи и разграничения доступа. Отдельно стоит учитывать требования 152-ФЗ при регистрации представителей сервисных организаций в личном кабинете — это тоже вопрос, который стоит продумать на этапе проектирования, а не после запуска портала.

Вывод

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

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

Источники

[1] consultant.ru — Федеральный закон от 26.07.2026 N 266-ФЗ "О внесении изменения в статью 6 Закона Российской Федерации "О защите прав потребителей" — https://www.consultant.ru/law/hotdocs/94987.html

[2] pravo.gov.ru — Федеральный закон от 26.07.2026 № 266-ФЗ, официальное опубликование — http://publication.pravo.gov.ru/document/0001202607260025

[3] garant.ru — Производителей обяжут снабжать сервисы техдокументацией для ремонта товара — https://www.garant.ru/news/2187559/

[4] kprim.ru — Производителей обязали передавать техдокументацию продавцам и сервисным компаниям — https://kprim.ru/proizvoditelej-obyazali-peredavat-tehdokumentacziyu-prodavczam-i-servisnym-kompaniyam/

[5] audit-it.ru — Обязанность производителей обеспечивать ремонт и поставку запчастей закреплена новым законом №266-ФЗ — https://www.audit-it.ru/news/finance/1136952.html

[6] reest-878.ru — С 2027 года ремонт техники изменится: производителям придется раскрывать документацию сервисам — https://reest-878.ru/news/s-2027-goda-remont-tehniki-izmenitsya-proizvoditelyam-pridetsya-raskryvat-dokumentatsiyu-servisam

[7] rosstip.ru — С марта 2027 года производители инструмента должны будут передавать сервисам техническую документацию — https://rosstip.ru/news/18058-s-marta-2027-goda-proizvoditeli-instrumenta-dolzhny-budut-peredavat-servisam-tekhnicheskuyu-dokumentatsiyu

[8] hofstrajibl.org — Protecting the Right to Repair: The U.S. vs. the EU — https://www.hofstrajibl.org/2024/03/protecting-the-right-to-repair-the-u-s-vs-the-eu/

[9] ifixit.com — The EU's Take On "Right to Repair" Has Finally Been Approved — https://www.ifixit.com/News/94705/the-eus-right-to-repair-has-finally-been-approved

[10] termopasty.com — Repairability Score in the EU Is Now in Effect — https://termopasty.com/en/repairability-score-in-the-eu-is-now-in-effect/

[11] docs.cntd.ru — ГОСТ 2.503-2013 Единая система конструкторской документации (ЕСКД). Правила внесения изменений — http://docs.cntd.ru/document/1200106868

[12] ca.kontur.ru — Как проверить МЧД, проверка машиночитаемой доверенности на сайте ФНС России — https://ca.kontur.ru/articles/51360-proverit_mashinochitaemuyu_doverennost

[13] law.ru — Машиночитаемая доверенность: подготовка и проверка МЧД — https://www.law.ru/article/27847-mashinochitaemaya-doverennost

[14] taxcom.ru — Как проверить машиночитаемую доверенность: пошаговая инструкция — https://taxcom.ru/baza-znaniy/elektronnaya-podpis/stati/kak-proverit-mashinochitaemuyu-doverennost/

[15] eesc.europa.eu — The right to repair (opinion) — https://www.eesc.europa.eu/en/our-work/opinions-information-reports/opinions/right-repair

[16] 5factor.ru — СберБизнес API: выписки, платежи и mTLS — https://5factor.ru/resources/integracziya-sberbiznes-api-s-1s-i-korporativnymi-sistemami

[17] 5factor.ru — ФГИС «Семеноводство» и 1С: обмен и ошибки — https://5factor.ru/resources/integracziya-fgis-semenovodstvo-s-1s-kak-perestat-vnosit-dannye-dvazhdy