В большинстве организаций 'комплаенс' живёт в Word-документе: кто к чему имеет доступ, какие данные не должны покидать систему, какой запрос логировать — всё записано, но применение оставлено людям. Самая частая точка слома на банковских аудитах — именно этот разрыв между записанной политикой и работающей системой. CentraQL закрывает его, встраивая комплаенс как профиль в рантайм.
Что такое ComplianceProfile?
ComplianceProfile собирает всё комплаенс-поведение установки в один объект конфигурации. Профили вроде 'Default' и 'RegulatedFinance' идут из коробки; каждый несёт:
- Какие вызовы LLM разрешены (обязателен ли on-prem?).
- Уровень маскирования PII (ИНН, IBAN, телефон).
- Ограничения поверхности запроса (allowFreeText, joinDepthMax, rangeOf).
- Срок хранения аудита (например, 365 дней).
- Политику egress (исходящих вызовов).
Смена профиля — одна строка; эффект мгновенно применяется ко всему конвейеру.
EgressGuard: ворота для каждого исходящего байта
EgressGuard — это шлюз, инспектирующий все исходящие сетевые вызовы. При RegulatedFinance его поведение однозначно: любой запрос к облачному LLM, внешнему API или неутверждённому endpoint блокируется на границе запроса. Даже если разработчик случайно добавит облачный вызов, при профиле 'RegulatedFinance' этот вызов не выполнится; блокировка пишется в аудит.
Это привязывает гарантию 'данные клиента не утекут' к коду, а не к добрым намерениям.
В связке с PromptAuditLog
Чтобы комплаенс был доказуем, у каждого запроса нужен след. Конвейер Copilot в CentraQL уже пишет каждую стадию в PromptAuditLog: query hash, пользователь, используемая модель, возвращённые строки, маскированные колонки. ComplianceProfile задаёт срок хранения и уровень детализации. При RegulatedFinance запись хранится 365 дней и неизменяема (append-only).
На аудите BDDK можно с доказательствами предъявить: 'в октябре этот CRO задал такой запрос, система использовала такую модель, замаскировала такие колонки и сформировала ответ таким SQL'.
Пересечение EU AI Act и KVKK
EU AI Act, действующий в 2026, требует аудита, объяснимости и человеческого надзора для высокорисковых применений ИИ вроде кредитного скоринга. Руководство KVKK от марта 2026 закрепило требование явного согласия при передаче персональных данных провайдеру LLM. ComplianceProfile превращает обе рамки в одну конфигурацию:
- Запросы, помеченные как высокорисковые, попадают в очередь человеческого утверждения.
- Никакие данные с PII не уходят без разрешения профиля.
- Каждое решение логируется с объяснением (нарратив + признаки).
Почему важно различие 'runtime'?
Документ политики статичен; система динамична. Когда разработчик добавляет новую интеграцию, документ не меняется, а поведение — да. Если комплаенс встроен в рантайм, новый код подчиняется тому же профилю — то есть комплаенс применяется заранее, а не проверяется постфактум. Аудит видит одну runtime-правду, а не разрыв между политикой и реальностью.
Порядок настройки
- Выберите профиль: RegulatedFinance для большинства банков.
- Отметьте PII-колонки через ColumnPolicy (ИНН, IBAN, телефон, email).
- Определите allowlist EgressGuard (обычно пустой — никаких исходящих вызовов).
- Настройте retention аудита и append-only хранилище.
- Подключите высокорисковые типы запросов к очереди человеческого утверждения.
Заключение
Комплаенс осмыслен, когда живёт в рантайме, а не на бумаге. Трио ComplianceProfile + EgressGuard + PromptAuditLog в CentraQL встраивает регулирование в систему вместо того, чтобы оставлять его человеческой дисциплине. Итог: нет разрыва между записанной политикой и работающей системой; аудит видит неизменяемую runtime-запись, а не документ.
