Avisar de que es una IA no tiene una sola forma.
El artículo 50(1) fija un resultado —que la persona esté informada— y no fija un formato. Esta guía separa las dos cosas que casi siempre se mezclan: lo que el texto exige, que es vinculante y se puede citar, y las formas técnicas de conseguirlo, que no las decide el Reglamento y aquí se describen como opciones.
Esto es una guía práctica, no una ficha de norma. Explica qué dice el texto y qué opciones técnicas existen. No dice cuál te corresponde a ti, ni si lo que tienes puesto basta: eso depende de contratos y de decisiones internas que no se ven desde fuera, lo valora quien te asesore y Keravo no presta asesoramiento jurídico.
Los datos vinculantes que cita proceden de AI Act, artículo 50 y se comprobaron contra el texto oficial el 4 de agosto de 2026. Lo que no es vinculante se dice donde aparece, en el propio párrafo y no en una nota al pie.
En corto
| Dato | Valor |
|---|---|
| Rango | Guía práctica — qué dice la norma y qué opciones técnicas existen |
| Referencia | Art. 50(1) · 50(5) |
| Instrumento | AI Act, artículo 50 |
| Fuente | AI Act, artículo 50, apartados 1 y 5 |
| Verificado contra | Texto oficial publicado por la Oficina de Publicaciones de la Unión Europea |
| Texto oficial | EUR-Lex · CELEX 32024R1689 |
| Última verificación | 4 de agosto de 2026 |
Qué dice el apartado 1, en su literal
No se resume aquí lo que se puede citar. Este es el texto oficial:
Artículo 50, apartado 1: «Los proveedores garantizarán que los sistemas de IA destinados a interactuar directamente con personas físicas se diseñen y desarrollen de forma que las personas físicas de que se trate estén informadas de que están interactuando con un sistema de IA, excepto cuando resulte evidente desde el punto de vista de una persona física razonablemente informada, atenta y perspicaz, teniendo en cuenta las circunstancias y el contexto de utilización.»
Tres cosas de ese párrafo cambian lo que hay que mirar, y conviene leerlas despacio:
- Es una obligación de resultado, no de formato. El texto pide que las personas «estén informadas». No dice con qué palabras, ni en qué parte de la pantalla, ni en qué momento exacto dentro de la primera interacción.
- Recae sobre los proveedores y habla del diseño y desarrollo del sistema. Quién es proveedor y quién responsable del despliegue en un montaje concreto no se resuelve mirando una web: es una valoración jurídica y está explicada aquí.
- Tiene una excepción de contexto, cuando resulte evidente para «una persona física razonablemente informada, atenta y perspicaz». Es una excepción de apreciación, no una lista cerrada de supuestos.
Cuándo hay que informar: el apartado 5
El apartado 1 dice qué, y el 5 dice cuándo y cómo se entrega esa información. Es la parte que más se olvida:
Artículo 50, apartado 5: «La información a que se refieren los apartados 1 a 4 se facilitará a las personas físicas de que se trate de manera clara y distinguible a más tardar con ocasión de la primera interacción o exposición. La información se ajustará a los requisitos de accesibilidad aplicables.»
Tres exigencias, y las tres son de las que se pueden observar: clara, distinguible y a más tardar con ocasión de la primera interacción. Más una cuarta que casi nunca se cita: la información se ajustará a los requisitos de accesibilidad aplicables.
Ese «a más tardar» es lo que hace que un aviso enterrado en un texto legal enlazado desde el pie del widget y un primer mensaje que lo dice en su primera línea no sean equivalentes, aunque los dos existan y digan lo mismo.
Las tres formas técnicas que se ven en la práctica
No las establece el Reglamento. Son las que aparecen cuando se abre un widget real, y se describen aquí como opciones observables. Ninguna se declara suficiente: si una configuración concreta atiende la obligación no lo determina Keravo.
| Forma | En qué consiste | Qué se puede observar desde fuera |
|---|---|---|
| Texto en el primer mensaje | El bot lo dice en lo primero que escribe, antes de que la persona teclee nada. | Sí: se abre el lanzador y se captura el primer mensaje. |
| Etiqueta permanente en el widget | Una marca fija en la cabecera o el pie del panel, visible durante toda la conversación. | Sí, si está en el DOM y no dentro de una imagen. |
| Aviso previo a la interacción | Un texto o una pantalla que aparece al abrir el panel, antes de la conversación. | Sí, si aparece sin enviar ningún mensaje. |
Las tres pueden convivir, y en muchos despliegues conviven. Lo que no hace ninguna por sí sola es dejar constancia de que estaba puesta en una fecha concreta, que es un problema distinto y viene después.
Qué preguntarle al proveedor del chatbot
Preguntas de hecho, con respuesta comprobable. Sirven igual para una consultora que revisa el despliegue de un cliente que para quien contrata el widget:
- ¿Quién controla el texto del primer mensaje? ¿Se edita en el panel o lo pone el producto?
- ¿Qué le pasa a ese texto si se renombra el bot, sobre todo si se le pone un nombre de persona?
- ¿Y si se cambia de idioma? ¿Está traducido el aviso, o solo la interfaz?
- ¿Y si se cambia de plan? ¿Se pierde alguna cadena de texto al subir o bajar de plan?
- ¿Avisáis antes de cambiar el texto por defecto, o se entera uno cuando ya ha cambiado?
- ¿Queda registro de la configuración que tenía el widget en una fecha pasada?
La última suele ser la que menos respuesta clara tiene, y es justamente la que decide si mañana se puede demostrar algo o solo recordarlo.
Qué se puede documentar, y qué no
Desde fuera se observa lo que sale a la pantalla, con su procedencia y su fecha:
- Qué proveedor de chat carga la página, por su firma en el DOM o en la red.
- Qué se ve al abrir el lanzador, capturado y fechado.
- Qué no se pudo ver, dicho como tal y no como ausencia de problema.
Y no se observa lo que no sale a la web: la configuración del panel del proveedor, el contrato, quién decidió qué. Eso entra como declaración del titular, con su etiqueta de procedencia, o no entra. La metodología lo detalla.
Hay además un límite temporal que no tiene arreglo: no se puede documentar hoy cómo se comportaba un widget el mes pasado. Se observa cuando ocurre, o no se observa. Aquí hay un expediente de ejemplo completo, con su huella y su fecha.
Qué no dice esta guía
- No dice si una configuración concreta basta. No lo determina Keravo.
- No dice quién responde en un caso dado: proveedor o responsable del despliegue es una valoración jurídica, no una observación.
- No enumera proveedores ni da instrucciones paso a paso para ninguno. Eso exige observación propia y fechada, y su sitio son las fichas por proveedor, con su captura y su configuración.
- No hay nota, ni porcentaje, ni semáforo, aquí ni en ninguna otra página.
Esta página documenta y cita. Explica qué exige el texto y qué opciones técnicas existen; no interpreta la norma para ningún caso concreto y no es asesoramiento jurídico.
Relacionado
- El artículo 50 del AI Act: desde cuándo se aplica y qué exige · vinculante
- La transición del artículo 50(2) hasta el 2 de diciembre de 2026 · vinculante
- Cómo marcar el contenido generado con IA · guía
Cómo se mantiene esta ficha
Última verificación contra la fuente: 4 de agosto de 2026. Esta sección se actualiza en vez de reescribirse, y cada ficha lleva esa fecha a la vista: si queda lejos, tómala por lo que es —una foto fechada— y comprueba el texto oficial.
El texto oficial está enlazado arriba y aquí, para no tener que fiarse de este resumen: EUR-Lex · CELEX 32024R1689.
El contenido de esta página no se edita a mano: sale de un fichero de datos versionado, y hay una comprobación que falla si el HTML publicado deja de coincidir con él. Es la misma disciplina que se aplica a los expedientes.
HABLAR CON KERAVO→