Plain-language configuration for verification flows and monitoring rules

At a glance

What this is: Sumsub’s updated Summy AI Copilot can now generate verification flows and monitoring rules from plain-language prompts, moving from advisory output to production-ready configuration.

Why it matters: This matters because IAM, compliance, and fraud teams must govern machine-produced configuration as an identity and control surface, not just the people approving it.

👉 Read Sumsub's update on AI Copilot for verification flows and monitoring rules

Context

Plain-language configuration changes the control problem from user instruction translation to configuration governance. The practical question is not whether the system can generate a flow or rule, but how teams validate that the generated output matches policy, jurisdiction, and operational intent before it is activated.

For compliance and fraud operations, this is an NHI governance issue because the platform is now acting on behalf of staff inside a production environment. That means the review model has to cover generated verification steps, monitoring logic, and change control for AI-authored configurations rather than treating them as ordinary user edits.

Key questions

Q: How should compliance teams govern AI-generated verification flows?

A: Compliance teams should treat AI-generated verification flows as production controls, not draft content. Every generated flow needs policy validation, jurisdiction checks, and accountable approval before it goes live. The key is to separate prompt creation from release authority so machine speed does not bypass control ownership.

Q: What breaks when AI builds monitoring rules from plain language?

A: What breaks is the assumption that only humans can translate policy into enforceable control logic. A plain-language prompt can yield a syntactically valid rule that is still wrong for risk tier, threshold logic, or regulatory scope. Without review, the organisation can deploy incorrect enforcement at speed.

Q: How do teams know if AI-generated configuration is working?

A: Teams know it is working when every generated object has traceable provenance, clear approval history, and measurable alignment to policy outcomes. If rules are proliferating faster than reviewers can explain them, the system is accelerating change without improving governance.

Q: Should organisations separate AI configuration creation from publication rights?

A: Yes. Separation of duties should apply to AI-generated controls just as it does to human-created ones. The person who describes the need should not be the only person who can publish the resulting rule or flow, especially when the object affects verification or monitoring decisions.

How it works in practice

Plain-language to platform schema translation

Summy is no longer just summarising cases or surfacing suggestions. It maps natural-language instructions into Sumsub’s exact schema for verification flows and monitoring rules, which means the AI is effectively acting as a configuration compiler inside the platform. That reduces manual setup, but it also compresses ambiguity into live control objects. If the prompt is underspecified, the output may still be syntactically valid while being operationally wrong. The core technical risk is schema conformity without governance correctness.

Practical implication: review generated outputs for policy fit and jurisdiction fit before activation, not just for syntax or completeness.

Human review in AI-generated configuration workflows

The update includes a human review step before generated configurations go live, which is the right boundary for a system that can create production objects. The technical issue is that once an AI generates a flow or rule, the object can carry real enforcement consequences across verification, screening, and monitoring. Review therefore has to inspect business intent, control coverage, and exception handling, not merely approve a draft. In governance terms, the AI becomes a configuration author, but not the final authority.

Practical implication: separate generation rights from publication rights and require approvers to validate control logic, not just accept the suggested configuration.

Editing, templates, and duplication as change-control accelerators

Level editing for the last 24 hours, template use, and duplication support create a fast iteration path that is useful operationally but demanding from a control standpoint. These capabilities reduce friction, yet they can also make it easier to propagate a flawed pattern across multiple flows or rules. In identity and compliance tooling, speed only helps when change provenance and rollback are clear. Without that discipline, template reuse becomes configuration drift at scale.

Practical implication: track lineage for generated and duplicated configurations so one bad template does not spread across multiple controls.

NHI Mgmt Group analysis

Generated configuration is now an identity control surface. When an AI system can produce verification flows and monitoring rules directly, the governance question moves from who can use the platform to who can author enforceable controls through it. That expands the identity boundary into configuration generation, where machine output can shape compliance outcomes. Teams should treat generated configuration as a governed artefact, not a convenience feature.

Plain language does not remove policy complexity. The translation burden changes form, but it does not disappear. A prompt can be easy to write and still produce a flow that is misaligned with geography, risk tier, or fraud policy. Practitioners need to assume that machine-authored configuration may be syntactically correct and operationally incomplete, which makes review quality the critical control.

Configuration provenance becomes the new audit question. Once AI can create, edit, and duplicate production rules, audit teams need to know which objects were generated, when they were changed, and who approved them. That is especially important in regulated operations where the enforcement logic itself is evidence. The governance test is whether every live control can be traced back to an accountable decision.

Workflow acceleration will pressure approval models. Tools that reduce setup effort inevitably change how much scrutiny teams apply before deployment. That can improve throughput, but it also risks normalising lighter review for high-impact controls such as verification steps and transaction monitoring rules. Practitioners should expect the approval process to become the bottleneck, because that is where machine-generated control logic is either validated or allowed to drift.

At scale, the platform is moving from assistant to delegated operator. Even with a human review gate, the AI is doing more than advising. It is drafting the configuration that determines how identities are verified and how suspicious activity is flagged. That makes delegated configuration authority the central governance issue, and teams should align their operating model to that reality.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• AI governance is already lagging in practice: 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to the same report.
• For a broader governance lens, the NHI Lifecycle Management Guide shows how provisioning, review, and offboarding discipline must extend to machine-authored controls as well.

What this signals

AI-generated configuration will force identity teams to widen their control perimeter. The immediate implication is that governance has to cover not only credentials and entitlements, but also machine-authored control logic that shapes how those credentials are verified and monitored. That is a lifecycle problem as much as a security problem, and it belongs in the same operating model as access review and change control.

Configuration provenance is becoming a practical audit requirement. If teams cannot tell whether a verification flow or monitoring rule was generated, duplicated, or hand-edited, they will struggle to defend control decisions after the fact. The most durable programmes will pair AI-assisted productivity with traceable ownership, clear approval boundaries, and explicit rollback paths.

With 80% of organisations already reporting AI agents acting beyond intended scope in our AI Agents: The New Attack Surface report, the lesson for practitioners is simple: delegated control creation needs stronger oversight than delegated control use. That is the governance shift this update should trigger.

For practitioners

• Classify generated configurations as governed control objects Treat AI-authored verification flows and transaction rules as production artefacts that require the same lifecycle handling as manually built controls, including ownership, approval, and traceability.
• Require policy and jurisdiction checks before go-live Validate each generated flow against internal policy, regional requirements, and fraud thresholds before the human review step approves publication.
• Track provenance for every generated or duplicated rule Record whether a flow or rule was generated from a prompt, adapted from a template, or duplicated from an existing object so audit teams can reconstruct decision history.
• Restrict who can publish AI-generated changes Separate configuration creation from release authority so the people approving live changes are distinct from those prompting the system.
• Use template libraries as controlled baselines Version template rules and compare any adapted configuration against the original baseline before allowing it into production.

Key takeaways

• AI-assisted configuration changes the governance problem from manual setup to machine-authored enforcement logic.
• Plain-language prompts can accelerate delivery, but they also create a new audit burden around provenance, approval, and policy fit.
• Teams should treat generated verification flows and monitoring rules as production controls that require separation of duties and explicit review.

Key terms

• Generated Configuration: A generated configuration is a live control object created by a system rather than hand-built by a human operator. In identity and compliance tooling, that can include verification flows, monitoring rules, or policy logic that will enforce real outcomes once published.
• Configuration Provenance: Configuration provenance is the record of how a control object was created, changed, duplicated, and approved. It matters because audit teams need to reconstruct the path from intent to enforcement, especially when AI systems can produce production-ready objects from plain-language instructions.
• Delegated Configuration Authority: Delegated configuration authority is the ability of a system to author control logic on behalf of people while remaining under human approval. The key governance question is not whether the system can generate a rule, but who is accountable for the rule once it is published.

Deepen your knowledge

AI-generated configuration governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for machine-authored verification flows or monitoring rules, it is worth exploring.

This post draws on content published by SumSub: New Sumsub AI Copilot update configures verification flows and monitoring rules from plain-language instructions. Read the original.