What We Log and Why: Compliance Engineering for an AI Data Platform

Compliance has a reputation as the department of slowing things down. Done properly, it is a specification language: every requirement translates into something the system must record, prove, or refuse to do. At Synthos, the compliance backlog and the engineering backlog are the same list.

The spine of it is the audit log. Every privileged action — role changes, user status changes, warranty approvals and rejections, settings edits, impersonation sessions — lands as an event with actor, target, timestamp, and source. The test we apply is reconstruction: could we replay an incident from the log alone? Fields that do not serve reconstruction do not ship.

Our favorite compliance artifact is customer-facing: the validation certificate. Each one is independently verifiable through a public endpoint — dataset, risk score, issue date, and an expiry fixed at ninety days from completion — so a third party can confirm a certification without trusting a screenshot. Turning an internal claim into a checkable public record is compliance engineering at its best.

The same philosophy shapes access controls: named API keys with scopes shown once at creation, two-factor enrollment with recovery codes minted at activation, session management that lists and revokes. Auditors ask “who could have done this”; the honest answer requires the controls to have been designed for the question.

The hardest discipline is data minimization on a platform whose product is data inspection. Deleted datasets go, while accountability records — certificates, warranty history, audit events — stay. The split is documented in the privacy policy and enforced in code, and keeping those two synchronized is itself a standing compliance task. Policy that diverges from implementation is worse than either alone.