AI governance: what to define before putting an agent into production

Define the scope in writing

The first control is also the simplest: record what the agent can and cannot do. Not as a general intention, but as a concrete list of allowed topics, prohibited topics and situations that require a transfer.

That document becomes the basis for both the technical configuration and the tests. Without it, there is no objective criterion for saying whether observed behavior is right or wrong.

Treat personal data by the same standards as the rest of the company

A customer service agent will process names, phone numbers and often financial information such as income range or intent to finance. LGPD (Brazil's data protection law) applies in full to this processing.

In practice, this means explicitly deciding a few points before turning the system on:

• What the legal basis for processing is and how it is communicated to the data subject.
• Which data is actually sent to model providers and how long it is retained.
• How long the company keeps conversation histories and for what purpose.
• Who, internally, has access to those records.
• How a data subject's deletion request is handled in practice.

Keep human review where the decision carries weight

Not every interaction needs supervision. But decisions with financial, legal or contractual impact need a person in the loop.

The common design lets the agent act freely on information and triage, and requires human confirmation for any action that creates a commitment — a final price, payment terms, a delivery promise.

Log interactions in an auditable way

When something goes wrong, the first question is what exactly was said. Without proper logging, the discussion comes down to the memory of whoever was nearby.

A useful history stores the full conversation, which data the agent looked up to answer, when a transfer to a human happened and which configuration version was active at that moment.

Evaluate continuously, not just at deployment

Systems built on language models do not have fixed behavior. Configuration changes, model updates and shifts in the mix of conversations change the results over time.

That is why evaluation has to be a routine, not an event. A set of representative test cases, run periodically, detects degradation before the customer notices. Sampling real conversations for human review completes the picture, surfacing problems no test anticipated.

Start small on purpose

The safest deployment starts with a narrow scope and controlled volume — one service segment, one location, one time slot. This makes it possible to observe real behavior with limited exposure.

Expansion comes later, backed by evidence that the system behaves as expected. It is slower at first and substantially cheaper than rolling back a broad deployment that went wrong.

Frequently asked questions

Does LGPD apply to using AI in customer service?

Yes. Processing personal data through an AI agent follows the same rules as any other processing: it requires a legal basis, transparency with the data subject, access control and fulfillment of the rights set out in the law.

What should you do when the AI gives a customer a wrong answer?

The plan needs to exist before the incident: logs that make it possible to reconstruct what was said, a defined way to correct things with the customer and a configuration change to prevent a repeat. Without auditable logs, none of these steps is possible.

How often should the agent's behavior be evaluated?

Continuously. A fixed set of test cases run periodically, plus human review of a sample of real conversations, is the minimum setup for detecting degradation before the customer does.