Un prompt para un agente de IA de atención al cliente no es un párrafo con buenas intenciones: es un documento de ocho bloques (identidad y alcance, aviso de que es una IA, fuentes de verdad, reglas duras, procedimientos, escalado, formato y datos personales) del que se excluyen a propósito los datos que caducan. Precios, horarios, stock y plazos van en la base de conocimiento o en una integración en vivo, nunca en el texto del prompt, porque el prompt se despliega y se vuelve a probar entero, mientras que la base se corrige en un minuto y sin tocar el comportamiento del agente.
La otra mitad del trabajo son las reglas. Conviene separarlas en dos montones: las blandas, que hablan de tono y de estilo, y las duras, que se pueden verificar leyendo una conversación sin conocer el contexto. "Sé cercano" no es auditable. "No afirmes un precio que no esté en la base de conocimiento" sí lo es, y esa diferencia deja de ser teórica en cuanto un agente promete algo que la empresa no piensa cumplir.
Aquí va el prompt entero publicado en esta misma página, más la parte que suele quedarse fuera: cómo se prueba un cambio sin romper lo que ya funcionaba, qué frase de apertura resuelve la obligación de transparencia que es exigible desde hoy, 2 de agosto de 2026, y en qué casos el problema no está en el prompt por mucho que se reescriba.
Qué va en el prompt y qué va en la base de conocimiento
La regla cabe en una línea: si un dato puede cambiar sin que cambie el comportamiento del agente, no va en el prompt. El prompt describe cómo se comporta; la base de conocimiento contiene qué es verdad hoy.
Hay tres motivos, y ninguno es estético. El primero es operativo: quien actualiza un precio no debería tener que abrir el texto que gobierna al agente, ni volver a probar las veinticuatro conversaciones de control por haber cambiado un número. El segundo es de atención: cuanto más largo es el prompt, más se diluyen las instrucciones que importan entre párrafos de catálogo. El tercero es de responsabilidad: un dato en la base se puede citar tal cual y trazar hasta su origen; un dato incrustado en el prompt se convierte en algo que el modelo recuerda a medias.
Hay un tercer sitio que mucha gente olvida: la integración en vivo. Stock, estado de un pedido, huecos libres en la agenda o saldo de una cuenta no son conocimiento, son estado. Si no hay consulta en tiempo real, la respuesta correcta del agente no es una estimación amable, es decir que lo confirma y escalar.
| Elemento | Dónde va | Motivo |
|---|---|---|
| Precios, tarifas y descuentos | Base de conocimiento | Cambian sin previo aviso y hay que poder corregirlos sin desplegar nada |
| Horarios, festivos y direcciones | Base de conocimiento | Caducan cada semana; en el prompt convierten al agente en fuente de errores |
| Stock, plazos y estado de un pedido | Integración en vivo | Ni prompt ni base: sin consulta en tiempo real, el agente no debe afirmarlo |
| Política de devoluciones y textos legales | Base de conocimiento, con la redacción exacta | El agente debe poder reproducir el texto vigente, no una paráfrasis de hace seis meses |
| Tono, tratamiento y longitud de respuesta | Prompt | Es comportamiento, no dato; no caduca cuando cambia el catálogo |
| Qué hacer cuando no sabe algo | Prompt | Es una regla de decisión y se versiona con el resto del comportamiento |
| Criterio para pasar a una persona | Prompt | Define cuándo el agente deja de hablar; el detalle está en la página de escalado de chatbot a humano |
Un síntoma clásico de haber mezclado las dos cosas: el agente responde con un precio antiguo y la respuesta suena perfecta. El tono está bien porque el prompt está bien; el dato está mal porque el dato estaba dentro del prompt.
Los ocho bloques de un prompt que atiende clientes
El orden importa más de lo que parece. Identidad y reglas duras van arriba: en textos largos, lo que queda en la mitad es lo que peor se sostiene cuando la conversación se alarga. El formato y los datos personales van al final porque son cierres, no marcos.
Estos son los ocho bloques, con lo que tiene que resolver cada uno.
- Identidad y alcanceQuién es, de qué empresa habla, qué tres o cuatro cosas resuelve y qué no resuelve. La lista de lo que no hace es tan importante como la de lo que hace.
- Apertura y transparenciaLa frase literal con la que se presenta y qué contesta si le preguntan si es una persona. Va literal, entre comillas, no descrita.
- Fuentes de verdadDe dónde salen los datos, qué hace si no están y qué hace si la consulta falla. Sin este bloque, el modelo rellena el hueco con lo que le parece razonable.
- Reglas durasLa lista cerrada de lo que no puede afirmar nunca. Se redactan en negativo y con un test binario: se cumple o no se cumple.
- ProcedimientosLos tres a cinco flujos que resuelve de principio a fin, en pasos numerados. Más de cinco y el agente empieza a mezclarlos.
- Criterio de escaladoLas condiciones exactas que disparan el paso a una persona y el mensaje textual con el que se despide. No un "si la cosa se complica".
- Formato de salidaIdioma, tratamiento, líneas máximas por mensaje, una pregunta por mensaje y qué caracteres no usar. En WhatsApp, los asteriscos y las listas numeradas se leen fatal.
- Datos personalesQué pide, qué no pide jamás y qué hace si el cliente envía por su cuenta algo que no debería haber enviado.
Ocho bloques no son ocho párrafos sueltos. Cada uno resuelve una pregunta que el modelo se va a hacer en algún momento de la conversación, y si no está escrita la respuesta, la improvisa.
Las doce reglas duras: lo que el agente no puede afirmar nunca
Una regla dura tiene una propiedad concreta: alguien que no conozca el negocio puede leer veinte conversaciones y decir, sin discutir, cuáles la incumplen. Todo lo demás (cercanía, empatía, calidez) es tono, y el tono se corrige releyendo transcripciones, no añadiendo adjetivos al prompt.
Estas doce cubren la mayoría de los sustos que hemos visto en atención al cliente.
- No afirmar un precio que no esté en la fuenteNi redondear, ni estimar, ni decir "suele rondar".
- No confirmar disponibilidad ni stock sin consulta en vivoSi la integración no responde, se dice que no se puede consultar ahora.
- No prometer plazos de entrega, reembolso ni resoluciónLos plazos los promete la empresa, no el agente.
- No inventar excepciones a una políticaNi "por esta vez", ni "seguro que te lo aceptan".
- No decir que alguien llamará en X tiempoSalvo que la llamada esté agendada por una herramienta y el agente tenga la hora.
- No pedir datos de pago ni contraseñas por el canalNi tarjeta, ni CVV, ni códigos de verificación, bajo ninguna excusa.
- No repetir por escrito datos personales innecesariosSi el cliente los manda, no se reproducen en la respuesta.
- No emitir diagnóstico médico, jurídico ni financieroSe recoge el caso y se escala, aunque la pregunta parezca sencilla.
- No hablar de la competenciaNi para bien ni para mal: se responde por el propio servicio.
- No negar que es una IASi preguntan, se dice. Y no se usa nombre propio de persona.
- No cerrar sin ruta cuando no sabeO escala, o recoge un contacto y una hora de respuesta. Nunca un "lo siento" a secas.
- No salirse del alcance declaradoFuera de sus temas, una frase y redirección. No opina de nada más.
Las reglas duras se redactan en negativo a propósito. Un modelo puede interpretar de mil maneras "da información precisa"; "no afirmes un precio que no esté en la base de conocimiento" solo tiene una lectura, y falla de forma visible.
Qué pasa cuando el agente promete algo que no existe: el caso Air Canada
El 14 de febrero de 2024, el Civil Resolution Tribunal de la Columbia Británica, un tribunal canadiense de reclamaciones de cuantía menor, condenó a Air Canada a pagar a Jake Moffatt 812,02 dólares canadienses por la información errónea que le había dado el chatbot de su web: 650,88 de daños, 36,14 de intereses y 125 de tasas. El expediente es SC-2023-005609 y la referencia, 2024 BCCRT 149.
Conviene situarlo antes de sacar conclusiones: es una resolución de un tribunal provincial de pequeñas reclamaciones en Canadá, aplica una figura del derecho anglosajón que no tiene traslado directo al ordenamiento español y no es aplicable aquí. No es jurisprudencia y no obliga a nada en España. Es un caso ilustrativo, y lo que ilustra sí viaja bien.
El tribunal resumió la postura de la aerolínea diciendo que, en la práctica, venía a sostener que el chatbot era una entidad separada responsable de sus propios actos, calificó ese planteamiento de notable y lo rechazó. Concluyó que Air Canada no había puesto el cuidado razonable en asegurar que su chatbot fuera exacto. Y añadió el detalle que más debería preocupar a quien monta agentes: el chatbot enlazaba a la página correcta, con la información buena, y aun así la empresa respondió, porque el tribunal no aceptó que el cliente tuviera que contrastar una parte de la web con otra.
En el mismo terreno, la Agencia Española de Protección de Datos publica una infografía de recomendaciones dirigida a los usuarios de chatbots donde advierte de que no hay garantías de que la información que da un chatbot sea correcta y de que, según el sistema, puede producir daño emocional, desinformación o inducir a engaño. Está escrita para el ciudadano, no impone obligaciones a las empresas, pero leída del revés es una lista razonable de lo que cualquier empresa debería ofrecer: identificar con claridad al responsable, informar con referencia al RGPD y explicar si el sistema sigue aprendiendo de las conversaciones.
Traducido a prompt: las tres primeras reglas duras de la lista anterior no son cuestión de estilo. Son la diferencia entre un agente que dice "no lo tengo confirmado, te lo miro" y uno que se inventa una condición comercial que alguien va a tener que pagar.
Debería resultar obvio para Air Canada que es responsable de toda la información de su web. Da igual que la información venga de una página estática o de un chatbot.
La frase de apertura que cumple la obligación de transparencia
Desde el 2 de agosto de 2026, es aplicable el artículo 50 del Reglamento (UE) 2024/1689. No entra en vigor hoy (el Reglamento está en vigor desde 2024): lo que ocurre hoy es que pasa a ser exigible. Su apartado 1 obliga a los proveedores a diseñar los sistemas destinados a interactuar directamente con personas de forma que esas personas estén informadas de que interactúan con un sistema de IA, salvo 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. La Comisión Europea, en sus preguntas frecuentes sobre el artículo 50, sostiene que esa excepción debe interpretarse de forma restrictiva y con el criterio de una persona media razonablemente informada, atenta y observadora.
Un matiz que se está contando mal esta semana: no, no se ha aplazado todo. El Reglamento (UE) 2026/1744, el llamado Ómnibus digital sobre IA, publicado en el DOUE el 24 de julio de 2026, sí ha retrasado el grueso de las obligaciones de alto riesgo y sí ha dado un margen hasta el 2 de diciembre de 2026, pero solo para el marcado técnico legible por máquina del apartado 2 y solo a los sistemas que ya estuvieran en el mercado antes de hoy. La obligación de informar de que se habla con una IA no tiene prórroga.
El artículo 50 no dice cómo hay que redactar la frase, más allá de que la información se facilite de forma clara y distinguible a más tardar en el momento de la primera interacción. Así que la frase es una decisión de producto, y va literal en el bloque 2 del prompt. Tres versiones que funcionan en canales distintos:
WhatsApp o Instagram: «Hola, soy el asistente de inteligencia artificial de [MARCA]. Si prefieres hablar con una persona, escribe PERSONA y te paso con el equipo.»
Web: «Chat automático de [MARCA]. Responde una IA. Para hablar con el equipo, escribe PERSONA o llama al [TELÉFONO].»
Voz: «Le atiende el asistente automático de [MARCA]. Esta llamada la gestiona una inteligencia artificial. Diga "persona" en cualquier momento para hablar con el equipo.»
Lo que rompe la frase: ponerle nombre propio de persona al agente, firmar con una foto de alguien que no existe o dejar el aviso en el pie de la web esperando que cuente como primera interacción. Y una decisión que este artículo no puede tomar por nadie: en un montaje de marca blanca, quién es proveedor y quién responsable del despliegue es una calificación jurídica que ninguna de las fuentes consultadas resuelve, y de ella depende a quién le toca cada apartado del artículo 50. Esa pregunta es para un abogado, no para un blog. Sobre cómo se redacta el aviso y dónde se coloca en cada canal, está la página sobre avisar de que un chatbot es una IA.
El prompt completo, listo para copiar
Aquí está entero, con los ocho bloques y las doce reglas duras dentro. Los corchetes son lo único que hay que sustituir. No hay formulario, no hay descarga: es texto seleccionable.
1. IDENTIDAD Y ALCANCE Eres el asistente de [MARCA], [una frase sobre a qué se dedica la empresa]. Atiendes por [CANAL] a clientes y a personas interesadas. Resuelves: [tema 1], [tema 2], [tema 3]. No resuelves: [lista corta]. Si te preguntan por algo de esa lista, dilo en una frase y ofrece pasar con el equipo.
2. APERTURA Y TRANSPARENCIA En el primer mensaje de cada conversación nueva, preséntate con estas palabras exactas: «Hola, soy el asistente de inteligencia artificial de [MARCA]. Si prefieres hablar con una persona, escribe PERSONA y te paso con el equipo.» Si el cliente pregunta si eres una persona, responde que no, que eres el asistente automático de [MARCA]. Nunca digas ni des a entender que eres humano. No uses nombre propio de persona.
3. FUENTES DE VERDAD Los precios, horarios, condiciones, plazos y disponibilidad están en la base de conocimiento y en las herramientas conectadas. Son la única fuente válida. Si un dato no está ahí, no lo deduzcas, no lo estimes y no lo redondees: di que lo confirmas y escala. Si la consulta a la base o a una herramienta falla, dilo tal cual («ahora mismo no puedo consultarlo») y escala. Cuando des un precio, un plazo o una condición, reprodúcelos tal y como aparecen en la fuente, sin reformular las cifras.
4. REGLAS DURAS (sin excepciones) No afirmes un precio que no esté en la fuente. No confirmes disponibilidad ni stock sin consulta en vivo. No prometas plazos de entrega, reembolso ni resolución. No inventes excepciones a ninguna política. No digas que alguien llamará salvo que la llamada esté agendada y tengas la hora. No pidas datos de tarjeta, CVV, contraseñas ni códigos de verificación. No repitas por escrito datos personales que no necesites para el paso en curso. No des diagnóstico médico, jurídico ni financiero. No hables de otras empresas ni compares. No niegues que eres una IA. No cierres una conversación sin ruta: escala o recoge contacto y hora de respuesta. No respondas fuera de tu alcance declarado.
5. PROCEDIMIENTOS [PROCEDIMIENTO 1, por ejemplo: pedir cita] a) Pregunta qué servicio necesita. b) Consulta la disponibilidad en [HERRAMIENTA DE AGENDA]. c) Ofrece dos huecos concretos, nunca más de dos. d) Pide nombre y teléfono. e) Cierra confirmando fecha, hora y dirección tal y como los devuelve la herramienta. Si falta un dato en cualquier paso, no pases al siguiente: pregunta. [Repite el mismo formato por cada procedimiento. Máximo cinco.]
6. ESCALADO Pasa a una persona, sin negociarlo, cuando: el cliente lo pida; escriba PERSONA; repita la misma pregunta dos veces sin quedar resuelta; mencione una reclamación, una queja formal, un problema de salud, un cobro indebido o un abogado; o cuando una regla dura te impida responder. Al escalar, escribe exactamente: «Te paso con una persona del equipo. Te responde en horario de [HORARIO]. Tu consulta queda registrada.» Después de escalar, no sigas respondiendo en esa conversación.
7. FORMATO Español de España. Trato de [tú o usted], siempre el mismo. Máximo [4] líneas por mensaje. Una sola pregunta por mensaje. Sin asteriscos, sin listas numeradas, sin emojis [o como máximo uno]. Nada de disculpas encadenadas ni de fórmulas de folleto. Frases cortas y una respuesta por vez.
8. DATOS PERSONALES Pide solo lo imprescindible para el procedimiento en curso: [nombre y teléfono]. No pidas nunca número de tarjeta, CVV, contraseñas ni datos de salud por este canal. Si el cliente los envía por su cuenta, no los reproduzcas en tus respuestas y avísale de que no los mande por aquí. Si pregunta por sus datos o quiere ejercer sus derechos, no improvises: pasa la conversación al equipo y facilita [CORREO DE PRIVACIDAD].
Lo que no está en esta plantilla y no debe estarlo: ni un solo precio, ni un horario, ni un plazo, ni una condición concreta. Todo eso vive fuera, y por eso la plantilla sigue sirviendo dentro de seis meses.
Cómo probar un cambio de prompt sin romper lo que ya funcionaba
El fallo típico no es escribir mal el prompt: es cambiarlo cuatro veces en una tarde, a ojo, y no saber cuál de los cuatro cambios arregló una cosa y estropeó otra. Un cambio de prompt es un despliegue, y se trata como tal.
El procedimiento mínimo, que no necesita ninguna herramienta especial más que un documento y paciencia:
- Congela un banco de veinte a treinta conversaciones realesCon los datos personales quitados. Que incluya las feas: el cliente enfadado, el que pregunta por algo fuera de alcance, el que insiste en hablar con un humano.
- Escribe al lado la respuesta que esperasNo la respuesta literal, sino qué tiene que hacer el agente: dar el dato, escalar, preguntar o negarse. Ese es el criterio, no si suena bien.
- Añade los casos límite que nunca aparecen solosBase de conocimiento sin el dato, herramienta caída, cliente que le pide que jure que es humano, cliente que envía un número de tarjeta.
- Cambia una sola cosa por iteraciónUn bloque, una regla, una frase. Si tocas tres a la vez, el resultado no te dice nada.
- Pasa el banco entero y cuenta incumplimientos de reglas durasEs un número, no una impresión. Si sube de cero, el cambio no sale, por mucho que las respuestas suenen mejor.
- Versiona el prompt anterior con fecha y motivoRevertir tiene que costar un minuto. Y publica primero en un volumen pequeño antes de dejarlo en toda la operación.
Un detalle que ahorra discusiones: el banco de casos se amplía con lo que falla en producción, no con lo que a alguien se le ocurre en una reunión. Cada conversación que sale mal se congela y entra en el banco, y a partir de ahí ya nunca vuelve a salir mal sin que nadie se entere.
Cuándo el problema no es el prompt
Media docena de síntomas que llevan a reescribir el prompt durante días y no se arreglan ahí, porque su causa está en otro sitio.
El agente deja de responder pasadas unas horas en WhatsApp. No es el prompt. Cuando un usuario escribe o llama a la empresa se abre una ventana de atención al cliente de 24 horas, y dentro de ella se pueden enviar mensajes de formato libre sin aprobación previa. Cuando se cierra, solo se pueden enviar plantillas preaprobadas. Dos matices que casi nadie cuenta: la ventana también la abre una llamada del usuario, y la reinicia un mensaje del usuario, no la respuesta de la empresa. Responder no alarga nada.
Una plantilla que funcionaba deja de enviarse o empieza a costar más. Tampoco es el prompt. Meta recategoriza plantillas ya aprobadas: si decide que una plantilla de utilidad es en realidad de marketing, avisa con un día de antelación y la plantilla sigue aprobada, pero pasa a facturarse como marketing. Y si determina que una plantilla de marketing o utilidad debería ser de autenticación, no la recategoriza: la rechaza el primer día del mes siguiente y deja de poder usarse, sin posibilidad de pedir revisión. Eso rompe el flujo en producción con el prompt intacto.
El agente tarda demasiado en contestar. La política de la plataforma de Messenger exige que los bots identificados como automatizados respondan a cualquier entrada del usuario en menos de 30 segundos, y la propia política aclara que esa exigencia se aplica a los bots declarados como automatizados, no a los declarados híbridos o manuales. Si hay latencia, se mira la integración y la cadena de llamadas, no la redacción del prompt.
El agente da precios viejos o no encuentra algo que sí está documentado. Lo primero es la base de conocimiento; lo segundo es la recuperación, es decir, cómo se busca dentro de esa base. Ninguna de las dos se arregla escribiendo mejor.
Y el caso más incómodo: el agente no sabe qué contestar porque la empresa no lo ha decidido. Un prompt no puede resolver si se aceptan devoluciones a los 45 días, si se cobra el cambio de fecha o quién asume un error de envío. Cuando el agente duda es porque, en la conversación equivalente, el equipo humano también dudaba; lo único que ha hecho el agente es hacerlo visible.
Un último aviso que no es de prompt sino de permiso: Meta exige obtener el consentimiento del usuario antes de escribirle por WhatsApp, y desde noviembre de 2024 admite que ese consentimiento sea general y no específico de WhatsApp, siempre que se cumpla la legislación aplicable. Ojo con la lectura fácil: eso es la política de Meta, no el RGPD. Cumplir con Meta no equivale a cumplir con la ley española.
Cómo hemos verificado esto
Las obligaciones de transparencia proceden del artículo 50 del Reglamento (UE) 2024/1689, de las preguntas frecuentes que publica la Comisión Europea sobre ese artículo y del Reglamento (UE) 2026/1744, publicado en el DOUE el 24 de julio de 2026. El caso Air Canada se ha leído en el texto íntegro de la resolución 2024 BCCRT 149, no en prensa; las advertencias sobre chatbots proceden de la infografía de recomendaciones a usuarios de la AEPD. Las reglas de ventana de 24 horas, plantillas y responsividad están tomadas de la documentación oficial de Meta en su versión en inglés.
Todo se comprobó el 2 de agosto de 2026. En este terreno las fechas cambian rápido: si lees esto meses después, contrasta el estado del artículo 50 y las condiciones de mensajería antes de dar nada por vigente.
Fuentes
Todo dato con cifra de este artículo sale de una de estas fuentes. Si una fuente cambia, el artículo se revisa y se actualiza la fecha de arriba.
- 1.Moffatt v. Air Canada, 2024 BCCRT 149 (texto de la resolución)Civil Resolution Tribunal de la Columbia Británica, 14 de febrero de 2024, expediente SC-2023-005609. Tribunal de reclamaciones de cuantía menor; no es aplicable en España.
- 2.AEPD. Recomendaciones para usuarios en la utilización de chatbots con inteligencia artificialInfografía divulgativa dirigida a usuarios, no a empresas. No impone obligaciones.
- 3.Comisión Europea. Preguntas frecuentes sobre las obligaciones de transparencia del artículo 50Confirma la aplicabilidad desde el 2 de agosto de 2026 y el margen hasta el 2 de diciembre de 2026 para el marcado del apartado 2.
- 4.Artículo 50 del Reglamento (UE) 2024/1689Base de datos jurídica que reproduce el texto oficial en español. Para uso litigioso conviene contrastar en el texto consolidado del DOUE.
- 5.Reglamento (UE) 2026/1744 (Ómnibus digital sobre IA)Publicado en el DOUE el 24 de julio de 2026. Modifica el calendario del Reglamento de IA.
- 6.Meta. Ventana de atención al cliente y envío de mensajes en WhatsAppDocumentación oficial, versión en inglés.
- 7.Meta. Categorización de plantillas de WhatsAppRecategorización con un día de preaviso y rechazo de plantillas que deberían ser de autenticación.
- 8.Meta. Política de la plataforma de Messenger e InstagramLa exigencia de respuesta en menos de 30 segundos está redactada para bots declarados como automatizados en Messenger.
Preguntas frecuentes
¿Qué diferencia hay entre el prompt y la base de conocimiento de un agente?
El prompt define el comportamiento: quién es el agente, qué no puede afirmar, cuándo escala y con qué formato responde. La base de conocimiento contiene los hechos que caducan: precios, horarios, condiciones y textos legales. La regla práctica es que si un dato puede cambiar sin que cambie el comportamiento del agente, no debe estar escrito en el prompt, porque el prompt se despliega y se vuelve a probar entero, mientras que la base se corrige en un minuto.
¿Cuánto debe ocupar un prompt de atención al cliente?
No hay una cifra oficial ni tiene sentido inventarla. El criterio útil es de contenido, no de longitud: si dentro del prompt hay precios, horarios, catálogo o textos legales completos, sobra. Deben caber los ocho bloques con sus reglas y de tres a cinco procedimientos. Cuanto más largo es el texto, más se diluyen las reglas duras entre párrafos que el modelo trata con la misma importancia que todo lo demás.
¿Es obligatorio avisar de que se está hablando con una IA?
El artículo 50 del Reglamento (UE) 2024/1689 es aplicable desde el 2 de agosto de 2026 y obliga a que las personas estén informadas de que interactúan con un sistema de IA, salvo cuando resulte evidente para una persona razonablemente informada, atenta y perspicaz, atendiendo al contexto. La Comisión Europea interpreta esa excepción de forma restrictiva. Lo práctico es incluir el aviso en la primera frase. Esto es información, no asesoramiento jurídico.
¿Quién responde si un agente promete algo que la empresa no piensa cumplir?
Depende del ordenamiento y del caso concreto, y no puede resolverlo un artículo. Sí existe un caso ilustrativo: en febrero de 2024, un tribunal canadiense de reclamaciones de cuantía menor condenó a Air Canada a pagar 812,02 dólares canadienses por la información errónea que dio el chatbot de su web, y rechazó que el cliente tuviera que contrastar una parte de la web con otra. No es aplicable en España, pero marca una dirección.
¿Puedo poner los precios dentro del prompt si casi nunca cambian?
Es mala idea aunque cambien poco. El día que cambien habrá que editar el texto que gobierna el comportamiento del agente y volver a probarlo entero por un motivo que no tiene nada que ver con el comportamiento. Además, un precio en la base se puede reproducir literalmente y trazar hasta su origen; un precio incrustado en el prompt acaba siendo algo que el modelo recuerda a medias y reformula.
¿Por qué el agente deja de responder unas horas después en WhatsApp?
Porque se ha cerrado la ventana de atención al cliente. Cuando un usuario escribe o llama a la empresa se abre una ventana de 24 horas en la que se pueden enviar mensajes de formato libre; cuando se cierra, solo se pueden enviar plantillas preaprobadas. La ventana la reinicia un mensaje del usuario, no la respuesta de la empresa. No es un fallo del prompt y no se arregla reescribiéndolo.
¿Cómo sé que un cambio en el prompt no ha empeorado nada?
Con un banco fijo de veinte a treinta conversaciones reales anonimizadas, cada una con la actuación esperada anotada al lado: dar el dato, preguntar, escalar o negarse. Se cambia una sola cosa por iteración, se pasa el banco entero y se cuentan los incumplimientos de reglas duras. Si ese número sube de cero, el cambio no sale, por muy bien que suenen las respuestas nuevas.