OBLYTECH / SERVICENOW CAPABILITY
ServiceNow AI governance and control for accountable workflows
Define access, approvals, exceptions, monitoring and evidence for ServiceNow AI workflows.
PARTNER DELIVERY — OBLYTECH is a ServiceNow Partner.
Discuss your AI governance priorityServiceNow AI governance is not a document added after an agent or automation has
been designed. It is the operating boundary that defines who can use the workflow,
what context it may access, which actions require approval and how a person can review
what happened. OBLYTECH helps teams make those boundaries practical.
Make AI control part of the operating model
An AI-enabled workflow sits inside existing roles, services, records, approvals and
integrations. Governance therefore needs to describe the work, not only the feature.
The owner should be able to explain the intended job, prohibited action, exception
route and evidence needed for review.
This makes governance useful during ordinary operation. It helps a reviewer understand
why a workflow stopped, lets an owner change a boundary deliberately and gives security
and risk stakeholders a route to challenge an action without stopping every workflow.
The control boundaries to define
Identity and permitted context
Define the user, role, service context and records available to each workflow step.
Access should be limited to what the job needs and should remain understandable after
the workflow has run. A broad technical account is not a substitute for an explicit
context decision.
Actions, approvals and human accountability
Separate information gathering, recommendations, preparation and actions that change
records or systems. State which actions are automatic, which require approval and who
owns the outcome when a person accepts or rejects a proposal.
Exceptions, monitoring and evidence
An exception should have a visible reason, owner, hand-off and closure condition.
Monitoring should show workflow state and failures, while evidence should preserve the
input, proposed action, decision and outcome in a form an operator can review.
How OBLYTECH approaches AI governance
OBLYTECH uses a staged sequence:
- Define the workflow job, users, owner and prohibited actions.
- Map context, roles, data sources, approvals and downstream systems.
- Set action boundaries, human review and exception conditions.
- Define monitoring, evidence, review cadence and change ownership.
- Test ordinary, incomplete, rejected and emergency paths.
- Establish the operating hand-off for control improvement.
For the delivery route, see ServiceNow AI and agentic automation.
For the broader platform route, see ServiceNow services overview.
What the engagement can establish
- an accountable owner and workflow boundary;
- identity, context and permitted-action decisions;
- approvals, human review and exception rules;
- monitoring, evidence and review requirements; and
- a change and operating model for the control.
Questions to settle before release
What must remain human?
Name decisions that require authority, judgement or separation of duties. Do not let
an unclear boundary become an accidental permission.
How will an operator investigate failure?
Define what context and evidence is retained, who receives the exception and how the
workflow resumes or closes.
Who can change the control?
Identify the owner, review route and evidence required when a prompt, action, role,
data source or integration changes.
Discuss your ServiceNow AI governance priority
Bring the AI workflow that needs a stronger control boundary around access, approvals,
exceptions, monitoring or evidence. OBLYTECH can help make governance part of the
workflow’s operating design.
Discuss your ServiceNow AI governance priority with OBLYTECH
Discuss your ServiceNow AI governance priority
Bring the AI workflow that needs a stronger control boundary around access, approvals, exceptions, monitoring or evidence.
Discuss your ServiceNow AI governance priority with OBLYTECHTreating a change to an AI workflow as a controlled change
An AI-enabled workflow changes more often than a conventional one, and many of the changes look too small to review. A new sentence in an instruction, an extra data source for better context, a wider role for a team that was struggling, a different threshold for routing: each one alters what the workflow can do. Governance has to treat these as changes with consequences, not as tuning. The table sets out the kinds of change that usually appear and the review each should trigger.
| Change to the workflow | Why it matters | Review that should follow |
|---|---|---|
| Instruction or prompt wording | It changes the decision the agent makes, even when the edit looks cosmetic | A re-run of the agreed test set, compared with the previous version |
| New data source added to context | It can bring in information the workflow was never meant to use | Approval from the source owner, and a privacy and access check |
| Role or group given the workflow | It widens who can trigger or accept the output | Workflow owner sign-off and an access review |
| Routing or confidence threshold moved | It changes how often a person sees the work | Sample review of cases on both sides of the new threshold |
| Integration endpoint or action changed | It changes what happens outside the platform | Failure path test and a reconciliation check |
| Underlying model replaced | It can change behavior across every case at once | The full test set and a period of supervised operation |
These changes can be governed through the platform’s own approval and change records, so each one leaves the same trail as any other production change.
Monitoring that shows whether the control still holds
Monitoring for an AI workflow should answer whether the control still holds, not only whether the workflow ran. The useful signals are the share of outputs a reviewer changed, the number of requests stopped by a boundary and the number of exceptions that remain open past their review date. A rising count of stopped requests may mean the boundary is doing its job or that the incoming work has changed. Either way the owner needs to know, and the monitoring should make the difference visible rather than leaving it to interpretation.
Failure monitoring is a separate matter. A workflow that fails quietly can be more dangerous than one that fails loudly. The control should specify who receives each class of failure, how quickly they must act and what the workflow does while the failure is unresolved. Pausing the agent and returning work to the queue should be a documented option, not an improvised one.
The evidence package a reviewer should be able to use
Evidence for an AI control is most useful when a reviewer can reconstruct a single decision without asking the team to explain it. For each run that matters, the record should keep the input as it arrived, the context that was used, the proposed action, the decision taken by the person or rule that accepted it and the resulting update. The evidence does not need to store everything the model produced. It needs to store enough to explain the outcome, and it should avoid copying sensitive input into places where it does not belong. The AI governance and risk controls page covers audit evidence alongside approved use, data access and human oversight.
A quarterly sample of these records, read by someone outside the workflow team, is a practical check. It catches drift that automated monitoring misses, because the drift is in the reasoning rather than in the failure count.
Where governance sits between security and the workflow owner
Workflow owners need a route to change a boundary without waiting for a committee to meet every time. A governance model should give each group a defined place. One workable split is that security can require a change to access or to a data source, and the workflow owner can adjust routing inside the agreed range. Changes that move the boundary itself go back to a joint decision. Writing that split down before launch avoids the argument that usually follows an incident, when nobody is sure who had the authority to change what. The AI and agentic automation page is about the bounded job and explicit controls these arrangements sit around, and the ServiceNow solutions hub lists the related solution routes.
Where a workflow relies on low-code configuration built by business teams, the same split applies to those builders.
Questions a control owner should be able to answer
- Which decisions in this workflow must remain with a named person, and why?
- Which data sources can the workflow read, and who approved each one?
- Where would a reviewer find the record of the last run that was stopped?
- Who can change the control, and what evidence must exist before they do?
What must remain with a person, whatever the agent can do?
Decisions that need authority, judgment or separation of duties should be listed explicitly. Typical examples are accepting a risk on another team’s behalf, overriding a policy exception and approving a change to a control itself. The list is specific to each organization and should be signed by its owner.
How should a team investigate a failed AI workflow run?
The investigation starts from the stored record of the run. The team should be able to see the input, the context used, the proposed action and the point at which the process stopped. If the record cannot answer those questions, the evidence design needs to change before the next incident.
Do low-risk workflows need the full control set?
A lighter set is reasonable for a workflow with a reversible action and a narrow context. The owner should still record the boundary, the monitoring signal and a review date, so the workflow can be widened later without starting from nothing.
Who reviews a change the vendor makes to the underlying model?
The organization’s workflow owner should review it, using the same test set as any other change. A vendor release note describes what the vendor changed. It does not show how that change affects the organization’s own cases.
Starting a control review for an AI workflow
To talk through a control review, contact Oblytech. A first conversation should establish who owns each type of change, which evidence is missing and what a reviewer would need to see before accepting the workflow.
ServiceNow guides on this topic
Guides from the Oblytech ServiceNow library that explain the practice behind this page.