AI Agent for Fraud Detection: Alerts With Human Review

An AI agent for fraud detection reads order and payment attempts, compares each event with rules and patterns agreed with the business, and produces an alert with the reason recorded. It should not block anything on its own. The decision to hold, release or cancel belongs to a person, who receives the context needed to decide. In this design, the AI organizes the signals and the team is accountable for the block.

Key takeaways

• The agent flags risk signals in orders and payments, but it does not cancel an order without a person deciding.
• Each alert must record the reason, the data consulted, and the rule or pattern that triggered it.
• Fixed rules remain the foundation. AI is added to read context, summarize the case and prioritize the queue.
• The data used should be the minimum needed for screening, with purpose and legal basis defined before the pilot starts.
• A pilot with one queue, one agreed metric and complete logs shows whether the design is worth keeping.

Why the agent should not have the final word

Fraud is a problem of false positives as much as false negatives. A wrongful block delays delivery, frustrates a legitimate customer and can generate a wave of support tickets, while a wrongful release causes direct loss. A model that decides alone tends to hide that trade-off behind a score, which makes it harder to correct the process when fraud patterns change.

There is also a legal point. Article 20 of the LGPD gives people the right to request a review of decisions made solely on the basis of automated processing of their data. Even when a company is not required to act this way in every case, keeping a person accessible in the process, with a real capacity to review, is the simplest way to reduce that risk. We cover this topic in more detail in our article on automated decisions under the LGPD and the right to review.

Which signals the agent can flag

Fraud signals rarely appear alone. It is usually a combination of two or three factors that justifies a review. Common examples, which should be validated against the company's own history:

• A delivery address that differs from the billing address, especially when the account is new.
• Several payment attempts with different cards within a short interval.
• An order value well above that customer's usual pattern.
• A change of address or phone number shortly after an order was approved.
• Contact details already linked to accounts with a history of payment disputes.

These signals are leads, not verdicts. The agent should describe them in plain language and should not use sensitive personal characteristics or make inferences about the person. This limit also needs to appear in the project's data policy.

Step by step: designing the flow

Before choosing a model or a tool, the flow design should answer a few simple questions. A practical sequence:

• Map the current flow: who receives the order, who releases it, how long review takes today and which losses have already happened.
• List the events the agent can see (order, payment attempt, account creation, delivery change) and the ones it should not see.
• Separate the rules that already exist into fixed rules and the points that depend on judgment. Only the second group justifies AI.
• Define three possible outcomes: release, review or hold for a person. Automatic cancellation should not exist in the pilot.
• Assign an owner to each queue and set an internal response deadline so orders do not sit idle.
• Record every alert with its reason, signals, rule version and final decision.
• Test with historical cases and synthetic cases before exposing the agent to real orders. This care is similar to what we describe in our guide on testing AI agents with mocks and sandboxes.

What each alert must record

An alert without a record is useless for audits and for improving the rules. For each case, the log should contain:

• The order identifier, and the date and time of the event.
• The signals found, described in short, verifiable sentences.
• The rule or pattern triggered and the current version of that rule.
• The data consulted to reach the alert, without copying the entire customer record.
• The risk level assigned and the action the agent recommends.
• The reviewer's name, the final decision and a written justification.
• Whether the customer requested a review or disputed the decision.

The reason must be specific. 'Suspicious activity' helps no one. 'Delivery address in another state, card added a few hours ago, and order value above this customer's usual level' lets a person review the case quickly and lets the team adjust the rule later. The same traceability logic appears in the NIST AI Risk Management Framework, which addresses documentation, monitoring and human accountability across the system's lifecycle.

Illustrative scenario: a store selling through its website and WhatsApp

Illustrative scenario, not a real case: an electronics store receives a high-value order, paid with a card added that same day, with a delivery address in another city. The agent produces an alert listing three reasons, classifies the case as review and sends it to the payments team, with the customer's history alongside. The reviewer confirms account ownership through a channel registered before the order, not through a link sent in the conversation. If the confirmation fails, the order is held and the team records the reason. In either outcome, the agent decides nothing beyond organizing the case and explaining why it arrived there.

The example shows the right role for AI: it shortens the time needed to understand the case, but decisions about money and delivery remain human.

Data limits, LGPD and the security of the agent itself

The agent needs access to personal data, and that requires care. Some basic practices: restrict access to the fields that are necessary, define how long logs are kept, separate test environments from production, and carefully assess where data goes when a model hosted outside Brazil takes part in screening. We discuss this last point in our article on international data transfer with AI providers under the LGPD. For up-to-date guidance on the law, it is worth consulting ANPD, Brazil's data protection authority.

Agents also carry a specific risk: the text of an order, a message or a note can contain instructions written to mislead the model, such as asking it to approve a transaction. For this reason, the agent should have no tools that release or cancel anything, and the guidance in the OWASP Top 10 for LLM applications on prompt injection and permission control should be part of the design from the start.

How we apply the method: map, limit, pilot, hand over

In our way of working, we start by mapping the current flow and the baseline for losses and review time. Then we limit the agent's data and actions, pilot a real queue with logs and with a success metric agreed before launch, and only then hand the operation over to the team. The next decision is to expand, adjust or stop. This process is described in how we work with companies. When the operation needs ongoing support, Be Human (be-human.ai) can run it.

Frequently asked questions

Can an AI agent block an order on its own? It is not the safest recommendation for the first cycle. In a pilot, the agent should only classify, explain and route cases, while a person confirms any hold or cancellation. This separation makes audits easier and limits the damage from an error.

What data does the agent need to detect fraud? Usually order, payment, account and delivery data, to the extent each rule requires. The full customer history is not always necessary. Start with the minimum and expand only if reviews show that a specific piece of data is missing for a decision.

How do you know whether the alerts are good? Compare alerts with the final outcome of reviews, noting how many led to a useful hold and how many were released after checking. Also track the queue's delay, because a good alert that no one reviews in time protects nothing. The metric should be agreed before the pilot, not after it.

Is this superintelligence? No. A fraud agent is a software system with rules, models and limited permissions, operating under supervision. The term superintelligence often appears in marketing material and does little to help with decisions. To separate the concepts, read our article on the difference between AGI, ASI and AI agents.

Sources

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• ANPD: Autoridade Nacional de Proteção de Dados