AI customer service with a reviewable trail, not a pretty demo

Imagine a Saturday at eleven at night. A customer writes to the assistant of their insurer, their bank or their store: "Has my payment been applied yet? I see a charge I don't recognize." The assistant answers kindly, in well-written language and with complete confidence: "Your payment is being processed, don't worry." It did not query the collections system, because it has no access to it. It answered with what it knew about the subject in general. On Monday, the customer calls their account executive and repeats everything from the beginning.

That scene is not a failure of the language model; it illustrates a design risk: an assistant can answer fluently and still lack the access, the permission or the context needed to resolve a real case. A demonstration, with its clean scenario, rarely exposes that risk.

This article is for whoever answers for customer service, operations, technology or compliance at a bank, a fintech, an insurer, a retail chain or a regulated company. It defends one idea: an AI assistant that serves customers around the clock can resolve, with control, when at least five capabilities exist before it is switched on, and if you can show an auditor or a customer what it did, with what data and why.

Why assistants stay at the demo stage

A demonstration works because the scenario is clean: a test customer, three rehearsed questions, no real system in the way. What happens afterwards, in an operation with decades of accumulated systems, has two frequent ways of failing.

The first: the assistant does not touch the real systems. It answers about policies, opening hours and frequently asked questions, but it cannot query a balance, a claim status, a policy or an order. When the customer asks about their case, the assistant can only apologize or transfer them. It becomes an FAQ search engine with good diction.

The second is more dangerous: it touches the systems, but without control. Someone gives it a generic user with broad permissions "so that it works," or connects a temporary access that stays forever. The assistant can now query and act, but no one can say precisely which data it accessed, on whose behalf, or who authorized that action. In a demonstration that goes unnoticed. In a complaint before the authority, it does not.

The market data points in the same direction, with a methodological caveat. Gartner data: in a survey of 5,728 customers conducted in December 2023, Gartner reported that only 14% of customer service and support issues were fully resolved in self-service; for those customers described as "very simple," the figure was 36% [3]. It is a consumer survey, not a baseline for Mexico or for any specific sector; use it as a signal. The figure distinguishes between answering and resolving; it does not by itself demonstrate the cause of each failure. For cases that require querying current information or starting a procedure, the committee should verify which data and actions the assistant is authorized to use.

What one that does resolve needs

When an assistant stops being a demonstration and starts to operate, it needs five capabilities. Four are technical and one is about process.

1. Identity: knowing who it is talking to and on whose behalf it acts

Before showing any data, the assistant must know that whoever is writing is who they say they are, and with what level of confidence. The level of trust is not determined by the channel alone: it should be defined according to the available signals and the risk of the action. A conversation started on WhatsApp is not automatically equivalent to an authenticated session with the controls your organization has defined. The useful rule is that the assistant does not raise by itself the level of trust: if the query is about a balance or a change of details, it asks for a verification that matches the risk, and if it is not completed, it does not proceed. The same applies in reverse: the assistant itself must have an identity of its own in your systems, not a person's shared credential.

2. Permissions: the minimum, for the specific

A service assistant does not need access to the whole system; it needs to query the status of an operation for the customer who has already been identified, and perhaps start a limited procedure. That difference, between "can see everything" and "can do these three things for this customer," is what separates a manageable risk from one that a risk committee would find hard to accept. Each action must be defined in advance, with a limited scope and, where possible, with the ability to be reversed.

3. Customer data: only what is necessary, and in view of the data subject

This is where the law comes in, as seen below. The underlying idea is operational: the more personal data passes through the assistant, the more surface there is to protect. It is advisable to know which data it queries, for what purpose, where it is processed, which providers are involved and how long the conversation is retained.

4. Log: being able to reconstruct any conversation

This is the capability that is most underestimated and that weighs most when something goes wrong. For each interaction it matters to be able to reconstruct: who asked and how they were verified, which data was queried, what the assistant answered, which action it executed, which version of the instructions and of the model was active and when it happened. A log that only stores the text of the conversation is not enough; the one that works also records what the assistant did in the systems. And it must be protected against tampering, because a log that someone can edit is not evidence.

5. Handoff to a human: leaving in time, with context

The assistant must know when it should not continue: a formal complaint, an upset customer, a case outside its scope, a doubt it cannot verify. And when passing the case on, the person must receive the necessary and relevant context to resolve the case (what has already been verified, what was queried and the history that can be justified), so that the customer does not have to repeat themselves. A good handoff to a human is not a failure of the assistant; it is part of the control. An assistant that never escalates tends to be an assistant that answers what it does not know.

What the new personal data law says

The Ley Federal de Protección de Datos Personales en Posesión de los Particulares (the Federal Law on the Protection of Personal Data Held by Private Parties) in force today is a new law: it was published in the Diario Oficial de la Federación (DOF, Mexico's official gazette) on March 20, 2025, replaced the 2010 one, and its current text includes a reform of November 14, 2025. The authority that enforces it is now the Secretaría Anticorrupción y Buen Gobierno (the Ministry of Anti-Corruption and Good Governance) [1]. Five points of the text matter to whoever operates an AI assistant. We summarize them below; how they apply to a specific flow, channel and sector should be validated with your legal and compliance departments.

• Privacy notice in electronic channels (art. 16). When data is obtained through an electronic medium, the notice must be given in its simplified form, with the basic information and the site where the full notice can be consulted. If personal data is collected in a chat or on WhatsApp, validate with your legal department how the simplified notice and access to the full one are made available in that flow, and include them from the first contact [1].
• Purpose (art. 11). Processing must be limited to the purposes in the notice; for a different purpose, consent must be obtained again. If you plan to reuse conversations to train or improve the assistant, check whether your notice provides for it [1].
• Security and confidentiality measures (arts. 18 and 20). Administrative, technical and physical measures are required against loss, alteration or unauthorized access, proportionate to the risk and to the sensitivity of the data, along with controls so that those involved in the processing keep confidentiality [1]. The minimum permissions and the log from the previous section are the practical version of this requirement.
• Automated decisions (art. 26, section II). The data subject may object, on legitimate grounds, to processing when it is automated, produces unwanted legal effects or significantly affects their interests, rights or freedoms, and is intended to evaluate, without human intervention, certain personal aspects or to analyze or predict, among others, their economic situation, reliability or behavior; the law excepts cases where the processing is necessary to fulfill a legal obligation [1]. If the flow could produce unwanted legal effects or significantly affect a person through automated processing, review the right to object with your legal department. Also define, as a risk control, which decisions require human review.
• ARCO rights and deadlines (art. 2, secs. VII and VIII; arts. 22 to 31 and 58). The data subject may request access, rectification, cancellation or objection (ARCO rights). The controller must communicate its determination within a maximum of twenty days from receiving the request, and the law defines "days" as business days; it may be extended once for an equal period if circumstances justify it. Failing to fulfill a request without a well-founded reason is an infraction [1]. It is advisable that the chat identify and route a possible ARCO request to the mechanism in the privacy notice, that identity and requirements be validated (art. 28) and that the date of receipt be kept; and cancellation is not always immediate deletion, because the law provides for a blocking period (art. 24).

A note of caution: the law refers to its Regulations for several procedures, and at the time of writing the compilation of the Chamber of Deputies listed only the Regulations published in 2011, issued for the previous law [5]. So, besides this law, confirm with your legal department the regulations, secondary provisions and sector regulation in force on the date you read this; any of them may specify the obligations above.

Complaints: where the log becomes a defense

For the financial entities listed in article 3, section IX, of the law (credit institutions, multiple-purpose financial companies, popular and community financial companies, savings and loan cooperatives, credit unions and financial technology institutions), it is advisable to check whether the assistant's flow falls within the clarification procedure. The Ley para la Transparencia y Ordenamiento de los Servicios Financieros (the Financial Services Transparency and Ordering Law, art. 23) says that, for transactions and services entered into through mass-contracted adhesion contracts and up to the maximum amounts set by the authority (CONDUSEF), when a customer disagrees with a transaction, they may submit a clarification request within ninety calendar days counted from the statement cut-off date or, as applicable, from the date of the transaction or service; that the entity must acknowledge receipt, and that, once the request is received, it has a maximum of forty-five days to deliver to the customer a report with a copy of the evidence considered and a detailed account responding to all the facts raised [2]. The list of financial entities in that law does not include insurers: if you are an insurer, your complaint process is set by the Law for the Protection and Defense of Financial Services Users (its art. 50 Bis requires every financial institution, insurers included, to have a specialized unit for inquiries and claims, which must receive them through any means that makes receipt easier and answer in writing within no more than thirty business days) and by insurance regulation [4]. The nuances of each type of complaint and of each authority come in the sector regulation; your compliance area should confirm them.

What matters here for an assistant is a practical consequence. Not every chat message is, by itself, a formal clarification request. If the channel is enabled to receive one, or the flow identifies and routes the request, the conversation may form part of the case file and preserve useful evidence. If the assistant said something incorrect, or if the customer said it and no one recorded it, the institution reaches the report without evidence. A complete, searchable log turns that conversation into an input for responding; one that does not exist turns it into a gap.

That is why the committee's question is not "how many contacts does the assistant contain?" It is: what happens when a contact becomes a complaint? CONDUSEF's provisions on specialized units already require, through any means of receipt, electronic included, acknowledging receipt, assigning a reference number and stating the response time, and keeping the records available to the Commission for two years [6]. Those provisions require acknowledgment of receipt, a reference number and a response time, and keeping records and resolutions for two years. The rest is an internal service objective, which should be set and tested in control exercises: that it is recorded with a reference number, date and time, that it passes to the right person without losing what was discussed and that someone can retrieve it in minutes, not days. It weighs as much as any containment percentage.

Scenario (illustrative; it corresponds to no real client. Complaint deadlines in insurance are set by other regulation; the principle, reaching the file with evidence, is the same). A mid-sized insurer enables an assistant to report claim status over WhatsApp. A policyholder asks about their claim and receives "under review, nothing pending." Two weeks later they file a complaint: they say a document was requested from them and no one told them. If the insurer can reconstruct which status the assistant queried, at what time and with what answer, it has the elements to cross-check the case and support its response. If it only keeps a generic summary, the file depends on the memory of the policyholder and of their account executive.

Five questions for your next committee

1. With what identity does our assistant act in each system? If it is a shared account or one with broad permissions, the first finding is already made.
2. Can we reconstruct any conversation in minutes? Who it spoke with, which data it queried, which action it took, which version was active. Test it with a randomly chosen conversation.
3. Where do the personal data that pass through the assistant reside and which providers are involved? Does our privacy notice cover that purpose? Does each provider act as a processor or as a third party, and is that documented? How would we detect and notify a security breach (art. 19)?
4. When a conversation becomes a complaint or an ARCO request, who receives it, with what reference number and in how long? How does it arrive with all the context?
5. If the assistant gives wrong information, who is responsible, how is it corrected and how is it documented?

The more answers are "I don't know," the more likely it is that what is missing is not a better model, but connecting and governing what already exists.

Before approving a use case

To compare proposals, ask for evidence for the specific case you want to enable: the data and providers involved; the actions allowed and the ones excluded; a sample of the log and of the handoff to a person; the business owner; and the acceptance criterion. That way the committee compares scope, risk and evidence, not just a demonstration.

Where to start this week

You don't need to start a broad project. Choose a sample conversation whose access is authorized and controlled, ideally with the data minimized, and ask your team to reconstruct, on paper, these five elements: how the person was verified, which system was queried and with what permission, what the assistant answered, where it was recorded and who would have found out if it had been a complaint. Document the gaps you find and prioritize them by risk: whatever cannot be reconstructed tells you where to start.

Do the same exercise with a conversation that the assistant handed to a person: did all the context arrive?

What Hábil does

Hábil works right where an assistant stops being a demonstration: connecting AI with the systems that already operate, with identity, limited permissions, a record of what it does and handoff to a person when appropriate. Hábil AI is the offering for connecting AI capabilities to an organization's systems; Nova is the virtual assistant oriented to customer service. When the case requires processing on infrastructure under your organization's control, the scope, providers and controls must be defined for that case. To decide who gets into each system, see Control who has access; to join your channels and systems, Unify your operations and your channels.

The first assessment conversation is at no cost: you leave with a first reading of the map of your integrations and of the points where money, time or evidence is probably being lost. Write to us on WhatsApp.