Your AI, APIs and gateways touch lab systems.
Who keeps the audit trail?

Requirement: 11.10(e) "Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information." Also 11.10(b) copies, 11.10(c) protection, 11.10(d) "Limiting system access to authorized individuals", 11.10(g) authority checks.

Designed to support: server-generated UTC timestamps; append-only SHA-256 hash chain with a verify tool that detects altered, removed or reordered entries; fail-closed (no response is returned if the record cannot be written); role-based access (operator, approver, QA read-only, admin); tool and route allow/deny lists; complete electronic export.

Customer responsibility: system validation, clock synchronisation, record retention and backup, user management, and audit trail review. Electronic signatures (11.50, 11.70, 11.100, 11.200, 11.300) are out of scope; the approval feature is not an electronic signature.

Requirement: 58.130(e) changes "shall indicate the reason for such change"; Data Integrity Q&A 2018 defines an audit trail as a record that "allows for reconstruction of the course of events" and warns "When login credentials are shared, a unique individual cannot be identified through the login".

Designed to support: a reason is required on write calls by default (X-Audit-Reason header or reason field); per-person identity through one client certificate per person, or through a user id from an authenticated gateway.

Customer responsibility: keep reason capture switched on; do not rely on a shared token alone for attribution.

Requirement: Annex 11 sec. 9 "For change or deletion of GMP-relevant data the reason should be documented"; 12.4 systems "should be designed to record the identity of operators entering, changing, confirming or deleting data including date and time"; 7.1 "Access to data should be ensured throughout the retention period". The 2025 draft (consultation, not in force) adds who/what/when/why, time zone, audit trail "enabled and locked at all times", and searchable, sortable copies.

Designed to support: reason on writes, operator identity and UTC time in each record, audit that cannot be switched off (attempts are logged), searchable export for QA.

Customer responsibility: risk assessment, periodic audit trail review, retention and archive controls, and capturing old and new values in the target system's own audit trail.

Requirement: No. 17 para 80 "Any change to electronic records must not obscure the original entry and be time and date stamped and traceable to the person who made the change"; para 95 record "the date, time and identity of operators entering, changing, confirming or deleting data"; No. 1 8.3.5 "Reason for changes should be given."

Designed to support: append-only, time-stamped, attributable records with reason; QA read-only role; admin-only settings; Swiss GLP retention profile (10 years after study completion) with legal hold.

Customer responsibility: test facility SOPs, archive management, and retaining original and modified data in the target system (No. 17 para 83).

Requirement: MHRA 6.13 an audit trail records actions "without obscuring or overwriting the original record" and captures "who, what, when and why"; PIC/S 9.6 entries "recorded in true time".

Designed to support: per-call records written at the time of the call, with identity, action, time and reason.

Customer responsibility: data governance, ALCOA+ controls across the whole process, and review.

Requirement: OECD No. 22 6.13 audit trails "should always be switched on during GLP activities", and switching them off and on again "should" be recorded automatically; WHO TRS 1033 Annex 4 11.10 audit trails "should reflect ... users, dates, times, ... changes and reasons for changes ... and enabling and disenabling of audit trails", 11.9 "shared logins or generic user access should not be used"; Swiss GLP Ordinance (SR 813.112.1) Annex 2 sec. 8.3 para 5 audit trails linking changes to persons with a reason, and sec. 10 retention "for at least ten years after study completion".

Designed to support: a record written when auditing starts; configuration changes recorded; per-person identity via client certificates or an authenticated gateway; reason on writes; a 10-year Swiss GLP retention profile.

Customer responsibility: individual user accounts, periodic checks that auditing is running, archive and backup. WHO 11.12 and OECD No. 22 6.13 accept add-on audit software as a justified, documented and time-bound measure for systems without their own audit trail, not as a permanent replacement.

AGIT guidance is not legally binding; it interprets the GLP Principles for Swiss test facilities. In a GLP test facility the gateway is itself a computerised system that transfers and stores GLP data, so the customer validates it like any configurable system (AGIT category C). The gateway is designed to support that work: an open OQ test runner, a requirements traceability matrix, a configuration report per regulation, release notes, audit-trail search and export for the audit-trail review SOP, and documented system requirements. Backup and restore, contingency planning and the validation itself remain customer procedures.

AGIT guidance is not a legal document. It expects archived electronic raw data and their audit trails to stay complete, unaltered, linked to their metadata and readable for the whole retention period (at least 10 years under the Swiss GLP Ordinance), with an index of archived files, integrity checks at risk-based intervals, tested backups, validated migrations, and disposal only with documented test facility management approval.

Designed to support: plain-text JSONL records readable with standard tools and an open-source verifier; a hash chain and head file that show whether a log is complete and unaltered; UTC timestamps; a 10-year retention profile, legal hold, and no disposal function in the Community edition. Also in Community 0.4.0: an archive manifest (archive-manifest: file list with sizes, hashes, record ranges and versions); verification of an archived copy against that manifest (verify --manifest) with a dated check report; closing a log segment requires a reason, a ticket and an approver, all recorded; offline runs (verify, export, manifest, report, review) are written to a separate hash-chained run log, checked with verify-run-log, and never append to the live audit log.

Customer responsibility: the archivist, archive storage on read-only or WORM media, off-site backups, clock synchronisation, control of the gateway configuration, periodic integrity checks, migration and disposal procedures. The gateway records gateway activity; it complements, and does not replace, the data audit trail of the target system.

Requirement: Art. 12(1) high-risk AI systems "shall technically allow for the automatic recording of events (logs)"; Art. 19(1) and 26(6) logs kept "of at least six months, unless provided otherwise in applicable Union or national law".

Designed to support: automatic logs of every tool or API call that a provider or deployer may keep; a 6-month default retention floor. The gateway does not by itself make an AI system meet Art. 12; whether the AI Act applies depends on the customer's system.

Every audit record holds personal data (user id and name, client certificate fingerprint, request path, kept headers), whatever the body mode. The body mode is the customer's choice and applies to both MCP and HTTPS traffic: the default hash_only stores only SHA-256 hashes of bodies, while full stores request and response bodies, which may include personal data. A SHA-256 of a short body can be re-identified by guessing, so hash_only is not anonymisation. The customer is the controller and decides the lawful basis, the body mode, retention, and how to answer erasure requests. Records are append-only and hash-chained: removing one breaks verification, so legal retention duties (GDPR Art. 17(3)) and erasure must be weighed by the customer before choosing full mode. The Community edition does not encrypt the log at rest; use disk encryption. A table of the personal data in each record is provided for the customer's record of processing (Art. 30).

These OECD advisory documents expect archived electronic records to be locked so they cannot be altered or deleted without detection, transfers documented with a chain of custody, migrations validated, accounts locked after repeated failed sign-ins, backups kept apart from the original data, and controls in cloud settings that the test facility runs independently of the provider.

Designed to support: a hash chain and head file that make alteration or deletion detectable; verification that the test facility can run itself against a head value it keeps on another system; TLS 1.3 for remote access; recorded failed authentication attempts. Also in Community 0.4.0: an archive manifest with custody records (archive-transfer) and a receipt that is added only when the received package matches (verify --manifest --received-by); an optional limit on repeated failed authentication attempts (listen.auth_failure_limit), off unless configured.

Customer responsibility: read-only or WORM archive storage, off-site backups of logs and configuration, restore tests, separation of system administration from data ownership, and service agreements with any hosting provider.

The EMA guideline expects changes to user roles and permissions to be recorded, timestamps to be unambiguous, the audit trail to be exportable as a searchable data file, the generation of data extracts and exports to be traceable, and audit trail review to be risk-based. AGIT expects software upgrades to be impact-assessed against the affected requirements.

Designed to support: UTC timestamps; recorded configuration at every start; audit-trail search and export. Also in Community 0.4.0: each startup record holds the identities and roles, the body mode and a SHA-256 of the effective configuration, and lists what changed since the previous start (with an optional change reason); a review-by-exception report (review) with JSON, Markdown or CSV output; a record of each offline export and verification run in a separate hash-chained run log; release notes that name the affected requirements and the effect on existing records; and an OQ runner option (--requirement) that repeats only the tests mapped to named requirements.

The gateway's hash chain is kept on the customer's system. It is not a distributed or independent ledger.

This page describes design intent. It is not legal advice and it is not a third-party approval of the product.