AI governance is the set of policies, roles, processes and technical controls an organization uses to decide how AI systems are built, deployed, monitored and retired, and to prove those decisions were followed. It covers the models, the data inputs those models use and the actions AI systems take.
AI governance decides who may do what with AI, under which rules, with what evidence. A policy that says "agents must cite sources" only counts once logs show that the agent's answers did.
An AI system here means any software that uses a model to generate content, make predictions or take actions. That includes chat features, autonomous agents and RAG pipelines. RAG (retrieval-augmented generation) is a pattern where the system fetches documents at query time and passes them to a model as context.
Why AI Governance Matters Now
AI governance matters now because recorded AI failures keep climbing as more products ship AI features. According to the Stanford AI Index 2026, "Documented AI incidents continued to rise, with the AI Incident Database recording 362 in 2025, up from 233 in 2024."
Policies are spreading too, but a written policy does not enforce itself. In our view, governance kept only in documents fails at runtime. If no control blocks an unapproved action, the written rule has no effect on what the agent does.
Responsible AI describes the values a team wants its AI to meet, such as fairness, safety and privacy. AI risk management is the practice of finding and reducing harms. AI governance is the structure that puts both into daily practice.
For startups, governance often shows up first as a sales question. In our experience, enterprise security reviews and procurement questionnaires often ask what AI you run, what data it touches and how you monitor it. Teams that already keep an inventory and logs can answer from records instead of rebuilding the story by hand.
The Core Principles of AI Governance
We group the core principles of AI governance into three pillars: accountability, transparency and risk management. Frameworks split these ideas differently, so you will also see lists of four, five or more principles. Fairness, privacy and security sit inside these pillars.
- Accountability: Each AI system has a named owner with clear decision rights. That person can approve, pause or retire the system.
- Transparency: Each system is documented, and its outputs trace back to their inputs and model version. Reviewers can see how a result was produced.
- Risk management: Teams assess possible harms and apply controls that match the risk. They monitor results after release.
The count matters less than the mapping. Each principle should link to a control that someone can check. AI transparency, for example, becomes real when a reviewer can open a log and see which sources shaped an answer.
AI Governance Frameworks and Regulations
AI governance frameworks tell you how to govern, while regulations tell you what is required by law. Most teams use a framework to organize the work and a regulation to set the minimum bar.
The table compares the three most-cited references on the same four attributes.
| Name | Type | Scope | What It Asks For |
|---|---|---|---|
| EU AI Act | Law | AI systems placed on the EU market or used in the EU | Risk-based duties, from bans on prohibited practices to documentation and oversight for high-risk systems |
| NIST AI Risk Management Framework | Voluntary framework | Organizations that design, develop, deploy or use AI | Four functions: govern, map, measure and manage |
| ISO/IEC 42001 | International management-system standard | Organizations that provide or use AI | An AI management system (AIMS) with policies, roles, risk processes and ongoing improvement |
The EU AI Act
The EU AI Act is a European Union law that sorts AI systems by risk and sets duties for each level. Prohibited practices are banned, and high-risk systems carry the heaviest obligations. The Act also sets rules for general-purpose AI (GPAI) models, which are models trained to handle many different tasks.
The high-risk rules phase in over time. According to the Commission's AI Act enforcement page, "The rules for high-risk AI systems listed in Annex III to the AI Act apply from 2 December 2027, while the rules for high-risk AI systems embedded into regulated products apply from 2 August 2028." Annex III is the Act's list of high-risk use cases.
The highest fines, up to €35 million or 7% of global annual turnover, apply to prohibited practices. Other breaches, including GPAI obligations, carry lower caps of up to €15 million or 3%, per the same Commission page. Many articles apply the 7% figure to every breach, which overstates the exposure for most teams.
The NIST AI Risk Management Framework
The NIST AI Risk Management Framework (AI RMF) is a voluntary US framework from NIST, the US National Institute of Standards and Technology. The NIST AI RMF Core page states that "the Core is composed of four functions: govern, map, measure, and manage." The NIST AI RMF Core page also notes that version 1.0 dates from 2023 and that a revised version is in progress.
Govern is cross-cutting, so it shapes the other three. Map sets context and finds risks, measure assesses them, and manage acts on them.
ISO/IEC 42001
ISO/IEC 42001 is an international management-system standard published in 2023. Per ISO's ISO/IEC 42001 page, the standard specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS).
An AIMS is the set of policies, roles and processes an organization uses to run AI in a controlled way. ISO/IEC 42001 governs processes across the organization and does not specify tests for individual models. In practice, the standard asks whether your governance loop exists, has owners and keeps improving.
How AI Governance Works Across the AI Lifecycle
AI governance works as a loop across the AI lifecycle. It runs through four stages: inventory, risk assessment, controls and monitoring. Each stage produces evidence the next stage uses.
These AI governance best practices apply to one model or many agents. Only the number of entries and the strictness of controls change.
Inventory: Know Which AI Systems You Run
An AI inventory is a list of every model, agent and AI feature your organization runs. Include AI switched on inside existing SaaS tools, since vendors can add AI features to products you already use.
Record these fields for each entry:
- System name and version
- Owner
- Purpose
- Model and provider
- Data sources, including live web sources
- Users affected
- Risk tier
The data sources field matters most for retrieval systems, because it lists each input the system can pull in. Inventories go stale as teams add features, so review them on a schedule, such as each quarter or each major release. Your AI governance policy should name who updates the inventory.
Risk Assessment: Classify Before You Control
Risk assessment sorts AI systems into tiers by impact, so controls match the stakes. An internal tool that summarizes meeting notes is low impact. A customer-facing agent that can issue refunds or send emails is high impact.
Higher tiers get stricter controls, such as more testing, human approval and closer monitoring. If you sell into the EU, map your tiers to the AI Act's risk categories. That mapping shows which legal duties apply to each system.
Controls and Human Oversight
Controls are the technical and process checks that make a policy enforceable. Human oversight means a person can review, approve or stop an AI system's actions. Start with these four controls:
- Access permissions: Limit which data, tools and systems each model or agent can reach.
- Approval steps: Require a human to approve high-impact actions, such as sending customer messages.
- Pre-release testing: Test outputs against defined checks before each release.
- Pause and rollback: Keep a way to switch off a system or return to a previous version.
Match each control to a tier. A low-tier summarizer may need only access limits, while a high-tier agent needs all four.
Monitoring and Audit Logs
Monitoring checks that AI systems keep working as expected after release. Track output quality, drift and incidents. Drift is a gradual change in model behavior or input data that makes results less accurate over time.
Audit logs are the evidence. An AI audit asks what the system did, with which inputs, under which rules. A per-request log answers that question with these fields:
| Field | What to Record | Why It Matters |
|---|---|---|
| Timestamp | Date and time of the request | Puts events in order |
| System and version | Model, prompt template and app version | Ties each output to a specific build |
| User | Person or service that made the request | Shows who triggered the action |
| Input or prompt | Text or data sent to the system | Lets reviewers reproduce the request |
| Retrieved sources | Each source URL plus its retrieval time | Shows what the system read and when |
| Tool calls | Each tool or API called, with parameters | Records the actions an agent took |
| Output | Response or action produced | Shows what users or systems received |
| Policy version | Governance policy in force at the time | Shows which rules applied |
| Human approver | Reviewer name, when approval was required | Proves oversight happened |
Web data collection needs a few more records. Olostep's scraping guidance recommends logging "the target robots.txt snapshot, the Terms of Service review date, your request configurations, and your automated deletion schedules." These records show what the source rules were when you collected the data.
Governing What AI Reads: The Data Input Layer
AI data governance for retrieval systems covers what the AI reads: where data came from, whether you may use it, how fresh it is and whether outputs trace back to it. In RAG systems and agents that retrieve live web data, outputs depend on inputs gathered at runtime.
Our reasoning, not a measured statistic: many failures in these systems likely trace to inputs, such as stale pages, unpermitted sources or unattributed claims. Governing this layer means following one chain: the system retrieves a source, checks its permission signals, produces an output, cites the source and logs each step.
Data Provenance: Record Where Every Input Came From
Data provenance is the record of a data item's source, retrieval time and collection method. Olostep's guidance on APIs versus scraping puts the rule in one line: "Document robust data provenance (source, timestamp, method)."
Capture four fields for each retrieved item: source URL, retrieval timestamp, content hash and extraction method. A content hash is a short fingerprint of the content, so you can tell later whether the page changed. The extraction method records how you got the data, such as an official API, a scrape or a crawl.
Agents make provenance harder because they choose sources at runtime. For agent-specific patterns, read this guide to tracking data provenance for agents.
Permissions and Copyright: Respect Source Signals
Permission governance checks whether you may collect and use each source. The most common signal is robots.txt, a machine-readable file at a site's root that lists crawl rules for bots. Crawlers follow robots.txt voluntarily, as explained in how robots.txt works.
The EU AI Act addresses copyright for GPAI providers. Under Article 53 of the AI Act, GPAI providers must "draw up and make publicly available a sufficiently detailed summary about the content used for training of the general-purpose AI model." Article 53 also requires a copyright policy that honors rights reservations, which are opt-outs that rights holders express.
Article 53 refers to rights reservations identified through "state-of-the-art technologies" and does not name robots.txt. An explicit robots.txt commitment appears in the voluntary GPAI Code of Practice. The Commission's copyright compliance FAQ explains: "Signatories of the Code commit, on top of respecting robots.txt and any subsequent version of that (commitment under Point 1(a)), to identify and comply with other appropriate machine-readable protocols used to express rights reservations."
More site owners now restrict AI crawlers. Per Cloudflare's 2025 Radar review, "AI crawlers were the most frequently fully disallowed user agents found in robots.txt files." Permissions can change after you approve a source, so re-check them on a schedule.
Olostep's Terms of Service require customers to respect applicable website terms, robots.txt directives and rate limits. The Terms also prohibit bypassing access controls without authorization.
Treat collection risk and reuse risk as separate checks. Collection risk is about how you fetched the data, while reuse risk is about what you do with it, such as training, republishing or quoting. Olostep's guide to the legal risks of web scraping covers both layers.
Freshness: Govern How Old Your Data Can Be
Freshness governance sets how old data can be before the system stops using it. Stale sources produce outdated answers, even when the model works as designed. Three controls apply:
- Maximum age: Set an age limit per source type, with shorter limits for fast-changing pages such as prices.
- Scheduled re-checks: Re-fetch or re-verify each source on a set schedule.
- Change logs: Record when content changes, with timestamps for each version.
An SLA (service-level agreement) for freshness is a target for how current each data type must be. For ways to measure staleness, see data freshness metrics and SLAs.
Monitoring tools can detect page changes between scheduled checks. The Olostep website monitoring API runs scheduled change detection on external pages and keeps snapshots.
Source Attribution: Make Outputs Traceable
Source attribution means returning the sources behind each answer so reviewers can check its claims. Attribution links each output back to its provenance records, which makes the answer auditable.
An auditable answer is one where each claim traces to a source URL and a retrieval time. Without attribution, a reviewer cannot tell a correct answer from a confident guess. Common AI source attribution practices show where this step tends to break.
Attribution can start at the data layer. Olostep's source-backed grounded answers API returns answers grounded in live web data along with the sources used. Attribution does not prove an answer is correct, but it lets a person check.
Example: Governing a Web Research Agent
A web research agent that tracks competitor pricing for a sales team is a clear example of AI governance in practice. The agent searches competitor sites, scrapes pricing pages and drafts a summary for sales reps. Agentic AI governance applies the usual controls to systems that act, such as browsing, calling tools or sending messages.
The team first adds an inventory entry with a named owner, the model provider and the list of competitor domains. It rates the agent internal, medium risk. The agent is internal, but its numbers can reach customers through sales reps.
| Governance Question | Control | Evidence Produced |
|---|---|---|
| Is the agent known and owned? | Inventory entry with a named owner | Inventory record with owner and last review date |
| How risky is it? | Medium tier for internal use with indirect customer exposure | Risk note with tier and reason |
| May it read these sources? | Domain allow-list, with robots.txt and terms checked before collection | Robots.txt snapshot and ToS review date per domain |
| Is the data current? | Maximum age for price pages, plus change monitoring | Retrieval timestamps and change logs |
| Can claims be checked? | Each price in the summary cites its source URL | Output with source URLs and retrieval times |
| Who approves customer use? | Human approval before any figure goes to a customer | Approver name and timestamp in the audit log |
| What did the agent do? | Per-request audit logging | Log entries for prompts, tool calls, sources and outputs |
ToS stands for terms of service, the rules a site sets for using its content. If a customer asks where a price came from, the team can point to the source, the retrieval time and the approver. The answer comes from logs instead of memory.
AI Governance vs. Data Governance vs. AI Compliance
AI governance, data governance and AI compliance overlap, but each answers a different question. AI governance includes data governance for AI and produces the evidence that compliance relies on.
Data governance is how an organization manages data quality, access, origin and retention. AI compliance means meeting the legal, regulatory and contractual rules that apply to AI. The table compares all three on the same attributes.
| Term | What It Covers | Main Question | Owner | Example Output |
|---|---|---|---|---|
| AI governance | Policies, roles and controls for AI systems across their lifecycle | Who may do what with AI, under which rules? | Executive owner plus system owners | AI inventory, risk tiers and audit logs |
| Data governance | Quality, access, origin and retention of data | Is this data accurate, permitted and well managed? | Data owners or data platform team | Data catalog, access policies and retention schedule |
| AI compliance | Legal, regulatory and contractual duties for AI | Do we meet the rules that apply to us? | Legal, compliance or security lead | Regulatory documentation and questionnaire answers |
Compliance teams draw on the evidence that governance creates. When governance logs are missing, compliance work turns into manual reconstruction.
How to Start an AI Governance Program
Start an AI governance program by naming an owner, listing your AI systems and turning on logging before you write long policies. You need access to your codebase, vendor list and production logs.
- Name an owner who is accountable for the program, plus a system owner for each AI system.
- Build the inventory of models, agents and AI features, including AI inside SaaS tools and each system's data sources.
- Tier each system by risk as low, medium or high, based on its impact.
- Write a short AI governance policy that covers approved tools, data rules and when human approval is required.
- Turn on logging for the audit-log fields above, including retrieved sources and retrieval times.
- Review the inventory, tiers, source permissions and logs on a set schedule.
After the first pass, you should be able to answer four questions. What AI do we run, who owns it, what data does it use, and how do we know it's working? If any answer needs a meeting to piece together, repeat the matching step.
This minimum program does not cover bias testing or deep model evaluation. Add those as your risk tiers require.
Frequently Asked Questions
What Are the Three Pillars of AI Governance?
We group AI governance into three pillars: accountability, transparency and risk management. Frameworks vary, and some list four, five or more principles.
What Is an Example of AI Governance?
One example is requiring human approval and source logging before a research agent's output reaches customers. Regulations such as the EU AI Act are external examples that set rules organizations must follow.
Which Companies Offer AI Governance Tools?
Vendors range from dedicated governance platforms to cloud and data providers with governance features. Compare them on inventory, policy enforcement, monitoring and audit features for the systems you run.
Who Is Responsible for AI Governance?
A named executive owns the AI governance program, and a system owner is accountable for each AI system.
Does AI Governance Cover Data Retrieved From the Web?
Yes, data retrieved from the web is an input, so its source, permissions, freshness and attribution need the same controls as training data.
How Do You Keep AI Governance From Becoming Paperwork?
Tie each policy to an enforced control and a log that proves the control ran. If a rule has neither, rewrite it or remove it.