AI Compliance Framework: Regulation to Evidence Calendar

Short answer: An AI compliance framework is neither a policy library nor a certificate. It is a working map that reads every rule that applies to you into four things — who owes it, who owns it internally, which artefact proves it, and when that artefact has to be produced — and keeps that map current as instruments are amended, systems are reclassified and new tools arrive.

Key takeaways

• A duty has an addressee before it has a control, and Article 25 of the EU AI Act can move an organisation from deployer to provider by branding a system or substantially modifying it.
• An obligation with no named owner and no cadence is a sentence, not a control.
• Dates decide when preparation starts: the prohibitions and the AI literacy duty applied from 2 February 2025, the general-purpose model chapter from 2 August 2025, the transparency duties from 2 August 2026, and the high-risk regime is deferred to 2 December 2027 and 2 August 2028.
• Evidence is produced on a cadence rather than on request, and a certificate covers a management system while an obligation is discharged by evidence from your own operation.

---

ai compliance framework: the map, not the policy library

Most teams asking for a framework already own the two things mistaken for one: a policy set in a document store, and a stack of vendor claims. Neither says which rule currently binds which team, which artefact answers it, or when that artefact is due.

The working definition here is small. A framework is three artefacts and one discipline:

1. A source list with versions. Every instrument that reaches your systems, named with the article or control a reviewer is likely to quote, stamped with the revision you read.
2. An obligation register. One row per obligation, not per instrument: what is owed, by which role, by whose hand, proved how, due when.
3. A delivery calendar. The cadence on which each row's evidence is produced, signed and filed — because a duty discharged once is a duty discharged by accident.

The discipline is the review: a register without a next-review date is a snapshot, and snapshots do not survive a changed model, a changed tool or a changed law.

Two scoping notes. The layered design of policy, roles, technical controls and evidence — and which layer owes which artefact — belongs to the AI governance framework treatment, and the enforcement point that makes a mapped control bite belongs to the control plane; this page owns the mapping dimension only. And where an obligation concerns untrusted input reaching a prompt, the mechanism sits on the secure prompt handling side of the cluster.

ai governance framework: which instrument supplies which obligation

Sourcing starts by reading each instrument for four things: the role it addresses, the trigger that makes it bind, the output it requires, and its application date. Skip the addressee and you build a register of duties nobody owes.

Instrument	What it obliges in an AI context	Addressee
EU AI Act, provider duties (Arts. 9-15, 17, 18, 19)	Risk management system, data governance, technical documentation, event recording, human oversight, robustness and a quality management system; documentation available for ten years; logs kept at least six months inside the provider's control	Provider of a high-risk system
EU AI Act, deployer duties (Art. 26)	Use per instructions, competent human oversight, log retention under the deployer's own control, information to workers and their representatives	Deployer
EU AI Act, value chain (Art. 25)	Branding a system or substantially modifying one transfers the provider's obligations to that party	Whoever crossed the line, from that date
EU AI Act, transparency and impact (Arts. 26-27, 50)	Disclosure of AI interaction, machine-readable marking of synthetic output, impact assessment for the listed public-interest deployments	Listed providers and deployers
EU AI Act, post-market and incidents (Arts. 72, 73)	Post-market monitoring plan; serious-incident reporting inside fifteen days, two days for a widespread infringement	Provider
NIST AI RMF 1.0 (GOVERN 1.1, MAP 1.5, MANAGE 4.1)	Voluntary: a documented legal and regulatory baseline, requirements understood per system, a post-deployment monitoring plan naming events and thresholds	The organisation, per system
ISO/IEC 42001 (cl. 9.1-9.3, Annex A.6), ISO/IEC 27001 (A.5.31, A.5.34), ISO 37301 (cl. 4.5, 9.1)	A management system with objectives, operational control, monitoring and management review; legal, statutory and contractual requirements identified and kept current; compliance obligations evaluated on a schedule	Compliance and security functions
GDPR (Arts. 22, 30, 35) and sector rules such as DORA (Arts. 19, 28)	Safeguards for automated decisions, records of processing, impact assessment for high-risk processing, incident reporting, a register of ICT third parties	Controller, or the regulated financial entity
Employment and consumer statutes: New York City Local Law 144, Illinois AIVIA, Colorado SB 24-205	Published bias audit, candidate notice and consent for video analysis, reasonable care with an impact assessment and an annual review	Employer or deployer that signs the contract

Two observations follow. The same technical fact lands in different rows because the addressee differs — a log store is an obligation for a provider, an operational control for a deployer and a processing record for a controller — and roles are per system rather than per company.

ai governance compliance: from a clause list to an obligation register

A clause list is what most teams have after reading the law: an instrument name, a page number and an uneasy feeling. The register is what makes it operational, and its columns are the deliverable.

Column	What goes in it	The failure it prevents
Source and version	Instrument, article or control, and the revision you mapped	A silent hole after an amendment
Addressee	The role obliged: provider, deployer, controller, employer	A duty carried by nobody, or by the wrong team
Trigger and scoping facts	The classification, data class, geography and autonomy level that made the row apply	A duty asserted with no test behind it, and no way to withdraw it
Obligation in plain language	One sentence with an actor and a verb, never a paragraph of statute	Legal text ships instead of a task
Owner, deputy and reviewer	Named roles, never a team name	An orphan row that outlives the person who cared
Control and evidence artefact	The thing that operationally satisfies the row, and the artefact that proves it	A mapped obligation with nothing behind it
Cadence	Daily, monthly, quarterly, annual, event-driven, or per release	Evidence that exists once and then ages out
Effective date, status and review date	Applies, not applicable with the reason, deferred with a date, met by control X; plus when the row is re-read	A deadline missed quietly, or a map that was true in the quarter it was written

Three conventions make the register usable. Write duties with an actor ("the deployer keeps the logs under its own control for at least six months"), never as summaries ("log retention"), because a summary cannot be assigned. Keep "not applicable" rows with the reason and the date they were judged, since the judgement is itself evidence. And separate the obligation from the control that satisfies it, so changing a control does not rewrite the obligation.

Register quality shows before an audit does. A register with no "not applicable" rows was built by searching for anything that sounds relevant; one whose owner column holds team names will lose a row at the next reorganisation. How each row's evidence is handed over — the record's own schema and export — is the subject of AI compliance; the register decides what must exist, that page decides what it looks like.

ai compliance certification: where a certificate sits in the obligation map

Certificates are evidence, and the register has a column for evidence, so the mapping question is narrow: which obligations may cite this artefact, and what stays outside it? Almost every mistake here is a scope error rather than a paperwork error.

A management-system certificate attests that an organisation operates a defined system against a standard, within a stated scope — the entities, sites and activities the certification body assessed. It is one row's evidence for the obligations the standard covers. It is not evidence per obligation: it does not show that a particular deployment was overseen by a competent person, that an incident was reported inside its window, or that a row is still accurate.

Four habits follow. Record the scope: the entities and systems covered, the standard and edition, the body and its accreditation, the issue and expiry dates — an out-of-scope system claiming the certificate is the first finding a reviewer writes. Bridge rather than assert: for each obligation the certificate should cover, name the clause and the internal control that maps to it. Keep operational rows independent, because certification is periodic while several obligations are continuous. Write the claim no wider than the artefact: "certified to standard X, scope: entities A and B, valid to date Y" is defensible, while "compliant" is a conclusion about a system in use that no body issues. The materials behind AI compliance certification cover what a certificate can and cannot attest; the mapping point is simpler — a certificate answers an evidence column, it does not fill the register.

ai agent audit: writing the obligation down when the actor is software

Accountability does not transfer to software, so an obligation whose described actor is "the agent" is incomplete. Three adjustments turn agentic rows into something a person can own.

The human-oversight row names a person and a mechanism. Where oversight is required, the requirement is about effectiveness rather than presence: oversight that understands the system's limits, is aware of automation bias, and can interrupt or override. As a row that becomes three facts — who is competent and currently assigned, what the intervention path is, and what proves the path was exercised, because an untested override is an untested control.

Accountability stays with the role that deployed the system. An agent that picks its own tools and runs multi-step tasks changes the fact pattern — autonomy level, tool set, whether access or money moved — and those facts belong in the scoping column, because they decide whether a lighter or a heavier duty applies. They do not create a new addressee.

Identity is part of the control, not only of the record. An obligation is discharged against a version: the instructions, tool set and model behind an agent identity are all part of what acted, so a row that says "the assistant" cannot be tested a year later. Register the agent as a system with a version, and each capability it reaches as a capability entry, which turns a behaviour change into a scope change instead of a surprise.

Where an agent works inside a regulated activity, obligations normally attach to the regulated institution rather than to the tool's vendor, and its duty is to show which authorised actor used which capability. That is why agents used for financial data analysis belong in a register whose owner column names a function with a mandate, not a project team: a supervisory finding is answered by the institution's own control, and a vendor's dashboard is a supporting artefact at best.

ai audit trail: the evidence class each obligation asks for

"A log" is not a category. Obligations ask for recognisably different artefacts, and a register that names them precisely turns an audit into retrieval rather than reconstruction.

Obligation class	Evidence class it asks for	Typical cadence
Scoping and classification	A dated scoping memo naming the system, the facts relied on and the role conclusion	Per system, on entry and on change
Risk management and design	A versioned risk assessment and technical documentation, held with the version they describe	Per release
Data and privacy	Records of processing, impact assessment, retention rule per field, lawful basis	On change, reviewed annually
Human oversight	A named-and-competent roster, the intervention path, a test record showing the override works	Per assignment, tested on a schedule
Monitoring	The monitoring plan with thresholds, and minutes showing someone acted on it	Monthly or quarterly
Incidents	An incident file: timeline, affected population, the reporting decision, the notice sent	Inside the statutory window
Third parties	A vendor and sub-processor register, contractual terms, attestation, exit plan	Onboarding, then annually
Change and training	A change-log entry with a re-scoping note, and completion records per role	Per change, per year

Two disciplines make the table usable. Every artefact needs a home, because an evidence class with no owning system gets recreated under deadline pressure and a recreated artefact is not evidence. And every artefact needs a delivery route that does not depend on the person who made it: a register entry saying "ask Dana" is a single point of failure, while one naming a store, a schema version and an export path survives a departure.

Note the deliberate boundary: this table names classes. The fields one row of the per-call record must carry, and how retention is chosen against a statutory floor, are the evidence-trail work owned beside AI agent security in this cluster, and a register that tries to specify fields drifts out of date the first time the schema version changes.

mcp logging: tool-level obligations and the third party behind them

The moment an agent reaches a tool hosted by someone else, a compliance question appears that has nothing to do with logging libraries: who owes what to whom about the data crossing that boundary? Tool servers range from open-source processes inside your own network to hosted services run by a supplier, and the register has to tell those apart. For a self-hosted server the data stays inside your perimeter and the obligations are your own; for a hosted one, four rows follow almost immediately.

• The processing row. Which party determines the purpose of the data crossing the boundary, what the supplier may do with it, the transfer mechanism for cross-border movement, and which sub-processors sit underneath. Tool arguments and results frequently carry personal data even when nobody thinks of the integration as a data flow.
• The retention row, with the store named. A supplier's own logs are the supplier's records, kept under the supplier's policy, and a supporting artefact at best. Any duty that requires you to keep something requires your store, so the evidence artefact must name a system you control rather than an interface you call.
• The capability-inventory row. Which servers are registered, which tools each exposes, and when a tool's description or input schema last changed. A rewritten description is a scope change, because the text the model reads has changed, and a scope change triggers a review rather than a silent deployment.
• The exit row. What happens to the record and the integration when a supplier withdraws a server, changes terms or disappears. An obligation satisfiable only by a third party's continued cooperation is a risk entry and belongs in the register.

One shortcut to avoid: treating the protocol as a compliance mechanism. A transport specification cannot promise that a line was written, that it was kept for a statutory period, or that a supplier will hand it back. The mapping requirement is only that the row names a store you control.

agent observability: the signals that mean the obligation map has drifted

A register decays faster than the systems it describes, because it is the only artefact nobody notices going stale. The answer is not a review culture but a short list of triggers, each of which already announces itself somewhere in the estate.

• An instrument changed. Amendments, delegated acts, guidance and new regulator FAQs move dates and add duties; the version column makes the change visible instead of theoretical.
• A system's facts changed. A new model version, data class, geography or autonomy level can move a system between classifications, which is a re-scoping event and a new scoping memo.
• The role changed. Branding a system, substantially modifying it or reselling it under your own name moves obligations from a partner's column to yours, and the date matters.
• The estate changed. A new tool server, supplier or region, or a retired integration, adds or removes rows and leaves an inventory diff a monitoring layer already computes.
• An incident, a finding or a questionnaire. A refused call, an unexpected denial, a diligence request or an auditor's observation is feedback on the adequacy of the controls the register claims.
• A deferred deadline arrived. Rows parked as "deferred with a date" are the ones that go missing; the date is the trigger, and the review is what keeps a deferral honest.

Observability here is not the alert set an engineer watches but the drift signal a compliance owner needs: one event stream answers both questions. The register's review log records the readings and the decision, and the register is read against the estate's current inventory — the diffs are where unrecorded changes live.

The delivery calendar: who signs what, and when

Everything above becomes real when a person has to produce something for someone else. Working back from that moment, the calendar has five rhythms, and the two that fail most often live outside the audit season.

Rhythm	What is delivered	Owner	Recipient
Event-driven	Incident notices inside the statutory window, re-scoping notes, change records	System owner, with the compliance function told the same day	Regulator where required, internal audit, customers
Monthly	Control-operation evidence: refusals and overrides, limit events, inventory diffs	Platform or security function	Register owner, service management
Quarterly	Register review: overdue rows, deferred dates, supplier changes, new tools	Compliance function with system owners	Management, internal audit
Annual	Management review and sign-off, impact-assessment refresh, training completion, supplier reassessment	Executive owner of the AI programme	Board or risk committee, external auditors
Per release or certification cycle	Versioned documentation, the evidence pack for the period under review, the bridge from certificate to register	System owner and compliance function jointly	Certification body, customer diligence, regulator

Three things keep a calendar alive through a busy quarter: every delivery names a role and a deputy, built at the start rather than borrowed in the week it is due; every delivery names an output and a store, so a period's pack is assembled from artefacts rather than written from memory; and the calendar is checked against what actually happened.

One operational fact belongs on the calendar rather than in a policy: where evidence retention depends on a platform tier, the tier is a procurement input. A record readable only for the length of its retention window has to be exported before it disappears, so the export gets its own dated line. Any ceiling a platform counts on your behalf is a commercial limit, not a guarantee about a duty.

Where SmartGate fits in the obligation map

The mapping work stays with the customer. What a governed gateway contributes is one row's worth of production and one row's worth of scope control: a single place where calls are recorded, attributed to a key and a team, and exportable, instead of four client libraries each keeping something different, plus a control point where a capability can be narrowed, a key revoked and a new server registered deliberately — which converts several rows from "we intend not to" into "it is not possible without a change record".

The limits are published facts and belong in the register as such. The plan table lists four tiers with monthly token ceilings of 2M, 20M, 100M and 200M+, MCP requests per minute per key of 120, 300, 600 and 1200, audit-log retention of 7, 30, 90 and 180 days, and a maximum of 2, 10, 30 and 9999 keys per team; the pricing page is authoritative and the version to quote.

Two cautions. A retention tier is a technical ceiling on readability, not an opinion about how long your duty lasts: where a duty runs longer than the tier, the calendar's export line closes the gap. And recording a call is not discharging an obligation — the register still needs an owner, a cadence and a reviewer.

Limitations

This page describes how to map published instruments into internal obligations and when the resulting evidence has to be delivered. It is not legal advice: it does not decide whether a system is high-risk, which role your organisation plays for a given system, which obligations follow from your contracts, or how long you must keep a record. Those depend on the system, the use, the jurisdiction and the counterparties, and the current text of each instrument is the only authority for them.

The tables are a mapping aid rather than a conformance verdict. Clause and control identifiers are quoted so a reader can find the source text, and an obligation is satisfied by an operating practice over time rather than by the existence of a row. Framework texts are revised — the Act has been amended once already and its high-risk dates have moved — so verify the current version before relying on a date here.

Nothing on this page claims that any product, plan or configuration satisfies a regulation, a framework or an audit. The plan figures quoted are commercial limits read from the published plan table on 2026-09-30, not statements about a duty, and no legal, retention or assurance opinion is offered.

The page carries no code excerpt, and the reason is in the Method note below: the slice matcher found no unique symbol for any of its eight sections.

Sources

• Regulation (EU) 2024/1689 (AI Act) — Article 25, responsibilities along the AI value chain, Article 26, obligations of deployers, Article 72, post-market monitoring and Article 113, application dates, read on 2026-09-30 for the role split, the reporting windows and the phased dates.
• Regulation (EU) 2026/1744 (the Digital Omnibus on AI), for the amended high-risk timetable: the Annex III regime moved to 2 December 2027 and the Annex I regime to 2 August 2028, as reflected in the Commission's implementation timeline.
• NIST AI Risk Management Framework 1.0 (NIST AI 100-1), for GOVERN 1.1, MAP 1.5 and MANAGE 4.1 — the framework core.
• ISO/IEC 42001:2023, clauses 9.1-9.3 and Annex A.6; ISO/IEC 27001:2022 controls 5.31 and 5.34; ISO 37301:2021 clauses 4.5 and 9.1 — the closest formal model of the register described here (iso.org).
• GDPR Articles 22, 30 and 35 — EUR-Lex; Regulation (EU) 2022/2554 (DORA) Articles 19 and 28, for the sector rows a financial entity carries in parallel.
• New York City Local Law 144, Illinois AIVIA and Colorado SB 24-205, used as worked examples of deployer-side rows.
• Demand figures are our own measurements: DataForSEO Google Ads, United States, 12-month window, measured 2026-09-30, recorded in this project's search_volume.json and research_brief.md.

Method note

This page carries no code excerpt, and that is a finding rather than an omission. The slice matcher recorded 0 of 8 sections pinned for this page (0 abstention(s), 8 no-slice verdict(s)): rule A found no unique symbol for any of the eight section keywords, because this lane's vocabulary (compliance, framework, governance, audit) collides with generic page and type names across a product codebase. The nearest candidates for the head phrase were a marketing page component, a metadata helper and two unrelated helpers. A pinned generic would have given the page the shape of a verified article with none of the substance, so every section above is written from the sources listed.

Product claims were read read-only from the product source at the revision the slice run recorded in this project's pipeline_results.json, and the plan figures were re-verified against the live pricing page on 2026-09-30. Clause numbers, control identifiers and application dates were re-read on that date from the instruments listed under Sources. No task identifiers, batch fingerprints, auction data or internal hosts are transcribed, so there is nothing here that has to be asserted verbatim.