Chatbot, copilot and agent are not the same thing. A chatbot answers within a defined scope; a copilot drafts responses for a human who decides; an agent can query systems and execute actions on its own. The architecture should be chosen based on impact and reversibility: the higher the autonomy, the more essential verified identity, permissions, validation, oversight, audit trails and human escalation become.
Comparison
Before deciding what to build, it helps to map each architecture against its function and its level of risk:
| Architecture | Function | Risk | Suitable use |
|---|---|---|---|
| FAQ / chatbot | Answers information requests | Low / medium | Frequently asked questions |
| RAG | Answers with sources | Medium | Policies and product info |
| Copilot | Assists a human agent | Medium | Summaries and drafts |
| Agent | Executes actions | High | Bookings or bounded changes |
The general rule is simple: don't grant a system write access if it only needs to inform.
Design by intent
The first step isn't choosing technology, but classifying the contacts the channel will receive:
- Information.
- Status.
- Change.
- Complaint.
- Payment.
- Cancellation.
- Emergency.
- Data rights.
Each intent carries its own data, its own authentication requirement, its own action and its own escalation path. The model must not improvise outside that catalogue.
Transparency
Article 50 of the EU Artificial Intelligence Regulation (AI Act) requires informing people when they interact with an AI system in the applicable cases, unless this is obvious from the context. That information must appear at the start of the conversation, not buried in a legal notice.
It must state:
- That artificial intelligence is involved.
- The purpose of the interaction.
- Its limitations.
- That the conversation may be recorded.
- How to reach a human.
- The applicable privacy policy.
Data protection
The chat may receive health data, account or ID numbers, attached documents or third-party data. Users should be warned not to share unnecessary information, and filtering and data minimisation should be built into the system by design.
It's necessary to assess:
- Purpose and legal basis.
- The system provider.
- Sub-processors.
- The processing region and any international transfers.
- Whether the data is used for training.
- The retention period.
- Individuals' rights.
- Whether a data protection impact assessment (DPIA) is required.
A bot must recognise requests to exercise data rights, or route them to a human, and must stop sending marketing communications once a user has objected.
Knowledge and RAG
Answers must be based on authoritative sources with identifiable dates and versions. If there is no evidence to support an answer, the system must decline to respond.
Public content, contracts and each customer's data must be kept separate, with the corresponding permissions applied before retrieving any information, not afterwards.
Authentication
Before showing the status of a case or executing a change, the user's identity must be verified with factors proportional to the risk. Knowing a name or order number is not always sufficient proof.
Authentication is not delegated to the language model: it is the company's identity system that hands over already-authorised context.
Tools
Each tool made available to the system must define:
- A specific operation.
- An input and output schema.
- An associated permission.
- A usage limit.
- Idempotency.
- An approval mechanism.
- An audit log.
Looking up an order, changing an address and processing a refund are distinct capabilities and must be treated as such.
Human escalation
Escalation to a human must be triggered by:
- An explicit customer request.
- Low confidence in the answer.
- A repeated query.
- Signs of frustration.
- Situations of vulnerability.
- Complaints.
- Exceptions outside the catalogue.
- A tool failure.
- High-impact cases.
The person who receives the case must have a summary, the data already confirmed and the steps taken so far. The customer should not have to repeat the entire conversation.
Quality
Metrics must cover several layers:
| Layer | Metric |
|---|---|
| Resolution | Case resolved correctly |
| Faithfulness | Answer backed by a source |
| Safety | Prohibited data or actions avoided |
| Experience | Drop-off and escalation |
| Operations | Latency and availability |
| Business | Cost per valid case |
"Deflection" — the percentage of cases that never reach a human — is not a success on its own if it masks customer frustration or incorrect answers.
Test set
Before putting any architecture into production, it should be validated against a test set that includes:
- Ordinary questions.
- Ambiguous cases.
- Outdated rules or terms.
- Sensitive data.
- Complaints.
- Exercise of data rights.
- Attack attempts.
- A tool failure.
- Customers in vulnerable situations.
- No available answer.
Security
The most relevant threats to these systems include:
- Prompt injection.
- Data extraction.
- Identity impersonation.
- Discount abuse.
- Fraudulent returns.
- Malicious links.
- Unlimited resource consumption.
Rate limits, input validation, per-tool permissions and continuous monitoring are applied against them. The instruction text (prompt) itself is not a sufficient security control.
Copilot for human agents
This is usually the safest first step for introducing AI into customer service. It can summarise the conversation, find the right source and draft a response, but a human reviews it before it is sent.
Both the accuracy of its suggestions and the team's degree of reliance on them should be measured. The team must always retain the ability to disagree with the copilot.
90-day plan
Days 1-30
Defining intents, risks, knowledge sources and a starting baseline.
Days 31-60
Building the chatbot or copilot, testing, privacy review and escalation design.
Days 61-90
Production pilot, metrics measurement and activation of bounded actions.
Common mistakes
- Choosing an "agent" architecture as a trend, without justifying it by actual risk.
- Not having an intent catalogue.
- Hiding that it is an AI system.
- Asking users for excessive data.
- Answering without sources to back up the information.
- Authenticating based only on what is said in the conversation.
- Granting the system too many tools.
- Not planning for escalation to a human.
- Measuring only case containment, not actual resolution.
- Storing conversations without a defined retention period.
Checklist
- Architecture chosen by risk, not by trend.
- Intent catalogue defined.
- Transparency about AI use.
- Data protection reviewed.
- Knowledge sources identified.
- Authentication proportional to risk.
- Minimum necessary tools.
- Human escalation defined.
- Evaluation and test set.
- Security and cost under control.
Frequently asked questions
Chatbot or agent?
Start with a chatbot backed by RAG or with a copilot. Reserve the agent for bounded, reversible actions only.
Must it disclose that it is AI?
Yes, in the cases covered by Article 50 of the AI Act, unless it is obvious from the context, and always clearly.
Can it handle complaints?
It can receive and classify them, but complex cases need human intervention and full traceability.
Summum IA can design the architecture, the RAG system, the tools, the evaluation and the escalation path for the customer service channel.