Roles and Approvals: Who May Change What in the Assistant

An assistant on a website is rarely the work of a single person. Someone maintains the content, someone signs off prices and deadlines, someone looks after embedding and tools, someone reads the analytics. As soon as several hands work on the same assistant, a question arises that has little to do with technology and a lot to do with organisation: who may change what, who has to approve it, and who may read visitors' conversations at all? This article describes a lean role model with three levels, the four-eyes principle for the system instruction and the knowledge base, versions with rollback, the log as the team's memory, and the two mistakes that keep recurring in small teams: shared logins and orphaned accounts.

Enlarge graphic

Labels in the illustration

• Editing
• Person A
• Approval
• Person B
• System
• Versions
• Prepare the change
• Instruction, source, price
• Run test questions
• same wording, before/after
• Check and approve
• price, deadline, promise, rule
• Sent back with questions if needed
• Previous version
• stays available
• New version goes live
• rollback creates another one
• superseded, not overwritten
• Log
• every action
• from all lanes
• Account A · change prepared · reason: new delivery time
• Account B · approval granted · after test questions
• Account C · conversation opened in plain text · owner role
• No shared login
• every line names one person

One change, two hands, one trail

Why an assistant needs several hands with different rights

From the outside, an assistant looks like a single tool: one window, one voice, one knowledge base. Behind it, however, sit different activities that rarely rest in one pair of hands. The content comes from the specialist department. Approving a price or a deadline belongs to the person who answers for it. Embedding the assistant in the website and shop is often handled by an agency or the in-house IT. And analysing the conversations falls to customer service or management. Each of these activities needs access – but a different kind each time.

In a small business, several of these hands belong to the same person, and that is not a flaw. What matters is that the responsibilities are named and that nobody holds more rights than their own activity requires. Which skills the individual responsibilities should bring is covered in the article on AI literacy under Article 4 of the AI Act. This article deals with the other side of the same question: rights, approvals and the trail both leave behind.

Three levels instead of single rights: owner, editing, read-only

Rights can be granted as a long list of individual checkboxes or as a few levels that build on each other. For a team running an assistant, levels are usually the better choice: they are quicker to assign, easier to review and harder to mix up. Each higher level contains the one below. Read-only allows insight into analytics and settings without changing anything. Editing allows changes to content, sources and the system instruction. The owner role manages the team, grants and revokes roles and decides on exporting and deleting conversations. Some teams add another level between editing and owner for technical administration; the principle stays the same.

The table is a starting point, not a rule book. More important than the exact assignment is the rule behind it: rights follow the task, not the position in the company. A managing director who only reads analytics does not need editing rights. A working student who maintains the knowledge base does not need access to conversation content. The IT-Grundschutz Compendium of the German Federal Office for Information Security (BSI) offers a yardstick for this. IT-Grundschutz is a BSI standard, not a law; its MUST requirements apply within that methodology and describe what it regards as the basis of good practice. It puts the rule above into a basic requirement:

Invitation and revocation: the life cycle of an access

An access has a beginning and an end, and both should be set deliberately. The beginning is the invitation. It goes to the person's own address, not to a shared mailbox, and it already carries the role. Whoever invites first and adjusts the role later has an account with unclear rights in the team for a while. An invitation that is not accepted should expire after a set period instead of lying around like an open door.

• The invitation goes to the person's own address, not to a shared mailbox.
• The role is set at the invitation and matches the task, not the position.
• Open invitations have an expiry date and are withdrawn once the need has passed.
• When the task changes, the role changes – downwards as well.
• Stand-ins and external service providers receive access with an end date that is in the calendar.
• Access is revoked on the last working day, not whenever someone happens to remember.

The end is the part that is often missing in practice. An employee moves to another department, an agency finishes its project, a temporary contract runs out – and the account remains, because its revocation is not tied to any process. The IT-Grundschutz states the counter-rule as a MUST requirement:

Four eyes on the system instruction and knowledge base

One sentence in the system instruction changes every answer the assistant gives afterwards. A changed price in the knowledge base is in front of a customer from the next conversation onwards. This reach is the reason for the four-eyes principle: the person who prepares a change does not approve it. The second person does not proofread but checks the statement – is the price correct, can the deadline be met, does the new rule fit the others? What belongs in a system instruction and what does not is described in the article on the system instruction and its boundaries.

The last row matters because a four-eyes principle that captures every trifle runs the risk of being circumvented. A division into classes makes sense: statements the business stands behind need approval, pure form does not. In small teams the second person does not have to sit next to you. It is enough that they can trace the change with the same test questions before and after it, before it takes effect. The subject-matter approval for prices applies to values entered into the knowledge base by hand; prices that come automatically from the checkout or the merchandise management system already carry their approval in the source. Who is responsible for which content and how often it is reviewed is set out in the article on keeping the knowledge base up to date.

Versions and rollback: keeping changes reversible

Four eyes prevent many mistakes, but not all of them. That is why every approval needs a way to be withdrawn. This works when every change creates a version of its own – with time, account and reason – and supersedes the previous version instead of overwriting it. Approval becomes simpler as a result: the second person compares two versions instead of rereading an entire text. And a rollback to an earlier version is itself a new version, so it remains traceable too; what it restores is the state, not the answers already given in the meantime. A version usually records:

• Time and personal account of the person who made the change
• Reason for the change in one sentence
• Area affected: system instruction, source, tool or approval rule
• Who approved it, and when
• The test questions used to check before and after

Rollback raises a question of its own: who may trigger it? A deliberate exception to the four-eyes principle pays off here. Rolling back to the most recently approved version returns to a state that has already been checked. As a rule, the editing role may also trigger it without a second approval, so that a mistake made in the evening does not keep working until the next morning. How a switch between versions runs without interrupting the customer dialogue is described in the article on updating an assistant without downtime.

The log: who changed what, and when

A log is the team's memory. It answers two kinds of questions. The first is operational: since when has the assistant answered the question about delivery times differently, and who changed it? The second concerns data protection: who accessed which conversations, who exported, who deleted? For the second kind, accountability provides the reason: the General Data Protection Regulation requires the controller not only to comply with its principles but to demonstrate compliance:

The provision does not name a particular means for this demonstration; a log is an obvious way to do it. A log usually includes:

• Time and the personal account that triggered the action
• Type of action: change, approval, rollback, invitation, revocation, export, deletion
• Object: which assistant, which source, which conversation
• No conversation content in the log itself – it refers, it does not copy
• Entries that cannot be altered afterwards

The fourth point is easily overlooked. A log that records the wording of the conversations it opens becomes a second conversation archive itself and then needs retention periods of its own. It is enough to record that a conversation was opened, and by whom. Anyone who has to explain to data subjects or the supervisory authority how conversations were handled finds the basis for it in the log. Which details a response about chat history contains is described in the article on the right of access under the GDPR.

Conversation content only for those who need it

Conversations with an assistant contain more than one might expect: names, phone numbers, order numbers, complaints, occasionally health details or family circumstances. This content is personal data, and the principle of data minimisation applies to it – not only when it is collected, but also when it is accessed in-house.

In practice this means: analysis works with aggregated topics, open questions and handover reasons, not with the wording of individual conversations. It needs no names to show which question remained without a reliable answer; what an analysis by topic looks like is shown on the page about conversation analytics. Even whoever continues a conversation or resolves a complaint can usually work with a view in which names, addresses and numbers are masked. If the case does need the plain text, the owner role opens it and states a reason – and that access is an event recorded in the log. The default setting explicitly counts. Article 25(2) GDPR requires measures for ensuring that, “by default, only personal data which are necessary for each specific purpose of the processing are processed”, and continues: “That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility.” Applied to the team, this suggests opening conversation content by default only to those who need it for their task.

Export and deletion belong to the same class. An export moves conversations out of the protected system into a file that can be forwarded; a deletion cannot be undone. Both should be reserved for the owner role and leave a log line behind. How long conversations are kept at all is a separate decision, covered in the article on retention periods for chat logs.

Common mistakes: shared logins and orphaned accounts

A typical mistake in small teams is also the most convenient one: a single shared login for everyone, often under the business's general address. It saves inviting people, but it devalues almost everything in this article. The log then only records that the shared account changed something. A four-eyes principle cannot be demonstrated, because both pairs of eyes use the same account. And the access of a person leaving the company cannot be revoked without changing the password for everyone. Against this, the IT-Grundschutz lists as a basic requirement:

A fixed date helps against all four. Once a quarter, the team list is compared with the current staff list, every role is checked against the actual task and every account that has not been used for some time is questioned. The IT-Grundschutz provides for such a review of documented rights and names the yardstick: the documentation must be checked regularly as to whether it reflects the actual state of the permissions granted. For accounts with far-reaching rights, usually the owner role, a second login factor is worthwhile as well.

What XICBOT provides for write paths and trails

Some of these rules can be solved organisationally, others belong in the system. In XICBOT, all writing actions of the assistant run through exactly one execution point, which checks role, confirmation by the visitor and tenant membership before anything is carried out; no tool writes around it. This confirmation concerns the individual action in the conversation, not the approval of content changes within the team. Which actions an assistant may trigger at all, and which need a confirmation first, you define via tool control. For conversation data, XICBOT keeps an event log: every plain-text access by your team, every export from the admin area and every deletion, including one triggered by a visitor, is logged. What changes in the product itself is listed separately in the public changelog.

Which roles your team needs, who approves the system instruction and the knowledge base and how revocation is tied to your exit checklist is a question of your organisation, not of the product. It can be agreed together during setup. If you would like to know in advance what this could look like for your business, get in touch.

Frequent questions