Detector de "AI slop" con vibe coding: qué funciona y qué no

1. El problema del slop y por qué detectar vídeo sintético es más difícil de lo que parece

El término slop (literalmente "bazofia": contenido de baja calidad producido en masa con herramientas generativas) se ha instalado en el vocabulario de internet porque describe algo que cualquiera reconoce sin necesidad de definición. Vídeos cortos de sucesos imposibles, inventos milagrosos, animales que hacen cosas que no hacen, escenas históricas que nunca ocurrieron. Circulan por redes sociales, se comparten en grupos familiares y llegan, con frecuencia creciente, acompañados de la frase "mira esto".

El problema no es únicamente estético. Es que la frontera se ha vuelto porosa incluso para personas con criterio técnico. Es habitual necesitar dos o tres visionados antes de que algo encaje: una sombra que no corresponde, un objeto que cambia de tamaño entre planos, una física que no cuadra. Y ese retardo de reconocimiento —el intervalo entre ver y sospechar— es exactamente el espacio donde el contenido sintético se propaga.

De ahí surge una idea que a mucha gente se le ha ocurrido: un sitio web donde pegar la URL de un vídeo de una red social y obtener un veredicto. "Esto es IA" o "esto no lo es". Suena a herramienta sencilla, casi obvia. La intuición dice que si los modelos generativos son capaces de crear estos vídeos, otros modelos deberían ser capaces de reconocerlos.

Esa intuición es incorrecta, y entender por qué es la primera lección del ejercicio. Generar y detectar no son operaciones simétricas. Un generador produce imágenes que optimizan la verosimilitud estadística; un detector necesita encontrar la huella de ese proceso en un archivo que, para cuando llega a nuestras manos, ha sido recomprimido por la plataforma, recortado, reescalado, superpuesto con texto y posiblemente regrabado desde otra pantalla. Cada una de esas transformaciones destruye precisamente las señales sutiles que un detector necesitaría.

A esto se suma una dificultad conceptual que atraviesa todo el problema: la categoría "generado por IA" no es binaria. Un vídeo puede estar íntegramente generado, parcialmente retocado, tener el audio sintetizado y la imagen real, estar recreado con gráficos por ordenador tradicionales —CGI, computer-generated imagery— sin intervención de modelos generativos, o combinar todo lo anterior. Un sistema que devuelva un simple sí o no está simplificando un espectro que no admite esa simplificación.

2. Paso 1: usar el modelo para validar la viabilidad antes de escribir una sola línea

El primer movimiento del proceso no fue abrir un editor de código, sino abrir una conversación con un modelo de lenguaje y plantearle la pregunta correcta. No "escríbeme esta aplicación", sino "tengo esta idea y quiero determinar si es viable; ayúdame a pensar cómo hacerla realidad". La diferencia entre ambas formulaciones es la diferencia entre obtener código que quizá no sirva para nada y obtener un análisis de si el problema tiene solución.

Este paso, que parece burocrático, es el más rentable de todo el proyecto. Un modelo de razonamiento moderno, cuando se le pide explícitamente que evalúe viabilidad, tiende a inventariar las aproximaciones existentes, señalar sus límites conocidos y proponer una arquitectura tentativa. Es, en esencia, una revisión bibliográfica acelerada del problema que uno quiere resolver.

Hay un matiz importante en cómo se conduce esa conversación: aportar de entrada lo que uno ya sabe. En este caso, se le indicó al modelo que existía SynthID de Google para identificar contenido creado con sus propias herramientas, y que los modelos Gemini eran de los pocos con capacidad real de comprensión de vídeo, incluida una versión actualizada de esa capacidad. Suministrar ese contexto evita que el modelo proponga caminos ya descartados y hace que su respuesta parta del estado real de las herramientas disponibles.

El proceso de deliberación se prolongó durante diecisiete minutos de cómputo. La conclusión fue matizada y, vista en retrospectiva, profética: sí, es técnicamente posible construir algo así, pero no será fiable al cien por cien, y hay que comunicar esa incertidumbre a quien use la herramienta. Lo interesante no es que el modelo acertara —era la respuesta prudente esperable—, sino que quien construye rara vez interioriza esa advertencia hasta que la sufre.

La lección práctica es directa: cuando se plantea una herramienta propia, conviene dedicar la primera sesión completa a interrogar al modelo sobre viabilidad, límites, precedentes y criterios de éxito, sin escribir código. Si en esa fase aparece la frase "no será fiable al cien por cien", hay que decidir de antemano qué grado de imprecisión resulta aceptable. Ese umbral debería fijarse antes de empezar, no negociarse a mitad de camino cuando ya se han invertido horas.

3. Las herramientas que ya existen: SynthID, C2PA y detección por artefactos

Cualquiera que se plantee este problema se topará con tres familias de soluciones, y conviene entender que resuelven cosas distintas y ninguna resuelve el problema completo.

La primera es el watermarking (marca de agua) invisible. SynthID, desarrollado por Google DeepMind, incrusta en el contenido generado por las herramientas de Google una señal imperceptible para el ojo humano pero recuperable mediante un detector específico. Es una tecnología sólida dentro de su ámbito, y ese ámbito es su limitación estructural: solo identifica lo que fue creado con modelos de Google que aplican la marca. Un vídeo generado con cualquier otra herramienta no lleva SynthID, y su ausencia no significa absolutamente nada sobre si el vídeo es real. El detector responde "no encuentro mi marca", que no es lo mismo que "esto es auténtico".

La segunda familia son las content credentials (credenciales de contenido) del estándar C2PA, una coalición industrial que define metadatos criptográficamente firmados sobre el origen y el historial de edición de un archivo. Es un enfoque de procedencia: en lugar de intentar adivinar si algo es sintético, se pretende que cada pieza lleve consigo un certificado verificable de cómo fue creada. El problema en la práctica es doble. Por un lado, la adopción es parcial: la mayoría del contenido que circula no lleva credenciales. Por otro, muchas plataformas eliminan los metadatos al procesar las subidas, de modo que aunque el archivo original las tuviera, la copia que uno analiza ya no las conserva. En las pruebas del proyecto, la comprobación de credenciales devolvió sistemáticamente el mismo resultado: no se identificaron credenciales de contenido. Ni en los vídeos sintéticos ni en los reales.

La tercera familia es la detección por artefactos: analizar el propio píxel buscando huellas del proceso generativo. Incoherencias temporales, texturas anómalas, patrones en el ruido de la imagen, comportamientos imposibles de la luz. Aquí entran tanto los modelos multimodales de propósito general como las herramientas especializadas de visión por computador entrenadas específicamente para esta tarea.

Y aquí aparece el hallazgo más contraintuitivo de todo el ejercicio: los modelos multimodales de última generación, esos que sí son capaces de describir con precisión notable lo que ocurre en un vídeo, son malos detectando que ese vídeo es sintético. Entienden la escena, la narran correctamente, identifican objetos y acciones... y concluyen que no observan indicios claros de generación por IA en material que un espectador humano descarta en cuestión de segundos. La comprensión semántica y la detección forense son capacidades distintas, y tener la primera no implica en absoluto tener la segunda.

4. La construcción: el primer prototipo y el primer fracaso

Con la viabilidad validada, el proyecto pasó a un entorno de codificación agéntica: una herramienta que recibe acceso a una carpeta local y escribe, ejecuta y corrige el código por sí misma. El arranque incluyó un detalle de método que merece atención: en lugar de reexplicar la idea desde cero, se le pasó al agente el enlace a la conversación de validación previa y se le pidió que la leyera para extraer todos los detalles y trazar el plan. Reutilizar el contexto ya elaborado, en vez de reconstruirlo, ahorra horas y evita que la especificación se degrade en cada traducción.

Una hora y dieciséis minutos después había una aplicación funcionando. Interfaz web, campo para pegar una URL de las principales redes sociales, opción de subir un archivo, informe de resultados con nivel de confianza. Todo el andamiaje estaba en pie. El primer aviso de que algo iba mal no fue técnico sino de redacción: los textos generados automáticamente para la interfaz eran, sencillamente, malos —forzados, con un registro impostado que no encaja con ningún público real—. Es un recordatorio menor pero útil: el copy generado por el modelo hay que revisarlo siempre antes de publicarlo.

La prueba de fuego llegó con el primer clip claramente sintético: una escena físicamente imposible que cualquier persona identifica al instante. El veredicto del detector fue que probablemente no era IA, y lo entregó con alta confianza. El razonamiento que ofreció es revelador: describió un efecto de partículas rígido y atribuyó su origen a efectos visuales tradicionales de CGI en lugar de a generación por IA. Es decir, el sistema detectó correctamente una anomalía visual, pero la clasificó en la categoría equivocada.

Ese fallo concreto ilustra un problema de fondo. Un detector de este tipo tiene que distinguir entre tres cosas —material real, material generado y material producido con técnicas digitales convencionales— y la frontera entre las dos últimas es genuinamente borrosa. Muchos artefactos que delatan generación por IA se parecen a artefactos de composición digital tradicional. Un modelo que razona sobre la escena en lenguaje natural puede construir una explicación coherente para cualquiera de las dos hipótesis.

El error más grave, sin embargo, no fue el veredicto equivocado. Fue el nivel de confianza alto que lo acompañaba. Un sistema que se equivoca ocasionalmente es tolerable; un sistema que se equivoca con seguridad aparente es peligroso, porque traslada al usuario una certeza que no existe.

5. Auditar el propio código: cuando el modelo revisa lo que otro modelo escribió

El siguiente movimiento fue abrir una conversación nueva con un modelo de razonamiento distinto y pedirle que auditara el trabajo anterior. Este patrón —usar un modelo para revisar críticamente el código producido por otro— resultó ser el más productivo de todo el proyecto.

En menos de seis minutos, la auditoría devolvió un diagnóstico claro: no había que confiar en las etiquetas de confianza alta que emitía la aplicación. Y explicó por qué, con problemas reproducibles en la lógica del veredicto. El más grave: la etiqueta de confianza alta se asignaba automáticamente a partir de un valor numérico devuelto por el modelo de análisis, de manera que cualquier puntuación por debajo de cierto umbral disparaba mecánicamente la máxima confianza. La aplicación, además, podía sobrescribir una evaluación que el análisis había marcado como no concluyente y convertirla en un veredicto firme.

Traducido a lenguaje no técnico: la interfaz proyectaba una seguridad que el motor subyacente nunca había expresado. La incertidumbre se perdía por el camino, entre la capa que analizaba y la capa que comunicaba. Es un fallo tan común en sistemas construidos con asistencia de IA que merece nombre propio: la confianza es una propiedad del sistema completo, no de un número aislado, y cualquier transformación de ese número en una etiqueta legible es una decisión de diseño con consecuencias.

A continuación se lanzó una tarea agéntica de objetivo persistente: implementar las correcciones recomendadas y seguir iterando y autoevaluándose hasta lograr un funcionamiento correcto. El agente trabajó durante más de ocho horas seguidas. Produjo cuatro documentos de análisis, ejecutó numerosas baterías de pruebas y, al terminar ese plazo, seguía sin dar el objetivo por cumplido.

El resultado cuantitativo de esas pruebas es el dato más honesto de todo el proyecto: sobre 39 clips generados por IA, el detector identificó correctamente 23. Sobre 36 clips reales, marcó erróneamente 2. Es decir, aproximadamente un 59 % de acierto en la detección de material sintético, con una tasa baja de falsos positivos (false positives: material auténtico clasificado como sintético). Un detector que deja pasar cuatro de cada diez vídeos generados no es una herramienta de verificación; es, como mucho, una señal débil. Y el propio agente lo reconoció explícitamente en sus registros: todavía no era suficientemente fiable como para confiar en él.

Vale la pena detenerse en ese comportamiento. El sistema probó, midió, se declaró insuficiente, volvió a probar y volvió a declararse insuficiente, en ciclos sucesivos, hasta llegar a una conclusión que no estaba en el plan original: la vía correcta no era seguir perfeccionando el detector propio, sino integrar una herramienta externa que ya resolviera ese problema.

6. El giro: delegar en una API especializada y descubrir el desacuerdo

La recomendación final del proceso de iteración fue conectar una API comercial (application programming interface, interfaz de programación que permite que un programa use los servicios de otro) de análisis de contenido visual con capacidad específica de detección de material generado por IA, disponible desde planes de suscripción de en torno a 29 dólares mensuales.

Hay una ironía que conviene no esquivar: el objetivo inicial era construir un detector, y la conclusión del propio sistema fue pagar por un detector ya existente. Esto no invalida el ejercicio, pero reordena su valor. Lo que se construye en un proyecto así rara vez es el algoritmo; es la envoltura: la interfaz, la ingesta de URLs de distintas plataformas, la extracción de fotogramas, la agregación de señales y la presentación del resultado. El componente forense se compra.

Un detalle práctico del proceso: el plan gratuito ofrecía 2.000 operaciones mensuales con moderación básica de contenido y detección de IA, pero no incluía procesamiento de vídeo, que era exactamente lo que el proyecto necesitaba. Es un patrón habitual en las capas gratuitas de las APIs comerciales, y conviene verificarlo antes de diseñar la arquitectura alrededor de un servicio.

La integración de la clave de acceso siguió el procedimiento estándar: un fichero de environment variables (variables de entorno), donde se guardan las credenciales fuera del código fuente para que no acaben publicadas por accidente. Prepararlo llevó unos veinte segundos de trabajo del modelo, y ni siquiera hizo falta usar la configuración más potente para una tarea tan mecánica: ajustar el nivel de esfuerzo del modelo a la dificultad real de cada tarea es una forma directa de ahorrar tiempo y coste.

Con la API integrada, apareció un problema nuevo y más interesante que los anteriores: el desacuerdo entre fuentes. Ante un vídeo sintético, la herramienta especializada marcaba indicios de IA en 19 de 23 posiciones muestreadas del metraje, mientras que el modelo multimodal no encontraba ningún indicio claro en el mismo material. La aplicación, correctamente diseñada para no fabricar certezas, resolvía ese conflicto declarando el resultado no concluyente y mostrando la discrepancia.

El comportamiento era técnicamente honesto y prácticamente inútil. Un usuario que pega una URL y recibe "no concluyente" no ha obtenido nada. Peor aún: el mismo veredicto aparecía también con vídeos evidentemente auténticos —una persona hablando a cámara—, con lo cual la etiqueta no distinguía nada. Cuando un sistema devuelve la misma respuesta para casos opuestos, esa respuesta no contiene información.

Además emergió un fallo del que conviene tomar nota: la aplicación informaba de que el análisis especializado solo admitía clips de menos de un minuto y hasta 50 megabytes. Esa restricción no procedía de ninguna especificación proporcionada por el usuario, sino que había sido introducida por el propio código durante alguna iteración. Los sistemas generados con asistencia de IA acumulan limitaciones autoimpuestas —umbrales, topes, filtros— que nadie pidió y que después se presentan al usuario como si fueran restricciones externas. Revisar periódicamente de dónde sale cada límite es parte del mantenimiento.

La solución final fue una decisión de arquitectura, no de algoritmo: establecer una jerarquía de fuentes en lugar de tratarlas como iguales. Dado que la herramienta especializada demostraba ser sensiblemente mejor en la tarea concreta de detección, se le dio prioridad sobre el análisis del modelo multimodal, y se elevó el límite de duración de los vídeos procesables. Treinta y un minutos de trabajo después, el sistema empezó a comportarse de forma útil: los vídeos auténticos devolvían ausencia de indicios claros —con justificaciones razonables como permanencia consistente de los objetos, contacto visual natural y coherencia acústica entre voz y ritmo—, y los sintéticos devolvían indicios detectados, incluidos casos procedentes de distintas plataformas.

El sistema resultante funciona, con una salvedad relevante: señala en qué momentos del metraje ha encontrado indicios, pero no explica qué ha visto exactamente. Marca posiciones, no razones. Para una herramienta de verificación, esa opacidad es una limitación seria, porque impide que el usuario evalúe por sí mismo si la señal es sólida.

7. El coste oculto: por qué el detector no pudo publicarse

El objetivo declarado desde el principio era poner la herramienta en línea para que cualquiera pudiera pegar una URL y consultar el resultado. No se cumplió, y el motivo no fue técnico sino económico.

Las APIs de análisis visual facturan por operaciones, y una operación no equivale a un vídeo. Analizar un vídeo implica extraer múltiples fotogramas y someter cada uno a inspección, de modo que una sola consulta puede consumir cientos de operaciones. En las pruebas del proyecto, un único análisis consumió 440 operaciones, y el contador acumulado superó las 12.000 operaciones tras procesar apenas media docena de vídeos, agotando una fracción sustancial de la cuota contratada.

Ese perfil de consumo hace inviable un servicio abierto financiado por una sola persona. Sin control de acceso, límites de uso por usuario ni un modelo de ingresos, bastarían unas pocas decenas de visitantes curiosos para agotar el presupuesto mensual. Y la imposibilidad de predecir de antemano cuántas operaciones consumirá un vídeo concreto —depende de su duración y del muestreo— convierte cualquier estimación de costes en una conjetura.

La alternativa que quedó fue publicar el código fuente para que quien quiera lo despliegue localmente y conecte su propia clave de API. Es una salida legítima y, de hecho, la habitual en este tipo de proyectos personales, pero cambia por completo el público destinatario: de "cualquiera que reciba un vídeo sospechoso" a "quien sepa clonar un repositorio, configurar variables de entorno y pagar una suscripción". Es decir, precisamente el público que menos necesita la herramienta.

La conclusión transferible es que en cualquier proyecto que dependa de APIs de pago, el modelo de costes debe modelarse en la fase de viabilidad, junto con la arquitectura. No es un detalle de última hora: es una restricción que determina si el producto puede existir en la forma imaginada.

8. Lecciones transferibles para quien quiera hacer vibe coding de su propia herramienta

Más allá del caso concreto, el proceso deja un conjunto de prácticas que se aplican a casi cualquier proyecto construido con asistencia intensiva de modelos de lenguaje.

Primera: separar la fase de viabilidad de la fase de construcción. Dedicar una conversación entera, sin escribir código, a que el modelo evalúe si el problema tiene solución, qué herramientas existen ya y qué precisión cabe esperar. Si la respuesta incluye "no será fiable al cien por cien", definir en ese momento qué nivel de error resulta aceptable.

Segunda: aportar contexto propio. Un modelo al que se le indica qué tecnologías existen y cuáles ya se han descartado produce planes sensiblemente mejores que uno al que se le lanza la idea en abstracto. Y reutilizar el contexto entre sesiones —pasando la conversación previa al agente de codificación en lugar de reexplicarlo todo— evita que la especificación se degrade.

Tercera: usar un modelo distinto para auditar el trabajo de otro. La revisión cruzada detectó en minutos fallos de lógica que llevaban horas incorporados al sistema. Un modelo revisando su propio código tiende a validarlo; uno que llega sin ese sesgo encuentra problemas reales.

Cuarta: desconfiar de las etiquetas de confianza que genera el propio sistema. Conviene rastrear de dónde sale cada indicador que se muestra al usuario y comprobar que ninguna capa intermedia convierte incertidumbre en certeza. Una confianza alta asignada automáticamente por un umbral numérico no es una confianza alta: es una regla de formato.

Quinta: auditar los límites autoimpuestos. Topes de tamaño, duración, formato o número de elementos que el código introduce durante alguna iteración y que después se presentan como restricciones inevitables. Preguntar explícitamente al modelo de dónde procede cada restricción es una comprobación barata y muy rentable.

Sexta: ajustar el nivel de esfuerzo a la tarea. Los modos de razonamiento prolongado son valiosos para depurar lógica compleja, y desproporcionados para preparar un fichero de configuración. Ejecuciones de ocho horas que terminan sin cumplir el objetivo indican que el problema estaba mal planteado, no que hiciera falta más cómputo.

Séptima: modelar los costes desde el principio. Si la solución depende de servicios de pago por uso, calcular el consumo por operación real antes de diseñar la interfaz. Es lo que separa un prototipo funcional de un servicio que puede existir.

Y octava, quizá la más importante: aceptar resultados parciales. El sistema resultante no era el producto abierto imaginado, pero sí una herramienta que funciona para su autor y que resuelve el problema original en su versión reducida. Distinguir entre el objetivo ideal y un resultado útil evita abandonar proyectos que sí aportan valor.

9. Qué haría falta para que un detector así funcionara de verdad

El obstáculo de fondo no es de ingeniería de aplicación, sino del estado del arte de la detección. Y admite una descomposición razonablemente clara.

Haría falta, primero, una adopción generalizada y resistente de los estándares de procedencia. Que las credenciales C2PA viajaran con el archivo a través de todas las plataformas, sobrevivieran a la recompresión y estuvieran presentes tanto en contenido sintético como auténtico. Con procedencia verificable el problema cambia de naturaleza: se deja de adivinar a partir de píxeles y se pasa a comprobar una firma. Hoy, en la práctica, esa comprobación devuelve casi siempre "sin credenciales", tanto para lo real como para lo generado.

Haría falta, segundo, marcas de agua interoperables entre proveedores. SynthID cubre lo que sale de las herramientas de Google, y hace bien lo que hace, pero un ecosistema con múltiples generadores —muchos de ellos abiertos y modificables— exige un mecanismo común. Y aun así quedaría fuera todo generador que decida sencillamente no marcar su salida, que es precisamente el escenario de quien produce contenido engañoso a propósito.

Haría falta, tercero, modelos multimodales genuinamente entrenados para detección forense y no solo para comprensión de escenas. La evidencia del caso es contundente en este punto: el mismo modelo que describe con precisión lo que ocurre en un vídeo es incapaz de identificar que ese vídeo es sintético. Son capacidades separadas y requieren entrenamiento específico.

Haría falta, cuarto, explicabilidad. Una herramienta que marca posiciones sospechosas sin decir qué encontró obliga al usuario a confiar a ciegas, lo cual reproduce el problema que pretendía resolver. Un detector útil debería poder señalar el artefacto concreto: esta sombra, esta transición, esta incoherencia de escala.

Conviene además incorporar una consideración estructural: existe una dinámica de persecución entre generación y detección. Cada mejora en la capacidad de detectar contenido sintético se convierte en una señal de entrenamiento para producir contenido menos detectable. Es un juego de gato y ratón sin equilibrio estable, lo que sugiere que la solución duradera pasa más por la procedencia verificable —demostrar de dónde viene algo— que por el análisis forense a posteriori.

Este caso alimenta también un argumento que circula en el debate sobre AGI (artificial general intelligence, inteligencia artificial general: sistemas tan capaces como cualquier persona en prácticamente cualquier tarea). Figuras destacadas de la industria, entre ellas el consejero delegado de Nvidia, Jensen Huang, han afirmado públicamente que la AGI ya ha llegado, y OpenAI ha sostenido que la era de la AGI está aquí. Frente a esas declaraciones, la observación que se desprende del ejercicio es incómoda: los modelos más avanzados disponibles públicamente fallan en una tarea que la mayoría de las personas resuelve en segundos. Enfrentados a material evidentemente sintético, responden que no pueden determinarlo.

Es un contraargumento acotado y hay que presentarlo como tal: no demuestra nada sobre las capacidades de sistemas no publicados, y la detección forense podría ser un caso atípicamente difícil por la dinámica adversaria descrita. Pero sí ilustra que la distancia entre la narrativa y la experiencia práctica sigue siendo considerable. Resulta significativo que la única pieza que acabó funcionando en este proyecto no fuera un gran modelo de lenguaje, sino un sistema de visión por computador especializado y entrenado para una tarea concreta.