Overview
Employees often struggle to report GRC issues with enough detail for triage teams to act on. Vague descriptions lead to back-and-forth, delayed resolution, and inconsistent records.
The Report a GRC Issue AI agent solves this by guiding employees through a conversation in Employee Center. It validates what they've described, structures it into organized fields, and automatically suggests the relevant entities, controls, policies, or regulations from your own ServiceNow data — before a single form field is filled.
What Is the Agent Trained On?
The agent does not use a custom-trained model. It combines two sources of intelligence, all grounded in your own ServiceNow instance:
|
Source |
What It Uses |
How |
|---|---|---|
|
Your GRC data |
Entities, Control Objectives, Policies, Regulations |
Semantic search against indexed records |
|
AI reasoning |
NowAssist Skill (GPT / Claude / Gemini) |
Structured prompt enriched with your org's GRC definitions |
End-to-End Flow
Behind the scenes, the agent orchestrates three tools — each with a specific responsibility: understanding your input, finding relevant records, and creating the issue. The diagram below shows the full flow; a detailed breakdown of each tool follows.
The Three Tools
Tool 1: Issue Key Information Finder
This is the agent's first act. Before anything is searched or saved, it reads your free-text description and does two things: confirms whether what you've described qualifies as a GRC issue, and if it does, structures it into organized fields.
How it knows what a "GRC issue" means in your organization
The tool doesn't rely on a hardcoded definition. Before calling the AI model, it reads your organization's definitions for key GRC terms directly from the sn_grc_context_definition table — issue, entity, control objective, policy, and regulation — and passes them into the prompt at runtime. The agent validates your input against your org's definitions, not a generic one.
sn_grc_context_definition is the right place to start — no code changes required.Along with those definitions, it pulls the current list of valid issue types and today's date from the system to ensure accurate classification and date interpretation.
What gets extracted from your description:
|
Field |
How it's determined |
|---|---|
|
Issue title |
A concise one-liner focused on the core problem |
|
Problem statement |
A comprehensive description of what happened |
|
Root cause |
The fundamental underlying cause, not just symptoms. Left blank if there isn't enough information |
|
Issue type |
Best match from the valid issue types configured in your system |
|
Date of occurrence |
Date on which the issue was identified or occurred |
|
Potential controls |
Control names inferred from your description — only for control-related issue types |
If your description doesn't qualify as a GRC issue, the agent asks for more detail. After one retry, if it still doesn't qualify, the conversation ends. The issue type identified here determines exactly which records Tool 2 searches for next.
Tool 2: Issue Related Object Information Finder
Once your description is validated and structured, this tool searches your ServiceNow instance for the actual records relevant to your issue — entities, control objectives, controls, policies, or regulations.
It doesn't search everything at once. It uses the issue type from Tool 1 to determine which objects apply, and runs checks along the way before committing to each search.
Entity search always runs first
Regardless of issue type, the agent always looks for the most relevant entity — the business unit, process, or system affected. It searches all entities in your instance using semantic matching and returns the best result, with up to four alternatives available if you choose to edit.
What gets searched next depends on your issue type
Control-related issues
Control design effectiveness failure · Control operative effectiveness failure · Control does not exist · Control does not meet requirement
The agent searches for the most relevant control objective, using your description and the inferred controls together as the search input. Only if both a matching control objective and entity are found does it then look for a specific control — by querying records directly linked to that entity and control objective. This ensures the suggested control is genuinely tied to the affected area, not just a loose keyword match.
Policy-related issues
Non-compliance to a policy · Improvement or suggestion to an existing policy · Recommendation for a new policy
The agent searches for the most relevant active policy in your instance.
Regulation-related issues
Non-compliance to a regulation
The agent searches your authority documents for the most relevant regulation.
All other issue types
Risk issue · Process optimization · Data Breach · Fraud · Misstatement · Documentation · Training · Observation · Other
Only the entity search runs. No control, policy, or regulation lookup is performed for these types.
What actually gets included in the search
Not all records in each table are indexed — filters control what's available for suggestions:
|
Object |
Filter Applied |
|---|---|
|
Entities |
All entities |
|
Control Objectives |
Active only, excluding UCF-sourced records |
|
Policies |
Active only |
|
Authority Documents |
All authority documents |
All searches use semantic similarity. A result must score at least 70% to be returned. The top result becomes the primary suggestion in your summary; the rest are held as alternatives if you choose to edit a field.
Tool 3: Create an Issue
Once you review the structured summary and confirm submission, this tool creates the issue record in ServiceNow.
Which table receives the record
If your organization uses the GRC Advanced application with the "My Issues" configuration enabled, the record is created in the advanced issue triage table. Otherwise it goes to the standard issue table. This is determined automatically from your instance configuration — no input needed from you.
Note on root cause and date of occurrence
These fields exist as dedicated columns only on the advanced triage table. If your org uses the standard issue table, these values are appended to the issue description so no information is lost.
What happens when a suggested value doesn't match a real record
If an AI-suggested value — an entity name, a control, a policy — can't be matched to an actual record in your system, it isn't silently dropped. It's appended to the issue description in a readable format so your triage team can see it and take action when they review the submission.
Customizing the Agent
The Report a GRC Issue agent supports a range of customizations — from updating how your organization defines a GRC issue, to adjusting search behavior, extracting additional fields from descriptions, and mapping them to the issue record.
For the full customization guide, refer to: Customizing the Report a GRC Issue Agent.
Frequently Asked Questions
Does the agent learn from submissions over time?
As new issues, policies, and entities are added to your instance and indexed, the quality of suggestions improves automatically. The underlying AI model does not change.
What if the search returns no results?
The agent still creates the issue. Any values that couldn't be matched are appended to the issue description. Nothing is lost.
Can I restrict who can use this agent?
Yes. Required roles: employee user, business_user, or business_user_lite plus sn_grc_genai.issue_aiagent_user. Access is configured via Define security controls for an AI agent.
Can I change which AI model powers the agent?
The model is configured at the Now Assist level and is shared across Now Assist applications. Changes are made in Now Assist settings, not in GRC-specific configuration.
Why aren't suggestions appearing right after activation?
Indexing is still in progress. Issue validation and field extraction work immediately — suggestions for related records appear only after indexing completes, which can take minutes to hours depending on your data volume.
