---
title: "El bot de soporte de Cursor inventó una política que no existía y los clientes cancelaron"
description: "En 2025 el bot de soporte de Cursor inventó una política de un dispositivo por suscripción, la defendió como «comportamiento esperado» y hubo cancelaciones."
slug: "cursor-bot-soporte-invento-politica-un-dispositivo"
url: "https://catalizadora.ai/blog/cursor-bot-soporte-invento-politica-un-dispositivo"
cluster: "casos-ia"
author: "Pablo Estrada"
published_at: "2026-08-26T08:03:54.89+00:00"
updated_at: "2026-08-26T18:44:30.141931+00:00"
read_minutes: "7"
lang: "es"
---
# El bot de soporte de Cursor inventó una política que no existía y los clientes cancelaron

> En 2025 el bot de soporte de Cursor inventó una política de un dispositivo por suscripción, la defendió como «comportamiento esperado» y hubo cancelaciones.

## La cronología

**Día 0.** A principios de 2025, Cursor —el editor de código con IA de la empresa Anysphere— era una de las herramientas más comentadas entre programadores. Como casi cualquier producto de suscripción que crece rápido, su soporte de primera línea por correo estaba parcialmente automatizado. Las respuestas llegaban firmadas por un agente llamado «Sam», sin ninguna indicación de que del otro lado hubiera un sistema y no una persona.

**Día 1.** Varios usuarios de pago empiezan a reportar un comportamiento nuevo: al pasar de una computadora a otra, la sesión se les cerraba. Escriben a soporte esperando que les confirmen un error. Reciben otra cosa. «Sam» contesta con total seguridad que eso es **el comportamiento esperado** de una política de un dispositivo por suscripción. No un bug: la regla. Esa política nunca existió, y «Sam» tampoco era quien parecía ser.

**Horas después.** La captura del correo circula en Reddit y en Hacker News. El hilo pasa de la extrañeza al enojo, y varios usuarios anuncian en público que cancelan su suscripción, porque trabajar en dos máquinas es lo normal para cualquier programador. Un cofundador de Cursor sale a responder: no existe tal política, cualquiera puede usar el producto en varias máquinas, y esa respuesta salió de un bot de soporte de primera línea. El cierre de sesión sí era real, pero venía de un cambio en el backend pensado para reforzar la seguridad de las sesiones que terminó invalidándolas sin querer. La empresa añadió que, en adelante, las respuestas generadas por IA en el soporte por correo quedarían identificadas como tales.

> Un bot de atención sin revisión humana no comete errores de atención: promulga políticas.

## Qué pasó, en detalle

El origen del incidente fue un problema técnico banal y perfectamente reparable: un ajuste de seguridad en el backend estaba invalidando sesiones y expulsando a usuarios legítimos cuando cambiaban de equipo. Ese tipo de regresión ocurre todas las semanas en todos los productos del mundo. Lo que convirtió un bug en una crisis de reputación fue la respuesta.

Cuando los usuarios preguntaron *por qué* estaba pasando, el sistema de soporte hizo lo que hace un modelo de lenguaje al que se le pide una explicación y no se le da una fuente: produjo la explicación más plausible. Y la más plausible, estadísticamente, es que se trate de una política. Los productos de suscripción tienen límites de dispositivos; suena razonable; encaja con el síntoma. El modelo no mintió en el sentido humano de la palabra. Rellenó un vacío con la respuesta que mejor cerraba la historia.

El problema es que ese vacío se rellenó por escrito, con el nombre de la empresa encima, dirigido a un cliente que pagaba. En ese momento la explicación dejó de ser una hipótesis de un sistema y se convirtió en la versión oficial. Los usuarios hicieron exactamente lo que haría cualquiera ante una condición nueva que no aceptan: dejaron de pagar. Y como el agente firmaba con nombre humano, nadie tuvo motivos para dudar de lo que leía.

La corrección llegó rápido y fue clara —el cofundador desmintió la política en público y pidió disculpas—, pero llegó después de las cancelaciones, del hilo de Reddit y de la cobertura en prensa técnica. [Cobertura en ARS TECHNICA](https://arstechnica.com/ai/2025/04/cursor-ai-support-bot-invents-fake-policy-and-triggers-user-uproar/).

## Por qué pasó

Conviene decirlo con precisión, porque es la lección entera del caso: no falló el modelo, falló el proceso alrededor del modelo.

Un modelo de lenguaje es un sistema que completa. Si se le pregunta por una política y no tiene acceso a la política real, va a redactar la más verosímil, y lo va a hacer con el mismo tono de certeza con el que redacta las verdaderas. Esa certeza no es arrogancia del sistema: es la textura normal de su salida. Un humano nuevo en soporte, ante la misma pregunta, hubiera dicho «déjame confirmarlo», porque sabe que no sabe. El modelo no tiene esa señal a menos que alguien se la construya.

Cursor tenía tres piezas ausentes, y cualquiera de las tres sola habría evitado el incidente. No había una fuente de verdad conectada: el bot no leía las políticas comerciales de una tabla, las recordaba. No había un límite declarado de competencia: nadie le había dicho «sobre políticas de suscripción no respondes, escalas». Y no había divulgación: el cliente no sabía que hablaba con un sistema, así que no aplicó el escepticismo que sí aplica cuando sabe que del otro lado hay automatización.

Súmele el ingrediente que amplifica todo: un bug real ocurriendo al mismo tiempo. El síntoma existía, el bot le dio una causa falsa pero coherente, y la coherencia es lo que hace creíble una explicación equivocada.

![Datos del caso Cursor: bot de soporte, política inexistente y cancelaciones en cadena](/img/casos/cursor-bot-soporte-invento-politica-un-dispositivo-datos.jpg)

*«Es el comportamiento esperado»: la frase con la que un bot defendió una política de un dispositivo por suscripción que nunca existió.*

## Dónde te puede pasar a ti

No hace falta ser una startup de software para reproducir este error. Hace falta tener un bot contestándole a clientes.

- **Atención por WhatsApp.** Un cliente pregunta si puede devolver un producto a los 20 días. El bot no tiene la política de devoluciones en ninguna tabla, así que redacta la más común del rubro: 15 días. Acaba de crear una política que su empresa nunca aprobó, y el cliente ya la tiene por escrito.
- **Cotizaciones.** El bot arma una cotización con un descuento por volumen que suena razonable, o promete un plazo de entrega que su operación no cumple en temporada alta. El precio salió de la memoria del modelo, no de su lista vigente.
- **Cobranza.** Un deudor pide facilidades y el bot le ofrece un plan de pagos que ningún gerente autorizó. En muchos países de la región, eso no es solo un problema comercial.
- **Contratación y contenido.** Un bot de reclutamiento describe un beneficio que la empresa no da; un generador de contenido publica una condición de garantía inventada en la página de producto, y ahí queda, indexada.

La pregunta incómoda: si abriera hoy las últimas cien conversaciones de su bot, ¿podría demostrar que ninguna de esas respuestas contiene una condición comercial que nadie en su empresa escribió jamás?

## Cómo se evita

**1. Las condiciones salen de una tabla, nunca de la memoria del modelo.** Precios, plazos, políticas de devolución, garantías y límites de plan viven en una base de datos versionada. El bot consulta y cita; no recuerda. Si la consulta no devuelve nada, la respuesta correcta es que no lo sabe, no la más plausible.

**2. Catálogo cerrado de capacidades.** Escriba la lista explícita de temas que el bot puede resolver. Todo lo que no está en la lista se responde con una sola frase: «esto lo revisa una persona y te contesta». Lo no declarado no existe. Esta regla, sola, habría matado el incidente de Cursor en su primer correo.

**3. Escalada por señales, no por criterio del bot.** Defina disparadores mecánicos: la palabra «cancelar», un reclamo, una pregunta que empieza con «por qué cambió», la mención de un cobro. Cuando aparecen, la conversación pasa a un humano automáticamente, sin que el modelo decida si es necesario.

**4. Divulgación desde el primer mensaje.** El bot se identifica como asistente automatizado y no usa nombre de persona. Un cliente que sabe que habla con un sistema verifica antes de cancelar; uno que cree hablar con un empleado, no.

**5. Registro auditable y la regla de los tres reportes.** Guarde cada conversación completa, revise una muestra diaria y monte una alerta: cuando tres clientes reportan el mismo síntoma en 24 horas, el bot deja de explicar la causa y abre un ticket. Una explicación inventada repetida cien veces es una política de facto.

## Cómo lo hacemos en Catalizadora

En Cortex, el motor de nuestros bots, los precios y las condiciones no están en el prompt: salen de las tablas del cliente a través del price-guard, y si la tabla no tiene el dato, el bot no improvisa. Las capacidades se declaran una por una en la configuración, con la regla dura de que lo no declarado no existe: si nadie escribió que el bot puede hablar de políticas de suscripción, no habla de eso, escala. La escalada a humano se dispara por señales, y «cancelar» es una de ellas.

Atlas guarda el registro completo e inalterable de cada conversación, que es la única forma honesta de responder la pregunta incómoda de la sección anterior: no con una impresión, sino abriendo las cien conversaciones. Y Faro deja a la vista la tasa de intervención humana, porque un bot que nunca escala no es un bot excelente, es un bot que está contestando cosas que no debería.

La regla, en una línea: si una respuesta compromete a la empresa, no puede nacer del modelo — tiene que salir de una tabla o de una persona.

---

*Este es uno de los casos documentados en nuestra hemeroteca de fallas de IA. Todos con su fuente enlazada, y todos con la misma conclusión: el problema casi nunca es el modelo.*
## Preguntas frecuentes

### ¿Qué pasó después del incidente?

Un cofundador de Cursor salió a responder en público que no existe ninguna política de un dispositivo por suscripción y que los usuarios pueden trabajar en varias máquinas, atribuyendo la respuesta a un bot de soporte de primera línea. Explicó además que los cierres de sesión venían de un cambio en el backend hecho para reforzar la seguridad, que invalidaba sesiones sin querer. La empresa indicó que en adelante las respuestas de IA en el soporte por correo quedarían identificadas como tales, pero varias cancelaciones ya se habían anunciado.

### ¿Cursor tenía realmente una política de un dispositivo por suscripción?

No. La política nunca existió: fue una explicación generada por el sistema de soporte para justificar un síntoma real. Lo que sí existía era un bug de sesiones provocado por un cambio de seguridad en el backend.

### ¿El problema fue el modelo de IA o el proceso?

El proceso. Un modelo de lenguaje al que se le pregunta por una política sin darle acceso a la política real va a redactar la más verosímil, y con el mismo tono de certeza que usa para las verdaderas. Lo que faltó fue una fuente de verdad conectada, un límite declarado de temas y una escalada obligatoria a un humano.

### ¿Hay que avisarle al cliente que está hablando con una IA?

Sí, y no solo por ética: es un mecanismo de defensa. Un cliente que sabe que habla con un asistente automatizado verifica antes de tomar una decisión drástica como cancelar; uno que cree hablar con un empleado toma la respuesta como la posición oficial de la empresa. Un bot con nombre humano y sin aviso convierte cualquier error en un comunicado.


---

Source: https://catalizadora.ai/blog/cursor-bot-soporte-invento-politica-un-dispositivo
Author: Pablo Estrada — AI Catalysts, LLC (catalizadora.ai)
