TL;DR
AI governance, risk, and compliance is one operating discipline, not three parallel programs. Governance assigns decision rights, risk quantifies exposure, and compliance produces the evidence, all running against a single AI inventory and a single control library.
Key Takeaways AI GRC works when governance, risk, and compliance share one AI inventory, one risk taxonomy, and one control library rather than running three separate programs with three sets of paperwork. Regulation (EU) 2026/1744, the Digital Omnibus on AI, moved Annex III high-risk obligations to 2 December 2027 and Annex I obligations to 2 August 2028, while leaving the 2 August 2026 transparency date untouched. The 35 million euro penalty ceiling applies only to prohibited practices under Article 5. High-risk and transparency breaches sit in the 15 million euro tier under Article 99(4). One well-written control can satisfy a NIST AI RMF outcome, an ISO/IEC 42001 requirement, and an EU AI Act duty at the same time, which is what makes a unified control library cheaper than three compliance programs. Agentic AI needs a control overlay that classic model governance never provided, covering agent identity, tool allowlists, action limits, and a kill switch that has actually been tested. Kanerika, one of the earliest Microsoft Purview implementors globally, built the data-control foundation that took a North American healthcare organization to 90% compliance adherence and a 57% reduction in data discovery time. The Date Every AI Compliance Plan Was Built Around Just Moved On 27 July 2026, Regulation (EU) 2026/1744 entered into force and reset the EU AI Act’s high-risk clock. Annex III high-risk obligations now apply from 2 December 2027, and Annex I obligations from 2 August 2028.
Watch on YouTube
Building an AI-Powered Compliance Platform That Scales Across Jurisdictions
Kanerika’s team walks through how a compliance platform holds up when the rules differ by country, which is the same problem an AI GRC control library has to solve.
Most published guidance still names 2 August 2026 as the high-risk deadline. That means a large number of enterprise roadmaps are sequenced against a date that no longer applies, while the transparency duties that did not move are still weeks away.
The deadline shifted, but the exposure did not. In this article, we’ll cover the operating model that holds governance, risk, and compliance together, the crosswalk that turns three frameworks into one control library, the controls agentic AI needs, and finally what belongs in front of the board every quarter.
What AI Governance, Risk, and Compliance Actually Means AI GRC is the coordinated system of decision rights, risk processes, controls, and records that keeps AI inside business, legal, and ethical limits. Governance decides who may approve, pause, or retire an AI system. Risk then estimates what could go wrong and how badly. Compliance finally proves to an outside party that the first two actually happened.
The three words describe three jobs, rather than three departments. Kanerika’s executive guide to AI governance covers the frameworks and ROI case in depth, and the AI compliance guide works through the regulatory map in detail. This article stays on the part almost nobody writes about, namely how the three functions operate as a single machine.
Datasheet
Elevate Data Governance, Compliance, and Security
The one-page view of how Kanerika builds the classification, lineage, and policy layer that an AI control library has to sit on top of.
View the Datasheet → Why the Three Functions Have to Run as One Operating Model Policy alone stops working the moment a model reaches production, though the document keeps looking correct. A model approved in March can drift by June, a vendor can swap the foundation model underneath a SaaS feature without telling anyone, or a business unit can adopt a copilot that never passed intake. Each of those failures is therefore invisible to a policy document and visible only to an operating control.
Most enterprises already own the machinery, too. Risk registers, issue management, vendor assessments, internal audit, and control testing all exist, usually sitting on a data governance foundation that was built for reporting rather than for models. Reworking that foundation for AI usually starts with data classification , because a control library cannot enforce anything on data nobody has labeled.
Name an Owner for Every AI Decision What is missing is a named owner for each AI-specific decision, which is why ownership disputes surface during an audit rather than before one. The fix is a three-lines-of-defense mapping that names roles instead of departments.
Table 1: RACI and three-lines-of-defense mapping for an enterprise AI system.
Decision or activity Accountable Responsible Consulted Line of defense Approve an AI use case at intake Business owner Product lead Legal, privacy, security First Classify the system and its risk tier Chief risk officer AI risk analyst Business owner, legal Second Run pre-deployment evaluation Model owner ML engineering Validation team First Independently validate the model Head of model validation Validation analyst Model owner Second Accept residual risk above tolerance Executive risk committee Chief risk officer Legal, business owner Second Collect and retain control evidence Compliance officer Control owner Data governance lead Second Pause or retire a failing system Business owner Platform engineering Risk, compliance First Test whether controls actually work Chief audit executive Internal audit Risk, compliance Third
One rule, above all, keeps this honest. Nobody who builds a control may also be the person who signs that it works.
The Regulatory Clock Moved and Most Guidance Has Not Caught Up The Digital Omnibus on AI amended Article 113 of the EU AI Act and split the high-risk application date in two. Chapter III Sections 1, 2 and 3 now apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified under Article 6(1) and Annex I.
Three things did not move, though, and this is where most summaries go wrong. The Article 50 transparency duties still apply from 2 August 2026. Two new prohibited practices were added under Article 5 with effect from 2 December 2026. Article 4 on AI literacy was rewritten rather than deferred, and now requires providers and deployers to take measures supporting AI literacy without guaranteeing any individual’s level.
The practical read is that the paperwork-heavy conformity work bought roughly sixteen extra months, while the customer-facing disclosure work did not.
Where the Penalty Tiers Actually Sit Penalties are, similarly, the second place the market gets it wrong. The widely quoted 35 million euro or 7% ceiling comes from Article 99(3) and applies only to breaches of the Article 5 prohibitions. Provider and deployer obligations, notified-body duties, and Article 50 transparency breaches sit one tier lower.
Table 2: EU AI Act penalty tiers under Article 99 and what each one covers.
Article Ceiling What it covers Applies from Article 99(3) 35 million euro or 7% of worldwide annual turnover Breaching the Article 5 prohibited practices only 2 February 2025, plus two additions from 2 December 2026 Article 99(4) 15 million euro or 3% of worldwide annual turnover Provider, importer, distributor, deployer, and notified-body obligations, plus Article 50 transparency 2 August 2026 for transparency, 2 December 2027 or 2 August 2028 for high-risk duties Article 99(5) 7.5 million euro or 1% of worldwide annual turnover Supplying incorrect, incomplete, or misleading information to authorities 2 August 2025
Getting the tier right therefore changes the risk number a chief risk officer reports. A transparency gap on a customer chatbot is a 3% exposure, not a 7% one, and treating it as the latter distorts every prioritization decision downstream.
Kanerika Service
AI Governance Built Into the Platforms You Already Run
Kanerika designs the AI inventory, the control library, and the enforcement points, then wires them into Microsoft Purview, Databricks, and Snowflake rather than standing up a parallel stack.
Explore AI Governance Services Build One Control Library Instead of Three Compliance Programs Running NIST, ISO, and the EU AI Act as three projects is still the most expensive mistake in this space. The three do different jobs, but they overlap heavily in what they ask you to actually do.
How the Three Frameworks Differ Table 3: How the three reference frameworks differ in status, scope, and proof.
Dimension NIST AI RMF 1.0 ISO/IEC 42001:2023 EU AI Act Legal status Voluntary risk framework Certifiable management-system standard Binding regulation with extraterritorial reach Core structure Govern, Map, Measure, Manage Management-system clauses plus Annex A controls Risk tiers from prohibited to minimal Unit of scope The AI system and its lifecycle The organization’s AI management system The AI system plus your role as provider or deployer What proves it Self-attestation against outcomes Third-party certification audit Conformity assessment, registration, technical documentation Generative AI coverage Extended by the NIST AI 600-1 profile Technology-neutral, applies by design Separate general-purpose AI chapter Biggest gap on its own No legal defence, no certificate Certification does not discharge EU legal duties Says what to achieve, not how to build it
The NIST AI Risk Management Framework remains at version 1.0, released January 2023, extended by the generative AI profile published as NIST AI 600-1 in July 2024. Third-party blogs referring to an “AI RMF 2026” are describing implementation guides, not a NIST revision. ISO/IEC 42001:2023 was published in December 2023 as the first AI management system standard, and certification against it does not discharge any EU AI Act obligation.
Listen on Spotify
What Are the AI Trends and Predictions for 2026?
The payoff of treating them as one library is that a single well-specified control frequently satisfies all three at once.
Where One Control Satisfies All Three Table 4: One control, three frameworks. A unified control map for four common AI controls.
Your control statement NIST AI RMF ISO/IEC 42001 EU AI Act Evidence produced once Every AI system is registered with an owner, purpose, and risk tier before it reaches users Map function, context and categorization outcomes Planning and operational planning clauses Article 6 classification, Article 11 technical documentation Inventory record with owner and classification rationale Each system passes a documented evaluation against accuracy, bias, and safety thresholds before release Measure function, test and evaluation outcomes Performance evaluation clauses and Annex A impact controls Article 9 risk management, Article 15 accuracy and resilience Signed evaluation report with thresholds and results Users are told when they are interacting with AI or viewing AI-generated content Govern function, transparency and accountability outcomes Annex A controls on communication with interested parties Article 50 transparency, live from 2 August 2026 Screenshot library plus disclosure copy under version control Production behaviour is monitored, and material change triggers reassessment Manage function, monitoring and response outcomes Continual improvement and corrective action clauses Article 72 post-market monitoring, Article 73 incident reporting Monitoring logs, drift alerts, change tickets, incident records
Notice what the last column does. Every row generates evidence once and spends it three times, which is the entire economic argument for treating AI GRC as one discipline.
Four requirements genuinely do not overlap, so they need their own workstream. Those are EU conformity assessment, EU database registration, the ISO certification audit itself, and regulator incident notification.
Checklist
The Enterprise AI Checklist for Readiness, Governance, and Adoption
A working checklist for the inventory fields, control owners, and gates most AI programs discover they are missing halfway through an audit.
Get the Checklist → The Risks That Need a Joint Governance, Risk, and Compliance Response A risk taxonomy on its own is not especially useful here. Kanerika’s guide to AI in risk management works through the categories, while the data governance knowledge hub covers the underlying controls. What matters for an operating model is which risks fail when only one function owns them.
Model drift. Engineering sees the metric move, then risk decides whether it breached tolerance, and compliance records the reassessment. Any one of those alone still leaves a gap.Shadow AI. Security discovers it, governance decides whether to approve or block it, compliance backfills the inventory record and the disclosure.Embedded vendor AI. Procurement flags the contract change, risk re-scores inherited exposure, compliance checks whether your provider or deployer role just changed.Hallucinated output reaching a customer. Support detects it, legal assesses liability, compliance decides whether Article 73 reporting applies.Training data provenance. Data governance holds the lineage, legal holds the rights position, while compliance holds the record an auditor will ask for.Each one crosses at least two functions. A program that assigns them to a single owner therefore produces exactly the ownership disputes that surface in the middle of an incident.
On-Demand Webinar
Strategies to Reduce LLM Security Risks
A working session on where large language models create real financial exposure, and which controls actually reduce it before an incident forces the question.
Watch the Webinar → Governing Agentic AI, Where Model Governance Runs Out Classic model governance assumes a model produces an estimate and then a human acts on it. An agent, however, removes the human from the middle. It calls tools, chains actions, holds memory across sessions, and can take an irreversible step in a business system before anyone approves that specific step.
That breaks three assumptions at once. The unit of risk is no longer a prediction but an action. The blast radius is no longer a wrong number but a wrong transaction. And the identity taking the action is a service credential, rather than a named employee.
Seven Controls an Agent Needs Seven controls close the gap, though none of them are in a standard model risk framework.
Agent identity. Every agent gets its own credential and appears in the identity system as a first-class principal, rather than a shared human account.Least privilege. Access is scoped to the single task the agent was approved for, and re-scoped when the task changes.Tool allowlist. Only approved tools and APIs are reachable, with the list under change control rather than in a prompt.Action limits. Hard caps on transaction value, volume per hour, and the systems an agent may write to.Human approval checkpoints. Any irreversible or externally visible action stops for a named approver.Immutable action log. Every input, tool call, and output recorded in a store the agent cannot write to.Tested kill switch. One command halts the agent, and the drill is run on a schedule rather than assumed to work.Kanerika’s Susan agent for PII redaction and Mike for quantitative proofreading are built against exactly this overlay, because an agent that touches sensitive data has to prove its own boundaries. Those boundaries come from the same data access governance controls already sitting under the platform, rather than from a separate AI-only permission layer.
What Banks Lose When Model Risk Management Stops at Statistical Models US banks have leaned on model risk management as the shortcut to AI governance for years, and until recently that worked. That shortcut narrowed in 2026.
SR 26-2, Revised Guidance on Model Risk Management , was issued on 17 April 2026 and replaced both SR 11-7 from 2011 and the SR 21-8 statement on Bank Secrecy Act model risk. The Federal Reserve describes it as most relevant to banking organizations above 30 billion dollars in total assets, and it moves toward a risk-based approach tailored to each organization’s model risk profile. The OCC issued the parallel guidance as Bulletin 2026-13 .
The detail that matters for AI GRC, meanwhile, sits in a footnote. The revised guidance states that generative AI and agentic AI models are novel and rapidly evolving, and as such are not within the scope of the guidance. It applies to traditional statistical and quantitative models and to non-generative, non-agentic AI models.
A bank that maps every AI system into its model risk inventory and stops there has now built a program that its own regulator says does not cover the fastest-growing part of the estate. The guidance is explicit that the organization’s own risk management practices should determine controls for anything outside its scope, which is precisely the AI GRC layer this article describes.
Enterprises in banking and insurance should read that as a mandate to run model risk management and AI governance as two connected registers, rather than one.
The AI Incident Runbook Almost Nobody Publishes Search for AI incident response and you will find plenty on security incidents, but almost nothing on model incidents. The failure modes are different, too. A model does not get breached, it gets confidently wrong, so the response has to be designed for that.
Six stages, in short, cover the ground. Detect through monitoring alerts, guardrail trips, and user reports. Triage by classifying severity and affected systems. Contain by throttling traffic, reverting the prompt or configuration, and rolling back to the last approved model version.
Notify legal, the regulator where required, and affected users. Remediate the root cause, retest against the original thresholds, and then re-approve through the same gate the system passed the first time. Then update the controls, the risk register, and the training that let it through.
The notification stage, however, is the one with a legal clock attached. Article 73 of the EU AI Act requires serious incidents to be reported no later than 15 days after the provider becomes aware. That falls to 10 days where a person has died, and to 2 days for a widespread infringement or serious and irreversible disruption of critical infrastructure.
Fifteen days sounds generous until you count backwards. Detection, triage, and a legal assessment of whether the event qualifies, meanwhile, routinely consume a week on their own.
What the Board and Audit Committee Should See Every Quarter Board reporting on AI tends to arrive as a demo or a slide of adoption statistics. Neither, though, tells a director whether the organization is exposed. A standing quarterly pack should therefore answer six questions and fit on two pages.
Coverage. How many AI systems exist, how many are inventoried and classified, and what the gap is.Concentration. Which systems carry the largest residual risk, and who accepted it.Control health. Test pass rate, controls with stale evidence, and open exceptions with expiry dates.Incidents. Count, severity, mean time to contain, and anything that triggered a regulatory notification.Regulatory readiness. Position against each applicable obligation and the dates that bind, including the 2027 and 2028 EU milestones.Decisions required. The specific approvals, funding, or risk acceptances the board is being asked for this quarter.Anything that cannot be traced to one of those six belongs in the operating review, rather than the board pack.
Five Levels of AI GRC Maturity Maturity models fail when levels describe ambition rather than evidence. This one is instead graded on what an auditor could verify on a Tuesday afternoon.
Level 1, ad hoc. AI is in production somewhere, but no central inventory exists, and no single person can name every system.Level 2, documented. A policy is written, an inventory has been started, and business owners are named, though only for the systems anyone knows about.Level 3, controlled. Controls are mapped to frameworks, every control has an owner, and lifecycle gates block a release until it has passed them.Level 4, measured. Controls are tested continuously rather than annually, and most evidence is generated by the platform instead of assembled before an audit.Level 5, assured. Internal audit provides independent assurance, the board sees a standing report, and coverage finally extends across every cloud and data platform in the estate.Most enterprises with real AI in production sit between Level 2 and Level 3. The jump from 3 to 4 is where cost drops, because manual evidence collection is the single largest recurring expense in a compliance program.
Choosing Tooling Without Starting a Second Program Tooling follows the operating model, rather than the other way round. The test, then, is whether a platform can hold your control library, your evidence, and your workflows without forcing a second inventory to exist alongside your enterprise GRC system.
Kanerika’s comparison of 14 AI governance tools covers the categories, pricing, and selection criteria in detail. The short version is that most enterprises need a governance layer connected to what they already run, rather than a parallel stack.
How Kanerika Builds AI GRC in Production Kanerika is a Microsoft Solutions Partner for Data and AI, a Snowflake Select Tier Partner, and a Databricks Consulting Partner, and holds ISO 27001, ISO 27701, and ISO 9001:2015 certification. It is also one of the earliest Microsoft Purview implementors globally, which matters here because AI governance without trustworthy data governance is a policy exercise.
Delivery runs in four stages. The assessment stage builds the AI inventory and maps current controls against NIST AI RMF, ISO/IEC 42001, and applicable EU duties, usually alongside a data strategy or AI strategy engagement. The design stage then produces the unified control library, the RACI, the risk-acceptance rules, and the lifecycle gates.
The build stage subsequently wires enforcement into the platforms where the data actually lives, using Microsoft Purview for classification, lineage, and policy, alongside data governance and AI governance engagements. The operate stage finally moves control testing from annual sampling to continuous checks that generate their own evidence.
What the Published Results Show The pattern is also visible in Kanerika’s published work. A North American healthcare organization with data spread across Azure Blob Storage, SQL databases, and SaaS applications reached 90% compliance adherence, a 57% reduction in data discovery time, and a 70% improvement in data accessibility after a Purview implementation. A separate bank engagement improved data classification accuracy by 72% with zero data breaches and full adherence to compliance regulations.
An AI regulatory management platform Kanerika built cut manual compliance effort by 60% , improved regulatory response time by 40%, and delivered five times better audit traceability. A further engagement put real-time compliance and risk detection behind an AI agent . These are data-control and compliance-automation outcomes, rather than certification outcomes.
Case Study
90% Compliance Adherence with a Microsoft Purview Implementation
A North American healthcare organization with data spread across Azure Blob Storage, SQL databases, and SaaS applications reached 90% compliance adherence, cut data discovery time by 57%, and improved data accessibility by 70%.
Read the Case Study → Teams in healthcare , banking , insurance , and pharma usually start with the two or three systems that carry real regulatory weight, then extend the same control library across the estate. Kanerika’s ethical AI implementation roadmap and the enterprise AI checklist are the two artifacts most teams use when scoping that first pass.
Wrapping Up The organizations that handle AI GRC well are generally not the ones with the thickest policy. They are the ones where a director can ask which AI systems are material, who owns them, what the top residual risk is, and what evidence supports the answer, and get a reply within a single reporting cycle.
Three moves, ultimately, get you there. Merge the three functions onto one inventory and one control library, add the agentic overlay before agents reach production, and write the incident runbook before you need it.
Talk to Kanerika
Map Your AI Estate Against the 2027 and 2028 Deadlines
A short working session with Kanerika turns a list of AI systems into a classified inventory, a mapped control library, and a dated plan against the obligations that actually bind you.
Book a Working Session → Frequently Asked Questions
What is AI governance, risk, and compliance? AI governance, risk, and compliance is the coordinated system of decision rights, risk processes, controls, and records that keeps AI inside business, legal, and ethical limits. Governance decides who may approve, pause, or retire a system. Risk estimates what could go wrong. Compliance proves to an outside party that both actually happened.
What is the difference between AI governance and AI risk management? AI governance sets the decision rights, policy, and ownership for AI systems. AI risk management identifies specific harms, estimates likelihood and impact, and tracks treatment to a residual position. Governance decides who may accept a risk, while risk management quantifies what is being accepted. Programs fail when one function is asked to do both jobs.
When do EU AI Act high-risk obligations actually apply? Regulation (EU) 2026/1744, the Digital Omnibus on AI, amended Article 113. Chapter III Sections 1, 2 and 3 now apply from 2 December 2027 for Annex III high-risk systems and from 2 August 2028 for Annex I systems. Article 50 transparency duties were not deferred and still apply from 2 August 2026.
Does ISO/IEC 42001 certification prove EU AI Act compliance? No. ISO/IEC 42001:2023 certifies that an AI management system meets the standard’s requirements, assessed by an accredited certification body. The EU AI Act imposes separate legal duties including classification, conformity assessment, registration, and incident reporting. Certification is strong evidence of governance discipline, but it does not discharge a single Article obligation.
What is the maximum fine under the EU AI Act? Article 99(3) sets the ceiling at 35 million euro or 7% of total worldwide annual turnover, and it applies only to breaches of the Article 5 prohibited practices. Provider, deployer, and Article 50 transparency breaches fall under Article 99(4) at 15 million euro or 3%. Misleading information to authorities sits at 7.5 million euro or 1%.
Who owns AI risk in an organization? The business owner of each AI system is accountable for its outcomes, while risk and compliance provide independent challenge and internal audit provides assurance. Residual risk above tolerance is accepted by an executive risk committee, never by the team that built the system. Ownership should be named per system in the inventory, not assigned to a committee.
How should companies govern AI agents that take actions in business systems? Agents need a control overlay that model governance does not provide. Give each agent its own identity rather than a shared login, scope access to a single approved task, restrict it to an allowlist of tools, cap transaction value and volume, require human approval before irreversible actions, log everything immutably, and test the kill switch on a schedule.
Can an existing enterprise GRC platform manage AI risk? Most of it, yes. Risk registers, issue management, vendor assessments, control testing, and audit workflows all carry over. What must be added are AI-specific records, including model and prompt versions, evaluation results, drift monitoring, agent action logs, and framework mappings. The test is whether the platform can hold those without forcing a second inventory to exist.
