After Toto Pulls Back the Curtain: GRC AI Must Become a Decision System
The next phase of AI in GRC is not a better wizard. It is better machinery.
Last week, I wrote about the Wizard of Oz problem in the current agentic AI conversation in governance, risk management, and compliance in Pay No Attention to the GRC AI Behind the Curtain. The market is full of booming voices, green lights, theatrical demos, confident claims, and promises of autonomous assurance, intelligent orchestration, and instant transformation. The message was simple: do not be dazzled by the AI spectacle. Pull back the curtain.
When you do, too often you find a familiar machine. A workflow engine. A chatbot. A retrieval layer. A few prompts. Some scripted API calls. A dashboard with better language. A forms-and-workflow platform dressed up in the language of agency.
That is not agentic AI. That is theater.
But pulling back the curtain is only the beginning. The more important question is what should be behind the curtain if the market is serious about the next generation of GRC technology and architecture.
The answer is not a louder wizard. It is not a more fluent chatbot. It is not a more polished demo. It is not a generative AI assistant that can summarize a policy, draft a control narrative, or explain a regulatory change in executive language. Those capabilities can be useful, and in many cases they deliver real productivity gains. But they do not, by themselves, transform GRC.
The next generation of GRC requires something more substantial. It requires connected context. It requires a dependency-aware architecture. It requires systems that can observe, model, compare, decide, act, and prove. It requires deterministic, explainable, reproducible decision support where the organization must make choices under real constraints.
In other words, AI for GRC must become part of a decision system.
GRC Is a Dependency Problem, Not a Table Problem
For decades, GRC technology has largely been organized around records and workflows. A risk is entered into a register. A control is documented. A policy is published. An issue is created. A third party is assessed. An obligation is mapped. A task is assigned. A report is generated.
This architecture brought order to chaos. It helped organizations move beyond spreadsheets, email, shared drives, and heroic manual effort. It created accountability, repeatability, documentation, evidence, approvals, and reporting. Those things still matter.
But the core problem of GRC was never simply the lack of tables. It was never simply the absence of records. Nor that the organization needed a better place to store risks, controls, policies, issues, and assessments.
The real problem is relationships.
GRC is a dependency problem. Objectives depend on processes. Processes depend on systems. Systems depend on data. Data depends on controls. Controls depend on people, procedures, configurations, access rights, and evidence. Business services depend on third parties. Third parties depend on subcontractors, geographies, infrastructure, financial viability, cybersecurity posture, and operational resilience. Regulations create obligations. Obligations shape policies. Policies require controls. Controls influence behavior. Failures cascade.
- A table can tell me that a supplier is critical . . . A dependency model can show me what happens when that supplier fails.
- A table can tell me that a control is ineffective . . . A dependency model can show me which business service, regulatory obligation, customer commitment, operational process, and executive objective are exposed.
- A table can tell me that a system is down . . . A dependency model can show me what decisions must be made, which recovery options are constrained, which third parties are involved, which controls are bypassed, which obligations are triggered, and which business outcomes are at risk.
That is the architectural shift. GRC is not a filing cabinet. It is an operating map of the enterprise.
This is why the next generation of GRC technology cannot be built around disconnected modules with AI decoration. The market does not need another risk module with a chatbot. It does not need another compliance module with a summarization button. Nor does it need another third-party risk workflow that can generate a nicer email.
The market needs an enterprise service-and-dependency model that maps relationships across objectives, processes, systems, services, data, controls, obligations, third parties, incidents, issues, and decisions. It needs to make cascades visible before everyone is guessing. It needs to move GRC from static administration to dynamic understanding.
This is where AI becomes meaningful. Not because it can produce fluent answers, but because it can help the organization understand relationships, identify weak signals, model consequences, and support decisions in context.
Fluency Is Not Agency
One of the greatest mistakes in the current AI cycle is the belief that a system that speaks well must therefore understand well.
Large language models are remarkable. They can summarize, classify, translate, draft, explain, and synthesize. They can take a dense regulation and produce an executive summary. They can review a policy and suggest improvements. They can summarize an audit finding. They can help a control owner understand evidence requirements. They can make GRC knowledge more accessible across the enterprise.
That is valuable. It is not agency.
A fluent answer is not the same as a defensible decision. A well-written recommendation is not the same as a validated course of action. A confident paragraph is not the same as a model that has compared constraints, dependencies, evidence quality, recovery options, business priorities, regulatory obligations, and operational feasibility.
In GRC, the difference matters because the work has consequences. Consider . . .
- A system that writes a remediation plan may save time. A system that understands whether the remediation plan will actually reduce exposure, fit available resources, meet regulatory commitments, preserve business continuity, and avoid creating new dependencies is doing something very different.
- A system that summarizes a supplier report may improve productivity. A system that understands how that supplier supports a critical service, what data it handles, what subcontractors it relies on, what obligations apply, what controls are missing, and what alternative suppliers exist is doing something very different.
- A system that answers questions about a policy may help employees. A system that observes behavior, detects drift from policy, connects that drift to control failures, escalates exceptions, and supports accountable decisions is doing something very different.
- This is why the market needs a sharper vocabulary. Assistive AI is useful. Generative AI is useful. Search is useful. Summarization is useful. Workflow automation is useful. But assistance is not agency. Automation is not intelligence. Fluency is not decision capability.
If the AI cannot show what it observed, what context it used, what options it considered, what constraints applied, what assumptions were made, what action was permitted, what human approval was required, and what outcome followed, then buyers should be cautious.
The standard remains simple: show me the work.
From Systems of GRC Record to Systems of GRC Orchestration
Historically, GRC technology from GRC 1.0 through GRC 6.0 has been built primarily as a system of record. The underlying architecture has largely been relational databases, structured forms, tables, records, workflows, and reports. A risk was a record. A control was a record. A policy was a document. An obligation was mapped to a control. A third party was assessed through a questionnaire. An issue was opened, assigned, tracked, and closed. The system’s purpose was to document, organize, route, evidence, and report on GRC activity.
That architecture was necessary. It brought structure to what had too often been managed through spreadsheets, email, shared drives, and fragmented departmental processes. It created accountability. It supported repeatability. It helped organizations maintain evidence, manage approvals, document decisions, and produce defensible reports. Systems of record still matter, and they will continue to matter in GRC 7.0.
But in GRC 7.0, the system of record is no longer the center of gravity.
The shift at the core of GRC is from systems of record to systems of orchestration. GRC 7.0 – GRC Orchestrate is not simply about storing more records, adding more workflow, or generating more reports. It is about coordinating intelligence, context, decisions, and action across the enterprise. It is about understanding how objectives, risks, controls, obligations, policies, processes, systems, services, third parties, evidence, issues, incidents, and decisions connect. It is about moving from static documentation to dynamic enterprise coordination.
At the center of this orchestration architecture are two essential subsystems:
- The first is a system of intelligence. This is where agentic AI and other analytical capabilities gather information, interpret signals, connect context, and make sense of what is happening across the organization. It draws from other business systems, documents, policies, regulations, controls, evidence, telemetry, incidents, third-party data, system logs, business process information, and external intelligence. But its purpose is not merely to summarize information. Its purpose is to understand relationships, identify patterns, surface weak signals, detect gaps, explain context, and support decision-making. Contextualizing information is critical.
- The second is a system of action. This is where autonomous or semi-autonomous capabilities move beyond insight into governed execution. A system of action can initiate a process, request evidence, assign a task, create a finding, escalate an exception, update a record, recommend remediation, trigger a review, or execute a defined action within approved boundaries. But in GRC, action must always be governed action. It requires permissions, approvals, audit trails, segregation of duties, policy constraints, human oversight, exception handling, and evidence of what was done and why.
This is the architectural distinction that matters. A system of intelligence helps the organization understand. A system of action helps the organization respond. A system of orchestration coordinates both so that GRC becomes more than documentation and workflow. It becomes an enterprise capability for observing the business, understanding dependencies, comparing options, making decisions, taking accountable action, and learning from outcomes.
This is why GRC 7.0 is not simply another phase of feature expansion. It is a shift in the core model of GRC technology. The relational database and the system of record were important foundations, but they are no longer sufficient. The future of GRC requires orchestration across connected context, intelligent interpretation, and governed action.
That is where agentic AI becomes meaningful. Not as a chatbot attached to a legacy workflow engine. Not as a fluent assistant generating polished text. Not as a magical interface layered over disconnected records. Agentic AI becomes meaningful when it operates within a system of orchestration that can gather information, understand context, maintain state, use tools, respect governance boundaries, take or recommend action, and prove the work.
This is the move from GRC as administration to GRC as orchestration. It is the move from managing artifacts to coordinating decisions. It is the move from recording what happened to helping the organization decide what should happen next.
But action in GRC is not merely execution. It is accountable execution.
This is where many AI claims become thin. It is easy to show an assistant that recommends a task. It is harder to show a system that can safely operate as a governed participant in GRC work. Governed action requires permissions, approvals, segregation of duties, audit trails, rollback, exception handling, evidence lineage, policy boundaries, model evaluation, performance monitoring, and human accountability.
It also requires comparison. A language model can propose options. But comparing options often requires structured data, quantification, optimization, scenario analysis, constraints, risk appetite, cost, timing, resources, operational feasibility, and outcome evidence.
This is where the real architecture of GRC AI becomes more interesting than the demo. The future is not one magical model answering every question. The future is an architecture in which different capabilities do different jobs. Such as . . .
- Language models help with interaction, summarization, explanation, classification, drafting, and translation between technical and business language.
- Machine learning and statistical analytics help with pattern detection, anomaly identification, signal interpretation, and predictive indicators where sufficient quality data exists.
- Knowledge graphs and ontologies help connect relationships across objectives, obligations, risks, controls, processes, systems, third parties, evidence, and decisions.
- Rules engines and deterministic logic enforce non-negotiable requirements, policy boundaries, approvals, and segregation of duties.
- Optimization models help compare response options, sequence recovery, allocate resources, and choose the best available path under constraints.
- Human judgment remains essential for accountability, interpretation, challenge, ethics, policy ownership, and final decisions where consequences require human responsibility.
That is not theater. That is architecture.
Absolutely — this version avoids Expose, Model, Optimize as a named structure, shifts the phrase to Enterprise Risk & Resilience Decision System, and frames it more in your GRC 7.0 – GRC Orchestrate language. 🟢
The Enterprise Risk & Resilience Decision System
A useful way to frame the next generation of GRC is the Enterprise Risk & Resilience Decision System. This is not simply another module. It is not a dashboard. It is not a chatbot. It is not a document repository with AI search. It is an operating architecture that helps the organization understand risk and resilience in context, evaluate choices under real-world constraints, and support accountable action across the enterprise.
The Enterprise Risk & Resilience Decision System is an expression of GRC 7.0 – GRC Orchestrate. It moves GRC beyond the historical system-of-record model that defined GRC 1.0 through GRC 6.0. Those earlier generations were largely built on relational databases, structured records, forms, workflows, and reports. They documented risks, controls, obligations, policies, issues, incidents, third parties, and assessments. That foundation remains important. Organizations still need evidence, accountability, approvals, records, and reporting.
But the center of gravity changes in GRC 7.0. The core is no longer the record. The core is orchestration.
At the heart of this orchestration is a decision architecture that connects risk and resilience to the operating reality of the business. It maps how objectives depend on processes, how processes depend on systems, how systems depend on data, how services depend on third parties, how controls depend on evidence, how obligations constrain action, and how failures cascade across the enterprise. It moves the organization from isolated inventories to a living model of operational dependencies.
This matters because risk and resilience decisions are not made in a vacuum. When disruption occurs, organizations do not operate with unlimited time, unlimited staff, unlimited budget, unlimited technology capacity, and perfect information. They operate under constraints. Some systems must be restored before others. Some services are more critical than others. Some teams are overloaded. Some facilities are unavailable. Some third parties are delayed. Some controls cannot be bypassed. Some regulatory obligations cannot be ignored. Some customer commitments have priority. Some recovery actions reduce risk in one area while creating exposure in another.
A true Enterprise Risk & Resilience Decision System helps the organization understand these relationships before decisions are made. It provides visibility into dependencies, context for consequences, and decision support for action. It asks: what is connected, what is exposed, what choices exist, what constraints apply, what trade-offs matter, and what action is defensible?
Consider recovery optimization as an example of what real GRC AI should look like. Recovery Optimization should not be a fluent paragraph saying, “restore the most critical services first.” That is obvious. The real question is how to sequence recovery when criticality, dependency, capacity, time, resource availability, contractual obligations, regulatory requirements, control implications, and business impact all collide.
That is not a job for a chatbot. That is a job for decision intelligence supported by optimization.
Constraint programming and linear programming can help sequence recovery under real operational constraints. They can evaluate what is possible, not merely what sounds good. They can compare alternatives. They can show why one recovery sequence is better than another. They can identify bottlenecks. They can expose infeasible assumptions. They can help the organization understand trade-offs between resilience, compliance, cost, timing, capacity, and impact.
Most importantly, this type of decision support can be deterministic, explainable, and reproducible.
That matters in GRC. A recovery decision cannot be based on a mysterious answer from a black box. Leaders need to understand the assumptions, constraints, priorities, dependencies, and trade-offs behind the recommendation. Risk, compliance, audit, legal, security, operations, technology, and executive management need to be able to challenge the model, review the evidence, and understand the basis for action.
This is what “show me the work” looks like in practice.
- Show me the dependencies.
- Show me the constraints.
- Show me the recovery options considered.
- Show me the decision criteria.
- Show me the rejected paths and why they were rejected.
- Show me what assumptions changed the recommendation.
- Show me what evidence supported the decision.
- Show me where human approval was required.
- Show me what was logged.
- Show me what happened after the decision.
- Show me what the system learned.
This is the difference between AI that describes risk and resilience and AI that helps manage risk and resilience. It is the difference between an assistant that can produce language and a decision system that can support action. It is the difference between GRC as documentation and GRC as orchestration.
The Enterprise Risk & Resilience Decision System is where GRC 7.0 becomes practical. It combines a system of intelligence that gathers information, interprets signals, and makes sense of context with a system of action that supports autonomous or semi-autonomous activity within defined governance boundaries. Together, these subsystems allow GRC to move from recording what happened to helping the organization decide what should happen next, act within constraints, and prove why the action was taken.
The Yellow Brick Road Has to Lead Somewhere
The Wizard of Oz metaphor works because the market has created so much spectacle. But the more useful part of the story is not only the curtain. It is the journey.
The yellow brick road is full of promises. Follow this path and you will get intelligence. Follow this path and you will get assurance. Follow this path and you will get autonomy. Follow this path and all the hard work of GRC will become easier.
But the road has to lead somewhere real.
If the road leads only to a louder wizard, buyers will be disappointed. If it leads to another generation of disconnected modules with AI-generated language, the market will have missed the point. If it leads to faster production of weak artifacts, organizations will simply do the wrong things more quickly and with more confidence.
The road has to lead to better decisions.
That is the purpose of GRC. Not maintaining artifacts. Not producing dashboards. Not generating reports. Not filling repositories. Not checking boxes. GRC exists to help the organization set and achieve objectives, address uncertainty, and act with integrity.
AI must be judged against that purpose . . .
- Does it help the organization understand what matters?
- Does it connect obligations, risks, controls, evidence, and actions to objectives?
- Does it reveal dependencies before they become surprises?
- Does it distinguish strong evidence from weak evidence?
- Does it compare choices?
- Does it support action within governance boundaries?
- Does it improve decisions?
- Does it preserve accountability?
- Does it prove what happened?
These are the questions that move the conversation beyond theater.
The Brain, the Heart, and the Courage of GRC AI
If the Wizard of Oz metaphor continues, then perhaps the next phase of GRC AI needs three things: a brain, a heart, and courage.
- The brain is connected intelligence. It is the ability to understand relationships, dependencies, context, signals, evidence, patterns, and consequences. It is not merely the ability to generate text. It is the ability to reason across a model of the enterprise.
- The heart is purpose and integrity. GRC technology must stay anchored to business objectives, accountability, ethical conduct, regulatory obligations, customer commitments, and the organization’s values. Intelligence without integrity is dangerous. Automation without accountability is reckless. Efficiency without purpose simply accelerates confusion.
- The courage is governed action. It is easy to summarize. It is harder to act. It is easy to recommend. It is harder to compare options and take accountable steps within defined boundaries. It is easy to demo intelligence. It is harder to expose the machinery to scrutiny.
This is where the market must mature. Vendors need the courage to be precise about what their AI does and does not do. Buyers need the courage to challenge vague claims. Boards and executives need the courage to demand proof before trusting AI-enabled systems with decisions that affect resilience, compliance, control, performance, and integrity.
The next generation of GRC will not be built by pretending that every assistant is an agent. It will be built by showing how intelligence becomes accountable action.
Business Confidence Comes From Proof
The outcome of all of this should be Business Confidence.
Business Confidence is not blind trust that everything is fine. It is not a dashboard ritual. It is not a green indicator that no one can explain. It is not the absence of risk. It is the confidence that leaders have enough relevant, reliable, contextualized information to make better decisions.
Business Confidence comes when the organization can see the signals, understand the relationships, evaluate the options, act within boundaries, and prove the outcome.
This is where agentic AI in GRC has real promise. It can scale scarce expertise. It can reduce administrative friction. It can help risk and compliance teams spend less time chasing evidence and more time advising the business. It can help audit teams understand evidence lineage. It can help executives receive briefings tied to objectives and decisions rather than static reports. It can help boards understand not only what is red, amber, or green, but what those indicators mean in context.
But Business Confidence does not come from AI language alone. It comes from connected context, ground truth, governed action, optimization, accountability, and evidence.
The future of GRC technology will be shaped by this distinction. Providers that merely attach AI to legacy workflow will have a story, but not a strategy. Providers that build dependency-aware, decision-capable, governed architectures will define the next era.
This is why architecture is becoming more important than features. AI is already changing the economics of software development. Features that once took months or years to build can increasingly be prototyped in days or weeks. That does not eliminate the need for product discipline, validation, security, usability, governance, and support. But it does mean that feature breadth alone will become less defensible.
When everyone can build features faster, differentiation moves to context, architecture, expertise, trust, and outcomes.
The question is no longer simply whether a GRC platform can do something. The question is whether it can help the client do it well.
- Can it represent the enterprise as a connected system?
- Can it support decisions, not just records?
- Can it observe behavior, not just collect attestations?
- Can it model dependencies, not just store objects?
- Can it optimize action, not just route tasks?
- Can it prove its work, not just produce fluent language?
That is where the future of GRC technology is going.
Do Not Ask for a Better Curtain
The market does not need a better curtain. It does not need more smoke, brighter lights, or a louder voice from the Emerald City. It does not need AI slogans stitched into legacy workflows. It does not need every chatbot renamed as an agent.
The market needs substance.
- It needs enterprise service-and-dependency models that make cascades visible.
- It needs systems of action that operate within governance boundaries.
- It needs decision systems that expose, model, and optimize.
- It needs deterministic optimization where deterministic optimization is the right tool.
- It needs language models where language models are the right tool.
- It needs human judgment where human judgment is required.
- It needs auditability, explainability, accountability, and proof.
Last week, in my blog article, the message was to pull back the curtain. This week, the message is to inspect the machinery.
When a vendor says it has agentic AI, ask what the system can observe. Ask what it knows. Ask what it can model. Ask what decisions it can support. Ask what actions it can take. Ask what constraints it understands. Ask what is deterministic, what is probabilistic, what is generative, what is optimized, and what is governed. Ask what is in production and what is roadmap poetry. Ask how it proves that the organization made a better decision than it otherwise would have made.
- Do not accept fluency as agency.
- Do not accept automation as intelligence.
- Do not accept workflow decoration as transformation.
- Do not accept the wizard’s voice when what the enterprise needs is a working decision system.
The future of GRC AI is not the illusion of magic. It is the discipline of architecture. It is the ability to connect context, understand dependencies, compare choices, govern action, and prove outcomes.
That is how GRC moves from theater to trust. That is how AI becomes useful. That is how organizations gain Business Confidence.