La cronología
Día 0. En 2023, G/O Media —la casa editorial detrás de Gizmodo, una de las cabeceras de tecnología más leídas del mundo— incorpora contenido generado por inteligencia artificial a sus publicaciones. La decisión se toma en la dirección de la empresa. Las redacciones, entre ellas la de io9, la vertical de ciencia ficción y cultura pop de Gizmodo, no diseñan ese proceso ni deciden qué se publica bajo qué firma.
Día 1. El equipo de io9 recibe un aviso: en diez minutos sale el primer artículo firmado por «Gizmodo Bot». Es una lista de las películas y series de Star Wars ordenadas cronológicamente. El artículo se publica. La lista no está en orden cronológico y omite series completas del catálogo. Cualquier lector habitual de io9 lo nota en la primera pasada; sus periodistas, todavía más rápido.
Horas después. El subeditor del sitio califica la pieza de «vergonzosa, impublicable e irrespetuosa con la audiencia» y envía una lista formal de correcciones. El episodio salta de la conversación interna a la prensa internacional. Lo que queda documentado no es un artículo con errores: es que la publicación ocurrió por encima de la propia redacción, que se enteró casi al mismo tiempo que los lectores.
La inteligencia artificial no decidió publicar nada; lo decidió un proceso que dejó fuera a las únicas personas capaces de ver el error antes que la audiencia.
Qué pasó, en detalle
Gizmodo es, desde hace años, una referencia global del periodismo tecnológico. io9, su sección de ciencia ficción, tiene una audiencia que conoce el material con un nivel de detalle obsesivo: gente que discute el orden de los eventos del universo Star Wars como quien discute una tabla de posiciones. Es, probablemente, el peor lugar posible para publicar una cronología aproximada.
El artículo firmado por «Gizmodo Bot» prometía exactamente eso, una cronología, y no la entregaba. El orden estaba mal y faltaban series enteras. No hacía falta ser periodista para detectarlo: hacía falta que alguien lo leyera antes de que estuviera en línea. Ese alguien existía, estaba a diez minutos de distancia y no fue consultado.
Diez minutos no son una revisión. Son un aviso. La diferencia entre las dos cosas es la que separa a un flujo editorial de un anuncio de despliegue: en el primero, alguien puede decir «esto no sale»; en el segundo, ya salió. El subeditor de io9 hizo lo que corresponde a su oficio —leer, verificar y devolver una lista formal de correcciones—, solo que lo hizo después de la publicación, cuando ese trabajo ya no protege al lector sino que documenta el daño. La escena completa quedó registrada en la cobertura en Variety.
Vale la pena separar dos cosas que en la conversación pública suelen ir pegadas. Una es la calidad del texto generado: mejorable, y mejorable con trabajo. La otra es quién tenía autoridad para detenerlo. En este caso, la segunda es la que explica el resultado. Un artículo malo pasa todos los días por las redacciones del mundo y muere en el escritorio del editor. Este no murió ahí porque nunca pasó por ahí.
Por qué pasó
Un modelo de lenguaje produce texto plausible, no texto verificado. Cuando se le pide una lista cronológica, no consulta un catálogo con fechas y lo ordena: produce una secuencia que se parece a las secuencias que ha visto. Si el orden real depende de una línea temporal interna del universo narrativo —que no coincide con el orden de estreno—, la respuesta correcta requiere una fuente de datos, no una generación de estilo. Sin esa fuente, el modelo entrega algo que tiene la forma de una cronología y no su contenido.
La omisión es todavía más silenciosa. Un modelo no sabe lo que no dijo. No hay ninguna señal interna que grite «faltan tres títulos»: la respuesta se ve igual de completa esté completa o no. Por eso el error de cobertura es el más peligroso en cualquier automatización de contenido, cotizaciones o catálogos. Un dato equivocado se nota; un dato ausente no deja rastro.
En lenguaje de negocio, el fallo se resume así: se usó un generador donde hacía falta una consulta a datos, y se eliminó del circuito la única capa que corrige ese tipo de error, que es la revisión humana con poder de veto. El modelo hizo lo que hacen los modelos. El proceso hizo lo que no debía: publicar sin puerta.
Diez minutos de aviso y cero minutos de revisión con poder de detener la publicación: esa es toda la distancia entre un flujo editorial y un incidente público.
Dónde te puede pasar a ti
Este caso parece de medios, pero el mecanismo es idéntico en cualquier empresa mediana que puso IA a producir algo que sale hacia afuera.
- El bot de atención responde por productos que ya no existen. Si el asistente redacta desde su memoria en lugar de consultar el catálogo vivo, va a describir referencias descontinuadas con total seguridad, y ningún cliente va a poder distinguir una respuesta correcta de una inventada.
- La cotización automática omite una línea. El total se ve bien, el formato se ve bien y falta el flete, la instalación o el impuesto. Nadie detecta lo que no está: el error aparece recién cuando el cliente reclama el precio que se le prometió.
- La cobranza escribe con un dato viejo. Un mensaje automático que menciona un saldo ya pagado no es un error de redacción, es una llamada furiosa y, según el rubro, un problema de cumplimiento.
- El contenido de marca se publica sin editor. Blogs, fichas de producto y respuestas en redes que van directo del generador al sitio, porque el flujo se diseñó para velocidad y la revisión quedó como una buena intención sin lugar en el calendario.
La pregunta incómoda para hoy: en tu operación, ¿existe una persona con autoridad real para detener una salida automática antes de que llegue al cliente, y esa autoridad está en el sistema o depende de que alguien esté mirando la pantalla en el momento justo?
Cómo se evita
1. Poner una compuerta, no un aviso. Todo contenido o mensaje generado que salga hacia afuera nace en estado «borrador» y solo cambia de estado con una acción explícita de una persona identificada. Si el sistema puede publicar sin ese clic, no hay revisión: hay notificación.
2. Separar generar de consultar. Los datos duros —precios, plazos, catálogo, saldos, fechas— se leen de una tabla de la empresa y se insertan en el texto; nunca los redacta el modelo desde su memoria. Esta semana se puede empezar por una sola tabla: la de precios.
3. Declarar el alcance por escrito. Definí qué tipos de piezas puede producir la automatización y cuáles no. Lo que no está declarado, no se genera. Una lista cerrada de tareas permitidas evita la mayoría de las sorpresas antes de que existan.
4. Exigir verificación de cobertura, no solo de exactitud. Antes de aprobar, la pregunta no es «¿está bien lo que dice?» sino «¿está todo lo que debía estar?». Un conteo contra la fuente —cuántos ítems tiene el catálogo, cuántos aparecen en la pieza— convierte esa pregunta en un chequeo de dos minutos.
5. Medir la tasa de intervención humana. Registra qué porcentaje de las salidas fue corregido antes de publicarse. Si es cero durante semanas, la revisión no está funcionando: está firmando. Si es altísimo, el generador está mal configurado y hay que arreglarlo antes de escalar.
Cómo lo hacemos en Catalizadora
En Cortex, nuestro motor de atención, las capacidades están declaradas de forma explícita: lo que no está declarado, no existe para el bot. Y los datos que comprometen a la empresa —precios, condiciones, disponibilidad— salen de tablas del cliente, nunca de la memoria del modelo. Es el mismo candado que le faltaba a esa cronología: cuando el dato viene de una tabla, el orden y la cobertura se verifican contra algo, no contra el estilo.
Con el método MAGIA entregamos fase por fase y con evidencia: nada avanza porque alguien lo dé por hecho, sino porque hay una prueba de que quedó bien. Y en Faro, el tablero del cliente, la tasa de intervención humana está a la vista, porque una automatización que nadie corrigió nunca no es una automatización madura: es una revisión que dejó de existir sin que nadie se diera cuenta.
La regla, en una línea: si algo puede salir con tu firma, alguien de tu equipo tiene que poder detenerlo, y ese poder tiene que estar en el sistema, no en la buena voluntad.
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.