How to log and assess regulatory breaches with an AI agent

Capture every possible breach the day it surfaces, and decide calmly afterwards. The agent logs each one from incidents, complaints and findings, gathers the facts, identifies the rule involved, and drafts a severity and reportability assessment against your criteria. A named compliance owner decides whether it is a breach, how serious, and whether the regulator must be told.

What is the process, and who owns it?

A regulatory breach is a failure to meet a rule that applies to the firm: a missed deadline, a control that did not operate, a customer treated in a way the rules do not allow. Most regulators expect firms to record breaches, assess them, remediate them and, for significant ones, notify the regulator promptly. Supervisors read breach logs, and a thin log is itself a warning sign.

The compliance function owns the breach log, often through a named breach manager, with the head of compliance deciding on notifications. Business owners own the root cause and remediation. The weak point in most firms is capture: breaches surface in many places and nobody records them. Whether an AI agent can keep a compliance breach log sets the boundary.

What does the agent prepare, and what does a person approve?

1. Agent, depth 1: watches the sources. Incident tickets, complaints classified with a regulatory angle, audit and monitoring findings, missed deadlines from the regulatory change log, third-party failures, and staff reports.
2. Agent, depth 2: logs each possible breach with the source, date identified, the facts known and the business area. Logging is a draft entry until confirmed.
3. Agent, depth 1: identifies the rule. The rule, policy or obligation that may have been breached, quoted from the obligations register.
4. Agent, depth 1: gathers impact facts. Customers affected, financial harm, duration, whether it is continuing, and whether it repeats an earlier breach.
5. Agent, depth 2: drafts the assessment. Severity against your criteria, and whether it meets your notification thresholds, with reasoning.
6. Person, breach manager: confirms or rejects the entry and the assessment.
7. Person, head of compliance: decides on notification to the regulator and approves the notification text, which the agent may draft.
8. Person, business owner: agrees remediation and root cause.
9. Agent, depth 1: tracks remediation to closure and reports overdue actions.

Which controls apply, and what evidence does each leave?

Everything logged, nothing deleted. Possible breaches that turn out not to be breaches stay in the log with the reason. Evidence: a complete log, which shows the regulator that capture works.

Identification date fixed. The date the firm became aware is recorded at intake. Notification timing is judged from it. Evidence: intake timestamp.

Criteria-based assessment. Severity and reportability are assessed against written criteria, not instinct. Evidence: each assessment cites the criteria.

Named decision on notification. Including decisions not to notify. Evidence: decision, reasons, approver.

Root cause linked. Each breach links to its root cause and to other breaches with the same cause. Evidence: patterns visible in the log.

What should you measure?

• Time from identification to logged entry, and to decision.
• Breaches found by supervisors or audit that were not in the log.
• Assessments changed by the breach manager, and in which direction.
• Repeat breaches with the same root cause.
• Remediation actions overdue.

Where does it usually go wrong?

Breaches hidden as incidents. An operational incident that caused customer harm may also be a regulatory breach. If only the incident process runs, the breach is never assessed. The agent reads incidents for this.

Data protection handled separately and differently. A personal data breach may also be a regulatory breach of conduct or resilience rules. Run both assessments and make them consistent; see assessing personal data breaches for notification.

Severity judged by the size of the error, not the harm. A small processing error that affected thousands of vulnerable customers can matter more than a large one caught before it reached anyone. The criteria should weigh customer harm, duration and repetition, and the agent's draft should show each factor separately so the breach manager can see what drove the rating.

Third parties forgotten. A breach caused by an outsourced provider is still the firm's breach. Links to assessing third-party risk help here.

Late regulatory change. A rule that came into force before the firm was ready is a breach from that date. Changes assessed through assessing the impact of regulatory change should feed missed dates straight into the log.

Agents as the cause. If an AI agent's action caused the breach, record that, reconstruct the action from its record, and check whether its bounds were right. A breach caused by an agent acting within its bounds means the bounds need changing.

The stance on compliance agents overall is in AI compliance agents.

Where Pryme fits

In Pryme, every agent action and verdict is filed in an append-only record, so a breach involving an agent can be reconstructed exactly: what it did, which bound decided, and on what sources. The breach-logging agent drafts at depth 2; confirming a breach and notifying a regulator are outside its role scope.