The best AI opportunities in Governance, Risk and Compliance may already be hiding inside the work we do every day.
Artificial Intelligence has quickly become one of the most discussed topics in technology.
Organizations are exploring AI strategies. Vendors are adding AI capabilities to their products. Teams are being encouraged to identify AI use cases. And almost every technology conversation eventually arrives at the same question:
But when it comes to Governance, Risk and Compliance (GRC), I think there may be a better question:
“What problem are we trying to solve?”
That difference may seem small, but it can completely change how we approach AI.
Instead of looking for somewhere to insert AI, we can start by looking at the friction that already exists in our GRC processes.
Because sometimes the best AI use case isn’t a revolutionary new platform.
Sometimes it is simply finding a smarter way to do something we already do every day.
AI Doesn’t Have to Start With a Big Project
When organizations discuss AI in GRC, the conversation can quickly become ambitious.
Can AI predict emerging risks?
Can AI continuously monitor controls?
Can AI interpret regulations?
Can AI identify compliance gaps automatically?
These are exciting possibilities.
But organizations don’t necessarily need to begin there.
There are smaller and more practical opportunities throughout the GRC lifecycle.
Think about the amount of information GRC teams work with.
Policies.
Regulations.
Risk assessments.
Controls.
Issues.
Action plans.
Audit findings.
Testing results.
Configuration files.
Reports.
Meeting notes.
Requirements.
Logs.
Many GRC professionals spend a significant amount of time not necessarily making decisions, but finding and organizing the information needed to make those decisions.
That is an important distinction.
And it is one of the areas where AI can potentially help.
Look for Friction
When I think about opportunities for AI or automation, I like to start with something simple:
Where is the friction?
What activity takes longer than it should?
What task do people repeat every week?
Where are we manually comparing information?
Where are we searching through hundreds of records?
Where are we copying information from one place to another?
Where are we spending hours preparing information before the real analysis can even begin?
Those activities are often better candidates for AI than trying to invent an AI project from scratch.
For example, imagine a GRC analyst reviewing hundreds of issues.
The important part of the job may be determining which issues require attention.
But before reaching that point, the analyst may spend hours sorting, filtering, reading descriptions, comparing dates, reviewing statuses, and identifying patterns.
AI does not necessarily need to make the risk decision.
It could simply help reduce the amount of information the analyst needs to manually process.
That alone can create value.
The Same Principle Applies to GRC Technology
The opportunity is equally significant for people building and supporting GRC platforms.
Consider a seemingly simple request:
“We need to change this field.”
Anyone who has worked with a mature enterprise platform knows that the next question should be:
“What else will this change affect?”
That field might appear in multiple views.
A calculation may reference it.
A workflow may depend on it.
It could be used in reporting.
It might participate in a dependent picklist.
An integration could be sending or receiving its value.
Suddenly, a simple field change becomes an impact-analysis exercise.
Traditionally, someone may need to search across configuration files, documentation, reports, spreadsheets, and system components.
Now imagine having tools that can extract those dependencies automatically and AI that can help organize and explain the results.
The developer still evaluates the change.
The architect still considers the design.
The business still determines the requirement.
But the tedious discovery work can potentially become much faster.
That is a practical example of AI in GRC.
AI Should Reduce the Work Around the Work
One of the most interesting opportunities for AI may be reducing what I call “the work around the work.”
A risk professional’s real value isn’t copying information between spreadsheets.
A developer’s real value isn’t manually searching thousands of lines of configuration.
A compliance professional’s real value isn’t spending hours formatting information before reviewing it.
A control owner isn’t adding value because they repeatedly enter the same information into multiple systems.
Those activities may be necessary today.
But they aren’t necessarily where human expertise creates the most value.
If AI and automation can reduce those activities, people can spend more time on:
analysis, judgment, decision-making, design, challenge, and problem-solving.
That is where augmentation becomes meaningful.
A Simple Framework for Finding AI Opportunities
Instead of starting an AI initiative by asking everyone for “AI ideas,” GRC teams could examine their existing processes through four questions.
1. What are we repeatedly reading?
Large policies, regulations, issue descriptions, audit findings, requirements, control documentation, and other text-heavy information may create opportunities for summarization, classification, extraction, or comparison.
2. What are we repeatedly searching for?
If people constantly search for relationships, dependencies, similar issues, related controls, historical decisions, or specific information across multiple sources, AI-assisted search and analysis may help.
3. What are we repeatedly creating?
Test cases, technical documentation, summaries, meeting notes, initial reports, mappings, and other first-draft content may be areas where AI can accelerate the starting point.
4. What are we repeatedly analyzing?
Trends, exceptions, overdue items, recurring issues, control failures, risk indicators, and configuration dependencies can potentially benefit from a combination of analytics, automation, and AI.
None of these automatically require AI.
Sometimes a simple SQL query is better.
Sometimes Python is better.
Sometimes an existing platform feature already solves the problem.
And sometimes AI is the right tool.
The problem should determine the technology.
Not Everything Needs AI
This may be one of the most important lessons as AI adoption accelerates.
Just because something can use AI doesn’t mean it should.
If a deterministic business rule can solve the problem reliably, a traditional calculation may be better.
If a SQL query can retrieve exactly what is needed, adding AI may introduce unnecessary complexity.
If a process can be automated using an API, that may be more reliable than asking an AI model to perform the same task.
AI becomes valuable when the problem benefits from capabilities such as understanding unstructured information, identifying patterns, generating content, summarizing large amounts of information, or assisting with complex analysis.
Good AI adoption isn’t about using AI everywhere.
It is about knowing where AI belongs.
And GRC Should Challenge AI Too
There is also an interesting irony in bringing AI into GRC.
GRC exists partly because organizations need governance, oversight, controls, and accountability.
AI should not be exempt from those principles.
If AI is being used to support risk analysis, compliance activities, control assessments, or development decisions, we should still ask:
Where did the information come from?
Can the output be explained?
Who validates the result?
What happens when the model is wrong?
Is sensitive information being protected?
Who remains accountable for the decision?
The same mindset we apply to other technologies should apply to AI.
Perhaps even more so.
The goal isn’t simply AI in GRC.
It should also be GRC around AI.
The Best AI Use Case Might Be Sitting in Your BAU
When people think about innovation, BAU work can sometimes feel like the opposite of transformation.
But I think BAU is actually one of the best places to look for innovation.
Why?
Because that is where the real problems are visible.
That is where you discover the task that takes three hours every Friday.
The report someone manually reconciles every month.
The configuration review that requires opening ten different files.
The hundreds of records someone needs to classify.
The documentation that developers repeatedly recreate.
The troubleshooting process that depends heavily on searching old information.
Those are real problems.
And solving one of them can sometimes create more value than launching a large AI initiative with no clearly defined problem.
AI in GRC Is Ultimately About Better GRC
The objective shouldn’t be to make GRC look more advanced because it uses Artificial Intelligence.
The objective should be to make GRC better.
Faster where speed matters.
More consistent where consistency matters.
More insightful where analysis matters.
More automated where manual effort adds little value.
And still human-led where judgment, accountability, and experience matter.
That is why, when someone asks:
“Where should we start with AI in GRC?”
My answer is becoming increasingly simple.
Don’t start by looking for AI.
Start by looking for the problem.
Find the repetitive work.
Find the bottleneck.
Find the information overload.
Find the manual analysis.
Find the place where experienced people are spending their time on activities that don’t actually require their experience.
Then determine the best tool for solving it.
Sometimes that tool will be automation.
Sometimes analytics.
Sometimes APIs.
Sometimes traditional software development.
And increasingly, sometimes it will be AI.
That is where practical AI transformation begins—not with the technology, but with the problem worth solving.
