Mark Emelianov

Семантический веб · Комплаенс · Статья 3 · Черновик

Комплаенс как граф, а не как таблица

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

Идея семантического веба предлагает другой способ хранить ту же информацию.

Идея простыми словами

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

Для управления, рисков и комплаенса (GRC) это означает небольшую перемену привычки. Требование, контроль, доказательство, риск и замечание аудита перестают быть строками в разных списках. Каждое становится записью со своей идентичностью, а связи между ними тоже становятся записями.

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

Как контроль выглядит в графе

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

Вверху контроль. От него идут связи к требованию, которое он выполняет, к риску, который он снижает, к доказательству, которое его подтверждает, и к замечанию аудита по его проверке. Полоса внизу говорит, что каждая связь сама является записью, в которой указано, кто её создал, когда и на каком основании.
Рисунок 2: контроль и то, с чем он связан

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

Что это делает возможным

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

Сопоставление между стандартами. Требования разных стандартов часто просят почти одного и того же. В графе контроль записывается один раз и связывается со всеми требованиями, на которые он отвечает, так что одна запись служит нескольким источникам, а пробел виден как требование, за которым нет контроля.

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

Вверху одна запись контроля. От неё идут три представления: руководитель по комплаенсу видит статус и пробелы, аудитор видит проверки и доказательства, а менеджер по рискам видит риски, которые она снижает. Запись хранится один раз, и каждый видит часть, подходящую его роли.
Рисунок 3: одна запись, несколько представлений

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

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

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

Слева агент с ограниченными учётными данными свободно читает граф посередине. Когда он хочет что-то изменить, он предлагает изменение шлюзу справа, где оно ждёт проверки и одобрения; в граф попадает только одобренное изменение. Полоса внизу говорит, что каждое предложение, решение и изменение записываются.
Рисунок 5: агенты читают и пишут через шлюзы

Где граф проигрывает таблице

Граф не бесплатен, и он не всегда лучший инструмент. Четыре честные цены:

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

Почему он подходит именно этой области

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

Он подходит и аргументу этой серии. Жёсткие контроли для агентов и комплаенс, который можно автоматизировать, зависят от одного и того же: явных, связанных, записанных фактов, за которыми может проследить и которые может проверить человек или агент.

Что взять с собой

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