La cronología
Día 0. Microsoft opera uno de los portales de noticias más visitados del mundo. No escribe esas notas: las licencia de medios establecidos y las republica en su plataforma. Sobre ese texto ajeno corre una capa de automatización que agrega elementos pensados para retener al lector, entre ellos encuestas generadas por IA a partir del contenido del artículo. Ninguno de esos agregados pasa por la redacción que firmó la nota.
Día 1. The Guardian publica su cobertura de la muerte de Lilie James, una joven de 21 años, en Sídney. La nota se replica en el portal de Microsoft y el sistema automático hace lo que hace con cualquier artículo: le agrega una encuesta. Las opciones que ofrece al lector para votar son la causa de la muerte de la joven: «¿Asesinato, accidente o suicidio?».
Horas y días después. La indignación de los lectores no cae sobre el sistema que insertó la encuesta, sino sobre la firma que aparece arriba de la nota: hubo comentarios pidiendo el despido de la periodista, que no tuvo nada que ver con el agregado. Microsoft retira la encuesta y desactiva ese tipo de agregados en notas de noticias. The Guardian escala el reclamo al presidente de Microsoft y exige explicaciones por el daño a su reputación.
Cuando automatizas sobre contenido ajeno, tu error se publica con la marca de otro.
Qué pasó, en detalle
El caso es breve de contar y difícil de olvidar. The Guardian informó sobre la muerte de una joven de 21 años en Sídney, una nota de crónica policial con todo lo que eso implica: una familia real, una investigación en curso, un tema que ningún manual de estilo trata a la ligera. Esa nota viajó, por acuerdo de licencia, al portal de noticias de Microsoft, que la mostró a su propia audiencia con el nombre del medio y el de la autora.
Al lado del texto apareció un widget que no había escrito nadie del Guardian: una encuesta automática que invitaba al lector a votar por qué había muerto la joven, con tres opciones que incluían asesinato, accidente y suicidio. La encuesta se publicó sin que un editor la viera, porque el sistema no estaba diseñado para que un editor la viera. Estaba diseñado para agregar un elemento interactivo a cada artículo y medir cuánta gente lo tocaba.
El resultado fue doble. Primero, el daño humano evidente: convertir la muerte de una persona identificada en un juego de adivinanzas frente a miles de lectores. Segundo, el daño reputacional, que se distribuyó al revés de como debía. Los lectores vieron la marca del medio y la firma de la periodista, no la de la compañía que insertó el widget. Hubo pedidos públicos de despido dirigidos a una profesional que ni siquiera tenía acceso a la plataforma donde apareció la encuesta. The Guardian sostuvo que el episodio dañó su reputación y llevó el reclamo directamente al presidente de Microsoft. Microsoft retiró la encuesta y desactivó las encuestas automáticas en artículos de noticias.
Cobertura en Search Engine Land
Por qué pasó
Es tentador leer esto como «la IA no entendió que el tema era sensible». Es una lectura cómoda y equivocada. El modelo hizo exactamente lo que se le pidió: generar una encuesta relevante a partir del texto de un artículo. Si el artículo habla de una muerte cuya causa está bajo investigación, la encuesta «relevante» es sobre la causa de la muerte. La salida es coherente con la instrucción. El problema es la instrucción, y sobre todo dónde estaba conectada.
El fallo de proceso tiene tres capas, y las tres son de diseño humano.
La primera es que el sistema estaba encendido por defecto para todo el catálogo. No había una lista de categorías excluidas —crónica policial, muertes, menores, salud, tragedias, juicios en curso— donde la automatización simplemente no corre. Cuando el default es «aplicar a todo», el peor artículo posible del inventario es también el que va a recibir el agregado.
La segunda es que no existía una compuerta humana antes de publicar. Un editor de noticias que ve esa encuesta la mata en dos segundos; no hace falta un comité de ética, hace falta un par de ojos con autoridad para decir «esto no sale». El sistema publicaba directo, y en un flujo directo a producción la única forma de descubrir un error es que lo descubran los lectores.
La tercera, la más costosa, es que la superficie de publicación pertenecía a una empresa y la marca visible pertenecía a otra. El portal ejecutaba la automatización, pero la nota llevaba el logotipo del medio y el nombre de la periodista. El error de un sistema se convirtió en el problema reputacional de un tercero que no lo controlaba ni podía apagarlo.
Una joven de 21 años, tres opciones de voto y cero revisiones humanas antes de publicar.
Dónde te puede pasar a ti
No hace falta operar un portal de noticias global. La estructura del error —automatización encendida por defecto, sin categorías prohibidas y sin revisión antes del clic— se reproduce igual en una empresa mediana de LATAM.
- El bot de atención que contesta todo. Si tu bot responde cualquier mensaje que entre por WhatsApp, tarde o temprano le va a llegar uno que menciona un accidente, un fallecimiento, un reclamo por daños o una amenaza legal. Si no tiene una regla que corte y escale a una persona ante esas señales, va a contestar con el mismo tono alegre que usa para consultar el horario de la sucursal.
- La cobranza automatizada. Un flujo que insiste solo con reglas de días de mora no sabe que ese cliente llamó ayer a reportar la muerte del titular de la cuenta. El tercer recordatorio automático, en ese contexto, no es una gestión: es un incidente.
- El contenido generado para tus canales. Resúmenes, titulares, posteos y respuestas a reseñas producidos en lote y publicados sin lectura previa. Basta un tema delicado en el insumo para que la salida sea publicable técnicamente e indefendible públicamente.
- La automatización que corre sobre datos o marcas de terceros. Si generás contenido, cotizaciones o respuestas en nombre de un cliente, un distribuidor o una franquicia, tu error no aparece con tu nombre: aparece con el de ellos, y el reclamo llega después.
La pregunta incómoda: en tu operación de hoy, ¿cuántos mensajes salen al cliente sin que ninguna persona pueda verlos antes, y qué temas tiene prohibido tocar ese sistema por escrito?
Cómo se evita
1. Lista de temas prohibidos, declarada y ejecutable. Escribí las categorías donde la automatización no corre: muerte, salud, accidentes, menores, temas legales, quejas graves. No como recomendación en un documento, sino como una regla en el código que detiene el flujo y lo manda a una cola humana. Si no está en la lista de lo permitido, no sale.
2. Detección de señales antes de generar, no después. Antes de que el modelo produzca cualquier salida, un clasificador barato revisa el insumo por palabras y patrones de riesgo. Es más fácil no generar que arrepentirse de haber publicado. Este paso se implementa en una tarde y se prueba con los últimos 200 casos reales de tu operación.
3. Compuerta humana para lo sensible, automatización libre para lo rutinario. No frenes todo: frena el 3% que puede costarte la reputación. Definí umbrales claros y medí cuántos casos caen en la cola humana por semana; si son demasiados, el problema es el umbral, no la persona.
4. Apagado de un botón, con dueño y teléfono. Todo sistema que publica o responde en automático necesita un interruptor que cualquier responsable de guardia pueda accionar sin abrir un ticket. Escribí quién lo tiene, dónde está y cuánto tarda en surtir efecto. Pruébalo una vez, en frío.
5. Registro completo de lo que salió. Cada mensaje, cada texto generado y cada decisión automática queda guardado con fecha, insumo y versión de la regla. Sin ese registro no puedes responder la única pregunta que importa cuando algo explota: qué salió exactamente, cuándo y por qué.
Cómo lo hacemos en Catalizadora
Nuestros bots corren sobre Cortex, y ahí hay dos candados que aplican directo a este caso. El primero es que las capacidades se declaran de forma explícita: lo que no está declarado no existe, así que el bot no improvisa funciones nuevas porque el contexto se las sugiera. El segundo es la escalada a humano por señales: ciertos temas y ciertas palabras no producen una respuesta más prudente, producen un traspaso a una persona con nombre y apellido.
Toda conversación queda en Atlas, en un registro completo e ineditable. Cuando un cliente pregunta qué le dijo el sistema el martes a las 3 de la tarde, la respuesta es un enlace, no una reconstrucción de memoria.
Y en Faro dejamos a la vista la tasa de intervención humana. Es la métrica que nadie quiere mirar y la única que avisa a tiempo: si baja a cero, el sistema dejó de escalar y estás publicando a ciegas.
La regla, en una línea: si el tema es sensible, la automatización propone y una persona publica.
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.