A notice hidden on a policy page cannot explain who, or what, is responding inside a live conversation. Customers need this information at the moment of interaction, in language they can understand, and as part of an experience that helps them decide what to do next.
Service teams therefore need a practical way to present approved disclosures, support accessible and localized experiences, manage escalation, and retain evidence that their controls worked as intended.
Article 50 of the EU AI Act establishes transparency requirements for certain AI systems. These include informing people when they interact directly with AI, subject to the regulation’s conditions and exceptions. The information must be clear, distinguishable, accessible, and provided no later than the first interaction or exposure. Organizations should confirm the requirements applicable on their implementation and publication dates, including amendments and official guidance.
Pega Customer Service provides building blocks for this operational challenge. Digital Messaging supports bot interaction flows and escalation to customer service representatives. Pega workflows and case management can help organizations assign work, apply approved rules, and retain proportionate evidence. Compliance still depends on the organization’s role, use case, implementation, and configuration,
This article is for customer service leaders, solution architects, compliance professionals, product owners, and Pega practitioners.
What the article covers
- How to place approved AI disclosures inside the customer interaction
- How transparency affects the final customer’s experience
- How to design a purposeful handoff from automation to human service
- How to assign ownership and retain proportionate evidence
Keep legal requirements and operational controls distinct
The first step is to separate legal requirements from service-design recommendations.
Article 50 addresses several forms of transparency. For customer service, two are especially relevant: informing people who interact directly with AI and informing people exposed to an in-scope emotion-recognition or biometric-categorization system. The exact requirement depends on the system and whether the organization acts as provider or deployer.
Human escalation, queue capacity, context transfer, and handoff monitoring are operational controls discussed here. Whether a human route is legally required depends on the laws, contracts, sector rules, and specific circumstances applicable to the service.
Why this matters to the final customer
From an organization’s perspective, AI transparency can appear to be a disclosure requirement. From the customer’s perspective, it is a much more immediate experience.
The customer wants to understand:
- Am I interacting with a person or an AI system?
- What can this assistant actually do?
- Is its answer authoritative, or should I verify it?
- Why is it asking me for this information?
- Can I reach a person if the conversation reaches a boundary?
- Will I need to repeat everything if the interaction is transferred?
When these questions are not addressed, the experience can become confusing.
A customer may assume that a response came from a human representative. They may provide information without fully understanding the nature of the interaction. They may follow an incomplete answer, reach the chatbot’s limits, and then need to restart the entire conversation through another channel.
This is not only a regulatory design issue. It is also a service and trust issue. Transparency helps customers form the right expectations before relying on the interaction.
The customer journey at a glance
The journey on the right is not created by a disclosure alone. It requires disclosure, service design, workflow, escalation, localization, testing, ownership, and monitoring to work together.
A personal observation from customer-facing chatbots
I have experienced this gap myself when interacting with customer-facing chatbots in Italy.
In some interactions, it was not immediately clear whether I was speaking with an automated system or a person. The conversation only revealed the system’s limitations after several exchanges. When the chatbot could not complete the request, the route to human assistance was either difficult to find or required starting again through another channel.
I do not present these individual experiences as evidence that a specific company was non-compliant. They are a practical reminder that implementation gaps are visible to customers long before they appear in an audit report.
A small omission at the beginning of a conversation can affect the entire experience. Clear identification, an understandable explanation of purpose, and a well-designed handoff can reduce ambiguity and customer effort.
This is why transparency should be treated as part of the service journey rather than as legal text added around it.
Design transparency as part of the journey
The following steps illustrate how organizations might configure Pega capabilities within a broader transparency framework.
A useful transparency pattern should answer three questions:
- What must the customer know?
- When must they know it?
- What happens if they want or need human help?
1. Disclose clearly
Start with the first interaction.
Pega Customer Service supports configurable bot interaction flows. An organization might configure approved disclosure wording at the beginning of that flow, based on its requirements and implementation design.
For example:
You are chatting with Acme’s AI virtual assistant. It can answer service questions and start requests. To contact our service team, select Talk to a person.
This wording is illustrative. Legal, accessibility, privacy, compliance, and customer service teams should approve the final language. Voice experiences need an equivalent, channel-appropriate approach.
Analytics also require careful classification. In Pega Customer Service, Conversational Analytics evaluates completed voice, digital messaging, and email interactions as part of wrap-up. It uses interaction transcripts to produce metrics that include customer and agent sentiment.
Teams should document the inputs, purpose, people affected, and intended use of the output, and then determine whether additional controls apply. Where analytics involve employees, organizations should conduct a separate legal, privacy, and workplace review before enabling or using the relevant metrics.
2. Set the customer’s expectations
Identification alone may not create a useful customer experience.
Where appropriate, the opening interaction should also explain:
- What the AI assistant is intended to do
- What it cannot decide or complete
- How the customer can request human support
- Whether the interaction can create or update a service request
- Where the customer can find the relevant privacy information
The objective is not to place a long legal notice inside the chat. It is to give the customer enough information to understand the interaction and make an informed choice about how to continue.
3. Hand off with purpose
Pega Customer Service supports self-service and escalation from a chatbot to a customer service representative. Organizations should configure escalation as part of the service design rather than treat it as an improvised exception.
For example, organizations might configure escalation around:
- A direct customer request
- Repeated failure to understand the customer’s intent
- Failed identity verification
- A sensitive service case
- A policy boundary requiring human judgment
- Insufficient information to continue safely
Implementation teams should validate the handoff for their Pega release, channel, licensing, and configuration.
They should confirm:
- What context reaches the representative
- How the work enters the queue
- Who owns the request
- Whether the customer must repeat any information
- What happens outside normal service hours
- How failed or abandoned handoffs are managed
Organizations may also choose to monitor completed escalations, waiting time, abandonment, repeat contact, and failed handoffs. These measures indicate whether the control works for customers, not simply whether an escalation option appears.
4. Assign ownership and capture evidence
Organizations can use Pega case management to design a pattern that assigns transparency reviews, approvals, testing, and remediation to named owners.
Pega’s case-management and auditing capabilities provide building blocks. The control design and completed implementation remain the organization’s responsibility.
Illustrative design pattern, not an out-of-the-box compliance package
An AI transparency control case might hold:
- System and business owner
- Market and channel
- Approved notice
- Language versions
- Accessibility evidence
- Analytics assessment
- Escalation design
- Approval history
- Training requirements
- Test results
- Incidents and remediation
- Review dates
A customer journey in practice
Consider an energy provider using Pega Customer Service:
- The customer opens Web Messaging Chat.
- The bot flow presents the approved AI disclosure before answering.
- The disclosure explains what the assistant can do and provides a visible path to the service team.
- The customer asks about an unusually high bill.
- The virtual assistant starts a billing inquiry.
- The customer selects Talk to a person.
- The system escalates the interaction to a customer service representative.
- Before go-live, the product team validates what context transfers and how the case continues in the selected release and channel configuration.
- The transparency control case links the approved wording, accessibility review, test results, owners, and review date.
- The organization monitors disclosure and escalation outcomes so that teams can identify failures and assign remediation.
The result is more than a banner. Disclosure, customer choice, escalation, ownership, and evidence operate as one service pattern.
A focused route to readiness
For an existing Pega Customer Service implementation, one practical approach is to:
- Inventory customer-facing AI interactions.
- Classify each use case with legal and compliance stakeholders.
- Review what the customer sees at the first interaction.
- Confirm that the wording is clear, accessible, and localized.
- Validate the human-support route where the organization has chosen, or is required, to provide one.
- Test what information and work transfer during escalation.
- Identify the minimum evidence needed to demonstrate that the control operated.
- Assign an owner and a review date.
This is author guidance, not a prescribed Pega product procedure.
An organization new to Pega can begin with one priority journey and one channel. Pega Blueprint can help business and technology teams map disclosure, escalation, ownership, and evidence requirements before implementation. Starting with a focused journey allows the organization to validate the pattern before expanding it.
Move transparency from policy to practice
Pega Customer Service provides messaging, workflow, case-management, and escalation building blocks that organizations can configure as part of a broader transparency framework.
The organization remains responsible for classifying its AI systems, determining its obligations, approving the customer experience, and validating the completed implementation.
Important: This article is provided for informational purposes only and reflects an illustrative implementation approach using Pega capabilities. It is not legal advice, regulatory guidance, or a statement of compliance. Organizations remain responsible for determining their obligations under applicable laws and regulations, including the EU AI Act, and should seek advice from qualified legal and compliance professionals.
Discuss with the Expert Circle
- Where have you seen AI disclosure handled well inside a customer service journey?
- Which handoff failure creates the greatest customer effort in your implementations: finding the human route, entering the queue, transferring context, or continuing the service case?