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

Посему предлагаю использовать две базовые таблицы с наворотами.

Первая - таблица Люди, куда включены обязательно присутствующие формально постоянные (редко изменяющиеся) атрибуты. К таковым отношу: ФИО, дата и место рождения, основные учётные номера (ИНН и СНИЛС). Если происходит изменение ЭТИХ атрибутов - то для этого человека вводится ещё одна запись. А для отслеживания в структуру вводится дополнительное поле. Если это актуальные данные - в нём Null, если же данные изменились, и имеется другая, актуальная, запись, то в этом поле находится идентификатор актуальной записи. Возможно, это будет не одна таблица, а набор таблиц (например, сведения о паспортах я бы вынес в отдельную таблицу), но сути это не меняет.

Вторая - таблица Контакты. Там соответственно хранятся именно контакты (возможно, в сериализованной форме). Таблица связана с таблицей Люди соотношением много-к-одному, а также имеет дополнительное поле валидности записи (контакт, потерявший актуальность, не удаляется, а помечается как невалидный).

Поскольку удаление записей в принципе не предусматривается, надобность в архиве отпадает.

Если есть опасность некорректной работы - можно дополнительно ввести таблицу журналирования изменений, а также дополнительные таблицы, которые за счёт переопределения позволяют вести контроль корректности связей. Ну и соответственно процедуры контроля целостности и восстановления минорных несоответствий.

Такая структура создаёт, конечно, определённые сложности по получению актуальной информации (из-за неограниченности количества изменений и, соответственно, длины цепи от поискового атрибута до актуальной записи - а Access не поддерживает рекурсивных CTE), придётся получение делать на основе VBA-процедур (и, возможно, временных таблиц). Упростить процесс можно за счёт ещё одного переопределения - дополнительной таблицы (запись - актуальная запись).

Rockefsкогда все данные можно уместить в поле text все ок, а если это файл/картинка/число/дата то такой вариант не сработает
Сериализация снимает эти проблемы. А файл/картинка - они вообще должны лежать в файловой системе, а в таблице хранится только ссылка (путь) к файлу (не забывай об ограничении на размер файла БД и то, что при его превышении БД повреждается - сразу, без предупреждения, причём необратимо и невосстановимо).

Rockefsбез VBA не устроить и обычному пользователю это будет сложно сделать.
Обычный пользователь работает через интерфейс, созданный программистом, все операции выполняет код, созданный тем же программистом, так что пользователю вообще параллельно, как и каким средствами там что-то выполняется. А уж какой-нить номер телефонный в форму и обезьяна ввести может...