Hace unas semanas escribí sobre por qué construí ViaMind Radar. Ese post era sobre el problema: demasiado ruido y poca claridad sobre qué merece atención.
Desde entonces Radar cambió bastante. Pensé que iba a ser más sencillo: conectar fuentes, dejar que la IA detectara las historias interesantes y publicar las mejores.
No lo fue. Lo difícil no fue que una IA encontrara noticias o escribiera. Fue decidir qué debía hacer el modelo y qué debía quedar bajo control del software.
¿Cuánto poder quiero realmente darle al modelo?
Con el tiempo, ViaMind Radar dejó de sentirse como una web de noticias con IA y empezó a convertirse en un sistema editorial automatizado con IA, software y reglas.
Radar no es un agente gigante
Desde fuera podría parecer un superagente que recorre internet y publica lo que considera importante.
No funciona así.
Es un pipeline editorial robusto: software, reglas y llamadas a modelos en etapas específicas. Y esta fue una de las primeras cosas que tuve que aprender: usar IA para todo no necesariamente hace que el sistema sea mejor. Hay tareas donde quiero exactamente lo contrario: comportamiento predecible.
El descubrimiento de nuevas URLs, la agenda, la publicación, los límites de presupuesto y los estados de las historias son principalmente software. La IA entra donde aporta juicio: interpretar lenguaje, evaluar relevancia, contrastar evidencia y escribir.
Radar trabaja sobre un catálogo controlado de medios, reguladores, blogs y documentos. El modelo no navega libremente por internet. Primero el software busca señales y genera candidatos. Después vienen los filtros, porque gastar recursos caros en ruido no tiene sentido.
La deduplicación ocurre en distintos momentos. Detectar la misma URL es una cosa. Detectar textos muy parecidos es otra. Entender que dos medios cubren el mismo evento es bastante más difícil. Ahí empieza el embudo editorial.
El flujo principal de ViaMind Radar. La IA entra donde aporta juicio; el software mantiene control sobre volumen, reglas y operación.
Una pregunta no es suficiente
Al principio lo pensaba como una sola pregunta: ¿esta noticia es buena o mala? Eso era demasiado simplista.
Hoy Radar separa al menos dos decisiones: ¿vale la pena investigar esto? Y después: ¿una vez investigado, realmente merece publicarse?
Una historia puede brillar en el titular y perder fuerza al revisar lo que hay detrás. Otra puede no parecer espectacular y terminar mostrando una señal más relevante. El modelo analiza dimensiones editoriales —un scoring, no una sentencia— y devuelve señales. El código recalcula, aplica reglas y decide hasta dónde puede avanzar.
El modelo puede opinar, pero no le entrego las llaves del sistema.
La parte cara empieza después
Cuando una historia supera ese embudo, empieza lo costoso. Radar construye un dossier, separa hechos reportados de promesas, inferencias y huecos, y compara las afirmaciones importantes con evidencia de las fuentes permitidas. Solo después viene la redacción.
La verificación ocurre antes de escribir. No quiero un texto bonito que después haya que justificar.
Eso no significa que Radar confirme independientemente todo lo que publica. Si una fuente dice algo, puede atribuirlo. No encontrar evidencia extra no lo vuelve falso, igual que encontrarla en una fuente no convierte al sistema en un investigador independiente. Parece una diferencia pequeña. No lo es.
La Mirada ViaMind es probablemente la parte más difícil
Si Radar solo resumiera noticias, el proyecto me interesaría bastante menos.
La parte que más intento proteger es la Mirada ViaMind. No quiero solamente explicar qué pasó. Quiero que el sistema se pregunte qué cambia realmente, quién gana, quién pierde, qué parte del anuncio podría estar exagerada, qué señal hay detrás y qué podría pasar después.
Un modelo puede escribir bien bastante rápido. Conseguir que piense de forma relativamente consistente dentro de una línea editorial requiere prompts, reglas, ejemplos, testing y, muchas veces, volver atrás porque una “mejora” empeoró otra parte.
READY: cuando la última milla dejó de ser inteligente
Uno de los cambios que más me ha servido fue una idea simple: READY. Una historia no entra a una ventana de publicación hasta estar lista. Entonces se agenda.
Cuando llega la hora, el sistema no vuelve a llamar un modelo ni a decidir. Publica algo que ya estaba preparado.
Al principio imaginaba que un sistema inteligente debía tomar decisiones cerca del final. Hoy prefiero lo contrario. La última milla debería ser aburrida.
Operar Radar no cuesta lo mismo que desarrollarlo
Hablar del coste de un sistema de IA sin separar operación y desarrollo puede ser engañoso. Intento gastar tokens donde realmente aportan valor, y hay un límite diario para que un flujo defectuoso no dispare llamadas indefinidamente.
En operación normal, Radar ronda un dólar al día. Ese número todavía puede mejorar. Pero no es el coste de construirlo.
Cuando hago un cambio importante, tengo que correr el sistema casi completo: una prueba de extremo a extremo desde cero. En algunos días he hecho cuatro de esas pruebas en preproducción y otras tres al pasar a producción. Fácilmente US$5 o US$7 solo en llamadas de Radar.
Y eso tampoco es todo. Desarrollarlo no es solo la API del producto. Es Claude, Codex y Cursor: las herramientas con las que escribo, reviso, depuro y vuelvo a probar. Ese gasto no aparece en la factura de publicar una historia, pero es parte real del coste. Si uno mira solo las llamadas del sistema en producción, el número queda a medias.
Es coste de desarrollo, no del producto. Pero sí cambia cómo hay que pensar el trabajo. Cada prueba realista de un sistema de IA también tiene un precio.
Control: automatizar no significa dejar de mirar
Esa diferencia entre operar y construir se nota también aquí. Cuando Radar se volvió más autónomo, empecé a necesitar una capa para entender qué está haciendo. Así nació Control.
No existe para aprobar cada noticia a mano. Eso destruiría el sentido de automatizar. Existe para observar, detectar bloqueos e intervenir si algo se sale del camino. Autonomía no significa ausencia de supervisión.
Control es la capa operativa desde donde puedo seguir historias, estados y flujos, e intervenir cuando algo necesita supervisión humana.
Radar ya no tiene un solo flujo
El proyecto empezó como un newsdesk y fue creando otros carriles: el Home Editor para la portada, un flujo semanal para las claves de la semana, y distribución social hacia LinkedIn y Buffer.
No quiero que Radar solamente produzca contenido. Quiero que también lo distribuya de forma consistente.
Radar ya no es un único proceso. Newsdesk, portada, resumen semanal, distribución y Control funcionan como carriles especializados alrededor del mismo sistema editorial.
La mayoría de las mejoras nacieron de cosas que salieron mal
Muchos de los cambios más importantes no nacieron de nuevas features. Nacieron de problemas.
En un momento parecía que el sistema no encontraba suficientes historias para llenar el día. No faltaban noticias: el presupuesto de tiempo para prepararlas era demasiado corto. Una sola candidata podía tomar uno o dos minutos, y el proceso se quedaba sin tiempo.
Otro problema vino de las imágenes. Podía existir una historia válida, investigada y lista, pero sin una imagen suficientemente segura, y eso rompía una ventana de publicación. La solución fue validar la imagen antes de reservar el espacio. Parece obvio después. Antes no lo era.
También tuve problemas de infraestructura. El 29 de agosto, en producción, el kernel mató el servicio de Radar cinco veces por falta de memoria (OOM). El host tenía menos de 4 GB de RAM y Radar llegaba a picos de 2,5 a 3,2 GB. Ese mismo día también se cayó un proceso de NeuraPRO. Días después, en preproducción, se acabó el heap de Node con demasiados trabajos abandonados en paralelo.
Puse límites de memoria y de procesos. Un sistema autónomo sin techos no solo puede gastar más tokens; también puede tumbar la infraestructura.
También he tenido scoring inestable, estructuras inválidas y respuestas truncadas. Cada uno de esos problemas terminó en una regla, un fallback o un cambio de arquitectura. Eso es lo menos visible cuando alguien ve un sistema funcionando.
Desarrollar con IA sigue siendo desarrollar
Desde fuera todavía existe una idea bastante simplificada: tienes una idea, se la explicas a una IA y la IA te construye la aplicación. Mi experiencia ha sido distinta.
Sí, puedo escribir código, explorar alternativas y construir solo cosas que hace algunos años probablemente habría necesitado un equipo. Pero el trabajo no desaparece. Cuanto más autónomo quiero que sea Radar, más preciso tengo que ser yo respecto de cómo debería comportarse.
Por eso miro con cautela la idea, bastante común en empresas, de pedir a los equipos que además de todo lo que ya hacen empiecen a desarrollar soluciones con IA. No porque la IA no ayude. Ayuda muchísimo. Pero usarla bien y mantener lo construido también requiere horas reales.
La IA no elimina el trabajo de ingeniería. Cambia dónde se concentra.
ViaMind Radar está lejos de estar terminado. Pero ya existe un pipeline editorial con IA que hace unos meses era solamente una idea. Y mientras más autónomo se vuelve, más importante me parece otra cosa: entender exactamente qué está haciendo y mantener la capacidad de controlarlo.
Eso ha sido una de las lecciones más interesantes de construirlo. No solamente aprender qué puede hacer la inteligencia artificial. También aprender dónde debería dejar de decidir ella y empezar a decidir el sistema.
Todo esto es lo que hoy está corriendo detrás de las historias que aparecen en ViaMind Radar.
Lecturas relacionadas:
- El problema ya no es encontrar noticias. Es saber cuáles importan.
- La IA no me dio nuevas ideas. Me dio la forma de construirlas.
- La factura de la IA: el problema del que casi nadie está hablando
✍️ Claudio from ViaMind
“Atrévete a imaginar, crear y transformar.”
POST DESTACADOS
SOBRE MI
Ecosistema ViaMind
- ViaMind — El núcleo de ideas, tecnología y estrategia.
- NeuraPRO — Software práctico para gestionar operaciones reales.
- ViaMind Radar — Menos ruido, más señal. Historias de tecnología curadas con IA.