La Yunqi Conference no es la respuesta, es el mapa de lo que la industria de la IA está apostando
【Observación Apsara】La Conferencia Apsara no es la respuesta: es un mapa de hacia dónde apuesta la industria de la IA
Recorrer esta edición de la Conferencia Apsara (la gran cita tecnológica de Alibaba en Hangzhou) me dejó una enseñanza más valiosa que añadir unos cuantos modelos o empresas nuevas a la lista: cambió mi forma de mirar una feria.
Antes, al asistir a una conferencia tecnológica, era fácil caer en una serie de juicios predeterminados: la dirección que los grandes fabricantes destacan en sus ponencias probablemente representa el futuro; los conceptos que reaparecen una y otra vez sobre el escenario probablemente son el consenso del sector; y un producto que ya cuenta con stand propio parece indicar que está lo bastante maduro. Tras asistir a muchas, también es fácil deslizarse hacia el extremo opuesto: pensar que la conferencia es puro marketing, los stands son publicidad y las presentaciones son envoltorio.
Ambas miradas son demasiado cómodas.
Una feria, por supuesto, tiene su vertiente comercial, pero el marketing en sí mismo también es información. Cuando un fabricante decide concentrar presupuesto, equipos de producto, ingeniería, ventas y recursos de stand alrededor de una dirección concreta, al menos está revelando dos cosas: qué quiere que el mercado crea, y a qué problemas está intentando responder con productos reales.
Por eso ahora prefiero tratar las grandes conferencias tecnológicas como un terreno de muestreo industrial de alta densidad. No te dan respuestas, pero te ofrecen muestras, señales, contraejemplos y un mapa del “futuro por el que está apostando el sector”.

I. Primero, descompón el “bullicio” de la feria en distintos niveles de evidencia
En esta edición empecé a descomponer, de forma consciente, cada dirección tecnológica en cinco niveles:
Capa narrativa → Capa producto → Capa producción → Capa negocio → Capa ingresos
(Narrative → Product → Production → Business → Revenue)
En la cima se sitúa la capa narrativa (Narrative): lo que los proveedores quieren que el mercado crea. Por ejemplo, que los agentes (Agent) se convertirán en la nueva puerta de entrada al trabajo, que las empresas necesitarán arquitecturas AI-native, que el contexto (Context) se convertirá en un activo central y que los sistemas multi-agente asumirán tareas cada vez más complejas. Estas afirmaciones son valiosas porque revelan hacia dónde se están desplazando la atención y el capital de las organizaciones, aunque no dejan de ser juicios y apuestas.
Un nivel por debajo aparece la capa producto (Product): lo que ya se ha construido y puede mostrarse, invocarse y entregarse. En los stands hay interfaces completas, APIs, consolas y plataformas de gobernanza, lo que demuestra que una dirección concreta ha pasado de concepto a producto. Entre “que pueda demostrarse” y “que pueda operar de forma estable y prolongada” sigue existiendo una distancia considerable.
Más abajo está la capa producción (Production): cuando el producto entra realmente en los flujos del cliente, opera de forma continua y empieza a chocar con problemas reales como permisos, datos, auditoría, recuperación, costes y coordinación organizativa. Solo entonces puede hablarse de producción.
Bajamos un nivel más hasta la capa de negocio (Business): hay que seguir preguntando, ¿qué cambió después del despliegue? ¿Se acortaron los ciclos de entrega? ¿Subieron las conversiones? ¿Bajaron los costes de mano de obra? ¿Aumentó el volumen de creatividades publicitarias en test? ¿O se hizo viable un proceso de negocio que antes no se podía ejecutar?
En la base —y también la más tangible— está la capa de ingresos (Revenue): si el cliente está dispuesto a pagar a largo plazo, por qué resultado concreto paga, y en qué condiciones se produce la renovación.
La utilidad de este marco es evitar mezclar evidencias de distinta naturaleza. Un stand demuestra que una dirección merece ser exhibida; un foro demuestra que el proveedor quiere reforzar cierta percepción; un caso de cliente real aumenta la credibilidad de las capas de producción y de negocio; solo los ingresos sostenidos validan la capa de ingresos.
Así que el hecho de que una dirección esté muy de moda en el congreso no implica directamente que “ahora haya que invertir”.

2. El cambio más evidente esta vez: sobre el modelo están creciendo cada vez más capas
Hace unos años, cuando se hablaba de IA, la atención estaba casi toda puesta en el modelo: tamaño de parámetros, benchmarks, capacidad de razonamiento, precio, ventana de contexto, calidad de imagen, capacidad de generación de código.
En esta ocasión, sobre el terreno, noté claramente que el foco se está desplazando.
Los modelos siguen siendo importantes, pero la capa de sistemas que se construye sobre ellos se ha engrosado de forma evidente. Capa de datos, acceso a modelos, gestión de tokens, Agent Runtime, sandboxes, context, memory, skills, Browser Use, Computer Use, verification, observability, permisos, auditoría y control de costes son cada vez más capacidades que se empaquetan como productos independientes.

La razón es directa: entre un modelo que responde preguntas y un modelo que se incorpora a un flujo de producción y completa tareas con fiabilidad, media todo un sistema de ingeniería.
Si recorres una feria tecnológica durante un día, verás cinco o seis productos con nombres completamente distintos, pero en el fondo todos están convergiendo hacia la misma estructura. QwenWork (plataforma agentic de Alibaba) muestra cómo un agente invoca múltiples herramientas dentro de un entorno aislado para completar tareas. Qoder habla de contexto, especificaciones (Spec), marcos de prueba (Harness), verificación (Verification), memoria y enrutamiento multi-modelo. TinyFish, un proveedor independiente presente en el evento, se especializa en hacer que los agentes entren en páginas web reales para ejecutar tareas. WonderClip descompone la producción de vídeo en guion, storyboard, material, generación, revisión, versiones y producción por lotes. La búsqueda agentic (Agentic Search) de Alibaba Cloud OpenSearch lleva la búsqueda hacia planificación (Planning), razonamiento (Reasoning), memoria (Memory), acción (Action) y evaluación (Evaluation).
Parecen pertenecer a dominios completamente distintos, pero la arquitectura subyacente está convergiendo:
Contexto → Planificación → Habilidad → Ejecución → Verificación → Memoria → Resultado de negocio
(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)
Los modelos se han ido convirtiendo en uno de los componentes clave, y el valor del producto reside cada vez más en las capas superiores del sistema.

3. El contexto (Context) pasa de ser «material de entrada» a activo a largo plazo
Qoder (asistente de codificación de Alibaba) lo dejó meridianamente claro en una diapositiva mostrada en directo:
Model power is a commodity. Context is the asset.
Evidentemente, la frase tiene sesgo de fabricante, pero apunta a un problema muy real: cuanto más potente y accesible resulta un modelo, menos depende de su capacidad bruta y más de «lo que realmente sabe» un agente (Agent) a la hora de funcionar de forma sostenida en el tiempo.
En un proyecto de software maduro encontramos restricciones arquitectónicas, decisiones heredadas, dependencias entre módulos, estándares de código, tropiezos ya documentados e historial de despliegues. En una empresa hay organigramas, permisos, SOP (procedimientos operativos estándar), documentación, chats internos, reglas de negocio y el estado de cada cliente. En una marca hay catálogos de productos, manuales de identidad visual, materiales acumulados, datos de campañas y restricciones por canal.
Nada de esto aparece por arte de magia por mucho que sustituyamos el modelo por uno más potente.
Por eso Qoder integra un wiki del repositorio de código (Repo Wiki), memoria (Memory) y tarjetas de conocimiento (Knowledge Cards); QwenWork pone el acento en el contexto empresarial (Enterprise Context), y OpenSearch prioriza la memoria a largo plazo, la memoria de tareas y la compresión de contexto. Todos apuntan al mismo problema: que el agente no tenga que partir de cero cada vez para entender el mundo.
Esto también pone en duda el valor real, a largo plazo, de las bibliotecas de prompts (Prompt Library) que muchos equipos venían acumulando. El prompt es, más bien, la forma de invocar una tarea concreta; lo que de verdad genera efecto compuesto es el contexto de negocio, el historial de decisiones, los resultados de validación, las causas de los fallos y las capacidades reutilizables.
Cuatro. La unidad de competencia de los productos de IA pasa de «una función» a «un trabajo completo»
WonderClip me dejó esa sensación especialmente clara.
Si uno se queda solo en la lista de capacidades, muchas funciones no son ninguna novedad: generar imágenes, generar vídeo, traducir, doblar, sustituir material o producir en lote. Vistas de forma aislada, cada una puede ser absorbida sin problema por los proveedores de modelos, el software de edición o cualquier otro SaaS.
Pero la estructura de producto que mostraron en directo ya apunta hacia un sistema de producción mucho más completo:
Subir el guion → Revisar el desglose → Preparar los recursos → Generar en masa
Después vienen Storyboard, Canvas, habilidades personalizadas, recursos compartidos, colaboración en equipo y gestión de versiones. El producto devuelve la “generación” al centro del flujo de trabajo.

De aquí se extrae una lección directa para quien desarrolla aplicaciones de IA.
Si el núcleo del producto sigue siendo “subir algo, dejar que la IA lo procese y bajar el resultado”, cada nueva actualización del modelo comprimirá con facilidad su valor. Un camino más estable consiste en hacerse cargo de la totalidad del trabajo que el usuario ya debía completar.
Tomemos el escenario de contenidos para e-commerce: por sí solas, acciones como cambiar de producto, sustituir el fondo, traducir o doblar son capacidades superficiales. Subiendo un escalón, el objeto del producto debería evolucionar progresivamente hacia la marca (Brand), el SKU, la campaña (Campaign), el mercado (Market), la estrategia creativa (Creative Strategy), las variantes (Variants), los canales de distribución (Distribution) y el rendimiento (Performance). La generación no es más que el motor de ejecución; el verdadero valor reside en la totalidad del flujo de trabajo de operaciones creativas (Creative Operations Workflow).
5. El Agent está pasando de “responder preguntas” a “completar tareas”
Hoy, en una sesión sobre agentic search de Alibaba Cloud OpenSearch, un diagrama de evolución me resultó especialmente elocuente.
Al principio, la búsqueda resolvía el trayecto de la consulta (Query) a la lista de resultados (Results). La IA generativa lo llevó un paso más allá: de la pregunta (Question) a la respuesta (Answer). La agentic search avanza otra etapa y reformula el objetivo como el camino de la meta (Goal) a la acción (Action).
Dicho de otro modo, la propia búsqueda se está reposicionando.
Un agente de investigación (Research Agent) del futuro cercano podría descomponer automáticamente una pregunta, trazar un plan de consulta, invocar múltiples fuentes de búsqueda, complementar con nuevas rondas de retrieval, contrastar la información, generar conclusiones intermedias y, a partir de ahí, llamar a otras herramientas para continuar la ejecución. La interfaz de búsqueda (API) empieza a parecerse más a una infraestructura que el agente utiliza para obtener contexto externo.
Esto también cambiará la forma de observar el SEO y el GEO (Generative Engine Optimization). Antes el foco estaba en impresiones (Impression), clics (Click) y posicionamiento (Ranking). Ahora habrá que monitorizar, además, la visibilidad ante la IA (AI Visibility), las citas (Citation), las menciones (Mention), el tráfico referido por IA (AI Referral), y si ese tráfico acaba en registros (Signup), conversión de pago (Paid) y retención (Retention).
La búsqueda no ha desaparecido: ahora se integra en circuitos cerrados de tareas más amplios.

6. El verdadero reto de la IA empresarial entra en la dimensión organizativa
En el congreso se habló largo y tendido sobre los aspectos técnicos de la IA corporativa: datos, permisos, seguridad, gobernanza, acceso a modelos, arquitectura cloud, plataformas de agentes.
Todo eso importa. Pero, tras escuchar varios casos reales de empresa, lo que más me preocupa es otra pregunta:
¿Quién tiene realmente incentivos para adoptarla?
Supongamos que un empleado usa IA y reduce una tarea de 8 horas a 5. ¿Qué pasa con esas 3 horas ahorradas? Si la única respuesta es “asignarle más trabajo”, lo más probable es que la motivación del empleado para impulsar la IA de forma proactiva sea bastante limitada.
Otro ejemplo: si el KPI del equipo de IA se mide por el número de agentes desplegados y el volumen de invocaciones, tendrá incentivos para añadir funcionalidades sin parar; el equipo de negocio asume el coste de la reingeniería de procesos; los equipos de TI y seguridad cargan con el riesgo de los errores; y el incremento de ingresos no se puede atribuir con claridad. En una estructura organizativa así, aunque la tecnología esté disponible, la adopción real puede avanzar muy lenta.
La IA empresarial no puede juzgarse solo por la arquitectura (Architecture): el diseño de incentivos (Incentive Design) es el verdadero techo.
Los problemas técnicos se resuelven con dinero; los organizativos, en cambio, no siempre se resuelven por mucho presupuesto del que se disponga. En cualquier proyecto, como mínimo, hay que dejar claros seis elementos: Rol (Role), KPI, Beneficio (Benefit), Coste (Cost), Riesgo (Risk) y Potestad de decisión (Decision Right). Quien obtiene el beneficio asume el riesgo; quien tiene la potestad de decidir responde del resultado.
Muchos de los llamados «problemas de implementación de IA» son, en el fondo, problemas de diseño organizativo.

VII. Los indicadores que más engañan suelen ser los más intuitivos a simple vista
Hay una diapositiva de Qoder que me dejó especialmente marcado:
Generation rate is a vanity metric.
En la presentación se comparaba el porcentaje de código generado por IA en distintas fases, al tiempo que se subrayaba que el Delivery Cycle (ciclo de entrega) no se había acortado en la misma proporción. Las cifras concretas proceden de un caso real mostrado por el propio fabricante, por lo que no deben tomarse como Benchmark de referencia para el sector. No obstante, la lógica de fondo se sostiene.
Cuando la IA abarata el coste de escribir código (Coding), el cuello de botella se desplaza hacia los requisitos (Requirement), el contexto (Context), la arquitectura (Architecture), la revisión (Review), las pruebas (Test), la integración (Integration), el despliegue (Deployment) y la validación (Validation).
Por eso, indicadores como la tasa de generación de código, el consumo de Tokens, el número de agentes, las invocaciones o el volumen de imágenes producidas pueden parecer mejoras locales de eficiencia. Lo que realmente importa es el resultado de extremo a extremo: si el plazo de entrega (Lead Time) se acorta, si las horas-hombre invertidas (Human Minutes) bajan, si la tasa de aceptación a la primera (First-pass Acceptance Rate) sube, si el coste por tarea aceptada (Cost per Accepted Task) disminuye y, en última instancia, si las métricas de negocio cambian.
La conferencia me dejó una lección: no te dejes deslumbrar por “cuánto ha hecho la IA”, mira “qué ha cambiado en todo el sistema gracias a ella”.
Ocho. La conferencia propone apuestas, pero el criterio sigue siendo tuyo
Lo más fácil que pasa cuando asistes a un evento así es que el mundo exterior empiece a fijar tus prioridades por ti.
Si en el escenario se habla mucho de una línea de trabajo, sientes que deberías investigarla; si una gran empresa invierte a fondo en algo, sientes que deberías seguirla; si un producto parece puntero, sientes que tú también deberías montar algo equivalente.
Esta vez prefiero reducir toda esta información a una pregunta más simple:
¿Qué decisión mía va a cambiar esta información?
Si solo me parece “interesante”, no pasa de insumo.
Si me obliga a replantear Build, Buy o Ignore, a mover el alcance de un producto, a detener una iniciativa de bajo valor, a rediseñar un flujo de trabajo o a redefinir la métrica de un experimento, entonces sí entra en la decisión.
La Conferencia Apsara (云栖大会, el evento insignia anual de Alibaba Cloud) no es la respuesta.
Se parece más a un mapa de apuestas del sector. Un mapa que me dice hacia dónde van los demás, qué caminos empiezan a congestionarse, qué infraestructura está tomando forma y qué problemas empiezan a empaquetarse como producto a gran escala.
Qué camino tomar al final sigue dependiendo de tus propios objetivos, restricciones, recursos y evidencia.
Y eso es precisamente lo que más quiero conservar cuando asisto hoy a una conferencia tecnológica: ver más apuestas, sin soltar el timón del juicio propio.
Si estás evaluando por dónde debería arrancar la IA en tu empresa, qué direcciones merecen inversión y cuáles son burbujas infladas por la narrativa, charlemos. Hacemos consultoría especializada en transformación de IA empresarial: desde la selección tecnológica y el diseño organizacional hasta el sistema de medición, te ayudamos a convertir el “ruido de la conferencia” en “tu propio criterio”. Correo de contacto: [email protected].
Lectura recomendada: 《AI 转型七步框架》 (Marco de siete pasos para la transformación con IA), donde se explica de forma sistemática la ruta completa para llevar la IA a la empresa.
Sobre esta serie
«Observaciones Yunqi» es una serie de IAIUSE sobre el terreno industrial. Partiendo de la Conferencia Yunqi 2026, analiza con mirada de investigadora los cambios reales que atraviesa el sector de la IA: sin perseguir modas, solo observando hacia dónde se dirigen las apuestas y con qué solidez se sostiene la evidencia.
La serie cubre temas como la capa de sistema por encima de los modelos, el despliegue de Agentes, los activos de Contexto, el diseño organizativo de la IA corporativa y el desplazamiento de la unidad competitiva en los productos de IA, a lo largo de unas diez entregas.
Cuento con casi ocho años de experiencia en consultoría y análisis de negocio para grandes empresas; trabajé en IBM y participé en proyectos de telecomunicaciones, finanzas, seguros y manufactura. Después seguí en primera línea con productos para operadores, productos de internet y desarrollo de aplicaciones de IA, en análisis de requerimientos, diseño de producto y ejecución interequipos. Las afirmaciones de esta serie nacen de mi observación directa sobre el terreno y de la validación cruzada con el sector: llevan una postura de autora explícita y no representan la visión de ningún proveedor.




