Where Is the Horse? The Rapid Transformation of GRC Technology in the Age of Agentic AI
In my recent GRC 20/20 Strategy Perspective, Agentic AI in GRC: Pulling Back the Curtain, I explored why much of the current market conversation around agentic AI in GRC is more theater than substance, what real agency requires, and how the next generation of GRC earns Business Confidence through connected context, governed action, and proof.
That report was intentionally direct. The GRC market is filled with bold claims about AI, agents, copilots, autonomous compliance, intelligent risk management, automated assurance, and instant transformation. A few of these claims are real. Most are exaggerated. Many are little more than an eloquent chatbot attached to an aging workflow engine and presented as if the future has arrived.
But the report was not written as an argument against AI. Quite the opposite. AI will and is reshaping GRC. Agentic AI will transform aspects of governance, risk management, compliance, audit, resilience, third-party governance, policy management, and assurance. The warning is not that AI lacks value. The warning is that buyers must distinguish between useful assistance, scripted automation, polished demos, and true governed agency.
The future is coming. In fact, it is already here. But the market needs to be honest about what is changing . . .
A powerful way to understand the moment we are in is to look back at Fifth Avenue in New York City at the beginning of the twentieth century. There is a famous pair of images often used to illustrate technological transformation. In the first, Fifth Avenue in 1900 is filled with horses, carriages, and wagons. The question posed is: Where is the car?
Then comes the second image, Fifth Avenue in 1913. Just thirteen years later, the street is filled with automobiles. The horse has nearly disappeared. The question now is: Where is the horse?
The point is not simply that cars replaced horses. The point is that an entire operating model changed.
In 1900, New York City was built around the horse. The visible street traffic was only the surface layer. Beneath it was a vast infrastructure of stables, feed supply, manure removal, blacksmiths, wheelwrights, harness makers, veterinary services, carriage builders, watering stations, street cleaning, and labor organized around the needs of animal-powered transportation. The city’s transportation architecture was not only what people saw on the street. It was everything required to make that street function.
By 1913, the automobile had not merely added another transportation option. It rearchitected the infrastructure of movement. Streets, fuel, repair shops, manufacturing, traffic rules, parking, supply chains, insurance, financing, licensing, and urban planning all had to adapt. The change was not only in the vehicle. It was in the ecosystem.
That is what is happening in GRC technology right now . . .
The GRC technology market is not in another ordinary product refresh cycle. This is not another generation of dashboards, forms, workflow routing, heat maps, and prettier reports. This is a transformation in the underlying architecture and infrastructure of GRC. The system of roads is changing. The means of motion is changing. The skills required to build, sell, implement, govern, and use GRC technology are changing.
And unlike the transformation from horse to automobile on Fifth Avenue, this shift in GRC architecture will not take thirteen years . . . it will unfold over the next few years.
The GRC Market Has Been Built Around the Horse
For the past two decades, most GRC technology has been built around the system-of-record model. This was necessary. Organizations needed a structured place to document risks, controls, policies, obligations, issues, incidents, vendors, assessments, audits, evidence, and remediation activity. Before GRC platforms, much of this work lived in spreadsheets, email, shared drives, disconnected databases, and heroic manual effort.
The system of record brought order. It helped organizations centralize information, enforce accountability, route tasks, collect attestations, track approvals, document evidence, and report status to management, executives, regulators, and the board. These capabilities mattered then, and they still matter now.
But much of the GRC technology market became comfortable competing on the artifacts of this model, which boiled down to features to support:
- Do you have risk assessments?
- Do you have control testing?
- Do you have issue management?
- Do you have policy attestations?
- Do you have third-party questionnaires?
- Do you have regulatory change workflows?
- Do you have incident management?
- Do you have audit planning?
- Do you have dashboards?
- Do you have reporting?
- Do you have Monte Carlo analysis/risk quantification?
For years, the market rewarded feature expansion. Vendors added modules. Buyers created long RFP checklists. Analysts, consultants, and procurement teams compared capabilities line by line. GRC technology providers competed on whether they had the required functions, how configurable the platform was, how much workflow could be automated, and how quickly reports could be generated.
That model is running out of road.
- Not because systems of record are useless . . . they are not.
- Not because workflow no longer matters . . . it does.
- Not because evidence, controls, reporting, and documentation are going away . . . they are not.
The issue is that these capabilities are no longer enough to define the future of GRC technology. They are increasingly the old infrastructure of the horse-drawn city. Necessary in many environments, but no longer sufficient for where the market is going.
AI Is Collapsing the GRC Feature Advantage
AI is changing the economics of software development. Capabilities that once required months or years of engineering can now be prototyped, tested, refined, and delivered in a fraction of the time. I recently heard a respected head of product say that what once required fifty developers can now be done with five developers and AI. Another firm demonstrated the rapid construction of Monte Carlo capabilities in hours with AI, which took a competitor nearly a year to build without AI.
I am not presenting either example as a universal formula. Every development environment, product architecture, data model, and engineering culture is different. But these examples are signals. AI is collapsing development cycles. It is reducing the barriers to building functionality. It is making feature replication easier.
That matters profoundly for GRC . . .
A traditional relational database GRC feature set built around fields, forms, records, tables, relationships, workflows, and reports can be copied faster than ever before. A risk register can be created. A control testing workflow can be configured. A third-party questionnaire can be built. A policy attestation process can be automated. A dashboard can be generated. A Monte Carlo feature can be added.
This does not mean GRC technology is becoming less important. It means technology differentiation is moving . . .
The future of GRC technology differentiation is not simply whether a platform has a feature. The question is whether the platform has the architecture, intelligence, context, governance, methodology, content, user experience, and orchestration to improve the organization’s GRC program and deliver measurable value.
Buyers should not be impressed by a checklist of features that everyone else can increasingly claim. They should ask deeper questions.
- Does the provider understand our business objectives?
- Does the provider understand our industry and regulatory environment?
- Does the provider understand our operating model?
- Does the provider understand how risk, compliance, controls, resilience, audit, policy, third-party governance, and performance interrelate?
- Does the provider bring experience, content, frameworks, expertise, and leading practices that improve our program?
- Does the provider help us move from fragmented, manual, and document-centric activity to business-integrated GRC?
- Does the provider understand the role of digital twins, semantic ontologies, contextual intelligence, and agentic AI in the future of GRC?
- Does the provider help us reliably achieve objectives, address uncertainty, and act with integrity?
This is where the market is headed. Features are becoming the price of admission. Program improvement is the sale. This was apparent in one RFP I worked on for a global aerospace firm. The final two . . . both of them could meet all the feature requirements. They chose the solution that challenged them and told them we could do it your way, but have you thought of doing it this way and why? That one the sale.
The GRC Buyer Does Not Need Another Better Horse
When the automobile first emerged, many people probably evaluated it through the frame of the horse.
- Is it faster than a horse?
- Is it more reliable than a horse? C
- an it pull the same carriage?
- Can it travel the same roads?
- Can it be managed with the same assumptions?
That is natural. New technology is often first understood through the lens of what it replaces . . .
The same is happening in GRC. Buyers are often evaluating AI-enabled GRC through the lens of traditional GRC technology.
- Does the AI summarize the risk register?
- Does it draft the control narrative?
- Does it write the policy?
- Does it classify obligations?
- Does it generate an issue description?
- Does it produce an executive summary?
These capabilities can be useful. They can save time. They can reduce administrative burden. They can make information more accessible. They can help GRC teams translate technical detail into business language.
But they are not the real transformation . . .
The real transformation is not that the old GRC system speaks more fluently. The real transformation is that the architecture of GRC begins to change from a system that records work to a system that observes, contextualizes, reasons, decides, acts, and learns within defined governance boundaries.
That is the difference between AI assistance and agentic GRC . . .
A chatbot that summarizes a policy is useful. A document assistant that reviews a supplier assurance report is useful. A model that drafts a remediation plan is useful. But useful does not equal agentic. Fluency is not agency. Summarization is not orchestration. Search is not intelligence. Workflow with a better voice is not transformation.
True agentic GRC requires a system that can operate toward an objective, understand context, maintain state over time, use tools with purpose, act within defined boundaries, preserve accountability, escalate when needed, and explain what it did. In a regulated enterprise, it must know when to act, when to recommend, when to stop, and when a human must decide.
That is a much higher standard than “our assistant can summarize a control test.”
From GRC System of Record to System of GRC Orchestration
The old model of GRC technology was primarily a system of record built on a relational database. It captured risks, controls, policies, obligations, issues, incidents, third parties, assessments, audits, and evidence. This will remain important. Organizations need structured accountability. They need records. They need evidence. They need repeatable processes. They need defensible documentation.
But the next generation of GRC technology is a system of orchestration . . .
GRC 7.0 – GRC Orchestrate is about connecting the organization’s objectives, processes, risks, controls, obligations, policies, third parties, assets, services, resilience dependencies, intelligence, actions, decisions, and assurance into a coordinated architecture. It is not simply about documenting what happened. It is about understanding what is happening, what could happen, what matters, who needs to act, what options exist, what evidence supports the decision, and how actions connect to objectives and outcomes.
This requires three connected layers . . .
- First, the system of record provides the structured foundation. It contains the entities, relationships, workflows, documentation, evidence, and accountability required to manage GRC activity. This is where much of the market has been. It is still relevant, but it is not sufficient.
- Second, the system of intelligence brings internal and external context into the GRC environment. This includes regulatory intelligence, risk intelligence, third-party intelligence, control intelligence, business intelligence, operational telemetry, horizon scanning, scenario analysis, and analytics. This is where GRC becomes more aware of change, dependency, and context.
- Third, the system of action brings automation. Where agentic AI enables and brings together decision support, workflow orchestration, continuous monitoring, task execution, escalation, and governed response together. This is where GRC moves beyond documentation into coordinated action.
The future is not one of these layers by itself. The future is their integration . . .
A system of record without intelligence becomes administrative. A system of intelligence without action becomes advisory noise. A system of action without governance becomes dangerous. The next generation of GRC requires all three: record, intelligence, and action connected through architecture, accountability, and proof.
The Market Infrastructure Is Changing
The Fifth Avenue analogy matters because it reminds us that transformation is not limited to the visible object. It is not just the car replacing the horse. It is the entire infrastructure changing around it.
The same is true in GRC technology . . .
The visible change is AI. The deeper change is the transformation of the GRC architecture and operating infrastructure. Buyers should look beyond the visible assistant, the glowing dashboard, the polished demo, and the confident narrative. They should ask what infrastructure supports it.
- What is the underlying data model?
- Is the platform still primarily a set of tables and forms, or does it understand relationships and dependencies?
- Can it connect objectives to risks, risks to controls, controls to obligations, obligations to policies, policies to evidence, evidence to assurance, and assurance to decisions?
- Does it have a semantic layer or ontology that gives meaning to GRC information?
- Can it observe behavior through telemetry and evidence streams, or does it rely only on manual attestations and self-reported records?
- Can it maintain state over time?
- Can it take governed action?
- Can it explain what it did?
- Can it be audited?
- Can it learn without losing control?
These are infrastructure questions. They are the GRC equivalent of asking whether the city has roads, fuel stations, repair shops, traffic rules, and manufacturing capacity. The car is not enough. The ecosystem matters.
This is where many legacy GRC architectures are under pressure . . .
They were designed for a world of centralized records, configurable forms, defined workflows, scheduled assessments, periodic reporting, and human-driven updates. That world is not disappearing overnight. But it is being overtaken by the need for connected context, real-time intelligence, behavioral evidence, digital twins, continuous monitoring, and governed action.
Legacy providers that simply bolt AI onto old architectures will struggle . . .
A chatbot on top of a fragmented system does not make the system agentic. A summarization feature inside an aging workflow engine does not create orchestration. A policy drafting assistant does not solve the deeper challenge of connecting obligations, controls, behavior, evidence, decisions, and outcomes.
The providers that succeed will be those that are fair to the past but honest about the future. Systems of record still matter. Workflow still matters. Evidence still matters. Reporting still matters. But the future requires something more.
Context Is the New Competitive Battlefield
In the old market, the database mattered. In the new market, context matters more.
A relational database is not the enemy . . .
Tables are useful. Records are necessary. Structured data remains essential. But GRC is increasingly a relationship and dependency problem, not simply a table problem . . .
- A table can tell you that a supplier is critical . . . a dependency model can show what happens when that supplier fails.
- A table can tell you that a control is ineffective . . . a connected context model can show which obligation, policy, business process, service, customer commitment, risk appetite statement, executive objective, and assurance conclusion are affected.
- A table can tell you that a regulation changed . . . a semantic GRC architecture can show which obligations changed, which policies need revision, which controls need retesting, which business units are impacted, which third parties are implicated, and which executives need to know.
This is where graph-oriented context, semantic models, ontologies, and digital twins become so important. GRC is not a filing cabinet. It is an operating map of the enterprise. It connects objectives, processes, systems, data, obligations, policies, controls, tests, findings, remediation, resources, decisions, and outcomes.
Without that contextual fabric, AI hovers above fragments. It retrieves text. It summarizes records. It generates plausible answers. It may sound intelligent, but it does not truly understand the operating environment in which GRC decisions are made.
Generic AI gives generic answers. GRC AI needs tenant-specific context. It needs the organization’s policies, controls, objectives, risk appetite, obligations, terminology, evidence, business processes, third parties, systems, services, decision rights, and governance boundaries. It needs scoped context, not a massive indiscriminate dump of documents. It needs to understand the difference between a risk statement, a control procedure, a policy requirement, an audit finding, an issue, an obligation, and a business objective.
Context architecture is the differentiator!
Truth Comes Before Intelligence
There is another issue buyers must not overlook: where does the truth come from?
It is one thing for AI to reason across policies, risk registers, control libraries, questionnaires, audit reports, and attestations. It is another thing to know whether those artifacts reflect reality. Controls do not fail on paper. They fail in behavior. A policy can say one thing while the business does another. A control owner can attest that a control is operating while system telemetry tells a different story. A third party can complete a questionnaire while evidence reveals gaps. A process can look mature in the workflow and fragile in actual execution.
This is one of the most important shifts in the next generation of GRC technology. GRC cannot become truly intelligent by reasoning only over documents and self-reported data.
GRC needs observation . . .
The future of GRC requires a behavioral observation layer. This may include continuous control monitoring, automated evidence collection, identity and access signals, transaction monitoring, system configuration checks, vulnerability data, incident feeds, third-party evidence, process mining, regulatory intelligence, and other forms of machine-verifiable signal. The point is not to collect every possible data point. The point is to connect the right signals to the right objectives, obligations, risks, controls, and decisions.
A thermostat cannot regulate the temperature of a room by reading the building policy on climate comfort. It needs a sensor.
Likewise, GRC cannot become truly intelligent by reading the policy library and risk register alone. It needs signals from the operating environment. It needs evidence that is relevant, contextualized, validated, and tied to objectives.
This does not mean telemetry is truth by magic. Data can be incomplete, biased, stale, noisy, misclassified, or disconnected from business context. Continuous monitoring can create false confidence if it monitors what is easy rather than what is material. But the answer is not less observation. The answer is better observation connected to better context.
In GRC, trust systems start with signals . . .
- The buyer question should NOT be “what can the AI generate?”
- The better question is “what can the system reliably observe, decide, enforce, and prove over time?”
The GRC Professional Services Boundary Is Also Changing
This market transformation is not limited to software vendors. Professional services firms are also being reshaped by AI.
Historically, the GRC ecosystem often separated technology and advisory. Software providers brought the platform. Professional services firms brought methodology, advisory expertise, implementation support, program design, transformation guidance, and client relationships. At times professional service firms built a platform to only divest of it to focus on services. That partnership model still matters, but it is becoming more complicated.
AI makes it easier for professional services firms to productize their intellectual property. They can build applications, workflow layers, assessment tools, analytics, reporting environments, AI agents, and implementation accelerators around their methodologies faster than before. They can wrap technology around their content. They can deliver technology-enabled services. They can blur the line between advisory, managed services, and software.
This means GRC advisor partners may become GRC vendor/solution provider competitors . . .
Boutique firms with deep domain expertise may build focused GRC solutions around specific use cases. Large global firms may develop technology-enabled service platforms that compete with software providers in targeted areas. Advisory firms may use AI to turn frameworks, maturity models, regulatory content, control libraries, and delivery playbooks into repeatable technology assets.
For GRC technology providers, this creates risk and opportunity. The risk is that implementation partners can become competitors. The opportunity is that technology providers can build stronger, more strategic partnerships with firms that bring domain expertise, industry insight, transformation capability, and market trust.
But those partnerships must evolve. They cannot be based only on referral agreements and implementation capacity. They need aligned market strategy, differentiated value, shared understanding of buyer outcomes, and mutual recognition that the market is changing.
For buyers, this shift means more choice, but also more confusion. Some “software” will increasingly look like advisory packaged in technology. Some “services” will increasingly look like software-enabled operating models. The buyer will need to ask: who owns the architecture, who owns the methodology, who owns the content, who owns the data, who governs the AI, and who is accountable when the system acts?
Legacy GRC Providers and New GRC Entrants Both Face Risk
It is tempting to assume that legacy GRC providers are at risk and new entrants are advantaged. The truth is more balanced.
Legacy providers do face significant pressure . . .
Many have deep functionality, large customer bases, broad market presence, and years of implementation experience. But some are built around older assumptions: centralized systems of record, complex configuration, heavy implementation, feature checklists, and incremental product evolution. These assumptions are being challenged by AI-native development, digital twins, semantic architectures, agentic AI, behavioral observation, and the buyer demand for faster time to value.
Legacy providers that only repaint the old house will struggle. Those that simply add AI features to aging architectures may create short-term excitement but long-term disappointment. The market will increasingly distinguish between AI-enabled workflow and real GRC orchestration.
At the same time, new entrants are not guaranteed success . . .
Innovation alone is not enough. A clever product is not enough. A better interface is not enough. A dazzling demo is not enough.
The GRC market is not a generic enterprise software market. It is shaped by regulation, accountability, governance, assurance, risk, trust, professional judgment, organizational politics, and executive concern. Buyers do not simply buy features . . . they buy business confidence.
New entrants need market strategy. They need positioning. They need use-case clarity. They need credibility. They need proof. They need partner strategy. They need to understand the complexity of GRC buying. They need to know where to compete, where to focus, and where to partner.
The market will reward both established providers and new entrants that can show substance. It will punish both established providers and new entrants that rely on theater.
What GRC Buyers Should Be Asking
The buyer’s job is not to be dazzled by the face on the screen. It is to ask what is behind the curtain.
When a provider claims to have agentic AI, buyers should ask what that means in practical terms . . .
- What can the system actually do?
- What actions can it take?
- What decisions can it support?
- What evidence does it use?
- What tools can it invoke?
- What permissions govern it?
- What happens when evidence conflicts?
- What happens when the AI is wrong?
- What gets logged?
- What can be audited?
- What can be rolled back?
- What is in production, and what is still roadmap?
Buyers should ask to see the work . . .
- Do not show me a summarized policy and call it governance.
- Do not show me a chatbot answering questions and call it agency.
- Do not show me a dashboard and call it intelligence.
- Do not show me a workflow with prettier language and call it orchestration.
- Do not show me a protocol diagram and call it proof.
- Show me how the system observes signals.
- Show me how it connects those signals to objectives.
- Show me how it understands dependencies.
- Show me how it distinguishes weak evidence from strong evidence.
- Show me how it selects tools.
- Show me how it maintains state.
- Show me how it compares options.
- Show me how it escalates.
- Show me how it asks for human approval.
- Show me how it logs actions.
- Show me how it learns from outcomes.
- Show me how it helps the organization make a better decision than it would have made otherwise.
That is the GRC buyer’s refrain: show me the work.
The Balanced View: Warning and Opportunity
The warning is real. AI can create false confidence. It can make weak architectures look modern. It can make shallow workflows sound intelligent. It can make old processes run faster without making them better. It can produce polished language that disguises poor evidence, weak context, and disconnected accountability.
A weak GRC process with AI can feel more mature than it is. The reports improve. The summaries improve. The interface improves. The language improves. But the organization may still lack connected context, behavioral evidence, defensible decisions, and accountable action.
That is the danger . . . But the opportunity is equally real . . .
When done properly, AI can reduce administrative burden. It can accelerate evidence review. It can identify patterns. It can improve consistency. It can brief leaders. It can support investigations. It can help compliance teams connect obligations to operational behavior. It can help risk teams spend less time chasing artifacts and more time advising the business. It can help audit teams understand evidence trails and control history. It can help executives understand what matters now. It can help boards gain confidence because conclusions are tied to signals, relationships, evidence, actions, and accountability.
The future is not simply headcount reduction. That is too narrow and too shallow. The future is expertise reallocation. Scarce GRC expertise should move away from repetitive administration, evidence chasing, document reconciliation, and manual coordination toward scenario analysis, advisory work, control improvement, resilience planning, assurance quality, and better decision support.
The goal is not to purchase AI. The goal is to improve how the organization is governed. AI is a means. Orchestration is a mechanism. Business Confidence is the outcome.
The Fifth Avenue Moment for GRC
The GRC market is standing on Fifth Avenue . . .
In one direction, you can still see the old infrastructure: systems of record, workflows, forms, dashboards, heat maps, attestations, questionnaires, manual evidence requests, and periodic reporting. These will not disappear immediately. They still have value. They still support important accountability. They are still embedded in organizations.
But look closely at the street . . .The automobile is already here . . .
Agentic AI, digital twins, semantic ontologies, knowledge graphs, continuous controls monitoring, behavioral observation, contextual intelligence, governed automation, and systems of action are beginning to rewrite the movement of GRC. The change is not simply in the visible tool. The infrastructure around the tool is changing.
The question for buyers is not whether they should abandon everything they have . . the question is whether their GRC architecture can evolve . . .
- Can it move from static records to connected context?
- Can it move from self-reported artifacts to observed evidence?
- Can it move from workflow automation to governed action?
- Can it move from dashboards to decision support?
- Can it move from administrative GRC to business-integrated GRC?
The question for providers is equally direct. Are you building the future, or are you putting a more eloquent face on the past?
The 1900 street did not know how quickly it would change. The infrastructure of the horse looked permanent because it was everywhere. But permanence is often an illusion created by familiarity.
GRC technology is now in that kind of moment.
The market will adapt. Buyers will adapt. Providers will adapt. Professional services firms will adapt. But the architecture and infrastructure of GRC are undergoing a significant transformation. It will not take thirteen years between pictures. It will happen in just a few years.
Some will still be asking, “Where is the car?” . . .Others will soon be asking, “Where is the horse?”
The organizations that succeed will not chase AI theater. They will build and buy GRC technology that provides connected context, grounded intelligence, governed action, evidence, accountability, and proof. They will demand architecture, not adjectives. They will insist that AI supports the purpose of GRC: to reliably achieve objectives, address uncertainty, and act with integrity.
That is the future explored in Agentic AI in GRC: Pulling Back the Curtain. The curtain is being pulled back. The market is changing. Buyers should be ambitious, but also demanding. The future of GRC should not be built around illusion. It should be built around proof.