Enterprise AI Governance: Security and Compliance Guide

Most companies now have AI in the building, but far fewer have a clear answer to a simple question: who is allowed to use which AI, on which data, and how would we prove it later? Enterprise AI governance is the set of policies, technical controls and accountability structures that answers that question. It decides what data an assistant can see, what it can do with that data, who can switch it on, and what evidence exists when an auditor, a customer or a regulator asks.

The pressure to get this right is no longer theoretical. The EU AI Act has been amended and is moving toward its main compliance dates. Breach reports now measure the cost of ungoverned AI in dollars. Security teams are being asked to approve tools that behave very differently from the software they are used to reviewing. This guide walks through the frameworks and regulations that matter, the real security risks (prompt injection and data leakage among them), the controls worth building, and how an architecture such as Higgins Enterprise is designed to fit inside a governed environment.

Key takeaways

• Enterprise AI governance is a technical and organizational discipline, not a policy PDF. Policy without enforced permissions, logging and data boundaries does not hold up under audit.
• NIST AI RMF and ISO/IEC 42001 give you a structure; the EU AI Act, GDPR, HIPAA and 21 CFR Part 11 give you obligations. Map one to the other once, then reuse the evidence.
• IBM's 2025 breach research found that 97% of organizations that reported an AI-related breach lacked proper AI access controls, so permissions are the highest-leverage control.
• Keep company data inside your own environment. Architectures that never send proprietary data or IP outside the enterprise remove entire categories of leakage and residency problems.
• Treat vendor claims carefully. "Designed to support" a regulation is not a certification, so ask what scope applies to your deployment and get it in writing.

Why enterprise AI governance is now a board-level issue

For two years, AI adoption was driven by curiosity. Teams tried chatbots, copied in a document or two, and reported back. The risk profile of that behavior was small because the use was small. Today the same tools sit inside email, document stores, ticketing systems and product data, and they act on more than they read. The exposure grows with every connection.

Three forces have converged. First, regulators have started writing AI-specific rules while existing privacy and sector rules already apply to AI processing personal or regulated data. Second, customers now include AI questions in security questionnaires, asking where data goes, who can see prompts and whether it is used to train a model. Third, the economics of failure are visible. IBM's Cost of a Data Breach Report 2025 put the global average breach at $4.44 million and the U.S. average at a record $10.22 million, and it reported that 63% of breached organizations either had no AI governance policy or were still developing one (IBM, 2025).

The AI governance gap, in numbers

The practical meaning is plain. Governance is not what slows AI down. Missing governance is what forces a company to freeze a rollout after an incident, or to quietly tolerate employees using whatever tool they like. If you want AI to scale past a pilot, the controls have to exist before the incident, not after it. Our post on why enterprise AI pilots fail shows how often trust and security concerns are what stall projects that otherwise work technically.

The framework layer: NIST AI RMF and ISO/IEC 42001

Frameworks are not law, but they are how most organizations turn vague duties into a repeatable program. Two matter most for enterprise AI governance, and they complement each other.

NIST AI Risk Management Framework

The U.S. National Institute of Standards and Technology published the AI Risk Management Framework 1.0 in January 2023 as a voluntary, sector-neutral guide. It organizes AI risk work into four functions: Govern, Map, Measure and Manage. Govern is the cross-cutting function: accountability, policies, culture and oversight. Map establishes context, meaning what the system is for, who it affects and what could go wrong. Measure analyzes and tracks those risks with defined methods. Manage prioritizes and treats them, including response and decommissioning.

NIST also released a Generative AI Profile in 2024 that applies the framework to risks specific to generative systems, such as confabulation, data privacy and information security. The framework is useful because it is not tied to a technology. You can use it to assess a vendor assistant, a model you fine-tuned, or an agent that takes actions. Details are on the NIST AI RMF page.

ISO/IEC 42001

ISO/IEC 42001, published in December 2023, is the first international management system standard for AI. Where NIST gives guidance, ISO 42001 gives a certifiable structure, in the same family as ISO 27001 for information security. It asks an organization to define its AI policy, assign roles, assess AI risks and impacts, set controls across the lifecycle, monitor performance and improve continuously. See the ISO/IEC 42001 standard listing for scope.

For many enterprises, the sensible pattern is to use NIST AI RMF as the working vocabulary for risk conversations and ISO 42001 as the management-system skeleton, particularly if you already run ISO 27001 or ISO 9001 processes. Importantly, neither one tells you which tool to buy. They tell you what you must be able to show about how you use it.

The EU AI Act timeline, updated for 2026

The EU AI Act is the most discussed AI regulation in the world, and its dates have just moved, so it is worth being precise. The Act entered into force in August 2024 and applies in stages. Prohibited practices and AI literacy duties began applying in February 2025, and obligations for general-purpose AI models began in August 2025.

The part that changed in 2026 concerns high-risk systems. Under the original schedule, stand-alone high-risk rules were due on 2 August 2026. The Digital Omnibus on AI, a package that streamlines and delays parts of the Act, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, according to Lewis Silkin's summary. Law firm analysis of the provisional deal, such as Sidley's June 2026 note, reports the same new dates.

For an enterprise, the Act's reach is wide. If you place AI on the EU market or use it for decisions about people in the EU, it can apply regardless of where you are headquartered. Penalties for the most serious violations can reach 35 million euros or 7% of worldwide turnover, whichever is higher. Most enterprise uses of an internal assistant will not be high-risk, but employment-related and medical-device-related uses can be, and your AI inventory should say which is which.

Privacy and sector rules that already apply

AI does not get a special exemption from the rules you already follow. When an assistant reads email, a shared drive or a quality system, it is processing whatever those systems contain. That makes the following regimes relevant to almost every AI rollout.

GDPR

The General Data Protection Regulation applies when personal data of people in the EU is processed. Principles that bite hardest for AI are lawful basis, purpose limitation, data minimization, transparency, security of processing, and restrictions on cross-border transfers. Rules on solely automated decisions with significant effects add further duties. Fines can reach 20 million euros or 4% of worldwide annual turnover. In practice, your AI program needs a record of what personal data each assistant can access, a way to honor access and deletion requests, and a documented transfer mechanism if data leaves the EU.

HIPAA

In the United States, the HIPAA Privacy and Security Rules govern protected health information held by covered entities and their business associates. For AI that means access controls, audit controls, transmission security and, when a vendor handles PHI, a business associate agreement. Pasting patient information into a consumer chatbot is the sort of act that fails these tests immediately, since no agreement or safeguards exist.

SOC 2

SOC 2 is an attestation framework, not a regulation. A SOC 2 report tells your customers that your controls for security, availability, confidentiality, processing integrity or privacy were examined by an independent auditor. If you build or buy AI, your auditors will ask how the new system fits into your existing control environment: access reviews, change management, logging, vendor management and incident response.

21 CFR Part 11

Life sciences, medical device and pharmaceutical teams face the FDA's 21 CFR Part 11, which sets expectations for electronic records and electronic signatures: system validation, secure computer-generated audit trails, access limited to authorized individuals, and record integrity. An AI that drafts, summarizes or retrieves controlled documents must not weaken any of these. Teams in these industries should read our companion piece on AI in regulated industries for SOPs, QA and regulatory affairs.

The common thread across all four is not mysterious. Each wants you to know what data is involved, restrict who can reach it, keep evidence of what happened, and be able to show that your vendor does the same.

The security risks specific to generative AI

Classic security controls still apply, but language models add failure modes that older software did not have. Four are worth understanding clearly.

Prompt injection. The OWASP Top 10 for LLM Applications ranks prompt injection first for 2025. The idea is that instructions hidden in content can override what the system was told to do. Direct injection comes from the user. Indirect injection is more worrying: a document, web page or email contains instructions that the model reads and may follow. If the assistant can also take actions, such as sending messages or updating records, the consequences grow.

Sensitive data disclosure. A model that can see a lot of data can surface a lot of data. If permissions in the underlying source are loose, an assistant can make badly permissioned content easy to find. This is why clean permissions come before wide connection.

Excessive agency. Agentic systems that act on your behalf need narrow scopes. An assistant allowed to read a repository should not automatically be allowed to write to it. See agentic AI in the enterprise for how to scope actions safely.

Leakage to external services. Every time company information is sent to a third-party model, you inherit questions about retention, training use, subprocessors and location. Employees using personal accounts bypass all of that, a problem we address in shadow AI risk and control.

A governed AI request, step by step

1. AuthenticateConfirm who is asking and which roles apply.
2. AuthorizeCheck permissions on the data source and the AI capability requested.
3. RetrievePull only the content that user is allowed to see, from approved sources.
4. Generate or actProduce the answer or run the permitted action within its scope.
5. RecordLog the request, sources and outcome for review.

No single control stops all of these. Defense in depth is the right posture: least-privilege access, input and output filtering, human approval for consequential actions, rate limits, monitoring, and red-team testing before and after launch.

What the evidence says about breach cost

Executives often ask whether governance spending is justified. The IBM data offers a useful, if sobering, comparison. In the 2025 report, organizations that used AI and automation extensively in security operations averaged breach costs of $3.62 million, compared with $5.52 million for those that did not, a difference IBM summarized as $1.9 million in savings and an 80-day shorter breach lifecycle (Kiteworks summary of IBM's report; IBM newsroom).

Average cost of a data breach, 2025

View chart data

Item	Value
Global average	$M4.44
U.S. average	$M10.22
Extensive security AI and automation	$M3.62
No security AI or automation	$M5.52

Read this carefully. The finding is not that AI is risky or that AI is safe. It is that ungoverned AI is expensive and governed AI is an advantage. IBM also reported that 13% of organizations had experienced a breach of an AI model or application, and that of those, 97% lacked proper AI access controls. Only 34% of organizations with an AI governance policy performed regular audits for unsanctioned AI.

Where AI governance is failing

View chart data

Item	Value
Breached organizations with no AI governance policy, or one still in development	63%
AI-breached organizations lacking proper AI access controls	97%
Organizations reporting a breach of an AI model or application	13%
Organizations with a policy that audit regularly for unsanctioned AI	34%

The controls that matter most

If you have to prioritize, put effort where the evidence points. These are the controls we see matter most in practice, expressed as questions you can ask of any platform, including your own.

Access control and permissions

Role-based access should apply to the AI, not just to the application behind it. You want a central place to define which teams can use which assistants, which data sources each can reach, and which actions are allowed. Permissions must flow from source systems so that the assistant never sees more than the person asking could see. Review them on a schedule, and remove access when people change roles.

Data residency and boundaries

Data residency is about where data is stored and processed, and about who can reach it. Know the answer for prompts, retrieved content, embeddings, logs and backups. The simplest boundary to defend is one where proprietary data and intellectual property do not leave your environment at all. If any part of the processing happens outside your region or outside your control, document it, map it to your transfer mechanism and make sure contracts agree.

Audit trails

An audit trail should let you reconstruct who asked what, which sources were used, what was returned and what actions followed. This matters for Part 11 style evidence, for HIPAA audit controls, for SOC 2 monitoring and for ordinary incident response. Be specific when you evaluate vendors: ask what is logged, how long it is retained, whether logs can be exported to your own monitoring, and who can read them.

Data minimization and quality

AI amplifies the state of your data. Stale or duplicated content produces confident wrong answers, and over-shared folders produce leaks. Cleaning permissions and designating authoritative sources is governance work, not just data work. Our guide to data readiness and a single source of truth covers the practical steps.

Human oversight and testing

Decide which outputs need review before they are used, particularly in regulated work. Test for prompt injection and data leakage before launch, and repeat when you add new connectors or new abilities.

How Higgins approaches governed AI

Higgins is an enterprise AI platform from higgins.ai that sits in front of the applications you already run and gives each associate one assistant for retrieving information, finding SOPs, forms and reports, summarizing email and capturing meeting actions. Because it connects to systems that hold sensitive information, its design starts from the question of control.

Data stays in your environment. Higgins is described as a "Safe and Secure AI Environment": company data and intellectual property are not permitted to leave the company's environment. When an outside information request is needed, the request goes out and the returned information comes back, without exposing company data or IP. This is a meaningful architectural choice. It narrows the residency and third-party retention questions that dominate most AI security reviews.

Federated access instead of copying everything. Higgins is a federated layer. It can draw on data directly from an application through its API, from a repository or backup of that application, or from a secondary repository, and it can use a clean internal data lake and departmental directories. Data and training can be refreshed daily or weekly depending on need. Fewer uncontrolled copies mean fewer places for sensitive information to sit.

Centralized permissions and usage. Higgins can be deployed as a global standardized internal AI with usage and permissions governed centrally, managed by the corporation and by function and department, and optimized down to the individual associate. That gives security and compliance teams one place to decide who can use what, rather than a patchwork of individual tools.

Built for your IT approval process. Higgins is designed to be approved through the customer's IT process, including risk assessments, security testing and API security testing. We would rather you test it than take it on trust.

Phased rollout lowers risk. Implementation begins with Best Practices AI that is not connected to company data, moves to a junior-level assistant connected to a limited set of repositories, and then to a senior-level assistant connected through APIs to systems such as PLM or quality tools. Each phase has a deliverable and listening sessions to surface concerns early. Security review can happen at each boundary instead of once at the end. See implementation and the integrations page for detail.

You can read more on the security and compliance page.

A practical 90-day governance plan

You do not need a perfect program to begin. You need a credible one that improves quarter by quarter. Here is a sequence that works for most enterprises.

Days 1 to 30: see and decide. Build an inventory of AI tools in use, sanctioned or not, and the data each touches. Classify use cases by risk, noting any that involve personal data, health data, regulated records or employment decisions. Name an accountable owner and a small cross-functional group from security, legal, IT, quality and the business. Draft an acceptable use policy that tells people what they can do, not only what they cannot.

Days 31 to 60: build the guardrails. Choose your reference framework, with NIST AI RMF for risk language and ISO 42001 if you want a certifiable management system. Set role-based access for AI, define the data boundary, and decide what must be logged. Run your vendor and architecture through the IT approval process, including security and API testing. Test for prompt injection and sensitive data disclosure before real data goes near the system.

Days 61 to 90: launch small and measure. Start with a sandbox, then a pilot with a bounded group, then a wider beta. Collect feedback, review access logs, adjust permissions and write down what you learned. Set a review cadence for new connectors, new models and new regulations. The EU AI Act dates, for instance, are worth a standing calendar item.

Measure governance like any other program. Useful indicators include the share of AI use that runs on sanctioned platforms, the number of access reviews completed on time, time to revoke access, and the number of use cases with a documented risk classification. We explore broader measurement in measuring AI ROI with usage-based pricing.

Frequently asked questions

Next steps

If you are building an AI governance program, start by mapping what you have, then choose a platform that fits your controls instead of asking your controls to fit the platform. To see how Higgins fits a governed rollout, read about Higgins Enterprise, hear from users in our testimonials, learn more about Higgins, or contact the team to discuss your security review. For hands-on training on practical AI use, the Higgins Masterclass is a good place to start.