Start AI Governance in 90 Days: Enterprise Framework Using NIST's RMF: Theodoros Ampas

An AI governance framework is the structured set of policies, roles, and controls that determine how an organization builds, approves, and monitors AI systems, drawing on standards like the NIST AI RMF, the EU AI Act, and the OECD AI Principles. If you lead an organization deploying AI today, the first move is not writing a policy document. It’s assigning an accountable owner and adopting a risk-tiering system so every AI use case gets scrutiny proportional to its actual risk.

TL;DR:

Most organizations should start AI governance by assigning an accountable owner and implementing risk-tiering before drafting policies.

Frameworks like the EU AI Act are legally binding within the EU, requiring compliance for products entering its market, while others like NIST are voluntary.

All governance models emphasize six pillars: accountability, risk-based controls, human oversight, data management, transparency, and security; mapping existing controls to these reduces gaps.

Embedding governance tools such as model registries and approval workflows into daily operational systems ensures better compliance and audit readiness.

Building governance into workflows and team tools, rather than separate systems, enhances adoption and ownership, especially when combined with ongoing training and clear role definitions.

What Counts as an AI Governance Framework?

Not every framework in this space carries the same weight, and confusing a voluntary guideline with a legal mandate is one of the fastest ways to misallocate compliance budget. Some frameworks are advisory scaffolding meant to shape internal practice. Others are law, with penalties attached. Knowing which is which determines where you spend your first dollar of governance effort.

The NIST AI Risk Management Framework (AI RMF) is a voluntary, US-origin framework organized around four functions: GOVERN, MAP, MEASURE, and MANAGE. It’s flexible by design, meant to be adapted rather than followed as a checklist, and it applies to any organization building or deploying AI regardless of sector.

The EU AI Act (Regulation 2024/1689) is not voluntary. It’s a binding law across the European Union that classifies AI systems into risk tiers, from prohibited practices down to minimal risk, and attaches concrete obligations, technical documentation, transparency disclosures, and record keeping to providers and deployers of high-risk systems. If your product touches EU users or markets, this framework outranks every voluntary guideline you might otherwise prioritize.

The OECD AI Principles set high-level values, human-centered design, transparency, robustness, accountability, adopted by dozens of governments and used as the philosophical backbone for many national laws.

Singapore’s Model AI Governance Framework offers practical, voluntary guidance built around internal governance structures, determining the right level of human involvement in AI-augmented decisions, and stakeholder communication, and it has been updated to keep pace with generative AI.

ISO/IEC 42001 is the first certifiable international standard for AI management systems, useful for organizations that want a third-party auditable claim of governance maturity.

UNESCO’s Recommendation on the Ethics of Artificial Intelligence is a global, values-based instrument adopted by member states, emphasizing human rights and environmental sustainability over technical mechanics.

India’s AI Governance Guidelines take a distinct people-first, whole-of-government approach, emphasizing institution building and inclusion rather than prescriptive technical controls.

Voluntary and flexible: NIST AI RMF, OECD Principles, Singapore Model Framework, UNESCO Recommendation
Legally binding: EU AI Act (within EU jurisdiction and for products entering EU markets)
Certifiable standard: ISO/IEC 42001
National institution-building approach: India AI Governance Guidelines

If you deploy in the EU, start there. If you need a common operational vocabulary that works across jurisdictions, NIST’s four functions give you the most exportable structure.

Strip away the jurisdictional differences and every serious AI governance model converges on the same six pillars. This convergence matters: it means you can build one internal program and map it to multiple external frameworks rather than running parallel compliance tracks.

Accountability and documentation. Someone, by name, owns each AI system’s risk profile, and that ownership is recorded, not assumed.
Risk-based approach. Controls scale with potential harm. A chatbot suggesting product names gets lighter scrutiny than a system approving loan applications.
Human oversight. Frameworks specify where a person must review, approve, or be able to override an automated decision, and at what threshold.
Data governance and model lifecycle management. Training data provenance, testing before deployment, and revalidation after updates.
Transparency and explainability. Stakeholders, internal and external, can understand what the system does and why it produced a given output.
Security, privacy, and safety controls. Standard information security practice extended to model weights, prompts, and inference logs.

Pro Tip: Map your existing SOC 2 or ISO 27001 controls against these six pillars before writing anything new. Most enterprises already have a significant part of the data governance and security work done. Governance gaps usually cluster around human oversight and accountability, not security.

The common thread across NIST, the EU Act, and Singapore’s model is that none of them ask you to eliminate risk. They ask you to know your risk and prove you’re managing it. That distinction shapes everything that follows.

How Do NIST’s Four Functions Work in Practice?

The NIST AI RMF is the most operationally useful of the major frameworks because it translates into concrete artifacts rather than abstract principles. Each function produces something you can point to during an audit or a board review.

GOVERN builds the foundation: policies, accountability structures, and documentation practices that exist before any specific AI project starts.

Draft an AI use policy defining acceptable and prohibited use cases.
Name an accountable executive (often a CAIO, chief risk officer, or delegated committee chair).
Establish a documented escalation path for disputes over risk classification.

MAP happens at project intake, scoping the context, intended use, and stakeholders before a single model is trained or purchased.

Complete a context-and-purpose questionnaire for every proposed AI use case.
Identify affected stakeholders, customers, employees, regulators, and document foreseeable harms.
Set go/no-go criteria the project must clear before moving into build or procurement.

MEASURE is where testing lives: performance metrics, fairness testing, and validation plans, including profiles NIST has extended specifically for generative AI.

Define acceptance thresholds for accuracy, bias, and robustness before testing begins.
Run adversarial and edge-case testing, not just average-case validation.
Document results in a model card or evaluation report tied to the specific model version.

MANAGE covers what happens after deployment: mitigation plans, incident response, and resource allocation for ongoing fixes.

Assign a response owner and a defined severity scale for AI-related incidents.
Build a remediation backlog tied to monitoring alerts, not just user complaints.
Schedule periodic reassessment tied to model updates or data drift.

Concrete artifacts worth building early: a one-page AI policy template, a model registry entry format (owner, purpose, risk tier, last validation date), and a risk-treatment plan template that ties each identified risk to a specific mitigation and deadline. NIST’s own guidance treats the RMF as a menu to adapt, not a checklist to complete, and that adaptability is precisely why it works across industries with wildly different risk profiles.

What Does a Practical Enterprise Operating Model Look Like?

Most enterprises fail at AI governance not because they lack principles but because they never decide who does what. Five pillars, an operating model, and a registry solve that.

The five pillars:

Policy and strategy: sets direction and defines acceptable risk appetite.
Risk management: runs the tiering, assessment, and mitigation tracking.
Ethics and oversight: reviews edge cases, bias findings, and disputed classifications.
Data and MLOps: owns pipelines, versioning, and technical validation.
Security and compliance: handles access control, audit readiness, and regulatory mapping.

Three operating models cover almost every organization. A centralized center of excellence puts one team in charge of all AI review, which works well for smaller organizations or highly regulated industries where consistency matters more than speed. A federated model distributes governance ownership to business units with a light central standards team, suiting large, decentralized enterprises with varied use cases. A hybrid model, central policy and risk tiering with federated execution, is what most mid-size to large organizations land on after their first year, because pure centralization becomes a bottleneck and pure federation loses consistency.

A simple RACI split: the AI governance council is accountable for risk-tier standards; business unit leads are responsible for individual use-case compliance; legal and security teams are consulted on every high-risk approval; and the board is informed quarterly on portfolio-level risk exposure.

The registry is the operational core. For every AI system in production, record its owner, purpose, risk tier, training data sources, last validation date, and monitoring status. This becomes your evidence pipeline for both internal audits and external regulatory review.

Pro Tip: Don’t build heavy approval gates for every automation. A low-risk internal tool, say, a meeting summarizer, should clear review in a day through a lightweight self-attestation form. Reserve full committee review for systems that touch customer decisions, financial outcomes, or protected data. Lighter controls for low-impact automation keep the business agile while heavier paths protect where it actually matters.

Who Should Own Governance Decisions, and What Should They Check?

Governance fails when responsibility is vague. Assign these roles explicitly, in writing, before your first AI project reaches production.

The board or executive team sets risk appetite and tone. They should ask, at minimum quarterly: What is our current AI risk exposure by tier? What incidents occurred, and how were they resolved? Are we compliant with binding regulations in every market we operate in?
The governance council or ethics committee meets on a fixed cadence, monthly for active programs, and owns escalated decisions: disputed risk classifications, bias findings that cross acceptance thresholds, and requests for exceptions to standard policy.
Model owners and stewards handle the operational layer: keeping documentation current, running scheduled revalidation, and defining the human-in-the-loop threshold, the specific point at which a human must review before an action executes.
Reviewers approving a new deployment should confirm five things before sign-off: documented purpose and scope, completed risk-tier assessment, testing results against defined thresholds, a named accountable owner, and a monitoring plan with defined alert thresholds.

Red flags that should stop an approval cold: no named owner, no documented testing methodology, a risk tier that was self-assigned by the requesting team without independent review, or a monitoring plan that only checks system uptime rather than output quality.

How Should You Measure and Monitor AI Systems Once They’re Live?

Governance doesn’t end at launch. It starts generating its most useful data after launch, which is exactly when most programs stop paying attention.

Track five categories of metrics: model performance against baseline, fairness indicators across demographic segments where relevant, exception rate (how often human reviewers override the system), mean time to remediation (MTTR) for flagged issues, and drift signals showing when live data diverges from training data.

Build runtime telemetry that captures inputs, outputs, and confidence scores, not just system health.
Set alerting thresholds tied to business impact, not arbitrary statistical cutoffs.
Design drift detection to run on a schedule, not only when someone notices a problem.
Log everything needed for audit: decision inputs, model version, human overrides, and timestamps, retained per your regulatory retention requirements.

One number worth building your monitoring around: exception rate. A rising rate of human overrides on a system that was supposed to run autonomously is often the earliest warning sign of drift, long before performance metrics degrade enough to trigger a standard alert.

The incident lifecycle follows four stages: detection (automated alert or human report), triage (severity classification and initial containment), remediation (fix deployed and validated), and root-cause update (policy or model change to prevent recurrence). Skipping the fourth stage is the most common failure. Teams fix the symptom and never close the loop on why it happened.

First 90 Days, Six Months, and the Long Game

Governance programs stall when leaders try to build everything at once. Sequence the work.

First 90 days:

Name an accountable executive owner for AI governance.
Run a full inventory of every AI system currently in use, including shadow deployments nobody officially approved.
Draft and approve a risk-tiering policy with three or four clear tiers.
Fix two or three quick, low-risk wins, like documenting an existing system, to build organizational momentum.

Six-month milestones:

Baseline monitoring live on all high-risk systems.
A functioning model registry covering the full inventory.
Formal policies published and communicated organization-wide.
Initial training delivered to model owners and reviewers.
A pilot recertification cycle completed on at least one system.

Long-term program activities include annual maturity assessments against your chosen framework, a fixed recertification cadence (most enterprises land on annual, with high-risk systems on a shorter cycle), and a standing process for tracking legal and regulatory changes across every jurisdiction where you operate.

A useful standing agenda for the quarterly governance review: portfolio risk summary, incidents since last meeting, upcoming model changes requiring reassessment, regulatory updates affecting current tiers, and open exceptions requiring a decision.

How Do You Keep Stakeholders Informed and Aligned?

AI governance dies quietly when only the compliance team knows it exists. Executives approve a policy, then engineering teams never hear about it, and six months later nobody can explain why a system was classified the way it was.

Different stakeholders need different information at different depths. The board wants portfolio-level risk exposure and incident summaries, not model architecture details. Engineering teams need the risk-tiering criteria and approval workflow spelled out clearly enough that they can self-assess before requesting formal review. Customer-facing teams need to know what disclosures are legally or ethically required so they’re not caught explaining an AI decision they don’t understand.

Build a communication cadence that matches this variation: quarterly board briefings, monthly updates to engineering and product leads, and a searchable internal policy hub so anyone can check current requirements without filing a request. When Singapore’s Model AI Governance Framework emphasizes stakeholder communication as a standalone pillar rather than an afterthought, it’s because unclear communication is usually the root cause when governance policies exist on paper but don’t shape actual behavior.

External stakeholders matter too. Customers affected by automated decisions, regulators reviewing compliance, and partners integrating with your systems all need a consistent, documented explanation of how your governance model works, not an improvised answer crafted after something goes wrong.

Where Does AI Governance Fit Inside Existing Corporate Compliance?

Building AI governance as an island, disconnected from existing risk, legal, and compliance functions, is one of the most expensive mistakes an organization can make. It duplicates work and creates conflicting approval paths.

The fix is structural. Route AI risk assessments through your existing enterprise risk management process rather than building a parallel one. If you already have a risk register for operational and financial risk, add an AI risk category to it rather than maintaining a separate spreadsheet nobody cross-references. Your legal and privacy teams already handle data protection obligations; AI governance should extend that same team’s remit rather than duplicating it with a standalone AI privacy function.

Internal audit should treat AI systems the same way it treats financial controls: subject to periodic, independent review against documented standards. If your organization already has SOC 2 or ISO 27001 certification, mapping AI controls to those existing control families, rather than inventing new categories, cuts audit prep time substantially.

The practical test: if your AI governance program requires a completely separate reporting line, separate documentation system, and separate audit process from everything else in the company, it will be under-resourced and ignored within eighteen months. Integration isn’t a nice-to-have structural choice. It’s what determines whether governance survives past its launch year.

How Do You Train Teams to Actually Follow the Policy?

Policy documents don’t change behavior. Training programs, reinforced by workflow design, do.

Effective AI governance training splits by role rather than running one generic session for the whole company. Model owners and stewards need hands-on training on the registry, the risk-tiering criteria, and how to document a testing plan correctly, ideally with a real example from their own team’s work rather than a generic template. Executives and board members need a shorter, higher-level briefing focused on risk appetite decisions and what questions to ask during quarterly reviews. Frontline employees using AI tools day to day need practical guidance on what’s permitted, what requires disclosure to customers, and who to contact when something looks wrong.

Change management works best when the new process is easier than the old workaround. If reporting an AI concern requires filling out a seven-field form buried three menus deep, people won’t do it. If it’s a one-click flag inside the tool they already use, they will. Build the reporting mechanism into existing workflows rather than adding a separate governance app nobody opens voluntarily.

Refresh training annually at minimum, and immediately after any material policy change or a significant incident. A policy that trained employees encountered once during onboarding and never again is, in practice, no policy at all.

What Have Early Governance Programs Learned the Hard Way?

Organizations that stood up AI governance in the past two or three years tend to converge on the same hard lessons, regardless of industry.

The most common early mistake is starting with policy documents instead of inventory. Teams spend months drafting a comprehensive AI ethics charter while shadow AI tools, ChatGPT accounts, unsanctioned automation scripts, unofficial model integrations, proliferate across departments with zero visibility. The inventory should come first. You can’t govern what you can’t see.

The second lesson is that risk tiering fails when it’s too granular. Programs that launch with seven or eight risk tiers collapse under their own complexity within a year; teams can’t consistently classify use cases, and the distinctions between adjacent tiers become arbitrary. Three or four tiers, clearly defined with concrete examples for each, hold up far better in practice.

The third lesson concerns ownership. Programs where a single compliance officer owns all AI risk decisions bottleneck immediately once the AI portfolio grows past a handful of systems. The programs that scale distribute day-to-day ownership to model stewards embedded in business units, with a central council handling only escalations and standard-setting, mirroring the hybrid operating model that most mature enterprises eventually adopt.

The fourth, and most underestimated, lesson is that governance built as a bolt-on to existing tools survives. Governance built as a separate parallel system, a new dashboard, a new approval app, a new reporting line, gets abandoned once the initial compliance push fades. Embedding governance checkpoints into the tools teams already use every day is what makes the difference between a policy that lives and one that quietly dies in a shared drive.

What Tools Actually Support Governance at Scale?

Manual governance, spreadsheets tracking model inventory, email chains for approvals, works for a handful of AI systems. It collapses somewhere between ten and thirty systems, depending on organizational complexity.

Model registries, whether purpose-built AI governance platforms or extensions of existing MLOps tooling, give you a single source of truth for what’s deployed, who owns it, and its current risk tier. Automated monitoring and observability tools flag drift and performance degradation without requiring someone to remember to check manually. Workflow automation platforms can enforce approval gates directly inside the tools teams already use, so a high-risk AI request automatically routes to the right reviewer instead of relying on someone remembering the policy.

The pattern worth noting: governance technology works best when it’s embedded inside existing operational systems, your CRM, your ticketing platform, your deployment pipeline, rather than bolted on as a separate compliance-only application. A registry entry that updates automatically when a model is redeployed is far more reliable than one that depends on a team remembering to file a change request. That’s the difference between governance that generates real evidence pipelines and governance that generates paperwork nobody trusts during an actual audit.

Why Governance Has to Live Inside the Workflow, Not Beside It

Most AI governance advice treats policy and implementation as two separate projects: write the framework first, build the systems second. In practice, that sequence produces governance nobody follows, because the controls exist somewhere a busy team never looks.

The pattern worth applying to your own program is inverse. Build the human-in-the-loop review, the CRM write-back, the decision log, directly into the workflow a team already uses. When a lead-qualification system writes its reasoning into the same CRM field a sales rep checks anyway, the audit trail exists without anyone doing extra work. When an approval gate sits inside the tool a claims adjuster already opens every morning, the governance step feels like part of the job, not a compliance tax layered on top of it.

The trade-off is real and worth naming plainly. Embedding controls into existing tools takes longer up front than bolting on a separate dashboard, and it demands genuinely understanding how a team’s workflow functions before writing a line of automation. But the payoff is a governance model owned by the people using it, not a policy binder maintained by a compliance team that never sees how the AI actually behaves day to day. A model registry entry that updates itself as part of a deployment pipeline beats a spreadsheet someone forgets to update every time.

Theodor

Get Help Turning This Framework Into a Working System

Reading about GOVERN, MAP, MEASURE, and MANAGE is one thing. Building a model registry that updates itself, an approval gate that lives inside your CRM, and a human-in-the-loop checkpoint that a busy team actually uses is another. A good governance implementation involves spending time inside actual sales, marketing, and operational tools before designing any control, so the governance layer fits the workflow the team already runs instead of adding a system they have to remember to check.

An embedded approach means the audit trail, decision log, and CRM write-back get built directly into the systems people use every day, with supervised handover so the team ends up owning and understanding what was built rather than depending on outside maintenance. Such an engagement typically starts with an audit of current workflows and AI risk exposure, followed by implementation and, where useful, an ongoing partnership to keep controls current as systems evolve. If you’re ready to move from a governance framework on paper to one running inside your actual tools, explore the embedded AI services Theodorosampas offers and start the conversation about where your risk actually lives.