How is AI governance different from data governance or IT governance?
AI governance doesn’t replace data or IT governance. Rather, it’s an extension of both. IT governance answers whether a system is secure, supported, and worth the spend. Data governance answers who can access which information and how it’s classified, retained, and protected.
AI governance answers a different question: whether a tool should be trusted for a specific decision, who can use it, and what data it should access.
IT governance vs. data governance vs. AI governance
| | IT Governance | Data Governance | AI Governance |
| Core question | Is this system secure, supported, and cost-justified? | Who can access this data, and how is it classified and retained? | Should this tool inform this decision, and who checks the output? |
| Primary focus | Systems and infrastructure | Information assets | Use cases and model behavior |
| Typical owner | IT leadership | Compliance, data stewards | Cross-functional committee |
| Key artifacts | Standards, change control, vendor reviews | Classification schema, retention policy, access matrix | AI inventory, use-case risk tiers, acceptable use policy |
| What’s distinct | Deterministic systems behave predictably | Data is static and can be inventoried precisely | Output varies run to run; risk shifts as vendors update models |
How is AI governance different from an acceptable use policy?
An acceptable use policy is one artifact inside AI governance, not a substitute for a holistic approach. The AUP is a set of rules governing how employees should use AI. The AUP is a necessary component, but it only answers questions someone anticipated in advance. It can’t tell you what tools are actually in use, whether a new one should be approved, who reviews a high-stakes output, or what to do when a vendor turns on an AI feature you never evaluated.
Comparison table: AI governance vs. acceptable use policy
| | Acceptable Use Policy | AI Governance |
| What it is | A document | A program |
| Audience | Employees | Leadership, IT/security, compliance, business owners |
| Answers | What am I allowed to do? | What are we using, at what risk, and who decides? |
| Scope | Known tools and known rules | Discovery, new requests, vendor changes, incidents |
| Failure mode | Silent on anything it didn’t anticipate | Requires sustained ownership to stay current |
| Update trigger | Periodic review | Any new use case, tool, or vendor model change |
In other words, an acceptable use policy is a critical component of an AI governance program, but the program itself should cover much more than the policy.
Ready to get started on your AUP?
Download our GenAI Policy Template >>
Is AI governance legally required?
No single law says, “You must have an AI governance program.” However, AI governance is effectively required by law in many scenarios due to regulation that affects how an organization handles their data. While there’s no comprehensive federal AI statute in the U.S., state AI laws remain in effect and enforceable.
The resulting environment is a patchwork of state laws, sector regulators, insurers, and customer contracts each imposing pieces of what a governance program produces.
Here’s what that looks like in detail.
AI governance: Not required, strictly speaking
- No U.S. federal law mandates an AI governance program for private companies.
- NIST AI RMF is voluntary. ISO/IEC 42001 is certifiable but elective — you pursue it because a customer or insurer asks you to.
AI governance required in specific situations
- State law, by use case. California, Texas, Illinois, and Utah obligations are in force, and Colorado’s replacement framework starts January 2027. Colorado’s amended law (SB 26-189) scaled back employer obligations substantially and now requires notice to individuals, a structured adverse action and human review process, and record retention of at least three years.
- Hiring and employment tools. Illinois requires disclosure when AI is used in employment decisions; NYC Local Law 144 requires bias audits for automated employment decision tools.
- EU exposure. If your use of AI exposes you to regulatory scenarios the EU market, the Article 50 transparency obligations apply from August 2, 2026, with high-risk obligations deferred to December 2027 and August 2028.
- Sector regulators. HIPAA, GLBA, FERPA, and CMMC don’t name AI, but they still govern the data flowing into it, and examiners may ask about the use of AI.
AI governance required in practice
- Cyber insurance renewal questionnaires now ask about AI use and controls.
- Enterprise and government customers are adding AI clauses to vendor security reviews and MSAs.
- Board and audit committees are asking for an AI inventory whether or not a regulator is.
Does the EU AI Act apply to a U.S. mid-market company?
For a U.S. mid-market company that uses AI rather than building or selling it, the answer is usually no, but not automatically. The AI Act reaches non-EU organizations in two ways that may be relevant to you:
- You’re established or operating in the EU.
- The output of an AI system you use is used in the EU.
A 300-user manufacturer in Ohio running Copilot and a few SaaS AI features for domestic operations falls outside it. The same company with an EU subsidiary, EU-based employees, or AI-assisted decisions affecting EU customers does not. And even when it applies, obligations on deployers are far lighter than the ones on providers.
When it reaches you
- You have an EU establishment, subsidiary, or EU-based employees.
- You use AI output that is then used in the EU—for example, AI-assisted screening for EU-based roles, or scoring applied to EU customers.
- Purely domestic use with no EU nexus is out of scope, regardless of which model you use.
What you’d owe as a deployer of AI (not a provider)
- Use the system per the provider’s instructions, and assign human oversight to someone competent and empowered to override it.
- Ensure input data is relevant and representative for the intended purpose, where you control the inputs.
- Retain system logs where they’re under your control.
- Inform workers and their representatives before putting a high-risk system into use in the workplace.
- Tell affected people when a high-risk system informs a decision about them.
- AI literacy, i.e. training staff who use AI on its capabilities and limits. This one applies broadly to deployers and has been in effect since February 2025.
How does AI governance intersect with HIPAA, GLBA, FERPA, or CMMC?
None of these four regulatory frameworks mentions AI, and none of them needs to. Each one governs a category of regulated data, and AI simply creates a fast, employee-driven path for that data to reach a third party you never vetted.
The intersection isn’t a new set of obligations. Rather, it’s the same obligations applied to a new pathway. AI governance is what makes that mapping explicit. It identifies which AI tools touch regulated data and gives you the documentation to show an auditor when they ask. The distinguishing factor across the four is how much room you have. HIPAA and GLBA are largely about vendor contracts and controls, while CMMC leaves almost no room at all.
| Framework | Regulated data | Where AI creates exposure | What governance adds |
| HIPAA | PHI | Staff pasting patient detail into general-purpose tools; AI features in EHR or scheduling systems | BAA with any vendor processing PHI; minimum-necessary applied to prompts; audit logging of AI access |
| GLBA | Customer financial information | AI in loan, underwriting, or servicing workflows; unvetted tools in client-facing roles | AI vendors treated as service providers under the Safeguards Rule; risk assessment updated to cover AI; access controls and oversight documented |
| FERPA | Student education records | Tools used by faculty and staff; vendors training models on student data | School-official exception applied deliberately—direct control, legitimate educational interest, and explicit no-training / no-secondary-use terms |
| CMMC | CUI and FCI | Any AI tool that ingests CUI, including AI features enabled inside existing cloud services | Hard boundary: CUI stays in assessed, FedRAMP-equivalent environments; enclave separation; AI tools inventoried as in-scope assets |
When it comes to CMMC, the answer is often simply “no.” A defense manufacturer can’t route CUI through a consumer AI tool under any policy language.
We only use Microsoft 365 Copilot and ChatGPT—do we still need governance?
Yes. In fact, using only two mainstream tools is closer to the reason you need governance than an argument against it. The question assumes that risk scales with the number of AI tools, but it actually scales with how much of your data those tools can reach—and how many decisions they touch.
Copilot and ChatGPT are the two broadest cases of both. Copilot inherits every permission your users already have, which means any oversharing latent in SharePoint and OneDrive becomes instantly searchable rather than merely present. And “we only use two tools” is almost always a statement about what IT approved, not about what’s actually running in terms of shadow AI.
There are a few specifics worth mentioning. For example, Copilot surfaces content based on existing access, so a broadly-permissioned site becomes a natural-language query result. The permissions problem predates AI, and AI makes it visible.
On the ChatGPT side, the consumer version and the enterprise version have materially different data handling, and employees generally don’t know which one they’re using or why it matters. Neither tool answers who reviews AI output before it goes to a client or informs a personnel decision, what happens when a vendor turns on a new AI feature by default, or what you tell a customer’s security questionnaire when it asks how you use AI. All of these are AI governance questions.
Who should own AI governance?
In most organizations, IT ends up owning AI governance in practice. IT holds the tenant, the identity layer, the vendor relationships, and the visibility into what’s actually running, so it’s the only function that can enforce a decision.
That said, IT can’t make all of the decisions alone. Whether an AI-assisted hiring screen is defensible is an HR and legal question. Whether an AI-drafted client deliverable meets the standard requires the judgment of a business-side leader. IT owns the mechanism, but the rest of the organization owns the judgment about acceptable use in its own domain.
Typically, the working model for a mid-market organization is IT as accountable owner, with a small standing group that meets quarterly and on-demand when a new tool or use case shows up.
| Function | Role in AI governance |
| IT / Security | Accountable owner. Maintains the AI inventory, enforces access and tenant controls, vets vendors, monitors for unsanctioned tools |
| Legal / Compliance | Maps use cases to regulatory obligations, reviews vendor terms and data-handling language, owns the disclosure and retention requirements |
| HR | Owns employment-related use cases, acceptable use enforcement, training and onboarding, and worker notice where required |
| Finance | Surfaces shadow AI through expense and card data, owns spend approval, evaluates AI use in financial controls and reporting |
| Business unit leaders | Propose and justify use cases, define what “good output” means in their domain, own the human review step |
| Executive sponsor | Sets risk tolerance, arbitrates when functions disagree, ensures the program keeps a review cadence |
Can we do AI governance in-house, or do we need help?
Most mid-market organizations struggle to establish AI governance in-house. They don’t lack the capability but rather the framework fluency and the uninterrupted bandwidth (often weeks of solid work) that are required to stand up the program.
This is why many companies turn to outside help. AI governance consulting offers an outside perspective informed by many implementations across different industries. It also offers an independent assessment that carries more weight with an auditor, insurer, or board than a self-review. The split that works is outside help for the assessment, framework selection, and initial policy set, with internal ownership for everything that recurs.
| Function | Typically owned by | Why |
| Baseline assessment / tool discovery | Consultancy | Independence matters; outside eyes find shadow AI that internal surveys miss |
| Framework selection and mapping | Consultancy | NIST AI RMF vs. ISO 42001 is a fluency question most internal teams face once |
| Policy and AUP drafting | Consultancy, reviewed internally | Faster to adapt a proven template than draft from scratch; internal review makes it fit your culture |
| Risk tiering of use cases | Joint | Consultant supplies the method; only your people know which decisions are consequential |
| AI inventory maintenance | Internal (IT) | Continuous, tied to systems only you can see |
| Approval of new tools and use cases | Internal | Must be fast; outsourcing this creates a bottleneck |
| Vendor and contract review | Internal legal, consultant on complex cases | Routine reviews are internal; unusual data-handling terms benefit from outside input |
| Training and awareness | Internal (HR), consultant-built content | Delivery has to be internal to stick |
| Periodic reassessment | Consultancy, annually or semi-annually | Independence again; also catches drift the internal team stops seeing |
| Incident response for AI issues | Internal, folded into existing IR | Should not be a separate process |
What are the challenges of AI governance?
AI governance comes with several challenges, such as defining a vision, implementing cultural change, and governing data properly. Whether AI adoption is coordinated or happening in an ad hoc fashion, it can have repercussions throughout an organization.
Here are several specific challenges that AI governance should address.
Defining a vision for AI
Without a clear vision from leadership, different teams and individual employees may react differently to the introduction of AI. When leadership articulates a vision, it helps everyone to understand what AI means in the context of the organization’s unique operational processes.
Cultural change
AI is such a new technology, it will almost certainly change your organization’s culture. Whenever your culture starts to change, you want to get control of that change and give it the right shape.
This is why AI governance must account for cultural change. You want to let your teams know exactly how the company will be using AI, what’s expected of them, and how AI will impact their jobs. Communicating things like this before, during, and after AI implementation can help provide clarity and craft a culture that has a positive, informed view of AI.
Ethics
AI presents a new way of working. Users can achieve tasks in seconds or minutes that were incredibly difficult or time-consuming before.
Yet with great power comes great responsibility.
It’s important to specify what kind of AI use is acceptable—and what’s not acceptable. You may find that some employees are already using AI to perform tasks while still getting credit for doing the work manually. You may also find that some employees are using AI outputs without checking them for quality or accuracy. There are many ways that people can get into ethical trouble with AI, so a good governance policy should spell out exactly what the organization expects.
Data governance
On the technical side, it’s important to set up your AI tools with the best possible datasets. Unfortunately, few organizations consider this before implementing AI. They may have some files stored locally, some in the cloud, and no cohesive system bringing them all together. AI can only work with the data it has, so the best AI implementations begin with a cohesive approach to data storage.
Of course, permissions and access are a key part of this as well. If file permissions aren’t set up properly, an AI tool may return answers from a document that a user isn’t supposed to access. The good news is that Microsoft Copilot, when implemented on top of proper permissions in Microsoft 365, automatically shows users only the data to which they have access.
Cybersecurity
When it comes to cybersecurity, not all AI tools have your best interests in mind.
Specifically, the public version of ChatGPT is continuously trained on information entered into prompts. If one of your employees types some proprietary data into ChatGPT and asks the bot to interpret it, that proprietary data may leak out in response to a prompt from another user.
This is a serious issue, and your AI governance policies should take it into account.
The good news is that Microsoft Copilot doesn’t share your organization’s proprietary data outside your Microsoft environment. Learn more here: Microsoft Copilot vs. ChatGPT.
