Your customer data and AI: what goes where (Peru + RGPD), in plain words

The journey of one message, step by step

Picture a visitor typing into the widget on your site: "Hi, I'm Juan Pérez, my order 4821 never arrived".

That message takes a trip. It is worth understanding, because every stop has its own rules.

Four stops. Most of the confusion comes from mixing them up. Let's go one by one.

• The visitor's browser. Only the text they typed goes through. Nothing else.
• Your server (or ours, depending on the setup). This is where the logic lives. This is where the keys to your systems are.
• The AI model. It only receives what it needs to answer that one question.
• The logs. A copy of the conversation gets stored, for debugging and improving.

Credentials never touch the browser

This is the first thing I check in any setup, and where I see the most mistakes in inherited projects.

The keys to your systems (your CRM key, your payment gateway token, your database password) live on the server, never in the browser or in the widget.

Why does this matter so much? Because anything that reaches the browser, the visitor can see. Just open the developer tools, two clicks. If an API key travels to the browser, anyone can read it and use your account.

That is why the chat widget knows nothing secret. It only knows how to send the user's message to your server and show the answer. All the sensitive parts (querying your CRM, reading an order's status, writing to your database) happen on the server side, where the visitor cannot reach.

Simple rule: if you could paste a data point into an email to a stranger without worrying, it can go to the browser. If not, it stays on the server.

The model only sees what it needs to answer

Second point, and the one that surprises people most: the AI model does not need to see your whole database.

When the agent looks up order 4821, my server queries your system, pulls the status of that one order, and passes the model only that. It does not send the other 9,800 orders. It does not send the customer list. It does not send card numbers.

This is called minimization. It is the most useful idea in this whole conversation, and it boils down to one sentence: the agent sees just enough to do its job, nothing more.

In practice this means concrete decisions:

Why do I keep pushing on this? Because the less that travels, the less there is to protect. A data point that never leaves your server cannot leak anywhere else. The safest way to protect a data point is not to move it.

• The agent receives "order 4821: in transit, arrives the 19th", not the customer's full profile.
• If it asks about an invoice, it sees the amount and the date, not the saved payment method.
• Sensitive data (national ID, health data, banking data) does not travel in the clear unless there is a real reason to answer.

What gets stored in the logs, and who can read them

Third point, the one most often forgotten.

Almost every serious agent stores the conversations. It is necessary: to understand why it answered badly once, to improve, sometimes to meet an accounting or legal obligation. But that record is exactly where personal data piles up.

So the right questions are not "is it stored?". They are these:

From my experience, log access control is where the chain breaks most easily. You can have a flawless server and still leave the conversations in a dashboard that opens for anyone with the link. Security is the whole chain, not the strongest link.

• Who can read the logs? It should be a short, named list, not "the whole team".
• How long are they kept? A defined window, not "forever just in case".
• Can they be deleted on request? If a customer exercises their right, you need to be able to find it and remove it.

The legal frame: Ley 29733 in Peru, RGPD for the EU

So far I talked about how it works. Now, the frame. And here I need to be very clear about something, I say it below in bold, do not skip it.

In Peru, personal data protection is governed by Ley 29733 and its regulation. The underlying idea matches what I already described: ask only for what you need, have a basis to process the data, inform the person, and give them control over their information.

If your agent serves visitors from the European Union, the RGPD (the European regulation) comes into play too. It applies based on the person's location, not on where your company sits. A Peruvian business serving customers in Spain falls under both frames.

The two share the same practical principles:

The good news: a well-built setup, with minimization and log control, already puts you close to compliant, under both frames. Clean architecture and the law point the same way.

• Minimization. Process only the data you need for the stated purpose.
• Purpose. Use the data for what you said, not for something else later.
• Rights of the person. Access, correct, delete their data.
• Security. Protect what you store, with controlled access.

This is not legal advice. Seriously.

As promised, in bold: nothing in this article is legal advice. I am the one who builds the agent and understands the technical flow of the data, not your lawyer.

What I am telling you here is how the technical part works and which principles I respect when building. What the law requires in your specific case depends on your sector, on your data, and on who you serve. A clothing store is not the same as a clinic or a fintech. A clinic handles health data, a fintech handles banking data, and there the rules get much stricter.

To know what you have to comply with, consult your own legal advisor, someone who knows Ley 29733 (and the RGPD if you serve the EU). I take care of making sure the architecture does not put you in avoidable trouble. Your lawyer takes care of your specific obligation. They are two different jobs and you need both.

The three questions you can actually ask today

You do not need to be technical to audit your own agent. With these three questions to whoever built it for you, you already see a lot:

If all three answers are clear and specific, you are in good shape. If they are vague, there is your next conversation.

In the end, all of this comes down to one idea: the safest data point is the one that never moved, and the agent should only see what it needs to answer. The rest is implementation detail, important, but detail.

If you want to review how your case is set up, or you have a specific doubt about your data flow before putting an agent into production, write to us and we will look at it together. But the deeper question, the legal one, that one always comes with your advisor.

• Do the credentials live only on the server? The right answer is yes, always.
• What exactly does the model receive in each answer? They should be able to tell you precisely, not in general terms.
• Who reads the logs, for how long, and can they be deleted? Three concrete answers, not a "it's protected".