ИТ-отдел — тоже поставщик: что GMP требует от отношений с собственной ИТ-службой

Не буквально поставщик — но функция, которую нельзя оставлять без документированного контроля.

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

И вот это условие осталось за кадром как личное качество конкретного человека. Хороший попался — повезло. Не очень — узнаете во время инспекции.

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

Что требует действующая норма

Приложение 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 — главный для нашей темы. Регулируемый пользователь должен иметь договор с провайдером услуг либо утверждённые процедуры с внутренним ИТ-подразделением. Регулятор сам разводит две формы и для внутреннего ИТ прямо выбирает процедуры, а не договор. Дальше перечислены девять элементов, которые проект предлагает включать в такой документ:

1. описание выполняемых работ и предоставляемой документации;
2. процедуры компании и регуляторные требования, которые надлежит соблюдать;
3. порядок регулярной, внеплановой и инцидентной отчётности и надзора, включая SLA и KPI, сроки ответа и сроки устранения;
4. условия проведения аудитов поставщика;
5. поддержка во время регуляторных инспекций — по запросу;
6. порядок устранения проблем, возникших при штатной эксплуатации, аудитах и инспекциях;
7. требования и процессы информирования о проблемах качества и безопасности;
8. стратегия выхода, обеспечивающая сохранение контроля над данными системы;
9. порядок выпуска новых версий системы и возможность протестировать их до релиза.

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

Подготовку документации передать можно, но ответственность за её критическую оценку нельзя. Для лабораторий, где валидационный комплект по ЛИМС фактически собрала ИТ-служба, а лаборатория его просто подписала, это самый неудобный пункт проекта. Неудобный не тем, что ИТ участвовала, — тем, что подпись без рассмотрения перестаёт быть формальностью.

Проект не создаёт новый принцип. Он переводит одну общую фразу действующей нормы в детализированную модель управления.

Как это выглядит на практике

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

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

• Объект — система, а не отдел. Из документа должно быть понятно, к каким GMP-значимым системам и функциям он применяется. Писать отдельную бумагу на каждую систему необязательно: можно охватить класс систем или сделать корпоративную процедуру с приложением-реестром. А вот формулировки вроде «все лабораторные системы» потом никто не проверит.
• Статус контролируемого документа. Документ оформляют и утверждают по правилам системы управления документацией: номер, версия, дата вступления в силу, реестр. Для GMP-критичной системы его обычно согласуют владелец процесса, владелец системы и QA — в пределах установленных ролей. Иначе текст трудно предъявить как элемент работающей системы качества.
• Границы полномочий. Что техническая служба меняет сама, а что — только по заявке владельца процесса, с формальным согласованием.
• Сроки реакции по классам обращений. Система легла и под угрозой данные — это одно. Завести нового пользователя — совсем другое. И там и там нужны цифры, а не «как можно скорее».
• Записи об административных действиях. Кто, когда и что изменил — прямое продолжение темы аудиторского следа: соглашение фиксирует, что систему ведут под запись и записи доступны владельцу процесса и QA.
• Порядок экстренных изменений. Режим «сначала восстановим работу, потом оформим» знаком всем. Вопрос в том, что происходит после «восстановим»: как документируют уже выполненное действие — с фактическими датой и временем, а не датой оформления, — кто и в какой срок сообщает владельцу процесса и когда изменение попадает в управление изменениями. Разница принципиальна: описать задним числом то, что реально сделали вчера, при установленной процедуре можно, а датировать запись вчерашним днём нельзя.
• Право на проверку. Не обязательно полноценный аудит по всей форме — но право посмотреть, что реально настроено, и получить нужные записи, а не поверить на слово.
• Закреплённый специалист и его знакомство с процессом. Кто именно со стороны ИТ отвечает за систему и откуда узнаёт, зачем она нужна лаборатории.
• Порядок эскалации. К кому идти, если стороны не сошлись во мнениях, и в какие сроки.
• Периодичность пересмотра. Документ, который никто не открывал три года, для инспектора выглядит так же, как его отсутствие.

Объём документа стоит соразмерять с критичностью системы и рисками для данных — причём критичность определяется не числом приборов и не размером лаборатории. Единственный хроматограф, на котором держится выпуск серий, критичен ровно так же, как ЛИМС. Для простой автономной системы с обоснованно низким риском документ может быть компактным; для системы, от которой зависят результаты выпускающего контроля и сохранность первичных данных, потребуется подробная модель взаимодействия.

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

Что происходит, когда этого нет

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

Показательный пример — предупреждение FDA контрактной лаборатории Missouri Analytical Laboratories Inc. (WL №615319 от 30 сентября 2021 года, по итогам инспекции 3–19 мая 2021 года). По пункту 21 CFR 211.68(b) инспекторы зафиксировали: индивидуальные учётные записи и уровни привилегий не были назначены пользователям ни в прикладном ПО, ни в операционной системе Windows; аналитики имели возможность удалять и перезаписывать данные; в корзине обнаружено около 36 удалённых файлов и папок. Плюс расчёты по показателям качества в невалидированных таблицах.

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

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

Вывод из этого делаю уже я, в письме его нет. Внешний подрядчик не выводится за пределы ответственности площадки — он её продолжение. А внутреннее ИТ-подразделение не попадает под ослабленный контроль по принципу «это наши» — оно оценивается по функциям, которые выполняет в GMP-значимой системе. Граница «свой — чужой», на которую опирается обыденная логика, для регулятора не работает ни в одну сторону.

Тот же принцип FDA сформулировала ещё в Compliance Policy Guide 425.200 — документе 1985 года в редакции 1987-го, который FDA до сих пор публикует со статусом Final: ответственность за пригодность компьютерных систем, используемых в производстве, обработке или хранении лекарственного препарата, несёт конечный пользователь. Документ старый и современные ожидания по целостности данных не заменяет, но базовый принцип с тех пор не изменился: передача технической функции не передаёт ответственности.

Ещё один ракурс даёт европейская практика. В отчёте о несоответствии GMP по Avlab S.r.l. (IT/NCR/01/H/2026, запись №186598 в базе EudraGMDP; отчёт выпущен AIFA 23 июля 2026 года по итогам инспекции 22–24 июня 2026 года) среди двенадцати основных несоответствий рядом стоят недостатки валидации компьютеризированных систем и управления электронными данными — и отдельным пунктом недостатки квалификации поставщиков и надзора со стороны контроля качества. Формально это самостоятельные находки, регулятор их не объединял. Но для предприятия у них может быть общий источник: недостаточная определённость ответственности и надзора.

С чего начать

Не обязательно сразу писать документ под каждую систему в лаборатории. Начните с одной — самой критичной, например с ЛИМС или хроматографического ПО — и с одного вопроса: если инспектор спросит, чем определены обязанности ИТ по этой системе и как вы контролируете их выполнение, что вы ему покажете?

Если ответ звучит как «у нас с ними и так всё понятно», это и есть ответ на вопрос, с какого документа начинать.