AI governance is the accountability layer around the AI systems an organization runs. It decides who owns each one, what it’s allowed to do, and what the organization needs to be able to show about it. That includes systems a team might not even describe as AI.
Legal and risk own the accountability, but security has to provide much of the evidence. That covers what’s deployed, what it touches, and what’s changed. That starts with an accurate inventory. AI can enter an environment through product updates, embedded assistants, free trials, and API integrations faster than procurement records it.
The EU amended its AI Act in July 2026, with the next date under it falling on December 2, 2026. Several US states brought their own AI laws into force this year. The UK still has no AI Act.
This guide covers what an AI governance framework contains, how to find the AI systems already running, assign ownership, work out which requirements apply, and keep the right evidence as things change. It covers the current position in the EU, US, and UK, with a checklist at the end keyed to the dates that are live now.
Key Takeaways on AI Governance
- AI governance comes down to accountability and evidence. Legal and risk own the obligation, and security supplies the proof.
- Shadow AI is a discovery problem before it becomes a policy problem, and the systems nobody registered are the ones a regulator’s question tends to land on.
- The parts of a framework that last are discovery, ownership, classification, controls, evidence and review, and none of them depend on a single deadline.
- The EU AI Act reaches companies established outside the EU. Article 50 has applied since August 2, 2026, and the next date under it is December 2, 2026.
- The US has no federal AI statute and several state laws. In Texas, substantial compliance with the NIST AI Risk Management Framework is a defense you can raise in enforcement.
What Is AI Governance?
AI governance is the set of policies, roles, and controls that determines who is accountable for an AI system, what it is allowed to do, and what evidence the organization can provide to a regulator. In simple terms, governance answers who is responsible; security answers what is exposed and what the system can reach.
The two overlap, but they aren’t the same discipline. AI governance establishes accountability and maps systems to obligations. AI security looks at the technical exposure created by those systems, including credentials, data access, integrations, model interfaces, and the actions an AI system can take.
The distinction is useful when you look at AI agents and large language models. AI agent security focuses on what an agent can access and do. LLM security focuses on the model and the application layer around it. Governance sits above both, defining ownership, policy, classification, evidence, and review.
Output quality is a separate concern. A hallucination can be a product or model-security problem, but transparency and disclosure obligations don’t depend on whether an output happens to be accurate.
Accountability vs. Security Evidence
Legal and risk teams are generally best placed to determine what an obligation means for the organization. Security teams are the people who can establish what is deployed, what it connects to, what changed, and what controls are operating.
That makes the inventory important. Governance can’t be more complete than the picture of the environment it is governing.
Shadow AI and the AI Attack Surface
Shadow AI is any AI system or feature running in your environment that hasn’t been through review. An AI system is part of the attack surface when it holds credentials, calls an external API, reads organizational data, or produces output that people or systems trust. It should therefore be treated like other technology in the environment, not as a separate class of software that lives outside normal security operations.
The challenge is that the official inventory rarely tells the whole story. A governance register built from procurement alone can miss AI introduced through existing SaaS products, developer tools, browser extensions, or inherited systems.
The goal isn’t to create another manually maintained spreadsheet. The useful register is a view of the live environment that can be reconciled against the systems the organization knows it has. That’s the same discipline a cryptographic inventory needs to survive an audit.
Where Shadow AI Comes From
- Vendor features: existing SaaS products can add AI capabilities without creating a new procurement record.
- Embedded assistants: AI can appear inside collaboration, development, productivity, security, and other tools already approved for use.
- Model and API integrations: developers can connect applications directly to model providers without going through a formal AI procurement process.
- Inherited systems: acquired businesses, legacy applications, and third-party platforms can introduce AI that isn’t yet documented centrally.
None of this necessarily means someone has broken a policy. It means the inventory process has to account for how software enters an environment in the real world.
How to Run Shadow AI Discovery
A practical discovery process can combine several signals:
- Model-provider traffic and API activity.
- SaaS administration and application logs.
- Browser extensions and locally installed AI tooling.
- Expense, procurement, and vendor records.
Run those checks on a schedule rather than treating discovery as a one-time project, the same continuous discovery loop that continuous threat exposure management describes. The environment changes, and a governance register should change with it.
How to Build an AI Governance Framework
A useful AI governance framework doesn’t need to be complicated. It needs to be repeatable. The core cycle is discovery, ownership, classification, controls, evidence, and review.
Two established references are useful starting points: the NIST AI Risk Management Framework (AI RMF), which provides a voluntary framework for managing AI risks, and ISO/IEC 42001, which specifies requirements for an AI management system. Neither replaces legal advice or tells an organization exactly how to comply with every jurisdictional requirement. They provide structure that can be adapted to the obligations that apply. The EU AI Act has a broad territorial reach. In relevant circumstances, obligations can apply to organizations outside the EU when AI systems are placed on the EU market or when outputs are used in the EU. That makes geographic scope part of the discovery and classification process.
In 2026, Regulation (EU) 2026/1744 changed parts of the implementation timetable. The important point for security teams is that the change was not a blanket delay of the Act. The high-risk timetable moved, while the transparency requirements in Article 50 continued to apply.
The amended timetable includes a later date for standalone high-risk systems under Annex III and a later date for high-risk AI embedded in products covered by EU product-safety legislation under Annex I. Organizations should use the Official Journal text and current Commission guidance when determining which date applies to a specific system.
Article 50 is particularly relevant to security and IT teams because it covers transparency obligations for certain AI systems, including direct interaction with people and AI-generated or manipulated content. For systems already placed on the market before 2 August 2026, the marking and detection requirement for AI-generated content has a 2 December 2026 transition date.
Other AI Act requirements have been applicable since earlier dates, including the prohibited-practices provisions and obligations relating to general-purpose AI. The exact obligation depends on the role of the organization and the system in question.
The European Commission has also published a voluntary Code of Practice on marking and labelling AI-generated content. Organizations should check the current Commission material and the final legal text before relying on any particular implementation approach.
- Discover Every AI System in Use
Start by reconciling the systems the organization knows about with what the environment shows. Compare procurement and application records with model-provider traffic, SaaS logs, browser extensions, developer activity, and other discovery signals. The result should be an inventory that reflects the environment rather than a list that reflects what someone remembers approving. - Assign a Named Owner
Every system needs a named owner with enough authority to change its configuration, restrict its access, or retire it when necessary. Responsibility can be shared across legal, product, IT, and security, but accountability still needs a clear owner. This is where enterprise AI governance tends to come apart, because an obligation that belongs to everyone gets met by nobody. - Classify Against the Obligations
Classification should connect each system to the requirements that apply to it. The questions will vary by jurisdiction. A useful starting point is whether the system interacts directly with people, generates content, or handles personal or sensitive data. It also matters whether it performs functions that may fall into a higher-risk category, or is used in a regulated context. Record the reasoning as well as the classification. - Select Controls per Obligation
Controls should follow from the obligations rather than being added as a generic AI checklist. Depending on the system, that might include disclosure at the point of interaction, technical measures for identifying AI-generated content, access controls, logging, or safeguards around prohibited uses. - Collect Evidence Continuously
Evidence collected before an audit or a regulatory request is far easier to produce than evidence assembled afterwards. Keep records of ownership, classification decisions, relevant controls, changes, exceptions, and testing as part of normal security operations. Where possible, extend the evidence and control-monitoring processes you already use for frameworks such as ISO 27001, NIS2, or DORA. - Set a Review Trigger on Regulatory Change
A calendar reminder once a year isn’t enough when regulatory requirements are moving. A better trigger is a material regulatory publication or change that could affect the classification or controls for systems in the inventory. Give that trigger a named owner.
Which AI Regulations Apply to You?
The answer depends on where an AI system is placed on the market or used, what it does, and which jurisdiction applies. Company registration alone isn’t always the deciding factor. The table below is a practical orientation. It isn’t a legal applicability test.
| Jurisdiction | Current position | What security teams should watch |
|---|---|---|
| European Union | The EU AI Act applies according to its scope. The 2026 amendment changed parts of the high-risk timeline, and Article 50 transparency requirements remain important. | Inventory systems with EU exposure, identify applicable obligations, and track the December 2, 2026 transition date for certain marking and detection requirements. |
| US federal | No single comprehensive federal AI statute governs all AI use. Existing federal agencies can still regulate conduct within their existing authorities. | Track the laws and regulatory requirements that apply to the organization’s sector and activities. |
| US states | Requirements vary by state. Texas, California, and Colorado have enacted AI legislation with different scopes and effective dates. | Maintain jurisdiction-aware classification rather than assuming one state-law approach applies everywhere. |
| United Kingdom | The UK continues to use a sector-led approach rather than a single dedicated AI Act. | Map AI use to existing data protection, online safety, cybersecurity, and sector-specific requirements where applicable. |
The EU AI Act
The EU AI Act has a broad territorial reach. In relevant circumstances, obligations can apply to organizations outside the EU when AI systems are placed on the EU market or when outputs are used in the EU. That makes geographic scope part of the discovery and classification process.
In 2026, Regulation (EU) 2026/1744 changed parts of the implementation timetable. The important point for security teams is that the change was not a blanket delay of the Act. The high-risk timetable moved, while the transparency requirements in Article 50 continued to apply.
The amended timetable includes a later date for standalone high-risk systems under Annex III and a later date for high-risk AI embedded in products covered by EU product-safety legislation under Annex I. Organizations should use the Official Journal text and current Commission guidance when determining which date applies to a specific system.
Article 50 is particularly relevant to security and IT teams because it covers transparency obligations for certain AI systems, including direct interaction with people and AI-generated or manipulated content. For systems already placed on the market before 2 August 2026, the marking and detection requirement for AI-generated content has a 2 December 2026 transition date.
Other AI Act requirements have been applicable since earlier dates, including the prohibited-practices provisions and obligations relating to general-purpose AI. The exact obligation depends on the role of the organization and the system in question.
The European Commission has also published a voluntary Code of Practice on marking and labelling AI-generated content. Organizations should check the current Commission material and the final legal text before relying on any particular implementation approach.
State AI Laws in the US
The US doesn’t currently have one comprehensive federal AI statute covering the field as a whole. Instead, organizations need to consider federal requirements that already apply to their activities alongside state-level AI legislation.
Texas, California, and Colorado illustrate why a single national checklist isn’t enough. Texas’s Responsible Artificial Intelligence Governance Act took effect in 2026 and includes an affirmative defense tied to substantial compliance with the NIST AI RMF. California has enacted AI-related requirements that took effect in 2026, while Colorado’s amended AI law has a 2027 effective date.
These laws differ in scope and terminology, so the operational answer isn’t to maintain one generic ‘US AI compliance’ status. Keep the underlying inventory consistent, then apply jurisdiction-specific classification and controls.
UK AI Regulation
The UK has continued with a sector-led approach rather than introducing a single dedicated AI Act. Existing requirements can still apply to AI systems, including data protection requirements and AI guidance from the ICO, online safety, cybersecurity, and sector-specific regulation.
For security teams, that means AI governance needs to sit alongside the controls and evidence already maintained for the organization’s wider regulatory obligations. There isn’t one UK AI deadline that replaces that work.
AI Governance Best Practices for Enterprise Security Teams
The most useful best practices are operational. They’re things a team does repeatedly, rather than principles that sit in a policy document.
- Keep your AI inventory current. Run shadow AI discovery regularly and update ownership when systems or responsibilities change.
- Keep evidence traceable. Version-control relevant configurations, disclosures, classifications, and generated-content controls alongside the systems they support.
- Reuse existing controls. Extend NIS2, DORA, or ISO 27001 monitoring where it already provides the evidence you need.
- Review when things change. Reassess classification and obligations when a system gains new data sources, users, integrations, or use cases. Assign someone to track regulatory changes and assess their impact.
How AI Governance Sits Alongside NIS2 and DORA
AI governance doesn’t need to become a separate compliance universe. For many European organizations, the better approach is to build AI-related evidence into the control and monitoring processes already used for other regulations.
NIS2 and DORA are concerned with areas such as security, risk management, resilience, governance, and evidence. The exact requirements differ, but there is practical overlap in the need to know what is deployed, who owns it, what controls are operating, and what changed.
That makes the existing security operating approach useful. Rather than maintaining one register for NIS2, another for DORA, and another for AI, look for the evidence and control processes that can support more than one obligation.
AI Governance for MSSPs: One Framework, Many Client Environments
The governance questions are similar for a managed security service provider, but the operating reality is different. An MSSP isn’t maintaining one environment. It’s repeating the assessment across clients with different tooling, configurations, policies, and risk appetites.
That makes discovery and evidence collection natural candidates for delivery automation. The underlying framework can stay consistent while the scope and implementation change from tenant to tenant.
AI Discovery Across Client Environments
Discovery still starts with the same signals. Those are model-provider traffic, SaaS administration, browser and endpoint activity, and procurement or expense records. What changes is the effort required to gather and normalize them across different client environments.
The MSSP can standardize the finding and evidence format without pretending every client has the same obligations. Each environment still needs its own inventory and context.
What the MSSP Owns vs. What the Client Owns
The MSSP can own the operational work of discovery, evidence gathering, change tracking, and reporting. The client should retain ownership of its legal interpretation, system classification, risk acceptance, and business decisions.
That distinction matters. An MSSP can identify an AI system and document what it can reach. Turning that technical finding into a legal conclusion is the client’s call.
For MSSPs, the opportunity is to make that process repeatable. One operational framework can be applied across client environments without turning governance into a manual exercise for every tenant.
AI Governance Checklist
Use this as a practical pre-December 2, 2026 check. It isn’t a substitute for a legal applicability review.
- List every AI system the organization provides, deploys, or makes available in the EU, where the EU AI Act applies.
- Reconcile the inventory against model-provider traffic, SaaS logs, browser or endpoint activity, and procurement or expense records.
- Identify which systems interact directly with people and confirm the applicable transparency requirements.
- For AI-generated content, confirm that the required marking and detection controls are supported by the production pipeline and aren’t stripped during export or reprocessing.
- Assign a named owner to every system.
- Record the classification decision and the reasoning behind it.
- Review the applicable EU AI Act implementation guidance and determine whether the relevant voluntary Code of Practice is being used.
- Fold AI-related evidence into existing NIS2, DORA, ISO 27001, or other applicable control-monitoring processes where appropriate.
- Set a named review trigger for regulatory changes so material updates result in a reassessment of affected systems.
Where Zynap Fits in AI Governance
We’re a preemptive cybersecurity platform. We discover what’s exposed across an environment, validate what’s exploitable, and reduce it, using AI agents and human-governed workflows.
Zynap is not an AI governance platform. We don’t sell governance software, and nothing we do makes an organization AI Act compliant. What we can help with is discovery and evidence. Applied to this work, that means finding the systems and integrations running in an environment rather than the ones on a list. It also means picking up the changes that would reset a classification.
NINA is the multi-agent engine behind that work, and every action it takes is traceable, auditable, reversible and policy-controlled. That’s the same property DORA and NIS2 ask for, and it’s what makes automated work usable as evidence at all. We measure the result in MTRER, or Mean Time to Reduce Exploitable Risk, a metric we coined. MTTR tells you how fast you responded after an incident, and there wasn’t one for reducing the risk before it.
Where to Start With AI Governance
If you’re building this over the next quarter, three things move it furthest.
- Running discovery once and comparing it against the procurement list, since the gap is your real scope.
- Putting a name against every system before classifying anything.
- Pointing the control monitoring you already have at the AI systems you found, rather than standing up a second register.
Get in touch if you’d like to see how we discover and validate what’s running in an environment.