Автор статьи
Не буквально поставщик — но функция, которую нельзя оставлять без документированного контроля.
Мы уже разбирали, зачем нужна матрица ролей и прав доступа и как выбрать администратора лабораторной компьютеризированной системы. Во второй статье прозвучал тезис: ИТ-отдел лучше других кандидатов соответствует принципу независимости, но при одном условии — администратор должен хотя бы в общих чертах понимать систему, которой управляет.
И вот это условие осталось за кадром как личное качество конкретного человека. Хороший попался — повезло. Не очень — узнаете во время инспекции.
На самом деле требовать этого только от человека недостаточно. Компетентность никуда не девается — но она должна перестать быть личным качеством и превратиться в управляемое требование: закреплённое документом, обеспеченное обучением и поддающееся проверке. И такое требование существует не первый год.
Что требует действующая норма
Приложение 11 к Правилам GMP — пункт 3.1 в редакции EU GMP и гармонизированное с ним положение Приложения 11 к Правилам ЕАЭС — требует:
если для поставки, установки, настройки, интеграции, валидации, обслуживания (в том числе через удалённый доступ), модификации, хранения системы или обработки данных привлекаются третьи лица, между производителем и ними должны существовать официально оформленные соглашения с чётким указанием ответственности третьей стороны.
Следующее предложение — то, которое обычно пролистывают:
аналогичные требования следует предъявлять к подразделениям информационных технологий производителя.
Обратите внимание на формулировку. В оригинале стоит formal agreements — официально оформленные соглашения, а не обязательно договор между самостоятельными сторонами. Для отношений между подразделениями одной организации это принципиально: норма не требует гражданско-правового договора, она требует того, чтобы ответственность была определена, зафиксирована письменно и поддавалась проверке.
В EU это положение действует с редакции Приложения 11, вступившей в силу в 2011 году; в ЕАЭС аналогичное требование закреплено в Приложении 11 к Правилам GMP, утверждённым Решением Совета ЕЭК № 77 от 3 ноября 2016 года. За это время в отрасли прижилась практика соглашений по качеству с контрактными лабораториями, калибровочными службами, поставщиками ПО. С собственным ИТ-отделом — заметно реже (практически никогда). Логика понятна интуитивно: это же не третье лицо, это наши. Но норма смотрит не на то, какое место ИТ-отдел занимает в организационной структуре предприятия, а на то, какую функцию он выполняет применительно к GMP-значимой системе.
Загляните в свою папку с соглашениями по качеству. Контрактная лаборатория там есть, поверитель есть, вендор ЛИМС есть. А ИТ-отдел?
Эта логика согласуется с общим принципом Главы 7 Правил GMP: переданную функцию нельзя считать управляемой, если обязанности сторон и порядок надзора остаются подразумеваемыми. Но подчеркну: внутреннее подразделение не следует автоматически приравнивать к исполнителю по Главе 7 — именно поэтому в Приложении 11 понадобилась отдельная фраза про ИТ-подразделения. Если бы Глава 7 покрывала этот случай напрямую, эта строчка была бы не нужна.
Два владельца одной системы
В международной практике для разграничения есть готовая рамка — роли System Owner и Process Owner, развёрнутая в GAMP 5 и названная в самом действующем Приложении 11. Владелец системы отвечает за доступность, поддержку, обслуживание и поддержание системы в контролируемом состоянии; владелец процесса — за процесс и данные, которые эта система обслуживает. А вот привязки этих ролей к подразделениям норма не устанавливает: в одной организации владельцем лабораторной системы будет ИТ, в другой — сама лаборатория или подразделение качества, а ИТ выступит техническим администратором. Это организационное решение. Требование GMP в другом: роли должны быть определены, разграничены и задокументированы.
Действующее Приложение 11 в разделе о персонале требует тесного взаимодействия между владельцем процесса, владельцем системы, уполномоченным лицом и ИТ. Взаимодействие есть почти везде — люди созваниваются, пишут в мессенджер, договариваются. Вопрос в другом: где это записано? Соглашение — тот документ, где граница перестаёт быть подразумеваемой: что техническая служба меняет сама, а что согласовывает с владельцем процесса.
Что добавляет проект новой редакции
7 июля 2025 года Европейская комиссия совместно с PIC/S опубликовала для консультаций проект новой редакции Приложения 11. Документ вырос с пяти страниц до девятнадцати и получил семнадцать разделов. Финальная редакция ожидалась в середине 2026 года, однако на портале EudraLex Volume 4 Приложение 11 на момент подготовки статьи по-прежнему значится в редакции января 2011 года. Пока это проект, и окончательные формулировки могут измениться.
Но направление видно отчётливо. В разделе 7 «Управление поставщиками и услугами» внутреннее ИТ-подразделение упомянуто наряду с внешними провайдерами в четырёх пунктах из пяти. Три из них стоит привести.
Пункт 7.1. Если регулируемый пользователь полагается на квалификацию или эксплуатацию системы со стороны вендора, провайдера услуг или внутреннего ИТ-подразделения, это не меняет требований настоящего документа. Ответственность целиком остаётся на регулируемом пользователе.
Пункт 7.3. Надзор за работой провайдера или внутреннего ИТ-подразделения осуществляется на основе согласованных с ними соглашений об уровне обслуживания (SLA) и ключевых показателей эффективности (KPI).
Обратите внимание на пропуск. Пункт 7.2 — единственный в разделе, где внутреннего ИТ-подразделения нет: требование провести аудит или углублённую оценку адресовано только вендору и провайдеру услуг. Почему именно так, проект не объясняет, и намерений авторам я приписывать не берусь. Но на уровне формулировок картина однозначная: весь набор инструментов, предусмотренных для внешнего поставщика, на внутреннее подразделение не переносится. Надзор — да, отчётность — да, а вот обязательный формальный аудит собственного ИТ по модели аудита подрядчика из проекта не следует. Право владельца процесса и QA проверять, как выполняются внутренние процедуры, при этом никуда не исчезает.
Пункт 7.5 — главный для нашей темы. Регулируемый пользователь должен иметь договор с провайдером услуг либо утверждённые процедуры с внутренним ИТ-подразделением. Регулятор сам разводит две формы и для внутреннего ИТ прямо выбирает процедуры, а не договор. Дальше перечислены девять элементов, которые проект предлагает включать в такой документ:
- описание выполняемых работ и предоставляемой документации;
- процедуры компании и регуляторные требования, которые надлежит соблюдать;
- порядок регулярной, внеплановой и инцидентной отчётности и надзора, включая SLA и KPI, сроки ответа и сроки устранения;
- условия проведения аудитов поставщика;
- поддержка во время регуляторных инспекций — по запросу;
- порядок устранения проблем, возникших при штатной эксплуатации, аудитах и инспекциях;
- требования и процессы информирования о проблемах качества и безопасности;
- стратегия выхода, обеспечивающая сохранение контроля над данными системы;
- порядок выпуска новых версий системы и возможность протестировать их до релиза.
Отдельно стоит пункт 9.9: документацию по квалификации и валидации может полностью или частично готовить внутреннее ИТ-подразделение, но регулируемый пользователь полностью подотчётен, обязан тщательно её рассмотреть и официально одобрить использование системы — оценив, покрывает ли она внедрённую версию и поддерживает ли процессы компании, или работу следует повторить в части либо целиком.
Подготовку документации передать можно, но ответственность за её критическую оценку нельзя. Для лабораторий, где валидационный комплект по ЛИМС фактически собрала ИТ-служба, а лаборатория его просто подписала, это самый неудобный пункт проекта. Неудобный не тем, что ИТ участвовала, — тем, что подпись без рассмотрения перестаёт быть формальностью.
Проект не создаёт новый принцип. Он переводит одну общую фразу действующей нормы в детализированную модель управления.
Как это выглядит на практике
Сначала о названии. Проект использует для внутреннего ИТ формулировку «утверждённые процедуры», в отечественной практике прижилось «техническое соглашение», кто-то ведёт это как регламент взаимодействия или раздел в процедуре управления компьютеризированными системами. Название не принципиально. Принципиально другое: содержание, чёткое закрепление обязанностей и статус контролируемого документа.
Девять элементов пока относятся к проекту и сами по себе обязательным содержанием внутреннего документа не являются. Но уже сегодня они годятся как модель, по которой можно проверить, достаточно ли полно предприятие определило отношения с ИТ. К ним имеет смысл добавить то, что специфично именно для внутренних отношений:
- Объект — система, а не отдел. Из документа должно быть понятно, к каким GMP-значимым системам и функциям он применяется. Писать отдельную бумагу на каждую систему необязательно: можно охватить класс систем или сделать корпоративную процедуру с приложением-реестром. А вот формулировки вроде «все лабораторные системы» потом никто не проверит.
- Статус контролируемого документа. Документ оформляют и утверждают по правилам системы управления документацией: номер, версия, дата вступления в силу, реестр. Для GMP-критичной системы
