Annex B

Annex B. Model and System Registry Schema

Version	1.0
Current as of	June 4, 2026
Document owner	AI Governance Committee
Publication status	Illustrative operating model for a hypothetical company. This annex is not legal advice, does not create an attorney-client relationship, and should be adapted to the Company's sector, market footprint, regulatory perimeter, system architecture, procurement process, contracts, and risk appetite before implementation.

Section 1

Purpose

The registry is the Company's single authoritative inventory of AI systems in scope. It connects the system a team wants to build, buy, fine-tune, embed, deploy, or repurpose to the evidence the Company needs when Legal, Security, Privacy, Procurement, Audit, the board, a regulator, a customer, or an incident-response team asks what the system is, who owns it, what it does, what data it uses, what risk tier it carries, what controls it cleared, and whether it is still behaving as approved.

The registry is not a spreadsheet of interesting models. It is the control record that ties intake, classification, review gates, vendor diligence, deployment authorization, monitoring, and escalation into one operating system. If a system cannot be found in the registry, the Company should treat it as unapproved until the AI Governance Office confirms otherwise.

Section 2

Registry Scope

The registry must include every AI system that falls inside the playbook scope, whether built internally, fine-tuned from a third-party foundation model, procured from a vendor, embedded inside existing software, exposed through a product feature, used by a business team, used in legal work, or operated as an agentic workflow.

Included record type	Registry treatment	Reason
Internally built model or AI system	Full system record with lineage, data, evaluation, controls, monitoring, and owner fields.	The Company owns design choices, testing, deployment, and change control.
Fine-tuned or adapted third-party model	Full system record with base-model lineage, adaptation data, provider-status analysis where relevant, and vendor evidence.	Adaptation can change legal role, technical risk, and evidence obligations.
Procured AI product or vendor feature	Full system record linked to vendor diligence and contract evidence.	The Company must govern the deployed use even when the vendor built the model.
Embedded AI inside licensed software	Full or simplified record depending on tier, always linked to procurement evidence and feature activation date.	Shadow AI often enters through existing software.
Retrieval-augmented generation system	Full system record with model, retrieval corpus, data source, access-control, and evaluation fields.	The risk often sits in retrieval sources and permissions, not only in the model.
Agentic workflow	Full system record with tool permissions, action boundaries, logs, rollback, kill switch, and monitoring fields.	Systems that act require stronger operational control than systems that answer.
Public or customer-facing generative AI feature	Full system record with disclosure, provenance, content-safety, abuse monitoring, and release evidence.	Public exposure creates disclosure, misuse, brand, consumer, and regulatory risk.
Minimal-risk approved tool use	Simplified record with owner, approved environment, use limits, data restrictions, and sample-audit cadence.	Low-risk use still needs inventory and reassessment triggers.

Section 3

Required Registry Principles

Principle	Operational requirement	Failure prevented
One system, one record	Every system has one authoritative registry ID. Multiple use cases can attach to that system record.	Duplicate records, inconsistent approvals, and unclear incident ownership.
Use-case granularity	A system with materially different uses must carry separate use-case entries under the same system record.	A low-risk use masking a high-risk use.
Evidence-linked fields	Fields that assert compliance, testing, diligence, or approval must link to the underlying evidence.	Empty compliance labels with no proof behind them.
Lifecycle status	The registry must show whether the system is proposed, in review, approved for evaluation, approved for deployment, live, suspended, retired, or rejected.	Approved pilots becoming uncontrolled production systems.
Owner accountability	Every live or approved system must have a use-case owner and accountable executive.	Diffuse responsibility when a system fails or drifts.
Time-bound review	Every classification, approval, exception, and monitoring record must have a date and next review trigger.	Stale approvals surviving after risk changes.
Change traceability	Material changes must create a new review entry or version record, not overwrite the old record.	Loss of evidence when the system changes.
Auditability	The registry must preserve who changed what, when, and why.	Inability to reconstruct decisions under audit or incident pressure.

Section 4

Core Data Schema

The schema below is the minimum viable enterprise registry. The Company may add fields, but it should not remove a field unless the AI Governance Committee documents why the field is not relevant to the Company's sector, posture, or deployment model.

Field	Type	Required for	Validation rule	Why this field matters
Registry ID	Unique identifier	All records	System-generated, immutable, and never reused.	Lets intake, contracts, gates, incidents, audits, and dashboards reference the same system.
System name	Text	All records	Plain-language name, unique enough to distinguish the system from similar tools.	Prevents vague references to vendor products, pilots, or internal nicknames.
System description	Text	All records	Must state what the system does, what output it produces, and what workflow or decision it affects.	Anchors the record to actual behavior rather than vendor or model branding.
System type	Controlled value	All records	Build, fine-tune, adapt, procure, embed, deploy, RAG, agentic workflow, public generative feature, or mixed.	Determines which diligence, lineage, vendor, and role fields apply.
Use-case ID	Unique identifier	All use cases	Required when one system supports more than one use.	Allows one system to carry multiple tiered uses without blurring their controls.
Use-case description	Text	All records	Must state the decision, recommendation, action, content, or workflow affected.	Drives risk classification and prevents model-level classification.
Use-case owner	Person	All records	Named individual, not a team mailbox.	Assigns operational accountability.
Accountable executive	Person	Limited-risk, high-risk, live systems, exceptions	Named executive, partner, or senior owner.	Identifies residual-risk owner and Gate 3 approver.
Submitting team	Controlled value	All records	Business unit, product group, legal team, practice group, corporate team, or engineering group.	Routes reviews, dashboards, and ownership reporting.
Sector path	Controlled value	All records	Finance, Tech, Law Firm, Other, or Healthcare review needed.	Selects sector examples, gate alignment, and regulatory overlays.
Posture	Controlled value	All records	Builds, deploys, or both.	Determines whether provider, deployer, vendor, and lineage controls attach.
Jurisdiction path	Controlled value	All records	NY, CA, International, more than one, or none yet for approved internal evaluation.	Selects statutory overlay and render path.
EU-market activity	Controlled value	All records	Yes, no, unclear, or not yet assessed.	Separates EU-market obligations from the generic International path.
California-facing activity	Controlled value	All records	Yes, no, unclear, or not yet assessed.	Routes California training-data, transparency, privacy, and generative AI review where applicable.
New York-facing activity	Controlled value	All records	Yes, no, unclear, or not yet assessed.	Routes NYDFS, NYC employment, and New York statutory review where applicable.
Other regulated markets	Text	Limited-risk, high-risk, external-facing systems	Required if non-U.S., federal, sector, customer-contract, or other market obligations are known.	Captures obligations outside the three front-end jurisdiction paths.
Risk tier	Controlled value	All records	Prohibited, high-risk, limited-risk, minimal-risk, provisional pending evidence, out of scope, or rejected.	Drives gates, controls, review cadence, and reporting.
Classification date	Date	All records	Required when risk tier is assigned or changed.	Shows whether a classification is current.
Classification owner	Person	All records	AI Governance Office reviewer or Committee owner.	Preserves who made the tier determination.
Classification evidence link	Link	Limited-risk, high-risk, prohibited, contested, exceptions	Must link to Annex C record, scoring worksheet, or Committee decision.	Prevents unsupported tier labels.
Lifecycle status	Controlled value	All records	Proposed, intake incomplete, in review, evaluation approved, deployment approved, live, suspended, retired, rejected, prohibited, or out of scope.	Shows what the system may do right now.
Environment	Controlled value	Evaluation, pilot, live systems	Sandbox, development, staging, internal pilot, production, customer-facing, public, or retired.	Prevents pilots and experiments from becoming undocumented production systems.
Launch or activation date	Date	Evaluation, pilot, live systems	Required before deployment authorization.	Connects approval to actual release.
Next review date	Date	All active records	Required before any system can move to live status.	Forces periodic reassessment.
Reassessment triggers	Text or controlled list	All active records	Must include material changes to purpose, population, data, model, vendor, market, scale, oversight, autonomy, and output audience.	Reopens governance when operating facts change.
Affected population	Controlled list plus text	Limited-risk, high-risk, external-facing systems	Customers, clients, applicants, employees, patients, users, minors, protected groups, vulnerable groups, public, or other.	Routes fairness, notice, remedy, and sector controls.
Decision or workflow affected	Text	All records	Must identify the business, legal, product, operational, customer, employment, health, or security process affected.	Determines consequence severity.
Human-oversight design	Text plus controlled value	Limited-risk, high-risk, agentic, external-facing systems	Must identify reviewer, review timing, override right, logging, and escalation path.	Distinguishes advisory output from controlled reliance or automated action.
Autonomy level	Controlled value	All records	None, recommendation only, bounded action with approval, bounded action without approval, or external action.	Routes agentic controls, rollback, kill switch, and security review.
Tool permissions	Structured list	Agentic systems	Required for every tool, API, workflow, system, data store, communication channel, transaction, or permission the system can access.	Makes blast radius visible.
Kill switch or suspension path	Text	High-risk, agentic, live external-facing systems	Must identify who can stop the system, how fast, and through which control.	Converts emergency stop from aspiration into procedure.
Input data sources	Structured list	All records	Must identify source, owner, category, system of record, and update cadence where known.	Supports data rights, lineage, and monitoring.
Data categories	Controlled list	All records	Public, internal, personal, sensitive personal, biometric, PHI, NPI, privileged, client confidential, credentials, security logs, trade secrets, regulated records, or other.	Triggers Legal, Privacy, Security, confidentiality, and healthcare controls.
Data-rights status	Controlled value	Limited-risk, high-risk, vendor, build, fine-tune, RAG, external-facing systems	Cleared, conditional, blocked, not assessed, or not applicable.	Prevents systems from advancing on unverified data rights.
Data location	Structured list	Systems using non-public data	Storage, processing, logging, retention, hosting, transfer, and vendor location where known.	Supports privacy, security, cross-border, and contract review.
Retention and logging rule	Text	Limited-risk, high-risk, external-facing, vendor, agentic systems	Must state prompt, input, output, log, and review-record retention.	Prevents hidden data accumulation and unsupported deletion practices.
Foundation model lineage	Structured list	Build, fine-tune, adapt, RAG, public generative feature	Base model, version, provider, license, release date if known, and dependency notes.	Makes inherited risk, vulnerabilities, license changes, and vendor changes traceable.
Training or fine-tuning data	Structured list	Build, fine-tune, adapt	Dataset name, source, owner, rights status, sensitive categories, and documentation link.	Supports provenance, bias, transparency, and provider-grade evidence.
Retrieval sources	Structured list	RAG systems	Corpus, system of record, access-control model, freshness, owner, and exclusion rules.	Controls hallucination, permission leakage, stale retrieval, and confidentiality exposure.
Vendor name	Text	Vendor or procured systems	Required where any third-party system, model, feature, or hosted tool is used.	Links running system to third-party evidence.
Vendor product or feature	Text	Vendor or procured systems	Required and specific to the AI feature, not only the product suite.	Prevents generic vendor approval from covering an unreviewed AI feature.
Contract reference	Link or ID	Vendor or procured systems	Must link to governing agreement, SOW, order form, DPA, security exhibit, AI terms, or renewal record.	Connects deployment to audit rights, restrictions, and liability allocation.
Vendor diligence status	Controlled value	Vendor or procured systems	Not started, in progress, cleared, cleared with conditions, blocked, expired, or not applicable.	Prevents deployment before diligence completion.
Vendor evidence link	Link	Limited-risk and high-risk vendor systems	Must link to model card, system card, evaluation, security evidence, training-data documentation, limitations, and change-notice terms where available.	Shows whether the Company has evidence to rely on the vendor system.
EU AI Act role	Controlled value	EU-market activity yes or unclear	Provider, deployer, importer, distributor, product manufacturer, more than one, unclear, or not applicable.	Determines obligation set.
EU role evidence link	Link	EU-market activity yes or unclear	Must link to role analysis and Article 25 analysis where relevant.	Prevents provider and deployer obligations from being discovered late.
Transparency or notice requirement	Controlled value plus text	Limited-risk, high-risk, public generative, employment, customer-facing systems	Required, not required, unclear, or not applicable, with owner and evidence link.	Controls user interaction, synthetic-content, employment, and affected-person notice.
Evaluation status	Controlled value	Limited-risk, high-risk, external-facing, built, fine-tuned, vendor systems	Not required, planned, in progress, passed, passed with conditions, failed, expired, or not applicable.	Shows whether Gate 2 evidence exists.
Evaluation evidence link	Link	Limited-risk and high-risk systems	Must link to performance, bias, robustness, security, red-team, or spot-check results as applicable.	Keeps evidence with the system record.
Bias or fairness review status	Controlled value	Employment, financial, high-risk, affected-population systems	Not required, planned, in progress, passed, passed with conditions, failed, expired, or not applicable.	Supports fairness and anti-discrimination review.
Security review status	Controlled value	Vendor, production, external-facing, sensitive-data, agentic, high-risk systems	Not required, planned, in progress, passed, passed with conditions, failed, expired, or not applicable.	Controls cybersecurity, access, integration, and abuse risk.
Privacy review status	Controlled value	Personal-data, sensitive-data, employee, customer, patient, public-facing systems	Not required, planned, in progress, passed, passed with conditions, failed, expired, or not applicable.	Controls data-use, notice, retention, transfer, and privacy obligations.
Legal review status	Controlled value	Limited-risk, high-risk, prohibited, vendor, regulated, public-facing systems	Not required, planned, in progress, passed, passed with conditions, failed, expired, or not applicable.	Captures legal-risk ownership without making Legal the owner of the whole system.
Gate status	Structured list	All records	Gate 0, Gate 1, Gate 2, Gate 3, and Gate 4 status, with owner, decision, date, and evidence link.	Shows where the system stands in the lifecycle.
Conditions before release	Text	Limited-risk, high-risk, conditional approvals	Must state required actions, owners, and due dates.	Prevents conditional approvals from becoming unconditional releases.
Residual-risk owner	Person	High-risk, exceptions, deployment authorization	Named accountable executive, partner, or senior owner.	Makes risk acceptance explicit.
Monitoring configuration	Structured list	Limited-risk, high-risk, live systems	Metric, threshold, owner, cadence, data source, alert path, and review date.	Turns monitoring into a managed control.
Last monitoring review	Date	Live systems	Required at cadence set by tier.	Shows whether monitoring is active.
Linked incidents	Link list	Systems with incidents, complaints, drift, audit issues, inquiries	Must link incident ID, date, severity, status, and outcome.	Allows pattern analysis and reclassification.
Exception status	Controlled value	Exceptions or urgent evaluations	None, requested, approved, approved with conditions, denied, expired, or revoked.	Tracks departures from the normal control path.
Exception evidence link	Link	Exceptions	Must link to business justification, scope limits, expiration date, and approver.	Prevents exception drift.
Retirement date	Date	Retired systems	Required when lifecycle status is retired.	Shows when the system left production.
Retirement evidence	Link or text	Retired systems	Must state shutdown, data disposition, vendor termination or feature disablement, and remaining obligations.	Prevents abandoned systems from retaining access or data.
Audit log	System-generated	All records	Must preserve create, edit, approval, status change, and deletion events.	Makes the registry defensible.

Section 5

Controlled Values

The registry should use controlled values wherever inconsistent wording would undermine reporting. Free text may explain a value, but it should not replace the controlled value.

Field	Controlled values
Risk tier	Prohibited; high-risk; limited-risk; minimal-risk; provisional pending evidence; rejected; out of scope.
Lifecycle status	Proposed; intake incomplete; in review; evaluation approved; deployment approved; live; suspended; retired; rejected; prohibited; out of scope.
System type	Build; fine-tune; adapt; procure; embed; deploy; RAG; agentic workflow; public generative feature; mixed.
EU AI Act role	Provider; deployer; importer; distributor; product manufacturer; more than one; unclear; not applicable.
Review status fields	Not required; not started; planned; in progress; passed; passed with conditions; failed; expired; not applicable.
Autonomy level	None; recommendation only; bounded action with approval; bounded action without approval; external action.
Data-rights status	Cleared; conditional; blocked; not assessed; not applicable.
Exception status	None; requested; approved; approved with conditions; denied; expired; revoked.
Environment	Sandbox; development; staging; internal pilot; production; customer-facing; public; retired.

Section 6

Required Evidence Links

The registry must not become a place where teams type "complete" without attaching proof. The following evidence links are mandatory when the condition applies.

Condition	Required evidence link
Any risk tier other than minimal-risk	Annex C classification record.
High-risk classification	Annex C trigger analysis, scoring worksheet, Gate 1 evidence, Gate 2 validation evidence, Committee decision, and residual-risk acceptance if deployed.
Prohibited classification	Prohibited-use screen, Legal review, Committee confirmation, and refusal rationale.
Vendor or procured system	Vendor diligence checklist, contract reference, security evidence, data-use terms, change-notice terms, and vendor documentation.
Fine-tuned or adapted model	Base-model lineage, training or fine-tuning data record, data-rights analysis, evaluation results, and provider-status analysis where EU-market activity exists.
EU-market activity	EU role analysis, high-risk classification analysis, Article 25 analysis where relevant, transparency analysis where relevant, and serious-incident route.
Public generative AI feature	Disclosure or provenance assessment, content-safety review, abuse testing, training-data documentation review where applicable, and complaint path.
Employment system	AEDT or employment-law analysis where applicable, bias-audit evidence where required, notice path, human-review design, and annual review date.
NYDFS-covered financial institution	Part 500 control mapping, third-party service-provider assessment if vendor system, NPI review where applicable, and incident route.
Healthcare or patient-impact system	Healthcare escalation record, HIPAA or data-use review, FDA or SaMD screen where applicable, clinical validation plan, and patient-safety monitoring.
Agentic workflow	Tool-permission matrix, approval gates, action logs, rollback procedure, kill switch, abuse cases, and monitoring thresholds.
Exception or urgent evaluation	Exception request, approver, scope limits, approved data, expiration date, monitoring owner, and prohibition on production or external effect if applicable.

Section 7

Registry Workflow

Workflow stage	Owner	Registry action	Exit condition
Intake opened	Use-case owner	Create draft record with intake ID, owner, system name, status, and initial description.	Intake form complete or closed as out of scope.
Provisional classification	AI Governance Office	Add provisional tier, classification owner, affected population, data categories, posture, jurisdiction, and required addenda.	Route assigned.
Evidence collection	Use-case owner with Legal, Security, Privacy, Procurement, validation owner, or sector reviewer	Attach required evidence links and update review status fields.	Required evidence complete or intake hold issued.
Gate review	Gate owners	Record gate decision, conditions, owner, date, and evidence link.	Gate passed, passed with conditions, failed, or escalated.
Deployment authorization	Accountable executive or Committee	Update lifecycle status, release conditions, residual-risk owner, monitoring configuration, and launch date.	System approved for defined environment or held.
Live monitoring	Use-case owner and validation owner	Update monitoring results, drift signals, incidents, last review date, and change records.	System remains live, changes trigger reclassification, or system is suspended.
Reclassification	AI Governance Office	Create new classification entry linked to prior record and material-change reason.	New tier and controls assigned.
Suspension or retirement	Use-case owner and AI Governance Office	Update lifecycle status, suspension or retirement reason, access removal, data disposition, and remaining obligations.	System stopped, retired, or returned to review.

Section 8

Validation Rules

The registry should reject or flag records that fail the validation rules below.

Rule	System response
A record cannot move to live status without a use-case owner, accountable executive, risk tier, classification date, lifecycle status, environment, and next review date.	Block status change.
A high-risk record cannot move to deployment approved or live without Gate 0, Gate 1, Gate 2, and Gate 3 decisions and evidence links.	Block status change and alert AI Governance Office.
A vendor system cannot move to live status without vendor diligence status, contract reference, and vendor evidence link or documented exception.	Block status change.
A system with EU-market activity marked yes or unclear cannot move to live status without EU role analysis.	Block status change.
A build, fine-tune, adapt, or public generative feature cannot move to live status without model lineage and training or input data source records.	Block status change unless Committee approves exception.
A system using personal, sensitive, biometric, protected health, privileged, client confidential, credential, security-log, trade-secret, or regulated data cannot move to live status without Legal, Privacy, and Security routing as applicable.	Block or route to required reviewers.
A system with autonomy level above recommendation only cannot move to live status without tool permissions, approval rules, action logs, rollback, and kill switch where technically feasible.	Block status change.
A system with lifecycle status live and no monitoring configuration must show minimal-risk clearance or documented reason monitoring does not apply.	Flag for AI Governance Office review.
A classification older than its review cadence cannot remain live without review update or documented extension.	Flag as overdue and route to owner.
A material change cannot overwrite prior classification evidence.	Require new classification entry linked to old record.
A retired system cannot retain production environment status, active vendor feature status, or active tool permissions.	Block retirement completion until cleanup fields are complete.

Section 9

Reporting Views

The registry should support operating views, not only compliance exports.

View	Required filters	Operational use
Executive risk view	Tier, sector, business unit, live status, high-risk count, overdue reviews, incidents, exceptions.	Shows senior owners where risk sits and what needs decision.
AI Governance Office queue	Intake status, missing evidence, reviewer, SLA age, next gate, contested tier, hold reason.	Runs daily governance operations.
Legal obligations view	Jurisdiction, EU role, Article 25 analysis, transparency or notice, employment, healthcare, financial, legal-services, public generative AI.	Identifies legal work and volatility exposure.
Security and privacy view	Data category, vendor, environment, tool permissions, security status, privacy status, incidents, monitoring gaps.	Routes cyber, data, and access-control risk.
Vendor concentration view	Vendor, product, model supplier, contract reference, feature, business unit, tier, incidents, change notices.	Shows third-party exposure and dependency concentration.
Model lineage view	Base model, version, provider, fine-tunes, RAG sources, downstream systems, vulnerabilities, license changes.	Identifies blast radius when a model or dataset changes.
Monitoring and drift view	Live systems, monitoring cadence, last review, thresholds, failed metrics, incidents, reclassification triggers.	Runs Gate 4.
Audit export	Registry ID, tier, owner, dates, gates, evidence links, approvals, exceptions, incidents, and retirement status.	Supports audit, regulatory, customer, and board review.

Section 10

Access and Governance

Role	Access	Responsibility
AI Governance Office	Full create, edit, review, route, and reporting rights.	Owns registry integrity, classification records, gate routing, and quality control.
Use-case owner	Create and edit assigned records before approval; update monitoring and change information after approval.	Keeps system facts current and submits material changes.
Accountable executive	Read assigned records, approve residual risk, approve or reject deployment where required.	Owns business accountability for approved use.
Legal	Read relevant records; edit legal review, jurisdiction, EU role, data-rights, notice, and obligation fields.	Owns legal determinations without becoming operating owner.
Security	Read relevant records; edit security, access, vendor security, agentic, incident, and monitoring fields.	Owns cybersecurity review and incident integration.
Privacy	Read relevant records; edit privacy, data category, retention, transfer, and affected-person fields.	Owns privacy and data-use review.
Procurement	Read vendor records; edit vendor, contract, diligence, renewal, and change-notice fields.	Connects vendor systems to contract controls.
Validation owner	Read relevant records; edit evaluation, testing, model validation, monitoring, and drift fields.	Owns technical or model-performance evidence.
Internal Audit	Read access and export access.	Tests whether registry controls operate as designed.
Business users	Limited read or submit access.	Submits intake and sees status without accessing restricted evidence.

Section 11

Quality Controls

The AI Governance Office should run registry quality checks on a fixed cadence and before any board, audit, regulatory, or customer-facing report.

Check	Cadence	Failure signal
Completeness check	Weekly	Required fields missing for active records.
Evidence-link check	Weekly for high-risk and monthly for limited-risk	Field says cleared, but no evidence link exists.
SLA check	Daily	Intake or gate review exceeds service level.
Overdue review check	Weekly	Next review date has passed.
Vendor change check	Monthly and on vendor notice	Vendor release, model update, terms change, subprocessor change, or feature activation lacks reassessment.
Model lineage check	Monthly for built and fine-tuned systems	Base-model version, license, vulnerability, or provider change not mapped to downstream systems.
Monitoring check	Monthly for live systems	Monitoring configuration missing, last review stale, threshold breach unresolved, or owner missing.
Exception check	Weekly	Exception expired, scope exceeded, evidence missing, or system moved beyond approved evaluation scope.
Shadow AI reconciliation	Quarterly	Procurement, expense, SaaS admin, browser extension, data-loss-prevention, or security logs show AI use not in registry.
Retirement check	Quarterly	Retired systems retain access, data, vendor feature activation, or monitoring obligations.

Section 12

Source Basis and Volatility Note

This registry schema aligns to NIST AI RMF Govern, Map, Measure, and Manage because it records accountability, system context, risk classification, evidence, controls, monitoring, and incident history in one operating record. It aligns to ISO/IEC 42001 because it creates documented ownership, risk treatment, operational planning, performance evaluation, change control, and continual-improvement evidence. It aligns to the EU AI Act because it captures intended purpose, role in the AI value chain, high-risk classification, technical-documentation evidence, transparency triggers, monitoring, and serious-incident routing when EU-market activity exists.

The schema also preserves the U.S. overlays the playbook relies on. California-facing public generative AI records need training-data documentation review where applicable. NYDFS-covered financial institutions need AI cybersecurity risk mapped into the existing Part 500 control environment. NYC employment systems need AEDT bias-audit and notice fields where applicable. Healthcare and patient-impact systems need separate HIPAA, FDA, SaMD, clinical-validation, and patient-safety fields rather than generic Other-sector treatment.

Julio Macedo Senior Attorney | AI Governance & Legal Ops jhmacal.com