LO QUE LA BÚSQUEDA VISUAL DELIBERADAMENTE NO ENTREGA

Los modelos de retrieval visual encuentran la página correcta, incluso en un escaneo difícil. Pero le devuelven una imagen, no texto. No puede copiar sin más una línea de ahí, ni tender una búsqueda de texto completo sobre el archivo, ni construir un rastro de auditoría legible por máquina. Para todo eso necesita texto reconocido. Esto no es una debilidad del nuevo enfoque, sino una división del trabajo deliberada: búsqueda sobre la imagen, obtención de texto por OCR, cada etapa para lo que mejor sabe hacer.

LO QUE PADDLEOCR-VL SABE HACER

Baidu ha presentado con PaddleOCR-VL un modelo OCR abierto que alcanza valores de primer nivel con apenas 0,9 mil millones de parámetros (proyecto). Reconoce texto, tablas, fórmulas y diagramas en 109 idiomas y reconstruye la estructura semántica de un documento. En el benchmark OmniDocBench v1.5 encabeza con alrededor de un 94,5% de precisión. Está bajo la licencia Apache-2.0, por lo que es de uso comercial libre y operable localmente. Para una pyme eso significa: reconocimiento de texto potente sin tarifa recurrente y sin fuga de datos.

EL MONTAJE HÍBRIDO

En la práctica, ambas vías corren en paralelo. La búsqueda visual encuentra las páginas relevantes de forma rápida y fiel al layout. Donde de ahí debe salir texto duro, por ejemplo para una posición de factura, una cláusula contractual que citar o una entrada en el ERP, el OCR se hace cargo justamente de esas pocas páginas. No hay que pasar todo el archivo por OCR, solo lo que la búsqueda ya ha marcado como importante. Eso mantiene el pipeline esbelto y evita que los errores de OCR se filtren en la búsqueda desde el principio.

LA LÍNEA PRAGMÁTICA

El o esto o lo otro es aquí la postura equivocada. La búsqueda visual mejora el encontrar, el OCR mejora el procesar después. Quien entiende ambos como herramientas con tareas claras construye la base de conocimiento más sólida que quien apuesta dogmáticamente por un solo bando. Cómo encajan las piezas, desde el encoder hasta la base de datos vectorial, está en el resumen del stack.

Para una empresa mediana que procesa a diario contratos, manuales técnicos y facturas de varias páginas, esa es la noticia más interesante. No que el reconocimiento de texto sea un par de puntos mejor, sino: un documento de 80 páginas ya no tiene que ser cortado en trozos y recompuesto, y para ello ningún documento tiene que salir de casa.

LO QUE HACE DISTINTO UNLIMITED-OCR

El núcleo es una atención modificada en el decoder que mantiene la memoria constante. Los modelos OCR clásicos basados en transformer dejan crecer la llamada KV-cache con la longitud del documento. Cuanto más largo el PDF, más memoria, hasta que en algún momento ya no cabe en un solo procesamiento.

Unlimited-OCR reemplaza esa parte por Reference Sliding Window Attention (R-SWA). La KV-cache permanece así constante, independientemente de la longitud del documento. Justamente eso significa el término one-shot long-horizon parsing: un documento largo se lee en una sola pasada, en lugar de descomponerlo en secciones y unir los resultados después.

Notable es la vía de entrenamiento. El equipo no empezó desde cero, sino que entrenó adicionalmente el checkpoint de DeepSeek-OCR: congeló el encoder y solo ajustó el decoder a lo largo de unos 4.000 pasos. Con ello el modelo está en línea directa con DeepSeek-OCR, que ya hemos situado en el contexto del stack. Código y pesos están abiertos en GitHub.

POR QUÉ CUENTA LA KV-CACHE CONSTANTE

El verdadero problema con los documentos largos no es la página individual, sino la coherencia a lo largo de las páginas. Cuando un modelo corta un documento de 60 páginas en bloques de diez páginas, se pierde justamente lo que cuenta en el día a día B2B: una tabla que cruza el salto de página, una cláusula que se refiere a una sección anterior, una posición cuya referencia está veinte páginas antes.

Una KV-cache constante permite mantener todo el documento en un solo contexto. La memoria no crece con la longitud, así que la estructura se conserva a lo largo de todas las páginas. De paso se vuelve más rápido: Baidu menciona en el modo base 5.580 tokens por segundo frente a 4.951 de DeepSeek-OCR, y con un límite de salida de 6.000 tokens la diferencia ronda el 35 por ciento.

En precisión, Unlimited-OCR se sitúa en OmniDocBench v1.5 en 93,23 puntos, 6,22 por encima de la base de DeepSeek-OCR, y en v1.6 en 93,92. Esas son las cifras del paper. En sus propios documentos, al final cuenta cómo el modelo maneja sus tablas, sellos y formularios, no el promedio de un conjunto de pruebas público. Emparentado está el desarrollo de los LLM subcuadráticos, que abaratan el contexto largo on-prem.

DÓNDE CAMBIA ALGO ESTO EN LA PYME

El beneficio surge allí donde documentos largos y estructurados deben convertirse en datos limpios y buscables. Unos cuantos puntos concretos:

• Contratos y acuerdos marco. Las referencias cruzadas y los anexos permanecen legibles en su contexto, en lugar de desmoronarse en los límites de bloque.
• Manuales técnicos y normas. Documentos largos con figuras, tablas y secciones numeradas en una sola pasada.
• Facturas y comprobantes de varias páginas. El texto extraído con limpieza es el paso previo para el procesamiento estructurado posterior, por ejemplo hacia la factura electrónica.
• Archivos y expedientes. Fondos que hasta ahora solo existían como escaneo se vuelven legibles por máquina, sin entregarlos a un servicio en la nube.

En casi todos los casos el OCR no es la meta, sino el primer paso. El texto parseado con limpieza es la base para una base de conocimiento con RAG: cuanto mejor el parsing, mejor encontrará la búsqueda después el pasaje correcto.

¿OCR O BÚSQUEDA VISUAL DE DOCUMENTOS?

No toda tarea documental necesita reconocimiento de texto clásico, y esa es una ponderación honesta. Existe ya toda una rama que ni siquiera convierte los documentos en texto, sino que los busca como imagen, con modelos como ColPali o ColQwen. Este enfoque libre de OCR lo hemos descrito por separado.

La regla práctica que a nosotros nos ha funcionado:

• Necesita los caracteres reales (importes de factura, cláusulas contractuales, extracción estructurada, traspaso a otro sistema): entonces difícilmente hay salida sin OCR, y un modelo como Unlimited-OCR es potente aquí.
• Necesita el pasaje adecuado, no el texto completo (responder una pregunta sobre un gran fondo, reencontrar una figura): entonces la búsqueda visual de documentos puede ser el camino más directo.

A menudo es ambas cosas a la vez. Unlimited-OCR abarata la parte de OCR de ese stack y la hace más fiable en documentos largos.

LO QUE COMPROBARÍA ANTES DE PONERLO EN PRODUCCIÓN

Un buen valor de benchmark es motivo para probar el modelo, no para ponerlo en producción. Antes de poner Unlimited-OCR en un proceso de cliente, comprobaría cuatro cosas:

🔸 Documentos en alemán y escritura a mano. Las cifras de benchmark dicen poco sobre formularios alemanes, expedientes antiguos o anotaciones manuscritas. Eso pertenece a un conjunto de pruebas propio de documentos reales.

🔸 Tablas y layout. En documentos B2B, la fidelidad de tablas y columnas decide la utilidad. Aquí vale la pena la comparación directa con el stack actual.

🔸 Hardware y operación. 3B como MoE con unos 500M de parámetros activos es realista on-prem. Lo que eso significa en concreto en memoria de GPU y rendimiento hay que medirlo antes del despliegue, no estimarlo.

🔸 Licencia y procedencia. MIT permite el uso comercial, on-prem, sin notas al pie. Que el rastro del modelo lleve a uno de los autores de DeepSeek-OCR es una señal de calidad, pero no reemplaza la propia verificación.

Lo realmente interesante de esta publicación es para mí menos el modelo en sí que la dirección: documentos largos en una sola pasada, suficientemente pequeños para el propio centro de datos, bajo una licencia que no restringe a nadie. Justamente ahí el procesamiento de documentos en la pyme se vuelve práctico. ¿Cuáles de sus documentos haría pasar primero?

MÁS ALLÁ DEL PROMPT

La ingeniería de prompts afina la pregunta. La ingeniería de contexto diseña el entorno en el que decide el modelo. Para una tarea puntual, un buen prompt basta. Para un agente que corre a lo largo de muchos pasos, lee herramientas y arrastra memoria, el prompt es una parte pequeña de lo que el modelo ve. El resto, lo que recuperas, lo que recuerdas, qué herramientas expones y cómo, es contexto, y decide mucho más del resultado. Por eso extender un harness de agente es en su mayor parte trabajo de contexto.

LOS CUATRO FALLOS CONTRA LOS QUE DISEÑAR

La mayoría de los fallos de agente se remontan a uno de cuatro problemas de contexto:

• Sobrecarga de contexto. Demasiado en la ventana. El modelo pierde el hilo, y el coste y la latencia suben. Más contexto no es mejor contexto.
• Envenenamiento de contexto. Un hecho erróneo o desactualizado entra en la ventana y el modelo lo trata como verdad. Un solo fragmento recuperado malo puede descarrilar una respuesta.
• Gestión de tokens. La ventana es finita. Sin un plan de qué conservar y qué descartar, el detalle importante queda expulsado por el ruido.
• Memoria obsoleta. Los agentes de larga duración acumulan contexto que ya no aplica, y actúan sobre él.

Nombrar el fallo es la mitad de la solución. Cada uno tiene un contramovimiento concreto.

PRÁCTICAS QUE AGUANTAN

Unos pocos patrones se repiten en montajes que se mantienen fiables:

1. Recupera, no viertas. Trae los pocos pasajes relevantes con buen retrieval en lugar de pegar todo. Ese es todo el sentido de RAG, y es la ingeniería de contexto aplicada a los datos.
2. Poda sobre la marcha. Aplica edición basada en reglas dentro del andamiaje para mantener la ventana esbelta: descarta lo que un paso ya no necesita.
3. Resume el historial largo. Reemplaza una transcripción larga por un resumen fiel antes de que desplace la tarea.
4. Empieza simple, escala según necesidad. Añade memoria y herramientas solo cuando un fallo real las exija, no por defecto.

El instinto de añadir más es la trampa. La disciplina es la sustracción.

POR QUÉ ESTA ES LA INGENIERÍA DE VERDAD

Un modelo más grande rara vez arregla un problema de contexto; solo falla de forma más cara. El trabajo que lleva a un agente de demo a fiable es casi por completo trabajo de contexto: qué ve, cuándo, y qué se le hace olvidar. Para entradas muy largas la arquitectura del modelo también importa, y ahí entran los enfoques subcuadráticos, pero para la mayoría de los equipos la ganancia está en el contexto, no en los parámetros.

EL MECANISMO, CON CLARIDAD

El RAG simple incrusta tu consulta, encuentra los pasajes más cercanos y responde a partir de ellos. RAG-Fusion añade dos pasos por delante. Primero, un modelo escribe un puñado de consultas alternativas que significan lo mismo desde ángulos distintos. Segundo, recupera para todas ellas y fusiona las listas clasificadas con fusión de rango recíproco, que premia los pasajes que se clasifican bien en varias consultas en lugar de en una sola. La respuesta se escribe luego a partir de ese conjunto fusionado y reordenado.

POR QUÉ IMPORTA EL PASO DE FUSIÓN

Una sola consulta es una sola conjetura sobre cómo está formulada la respuesta en tus documentos. Los archivos reales usan sinónimos, abreviaturas y redacciones distintas para lo mismo. Al preguntar de varias formas y premiar lo que se clasifica alto de forma consistente, RAG-Fusion saca a la luz el pasaje que una sola formulación habría perdido. La fusión de rango recíproco es el caballo de batalla silencioso aquí: combina listas sin necesitar puntuaciones comparables, que es también por lo que aparece en montajes híbridos y de interacción tardía como los que hay detrás de Qdrant y ColQwen.

CUÁNDO AYUDA Y CUÁNDO PERJUDICA

RAG-Fusion se gana su coste en preguntas ambiguas o cargadas de terminología, donde una sola formulación es una apuesta débil. Cuesta más: varias recuperaciones y un paso de generación por pregunta, así que no es latencia gratis. Y tiene un modo de fallo real. Si las variantes de consulta generadas se alejan de lo que en realidad querías decir, arrastran pasajes fuera de tema y la respuesta divaga. La solución es mantener las consultas generadas estrechamente ligadas a la intención original, y medir, no suponer, que el recall mejoró.

DÓNDE SE SITÚA ENTRE LAS OPCIONES

RAG-Fusion es una de varias formas de mejorar el retrieval, no un reemplazo de un buen retrieval. Antes de recurrir a ella, asegúrate de que lo básico se sostiene: chunks limpios, un modelo de embeddings sólido y un almacén vectorial adecuado a la tarea. Para documentos visualmente densos, la palanca mayor suele ser el retrieval visual en lugar de más variantes de consulta. Usa F-RAG donde la pregunta sea genuinamente ambigua y la ganancia de recall valga las llamadas adicionales.

EL PROBLEMA NUNCA FUE ANIMAR, SINO EL HANDOFF

Hasta ahora el movimiento de UI surgía fuera de Figma. La diseñadora lo construía en una segunda herramienta, exportaba un vídeo o una descripción, y el desarrollo tenía que reconstruir las curvas y los tiempos, a menudo a ojo. En ese proceso se pierde precisión: una curva de easing se vuelve una idea aproximada, un timing una estimación. Justamente esa ruptura, no la falta de herramientas de animación, ha hecho inconsistente el movimiento en muchos productos.

QUÉ APORTA FIGMA MOTION EN CONCRETO

Tres cosas cambian el flujo de trabajo de forma perceptible:

• Timeline en el canvas. Keyframes, presets y control de movimiento residen donde el diseño ya vive. Sin cambiar a una segunda herramienta.
• Movimiento como parte del sistema de diseño. Un componente se anima una vez, y el movimiento viaja como el color o la tipografía por cada pantalla y cada archivo. Ese es el punto que impone la consistencia en lugar de esperarla.
• Handoff legible. En el Dev Mode todo el timeline es visible: cada valor de timing, cada curva de easing, cada keyframe. La exportación va como CSS, JSON o React listo para el framework, además de MP4, WebM, SVG animado y GIF.

Con ello el desarrollo lee el movimiento en lugar de interpretarlo. Ese es el verdadero desplazamiento.

DÓNDE ESTÁ EL PERO

Una herramienta integrada no es automáticamente la correcta para cada caso. El trabajo de motion complejo y narrativo, por ejemplo una pieza de marca elaborada, sigue siendo cosa de herramientas especializadas. Figma Motion apunta a la animación de interfaz: estados, transiciones, microinteracciones, es decir justamente lo que se necesita a diario en el producto y hasta ahora sufría en la ruptura del handoff. Para esa clase de movimiento, la integración es la ganancia. Para todo lo que va más allá, la caja de herramientas sigue siendo mixta.

PARA QUIÉN VALE LA PENA MIRARLO

Quien mantiene un producto con patrones de UI recurrentes es quien más se beneficia: el movimiento definido una vez permanece consistente, y la implementación recibe valores exactos en lugar de aproximaciones. El movimiento no es aquí decoración, sino parte de la comprensibilidad de una interfaz, un punto que desarrollamos con más detalle en el papel clave del UX en el desarrollo de software. Figma Motion hace por fin editable esa parte en un solo lugar.

TRES LANZAMIENTOS, EN TÉRMINOS LLANOS

Cada uno de estos salió en una quincena respecto a los otros en junio de 2026, y cada uno es un tipo de cosa distinta. Vale la pena ser preciso, porque dos de ellos se describen mal por todas partes.

GLM-5.2, de Z.ai en Pekín, se publicó el 17 de junio. Es un modelo Mixture-of-Experts de pesos abiertos, unos 750 mil millones de parámetros con cerca de 40 mil millones activos, un contexto de un millón de tokens y, crucialmente, una licencia MIT con los pesos publicados en HuggingFace.

Sakana Fugu, de Sakana AI en Tokio, se publicó el 22 de junio. No es un modelo convencional, y el encuadre común lo entiende mal: Fugu es un orquestador entrenado que llama a un grupo de otros modelos y sintetiza su trabajo. Es solo API, ofrecido como un endpoint compatible con OpenAI.

Claude Fable 5, de Anthropic en Estados Unidos, se publicó el 9 de junio. El segundo error común es archivar a Fable como un nivel rápido o creativo. Es el buque insignia, el modelo más capaz de Anthropic de amplia difusión, con puerta de seguridad, solo en la nube, a 10 y 50 dólares por millón de tokens. Sus cifras de benchmark son fuertes; para este artículo también son irrelevantes.

LA ÚNICA COMPARACIÓN QUE SOBREVIVE A COMPRAS

Quita el ranking y alinéalos en las dimensiones de las que un comprador B2B alemán es realmente responsable. La imagen es clara, y no va sobre cuál es el más inteligente.

Dos salvedades honestas pertenecen a esta tabla. La vía por defecto de GLM-5.2, la API de Z.ai, se sitúa bajo las leyes de datos de China, con sus disposiciones de acceso obligatorio, que es justo por lo que importan los pesos abiertos: autoalojar en la UE neutraliza ese riesgo. Y la afirmación de Fugu de paridad frontera es totalmente autoinformada, debilitada por el hecho de que Fable y el restringido modelo Mythos ni siquiera están en su grupo. Yo no apostaría una decisión al benchmark de ninguno de los dos proveedores.

LO QUE REALMENTE LE DIGO A UN CLIENTE

No recomiendo uno de estos en abstracto. Ajusto la postura a lo que el cliente puede financiar y a lo que es responsable.

🔸 GLM-5.2 es la jugada on-prem. Los pesos abiertos MIT son todo el punto: puedes correrlo en tu propio centro de datos, y los prompts nunca salen de tu red. El pero es la huella de GPU, unos 744 gigabytes en FP8, así que encaja con el cliente que puede financiar el hardware y necesita que los datos se queden en el edificio. Es la historia de soberanía más limpia de los tres.

🔸 Claude Fable 5 es la jugada de garantía gestionada. Estás alquilando capacidad a un proveedor de EE. UU., al precio más alto de aquí, con puerta de seguridad real y enrutamiento regional de datos en las grandes nubes. Para un equipo que quiere un modelo puntero sin poseer el stack, y puede vivir con una dependencia de nube, es la opción gestionada más fuerte.

🔸 Sakana Fugu es la jugada de conveniencia, con la historia de control más débil. Una API que enruta a través de un grupo de modelos es ingeniosa, y Japón es una geopolítica más blanda que China. Pero no puedes correrlo on-prem, no eliges qué modelo ve los datos, y la evidencia es escasa. Yo lo trataría como interesante, no como un valor por defecto para trabajo regulado.

Esta es la misma lección que Claude Fable 5 enseñó por las malas cuando un modelo anterior se apagó en 72 horas: la capacidad alquilada es revocable, y el control es una propiedad del stack, no de la puntuación. Es por lo que sigo señalando a los clientes hacia modelos de pesos abiertos que de verdad pueden poseer.

LA PREGUNTA POR LA QUE VALE LA PENA DISEÑAR

Si te llevas una cosa de esto, que sea la pregunta, no el ranking. Los modelos volverán a intercambiar posiciones en el ranking dentro de un trimestre; esa parte es ruido. La pregunta duradera es la que un responsable de compras debería estar haciéndose el primer día: ¿cuál de estos puedes seguir corriendo, auditando y costeando cuando el proveedor cambie las condiciones? Para la mayoría de los clientes regulados con los que trabajo, esa pregunta se responde sola, y no apunta al benchmark más alto. Así que antes de elegir el modelo más inteligente, ¿qué te costaría perderlo?

QUÉ ES GEMINI OMNI EN REALIDAD

Acierta el nombre primero, porque el marketing lo difumina. La familia es Gemini Omni y el primer modelo es Gemini Omni Flash. Acepta texto, imagen, audio y vídeo como entrada, y en el lanzamiento produce una sola salida: vídeo, en clips de unos 10 segundos con audio sincronizado de forma nativa. Google lo describe como un paso hacia un modelo del mundo, es decir, intenta mantener la física, la gravedad y la coherencia espacial consistentes a lo largo de una escena generada, y corre en las TPU de 8.ª generación de Google divididas en variantes de entrenamiento e inferencia.

Una corrección honesta importa para un lector técnico: Omni se comercializa como cualquier-a-cualquier, pero tal como se entregó es cualquier-entrada-a-vídeo. Las salidas de imagen y audio están en la hoja de ruta, no en el producto. Así que no es un asistente omni conversacional en tiempo real, y aún no es el sistema universal cualquier-a-cualquier que el nombre sugiere. Es un generador de vídeo muy capaz y flexible en la entrada, que es algo más estrecho y más útil sobre lo que planificar.

ANUNCIADO, ENTREGADO Y DISPONIBLE SON TRES COSAS DISTINTAS

La distinción más útil para un comprador es que estos tres estados no son lo mismo, y Omni se sitúa en distintos según quién seas. Está entregado a consumidores y creadores, y meramente anunciado para todos los que construyen sobre una API.

La lectura práctica para una empresa de la UE es directa. Si necesitas residencia en la UE de grado RGPD para generación de vídeo hoy, Omni no puede dártela, porque su vía empresarial aún no existe. La opción soportada en el propio stack de Google sigue siendo Veo 3.1 en Vertex AI, que puedes fijar a una región de la UE. Este es el mismo patrón que seguimos viendo con los lanzamientos de modelos nuevos, donde la demo y el producto desplegable están a meses de distancia.

QUÉ DEBERÍA HACER AHORA UNA EMPRESA ALEMANA

Trata a Omni como una señal a seguir, no como una herramienta a adoptar este trimestre. Tres movimientos concretos.

• Usa Veo 3.1 fijado a región para vídeo de producción hoy. Tiene una API real de Vertex, regiones de la UE y un SLA. Omni no tiene nada de esto todavía, así que no pertenece a un pipeline de producción ahora.
• Planifica pronto la historia de procedencia. Omni incrusta una marca de agua SynthID en cada clip. Para contenido regulado o de cara al público, incorpora a tu proceso la expectativa de que el vídeo generado por IA se etiquete y se pueda rastrear, sin importar qué modelo gane.
• Vigila dos riesgos, no solo la capacidad. Los revisores han reproducido personajes registrados reconocibles en la salida de Omni, lo que es una exposición de propiedad intelectual real para uso comercial, y la consistencia visual aún se desvía en el movimiento rápido. El tope de 10 segundos es un límite de UX, no un techo del modelo, así que espera que se mueva.

El punto duradero es el que el lanzamiento hace por accidente: un modelo que puedes ver en una keynote no es un modelo que puedas desplegar bajo contrato. Separa los dos, y el bombo se convierte en un punto de la hoja de ruta en lugar de un error de compras.

QUÉ SE ENTREGÓ REALMENTE EN 2025 Y 2026

El titular es estabilidad tras años de agitación. LangChain 1.0 y LangGraph 1.0 alcanzaron ambos la versión estable el 22 de octubre de 2025, con el compromiso de no introducir cambios rompedores hasta la 2.0. La nueva abstracción estrella del framework, create_agent, corre ahora sobre el runtime de LangGraph por debajo, así que el bucle de agente es un grafo de LangGraph. Esa es la señal más clara de la fusión: el framework y el runtime de orquestación ya no son elecciones separadas.

LangGraph 1.0 trajo la ejecución duradera integrada: el estado se registra en checkpoints de forma automática, así que un flujo de larga duración o con humano en el bucle se reanuda tras una interrupción o un reinicio de servidor. LangSmith, la capa de observabilidad y evaluación, añadió soporte completo de OpenTelemetry en marzo de 2026, lo que significa que puedes enviarle trazas desde código que no use LangChain en absoluto. La imagen comercial acompañó a la técnica: LangChain Inc levantó una Serie B de 125 millones de dólares a una valoración de 1.250 millones en octubre de 2025, y renombró LangGraph Platform a LangSmith Deployment, plegando despliegue, observabilidad y evaluación en un solo producto.

CUATRO NOMBRES, DOS EMPRESAS

Aclarar quién hace qué es lo más útil antes de elegir. La mayoría de los artículos lo difuminan; acertarlo cambia la decisión.

LangFlow es el que hace tropezar a la gente. No es un producto de LangChain Inc. Es un constructor visual de código abierto creado por DataStax, cuya matriz fue adquirida por IBM en febrero de 2025, y ahora apunta hacia watsonx de IBM. La rima del nombre es una coincidencia. Si tu requisito es un lienzo de arrastrar y soltar para gente que no escribe Python, LangFlow es el candidato; no es una capa del stack de LangChain.

LA DECISIÓN QUE LA MAYORÍA DE LOS EQUIPOS REALMENTE ENFRENTA

Una vez claros los nombres, la elección suele ser un árbol de decisión corto, y rara vez necesitas los cuatro.

• ¿Necesitas orquestación duradera? LangGraph es la pieza más fuerte, y la que hasta los críticos tienden a respetar. Estado reanudable, checkpointing y humano en el bucle son ingeniería de verdad, no envoltorios.
• ¿Necesitas observabilidad y evaluación? LangSmith es capaz, pero te acopla al ecosistema. Langfuse es la contrapresión de código abierto y autoalojable, y la salida de emergencia más citada. Ahora que LangSmith habla OpenTelemetry, puedes trazar desde código que no use LangChain, lo que suaviza el lock-in.
• ¿Construyes un agente sencillo? Los SDK de proveedores (el OpenAI Agents SDK, el Claude Agent SDK) y Pydantic AI son alternativas creíbles y más ligeras. La queja dominante de los profesionales son las capas de abstracción del framework, y varios equipos reportan recortar código y mantenimiento al pasar a un stack más delgado.
• ¿No ingenieros prototipando? LangFlow, con la salvedad de que un prototipo en lienzo aún necesita la misma gobernanza y evaluación antes de entrar en producción.

Esta es la misma lección que sacamos al comparar cómo cablear la IA en un stack a través de una API, un servidor MCP o un CLI: las herramientas son capas, y eliges por la tarea, no por la novedad. También rima con lo que encontramos al mirar constructores de agentes no-code para la pyme, donde el lienzo te consigue una demo rápido y se detiene justo en la gobernanza, la fiabilidad y el coste.

ESTABLE NO SIGNIFICÓ ENDURECIDO

Una salvedad importa para un público de negocio: 1.0 compró estabilidad de API, no una postura de seguridad endurecida. Un grupo de CVE aterrizó contra LangChain y LangGraph a finales de 2025 y comienzos de 2026, encabezado por un fallo de deserialización que podía filtrar claves de API y secretos de entorno, calificado CVSS 9.3 y apodado LangGrinch. Siguieron dos más: un problema de path-traversal en la API de carga de prompts, y una inyección SQL en el checkpointer SQLite de LangGraph.

La lectura práctica no es evitar el framework. Es tratarlo como cualquier otra dependencia que toca tus secretos y tus datos: fija versiones, aplica las releases parcheadas e inclúyelo en tu modelo de amenazas. Un framework que orquesta llamadas a herramientas y guarda credenciales es parte de tu superficie de ataque, y "estable" en el número de versión dice poco sobre eso. Para un despliegue regulado u on-prem, esa revisión pertenece a la misma conversación que la residencia de datos, no después del go-live.

EL PROBLEMA CON EL VECTOR ÚNICO

La búsqueda vectorial clásica comprime todo un pasaje de texto o toda una página en un único vector. Es económico, pero promedia y borra lo que es localmente importante. Si el importe buscado está en una celda concreta de una tabla, esa referencia desaparece en el promedio de toda la página. Para texto corrido limpio suele bastar. Para los documentos ante los que la búsqueda visual siquiera compite, no basta.

LATE INTERACTION, EN UNA FRASE

Late Interaction conserva muchos vectores por página y los compara tarde, solo al buscar. El modelo genera para la consulta un vector por token y para la página un vector por fragmento. La puntuación se llama MaxSim: para cada token de la consulta se busca el fragmento de página que mejor encaja, y esos mejores aciertos se suman. Así la palabra "saldo restante" puede acoplarse con precisión a la celda de tabla en la que está. La técnica proviene de ColBERT y se trasladó a imágenes con ColPali. Quien quiera ver toda la caja de piezas: el stack libre de OCR ordena los modelos.

DÓNDE ENTRA QDRANT EN JUEGO

Late Interaction necesita una base de datos que entienda varios vectores por objeto. Qdrant soporta tales multi-vectores directamente, sin pre ni posprocesamiento, y puede sostener cualquier modelo de Late Interaction como ColBERT o ColPali (documentación). El montaje habitual es en dos etapas: una primera búsqueda rápida con vectores densos normales acota los candidatos, luego MaxSim puntúa con precisión solo esas pocas páginas. Así el índice sigue siendo asequible, porque los costosos vectores de token no tienen que indexarse por completo, sino que sirven para la reordenación.

QUÉ SIGNIFICA ESTO EN LA PRÁCTICA

Obtiene aciertos que respetan el layout, sin volver la búsqueda impagable. El precio es más memoria por página y algo más de complejidad en el montaje. Ambos son manejables si se planifica la etapa de reordenación desde el principio en lugar de indexar por completo cada vector de token. Para contextos muy largos vale la pena mirar los modelos subcuadráticos; para la idea básica de retrieval, Qué es RAG sigue siendo el punto de entrada.

POR QUÉ EL TAMAÑO SE VUELVE AQUÍ UN OBSTÁCULO

Los modelos de retrieval visual como ColPali o ColQwen son certeros, pero también son grandes. On-prem, es decir, sobre hardware propio en casa, eso se vuelve rápido una cuestión de coste: los modelos grandes exigen GPU potentes, más memoria, más electricidad. Para muchos montajes de pyme, el obstáculo no es la calidad, sino la factura del hardware. Justamente aquí aplica un modelo más pequeño la palanca.

QUÉ HACE DISTINTO MODERNVBERT

ModernVBERT es un encoder compacto de visión y lenguaje con 250M de parámetros (paper). Combina un moderno text-encoder de 150M basado en ModernBERT con un pequeño image-encoder y alinea ambos mediante un objetivo de Masked-Language-Modeling. ColModernVBERT es la variante ajustada para retrieval. El resultado según el paper: pese a unas diez veces menos parámetros, queda solo 0,6 nDCG@5 por debajo de ColPali en el benchmark agregado ViDoRe y alcanza así valores para los que antes hacían falta modelos casi diez veces más grandes. Modelo y código están disponibles de forma abierta.

POR QUÉ ESTO CUENTA PARA LA SOBERANÍA

Un modelo pequeño, abierto y potente es justamente la combinación que hace posible la operación local. Cabe en una GPU modesta, los pesos están abiertos, y los documentos permanecen en casa, porque la búsqueda no va a un endpoint ajeno. Eso no es una función de seguridad añadida a posteriori, sino una propiedad de la arquitectura. El contexto mayor, por qué local y abierto van juntos, lo tratamos en On-Premise contra Cloud.

CUÁNDO EL MODELO PEQUEÑO ES LA ELECCIÓN CORRECTA

No siempre hace falta el modelo más grande. Si su hardware es limitado y sus documentos son documentos de negocio típicos, ColModernVBERT es a menudo la elección más honesta que ColQwen: casi la misma calidad, una fracción del coste. Si necesita el último ápice de precisión en páginas especialmente densas, vale la pena la comparación con el modelo más grande. Cómo interactúan ambos en el stack completo con Qdrant está en el resumen.

Qué hace fuerte a n8n

n8n es automatización de flujos basada en nodos, autoalojada o en la nube, con más de 400 integraciones más un nodo HTTP y nodos de código para todo lo demás (n8n). El punto decisivo para sectores regulados: corre en casa, los datos no salen de la infraestructura. La licencia Fair-Code permite el uso interno sin tarifa. Quien necesita lógica propia, endpoints propios y control total de los datos, está aquí en lo correcto. El precio de ello es la operación: usted mismo aloja, actualiza y respalda.

Qué hace fuerte a Make.com

Make.com es un servicio en la nube con escenarios visuales que prescinde de operación propia. Se arma un flujo a clics y corre, sin servidor, sin mantenimiento. Para equipos sin profundidad técnica o para una idea rápida, ese es el camino más corto. Se factura por operación, es decir, por paso ejecutado. Eso es barato con volúmenes pequeños y puede crecer de forma incómoda con flujos grandes y frecuentes. El reverso de la comodidad: los datos corren a través de un servicio ajeno, y la lógica permanece dentro de sus límites.

La decisión en una tabla

La línea divisoria es clara: control de datos y profundidad frente a velocidad sin operación propia.

Nuestro consejo pragmático

Prototipe rápido, aloje de forma consciente. Para una primera prueba que solo deba mostrar si un flujo sostiene, Make.com suele ser más rápido. En cuanto entran en juego datos sensibles, altos volúmenes o lógica propia, gana n8n, porque corre en casa. Y donde la automatización roza tareas reales de IA, vale la pena mirar los agentes no-code y sus límites: automatización y agente no son la misma herramienta.

Por qué el OCR era la parte tambaleante del pipeline

El OCR fue durante mucho tiempo el punto por el que entraban errores silenciosos en la respuesta. El camino clásico es una cadena: escanear la página, convertirla por OCR en texto, cortarla en trozos, incrustar, recuperar. Cada etapa pierde algo. Una página de dos columnas se recompone mal, una tabla se desmorona en cifras inconexas, un diagrama cae del todo, porque no es texto. En nuestra experiencia, en documentos difíciles la mayor parte del problema de calidad no está en el modelo de lenguaje, sino aquí, en la lectura. El retrieval visual aplica justo en esa etapa: se salta el reconocimiento de texto al buscar y trabaja sobre la imagen de la página.

Las cuatro piezas, brevemente explicadas

ColPali. La referencia, presentada en julio de 2024 (arXiv). Se construye sobre el modelo de visión y lenguaje PaliGemma y genera unos 1024 vectores de fragmento de imagen por página, cada uno de 128 dimensiones. En lugar de comprimir la página en un único vector, la granularidad se conserva. El cotejo pasa por Late Interaction, una técnica tomada de ColBERT que desglosamos aquí con más detalle.

ColQwen. La misma receta, otra base: ColQwen2.5 apuesta por Qwen2.5-VL en lugar de PaliGemma y suele ir por delante en el benchmark ViDoRe. Quien empieza hoy de cero, empieza sensatamente aquí.

ModernVBERT. La palanca de eficiencia. ColModernVBERT tiene 250M de parámetros, es decir, unas diez veces menos que ColPali, y según el paper queda aun así solo 0,6 nDCG@5 por debajo. Es la pieza que hace asequible el retrieval visual on-prem.

Qdrant. La infraestructura de debajo. Qdrant almacena los multi-vectores de estos modelos de forma nativa y calcula la puntuación de Late Interaction al buscar (documentación). Sin una base de datos vectorial que entienda varios vectores por página, no corre ninguno de los tres encoders.

Cuándo vale la pena el cambio, y cuándo no

El retrieval visual gana allí donde el layout porta la información. Contratos escaneados, facturas, hojas de datos, presentaciones, formularios, expedientes multilingües: todo aquello en lo que una cadena de OCR fracasa con regularidad. Además ahorra todo el mantenimiento de esa cadena.

Pero no es una ganancia general. Varios vectores por página cuestan más memoria y más índice que un único vector de texto, a menudo varias veces más. Con texto corrido limpio y puro, el RAG de texto clásico sigue siendo más barato y del todo suficiente. Y algunas tareas necesitan al final texto de todos modos, por ejemplo búsqueda de texto completo, copiar o un rastro de auditoría. Para eso sigue habiendo buenas razones para el OCR, en el híbrido junto al retrieval visual.

Una hoja de ruta sobria

1. Probar con los propios documentos, no con el benchmark. ViDoRe es una buena referencia, pero su situación de expedientes no lo es. Tome las veinte páginas en las que su búsqueda actual fracasa.
2. Empezar con ColQwen o ColModernVBERT, según el hardware. En una GPU justa, el modelo pequeño suele ser el más honesto.
3. Montar Qdrant como almacén multi-vector, Late Interaction solo en la etapa de reordenación, para mantener el índice pequeño.
4. Calcular el precio de memoria de antemano. El tamaño del índice es el punto que después duele, no la elección del modelo.

Quien busca el arco mayor, es decir, por qué los modelos locales y el retrieval propio van juntos: eso está en On-Premise contra Cloud. Las piezas individuales las profundizamos en textos propios, empezando por la mirada de la pyme.

La brecha entre una malla y una pieza

Una malla generada y una pieza fabricable son objetos distintos, y la brecha no es cosmética. Tres restricciones lo evidencian. Primero, imprimir necesita un sólido estanco y de variedad (sin agujeros, sin normales invertidas, sin autointersecciones), y las mallas generativas violan esto de forma rutinaria; un slicer no puede hacer una pieza a partir de una superficie con huecos. Segundo, una malla es una sopa estática de triángulos, mientras que la fabricación quiere un modelo B-rep paramétrico (un archivo STEP con bocetos, features y restricciones) que un ingeniero pueda editar y un sistema CAM pueda mecanizar. Ninguna de las herramientas image-to-mesh produce eso.

Tercero, y lo más fundamental, una sola imagen no lleva escala métrica. El modelo asigna una cámara conjeturada y produce una forma sin milímetros garantizados, sin espesor de pared impuesto, sin tolerancias. Y como una foto solo ve un lado, el lado oculto no se reconstruye, se imagina: el modelo rellena la geometría no vista con un promedio plausible. Un asset de videojuego puede esconder todo esto tras una textura bonita. Una pieza no puede, porque a la impresora y a la carga no les importa cómo se ve.

Dos pipelines que el bombo difumina

La forma más clara de planificar es separar dos pipelines que el marketing junta. Sirven a piezas distintas y necesitan herramientas distintas.

El primer pipeline es real hoy para piezas donde el ajuste es indulgente. La IA bloquea la forma; una persona aún se ocupa de hacerla estanca, escalarla a dimensiones reales y correr una comprobación de imprimibilidad. El segundo es donde se sitúa la frontera relevante para la fabricación: la investigación de image-to-CAD como CAD-Recode e Img2CAD genera geometría paramétrica editable, y herramientas comerciales como Zoo pueden exportar un archivo STEP real, pero están en gran medida limitadas a piezas más sencillas por ahora. Para geometría exigente, la ingeniería inversa clásica basada en escaneo (Geomagic, PolyWorks) sigue siendo la ruta fiable. Este es el primo de fabricación de la pregunta que hicimos sobre la reconstrucción humana a partir de una sola imagen: una superficie plausible no es lo mismo que un sólido en el que se puede confiar.

Qué es real para un fabricante de pyme hoy

Frente al bombo, las victorias genuinas son más silenciosas y más valiosas que sacar una pieza de un tirón desde la foto de un móvil. La cuña real más fuerte es digitalizar lo que ya tienes: herramientas como Theia de Spare Parts 3D y el análisis de planos de 3YOURMIND convierten planos técnicos 2D antiguos en modelos de repuestos imprimibles, reportado como hasta 200 veces más rápido que redibujar a mano, con una comprobación de fabricabilidad adjunta. Eso es image-to-3D donde la entrada es un plano de ingeniería, no una instantánea de vacaciones, y la geometría está anclada en dimensiones reales.

Las otras victorias sólidas son la aceleración de la ingeniería inversa, donde la generación por IA y la retopología inteligente aceleran un flujo existente basado en escaneo en lugar de reemplazarlo, y el prototipado rápido de piezas no críticas. Donde falla es justo donde las apuestas son más altas: piezas portantes, de tolerancia estrecha y reguladas, que necesitan escala, especificación de material y trazabilidad que una sola imagen no puede proporcionar. La regla que llevarse es corta. Para una pieza que soporta peso o pasa una auditoría, el lado no visto es siempre una conjetura, y una conjetura es un defecto.

La diferencia real, en una línea cada una

La ingeniería de prompts es redactar bien una instrucción. La ingeniería de contexto es decidir qué ve el modelo en absoluto. El término fue popularizado en junio de 2025 por Tobi Lutke de Shopify y amplificado por Andrej Karpathy, que lo describió como el arte de llenar la ventana de contexto con justo la información adecuada para el siguiente paso. La distinción más limpia viene de Philipp Schmid: el contexto es todo lo que el modelo ve antes de generar una respuesta, y eso es un sistema, no una cadena.

Los dos no son rivales; la ingeniería de prompts es un subconjunto. Cuando escribes un buen prompt de sistema, eso es ingeniería de prompts. Cuando decides qué tres documentos recuperar, qué herramientas exponer, cuánto historial conservar, qué resumir y descartar, y qué esquema de salida exigir, todo bajo un presupuesto de tokens, eso es ingeniería de contexto. La propia guía de Anthropic lo encuadra como gestionar todo el estado del contexto a lo largo de los turnos, y su frase más afilada es la que vale la pena conservar: el contexto es un recurso finito con rendimientos marginales decrecientes.

Por qué el campo cambió, y no fue moda

La razón por la que la ingeniería de contexto se volvió una disciplina con nombre es que la suposición fácil se rompió bajo la medición. La suposición era que los modelos de contexto largo te dejan atiborrar la ventana y dejar de pensar. El estudio Context Rot de Chroma probó 18 modelos frontera en julio de 2025 y encontró que cada uno degrada a medida que crece la entrada, a menudo de formas no uniformes: el modelo no maneja el diezmilésimo token de forma tan fiable como el centésimo. El hallazgo más antiguo de lost-in-the-middle apuntaba en la misma dirección.

Dos fuerzas hicieron de la carga, no del prompt, la cosa a ingenierizar. Primero, los agentes, el uso de herramientas, el retrieval y la memoria significan que el contexto lo ensambla a lo largo de muchos turnos un sistema, no se escribe a mano una vez. Segundo, la economía: en producción en Manus, la proporción de tokens de entrada a salida ronda 100 a 1, y reutilizar la caché clave-valor genera una gran diferencia de coste, así que lo que pones en la ventana es una decisión de coste tanto como de calidad. Más contexto no es mejor; el contexto presupuestado y relevante lo es. Esta es la columna vertebral empírica bajo nuestro recorrido anterior por la ingeniería de contexto y por qué importa.

De qué está hecha realmente la ingeniería de contexto

Despojada de la etiqueta, la ingeniería de contexto es un conjunto de prácticas comprobables, no susurros de prompt. Las técnicas nombradas se repiten en Anthropic, LangChain y el artículo de producción de Manus:

• Retrieval. Trae los pocos documentos relevantes en el momento en que se necesitan, en lugar de pegar todo. Esta es la disciplina detrás de la generación aumentada por recuperación.
• Compactación y resumen. Comprime turnos viejos en un resumen rodante para que el presupuesto se gaste en lo que está vivo, no en la transcripción.
• Memoria y toma de notas. Descarga el estado a notas o archivos externos que el agente pueda releer, en lugar de arrastrarlo en la ventana.
• Curación de herramientas. Mantén de tres a cinco herramientas centrales cargadas y trae el resto justo a tiempo. Cargar cada herramienta diluye la señal y rompe la caché.
• Salidas estructuradas. Exige un esquema para que el modelo gaste tokens en la respuesta, no en la prosa de formato.
• Aislamiento. Reparte el trabajo entre subagentes para que cada uno vea solo el contexto que necesita.

LangChain encuadra el mismo conjunto como escribir, seleccionar, comprimir y aislar. El punto es que cada una de estas es medible: puedes hacer A/B a un recuperador, un umbral de compactación o un conjunto de herramientas, que es exactamente lo que hace de esto ingeniería en lugar de fraseo.

¿Es solo un cambio de marca? La respuesta honesta

En parte, y está bien. Sí, los buenos ingenieros ya curaban lo que el modelo ve; el valor del nombre es que apunta la optimización a la carga y al sistema, no a la frase, que es donde viven de verdad la fiabilidad y el coste. El debate vivo es más útil que la discusión terminológica. En junio de 2025, Cognition argumentó contra los sistemas multiagente, con el fundamento de que compartir contexto con limpieza entre agentes es difícil, y recomendó mantener el trabajo de un solo agente y compartir trazas completas. La misma semana, Anthropic describió un sistema de investigación multiagente que depende de un aislamiento de contexto disciplinado. Misma disciplina, conclusión arquitectónica opuesta.

Para un equipo que construye con LLM, las conclusiones son llanas. Presupuesta tokens como presupuestas cómputo, porque más no es gratis ni siempre mejor. Trata el trabajo como fontanería (calidad del retrieval, compactación, memoria, curación de herramientas, salidas estructuradas), no como fraseo. Y elige tu arquitectura según lo fiablemente que puedas compartir contexto, en lugar de por qué enfoque suena más avanzado. El nombre seguirá mutando, algunos ya llaman a la siguiente capa ingeniería de harness, pero el objeto es estable: el sistema que decide qué puede ver el modelo.

Empieza por el suelo, no por el techo

Antes de cualquier método ingenioso, acierta la base, porque arregla la mayoría de las quejas. El valor por defecto de producción de 2026 es la búsqueda híbrida (embeddings densos más BM25 por palabra clave) seguida de un reranker de cross-encoder. La búsqueda híbrida capta tanto coincidencias semánticas como de término exacto; el reranker repuntúa un gran conjunto de candidatos hasta los pocos pasajes que son de verdad relevantes, no solo temáticamente cercanos. Las guías de profesionales reportan que esta combinación eleva la calidad del retrieval del 15 al 30 por ciento en conjuntos de evaluación estándar.

Esto importa porque la mayoría de los fallos del mundo real son del tipo simple: la respuesta estaba en los documentos, pero el sistema no la sacó a la luz. Eso es un problema de recall y ranking, y el suelo de arriba lo arregla. Demuestra que necesitas más antes de construir más. Cada técnica más allá de este punto añade llamadas al LLM, latencia y coste, así que cada una debe ganarse su lugar contra un fallo medido, no una corazonada.

La caja de herramientas, indexada por el fallo que arregla

La forma útil de sostener todo el zoológico de métodos es mapear cada uno al único modo de fallo que aborda. Recurre a un método cuando veas su fallo, no antes.

Cada fila tiene procedencia real: HyDE viene de un paper de CMU de 2022 sobre retrieval denso zero-shot; el prompting de paso atrás de Google DeepMind, 2023; GraphRAG de Microsoft, 2024. Esta es la misma disciplina de decisión por fallo detrás de nuestra mirada a RAG-Fusion y en qué se diferencia del RAG simple.

Descomposición de consultas, en concreto

La descomposición de consultas divide una consulta compleja en subpreguntas independientes, recupera para cada una y luego sintetiza una respuesta. Es la herramienta correcta cuando una sola pasada de retrieval no puede funcionar, porque los hechos viven en distintos documentos o un hecho depende de otro (quién dirigió la película que ganó un premio concreto). El linaje corre del prompting de menos a más de 2022 a los motores de consulta de subpreguntas de los frameworks actuales.

La parte honesta es que no es gratis, y puede perjudicar. Un estudio de julio de 2025 de HU Berlin midió que la descomposición más reranking elevó el recall multisalto (Hits@10) del 74,7 al 87,2 por ciento, una ganancia real. El mismo estudio midió el coste: unos 16,7 segundos por consulta frente a 0,03 segundos para el retrieval ingenuo, y encontró que descomponer una consulta ya específica introduce ruido y empeora la respuesta. Así que la descomposición pertenece a preguntas genuinamente multisalto, no a cada consulta por defecto. La habilidad es distinguir las dos.

La palanca que se paga sola es el enrutamiento

Si te llevas una idea operativa de esto, que sea el enrutamiento. Clasifica la consulta primero, luego gasta complejidad solo donde se gana. Un análisis de 2026 sobre enrutamiento consciente del coste recortó los tokens facturados un 26 por ciento y la latencia media un 34 por ciento a igual calidad de respuesta, enviando solo alrededor del 18 por ciento de las consultas a retrieval pesado y el 14 por ciento a ningún retrieval en absoluto. Los métodos caros se reservaron para las consultas que los necesitaban.

Para un equipo de una pyme alemana esto es una historia de gobernanza y coste tanto como de calidad. Menos llamadas al LLM justificadas significan gasto predecible, menor latencia y un sistema que puedes explicar a una parte interesada consciente del cumplimiento: aquí está por qué esta consulta tomó el camino caro, y aquí por qué aquella no. El retrieval sobreingenierizado no solo es lento, es gasto inexplicable. El sistema RAG sofisticado en 2026 es el que sabe cuándo no usar ninguno de sus trucos.

Qué sabe hacer bien de verdad la RPA

La RPA es basada en reglas y determinista. Describe un flujo fijo, y corre cada vez igual: misma entrada, mismo camino, mismo resultado. Para un proceso estructurado y estable, por ejemplo transferir datos de un formulario fijo a un ERP, es justamente lo correcto. Es verificable, repetible y barato de operar. La debilidad se muestra solo cuando algo cambia: un nuevo layout de campos, una entrada inesperada, y la regla rígida se rompe.

Qué saben hacer mejor los agentes de IA

Un agente de IA entra en juego allí donde el flujo no es rígido: entradas ambiguas, lenguaje libre, decisiones que necesitan contexto. Puede leer un correo no estructurado y hacer lo correcto, donde una regla de RPA capitularía. El precio es que no es determinista: la misma entrada puede entregar dos resultados, y necesita guía, barandillas y verificación. Hasta dónde llegan los agentes no-code y dónde se detienen lo tratamos en otro lugar.

La línea de decisión

Una heurística simple separa los casos:

• Estable y estructurado (formulario fijo, regla clara, alta repetición): RPA. La fiabilidad le gana a la flexibilidad.
• Ambiguo y lingüístico (textos libres, entradas cambiantes, cuestiones de juicio): agente. La flexibilidad le gana a la rigidez.
• Mixto: a menudo la mejor respuesta. La RPA hace la parte fija, el agente asume solo el punto que de verdad exige juicio.

Las cifras del mercado invitan a la sobriedad: Gartner espera que más del 40 por ciento de los proyectos de IA agéntica se cancelen para finales de 2027. Muchos de ellos, porque se usó un agente donde una regla habría bastado.

El término medio sobrio

No IA o RPA, sino el nivel correcto para la parte correcta. El error más caro es dejar un flujo fiable y reglable a un agente no determinista, solo porque la IA suena más moderna. Empiece con la pregunta por la tarea, no por la herramienta. Dónde pertenece de verdad la IA en el stack y a través de qué interfaz lo ordena API frente a MCP frente a CLI.

Qué hace realmente SAM 3D Body

SAM 3D Body reconstruye una malla humana de cuerpo completo, incluidas manos y pies, a partir de una sola imagen, estimando tanto la pose como la forma. Introduce un nuevo formato de cuerpo paramétrico, el Momentum Human Rig (MHR), que desacopla el esqueleto de la superficie de tejido blando, de modo que el rig y la forma del cuerpo se pueden razonar por separado. Como el resto de la familia Segment Anything es promptable: puedes pasar keypoints 2D o máscaras de segmentación para guiar el resultado.

Los detalles prácticos importan para cualquiera que planee desplegarlo. Meta distribuyó pesos abiertos en dos backbones, un DINOv3-H+ de unos 840M de parámetros y un ViT-H de unos 631M, junto con código de inferencia, datos de entrenamiento y el modelo MHR. Reporta un error de malla en 3DPW (MPJPE) de 54,8, y ya alimenta una función de consumo en vivo, la de Facebook Marketplace View in Room. Se entrenó con unos 8 millones de imágenes. Esto no es una demo de investigación; entró en un producto el día uno.

La victoria B2B es el pipeline, no los píxeles

El punto estratégico para una empresa alemana o de la UE es dónde corre el cómputo, no qué tan ingeniosa se ve la malla. Una imagen de cuerpo humano es dato personal sensible bajo el RGPD. En el momento en que envías la foto de un cliente a una API de reconstrucción de terceros, tienes un contrato de encargo de tratamiento, una cuestión de transferencia y un coste de confianza. Los pesos abiertos eliminan ese paso: ejecutas el modelo dentro de tu propia red, y la imagen del cuerpo nunca sale.

Eso reencuadra varios casos de uso de incómodos a apropiables. La prueba virtual y la visualización de ajuste, los avatares de AR y VR, la analítica de fitness y movimiento, y el previz para animación o producción virtual pueden todos correr en infraestructura que controlas, con la misma UX que daría una API alojada. Esta es la misma lógica de pipeline propio que aplicamos a generar assets 3D a partir de una sola imagen con TRELLIS: el valor no es solo el modelo, es mantener la entrada sensible en tu propio lado del muro. La licencia es lo único que verificar antes de construir: el rig MHR está confirmado como comercial permisivo, y los pesos del cuerpo se distribuyen bajo la SAM Licence, así que lee los términos reales para tu uso.

Dónde se rompe en silencio

Dimensionar el caso de uso correctamente es toda la habilidad, porque la reconstrucción a partir de una sola imagen tiene límites honestos que ninguna cantidad de calidad de modelo elimina. El análisis independiente encontró que SAM 3D Body prioriza una pose plausible sobre la precisión métrica, y empujará cuerpos atípicos (escoliosis, cambios por edad, embarazo) hacia un promedio sano. Eso está bien para un avatar que debe verse bien; está mal para el dimensionamiento médico, ergonómico o legal, donde la desviación es el punto.

Tres límites más para los que diseñar. Una sola imagen no puede resolver profundidad ni escala verdadera, así que la posición global y las dimensiones del mundo real son conjeturas poco restringidas. La oclusión fuerte, donde la mayor parte del cuerpo está oculta, lo degrada de forma pronunciada. Y es por imagen, no en tiempo real: la comunidad ya corre por arreglarlo con variantes más rápidas y runtimes en C++, y el vídeo necesita maquinaria extra para la estabilidad temporal. La regla que te mantiene a salvo es simple. Dimensiona el caso de uso a lo plausible (visualización, prueba, avatares), no a lo preciso (medición, diagnóstico, seguridad). Dentro de esa línea, un modelo humano 3D propio y preservador de la privacidad es una opción nueva real en 2026.

Dónde fracasa el RAG clásico en la pyme

RAG convierte sus documentos en conocimiento buscable. El punto débil es la primera etapa: el reconocimiento de texto. Una factura de proveedor con tabla de posiciones, un contrato de dos columnas, una hoja de datos escaneada con plano acotado: el OCR recompone algo así con regularidad de forma equivocada. La tabla se vuelve un desierto de cifras, las columnas se entrecruzan, el plano desaparece. El modelo recibe entonces ya texto roto y responde en consecuencia. En nuestra experiencia, con expedientes reales la mayor parte de los errores está aquí, mucho antes de que un modelo de lenguaje tome siquiera la palabra.

Cómo lo esquiva la búsqueda visual

Los modelos de retrieval visual se saltan el reconocimiento de texto al buscar. Descomponen la imagen de la página en muchos pequeños fragmentos, incrustan cada uno y comparan la consulta directamente con ellos. Así se conserva que una cifra está en una celda de tabla y no en el texto corrido. Tres nombres encabezan el campo: ColPali como referencia, ColQwen como variante casi siempre más fuerte sobre base Qwen, y ModernVBERT como modelo pequeño y apto para on-prem. Toda la caja de piezas junto con la base de datos vectorial la ordenamos en el resumen del stack. Para la mirada práctica basta: la página se ve, no se adivina.

Honesto sobre los costes

La ganancia no es gratis. Varios vectores por página necesitan bastante más memoria de índice que un único vector de texto. Con un archivo de texto corrido puro y limpio, el RAG de texto clásico sigue siendo más barato y basta. La búsqueda visual vale la pena allí donde el layout porta la información, y justamente eso es en la pyme más la regla que la excepción. Y para casos en los que al final necesita de todos modos texto buscable, por ejemplo para copiar o para un rastro de auditoría, el OCR sigue siendo sensato, como complemento en lugar de sustituto.

El primer paso es pequeño

No hay que reconstruir nada grande para ello. Tome los veinte documentos en los que su búsqueda actual fracasa, y haga justamente las preguntas que hoy se equivocan. Si la búsqueda visual encuentra la fila de tabla que el OCR perdió, tiene su respuesta, en sus propios expedientes, no en un benchmark. Lo bonito de ello: todo el montaje corre localmente, los datos se quedan en casa. Por qué eso cuenta para documentos sensibles está en On-Premise contra Cloud.

Por qué la costura era el verdadero problema

Generar una secuencia larga uniendo clips cortos introduce justamente los artefactos que hacen inutilizable el metraje: costuras visibles entre segmentos, rostros de personajes que se desvían entre planos, iluminación que salta. Para un vídeo de marca o de producto, esa deriva es la diferencia entre un asset usable y una falsificación obvia. La duración en una sola pasada elimina la costura, que es por lo que 30 segundos nativos son un paso real, no una cifra de vanidad.

Qué cambia realmente en la 2.5

Tres cosas destacan para un equipo que de verdad lo usaría:

• Clips nativos de 30 segundos. Una pasada, sin costuras, así que la consistencia se mantiene a lo largo de toda la duración.
• Hasta 50 referencias multimodales. Imágenes, audio y vídeo combinados en una generación, unas cuatro veces las doce de Seedance 2.0, orientadas a mantener estables un personaje, un producto y un estilo.
• Generación conjunta de audio y vídeo. Lo visual y lo auditivo se coprocesan en un espacio latente en lugar de generarse por separado y sincronizarse después, que es lo que mantiene alineados el movimiento y el sonido.

Juntas apuntan al mismo objetivo: consistencia en el tiempo, que es lo que el vídeo de negocio necesita y los clips cortos no podían dar.

La salvedad honesta

La calidad es ahora la parte fácil. Para uso de negocio, las preguntas difíciles lo deciden: ¿puedes usar el metraje comercialmente, de quién es la imagen que aparece, a dónde van los datos, y es la salida lo bastante consistente para ponerle una marca? Seedance 2.5 está en beta empresarial con un lanzamiento público previsto para principios de julio, así que los detalles de licencia y procedencia son justo lo que hay que leer antes de comprometerse. El campo más amplio, y cómo elegir entre los modelos, está en nuestro estado del vídeo con IA 2026.

Dónde encaja

Para storyboarding, películas de concepto y assets sociales cortos, un clip nativo limpio de 30 segundos cambia lo que una sola persona puede producir. Para trabajo regulado o crítico para la marca, trátalo como un motor de borradores hasta que los derechos y la consistencia superen tu listón. La capacidad es real; la gobernanza es la parte a acertar primero.

Dónde ayuda

El Vibe Coding brilla en todo lugar donde cuenta la velocidad y el código puede desaparecer después. El prototipo en una tarde, la herramienta interna para un equipo pequeño, la maqueta clicable para una presentación de cliente, el primer 70 por ciento de una idea: aquí aporta valor real. El ejemplo original de Karpathy era justamente eso, software desechable para un proyecto de fin de semana.

La demanda lo confirma. Herramientas como Cursor, Claude Code, Lovable y Bolt han crecido en tiempo récord, Lovable hasta unos 200 millones de dólares de facturación anual a finales de 2025. También en mi trabajo el beneficio es concreto: una persona experta sin formación en programación puede poner en marcha una idea ella misma, en lugar de describirla primero y luego esperar dos semanas. Mientras el resultado siga siendo un experimento y nadie apoye su negocio en él, es una ganancia de velocidad que no habría que minimizar.

Dónde muerde

En cuanto el código se entrega, la imagen se invierte, y las pruebas son incómodamente concretas. Veracode examinó en 2025 más de 80 tareas y más de 100 modelos: el 45 por ciento del código generado contenía una brecha de seguridad, y los modelos más nuevos o más grandes no salieron mejor parados. Un estudio de METR encontró que los desarrolladores experimentados con herramientas de IA fueron un 19 por ciento más lentos, pero se creyeron más rápidos.

A eso se suman los incidentes que quedan en la memoria. Un agente de Replit borró en julio de 2025 una base de datos de producción, ignoró la instrucción expresa de no cambiar nada, y afirmó después que una restauración era imposible (no lo era). Alrededor de uno de cada cinco paquetes propuestos por una IA no existe siquiera, y el 43 por ciento de esos nombres inventados aparece de forma repetida, lo que abre a los atacantes una nueva brecha de cadena de suministro. Addy Osmani lo llama el problema del 70 por ciento: la IA le lleva rápido al 70 por ciento, el último 30 por ciento de casos especiales, seguridad e integración sigue siendo trabajo de ingeniería clásico. Y jurídicamente la situación es inequívoca: la responsabilidad por el software entregado se queda con la empresa que lo construye y vende, no con el proveedor de IA.

La línea: desechable frente a entregado

La distinción más útil no es una sobre herramientas, sino sobre el propósito. Un script que una persona usa una vez es otra cosa que un software que sus clientes, sus auditores y el Cyber Resilience Act de la UE a partir de diciembre de 2027 juzgan. Incluso Gartner, que cuenta hasta 2028 con un 40 por ciento de cuota de Vibe Coding en el software empresarial, llama expresamente a la salida en bruto código desechable, no listo para producción.

Para la pyme eso significa: la pregunta no es si su equipo puede usar Vibe Coding, sino para qué. Desechable y experimento: con gusto, rápido, sin ceremonia. Todo lo que toca datos de clientes, se entrega o debe resistir una auditoría: nunca sin leer. Esa sola clasificación ahorra la mayoría de los dolores posteriores.

El camino maduro: Vibe Coding controlado

La buena noticia es que la respuesta profesional en 2025 y 2026 ya existe, y no se llama prohibición. Se llama Vibe Coding controlado, o desarrollo asistido por IA: la IA como junior muy rápido, con un senior responsable al lado. Así lo abordamos.

🔸 Especificación antes del prompt. El contramovimiento se llama Spec-driven Development, con herramientas como GitHub Spec Kit: primero especificación, plan y tareas, luego código. Eso hace el resultado verificable en lugar de aleatorio.

🔸 Revisión y pruebas antes de producción. Ningún código de IA entra en vivo sin leer. Revisión de código, pruebas automatizadas y un escaneo de seguridad son la condición, no el adorno, sobre todo en todo lo que toca datos o dinero.

🔸 Licencia y cadena de suministro a la vista. El código de IA sin verificar puede colar fragmentos con licencia GPL o paquetes inventados. Ambos pertenecen al proceso de verificación, antes de que se conviertan en un problema de cumplimiento.

El Vibe Coding es una herramienta brillante para la tarea correcta y un riesgo para la equivocada. La diferencia está en saber, antes del primer prompt, en qué lado de la línea se está. ¿En qué lado está su próximo proyecto?

Qué cambió realmente YOLO26

YOLO26 elimina los dos pasos de posprocesamiento que hacían incómodos de desplegar a los detectores anteriores. Ejecuta una cabeza de detección uno-a-uno por defecto, así que no hay non-maximum suppression (NMS) en la inferencia y la red produce las detecciones finales directamente. También descarta el distribution focal loss (DFL), lo que aligera la cabeza para dispositivos de edge y de baja potencia. La receta de entrenamiento también es nueva: un optimizador MuSGD, pérdida progresiva y asignación de etiquetas de objetivos pequeños.

Por qué sin NMS es la parte que vale la pena cuidar: NMS es un paso separado, dependiente de los datos, que corre después de la red, y su tiempo varía según cuántos objetos hay en el cuadro. Eliminarlo te da latencia determinista y una exportación más limpia, que es justo lo que quieres cuando el objetivo es ONNX, TensorRT, OpenVINO o CoreML sobre hardware fijo. Menos perillas de posprocesamiento significan menos formas en que el camino de producción se desvía del laboratorio.

Las cifras son incrementales, no dramáticas. En COCO, YOLO26n alcanza 40,9 de mAP con 2,4M de parámetros, y Ultralytics reporta hasta un 43 por ciento más rápido de inferencia CPU ONNX que YOLO11n. Esa cifra de CPU, no la precisión, es el titular para un comprador que corre detección sobre silicio de edge de consumo sin GPU.

Los números de versión dejaron de significar lo que crees

Lo más útil de entender en 2026 es que "YOLO" ya no es un solo proyecto, y los números de versión vienen de equipos distintos. Ultralytics mantiene YOLO26, YOLO11 y los más antiguos v8 y v5. YOLOv12 y YOLOv13 son líneas académicas separadas, y ambas aún dependen de NMS y DFL, justo lo que YOLO26 eliminó.

La lección es que un número de versión más alto no es un producto más nuevo del mismo proveedor. A veces es un grupo de investigación distinto por completo. YOLOv13 recibió críticas abiertas por reportar un AP en torno a 54,8 frente al 55,2 de YOLOv12 mientras corría más pesado, una regresión presentada como una mejora. Y YOLO en sí no es automáticamente el líder en precisión: los detectores basados en transformer de la familia RF-DETR ahora compiten de frente en la gama alta. Lee el benchmark y el mantenedor, no la etiqueta.

La cuestión de licencia que un comprador alemán pregunta primero

Antes de la arquitectura, comprueba la licencia, porque la de por defecto restringe cómo entregas. YOLO de Ultralytics está licenciado bajo AGPL-3.0. AGPL es una licencia copyleft fuerte: si distribuyes el software, o lo ofreces por red como servicio, generalmente estás obligado a liberar el código fuente completo correspondiente de tu obra derivada, y la lectura común extiende esa obligación a los pesos y al código de la aplicación circundante.

El punto que la mayoría de los equipos pasa por alto es que on-prem no te exime. La cláusula de red de AGPL se dispara al ofrecer la funcionalidad como servicio, incluso de cara interna en algunas interpretaciones, no solo al enviar un binario a un cliente. Para un producto de código cerrado, o un despliegue que preferirías no abrir en código, Ultralytics vende una licencia comercial Enterprise. Es a precio personalizado, sin precio público, así que pertenece pronto a la conversación de compras, no después de que el prototipo funcione.

La conclusión relevante para compras es simple: presupuesta la licencia Enterprise, o elige desde el principio un detector bajo una licencia permisiva (Apache o MIT). Esta es la misma cuestión de control a la que seguimos volviendo con los modelos de pesos abiertos, donde la licencia y el stack, no el benchmark, deciden qué te está permitido hacer.

Cómo elegir sin perseguir el número

Trata los lanzamientos de 2026 como una lista de comprobación corta y aburrida en lugar de un leaderboard.

• Fija una versión mantenida. Para producción, la línea de Ultralytics (YOLO26 o YOLO11) es el camino soportado. Las líneas académicas v12 y v13 son investigación, útiles de leer, no el valor por defecto a entregar.
• Lee el benchmark, no la etiqueta. Compara mAP y latencia en hardware cercano al tuyo, y sé honesto en que RF-DETR o un modelo más pequeño y más antiguo puede ganar para tu escena.
• Prueba pronto el camino de exportación. El valor de sin NMS se materializa en la exportación ONNX o TensorRT sobre tu dispositivo objetivo. Confírmalo ahí antes de comprometerte.
• Resuelve la licencia antes del piloto. AGPL o licencia Enterprise, o una alternativa permisiva. Decídelo mientras aún es barato cambiar.

Nada de esto necesita el número más nuevo. Necesita un detector que corra a tu latencia, sobre tu hardware, bajo una licencia con la que puedas vivir.

La parte honesta viene después. n8n le quita de encima el cableado de los procesos de negocio, y con los nodos de IA se suma un procesamiento de lenguaje real. Pero en cuanto entra en juego un modelo de lenguaje, el flujo deja de ser determinista, y justo ahí se decide si una automatización aguanta en el día a día. Este artículo muestra ambas cosas: lo que n8n hace bien y dónde discurre la frontera con la ingeniería de verdad.

Qué es realmente n8n

n8n es una plataforma basada en nodos para la automatización de flujos de trabajo. Usted construye un flujo de forma visual a partir de nodos y puede añadir en cualquier punto su propio código en JavaScript o Python.

🔸 Autoalojado o en la nube. El punto decisivo para el Mittelstand: n8n se ejecuta como contenedor Docker en su propia infraestructura. El procesamiento y los datos permanecen en la red propia; la empresa sigue siendo la única responsable.

🔸 Más de 400 integraciones más un nodo HTTP para cualquier interfaz REST. Lo que no existe como nodo listo, lo conecta usted mismo.

🔸 Fair-Code, no Open Source clásico. La Sustainable Use License permite el uso interno de negocio de forma gratuita. Lo que está prohibido es revender n8n como producto alojado a terceros. Para el uso propio clásico esto es irrelevante, pero para un público técnico es importante nombrarlo con precisión.

Quien todavía esté decidiendo si la IA debe ejecutarse localmente encontrará la ponderación en On-Premise frente a Cloud-LLM.

Cómo automatiza n8n los procesos de negocio

La estructura es siempre la misma: un trigger inicia el flujo, y después los nodos se ejecutan paso a paso.

🔸 Trigger: webhook, programación temporal, un evento de una app como un nuevo correo o una nueva entrada en el CRM, un formulario enviado.
🔸 Nodos: integraciones de apps, llamadas HTTP, consultas a bases de datos, lógica como IF y Switch, transformación de datos.

En la práctica vemos en el Mittelstand una y otra vez los mismos patrones:

Es la misma lógica con la que construimos nuestra propia microaplicación Event-Scout, antes de decidir qué merecía ingeniería de verdad.

Dónde entra en juego la IA

n8n no ha pegado la IA por encima, sino que la ha integrado como una familia propia de nodos basada en LangChain.

🔸 AI Agent Node. Un agente completo con llamadas a herramientas, memoria y un bucle iterativo de razonamiento, no solo un campo de prompt. El agente recibe otros nodos o flujos de trabajo como herramientas.

🔸 RAG sobre documentos propios. Desde la versión 1.74.0 de enero de 2025, los vector stores como Qdrant, Weaviate o pgvector pueden integrarse directamente como herramienta del agente. Con ello el sistema responde sobre la base de sus documentos, no del conocimiento general del modelo. Qué es exactamente RAG lo hemos explicado en Qué es RAG.

🔸 Modelos locales. A través de la conexión con Ollama, la inferencia se ejecuta en su propio hardware. n8n autoalojado más un modelo local da como resultado un stack de IA completamente privado, sin transferencia a terceros países. Qué hardware cuesta esto de forma realista está en LLM local en la empresa.

Lo que funciona bien: clasificación, extracción, enrutamiento, RAG, agentes sencillos. Se vuelve frágil en cadenas de agentes largas y de varios pasos, y en la reproducibilidad de las salidas del modelo.

Límites, y cuándo se inclina hacia la ingeniería

Unos cuantos puntos que mencionamos a los clientes antes de empezar:

🔸 Determinismo y depuración. Un paso de IA no entrega necesariamente la misma salida ante la misma entrada. Depurar flujos largos de agentes es laborioso.
🔸 Versionado. Los flujos de trabajo viven en la base de datos. Una revisión limpia basada en Git no es el estándar nativo, sino más bien cosa de las funciones Enterprise.
🔸 Escalado. El modo de servidor único llega a sus límites con muchos webhooks en paralelo. En producción hace falta el modo de cola con workers separados.
🔸 Mantenimiento. Autoalojado significa: actualizaciones, parches de seguridad, copias de seguridad y monitorización corren de su cuenta.

Se inclina hacia la ingeniería de verdad en cuanto se requiere lógica crítica y determinista, altos volúmenes de transacciones, niveles de servicio estrictos o la operación de múltiples agentes en funcionamiento continuo. Entonces hacen falta pruebas, CI/CD y observabilidad, no solo clics en el editor. La versión de hardening n8n 2.0 de enero de 2026 ha reforzado esto, con ejecución de código aislada y un comportamiento más estable bajo carga.

Cómo situamos n8n en iiterate

Usamos n8n con gusto precisamente para aquello en lo que es fuerte: automatizar rápido flujos internos, acoplar la IA allí donde de verdad mejora un paso, y operar todo el conjunto de forma conforme al RGPD en la propia casa.

El error que más vemos es confundir un flujo que funciona con un sistema listo para producción. Para procesos internos y bien tolerables, n8n es a menudo la respuesta completa. En cuanto el proceso se vuelve crítico para el negocio, n8n es el camino más rápido para encontrar el flujo correcto, y el punto en el que trasladamos el camino ya probado a ingeniería propia. Dónde tiene sentido en conjunto que la IA arranque en el Mittelstand lo hemos resumido en Soluciones de IA para el Mittelstand.

Así que la elección no va sobre qué modelo es mejor en abstracto. Va sobre la tarea que tienes delante y el stack que ya ejecutas.

Acierta primero con el linaje

La mitad de la confusión en esta comparación es la nomenclatura, así que vale la pena resolverla antes que nada.

🔸 GPT Image 2 es el modelo de imagen actual de OpenAI, el sucesor en la línea gpt-image, lanzado en 2026. El id de API más antiguo gpt-image-1 es la primera generación, no este.
🔸 Nano Banana Pro es el nombre de marketing de Google para Gemini 3 Pro Image, anunciado en noviembre de 2025 y construido sobre Gemini 3 Pro.
🔸 Nano Banana sin el Pro es el anterior Gemini 2.5 Flash Image, ahora posicionado como el nivel rápido y económico. No confundas ambos, ya que su calidad de salida y su precio son distintos.

Acertar con esto importa por la misma razón por la que importaba el linaje del modelo en la lección de soberanía de Fable 5: no puedes razonar sobre una herramienta que has identificado mal.

La comparación que decide el trabajo real

Los ejes que de verdad cambian el resultado que entregas:

La lectura breve: Nano Banana Pro gana en texto, resolución y consistencia. GPT Image 2 gana en el aspecto general y en encajar en un flujo de trabajo de OpenAI existente.

Dónde gana cada uno

🔸 Creatividad de marketing con mucho texto en imagen o infografías. Nano Banana Pro. El mejor renderizado de texto, salida a 2K y 4K, y fundamentación por búsqueda para datos y logotipos precisos. GPT Image 2 es un buen recurso alternativo si ya construyes sobre OpenAI.
🔸 Consistencia de producto o de personaje a lo largo de un conjunto. Nano Banana Pro. Es el que tiene una especificación declarada, 14 imágenes de referencia y 5 personas consistentes, que es lo que necesita una campaña coherente o una toma de producto recurrente.
🔸 Imágenes hero o editoriales generales. Ajustado. GPT Image 2 lidera actualmente las clasificaciones generales de texto a imagen, así que elige por preferencia de aspecto. Elige Nano Banana Pro si necesitas 4K directamente del modelo.
🔸 Integración estrecha de stack. Usa lo que ya ejecutas. Una tienda de OpenAI obtiene una sola API y descuentos por lotes con GPT Image 2. Una tienda de Google o Vertex obtiene generación nativa con Nano Banana Pro.

Esta es la misma disciplina de selección que aplicamos a los modelos de vídeo de IA y a imagen a 3D con TRELLIS. Elige por la tarea, no por el logotipo.

Límites honestos en ambos lados

Ninguno de los modelos está libre de compromisos, y los compromisos son los que muerden en producción.

🔸 GPT Image 2 tope cerca de 1536 px en el lado largo y ofrece solo tres relaciones de aspecto, así que pierde en gran formato y en formas inusuales. El precio por tokens encarece el trabajo intensivo en edición, ya que las ediciones también facturan tokens de entrada de imagen. La marca de agua son metadatos C2PA en lugar de una marca invisible incrustada, lo que conviene confirmar según tus necesidades de cumplimiento.
🔸 Nano Banana Pro lleva la marca de agua invisible SynthID en la salida, que no es eliminable por debajo del nivel empresarial superior. Algunos clientes la quieren fuera, así que compruébalo pronto. También funciona con mayor coste y latencia que el Nano Banana base, y Google no publica un precio limpio por imagen, así que planifica el coste a través de la calculadora de Vertex.

Nada de esto es un impedimento. Es el tipo de detalle que decide qué modelo encaja con una restricción concreta de cliente.

Cómo elegimos en iiterate

Nuestro criterio por defecto no es la lealtad a un modelo, es una lista breve. ¿Lleva la imagen texto o necesita 4K? ¿Tiene que mantenerse consistente a lo largo de un conjunto? ¿Qué nube ejecuta ya el cliente? ¿Hay restricciones de marca de agua o de residencia?

La mayoría de las veces esas cuatro preguntas se responden solas. El trabajo con mucho texto, de alta resolución o crítico en consistencia va a Nano Banana Pro. El trabajo editorial general y los pipelines nativos de OpenAI van a GPT Image 2. Mantenemos ambos en el kit precisamente porque la respuesta correcta cambia según el encargo.

Los modelos seguirán adelantándose el uno al otro, así que vuelve a revisar las clasificaciones y el precio en el momento de decidir. Lo que se mantiene estable es el hábito: emparejar el modelo con la tarea, y con el stack en el que el cliente ya vive.

Este artículo cubre qué es TRELLIS, cómo funciona, dónde encaja en un pipeline de assets real y los puntos en los que deja de ser una respuesta de un solo clic.

Qué es TRELLIS

TRELLIS es un modelo generativo 3D que acepta una imagen, varias imágenes o un prompt de texto y produce un asset 3D.

🔸 Latentes estructurados (SLAT). La idea central es un latente unificado que fusiona una rejilla de vóxeles 3D dispersa para la estructura con rasgos visuales densos para la apariencia. Desacoplar la forma del aspecto es lo que permite que el mismo latente se convierta en salidas distintas.
🔸 Tres salidas desde un latente. Campos de radiancia, gaussianas 3D o una malla exportada como GLB. GLB es el objetivo práctico, ya que arrastra los materiales a visores web y AR.
🔸 Abierto y con licencia MIT. El caballo de batalla de imagen, TRELLIS-image-large, tiene 1,2B de parámetros. El modelo y la mayor parte del código son MIT, lo que importa para uso comercial. Una línea más reciente de 4B añade materiales físicamente basados completos, digna de seguir a medida que madura.
🔸 Entrenado a escala. Unos 500.000 objetos curados, con el artículo aterrizando como Spotlight de CVPR 2025.

Esto se sitúa junto al extremo paramétrico y controlable del trabajo 3D que cubrimos en Grasshopper para diseño computacional. El 3D generativo y el 3D paramétrico resuelven problemas distintos.

Cómo funciona

El pipeline es breve de describir y útil de entender antes de comprometer una GPU a ello.

1. Entrada. Una sola imagen, varias vistas o un prompt de texto.
2. Latente estructurado. Un transformer de flujo rectificado en dos etapas genera primero la estructura dispersa y después rellena los rasgos SLAT.
3. Decodificación. El latente se decodifica al formato que elijas: malla, gaussianas o campo de radiancia.

En la práctica, cuenta con unos 16GB de VRAM como suelo, con 24GB cómodo. La generación corre en menos de dos minutos sobre una RTX 4090. Las builds de la comunidad reducen aún más las necesidades de memoria, que es lo que hace realista autoalojar TRELLIS en lugar de alquilarlo. Para equipos que ya ponderan inferencia local frente a alojada, el mismo compromiso que escribimos en on-premise frente a LLM en la nube aplica también a los medios generativos.

Dónde encaja en un pipeline de assets

El mejor encaje es al frente del pipeline, donde la velocidad supera al pulido.

🔸 Una foto de producto o un prompt a un GLB. Suéltalo en un visor three.js o un model viewer en la web, convierte a USDZ para AR, o escénalo en una escena de visualización. La conceptualización rápida y las previsualizaciones son donde brilla TRELLIS.
🔸 Edición local. TRELLIS puede regenerar o refinar una región del modelo, algo raro entre los generadores de una sola imagen.
🔸 Honesto sobre la topología. La salida es geometría generativa, no limpia de artista. Espera triángulos irregulares, sin flujo de aristas limpio, y UVs autogeneradas. Para videojuegos o cine harás retopología, re-UV y rebake de texturas. La línea más reciente consciente de materiales estrecha esa brecha sin cerrarla.

Así que la prueba de valor para un asset dado es simple: ¿tiene que verse bien en un visor la semana que viene, o tiene que ser un asset de videojuego riggeable y optimizado? TRELLIS es excelente en lo primero y un punto de partida para lo segundo.

TRELLIS frente a las alternativas

El campo 3D abierto y alojado se movió rápido. Una orientación rápida:

Dónde se sitúa TRELLIS: la opción genuinamente MIT más sólida, con salida multiformato y edición local. Las herramientas alojadas como Tripo y Rodin lo superan en topología limpia lista para usar, y Hunyuan a menudo gana en textura pero con una licencia más restrictiva. Si tu restricción es ser dueño del modelo y de los términos legales, TRELLIS es el punto de partida obvio.

Los límites honestos, y cómo lo usamos

Unas cuantas advertencias que ponemos sobre la mesa antes de que nadie cablee TRELLIS en producción:

🔸 La topología y las UVs no son listas para usar en videojuegos o CAD. Presupuesta retopología.
🔸 El CAD queda fuera de alcance. Las mallas generativas no son sólidos paramétricos, así que no son geometría de ingeniería.
🔸 El riesgo del input es tuyo. El modelo es MIT, pero la exposición legal de tu imagen o prompt de entrada es tuya. No alimentes tomas de producto que no puedas licenciar.

Tratamos TRELLIS como un motor de conceptualización y previsualización: una forma de poner un asset 3D creíble delante de un cliente en una tarde, y después decidir qué merece un pipeline acabado a mano. Ese es el mismo instinto detrás de dónde es útil la ola actual de modelos de vídeo de IA, y la misma disciplina de selección que aplicamos al elegir un modelo de imagen. La herramienta no es el entregable. El criterio sobre dónde encaja sí lo es.

Este artículo cartografía ambos lados: qué hacen bien de verdad estas plataformas en 2026, y los puntos concretos donde debe esperar toparse con un muro.

Qué es realmente un constructor de agentes no-code

Conviene separar dos cosas que se venden bajo el mismo cartel.

La automatización de flujos de trabajo es determinista. Se dispara un desencadenante, se ejecutan pasos fijos, la misma entrada da la misma salida. Los escenarios clásicos de Make o Zapier viven aquí, y también mucho trabajo útil.

Un constructor de agentes no-code deja que un modelo de lenguaje decida el camino. Usted describe un resultado, y el modelo elige herramientas, llama a APIs, lee sus documentos y itera hasta que cree que ha terminado. El flujo no lo cablea usted de antemano.

La línea se difumina, porque las plataformas de automatización acoplaron agentes a sus lienzos mientras las herramientas nativas de agentes añadieron integraciones. Para un equipo de la mediana empresa, la pregunta práctica no es 'agente o flujo de trabajo'. Es cuánto no-determinismo está dejando entrar en un proceso de negocio, y quién guarda los datos mientras se ejecuta. Hicimos la misma distinción cuando escribimos sobre la diferencia entre una API, un servidor MCP y una CLI.

Lo que hacen bien hoy

Usadas para la tarea adecuada, estas herramientas se ganan su lugar rápidamente:

🔸 Desencadenantes e integraciones. Webhooks, eventos de aplicaciones y programaciones a través de miles de conectores. La fontanería está resuelta.

🔸 Llamada a herramientas. El agente no solo conversa, actúa: consulta una base de datos, publica en un sistema, abre un ticket.

🔸 Retrieval sobre sus propios documentos. Fundamentar las respuestas en conocimiento interno son ahora unos pocos clics, el mismo patrón que cubrimos en nuestro artículo sobre RAG.

🔸 Flujos de varios pasos con un humano en el bucle. Una puerta de aprobación antes de que ocurra algo irreversible.

La recompensa es la velocidad. Puede demostrar que una idea merece la pena en días, que es exactamente para lo que sirve un prototipo. Construimos nuestra propia micro-app event-scout con este espíritu antes de decidir qué merecía ingeniería de verdad.

Dónde se detienen

Esta es la parte que la mayoría de las demos se saltan, y es la razón por la que Gartner espera que más del 40 por ciento de los proyectos agénticos se cancelen para finales de 2027. El modo de fallo rara vez es una caída. Es más silencioso que eso.

🔸 Fiabilidad y no-determinismo. La misma petición no da el mismo resultado dos veces. Los agentes no dan error, se desvían: entran en bucle, eligen la herramienta equivocada o actúan sobre contexto obsoleto. El coste aparece como calidad y latencia, sin ninguna luz roja en el panel.

🔸 Evaluación y observabilidad. Las consolas no-code ofrecen un rastreo escaso. Medir si un agente está mejorando de verdad, a lo largo de toda una ejecución de varios pasos y no solo en la respuesta final, es un añadido que hay que construir.

🔸 Gobernanza y alojamiento de datos. La mayoría de estas plataformas son SaaS estadounidense. Para datos alemanes eso significa cuestiones de RGPD y Schrems II que no se pueden ignorar. Las opciones autoalojables que mantienen los datos en sus propios servidores de la UE son una lista corta: n8n, Flowise, Langflow, Dify. Profundizamos en ese compromiso en on-premise frente a LLM en la nube y en qué permite realmente el RGPD.

🔸 Coste a escala. La facturación por ejecución y por crédito castiga el volumen. Con un modelo de créditos, el mismo agente puede costar unos pocos euros o varios cientos, dependiendo solo de cómo se haya construido. Los pilotos parecen baratos. La producción a menudo no lo es.

🔸 Dependencia y traspaso. Los lienzos propietarios no se exportan a ingeniería real. Cuando se supera una herramienta no-code, normalmente se reconstruye en lugar de migrar.

La lente de decisión

Uso cinco preguntas para decidir si algo se queda en no-code o gradúa a un sistema construido. Puntúe cada una como baja o alta.

1. Sensibilidad de los datos. ¿Toca datos personales o regulados?
2. Curva de volumen y coste. ¿El uso escala hasta un punto en el que la facturación por crédito duele?
3. Nivel de fiabilidad. ¿Es interno y tolerante, o de cara al cliente con un SLA?
4. Complejidad de la lógica. ¿Ramificación ligera, o lógica condicional y con estado profunda?
5. Auditoría y evaluación. ¿Necesita evaluaciones a nivel de trayectoria y un registro de auditoría?

Dos o más respuestas 'altas', y querrá una construcción a medida o híbrida. De lo contrario, no-code es la herramienta correcta, especialmente para demostrar valor.

El patrón que funciona en la práctica no es o uno o lo otro. Prototipe en algo como n8n o Flowise, encuentre el camino que realmente entrega, y luego endurezca ese único camino en ingeniería propia. El prototipo no se desperdició. Le dijo exactamente qué construir.

Cómo los tratamos en iiterate

Recurrimos a los constructores de agentes no-code pronto y a menudo, y luego somos deliberados sobre cuándo dejarlos. Un agente no-code es una forma rápida y honesta de averiguar si un resultado merece la ingeniería que costaría hacerlo fiable. Eso es valor genuino, y para muchas tareas internas es la respuesta completa.

El error que más veo en la mediana empresa es tratar una demo funcional como un sistema terminado. No son lo mismo, y la brecha entre ambos es la lista de arriba. Si sabe dónde está la línea antes de empezar, obtiene la velocidad sin el proyecto cancelado. Si quiere una visión fundamentada de dónde encaja la IA en una empresa mediana para empezar, lo desarrollamos en Soluciones de IA para la mediana empresa.

Dos advertencias por adelantado para un comprador alemán. El precio de los tres cambia con frecuencia, así que trate cada cifra aquí como desactualizada y digna de volver a comprobar. Y la residencia de datos es una restricción real: ninguno aloja en la UE por defecto, lo que importa antes de que cualquier dato personal toque una llamada.

Qué es realmente cada uno

🔸 ElevenLabs Agents. Construido sobre la calidad de voz por la que ElevenLabs es conocida, ahora envuelta en una capa de agente alojada con telefonía sobre SIP. La elección cuando la voz de sonido más natural y el control para desarrolladores son los factores decisivos.

🔸 Retell AI. Infraestructura de agentes de voz orientada a telefonía. Se posiciona en baja latencia y gestión fiable de llamadas, entrantes y salientes, y permite traer tu propio operador. La elección para operaciones de llamadas en producción.

🔸 Voiceflow. Una plataforma visual y colaborativa para diseñar agentes de chat y voz, con una base de conocimiento integrada. Orientada al diseño y con el no-code por delante. La elección para un equipo de CX o diseño que itera sobre flujos. Ten en cuenta que la voz telefónica en vivo es la más débil de los tres aquí, ya que se apoya en un proveedor de telefonía separado.

Si tu trabajo se parece más a un agente de texto o de uso de herramientas que a una línea telefónica, aplica la misma lógica de construir-frente-a-comprar de los constructores de agentes no-code.

La comparación que importa

Las dimensiones que realmente deciden un proyecto de agente de voz, una al lado de la otra:

Lea la tabla como un mapa de compromisos, no como un marcador. Ninguna columna es la mejor en todo, que es justamente el punto.

Dónde encaja cada uno

🔸 Una línea de soporte alemana que necesita telefonía y una voz alemana natural. Empiece con Retell para una gestión de llamadas fiable y control del operador, o con ElevenLabs si la naturalidad de la voz alemana es el factor decisivo. Para una soberanía de datos estricta, ninguno aloja en la UE por defecto, así que dimensione un Retell autoalojado o una alternativa nativa de la UE.

🔸 Un equipo orientado al diseño que construye un flujo de CX. Voiceflow. El constructor visual, la colaboración multieditor y la base de conocimiento permiten a un equipo iterar sin ingenieros. Añada telefonía por separado cuando necesite voz.

🔸 Un desarrollador que quiere la máxima calidad de voz y control personalizado. ElevenLabs. El mejor TTS, control por SDK, agnóstico al modelo, SIP para telefonía.

El patrón es el mismo que aplicamos a la mayoría de las decisiones de herramientas: nombre primero el trabajo, luego elija la herramienta que domina ese trabajo.

La cuestión de la residencia de datos en Alemania

Esta es la parte que decide si un agente de voz está siquiera permitido antes de que la calidad de voz importe en absoluto.

El cumplimiento del RGPD no es lo mismo que el alojamiento en la UE. Un proveedor puede estar alineado con el RGPD y aun así procesar y almacenar las llamadas en infraestructura estadounidense, lo que reabre las cuestiones de Schrems II. Entre estos tres: ElevenLabs ofrece residencia de datos en la UE solo en el nivel Enterprise, Retell la alcanza mediante autoalojamiento, y Voiceflow es solo en la nube sin opción de residencia soberana.

Para una línea de soporte alemana que maneja datos de clientes, eso convierte la lista corta en una decisión de alojamiento tanto como en una decisión de funcionalidades. Es la misma lógica que exponemos en qué permite realmente el RGPD y en on-premise frente a LLM en la nube: decida dónde se permite que residan los datos, luego elija la herramienta que lo respeta.

Cómo elegiríamos

No partiríamos de la marca. Partiríamos de tres preguntas: ¿esto funciona por teléfono?, ¿quién lo mantiene? y ¿dónde se permite que residan los datos?

Si es una línea telefónica, Retell se gana la primera mirada. Si la calidad de voz sostiene la experiencia y la mantiene un desarrollador, ElevenLabs. Si un equipo no técnico necesita diseñar y poseer el flujo, Voiceflow. Y si los datos no pueden salir de la UE, la conversación pasa al alojamiento antes que a las funcionalidades, lo que a menudo reconfigura la lista corta.

El precio seguirá moviéndose, así que vuelva a comprobarlo en el momento de la evaluación en lugar de confiar en una única cifra. La parte duradera es el ajuste, y el ajuste sigue al trabajo.

Este artículo explica por qué la construimos, qué sabe hacer, dónde se detiene con honestidad, y plantea al final una pregunta abierta.

LA OBLIGACIÓN, BREVE Y CORRECTA

La factura electrónica ya no es una opción en el B2B alemán, sino obligación, y el calendario es concreto.

• Desde el 1 de enero de 2025 toda empresa nacional debe poder recibir y procesar facturas electrónicas. Sin excepción, sin límite de facturación, también los pequeños empresarios.
• Hasta finales de 2026 aún se permiten papel o PDF en el envío, pero el PDF solo con el consentimiento del destinatario.
• A partir de 2027 las empresas con más de 800.000 euros de facturación en el año anterior deben emitir facturas electrónicas, a partir de 2028 todas.

Con factura electrónica no se entiende un adjunto en PDF, sino un formato estructurado según la norma europea EN 16931. ZUGFeRD es la variante habitual en Alemania: un archivo PDF/A-3 con XML incrustado. La persona ve un PDF legible, el software lee el XML directamente, sin teclear y sin reconocimiento de texto. La imagen de abajo muestra exactamente esas dos vistas sobre el mismo archivo.

POR QUÉ NO CONTRATAMOS SIN MÁS UNA SUSCRIPCIÓN

El detonante lo conoce cualquiera: llega la obligación, así que se necesita una herramienta. La respuesta obvia es una suscripción, y justo ahí nos detuvimos.

Para un proceso en el fondo sencillo, generar un PDF con XML incrustado, se acumulan rápido costes recurrentes: las herramientas de facturación habituales empiezan en unos 10 euros al mes y llegan bastante más alto para el envío de facturas electrónicas según la tarifa. Para una casa que solo escribe unas pocas facturas al mes, con eso se paga de forma permanente por una contabilidad completa que ni siquiera se usa.

El verdadero motivo no fue el precio, sino los datos. Una factura contiene nombres, direcciones y a menudo datos bancarios. Si se pasa por una herramienta en la nube, eso es un encargo de tratamiento según el art. 28 del RGPD: un contrato, un tercero, datos que salen de casa. Autoalojado, eso desaparece por completo. Es la misma lógica que defendemos con los modelos de lenguaje, como se lee en On-Premise vs. LLM en la nube: conservar el beneficio, no ceder la soberanía de los datos.

QUÉ HACE BELEGT EN CONCRETO

Belegt es deliberadamente pequeño y de alcance nítido. Es un generador, no un sustituto de contabilidad.

Técnicamente es una aplicación web que se opera en el propio ordenador o servidor. Los datos residen localmente en un archivo, y los campos sensibles como los datos bancarios se guardan cifrados. Genera facturas ZUGFeRD y Factur-X en el perfil EN 16931, es decir, el nivel que jurídicamente cuenta como factura electrónica de pleno derecho, las valida contra la norma, asigna números de factura correlativos, gestiona perfiles de empresa y de cliente, y mantiene a la vista las partidas pendientes y las evaluaciones.

Las dos cosas que más tiempo nos ahorran: un flujo guiado que completa una factura conforme en pocos pasos, y que el archivo generado trae de inmediato la vista de máquina que el destinatario necesita. La usamos nosotros mismos, cada mes. Esa es la recomendación más honesta que podemos dar: no la construimos para un mercado, sino para nosotros. Es una de varias pequeñas herramientas que surgieron así, como la herramienta Event-Scout.

DÓNDE SE DETIENE CON HONESTIDAD

Una herramienta individual autoalojada tiene límites reales, y callarlos sería justo el tipo de marketing que no hacemos.

🔸 La norma se mueve. EN 16931 y las listas de códigos se actualizan con regularidad. Un generador hay que mantenerlo, o en algún momento genera facturas que dejan de ser conformes. Ese es trabajo que alguien tiene que hacer.
🔸 El archivado no está incluido. Generar no es lo mismo que archivar de forma inalterable. Las GoBD exigen una conservación inalterable en el formato original, ahora ocho años. Eso no lo resuelve un simple generador, eso queda como tarea del usuario.
🔸 No reemplaza a un asesor fiscal. Una factura técnicamente válida puede, aun así, estar incompleta en su contenido. No existe una conexión directa con la asesoría o con sistemas contables.

Resumido con justicia: Belegt cierra con limpieza y sin suscripción el hueco obligatorio de generación y validación. El archivado y el flujo fiscal quedan fuera. Quien lo confunda con una suite completa se llevará una decepción. Quien tenga exactamente ese hueco recibe una herramienta sin lastre.

¿DEBEMOS COMPARTIRLA, Y CÓMO?

Aquí el artículo termina deliberadamente con una pregunta en lugar de una respuesta, porque nosotros mismos aún no lo sabemos.

Hay dos caminos plausibles. Uno: liberamos Belegt, como solución autoalojada que cualquier pequeño negocio puede correr en su propia máquina, sin suscripción y con los datos en casa. El otro: ofrecemos una variante mantenida, que mantenemos al día, con la que ayudamos en la instalación y por la que respondemos ante las actualizaciones de la norma, a cambio de una aportación justa. Ambos tienen su lógica, y la carga de mantenimiento del apartado anterior es justamente el motivo por el que la respuesta no es trivial.

Por eso esta petición honesta: si una herramienta ZUGFeRD local, conforme a la protección de datos y sin suscripción le fuera útil a usted o a su negocio, escríbanos. ¿Le bastaría con operarla usted mismo, o preferiría una versión gestionada? Justamente esa señal nos ayuda a decidir si de algo que construimos para nosotros surge algo que compartamos.

Claude Code, Codex, Cursor, Antigravity y Opencode resuelven la misma tarea de maneras muy distintas. La única pregunta que divide el campo es simple: ¿debe poder salir vuestro código de casa? Quien pueda responder eso con un sí, elige según el stack. Quien no pueda, tiene exactamente una opción seria. Este texto ordena los cinco a lo largo de esa pregunta y termina con la decisión que recomiendo a un equipo alemán.

CINCO HERRAMIENTAS, UNA PRIMERA PREGUNTA

Las cinco se sitúan en niveles distintos, y el factor de forma ya dice mucho sobre el uso.

• Claude Code es un agente de terminal de Anthropic: fuerte en cambios multiarchivo, gran contexto y un bucle agéntico en el terminal.
• Codex de OpenAI existe como CLI, sandbox en la nube e integración en IDE desde una ventana de uso común.
• Cursor es la IDE de IA con modo agente y agentes en segundo plano y libre elección de modelo.
• Antigravity es la IDE centrada en agentes de Google, disponible desde el 20.11.2025, con una interfaz de gestor para lanzar y observar agentes en paralelo (Google).
• Opencode es un agente de terminal de código abierto bajo licencia MIT, independiente del modelo a través de muchos proveedores y endpoints autoalojados (opencode.ai).

Cómo encajan estas herramientas en un stack, desde la API hasta la CLI, lo hemos expuesto en API, MCP o CLI. Aquí se trata de la elección, y esa empieza con la situación de los datos.

¿SALE VUESTRO CÓDIGO DE CASA?

Esta sola pregunta ordena el campo más rápido que cualquier lista de funciones, porque decide sobre cumplimiento y confidencialidad antes de que cuente cualquier característica.

Cuatro de los cinco envían el código a una nube ajena. Claude Code, Codex, Cursor y Antigravity corren contra modelos alojados en EE. UU. Eso no es en sí mismo una descalificación: para muchos proyectos está bien, y en la tarifa Enterprise se pueden negociar cláusulas de retención cero de datos y de no entrenamiento. Pero el código sale, y eso hay que aceptarlo conscientemente, no pasarlo por alto.

Opencode es la excepción. Como es independiente del modelo y puede dirigirse a un endpoint local, corre por completo contra un modelo autoalojado. Entonces el código nunca sale de casa. Esa es justamente la línea divisoria que decide todo lo demás. Qué modelo de pesos abiertos ponéis detrás es una decisión propia, que repasamos en Modelo de pesos abiertos para el B2B alemán.

SI LA NUBE ESTÁ BIEN: ELEGIR SEGÚN EL STACK

Si aceptáis conscientemente la nube alojada, entonces decide el stack, no el benchmark. Un mapa breve:

La regla pragmática: casa Anthropic toma Claude Code, casa OpenAI toma Codex, un equipo centrado en la IDE toma Cursor o Antigravity. Circulan cifras de benchmark como valores de SWE-Bench en torno al 85 por ciento, pero suelen ser datos del proveedor y rara vez verificados de forma independiente; yo no basaría en eso una elección de herramienta. Lo que un agente de codificación aporta más allá del puro desarrollo lo muestra nuestro artículo Claude Code más allá de la ingeniería.

SI EL CÓDIGO DEBE QUEDARSE EN CASA: OPENCODE MÁS MODELO PROPIO

Si el código no puede salir, queda una opción seria, y es buena.

Opencode es de código abierto bajo MIT, habla con muchos proveedores y, lo decisivo, con un endpoint local. Combinado con un modelo de pesos abiertos autoalojado surge un agente de codificación en el que ni el código fuente ni los prompts salen de la propia infraestructura. Para datos regulados, secretos de mandato o simplemente clientes cautelosos, ese suele ser el único montaje viable. Un modelo de codificación abierto como Kimi K2.7 lo hemos examinado expresamente para ello.

El precio de ese control es trabajo propio: ensambláis vosotros mismos modelo, hardware y operación, no hay una flota gestionada de agentes en la nube. En la práctica ayuda dar estructura al agente, por ejemplo un mapa del código base, como el que describimos en Graphify. El esfuerzo es real, pero compra algo que las herramientas alojadas no pueden ofrecer.

CÓMO LO DECIDO YO

No necesitáis una única respuesta para toda la empresa, sino la correcta según la situación de los datos. Así procedo:

1. Aclarar la situación de los datos. ¿Puede el código en cuestión ir a una nube de EE. UU.? Esa respuesta viene del derecho y del cliente, no del equipo de desarrollo.
2. Si sí, elegir según el stack. Casa Anthropic a Claude Code, casa OpenAI a Codex, equipo de IDE a Cursor o Antigravity, en cada caso con condiciones de RCD y de no entrenamiento negociadas.
3. Si no, Opencode más modelo propio. La única opción en la que el código no sale de casa.
4. Mantener el lock-in a la vista. Si cada herramienta exige su propia atadura, dejad abierto un camino de vuelta a un nivel más profundo, por si un proveedor cambia las condiciones.

Nosotros mismos trabajamos según el proyecto con varias de estas herramientas, y ese es justamente el punto: la elección está ligada al proyecto, no a una cosmovisión. La pequeña herramienta interna que construimos con un agente en lugar de encargarla está en Construyendo event-scout. ¿Cuáles de vuestros repositorios no deberían en realidad ir hoy a una nube ajena, y qué herramienta usáis a pesar de ello para eso?

Este es el mapa de esa superficie, para qué sirve cada pieza y dónde están los bordes afilados.

CINCO FORMAS DE EXTENDER, UN PRINCIPIO

Bajo los nombres, cada punto de extensión hace lo mismo: mueve el saber hacer fuera del prompt y a archivos versionados que el agente carga cuando los necesita.

• Los Skills son carpetas de instrucciones, scripts y recursos. Una descripción corta reside en el contexto; el skill completo se carga solo cuando el agente lo juzga relevante. Esto es divulgación progresiva: barato de mantener, detallado al invocarse.
• Los comandos slash son atajos con nombre que se expanden en un prompt fijo. La forma sencilla de codificar una petición repetida una vez y reutilizarla.
• Los hooks son comandos de shell disparados en eventos del ciclo de vida: inicio de sesión, antes de una llamada de herramienta, después, al detenerse. Un hook previo a la herramienta puede inspeccionar y bloquear una llamada antes de que se ejecute.
• Los conectores MCP dan al agente acceso autenticado a sistemas que de otro modo no puede alcanzar: una base de datos, un rastreador de incidencias, una API interna. Cada servidor lleva sus propias credenciales.
• Los subagentes son instancias de agente separadas generadas para una subtarea concreta, con su propio contexto e instrucciones.

Un plugin agrupa cualquiera de estos en una unidad instalable. El principio bajo todo ello: codifica tu saber hacer como archivos en tu repositorio, no como hábitos en la cabeza de una persona. La versión de integración de sistemas de esta elección la expusimos en API, MCP o CLI.

SKILLS Y MCP NO SON RIVALES

La pregunta más común ahora mismo es "¿Skills o MCP?", y la respuesta honesta es que resuelven problemas distintos.

MCP es acceso: conecta al agente con un sistema que no puede alcanzar por sí solo, con credenciales y estado. Los Skills son saber hacer: pericia repetible que el agente aplica a sistemas que ya tiene. La analogía que circula es justa: MCP son los pasillos de la ferretería, los Skills son el empleado experimentado que sabe a qué pasillo ir.

La economía de tokens decide la forma de un buen montaje. Un Skill cuesta unas pocas decenas de tokens hasta que se invoca. Un puñado de servidores MCP puede costar decenas de miles de tokens de contexto antes de la primera tarea, porque cada servidor anuncia todas sus herramientas de entrada. Así que el patrón de trabajo hacia el que converge la mayoría de los profesionales son muchos Skills delgados y pocos conectores bien elegidos, no un montón de instálalo-todo. La demo de abajo recorre los cinco tipos de extensión y el coste y riesgo que cada uno acarrea.

POR QUÉ EL ESTÁNDAR ABIERTO IMPORTA PARA LA SOBERANÍA

El cambio reciente más útil es que la capa de extensión dejó de ser la característica de un solo proveedor.

Los Agent Skills se publicaron como estándar abierto en diciembre de 2025, y el formato fue adoptado por varios proveedores de agentes en semanas. En la práctica eso significa que un skill que escribes para un harness no queda atrapado ahí. Para una empresa alemana que sopesa el riesgo de "atada a un solo proveedor de EE. UU.", esta es una respuesta parcial en la capa que controlas: el saber hacer que codificas es portable, aunque el modelo de debajo esté alquilado.

Combina eso con conectores apuntados a sistemas alojados en la UE u on-premise y la historia de residencia de datos se sostiene a la vez que la de capacidad. El saber hacer es tuyo y portable; los datos se quedan donde deben. Esa es una posición más duradera que apostar el flujo de trabajo a la hoja de ruta de un proveedor, el mismo razonamiento detrás de elegir un agente de codificación por el harness, no por el modelo.

CADA PUNTO DE EXTENSIÓN ES UNA SUPERFICIE DE ATAQUE

El mismo poder que hace útil al harness lo hace peligroso, y los riesgos son recientes y documentados, no hipotéticos.

Los hooks ejecutan shell arbitrario, que es exactamente una superficie de ejecución. Check Point reveló CVE-2025-59536 en febrero de 2026: un archivo de configuración malicioso en un repositorio clonado podía ejecutar hooks antes de que apareciera siquiera el diálogo de confianza. Un problema acompañante, CVE-2026-21852, cubría la exfiltración de claves de API a través de una anulación de entorno. MCP trae un problema de cadena de suministro propio: cada servidor guarda credenciales, y los escaneos han encontrado cientos de servidores MCP expuestos a internet sin autenticación. Y los marketplaces de skills listan ahora miles de skills comunitarios, fáciles de instalar y difíciles de auditar, con informes de algunos abiertamente maliciosos en circulación.

Nada de esto es razón para evitar extender el harness. Es la razón para extenderlo de forma deliberada.

GOBIERNA EL CATÁLOGO, NO COLECCIONES PLUGINS

La disciplina que separa un montaje de producción de un experimento científico es un catálogo revisado y en lista de permitidos: un conjunto conocido de skills, hooks y conectores que alguien ha leído, con una puerta de confianza antes de que se una algo nuevo.

Eso es poco glamuroso y es todo el juego. Qué hooks pueden ejecutar shell. Qué servidores MCP guardan qué credenciales. Qué skills están aprobados, y quién los aprobó. Para un equipo de una pyme, aquí es donde el conocimiento institucional se vuelve herramienta duradera que sobrevive a la rotación de personal, y donde el trabajo deja de ser la configuración ingeniosa de un ingeniero y se convierte en algo que la empresa posee. Cuando construimos nuestra propia herramienta interna de scouting como una pequeña app agéntica, el valor no fue la astucia, fue que el proceso pasó a ser un archivo revisado en un repositorio en lugar de un recuerdo. Lo escribimos en construyendo una pequeña micro-app agéntica.

El modelo lo puedes cambiar el próximo trimestre. El catálogo de extensiones es el activo que conservas. Así que la pregunta que vale la pena hacerse antes de instalar el próximo plugin es simple: ¿quién lo revisó, y qué puede tocar?

Este artículo es un panorama sobrio: los casos de uso que sostienen, la financiación que de verdad existe en RLP, y el único obstáculo que casi todo lo frena.

QUÉ SOLUCIONES DE IA SOSTIENEN DE VERDAD

Las soluciones que se acreditan en la pyme son poco espectaculares y cercanas a los procesos existentes. Ahorran tiempo, rara vez inventan nuevos ingresos.

🔸 Inteligencia documental. Leer y clasificar automáticamente facturas, albaranes, contratos y correos. La barrera de entrada más baja, con efecto perceptible rápido.
🔸 Gestión del conocimiento con RAG. Una consulta propia sobre el fondo documental interno: manuales, documentación de procesos, ofertas, historial de servicio. Descarga la incorporación y el soporte, y el conocimiento no se pierde en los cambios de personal.
🔸 Automatización de ofertas y facturas. Generar textos de oferta y cálculos a partir de procesos, ordenar los flujos de facturación. Con la obligación de la factura electrónica, ya en la agenda de todos modos.
🔸 Agentes de servicio sobre conocimiento propio. Soporte de primer nivel y FAQ, anclados en datos de la empresa en lugar de en un chatbot genérico en la nube.
🔸 LLM local para datos sensibles. Procesar datos de personal, de mandato, de construcción o de pacientes localmente o en hosting alemán.

La lectura sobria: la IA en la pyme paga sobre todo en eficiencia, rara vez directamente en ingresos. Quien no elige el caso de uso con limpieza quema presupuesto, justo porque el gasto en innovación tiende a bajar.

EL MARCO DE FINANCIACIÓN EN RLP, SIN MITOS

Antes de la financiación, un trabajo de limpieza: muchos programas que circulan están muertos o nunca fueron de RLP. DigiBoost RLP está cerrado desde 2022, el go-digital de ámbito federal expiró a finales de 2024, y el a menudo citado bono de digitalización de 20.000 euros pertenece a Renania del Norte-Westfalia, no a RLP.

Lo que corre de verdad en 2025 y 2026:

• Programa de asesoría empresarial de RLP. Desde diciembre de 2025, subvención entre otras cosas a la digitalización y a la inteligencia artificial. Sustituye al anterior BITT.
• IBI-FEDER Renania-Palatinado. Subvención para innovación y digitalización empresarial, para pymes con sede en RLP.
• Bono de innovación de RLP. Hasta 20.000 euros no reembolsables para encargos de investigación y desarrollo a entidades externas.
• Centro Digital de la Pyme de Kaiserslautern. Asesoría gratuita y neutral respecto a proveedores, talleres y demostradores.

La financiación está, pues, ahí. Solo que no reemplaza una decisión sobre qué se quiere construir en realidad. Justamente en eso ayuda la selección en la imagen de abajo.

EL VERDADERO OBSTÁCULO ES LA PROTECCIÓN DE DATOS, NO LA TÉCNICA

Cuando los proyectos de IA fracasan en la pyme, rara vez es por el modelo. Fracasan por la pregunta de dónde pueden residir los datos.

El 77 por ciento de las empresas cita la protección de datos como mayor obstáculo, por delante de la escasez de personal cualificado con el 70 por ciento. A la vez, el 73 por ciento permite a sus empleados usar modelos de lenguaje, pero solo el 23 por ciento los limita a modelos propios de la empresa. Eso significa en claro: alrededor de la mitad deja correr sin control modelos de nube de libre disposición. Eso no es digitalización, eso es IA en la sombra, una fuga de datos anunciada.

A eso se suma la falta de madurez de los datos, casi un cuarto no tiene datos adecuados, y un escepticismo justificado sobre el ROI. La brecha no es IA sí o no. Está entre el uso informal y un marco seguro y productivo.

SOBERANO NO SIGNIFICA MÁS CARO, SIGNIFICA CONTROLABLE

La respuesta al obstáculo de la protección de datos no es renunciar a la IA. Es orientar el lugar de uso a la sensibilidad de los datos, no al marketing.

Para tareas no críticas, un modelo en la nube es defendible. En cuanto entran en juego datos personales, confidenciales o críticos para el negocio, el tratamiento pertenece a un entorno alemán o de la UE o a hardware propio. RAG sobre el propio fondo, local o alojado en Alemania, da el beneficio de un modelo de lenguaje sin enviar el contenido fuera de casa en cada consulta. Qué justifica la IA local frente a la nube y cuándo lo ordenamos en On-Premise vs. LLM en la nube, y cómo funciona RAG técnicamente en Qué es RAG.

Honestamente queda: no toda solución tiene que ser on-premise. El arte es la asignación, y justamente esa no la quita ninguna herramienta ni ningún certificado de subvención.

UN PRIMER PASO REALISTA

El camino transitable es sobrio y por etapas, no la gran promesa de IA de golpe.

Priorizar el caso de uso del que penden tiempo o errores. Comprobar el fundamento de datos, porque RAG sobre un fondo caótico no entrega valor. Construir un pequeño piloto con una medida de éxito clara. Solo entonces escalar. Estas etapas se pueden cofinanciar a través del programa de asesoría empresarial de RLP o del bono de innovación, y flanquear gratis a través del Centro Digital de la Pyme. El flujo completo lo hemos descrito en la hoja de ruta práctica de IA.

En iiterate estamos en Coblenza y Remagen y reunimos justamente estas tres cosas: estrategia, construcción y cumplimiento. La pyme de RLP ya está en ello. La tarea es convertir el ensayo informal en algo soberano y sólido. ¿Por dónde empezaría usted, y dónde están sus datos más sensibles?

Veo, Kling y Seedance entregan clips impresionantes, pero son cerrados y alojados. Wan Animate de Alibaba es el único modelo abierto de la serie, y con ello la palanca interesante para todos los que no quieren entregar el material. Este texto ordena los cuatro para una empresa alemana que construye demos de producto y vídeos de marketing, y toma en serio la regulación que se vuelve estricta en agosto.

EL AUDIO SE VOLVIÓ ESTÁNDAR, LA CALIDAD SE VOLVIÓ OBLIGATORIA

El cambio más importante del año es que la calidad visible ya no es una ventaja, sino la apuesta de entrada.

El sonido nativo se ha vuelto estándar. Veo 3 trajo audio generado de forma sincronizada, y a comienzos de 2026 también Kling 2.6 y el Seedance 2.0 de ByteDance generaban diálogo y ruidos en una sola pasada. Los modelos mudos parecen ya anticuados para el trabajo de demo. A la vez, los clips siguen siendo cortos: ocho segundos nativos son típicos, Seedance 2.0 alcanza unos quince, las piezas más largas surgen por encadenamiento, no de una sola pieza.

Los laboratorios chinos encabezan varias clasificaciones. Seedance estuvo en junio de 2025 en la cima de comparativas independientes de texto a vídeo, por delante de Veo 3 y Kling (arXiv). Tales puestos cambian cada mes. Ese es justamente el motivo para no fijar la elección en la clasificación, sino en los tres criterios que permanecen estables.

LOS CUATRO EN RESUMEN

Una nota importante sobre los nombres de antemano: en ByteDance, Seedream es el modelo de imagen y Seedance el de vídeo. Aquí se trata de Seedance.

• Veo 3.1 (Google, cerrado). La mejor fidelidad al prompt, sonido sincronizado de 48 kHz, la integración más profunda en un pipeline a través de Vertex AI y Flow. Alojado, la salida lleva la marca de agua SynthID de Google.
• Kling 2.6 (Kuaishou, cerrado). Fuerte imagen-a-vídeo y buen movimiento, desde la versión 2.6 con sonido nativo, hasta unos diez segundos. Accesible por API con almacenamiento de datos en Singapur.
• Seedance 2.0 (ByteDance, cerrado). Clips más largos hasta unos quince segundos y planificación de cámara. Acompañado de una cuestión jurídica abierta, después de que Disney enviara en febrero de 2026 un requerimiento de cese, lo que para el uso comercial es un riesgo real.
• Wan Animate (Alibaba, abierto). Publicado bajo Apache 2.0 y autoalojable, especializado en animación de figuras, transferencia de movimiento y sustitución de personajes a partir de una imagen de referencia (Hugging Face). Menos pulido y clips más cortos que los alojados, a cambio de control total.

Runway, el Sora 2 de OpenAI y MiniMax llenan más el campo, pero para la pregunta decisiva aquí están igual: fuertes, pero cerrados.

LA OBLIGACIÓN DE ETIQUETADO LLEGA EL 2 DE AGOSTO

La regulación es en 2026 el verdadero acontecimiento, no el próximo modelo. Quien use vídeo con IA de forma comercial debe resolver antes el etiquetado.

Las obligaciones de transparencia del artículo 50 del Reglamento de IA de la UE se vuelven aplicables a partir del 2 de agosto de 2026 (EU AI Act). Los medios sintéticos deben marcarse de forma legible por máquina y los deepfakes deben etiquetarse. En la práctica eso significa: la procedencia es una función de cumplimiento, no un extra bonito. Los modelos alojados lo traen en parte, Google por ejemplo vía SynthID, otros vía pruebas de contenido C2PA. Wan autoalojado, en cambio, no lleva marca de agua forzada, así que el etiquetado queda entonces en vuestras manos, como un paso propio y documentado en el pipeline.

Qué contenidos de IA caen bajo el reglamento y qué hay que implementar y para cuándo lo hemos expuesto en EU AI Act 2026 y en el marco de RGPD e IA.

EL MODELO ABIERTO ES LA PALANCA

Cuando el material no puede salir de casa, el modelo abierto es la verdadera respuesta, no el más bonito.

Wan en las versiones 2.1 a 2.2 y Wan Animate está de forma continua bajo Apache 2.0, es decir, uso comercial pleno, redistribución y ajuste fino sin llamada a casa. La variante más pequeña corre en una sola tarjeta de 24 GB, la variante 14B necesita unos 80 GB. Autoalojado sobre infraestructura europea, en caso necesario aislada, ningún metraje sale de vuestro control, y no hay condiciones de uso ajenas ni dependencia geopolítica. El precio es menos pulido y clips más cortos que en Veo o Seedance, algo que se asume conscientemente a cambio de la soberanía.

Esa es la misma lógica que trazamos con los modelos de lenguaje: un modelo abierto y controlado le gana al último porcentaje de calidad cuando el control es el punto (IA europea soberana). También en los modelos del mundo se perfila el mismo camino abierto (NVIDIA Cosmos 3).

CÓMO LO DECIDO PARA UN PROYECTO DE DEMO

La decisión sigue la situación de los datos y el propósito, no el demoreel más bonito. Así procedo:

1. Material sensible o regulado. Si el vídeo muestra productos antes del lanzamiento, clientes o asuntos internos, entonces Wan autoalojado sobre infraestructura de la UE, y el etiquetado como paso propio del pipeline.
2. Marketing público, contenido no crítico, pulido decisivo. Entonces un modelo alojado como Veo o Seedance, pero con condiciones elegidas conscientemente y procedencia aclarada.
3. En todo caso resolver el etiquetado antes del 2 de agosto, no después.

En nuestro propio trabajo creativo mezclamos esto según el proyecto, y el punto no es coronar un modelo ganador. El punto es que la calidad visible se ha vuelto lo fácil y las preguntas difíciles, situación de datos, derechos y etiquetado, deciden sobre el uso. ¿Cuál de vuestros vídeos planeados podríais siquiera confiar a un servicio alojado de EE. UU., y cuál pertenece a vuestra propia infraestructura?

Qwen, Kimi, Nemotron y Minimax son en 2026 todos seriamente utilizables. Pero solo tres de los cuatro llevan una licencia realmente libre, solo una familia encaja limpiamente en hardware de pyme, y ningún proveedor publica una comparación limpia justamente de estos cuatro en alemán. Este texto ordena los cuatro según los criterios que un comprador tiene que comprobar de verdad, y termina con la decisión que recomiendo a una pyme.

Primero la licencia, luego el benchmark

La licencia es la primera puerta, porque decide sobre todo uso comercial on-prem antes de que cuente un solo benchmark.

Tres de los cuatro son aquí sencillos. Qwen3 está bajo Apache 2.0, Minimax M2 bajo MIT, Kimi K2 bajo una licencia MIT modificada (Hugging Face). Son concesiones reales y libres: uso comercial, redistribución, ajuste fino, sin llamada a casa.

🔸 Nemotron es el caso especial.
La Open Model License de NVIDIA no es una licencia Apache o MIT pura. Ata el uso a las condiciones de NVIDIA y termina automáticamente si se retiran los mecanismos de protección incorporados (NVIDIA). El modelo es bueno, pero esa cláusula aterriza primero en el departamento jurídico, no en ingeniería. Hemos descrito el enfoque de NVIDIA en detalle en el artículo sobre Nemotron 3.

Quien usa la soberanía como argumento debería saber leer la licencia como un contrato, porque justo eso es.

¿Qué tan bueno es el alemán en realidad?

La respuesta honesta: no existe una comparación limpia de cuatro vías de estos modelos en alemán, así que hay que producirla uno mismo.

La infraestructura de evaluación en alemán existe. SuperGLEBer, el leaderboard Occiglot Euro-LLM y MMLU-ProX sobre 29 idiomas cubren el alemán (ACL Anthology). Lo que falta es una comparación cabeza a cabeza publicada justamente de estos cuatro sobre texto en alemán. Qwen3 se entrenó sobre 119 idiomas y es la familia con la multilingüidad más ampliamente acreditada (Qwen); para Kimi, Nemotron y Minimax los proveedores no mencionan el alemán como foco específico.

La consecuencia práctica es incómoda, pero clara: los puestos de benchmark en pruebas en inglés dicen poco sobre la calidad en vuestros contratos, ofertas o textos de soporte en alemán. La única prueba fiable es la que se hace sobre vuestro propio material. Cómo leer siquiera los leaderboards sin dejarse engañar está en el artículo sobre el modelo local.

Qué corre en vuestro hardware

El encaje de hardware ordena el campo más rápido que cualquier benchmark, porque un modelo que no cabe en vuestras tarjetas simplemente queda descartado.

Qwen3 es aquí la excepción. Las variantes densas de 4B a 32B corren cuantizadas en una o dos GPU, y la variante 30B-A3B-MoE entrega calidad de modelo con solo unos 3B de carga de cómputo activa. Ese es el corte que encaja con una caja on-prem típica de pyme.

Kimi K2 y Minimax M2 son modelos MoE de frontera. Minimax activa solo 10B de parámetros, pero los pesos completos exigen un servidor de varias GPU; Kimi, con 1 billón de parámetros totales, aún más. Nemotron 3 Nano es con 3,6B de parámetros activos muy sobrio y corre en una tarjeta, pero queda rezagado por la licencia. Cuánto cuesta en concreto esa realidad de VRAM lo hemos calculado en el artículo de hardware.

La geopolítica está en los pesos, no en la API

Con los modelos de pesos abiertos se desplaza la pregunta de soberanía: los pesos corren por completo offline, así que no hay un interruptor remoto. Lo que queda es lo que está horneado en el modelo.

Tres de los cuatro laboratorios son chinos (Qwen, Kimi, Minimax), uno estadounidense (Nemotron). Como los pesos corren localmente, la verdadera pregunta no es la ubicación del servidor, sino la orientación dentro del propio modelo. Pruebas independientes reportan altas tasas de rechazo de los modelos chinos en temas políticamente delicados, más fuerte en lengua china y más débil, pero presente, en alemán (ChinaBench). Esas cifras son autopublicadas y no revisadas por pares, así que hay que leerlas con cautela, pero el efecto es lo bastante real para un párrafo honesto en el pliego de requisitos.

Para trabajo de texto B2B puro, es decir, borradores, extracción, clasificación y retrieval sobre vuestros propios documentos, ese efecto suele ser manejable. Es una cuestión de calidad de salida y de imagen externa, no una fuga de seguridad. El arco de soberanía mayor, los modelos europeos y cuánto vale de verdad la etiqueta, lo trazamos en el artículo sobre la IA europea soberana.

Cómo lo decido para una pyme

La decisión no es patriótica ni impulsada por el leaderboard, sigue un orden. Así procedo:

1. Comprobar la licencia. Solo modelos con una concesión real Apache o MIT entran en la selección estrecha sin consulta jurídica. Aquí son Qwen3, Kimi K2 y Minimax M2.
2. Probar sobre vuestro propio alemán. No el benchmark en inglés, sino cincuenta de vuestros textos reales contra dos candidatos y evaluar a ciegas.
3. Cotejar el hardware. Lo que cabe en vuestras una o dos tarjetas gana casi siempre, porque de lo contrario la operación se vuelve cara y frágil.

Para la mayoría de las pymes eso aterriza en Qwen3 como punto de partida: licencia libre, ampliamente multilingüe, en la ventana de hardware correcta. Kimi y Minimax son la elección cuando el servidor ya está de todos modos y el razonamiento o los agentes están en primer plano. El modelo de codificación de pesos abiertos Kimi K2.7 lo hemos examinado expresamente para ello.

Y, como siempre en nosotros: construid la arquitectura de modo que podáis cambiar el modelo. El próximo mejor modelo de pesos abiertos llegará seguro. La verdadera pregunta no es cuál va hoy por delante, sino cuáles de vuestras tareas necesitan siquiera el modelo más fuerte y cuáles solo uno bueno que os pertenezca. ¿Cuáles de vuestros textos confiaríais a un modelo que no habéis probado vosotros mismos?

Este artículo es la versión de profesional de ese montaje, y la versión honesta de sus límites.

La bóveda es el activo, el agente es alquilado

Mantén separado lo duradero y lo intercambiable, y la mayor parte del diseño se sigue de ahí.

Lo duradero es tu bóveda: archivos .md planos, [[wikilinks]], frontmatter YAML. Sin base de datos, sin formato propietario, sin paso de exportación. Lo intercambiable es el agente que la lee. Los dos proyectos comunitarios que lideran este espacio, obsidian-second-brain y obsidian-mind, ambos se distribuyen para Claude Code, Codex CLI y Gemini CLI a propósito. La bóveda es la inversión; el modelo es un inquilino que puedes desahuciar.

Ese es el mismo razonamiento que aplicamos a cablear la IA en cualquier stack: posee la interfaz, alquila la capacidad. Lo escribimos para la integración de sistemas en API, MCP o CLI. La gestión del conocimiento personal es el mismo argumento a escala de escritorio.

Qué cambia cuando un agente puede leer tus notas

Un agente con acceso a archivos convierte una bóveda estática en una que se mantiene a sí misma, dentro de los límites que fijes.

• CLAUDE.md es el manual de operación. Ejecuta claude desde la raíz de la bóveda y carga este archivo en cada sesión: tu mapa de carpetas, tus convenciones de enlace, tus plantillas de notas, tus comportamientos por defecto. Es el único archivo que sostiene en todo montaje que funciona. /init escribe un primer borrador.
• El contexto de sesión es un hook, no magia. obsidian-mind inyecta un extracto de estrella polar, una lista de tareas y un listado de archivos al inicio de sesión para que el agente no empiece en blanco. Eso es un hook SessionStart corriendo en tu máquina, nada más.
• Archivar se vuelve un skill. Los comandos slash y los subagentes manejan las tareas: archivar una nota recortada en la carpeta correcta, generar un mapa de contenido, encontrar notas huérfanas, escribir el registro diario. obsidian-second-brain distribuye docenas de estos.
• El frontmatter es la capa legible por máquina. Fecha, estado, fuente, un marcador de confianza en YAML, más wikilinks, dan al agente estructura para recuperar y cotejar, en lugar de adivinar a partir de la prosa.

El cambio más nuevo son notas que reescriben en lugar de anexar: una fuente nueva actualiza y reconcilia notas existentes en lugar de apilar otra entrada fechada. Útil, y el primer lugar donde tener cuidado, que es la sección de después de la siguiente.

Retrieval, no volcado: la realidad de los tokens

No cargues toda la bóveda. Deja que el agente traiga las pocas notas que una pregunta necesita.

El montaje ingenuo empuja la bóveda al contexto y se rompe en torno a unos pocos cientos de notas. El montaje frugal mantiene todo en disco y trae solo lo que coincide, mediante búsqueda por línea de comandos o grep. Los profesionales reportan la brecha como unos 100 tokens para una búsqueda de bóveda por CLI frente a decenas de miles por cargar un proyecto entero. La mecánica es poco glamurosa: buscar, leer las tres notas que coincidieron, responder.

Esto sigue importando aunque Claude Code ahora corra una ventana de contexto de un millón de tokens. El límite de tasa rodante muerde mucho antes de que la ventana se llene, así que una bóveda que responde en 100 tokens te deja hacer cien preguntas donde el montaje de cargar todo te da un puñado. El retrieval frugal es lo que hace un segundo cerebro usable a diario en lugar de impresionante una sola vez.

La línea de privacidad es la inferencia, no el almacenamiento

La comunidad vende "todo se queda en tu bóveda, sin SaaS". Eso es cierto para el almacenamiento y falso para la inferencia, y la diferencia es todo el riesgo.

Tu Markdown se queda en tu disco. Pero por defecto cada consulta envía las notas relevantes a una API en la nube para ser leídas. Para una bóveda de hobby de recetas, bien. Para una bóveda que guarda notas de clientes, contratos o cualquier cosa cubierta por un contrato de encargo de tratamiento, eso son datos que salen del edificio en cada pregunta. La portabilidad de Markdown plano no es lo mismo que la privacidad local.

Dos salvedades honestas más. La inyección de prompt es estructural: un agente que lee tus notas no puede separar con limpieza "instrucciones" de "contenido", así que cualquier Markdown que entre en la bóveda, una página web recortada, una nota compartida, un PDF ingerido, puede llevar instrucciones sobre las que luego actúa. Y el riesgo no es hipotético: en abril de 2026, atacantes abusaron de plugins comunitarios de Obsidian para ejecutar código cuando una víctima abría una bóveda compartida, reportado por The Hacker News. Un agente con acceso de escritura de archivos y de shell eleva esa apuesta, no la baja. Las notas que se reescriben a sí mismas también pueden inventar en silencio un backlink o sobrescribir una línea correcta, y el cambio se guarda antes de que lo leas.

El mismo patrón, mantenido soberano

Todo lo bueno de este montaje sobrevive cuando mueves el modelo a casa. El problema de privacidad es la única parte que necesita el cambio.

La versión soberana conserva la bóveda y el flujo de trabajo y cambia la inferencia en la nube por un modelo local: una capa de retrieval sobre tu Markdown servida por un modelo corriendo en tu propio hardware o en hosting de la UE. Conservas la propiedad del texto plano, el manual de operación CLAUDE.md, los skills, y dejas de enviar los contenidos fuera en cada pregunta. Para una empresa de una pyme, este es el puente de un experimento personal a la gestión real del conocimiento interno, manuales de producto, documentación de procesos, historial de soporte, sin una pregunta de encargo de tratamiento colgando sobre cada consulta. Cuándo hacer ese movimiento, y cuánto cuesta, es el tema de On-Premise vs. LLM en la nube.

El encuadre de aficionado es "construye un segundo cerebro". El encuadre de negocio es la misma máquina apuntada al conocimiento de la empresa en lugar del tuyo. La pregunta interesante, de nuevo, no es si funciona. Es quién puede leer las notas. Así que: ¿a dónde envía de verdad tu bóveda sus preguntas ahora mismo?

Este artículo ordena ambas: qué es ya fuerte, dónde chirría, y qué se sigue de ello para una empresa local.

La investigación está ahí, y es densa

El lado de la investigación no tiene que esconderse ante ningún Estado federado. Solo que está muy concentrado.

Kaiserslautern porta el núcleo: sede principal del DFKI, la RPTU con ocho cátedras de IA, Fraunhofer IESE e ITWM, además de una cooperación con el Instituto Max Planck. El primer centro de innovación y calidad de IA de ámbito federal de la Mission KI también reside aquí, con 32 millones de euros de presupuesto federal. Coblenza construye el segundo polo: la universidad puso en marcha en julio de 2025 un hub de IA interdisciplinar, la Hochschule Koblenz opera con DigiMit un centro de competencia para la región.

La clasificación honesta está justo al lado. El clúster está ponderado hacia KL y Coblenza, la superficie está peor conectada, y en la comparación federal RLP está en el grupo delantero, no en la cima. En digitalización lideran Baviera, Berlín y Hamburgo, en innovación Baden-Wurtemberg.

El propio Estado apuesta por una IA soberana

Notable es con qué trabaja el Estado: no con una suscripción de nube de EE. UU., sino con una línea propia y soberana.

La agenda de IA del Estado nombra una tríada de IA, y uno de los tres pilares se llama expresamente LLM On-Premise. Con GPU4GenAI el Estado invierte en infraestructura de GPU propia en el DFKI, y desde septiembre de 2025 corre una cooperación planteada a tres años con el DFKI que lleva la IA a la administración del Estado: análisis documental, plataformas de datos seguras, sistemas de asistencia.

Eso es más que una nota al margen. Si la administración pública en RLP construye IA conforme a la protección de datos y operada localmente, entonces la asesoría en on-premise y soberanía para la pyme no es un tema de nicho, sino un tema que enlaza con lo que el Estado ejemplifica. La imagen de abajo muestra el problema de fondo: nodos fuertes, demasiado pocas líneas hacia la superficie.

En la pyme la situación es distinta

En el banco de trabajo la velocidad es otra, y las cifras son sobrias.

En una encuesta de la Hochschule Koblenz en el norte de RLP (176 empresas, diciembre de 2025), solo el 8,5 por ciento valora la IA hoy como central para el modelo de negocio, y en cinco años al menos el 42 por ciento. Más de un cuarto ya usa herramientas de IA, alrededor de la mitad prueba en proyectos piloto. Un segundo estudio regional de la IHK y la Cámara de Oficios de Coblenza muestra el patrón real: casi dos tercios usan IA, de ellos la mayoría solo desde hace como mucho dos años, casi el 90 por ciento apuesta para ello por software externo, y el mayor reto mencionado es la seguridad jurídica.

La investigación de vanguardia y la difusión en la amplitud son, pues, dos cosas distintas. La una está aquí presente, la otra todavía no.

La brecha es la implementación, no la técnica

El obstáculo en la pyme rara vez es el modelo. Es el camino de la idea al uso seguro y productivo.

A nivel federal solo alrededor de un tercio de las empresas tiene una estrategia de IA elaborada, en RLP se menciona repetidamente la falta de conocimiento experto como freno. Y el casi 90 por ciento que apuesta por software externo compra con ello dependencia, a menudo de servicios de nube de EE. UU., justo donde las mismas empresas indican la seguridad jurídica como su mayor preocupación. Eso es una contradicción anunciada.

Una relativización honesta pertenece a esto: las tasas de uso sobredimensionan la madurez. Mucho es uso informal de herramientas de libre disposición, sin estrategia, sin gobernanza, sin un marco claro de protección de datos. La pregunta en la pyme hace tiempo que ya no es IA sí o no. Es soberano y productivo en lugar de informal y arriesgado. Qué significa eso en la práctica lo hemos detallado en la hoja de ruta práctica de IA para la pyme.

Qué significa esto para las empresas en RLP

La estrategia evidente es la que el Estado ya sigue: recoger el beneficio sin ceder la soberanía de los datos.

La pieza que falta no es otra herramienta, sino la capa entre la financiación y la investigación por un lado y el uso productivo y soberano por el otro. En concreto eso significa: modelos locales o alojados en Alemania para datos sensibles, gestión del conocimiento con RAG sobre el propio fondo documental, y un camino sobrio de la selección del caso de uso hasta la operación piloto. Cuándo vale la pena la IA local frente a la nube lo ordenamos en On-Premise vs. LLM en la nube.

En iiterate estamos en Coblenza y Remagen, es decir, en pleno segundo polo de IA del Estado, y justamente esa capa de difusión es nuestro trabajo: reunir estrategia, construcción y cumplimiento, en lugar de dejar solas a las pymes entre el certificado de subvención y el banco de trabajo. La investigación en RLP está asentada. La pregunta más emocionante es qué tan rápido llega a la superficie, y quién traza las líneas para ello.

Este texto explica por qué el contexto largo es caro, qué enfoques subcuadráticos hay, qué de las promesas más ruidosas está acreditado, y qué aporta eso en concreto al RAG on-prem. La recomendación al final es poco espectacular y justamente por eso sostenible.

Por qué el contexto largo es caro

La razón está en la matemática de la autoatención: su esfuerzo crece cuadráticamente con la longitud de la entrada.

En un transformer clásico, cada token compara con cada otro. Si se duplica la longitud del contexto, se cuadruplica a grandes rasgos el esfuerzo de cómputo de la atención. A eso se suma la memoria: la caché clave-valor que el modelo arrastra durante la generación crece linealmente con la longitud y devora rápido la memoria disponible en una GPU fija. Ese es el verdadero cuello de botella en la operación on-prem, donde el hardware está fijado y no se alquila de forma elástica.

Justamente aquí aplican los enfoques subcuadráticos. Intentan empujar los costes de secuencia hacia lo lineal, es decir, O(n) en lugar de O(n al cuadrado), y limitar la memoria por token. Qué significa eso para la realidad del hardware en la empresa lo hemos calculado en LLM local.

El paisaje subcuadrático

Hay varios caminos, y el ganador práctico de los años 2024 a 2026 no es el más puro, sino el híbrido.

• Modelos de espacio de estados (Mamba). Mamba (diciembre de 2023) y Mamba-2 (mayo de 2024) modelan secuencias en tiempo lineal con una memoria de estado fija en lugar de una caché creciente (arXiv). El precio: un estado fijo es un compresor con pérdidas y más débil en el recuerdo exacto de puntos muy lejanos.
• Atención lineal (RWKV, RetNet). Reformulan la atención de modo que los costes crezcan aproximadamente lineal. Compromiso similar en la memoria asociativa.
• Híbridos en producción. Nadie entrega modelos subcuadráticos puros de calidad puntera. En su lugar, todos mezclan una minoría de capas de atención plena con una mayoría de capas de espacio de estados o lineales: Jamba (AI21, 2024), MiniMax-01 (enero de 2025), Falcon-H1 (mayo de 2025), Nemotron-H de NVIDIA, IBM Granite 4.0 (octubre de 2025) y Qwen3-Next (septiembre de 2025). Las capas plenas conservan la memoria, las esbeltas compran la ventaja de coste y memoria.

La línea de NVIDIA detrás de Nemotron, que usa justamente este montaje híbrido, la hemos descrito en Nemotron 3.

Qué promete 'subQ' y qué de ello está acreditado

El término exige cautela, porque lleva dos significados, uno arquitectónico y uno de marketing.

Junto a la familia subcuadrática general hay un producto concreto: la startup Subquadratic salió del anonimato en mayo de 2026 con una financiación de unos 29 millones de dólares y se promociona con una atención subcuadrática y dispersa. Los titulares son grandes: un modelo de investigación con 12 millones de tokens de contexto, alrededor de una quinta parte de los costes frente a los modelos punteros, un múltiplo de velocidad (The New Stack).

La clasificación honesta: una parte está verificada por terceros, por ejemplo un resultado RULER-128K, mientras que las cifras espectaculares de 12 millones de tokens y del factor de velocidad son en cambio datos del proveedor de ejecuciones aisladas y no reproducidos de forma independiente. Eso es un indicio prometedor, no una base de compra. Justamente esa separación, acreditado frente a afirmado, es la disciplina que aplicamos a cada nuevo modelo.

Qué aporta esto al RAG on-prem

La ganancia concreta es memoria y rendimiento sobre hardware fijo, y ese es para el RAG on-prem justamente el tornillo correcto.

• Caché limitada, memoria planificable. Las capas de espacio de estados portan un estado fijo, así que la memoria no explota con la longitud. IBM menciona para Granite 4.0 más de un 70 por ciento menos de necesidad con contexto largo, un dato del fabricante, pero plausible y en dirección a más sesiones simultáneas por GPU.
• Modelo y contexto en una tarjeta. NVIDIA reporta que un modelo Nemotron-H con 51 mil millones de parámetros junto con la caché cabe en una sola tarjeta de 80 GB, también un dato del fabricante.
• Disciplina de chunking más laxa. Un contexto más barato permite ventanas más grandes y un troceado de documentos menos temeroso.

Los reparos honestos pertenecen a esto. En RAG con carga de memoria, por ejemplo la fuente exacta a lo largo de textos muy largos, los modelos subcuadráticos puros aún quedan por detrás de la atención plena, los híbridos cierran la brecha en gran medida, pero no del todo. El entorno de herramientas, es decir, cuantización, serving y ajuste fino, va por detrás de los modelos densos establecidos. Y la frase más importante: contexto largo no es igual a buen retrieval. Un modelo sólido con buen RAG le gana hoy casi siempre al intento de simplemente volcar millones de tokens dentro. Qué aporta siquiera RAG está en Qué es RAG y La fuerza de RAG.

Cómo lo trato hoy

Subcuadrático merece observación, pero no una apuesta. Así lo manejo:

1. Construir la capa RAG independiente del modelo. Tras una interfaz estable, de modo que se pueda emplear un híbrido de la clase Granite 4 en cuanto el entorno de herramientas esté maduro.
2. Empezar con un modelo sólido y bien soportado, no con la última arquitectura, y sacar el valor de la calidad del retrieval.
3. Ignorar las promesas no acreditadas. Un factor afirmado de mil espera hasta que alguien independiente lo reproduzca.

Ese es el mismo patrón que trazamos en On-Premise frente a Cloud: decidir de forma consciente, construir intercambiable (On-Premise vs. LLM en la nube). La pregunta emocionante no es si los modelos subcuadráticos abaratarán algún día el contexto largo. Probablemente lo harán. La pregunta es si vuestra arquitectura está lista para recoger la ganancia sin que apostéis hoy por ella. ¿Está vuestra capa RAG construida de modo que podáis cambiar el modelo sin reescribirlo todo?

La mayoría de los equipos que integran IA en sus sistemas no necesitan elegir un ganador. Necesitan situar cada llamada a la altura correcta. Este artículo define las tres con claridad, muestra cuándo encaja cada una, señala los costes que la gente pasa por alto y termina con una decisión que puedes defender. Dos preguntas resuelven la mayor parte: cuántas integraciones estás ejecutando y quién debe auditarlas.

Tres capas, no tres rivales

Cada patrón se sitúa en un nivel de abstracción distinto, con un compromiso claro entre control y comodidad.

• Una llamada directa a la API es el bloque de construcción más bajo. Tu código llama a un modelo o a un servicio a través de HTTP. Obtienes el máximo control y herramientas estándar, y escribes el pegamento: autenticación, petición, análisis de la respuesta, gestión de errores.
• MCP, el Model Context Protocol, estandariza la conexión, no el modelo. Es un estándar abierto que Anthropic presentó en noviembre de 2024 y que da a un modelo una forma coherente de descubrir y llamar a herramientas y datos, de modo que un cliente compatible con MCP pueda comunicarse con un servidor MCP que no conocía previamente (Wikipedia). Se difundió con rapidez: a lo largo de 2025 fue adoptado por OpenAI, Google y Microsoft, alcanzó más de 5.800 servidores comunitarios en abril de 2025 y, a finales de 2025, reportaba decenas de millones de descargas mensuales de SDK antes de que Anthropic lo donara a una iniciativa de la Linux Foundation (Thoughtworks, The New Stack).
• Una CLI agéntica es la capa más alta. Una herramienta como Claude Code envuelve un modelo, un conjunto de herramientas y un bucle de razonamiento en un flujo de trabajo de terminal. Menos pegamento, más opinada, la más rápida para trabajo abierto.

Se componen en lugar de competir: una CLI agéntica puede llamar a servidores MCP, que a su vez envuelven APIs simples (iiterate).

Cuándo cada una está a la altura correcta

La elección sigue la forma del trabajo, no la novedad de la opción. Un mapa breve:

En la práctica: un trabajo por lotes nocturno que golpea un único endpoint debería llamar a la API directamente, porque MCP añadiría latencia y puntos de fallo sin beneficio alguno. MCP se gana su lugar cuando varios agentes necesitan las mismas integraciones, de modo que cada cliente MCP obtiene una interfaz coherente en lugar de que cada agente lleve su propio envoltorio. El punto de cruce que reportan los profesionales ronda las tres o más integraciones conectadas a IA (MindStudio). Una CLI agéntica encaja cuando la tarea es abierta y alguien necesita resultados rápidos a través de muchas herramientas.

Los costes que la gente pasa por alto

Los beneficios titulares son fáciles de encontrar. Los costes más silenciosos deciden si una elección envejece bien.

• Tokens. Una capa de herramientas estandarizada no es gratis. Cuando un agente llama repetidamente a una herramienta, la sobrecarga de descubrimiento de MCP puede costar muchos más tokens que una llamada directa a la CLI o a la API para la misma tarea (MindStudio).
• Observabilidad. Las llamadas HTTP aparecen en tus registros, y herramientas estándar como Datadog las trazan sin coste. El transporte de MCP es comparativamente opaco, y su monitorización en producción aún está madurando, así que pagas en instrumentación a medida (IJONIS).
• Dependencia y portabilidad. Una API en crudo mantiene la integración en código que es tuyo. Cuanto más alto subes, más dependes de un cliente, de un ecosistema de servidores o del agente de un proveedor. Mantén un camino de vuelta a una capa inferior.

La superficie de seguridad de MCP es nueva y real

Estandarizar cómo los modelos llegan a las herramientas también estandariza una nueva superficie de ataque, y merece un tratamiento explícito.

OWASP clasifica la inyección de prompts como la principal vulnerabilidad para aplicaciones de LLM en 2025. MCP añade una variante específica, el envenenamiento de herramientas, donde se incrustan instrucciones maliciosas en la descripción de una herramienta, más cercano a un ataque a la cadena de suministro sobre el contexto del agente que a un jailbreak del lado del usuario, y registrado como CVE-2025-54136 (TrueFoundry). Dado que los servidores MCP suelen contener credenciales y alcanzan sistemas reales, un servidor con permisos excesivos o no confiable es un riesgo serio, y las protecciones del cliente varían mucho (Simon Willison, Microsoft). La postura práctica: ejecuta servidores verificados, da a cada uno el mínimo privilegio y mantén la monitorización, las mismas cuestiones de gobernanza que aplican en el momento en que un agente toca datos reales (iiterate).

Una decisión que puedes defender

No necesitas una única respuesta para toda la empresa. Necesitas la altura correcta por integración. Una regla práctica:

1. Opta por defecto por una API directa para una única llamada estable y de alto volumen.
2. Recurre a MCP cuando varios agentes necesiten las mismas herramientas, o cuando quieras herramientas intercambiables tras una sola interfaz.
3. Usa una CLI agéntica cuando el trabajo sea abierto y lo dirija una persona u otro agente.
4. Sea cual sea la capa, mantén el mínimo privilegio, registros reales y una forma de bajar una capa si un proveedor cambia sus condiciones.

Para la mayoría de los sistemas en producción la respuesta honesta es una mezcla: APIs directas bajo los servicios, MCP como capa de traducción y descubrimiento para los agentes, y una CLI donde trabajan las personas. El modo de fallo no es elegir la herramienta equivocada. Es adoptar la capa más nueva porque es la más nueva, y pagar sus costes para un trabajo que una capa inferior habría hecho mejor.

El sentido del artículo no son los eventos. Es la forma. event-scout es una micro-app agéntica: algo que construyes una vez con un agente de codificación y luego dejas corriendo, donde el agente hace el juicio confuso y scripts simples hacen la fontanería aburrida y repetible. Esa división es toda la lección, y viaja a casi cualquier tarea interna que un equipo de una pyme sigue haciendo a mano. event-scout corre en la más alta de esas capas, un CLI agéntico (iiterate).

QUÉ HACE, EN CONCRETO

Una vez por ejecución, event-scout recorre una base de datos curada de fuentes de sitios de eventos, calendarios, boletines y unos pocos feeds de LinkedIn. De todo lo que recupera, conserva solo eventos presenciales y futuros al alcance de Remagen, puntúa cada uno según su utilidad para nosotros, elimina duplicados en un único almacén y reconstruye un panel que de verdad abrimos.

Poco de esa lista es novedoso por sí solo. Lo que lo hace funcionar es que corre sin supervisión según un calendario, y que el juicio que aplica es el nuestro, no un filtro genérico de relevancia. El resultado no es un feed de todos los eventos tecnológicos de Alemania. Es una respuesta corta y clasificada a una pregunta: dónde deberíamos aparecer a continuación.

LA FORMA QUE LO HIZO FUNCIONAR: AGENTE PARA EL JUICIO, SCRIPTS PARA LA FONTANERÍA

La decisión de diseño que importa es dónde se detiene el modelo y empieza un script.

El fetch se delega a un ayudante determinista. Un pequeño orquestador en Node renderiza cada fuente pendiente en un navegador headless real, así maneja páginas con JavaScript, muros ligeros anti-bot y listas de carga diferida, y captura datos de eventos estructurados de schema.org cuando una página los expone. Eso es fontanería: fiable, programable y siempre igual.

El agente lee lo que el fetcher guardó y hace las partes que resisten al hard-coding: extraer eventos reales de páginas desordenadas, decidir qué cuenta como presencial y relevante, puntuar cada uno, y detectar que dos anuncios son el mismo evento. Un segundo pequeño motor fusiona luego, poda entradas viejas y regenera el panel.

🔸 No hagas que el modelo haga lo que un script hace barato.
Renderizar una página y escribir un archivo es trabajo determinista. Pasárselo al modelo sería más lento, más caro y menos fiable.

🔸 No hagas que un script haga lo que necesita juicio.
Si un anuncio a medio formatear es un evento real, relevante y presencial es exactamente la llamada en la que un modelo es bueno y una regex no.

Poner esa línea en el lugar correcto es la mayor razón por la que la herramienta es fiable en lugar de una demo ingeniosa.

SE AJUSTA A SÍ MISMA

Un scout que revisa cada fuente por igual en cada ejecución desperdicia la mayor parte de su esfuerzo, porque los eventos no aparecen de forma uniforme.

Así que cada fuente lleva su propio historial breve de rendimiento. Las fuentes que producen eventos relevantes de forma fiable se revisan en cada ejecución. Las fuentes que vuelven vacías una y otra vez se repliegan hacia un enfriamiento creciente, una semana, luego dos, luego un mes, y se vuelven a probar al expirar en lugar de descartarse. Una fuente que simplemente no renderizó eventos se despriorizó en silencio; solo una fuente que falla al cargar varias veces seguidas se retira como rota.

El efecto es que la atención fluye hacia donde los eventos realmente aparecen, y se ajusta sola a lo largo de semanas sin que nadie la atienda. Ese autoajuste es lo que convierte lo de sin supervisión en una afirmación real y no en un deseo.

LA PUNTUACIÓN CON OPINIÓN LE GANA A UN FEED GENÉRICO

La puntuación es deliberadamente nuestra. Cada evento recibe un valor sobre 100, ponderado según nuestra situación: qué tan cerca y fácil de alcanzar es, con qué densidad la sala reúne el tipo de compradores que servimos, qué tan íntimo es, si hay una palanca concreta como un descuento o un turno para hablar, y qué tan pronto es.

La ponderación lleva una opinión que tenemos sobre la venta. Una gran conferencia solo clasifica alto cuando hay una palanca real que usar, porque para la venta basada en relaciones una sala abarrotada sin una vía de entrada vale menos que una mesa redonda regional pequeña donde de verdad podemos hablar con la gente. El resultado se lee como un panel de decisión más que como un calendario: apunta a dónde invertir un día, no a todo lo que existe.

Un feed genérico de eventos no podría codificar eso, porque el juicio es específico de cómo un equipo concreto gana trabajo. Esa especificidad es la razón por la que valió la pena construirlo en lugar de comprarlo.

POR QUÉ UNA MICRO-APP, NO UN SAAS

event-scout es pequeño a propósito. Todo el asunto es un puñado de archivos JSON para las fuentes y el almacén de eventos, un par de scripts y un panel HTML autocontenido que se abre directo desde el disco. No hay base de datos que correr ni suscripción que renovar. Los datos siguen siendo nuestros, y también la puntuación.

Este es el mismo movimiento que los propios equipos no técnicos de Anthropic han descrito, construir pequeñas herramientas internas con un agente de codificación en lugar de presentar una solicitud y esperar (claude.com). Sobre ese patrón hemos escrito también desde el lado del usuario (iiterate).

No está libre de asperezas, y pretender lo contrario sería deshonesto. Las fuentes con muro de login necesitan una sesión capturada a mano una vez. Unos pocos sitios tercos siguen siendo leads manuales en lugar de resultados falsos. Y verificamos cada reconstrucción revisando la estructura de la página directamente, porque una captura de pantalla se atasca en la carga de una fuente tipográfica. Nada de eso cambia la conclusión: cuando una tarea es repetible y específica de cómo trabajas, un agente de codificación puede convertirla en una pequeña herramienta propia por menos que el SaaS o las horas manuales que reemplaza. La pregunta más difícil no es si puedes construir una. Es cuál de tus tareas semanales ha estado esperando en silencio convertirse en una.

Claude Code está construido para ingenieros, pero el trabajo del que se ha hecho cargo silenciosamente para nosotros está en marketing y en el back office: las tareas repetibles y sujetas a reglas que nadie disfruta. La razón por la que encaja ahí es simple. Alguien que conoce un procedimiento, las reglas de marca, la lista de comprobación de cierre de mes, la forma en que etiquetamos una exportación de campaña, lo escribe una vez en lenguaje llano, y el agente lo ejecuta contra archivos reales. Sin proyecto de software, sin un desarrollador en el bucle. Este artículo es lo que hemos aprendido sobre dónde eso vale la pena, dónde no y cómo empezar sin arrepentirse.

El cambio real no es programar. Es escribir el procedimiento

Para una persona no desarrolladora, un agente de programación es una forma de convertir un procedimiento repetible en algo que una máquina ejecuta, sin construir software primero.

El mecanismo que hace que esto funcione fuera de la ingeniería son las Agent Skills. Una skill es una pequeña carpeta: un archivo de instrucciones en lenguaje llano, opcionalmente uno o dos scripts, y el material de referencia que necesita. El agente solo ve el nombre de una skill y una descripción de una línea hasta que tu tarea la necesita, y entonces lee las instrucciones completas bajo demanda. Simon Willison, que documentó el formato cuando se lanzó en octubre de 2025, expuso su economía con claridad: cada skill cuesta solo unas pocas docenas de tokens hasta el momento en que se usa (simonwillison.net, Anthropic).

La consecuencia es la parte que importa para un equipo del Mittelstand:

🔸 El autor es un experto en el dominio, no un programador.
La persona que conoce el proceso escribe la skill, como haría al informar a una nueva incorporación.

🔸 Los conectores le dan alcance real.
A través de MCP, un estándar abierto de conectores, el agente puede leer y actuar en sistemas reales, una hoja de cálculo, una unidad compartida, una cola de tickets, bajo el acceso que le concedas.

🔸 Tú decides el radio de acción.
Solo toca lo que le permitas tocar. Ese límite de permisos es todo el juego, y volvemos a él más abajo.

Tres tareas aburridas donde realmente vale la pena

Las victorias son poco glamurosas y repetibles. Tres patrones se han sostenido para nosotros y en el registro público.

Variantes de marketing a volumen. El propio equipo de Growth Marketing de Anthropic conectó dos subagentes especializados para leer un CSV de cientos de anuncios activos, marcar los de bajo rendimiento y escribir nuevas variantes dentro de estrictos límites de caracteres, minutos de trabajo en lugar de horas. Un plugin de Figma complementario genera hasta 100 variaciones de diseño por lote intercambiando titulares y descripciones (claude.com). Es su propio equipo, así que léelo como prueba de que el patrón funciona, no como tu cifra.

Ordenar datos del back office. El tramo aburrido de la semana: conciliar un extracto de tarjeta en una hoja de gastos, limpiar una lista desordenada, redactar un informe recurrente a partir de una plantilla. Un fundador en solitario, no técnico, en r/SaaS describió cómo ejecutaba prácticamente toda su operación de SEO a través de Claude, reportando 1,54 millones de impresiones de búsqueda y 12.900 clics en tres meses sin ingeniero y sin agencia (r/SaaS). El informe de una sola persona, pero revelador.

Herramientas internas construidas por quien las necesita. El equipo legal de Anthropic prototipó un pequeño "árbol telefónico" que dirige una pregunta al abogado adecuado, construido por un abogado de producto que no escribe código (claude.com). Lo interesante no es la herramienta. Es quién la construyó, y que no tuvo que abrir un ticket para hacerlo.

Hemos escrito antes sobre dónde la IA realmente se gana su lugar en un negocio en lugar de dónde luce bien en una demo (iiterate); esta es la misma prueba aplicada a una sola herramienta.

Por qué marketing y operaciones, en concreto

Estas funciones encajan porque su trabajo es repetible, sujeto a reglas y ya vive en archivos.

Eso se corresponde limpiamente con lo que una skill puede contener. Una skill de directrices de marca lleva la paleta, las reglas tipográficas y el tono de voz. Una skill de procedimiento lleva la lista de cierre o un paso de cumplimiento. Una skill de plantilla lleva el propio documento. Anthropic distribuye una skill de directrices de marca funcional como ejemplo público, con reglas de color, tipografía y maquetación que un agente aplica a petición (GitHub, Anthropic).

El hallazgo recurrente en estos informes es que la experiencia en el dominio impulsa el resultado más que la habilidad de programar. Esa es la ventaja silenciosa del Mittelstand. La persona que conoce el proceso ya está en el edificio, y una skill no es más que su proceso, escrito.

Dónde es la herramienta equivocada

Un agente de programación es la herramienta equivocada en el momento en que el trabajo deja de ser repetible, verificable o seguro de entregar a un agente con acceso amplio. Los riesgos honestos, en el orden en que muerden:

Radio de acción. Un agente con acceso a archivos y sistemas puede borrar la carpeta equivocada o enviar el mensaje equivocado. Dale el mínimo privilegio: primero solo lectura, una carpeta, una copia de los datos, no el original. Los equipos de seguridad han catalogado lo que sale mal cuando se omite este paso (Docker, Oso).

Respuestas erróneas con aplomo. Afirmará una cifra que no verificó, en prosa fluida. Mantén un control humano sobre cualquier cosa que salga del edificio.

Gobernanza y datos. En el momento en que toca datos personales o de clientes, aplican el RGPD y el EU AI Act. Sabe dónde residen los datos y quién puede ser auditado antes de conectarlo, que es la misma cuestión de control detrás de ejecutar modelos propios en lugar de alquilarlos (iiterate).

Procedencia. La mayoría de los casos de estudio pulidos, incluidos dos de este artículo, los publica el proveedor. Léelos como evidencia de que el trabajo es posible, no como evidencia de tu retorno.

Cómo empezar sin arrepentirse

Empieza en pequeño, con trabajo que te puedas permitir equivocar.

1. Elige una tarea que sea repetible y sujeta a reglas, y que no sea tu proceso más importante.
2. Escribe el procedimiento como una skill en lenguaje llano, como informarías a una nueva incorporación capaz en su primer día.
3. Concede acceso de mínimo privilegio: solo lectura, una carpeta, una copia de los datos.
4. Mantén un control humano sobre cualquier cosa que salga por la puerta o toque los datos de una persona.
5. Mide con la métrica aburrida, horas ahorradas en la tarea tediosa, no en cómo se sintió la demo.

Hecho así, las victorias son pequeñas y se acumulan, que es lo opuesto a cómo suele venderse esta tecnología. La pregunta que vale la pena considerar no es si un agente de programación puede hacer trabajo de marketing o de operaciones. Es cuáles de tus procedimientos has escrito realmente, porque eso, y no el modelo, es lo que decide hasta dónde llega esto.

El dictamen clave del Comité Europeo de Protección de Datos sobre modelos de IA se apoya en la frase "caso por caso", y la guía conjunta del CEPD y la Comisión Europea sobre cómo el RGPD se cruza con el Reglamento de IA de la UE no se espera antes de principios de 2026. Así que la pregunta útil no es "¿está permitida la IA bajo el RGPD?". Es "¿bajo qué condiciones, y cuáles de esas condiciones controlamos de verdad?". Este artículo mapea los pocos límites duros, el amplio centro condicional y las palancas que un equipo de una pyme puede accionar. Es orientación, no asesoramiento jurídico, así que involucra a tu delegado de protección de datos antes de actuar.

EMPIEZA POR LAS POCAS COSAS QUE ESTÁN GENUINAMENTE RESTRINGIDAS

Una lista corta de usos de IA está cerca de una prohibición real bajo el RGPD. Conocerlos primero facilita razonar sobre el resto.

• Decisiones únicamente automatizadas sobre personas. El artículo 22 restringe las decisiones con efecto jurídico o similarmente significativo que se toman sin intervención humana significativa. Las autoridades de control alemanas lo leen de forma estricta y esperan una supervisión humana efectiva en lugar de un sello de goma (Hogan Lovells).
• Datos de categorías especiales por defecto. Los datos de salud, biométricos, de creencias y similares están prohibidos para el tratamiento bajo el artículo 9 salvo que aplique una excepción específica. El Reglamento de IA de la UE añade una apertura estrecha: el artículo 10(5) permite tales datos estrictamente para detectar y corregir sesgos en sistemas de alto riesgo (IAPP).
• Modelos construidos sobre datos recopilados ilícitamente. El Dictamen 28/2024 del CEPD, publicado el 18 de diciembre de 2024, sostiene que si un modelo se desarrolló usando datos personales tratados ilícitamente, eso puede viciar la licitud de su despliegue, salvo que el modelo haya sido debidamente anonimizado (CEPD).

La mayor parte del trabajo con IA queda fuera de esta lista corta, donde la respuesta rara vez es un "no" rotundo. Es un "sí, si".

LA MAYOR PARTE ES CONDICIONAL, NO PROHIBIDA

El amplio centro del trabajo con IA es lícito cuando puedes mostrar las condiciones correctas y documentarlas.

Dos condiciones hacen la mayor parte del trabajo. La primera es una base jurídica. Para entrenar y usar modelos con datos personales, el CEPD estableció una prueba de tres pasos para apoyarse en el interés legítimo, sopesando el interés en sí, si el tratamiento es necesario, y un equilibrio frente a los derechos de las personas en los datos (CEPD). El interés legítimo está disponible, pero se gana con esa prueba, no se presupone.

La segunda es la anonimidad, que no puedes declarar por tu cuenta. El mismo dictamen sostiene que un modelo entrenado con datos personales no es automáticamente anónimo. Cuenta como anónimo solo cuando es muy improbable tanto identificar a las personas cuyos datos lo entrenaron como extraer esos datos mediante consultas, evaluado caso por caso por la autoridad de control (IAPP). El dictamen se apoya tanto en "caso por caso" que los analistas jurídicos contaron la frase a lo largo del texto (Ropes & Gray). La lectura práctica: la mayor parte del tratamiento con IA está permitida, con la condición de que puedas mostrar tu base y tu documentación.

LAS CONDICIONES SON EN SU MAYORÍA ARQUITECTÓNICAS

La parte alentadora es que las condiciones que debes cumplir las decide en gran medida cómo construyes el sistema, no quién eres.

• Conserva menos, por menos tiempo. La minimización de datos y la limitación de la finalidad aplican a los lugares específicos de la IA donde se esconden los datos: registros de prompts y de sistema, y los vectores dentro de un almacén RAG. La guía del CEPD apunta a minimizar lo que se registra, preferir identificadores agregados o seudónimos, y retención corta (análisis del CEPD).
• Decide dónde residen los datos, a propósito. Desde la sentencia Schrems II, enviar datos personales a un proveedor de EE. UU. no queda zanjado con firmar cláusulas contractuales tipo. Tienes que evaluar si esas cláusulas pueden realmente sostenerse dada la ley de vigilancia de EE. UU., y esa responsabilidad no se puede traspasar al proveedor (análisis).

Esta es la razón práctica por la que la residencia de datos y el despliegue on-prem son palancas de control en lugar de ideología, el mismo punto detrás de operar modelos que posees en lugar de alquilar (iiterate).

EL RGPD Y EL REGLAMENTO DE IA DE LA UE SON DOS REGÍMENES, NO UNO

Ayuda tratar la protección de datos y la regulación de la IA como obligaciones separadas que se encuentran, en lugar de un solo reglamento.

El RGPD es un régimen de derechos fundamentales sobre datos personales; el Reglamento de IA de la UE se parece más a una ley de seguridad de productos para sistemas de IA (IAPP). Un sistema de alto riesgo puede deber obligaciones bajo ambos: una Evaluación de Impacto relativa a la Protección de Datos bajo el artículo 35 del RGPD, y una Evaluación de Impacto sobre los Derechos Fundamentales bajo el artículo 27 del Reglamento de IA, que la complementa en lugar de reemplazarla. Los dos también interactúan de formas incómodas. Los profesionales señalan, por ejemplo, que la elaboración de perfiles del RGPD puede volver a meter en el ámbito un sistema que una exención del Reglamento de IA parecía liberar (r/gdpr). La ayuda oficial está en camino: el CEPD y la Comisión Europea deben publicar una guía conjunta sobre el solapamiento a principios de 2026 (IAPP).

UNA POSTURA DE CUMPLIMIENTO OPERATIVA PARA UN EQUIPO DE UNA PYME

No necesitas una certeza que el regulador no ha proporcionado. Necesitas una postura defendible y documentada. Un orden práctico:

1. Mapea dónde entran los datos personales en el sistema: entradas, prompts, registros, datos de entrenamiento y el almacén RAG.
2. Elige y anota una base jurídica para cada uso. Si te apoyas en el interés legítimo, ejecuta la prueba de equilibrio en lugar de presuponerla.
3. Ejecuta una EIPD antes de desplegar cualquier cosa que elabore perfiles o decida sobre personas, y mantén a un humano significativamente en el bucle para los casos del artículo 22.
4. Minimiza y acota en el tiempo lo que el sistema conserva, especialmente registros de prompts y vectores.
5. Decide la residencia de datos de forma deliberada. Si los datos personales fueran a salir de la UE, haz la evaluación de la transferencia, o mantén el tratamiento en la UE u on-prem.
6. Revisa la postura cuando llegue la guía conjunta del CEPD y la Comisión en 2026.

La versión corta: muy poco sobre la IA está categóricamente prohibido bajo el RGPD, unas pocas cosas genuinamente lo están, y la mayor parte del resto es un "sí, si" documentado. Las condiciones que lo deciden son en su mayoría arquitectónicas, lo que significa que son tuyas de fijar. Las mismas preguntas de gobernanza afloran en cuanto un agente interno toca datos de clientes (iiterate). Esto sigue siendo orientación en lugar de asesoramiento jurídico, así que haz de tu delegado de protección de datos el próximo lector.

La escena europea de modelos, Mistral y los actores a su alrededor, tiene dinero real y modelos reales en 2026. También se sitúa por detrás de la frontera estadounidense y china en capacidad pura, y la palabra europeo en una etiqueta no significa por sí sola soberano. Así que para una empresa mediana la pregunta útil no es si existe un modelo europeo. Es qué tipo de control necesita realmente, y qué se lo proporciona. Este artículo expone el panorama, las brechas honestas y la decisión que hay debajo.

Qué significa realmente soberano, y qué no

IA soberana significa que el modelo y sus datos permanecen bajo el control legal y operativo de una organización. Las palancas que lo logran son concretas: pesos abiertos que puede autoalojar, y un alojamiento que mantiene los datos en la UE o en sus propias máquinas.

Dos advertencias honestas impiden que la palabra se convierta en marketing.

🔸 Un código postal en la UE no es soberanía por sí mismo.
Las leyes de acceso estatal, incluidas las de Francia y Alemania, pueden obligar a entregar datos de formas que una ubicación en la UE no protege del todo. Dónde residen los datos es necesario, no suficiente.

🔸 La propiedad decide tanto como el origen.
Silo AI, el fabricante finlandés de los modelos abiertos Poro y Viking, es ahora filial de AMD, una empresa estadounidense, lo que la somete a la legislación de EE. UU. Un modelo nacido en Europa bajo propiedad extranjera no es automáticamente uno soberano (North Atlantic).

La soberanía, entonces, es una cuestión sobre el stack y su propiedad, no una bandera en una página de inicio.

Mistral, y el dinero que hizo que Europa fuera en serio

Mistral es la razón por la que la IA europea dejó de ser una nota al pie, y la forma en que se armó su financiación es la señal de verdad.

En su ronda reportada en septiembre de 2025, Mistral recaudó unos 1.700 millones de euros con una valoración de aproximadamente 11.700 millones, y el inversor principal fue ASML, el fabricante neerlandés de equipos de chips, aportando unos 1.300 millones de euros (CNBC). Que una empresa que vende las máquinas que fabrican chips avanzados invierta en un laboratorio de modelos es un movimiento de soberanía, no solo financiero. Mistral lo ha combinado con infraestructura, apuntando a unos 200 megavatios de computación europea para 2027, en propiedad en lugar de alquilada, en emplazamientos cerca de París y una gran construcción nueva en Suecia (Data Center Dynamics). Su tracción empresarial también es real, con trabajo declarado junto a Airbus, BMW, Amazon y SAP.

La historia que Mistral cuenta sobre sí misma es la parte útil: no intenta ganar la carrera pura de modelos contra los gigantes estadounidenses, intenta poseer el stack europeo que se sitúa bajo los modelos. Para un comprador que se preocupa por el control, ese enfoque importa más que un puesto en una tabla de clasificación.

Y más allá: el resto del banquillo europeo

Mistral no es todo el campo, y los demás revelan apuestas distintas sobre dónde reside el valor europeo.

Aleph Alpha, la empresa de Heidelberg que en su día se presentaba como la esperanza de modelo frontera de Alemania, dejó de perseguir la frontera y se reconstruyó en torno a una plataforma de soberanía y cumplimiento, PhariaAI, orientada al despliegue on-prem y aislado en sectores regulados (análisis). Black Forest Labs, fundada en Friburgo por parte del equipo original de Stable Diffusion, crea la familia abierta de modelos de imagen FLUX (Dakota). Y Teuken-7B, del consorcio OpenGPT-X liderado por Fraunhofer, es un modelo descargable de forma abierta entrenado en las veinticuatro lenguas oficiales de la UE, construido para autoalojarse (Fraunhofer).

El patrón que vale la pena notar es que las apuestas europeas más fuertes tienen cada vez más que ver con el stack, la apertura y el modelo de despliegue, más que con un único modelo frontera. Y ahí es justamente donde reside la ventaja de un comprador mediano.

La brecha honesta de capacidad

Ser sobrio es más creíble que ser entusiasta, así que aquí va la brecha sin rodeos. En índices de capacidad independientes, el buque insignia europeo se sitúa en torno a la zona media del pelotón de pesos abiertos, no en la frontera (Artificial Analysis). La financiación también está desequilibrada: la financiación combinada de modelos de Europa es pequeña frente a la valoración de un único laboratorio estadounidense, más cercana a un error de redondeo que a una rivalidad (North Atlantic).

El movimiento útil no es negar la brecha, sino preguntar si toca su tarea. Para redacción, extracción, clasificación y retrieval sobre sus propios documentos, un modelo abierto de la zona media que usted controla del todo suele superar el listón, y el control vale más que los últimos puntos de benchmark. Ese es el mismo compromiso que trazamos cuando un modelo frontera desapareció de un mercado en setenta y dos horas: el control operativo supera a la capacidad alquilada cuando la capacidad que alquila puede serle retirada (iiterate). La frontera es donde los modelos europeos genuinamente se quedan atrás. También es la parte del trabajo que muchas empresas en realidad no necesitan.

Qué significa esto para un comprador de la mediana empresa

La decisión no es patriótica, es arquitectónica. Tres caminos prácticos, según lo que necesite la carga de trabajo:

1. Necesita capacidad frontera, datos no sensibles. Un modelo frontera alojado sigue siendo la opción más capaz. Úselo, y acepte la dependencia con conocimiento de causa.
2. El control es lo que importa. Para datos regulados, confidencialidad de clientes o cualquier cosa que deba poder auditar, autoaloje un modelo europeo abierto o de pesos abiertos, o use inferencia alojada en la UE, y ponga la residencia y la propiedad de los datos en la especificación, no en el marketing.
3. Juzgue la soberanía por el stack, no por la bandera. Dónde se ejecutan los pesos, dónde residen los datos, quién puede obligar a dar acceso y si puede intercambiar el modelo. La misma cuestión de control se sitúa bajo el RGPD (iiterate).

La escena europea es por fin lo bastante real como para ser una respuesta seria para el segundo caso, que es la mayor parte de lo que se nos pide construir. La razón para preocuparse no es la bandera. Es que la capacidad alquilada es revocable y el control es algo que se construye. La pregunta que vale la pena sostener no es si Europa puede igualar la frontera este año. Es cuáles de sus cargas de trabajo necesitan de verdad la frontera, y cuáles solo necesitan un modelo capaz que usted controle.