How to Implement AI Governance in 6 Steps (2026 Guide)

We read Superblocks' AI governance guides and docs alongside NIST AI RMF, ISO/IEC 42001, and the EU AI Act. Here's how we'd implement AI governance in six steps, with business teams building inside the rules IT sets.

What you need before you implement AI governance

Superblocks' AI governance policy guide lists five prerequisites for implementing AI governance.

• An executive sponsor: The guide asks for a named C-level owner with authority to settle disagreements between functions.
• A drafting team of 5 to 8 people: IT, security, legal, privacy, HR, and at least one business unit each need a representative.
• A starting AI inventory: An incomplete list is enough, and Step 1 expands it into a full register.
• A reference framework: NIST AI RMF, ISO/IEC 42001, or the EU AI Act. Step 4 goes through each.
• A policy management process: The guide wants to know how the policy will be published and versioned, and how it will be reviewed.

Time required: Superblocks estimates 4 to 8 weeks for a first draft, plus 4 to 6 weeks for pilot and rollout.

How to implement AI governance: 6 steps

Each step feeds the next. The order matters, because you can't assign a risk tier to a tool you haven't found, and you can't enforce a policy that hasn't been written.

Step 1: Inventory every AI tool, including shadow AI

Build a register of every AI model and tool in the company, and record each use case alongside it. Superblocks' AI governance guide asks you to document who owns each system, what data it touches, and which decisions it influences.

Shadow AI refers to AI tools that employees use without IT's knowledge, and the same guide says "you'll likely discover shadow AI you didn't know existed." To find it, start by surveying employees with an anonymous form about which AI tools they use and what data they input.

Then audit SaaS contracts and product pages for AI features, and review expense reports for AI subscriptions. With the results from those three checks in hand, tag each use case by team, business purpose, data sensitivity, and approximate risk level.

The register records which data each tool is meant to touch. Logging shows which data employees put into it, because a tool list can't tell you whether customer records were pasted in.

Step 2: Form a cross-functional team and assign RACI roles

A drafting team of 5 to 8 people brings together the functions responsible for AI risk, with the executive sponsor from the prerequisites as one of them. That means an IT or security lead, legal counsel, a privacy officer, a business unit representative, and an HR representative.

Write a RACI for each major decision. The policy guide's example looks like this:

The board is informed once final approval is given. For the wider oversight structure, Superblocks' enterprise AI governance guide names three options to use alongside this table.

The three options are governance committees, executive oversight (typically a Chief AI Officer or Chief Data Officer), and ethics boards.

Each decision in the table has one accountable role, which gives a disagreement a clear place to land. For final approval, that role is the CEO.

Step 3: Classify AI use cases into risk tiers

Sort every register entry on two axes. One is how sensitive the data is, and the other is how much the output affects people. Together they decide how much review a use case gets.

For data, the policy guide's sample clause sets three rules. Public data can use any AI tool the company permits. Internal data requires an enterprise-tier tool that doesn't train models on inputs.

The third rule is the strictest. Confidential and restricted data may only be processed through on-premise or bring-your-own inference deployments that the privacy officer authorizes.

A looser clause elsewhere in the same guide allows approved enterprise tools with signed Data Processing Addenda for that data. The two rules conflict, so pick one and write it once.

For impact, the AI governance guide says to map risk by use case and start with systems that handle sensitive data (PII, financial, health), make decisions affecting people, interact directly with customers, or could damage your reputation if they fail.

The EU AI Act gives those criteria a scale with four levels of risk. Unacceptable risk is banned, and high risk carries strict obligations before market entry.

The two lower levels ask for less. Transparency risk brings disclosure duties (such as telling people they're talking to a chatbot), and minimal risk comes with no new rules. We'd copy that four-tier structure for the impact axis, with your own definitions.

We'd place a use case at the higher of its two ratings, so a tool that handles internal data but screens job applicants lands in the high-risk tier.

Classify a use case while it's still a request, and above all before launching anything customer-facing or confidential.

Step 4: Write the core policies against NIST AI RMF, ISO/IEC 42001, and the EU AI Act

Draft a policy with six sections. The sections are scope and applicability, definitions and principles, approved and prohibited uses, roles and accountability, data and security, and monitoring, auditing, and incident response. The AI governance policy guide includes an example for each.

Then anchor the policy to a named standard:

• NIST AI RMF: NIST released this voluntary framework on January 26, 2023. Its core has four functions (Govern, Map, Measure, and Manage), and Govern is "a cross-cutting function that is infused throughout AI risk management."
  
  Separately, NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan, so cite the current version when you write the policy.

• ISO/IEC 42001: This international standard sets requirements for an AI management system (AIMS) at organizations that provide or use AI-based products or services. Superblocks' guide calls it certifiable through third-party audit and useful for showing maturity in vendor contracts.

• EU AI Act: Article 2 applies, among others, to providers placing AI systems or general-purpose AI models on the EU market, deployers established or located in the EU, and providers and deployers in third countries when the system's output is used in the EU.

The Act became applicable on August 2, 2026, with some exceptions. Its high-risk obligations come later, because the AI Omnibus extended them to December 2, 2027 for Annex III use cases and to August 2, 2028 for systems embedded in regulated products.

Superblocks' guide suggests NIST AI RMF as the core operating framework and the EU AI Act for risk classifications that involve the EU. Add ISO/IEC 42001 if you plan to certify.

Whichever framework you choose, write rules a system can check. One sample clause from the guide reads, "All AI use involving confidential or restricted data must be logged to the centralized audit system."

The best practices guide says people tend to skip policies that no system enforces once deadlines tighten.

Step 5: Add technical controls that enforce the policy

Four controls put the policy into practice.

• Release checks in CI/CD: Run tests for bias, fairness, and security whenever someone updates a model. Keep an audit trail of each release, and use Git for full revision history.

• Access controls: Define who can access, modify, deploy, or audit AI, and require approval for critical actions such as deploying a new AI model or releasing a major update.
  
  Role-based access control (RBAC) assigns permissions to roles and roles to users, while attribute-based access control (ABAC) evaluates attributes of the user, the resource, the requested action, and the environment.
  
  With ABAC, a data tier from Step 3 can decide who gets access.

• Logging and audit trails: Record prompts, user queries, and model responses, and tag each log with its Step 3 data tier. We'd also set who can read the logs and how long you keep them, and review them regularly.

• Bias and drift testing: Check outputs on a regular schedule for drift and policy violations, and set alerts for outliers.

For apps that business teams build with AI, the AI governance guide says your governance team sets the rules once and apps on the platform inherit them.

RBAC controls which Superblocks features members can access, while organization knowledge defines the standards Clark, the AI that business teams use to build apps on Superblocks, follows by default.

For example, a rule like "All API error responses must be caught and displayed with a toast notification" applies to Clark conversations across the org.

According to its platform guide, Superblocks governs apps on the platform, with third-party models and model monitoring out of scope. Bias and drift tests should run in your own pipeline.

First priority: Within Step 5, turn controls on first for confidential and restricted data, since the sample clause in Step 4 already requires central logging for that data.

Step 6: Monitor, audit, and review on a schedule

Controls only help if someone reviews what they record, so Step 6 sets the review calendar. In the policy guide's sample, the AI governance committee meets quarterly and reviews the policy annually and after any material incident.

Incidents run on a tighter clock. AI-related incidents go to the privacy officer within 24 hours of discovery.

Audits can start with the logs. The AI governance guide's tooling advice is "Start with monitoring since you can't govern what you can't see."

On Superblocks Enterprise, Audit Logs record builder activity (edits, deploys, permission changes) and end-user activity in apps. They also track integration and platform changes.

From there, admins filter by date range, event type, status, severity, resource, and actor, then send any event that looks like a policy violation to the accountable owner from Step 2.

What are best practices in AI governance?

Best practices in AI governance include human-in-the-loop review for high-risk decisions, a named owner for every model, peer review before launch, and continuous monitoring, meaning alerts for outliers plus scheduled log reviews. Superblocks' AI governance best practices guide explains each one.

For human-in-the-loop review, the guide asks for sign-off on sensitive or high-impact outputs and a traceable human reviewer on each decision path, since AI mistakes in high-risk decisions can lead to financial losses.

Each model also gets a named owner, a unique ID in a central registry, and a record of its purpose and incident history.

Before launch, the guide's rule on peer review is a single line, "Require peer review before any model goes live." Once models are running, set alerts for outliers and review logs regularly, which can surface drift between committee meetings.

Common mistakes to avoid

The same guide points to four ways to head off common mistakes. Include every function from the start (Step 2), since AI governance "requires coordination across legal, compliance, security, and business teams."

Two more involve tooling. Keep version control on AI behavior, because the guide says that without it, teams struggle to explain why behavior changed unexpectedly or to roll back problematic changes.

The other tooling mistake is relying on vendor governance tools alone. Check them against your own risk profile and compliance requirements, since the guide warns they may not match either.

The last mistake is regulation. Name someone to track it, since the AI Omnibus moved the EU AI Act's high-risk dates (see Step 4).

How Superblocks applies AI governance to apps business teams build

Superblocks describes its platform as governed by security and IT, with business teams building apps through Clark inside rules that IT configures. Four controls apply to apps made this way.

• Admin MCP: Like the Audit Logs from Step 6, it's an Enterprise feature, and both first appear in release 4.13.26, which lists the Admin MCP under the name Superblocks MCP. The Admin MCP queries audit events, lists apps, manages integrations, assigns org-level roles, and deploys or undeploys apps.

• Code Security across three stages: A Package Install Gate runs CVE detection before Clark adds a package. At publish, a Security Scan and a Security Agent run, and the agent reviews the app for security issues.
  
  Vulnerability Detection then re-runs against published apps as new advisories appear. Depending on each Code Security policy's scan mode, critical and high severity issues can block a publish.
  
  Git-connected apps are the exception, since they skip the pre-publish agents, and the docs recommend equivalent checks in CI, which is the release check from Step 5.

• Deploy in your VPC: In Hybrid, production customer data stays within your VPC while Clark inference runs in Superblocks Cloud on non-production data. In Cloud-Prem, the full platform, including AI inference, runs in your own AWS, GCP, or Azure environment. The deployment overview describes both setups.

• Source Control: Enterprise connects to GitHub, GitLab, Bitbucket, and Azure DevOps. Per the docs, changes reach end users after they're merged into the default branch and imported back into Superblocks. That gives app changes the Git history that Step 5 asks for.

Which of these controls you get depends on the plan.

Teams costs $125 per month, billed monthly, or $100 per month, billed annually. It supports up to 15 Builders and includes 100 Governed Agent Units (GAUs) per month, 1 hosted app per Team, and role-based access control, with additional apps at $10/app/mo. Enterprise is custom-priced and adds SSO/SAML/OIDC, Audit Logs, Source Control, Deploy in your VPC, Security Agents and Scans, and the Admin MCP.

Each control above has a page in the Superblocks docs, and you can book a demo to see them configured.

Frequently asked questions

How long does it take to implement AI governance?

Budget 4 to 8 weeks for a first policy draft, then 4 to 6 more for pilot and rollout, according to the policy guide. Treat those as the guide's own estimates.

Can you give me an example of AI governance?

Yes. A company lists the AI tools it uses, sorts each one into a risk tier, and requires that AI use involving confidential or restricted data be logged to a central audit system.

A governance team owns those rules. On Superblocks, organization knowledge sets the standards Clark follows, and Enterprise adds Audit Logs for reviewing activity.

What are the six pillars of AI governance?

The count varies by source. Superblocks' AI governance guide names four principles, its best practices guide presents five, and its principles guide describes nine. None of those three lists six. The six steps in this guide describe a sequence to follow in order.

What is the 30% rule in AI?

The 30% rule in AI is an informal guideline with no official definition. SlashGear describes it as a 70/30 split, with AI handling 70% of the workflow and humans handling the remaining 30% that calls for creativity and critical thinking.

BGR adds a second reading, since some online sources trace the rule to education, where it means under 30% AI-generated content. The NIST AI RMF, the ISO/IEC 42001 page, and the European Commission's AI Act page did not mention it when we checked in October 2026.

Can Superblocks help govern apps that business teams build with AI?

Yes, for apps on Superblocks. IT sets org-level roles with RBAC and rules in organization knowledge, and the AI governance guide says apps on the platform inherit these controls.

Plan and scope limits apply. SSO, Audit Logs, Source Control, and Deploy in your VPC require the Enterprise plan, and the platform leaves third-party models to your own monitoring.