跳到正文
DEV Community· mdodeja·· 4 小時前AI 評分59

員工專用 AI 助理:內部聊天機械人是否須按《歐盟 AI 法案》第 50 條作出披露?

Staff-only AI assistants: does an internal chatbot need an Article 50 disclosure?

AI 導讀

指南指出,《歐盟 AI 法案》第 50(1) 條涵蓋直接與員工互動的 AI 系統,但若其 AI 性質在使用情境中明顯,毋須另行披露。以同事身份發訊息的機械人,以及仿真實同事、可能被視為真實內容的 AI 聲音或影片,則須特別處理;第 50(4) 條對 AI 生成文本的披露要求只涵蓋以告知公眾公共利益事宜為目的而發布的文本。

正文

This guide was drafted by an AI agent from the primary sources linked at the bottom, and has not been reviewed by a lawyer. It is general information, not legal advice. The original is at https://mdodeja.github.io/eu-ai-act-article-50-guide/guides/staff-only-ai-assistants-article-50.html.

Short answer. Article 50(1) is not limited to customers. It covers any AI system meant to interact directly with natural persons, and employees are natural persons. In practice most internal assistants are already obviously AI (staff open a tool called "AI assistant"), and the Act exempts that case. The internal cases that still need care are bots that pass messages as if from a person, AI voice or video that resembles real colleagues, and the separate AI literacy duty in Article 4.

The rule does not stop at customers

Article 50(1) says providers must design AI systems "intended to interact directly with natural persons" so that the people concerned are informed they are interacting with an AI system. Nothing in it limits the duty to consumers or the public. A staff member asking an HR chatbot about leave is a natural person interacting with an AI system.

There is also no general exemption for internal use. "Putting into service" includes supplying an AI system for your own use in the EU (Article 3(11)), so a company that builds an assistant for its own staff can be its provider as well as its deployer.

Why most internal assistants are already covered

The same paragraph has a built-in exception: no disclosure is needed where the AI nature is obvious "from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use".

Most internal tools meet that easily:

Internal tool Obvious it is AI? Comment
Staff open an app or tab called "AI assistant" or "Copilot" Yes The name and the way it is reached tell them
IT helpdesk chat that greets staff as "the AI helpdesk assistant" Yes The greeting is the disclosure
HR chat in the intranet with a person's name and photo, no AI mention No Staff could think HR is replying
Bot that posts in team chat or email under a colleague's name No It looks like a message from a person
Ticket system where an AI drafts and sends replies in an agent's name No Unless the reply or the system says so

The safe pattern is the same as for a customer chatbot: name the tool as AI and say so in the first message. It costs one line, and it removes the argument about what is obvious.

Who carries the duty

Under Article 50(1) the duty is the provider's: whoever builds the assistant, or has it built and puts it into service under its own name. For an off-the-shelf tool such as an enterprise chatbot product, that is the vendor, and those products usually present themselves as AI. For an assistant your own team built on a model API, your company is likely the provider, so the disclosure is yours to design in.

The internal cases that do need a label

AI voice or video of real colleagues. Article 50(4) requires deployers of an AI system that generates or manipulates image, audio or video content constituting a deep fake to disclose that the content is artificially generated or manipulated. Unlike the text rule in the same paragraph, that sentence does not depend on the content being published to the public. An AI avatar of your CEO in an onboarding video, or a cloned voice of a trainer, resembles real persons and could pass as authentic, so label it. The deep fake guide covers the definition.

AI-written internal text. The Article 50(4) text duty covers text "published with the purpose of informing the public on matters of public interest". Internal memos, policies and newsletters to staff are not published to the public, so that duty does not apply to them. Labelling them can still be good practice.

Emotion recognition at work. Article 50(3) requires deployers of emotion recognition systems to inform the people exposed. Separately, Article 5(1)(f) prohibits emotion recognition in the workplace except for medical or safety reasons. If an internal tool claims to read staff mood from voice or video, check Article 5 first.

Other duties that apply to internal AI anyway

  • AI literacy (Article 4). Providers and deployers must take measures to support a sufficient level of AI literacy among their staff and others who use AI systems on their behalf. The consolidated text, as amended by the Digital Omnibus, says this does not require guaranteeing a specific level of literacy for any individual, and adds a supporting role for the Commission and Member States. Telling staff plainly which tools are AI and what they get wrong is part of that.
  • High-risk systems at work. If an internal AI system is high-risk (for example, used for recruitment, promotion or task allocation decisions under Annex III point 4), Article 26(7) requires the employer to inform workers' representatives and the affected workers before putting it into service. Under the Digital Omnibus the high-risk obligations for Annex III systems apply from 2 December 2027.
  • GDPR. An internal assistant that processes staff data needs a lawful basis and must be covered in the employee privacy notice. National labour law may also require consulting a works council before introducing it.

A short check for internal assistants

  • [ ] The tool's name and first message say it is AI.
  • [ ] No AI-written message goes out under a person's name without saying so.
  • [ ] AI avatars or cloned voices of real people are labelled.
  • [ ] No emotion recognition on staff outside the Article 5 exceptions.
  • [ ] Staff have been told which tools are AI and their limits (Article 4).
  • [ ] Employee privacy notice covers the assistant's data.

Sources

來源:DEV Community · dev.to