COMPLIANCE · REGULATION MAPPING

For every named regulation on a segment page,
Yolo’s audit chain produces the evidence
that regulation requires.

The claim is structural: evidence is produced without depending on the regulated entity’s own records, without trusting Yolo, and without trusting the customer. The on-chain Merkle root is the trust anchor. This page maps each major regulation to the specific artifacts Yolo produces.

For the architectural mechanism behind these artifacts — the three tamper-evidence layers, the hash chain construction, and the verification path — see /methodology.

Enterprise inquiries: agents@yolo.solutions

For every AI-mediated decision logged to Yolo, three artifacts are generated. These artifacts together produce the record-keeping evidence the regulations named on the segment pages require.

01 · EVERY TIER
The audit chain entry
A tamper-evident, hash-chained record of the decision. Contains agent identity, timestamp, decision type, tier classification, payload hash, and a chain link to the previous entry (prev_hash = the previous entry's chain_hash).
Append-only Postgres. audit_log_prevent_mutate trigger blocks all mutations at the database engine level.
02 · NIGHTLY
The Merkle root anchor
Every night at 02:30 UTC, all entries from the prior 24 hours are aggregated into a Merkle tree. The root is committed to Base mainnet via the Yolo Audit Chain contract.
On-chain: 0xDf5e1c1e82880C0E9dce3758A58e62189Ca365FD on Base mainnet. The on-chain root cannot be modified by Yolo, by the customer, or by any party short of compromising Ethereum mainnet.
03 · ALL TIERS
The IPFS availability pin
The nightly anchor blob — each batch's {seq, chain_hash} list and Merkle root — is pinned to IPFS (Pinata) as a public availability mirror, so anyone can recompute the anchored root and verify entries without Yolo. The readable decision record is retained by the originator; under Strict-B, Yolo holds only hashes, never the content.
Anchor blob pinned to IPFS (Pinata); CID stored in agent_audit_anchors.ipfs_cid (per batch, all tiers). Retrievable without Yolo cooperation.

Every regulation listed in Yolo’s segment pages is mapped below to the specific artifacts the regulation requires and the specific artifacts Yolo produces. The mapping is structural, not aspirational. For primary regulatory text, defer to the cited source.

REGULATION
EU AI Act
Article 12 — Record-keeping
EU · High-risk AI · Annex III · operative Aug 2, 2026 (proposed Digital Omnibus delay to ~2027 not enacted — Aug 2026 stands)
WHAT IT REQUIRES

Providers of high-risk AI systems must enable the automatic recording of events ("logs") throughout the system's lifecycle. Logs must be of a level of granularity appropriate to the system's intended purpose and retained for an appropriate period.

WHAT YOLO PROVIDES
PER-DECISION ENTRY
Timestamp, agent identity, decision type, payload hash — one entry per decision at every tier.
CRYPTOGRAPHIC INTEGRITY
Hash-chained, append-only. Retroactive modification detectable by any party with the original entries.
STRUCTURED EXPORT
Machine-readable JSON conforming to the open schema at /methodology. Exportable on demand.
RETENTION CONTROL
Consequential tier: 7-year default. High-stakes: configurable, including indefinite. Customer-controlled via contract clause.
INDEPENDENT REGULATOR VERIFICATION
Regulators verify entries against the on-chain Merkle root without Yolo's cooperation or credential.
ENFORCEMENT CONTEXT

Article 99(4): up to 3% of global annual turnover or €15M for record-keeping violations. This is distinct from the 7% penalty under Article 5 (prohibited uses: social scoring, biometric surveillance).

Annex III covers: credit scoring, insurance underwriting, healthcare diagnostics, employment, education, law enforcement, migration/border control, public benefits, and judicial administration. Each maps to a Yolo segment at /for.

REGULATION
EU AI Act
Article 13 — Transparency obligations
EU · High-risk AI systems
WHAT IT REQUIRES

High-risk AI systems must be designed to allow users to interpret output and use it appropriately. Information about the system's capabilities, limitations, and the logic behind decisions must be available.

WHAT YOLO PROVIDES
VERIFIABLE AGENT IDENTITY
ERC-721 + ERC-8004 identity registry. The specific agent and version responsible for any decision is unambiguously verifiable on Base mainnet.
DECISION RATIONALE, HASH-COMMITTED
The rationale is retained by the originator and committed to the entry by hash (Strict-B: Yolo holds the hash, not the readable text), so a regulator can confirm the originator's rationale is the one logged.
MODEL VERSION HISTORY
Version change events on Base mainnet via identity registry.
REGULATION
EU AI Act
Article 14 — Human oversight
EU · High-risk AI systems
WHAT IT REQUIRES

High-risk AI systems must include features that enable effective human oversight, including the ability to override or interrupt system outputs.

WHAT YOLO PROVIDES
HUMAN-AI INTERACTION CAPTURE
Per-decision entries capture whether the AI output was reviewed, accepted, overridden, or escalated — and by whom, with timestamp.
ORIGINATOR-HELD RECORD, HASH-ANCHORED
The complete human-AI interaction is retained by the originator — under Strict-B, Yolo holds only its hash. Each entry's hash is anchored on Base and mirrored to IPFS, so an inspector can prove the originator's record is the exact one logged, without trusting Yolo.
REGULATION
GDPR
Article 22 — Automated decision-making
EU · All AI decisions affecting EU data subjects
WHAT IT REQUIRES

Individuals have the right to obtain meaningful information about the logic involved in automated decisions and the right to contest those decisions.

WHAT YOLO PROVIDES
ENTRY PER AUTOMATED DECISION
One audit chain entry per decision affecting an individual.
TAMPER-EVIDENCE FOR DISPUTES
Cryptographic proof the entry has not been modified after the fact — critical when an individual contests the decision and the controller's logs are challenged.
CONTROLLER-INDEPENDENT VERIFICATION
The individual or their representative can verify the entry against the on-chain Merkle root without relying on the controller's cooperation.
REGULATION
HIPAA
Section 164.312(b) — Audit controls
US · Covered entities and business associates
WHAT IT REQUIRES

Covered entities must implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems containing electronic protected health information.

WHAT YOLO PROVIDES
PER-DECISION EPHI ENTRIES
Audit chain entries for every clinical AI decision touching protected health information.
TAMPER-EVIDENCE BEYOND REGULATORY MINIMUM
Append-only enforcement at the database trigger level exceeds the standard "tamper-evident" documentation requirement.
HIPAA AUDITOR ACCESS
Auditors receive permissioned read from the covered entity. Independent verification via public on-chain root.
HIPAA BAA
Available on request. Contact agents@yolo.solutions.
ENFORCEMENT CONTEXT

OCR enforcement precedent: Anthem $16M, Premera $6.85M, Excellus $5.1M. The audit chain is preventive infrastructure against these exposure amounts.

REGULATION
FDA
SaMD post-market surveillance
US · Software as Medical Device
WHAT IT REQUIRES

AI/ML-based SaMD must log algorithm inputs, outputs, and model version at every inference. FDA expects post-market surveillance evidence from production decision logs, not aggregated statistics.

WHAT YOLO PROVIDES
PER-INFERENCE ENTRY
Model version (ERC-8004 identity event), input hash, output hash, and confidence score in the payload.
TAMPER-EVIDENT CLINICAL DECISION LOG
High-stakes clinical decisions (diagnostic, therapeutic-consequence) are hash-logged and anchored on Base; the proof is independently reconstructible for FDA inspection. The clinical record itself is retained by the provider — under Strict-B, Yolo holds only its hash.
SUBMISSION EVIDENCE PACKET
Reproducible evidence for 510(k) and PMA submissions.
ENFORCEMENT CONTEXT

FDA April 2, 2026 Purolea Cosmetics warning letter — the first FDA letter to cite AI overreliance / lack of human oversight in regulated decisions as a cGMP deficiency (it did not allege missing audit trails). It makes "show me how this was generated, and who reviewed it" an enforcement-relevant question — which the audit chain entry answers.

REGULATION
NAIC Model Bulletin
AI Use in Insurance
US · ~24 states (over half) as of early 2026
WHAT IT REQUIRES

Insurers must document, audit, and explain AI-driven underwriting and claims decisions. Algorithmic explanations must be producible on demand.

WHAT YOLO PROVIDES
PER-DECISION ENTRY
One audit chain entry per underwriting or claims decision.
ADVERSE-ACTION SUPPORT
The model version is recorded in the entry; the data inputs, decision output, and rationale that support an adverse-action notice are retained by the originator and hash-committed to the entry (Strict-B: Yolo holds only hashes). The originator can produce them on demand and prove they match the logged decision.
COMMISSIONER ACCESS
State insurance commissioner access via permissioned read. Independent verification on-chain.
REGULATION
MiFID II
RTS 6 — Algorithmic trading records
EU · Regulated financial firms
WHAT IT REQUIRES

Records of all orders and transactions including the decision-making algorithm. Firms must be able to reconstruct each algorithmic trading decision from the log. Machine-readable format required.

WHAT YOLO PROVIDES
PER-TRADE DECISION ENTRY
Model version, inputs, output, timestamp at microsecond precision.
MACHINE-READABLE EXPORT
Open schema JSON export. ESMA examination via permissioned read.
RECONSTRUCTION WITHOUT TRUST
Neither the firm nor Yolo required to cooperate. Independent verification against the on-chain root.
REGULATION
SR 11-7 + FS AI RMF
Model risk management
US · Fed Reserve, OCC, FDIC supervised institutions
WHAT IT REQUIRES

Documented model risk management for AI/ML models affecting capital requirements, credit decisions, and risk weights. Internal audit and supervisor access to model decision logs expected.

WHAT YOLO PROVIDES
MODEL OUTPUT LOG
Audit chain entries serving as the model output log for supervisor access.
MODEL VERSION TRACEABILITY
Identity registry provides the model version traceability SR 11-7 requires.
MRM FRAMEWORK INTEGRATION
Fits within existing MRM frameworks. Yolo is the evidence substrate, not a replacement for the MRM process.
REGULATION
DSA
Article 15 — Algorithmic accountability
EU · Very Large Online Platforms (VLOPs)
WHAT IT REQUIRES

VLOPs must produce documentation of recommender system logic and automated moderation decisions. DSA audits by the European Commission can demand decision-level audit trails.

WHAT YOLO PROVIDES
DECISION-LEVEL ENTRIES
One audit chain entry per moderation decision: takedown, account action, demotion, age-gate.
ARTICLE 15 SPECIFICITY
Decision-level granularity provides the specificity Article 15 expects.
COMMISSION ACCESS
EC and Digital Services Coordinator access via permissioned read. Public verifiability via on-chain root.
TRANSPARENCY REPORT PROOF
Cryptographic proof that transparency reports correspond to actual decisions made.
ENFORCEMENT CONTEXT

DSA non-compliance: up to 6% of global annual turnover. For VLOP-tier platforms, exposure runs into the billions of euros.

REGULATION
FDA-EMA Joint Principles
Good AI Practice · January 14, 2026
US + EU · Drug development life cycle
WHAT IT REQUIRES

Ten principles for AI used to generate or analyze evidence across the drug development life cycle, including data provenance, transparency, bias control, traceable documentation, and risk-based credibility assessment.

WHAT YOLO PROVIDES
CROSS-LIFECYCLE ENTRIES
Audit chain entries for each AI decision in discovery, clinical trial design, safety signal classification, regulatory submission, and post-market pharmacovigilance.
CROSS-JURISDICTIONAL ANCHOR
The same on-chain root is independently verifiable by both FDA and EMA inspectors.
TAMPER-EVIDENT SUBMISSION DECISION LOG
High-stakes submission, safety-conclusion, and label decisions are hash-logged and anchored on Base — the proof is permanent and independently reconstructible. The underlying records are retained by the submitter; under Strict-B, Yolo holds only their hashes.

The audit chain produces evidence consumable by every regulator named across Yolo’s segment pages. For the specific obligation language, see the relevant segment at /for.

DoD AI Ethics Principles
Traceable and Governable directly addressable via audit chain and reputation oracle
EASA Part 145/M/CAMO + ARP-6983
Audit chain provides evidence at DAL-C; higher DALs require additional verification
NHTSA Standing General Order 2021-01
Decision-log substrate for crash reporting and AV STEP program participation
FCC + ITU + UN COPUOS
Orbital maneuver decision evidence for satellite operators
IMO MASS Code (entering force 2032)
Pre-builds evidence substrate for autonomous vessel operations
CFTC · SEC · FINRA · OCC · Federal Reserve
Model risk and algorithmic trading record requirements
State bar associations + LPL insurers
AI use documentation for malpractice and sanctions defense

One audit chain. Every jurisdiction.

The audit chain is jurisdiction-neutral by construction. A single on-chain Merkle root anchored on Base mainnet produces the record-keeping evidence every jurisdiction’s documentation requirement calls for, simultaneously. There is no regional log to reconcile, no jurisdiction-specific storage to maintain, no cross-border data transfer issue introduced by the audit infrastructure itself.

A multinational operator deploying AI across EU + US + UK + Singapore + Japan + Canada uses one audit chain. EU AI Act Article 12, US OMB AI memos, UK ICO AI guidance, Singapore MAS Veritas, Japan METI guidelines, and Canadian ISED framework all reference the same evidence artifacts.

Customer-side jurisdiction-specific export adapters convert the canonical entry format into each regulator’s preferred submission format. The underlying truth is one chain.

PUBLIC CHAIN VERIFICATION

Any regulator, plaintiff, or investigator with an audit chain entry hash can verify it against the on-chain Merkle root without Yolo’s cooperation. The verification path is documented at /methodology. This protects regulators from any future change in Yolo’s commercial posture, ownership, or jurisdiction.

PERMISSIONED READ ACCESS

Customer-controlled access to entries within the customer’s namespace. A HIPAA auditor reviewing a health system’s clinical AI decisions receives access from the health system, not from Yolo. An ESMA examiner reviewing a bank’s algorithmic trading records receives access from the bank. Yolo provides the substrate; the customer governs who reads their entries.

Public verifiability and permissioned content are not in tension — they address different parties. Verifiability without permission protects integrity. Permissioned content protects the customer’s commercial and privacy interests.

CERTIFICATION
STATUS
SOC 2 Type II
In progress
ISO 27001
Scoping
HIPAA BAA
Available on request
GDPR Article 28 DPA
Available on request
FedRAMP Moderate
Via partners
FedRAMP High
Roadmap
ISO 42001 (AI management)
Scoping
EU NIS2 Directive
Assessing applicability

For procurement requiring already-certified infrastructure before SOC 2 Type II completion, contact agents@yolo.solutions to discuss partner deployment or bridge contract options.

NOT A SUBSTITUTE FOR MODEL RISK MANAGEMENT.
The audit chain produces the evidence MRM frameworks require. It does not perform MRM. SR 11-7, Solvency II, GAMP 5, and similar frameworks impose responsibilities that remain with the customer.
NOT A REGULATORY ADVISOR.
This page explains how the audit chain maps to regulator requirements. It is not legal advice on whether a given AI deployment is in compliance. Engage qualified counsel for regulatory determinations.
NOT A SUBSTITUTE FOR HUMAN OVERSIGHT.
Article 14 of the EU AI Act requires human oversight features. Yolo documents the human oversight that occurs; it does not perform the oversight.
DOES NOT CERTIFY AI MODELS.
Identity registry events document model version changes. Reputation oracle scores reflect verified output history. Neither substitutes for model evaluation, bias testing, or safety review.
INCOMPATIBLE WITH CLASSIFIED DEPLOYMENTS UNDER CURRENT ARCHITECTURE.
Public-chain anchoring conflicts with TS/SCI and IL5/IL6 information handling requirements. A private-chain variant for classified deployments is on the architectural roadmap.
HOW YOU USE YOLO · COMPLIANCE & RISK TEAMS

Your AI makes decisions — underwriting, claims, clinical, credit — that a regulator can demand you produce and prove were not altered after the fact. Your own logs are only as trustworthy as your control over them. Yolo gives you a decision record neither you nor Yolo can alter undetectably — one a regulator can verify without trusting either of you.

Yolo produces the record-keeping evidence regulations like EU AI Act Article 12 require — tamper-evident, independently verifiable proof that a decision was made, when, and by which model. It does not make those decisions, judge them, or replace your model-risk process (see What Yolo is not, above).

1
See it's real — before you talk to us. No signup, no sales call. Open a live entry's public verification page — e.g. /verify/36 — or clone the open-source verifier and run it yourself against any record from Argus (Agent #001, our reference agent). Read the full architecture at /methodology and your sector's regulatory mapping at /for. You are confirming the infrastructure is real and independently checkable before committing anything.
2
Request access — private beta. Email agents@yolo.solutions. We register your AI system and issue you a scoped API key. We are in free private beta: deliberate, limited onboarding, no billing yet. The same conversation is where we share current certification status and a draft contract structure for your jurisdiction's data-residency and retention requirements.
3
Log a decision — one API call. When your AI decides, your system sends Yolo a hash of the decision — never the decision itself. One authenticated POST carries the tier, a SHA-256 hash you compute locally, and the model ID and version. Readable content is rejected by the API by design; Yolo holds that hash and non-identifying metadata, never the readable decision. Full integration reference at /developers/decisional-logging.
4
It's anchored — permanently. Your entry is hash-chained on write and, on the next anchor, folded into a Merkle root committed to Base mainnet. From that point the record cannot be altered — by you, by Yolo, by a future owner of Yolo, or by anyone — without leaving permanent, public evidence.
5
Anyone can verify it — without trusting Yolo. When a regulator, auditor, or your own counsel needs to confirm a decision, they hash the readable record you kept and confirm that hash appears in an entry anchored on Base mainnet — using the open-source verifier, with no Yolo cooperation, credential, or trust in us required. The verifier proves the entry is genuine and unaltered against the on-chain root; the matching hash proves the record you produced is the exact one logged.

Start here:see it's real → request a beta key → log your first decision → verify it publicly.

REQUEST EARLY ACCESS — PRIVATE BETA
agents@yolo.solutions →