An Ecore micro-model of AI governance: AI systems as inventory entries, an AI risk taxonomy, impact assessments, human oversight, AI-typed evidence, and incidents.

It is an extension, not a standalone framework. Everything generic — frameworks and requirements, policies, controls, control applications, risks, assessments, findings, waivers — comes from the governance model, and through the micro-model tower under it from architecture, work, lifecycle, IAM, and role. This model adds only what is specific to AI: about a dozen classes and enumerations.

The split follows the one the standards world itself uses. ISO/IEC 42001 is the generic Annex SL management-system skeleton plus AI-specific controls; NIST AI RMF is enterprise risk management specialized to AI; OSCAL is domain-neutral with frameworks as data. A base that stays micro is reusable by the information security program and the financial controls program; the AI vocabulary that would otherwise pollute it lives here.

Position in the tower

The aspect spine runs nxcore < role < iam < seal < lifecycle < decision analysis < decision binding < governance < work < architecture < threat. AI governance branches off threat, and the agent and MCP models sit above it.

Three consequences follow, and they are the whole point of the arrangement:

• AISystem extends Governed. Applied controls, risks, and waivers are inherited, not redeclared. An AI inventory entry is a governed element like any other, so per-framework compliance views, gap reports, and audit packs come from the base model’s machinery.
• An agent is an AI system. Agents from the agent model are AISystems and are therefore governed by construction; the tools and MCP servers they call are threat-model Assets, hence architecture elements. Nobody has to remember to add the agent to the register.
• Composition is not duplicated here. What an AI system is made of — agents, prompts, tools, MCP servers, models at runtime — belongs to the agent and MCP models, and those elements are themselves governable. AISystem is the unit that regulators, risk registers, and inventories talk about, not a second description of the runtime.

The ModelAsset / DatasetAsset pair is the inventory view of the same principle: provider, version, modality, open weights, provenance, personal data, licence — what a register and a due diligence questionnaire ask for, with the wiring left to the models above.

Competitive landscape

Four camps, none of which occupies this position:

AI GRC platforms. Credo AI, Holistic AI, Trustible, OneTrust AI Governance, IBM watsonx.governance, ServiceNow AI control tower, and the ISO/IEC 42001 modules bolted onto Vanta and Drata. They do the workflow well: intake questionnaires, policy libraries, evidence collection, vendor-maintained framework crosswalks. The data model is proprietary and the register is the silo: the AI inventory lives in the GRC tool, the architecture in an EA tool, the agents in Python, the telemetry in an observability backend, and every crosswalk between them is manual. Their crosswalk between frameworks is a product feature you rent; here it is a many-to-many reference in a model you own.

MLOps and evaluation tooling. MLflow and Weights & Biases registries, SageMaker and Vertex model cards, evaluation harnesses (OpenAI Evals, promptfoo, DeepEval, Inspect), guardrail libraries. Excellent at producing run artifacts, silent on governance semantics: an eval score is a number in a dashboard, not something that satisfies a requirement, verifies a control application, or closes a finding. Evaluation with metric, threshold, and passed is exactly that adapter — the score becomes evidence attached to a control application.

Standards, catalogs, and interchange formats. NIST AI RMF and its Generative AI Profile, ISO/IEC 42001, 23894 and 42005, the EU AI Act, OSCAL, CycloneDX ML-BOM, the SPDX AI profile, model cards, the AI Incident Database and the OECD AI Incidents Monitor. These are sources and export targets rather than competitors. Each covers a slice — a control catalog, a bill of materials, an incident schema — and none ties the slices together. Frameworks load here as Framework/Requirement instance data: adding the AI Act is authoring, not a metamodel change.

Open-source responsible-AI toolkits. AI Verify, the Responsible AI Toolbox, AIF360, fairness and explainability libraries. They generate measurements, which is the evidence side of one control. The governance record around them is still a spreadsheet.

And the actual competitor, as with governance and threat modeling: an AI inventory in Excel, a DPIA in Word, a risk register in a second spreadsheet, and a slide deck for the board — four artifacts that are already inconsistent with each other on the day they are filed.

What a typed model adds

One control, many requirements. A human review step can satisfy an EU AI Act Art. 14 obligation, an ISO/IEC 42001 Annex A control, and an AI RMF MANAGE subcategory at once. That is a reference in a model and a hand-maintained matrix everywhere else. Add a framework, regenerate the views.

Human oversight is typed, not prose. HumanOversightControl with OversightMode forces the distinction the regulation cares about: in the loop (a human approves each consequential action), on the loop (a human can intervene, actions proceed by default), in command (kill switch and scope authority). “There is human oversight” stops being a sentence in a questionnaire and becomes a claim that can be rendered, reviewed, and disputed.

Impact assessments reuse assessment mechanics. ImpactAssessment is an Assessment with a kind and affected stakeholders. An algorithmic impact assessment, a GDPR Art. 35 DPIA, and an AI Act Art. 27 fundamental rights assessment share findings, evidence, scope, and remediation tracking instead of being three unrelated Word templates.

Evidence from telemetry. TelemetryEvidence is a metric, a query against modeled telemetry, and a threshold. Continuous control monitoring becomes a query reference rather than a platform feature, and collection is automated by construction rather than by an integration you buy.

Incidents feed the control catalog. Incident carries reportable (AI Act Art. 73) and, more consequentially, correctiveActions pointing at Controls. The post-mortem strengthens the catalog the compliance program already runs on, instead of landing in a separate incident tracker nobody opens at audit time.

Honest defaults. AiActRiskTier starts at NOT_ASSESSED, not MINIMAL. Waivers and findings are first-class. A model that cannot express “we have not looked at this yet” and “we knowingly deviate, here is why, until this date” is a marketing document, not a register.

Applications

Educational — understanding AI governance. The domain is usually taught as a pile of acronyms (AI Act, AI RMF, 42001, DPIA, FRIA, GPAI, ML-BOM) whose relationships are left to the reader. A metamodel is the relationships: Framework contains Requirements, a Control satisfies requirements across frameworks, a ControlApplication is the unit of status, Evidence supports it, an Assessment produces Findings, and a Waiver is what honesty looks like when a control is not applied. The enumerations are the syllabus in condensed form — five AI Act risk tiers, four actor roles, eleven AI risk categories, three oversight modes, five evaluation kinds — each with a one-line definition, in a structure that shows how they connect. The vocabulary tracks the IAPP AIGP Body of Knowledge and its underlying sources, so the generated documentation site doubles as study material. The most instructive exercise is instantiation: take one fictional system (a CV screening tool is the canonical Annex III example), classify it, register its models and datasets, write the risks, apply controls with evidence, run an impact assessment, record an incident. The fields you cannot honestly fill in are the lesson.

AI system inventory. The register every AI Act deployer and every 42001 certification needs, in a form that is diffable, reviewable in a pull request, and generated into a browsable site rather than maintained as a spreadsheet tab.

Documentation generation. Annex IV style technical documentation, model cards and fact sheets, risk registers with inherent and residual heat maps, per-framework compliance views, per-system audit packs, board-level summaries — all views over one source, so they cannot drift apart.

Continuous compliance. With telemetry-backed evidence and evaluation results attached to control applications, “is control X on system Y still effective” is a query rather than a quarterly email round.

Composition with the agentic stack. Agents, tools, and MCP servers from the agent and MCP models arrive already governed and already threat-modelable. The AI Risk Manager persona consumes what the AI Architect persona produces — control status, evidence, incident records — as a different generated view of the same model.

Export and interoperability. OSCAL-shaped artifacts, CycloneDX ML-BOM and SPDX AI profile documents, incident records in AIID / OECD AIM shape: generated views. Interoperate with the tools without living in them.

Procurement and third-party due diligence. ModelAsset provider, version, and open-weights status, DatasetAsset provenance, personal data, and licence, plus the evidence attached to each — the vendor questionnaire answered from the model instead of from memory.

Model overview

The AI risk taxonomy draws on the AI RMF, the AIGP Body of Knowledge, and the OWASP LLM and agentic risk catalogs: bias and discrimination, privacy, security, hallucination, toxicity, IP and copyright, transparency, safety, drift, misuse, and overreliance. The base Risk.category stays free-form for anything the taxonomy does not cover, and threats promoted from the threat model land in the same register.

Resources

• docs.nasdanika.org
• Nasdanika Medium publication.