Любая система, которая участвует в создании или контроле GxP-значимых документов, подлежит валидации (CSV — Computerized System Validation). Это не бюрократическая формальность, а способ доказать, что инструмент работает предсказуемо и его результаты можно использовать в регуляторном досье. Разберём, как устроен валидационный пакет и о чём спросить вендора до пилота.
С чего всё начинается: URS
Фундамент валидации — User Requirements Specification (URS), спецификация требований пользователя. В ней фиксируется, что именно система должна делать с точки зрения процесса: какие документы проверяет, какие роли поддерживает, как ведёт журнал аудита. Без чёткого URS невозможно проверить, что система «соответствует назначению» (fit for intended use).
Риск-ориентированный подход
Современная валидация по GAMP 5 строится вокруг анализа рисков: глубина тестирования зависит от того, насколько критична функция. Подавление аудиторской находки и запись в Audit Trail требуют более строгой проверки, чем, например, настройка интерфейса.
Три квалификации: IQ, OQ, PQ
IQ (Installation Qualification) — подтверждает, что система установлена и сконфигурирована корректно: версии, окружение, права доступа, параметры безопасности.
OQ (Operational Qualification) — проверяет, что функции работают в соответствии со спецификацией: загрузка документа, запуск аудита, формирование находок, ролевые ограничения, неизменяемость журнала.
PQ (Performance Qualification) — демонстрирует, что в реальном рабочем процессе и на реальных (обезличенных) данных система даёт воспроизводимый результат.
Особенность систем с ИИ
LLM-компонент недетерминирован по своей природе, поэтому к нему предъявляются дополнительные требования: фиксация версии модели, разделение детерминированных бизнес-правил и вероятностных подсказок, протоколирование того, что финальное решение всегда принимает человек. Эти аспекты должны быть отражены в валидационном плане отдельно.
Вопросы вендору до пилота
- Предоставляете ли вы шаблоны URS и валидационного плана?
- Есть ли готовые протоколы IQ/OQ/PQ и матрица трассировки требований?
- Как версионируется ИИ-модель и фиксируется ли она в Audit Trail?
- Как организовано управление изменениями (change control) при обновлениях?
- Какие данные нужны для PQ и в каком виде (обезличивание)?
Заключение носит практический характер: автоматизированный аудит не заменяет экспертизу специалиста, а освобождает его время от механической сверки для решения более высокоуровневых задач.
