A veces tenemos buenas herramientas, reuniones recurrentes, tableros actualizados, indicadores, documentos y canales de comunicación abiertos y aun así aparecen malentendidos, decisiones que no quedan claras, expectativas distintas, tensiones no resueltas o silencios que terminan convirtiéndose en bloqueo.

Por eso me parece tan importante hablar de dos habilidades que suelen aparecer en segundo plano, pero que marcan una diferencia enorme en el día a día: la inteligencia emocional y la comunicación efectiva.

La inteligencia emocional va más allá de la gestión de emociones

Daniel Goleman ayudó a popularizar el concepto de inteligencia emocional aterrizándolo en capacidades como la autoconciencia, la autorregulación, la motivación, la empatía y las habilidades sociales.

Dicho de forma sencilla: no se trata solo de “gestionar emociones”, sino de entender mejor qué nos pasa, cómo reaccionamos, cómo impactamos en otras personas y cómo podemos responder con más conciencia en situaciones de tensión, cambio o incertidumbre.

Porque en el trabajo no colaboramos con roles, organigramas o procesos, colaboramos con personas.

Y las personas interpretamos, nos frustramos, nos ilusionamos, nos defendemos, nos cansamos, nos motivamos, nos bloqueamos o nos sentimos escuchadas. Ignorar esa parte no la hace desaparecer, la deja actuar sin que la gestionemos.

La inteligencia emocional se nota mucho en situaciones muy concretas:

• Cuando recibimos un feedback que nos incomoda y somos capaces de no responder en caliente.
• Cuando una prioridad cambia y evitamos convertir la conversación en una búsqueda de culpables.
• Cuando tenemos que decir que no y explicamos el motivo sin deteriorar la relación.
• Cuando detectamos que detrás de una resistencia puede haber una preocupación legítima.
• Cuando un equipo baja el ritmo y no miramos solo las métricas, sino también las conversaciones, la energía y la confianza. Aspectos que quizá no siempre vemos en un tablero, pero que condicionan profundamente cómo colaboramos y cómo decidimos.

Pero la inteligencia emocional necesita una compañera de viaje que es la comunicación efectiva.

La comunicación efectiva genera confianza

Comunicar bien no es hablar más. Tampoco es escribir correos más largos, convocar más reuniones o llenar un documento de información. Comunicar bien es conseguir que las personas entiendan qué está pasando, por qué importa, qué se ha decidido, qué se espera de ellas y dónde pueden influir. En este sentido, en el artículo sobre 5 tips para que tu proyecto sea un éxito ya hablábamos de la comunicación como uno de los grandes factores de éxito: adaptar el mensaje a cada audiencia, evitar silos, documentar decisiones relevantes y usar la narrativa para que lo importante no solo se diga, sino que se entienda.

Para mí, una comunicación efectiva debería responder siempre a cuatro preguntas básicas:

• ¿Qué queremos decir realmente?
• ¿Qué necesita entender la otra persona?
• ¿Qué decisión, acción o conversación debería ocurrir después?
• ¿Qué puede malinterpretarse si no lo dejamos claro?

Muchas fricciones nacen justo ahí, en lo que damos por supuesto:

• Damos por hecho que alguien ha entendido la prioridad.
• Damos por hecho que el objetivo era evidente.
• Damos por hecho que una decisión estaba cerrada.
• Damos por hecho que el silencio significa acuerdo.
• Damos por hecho que la otra persona tenía la misma información que nosotros.

Y muchas veces no era así. Por eso, algunas prácticas sencillas pueden ayudarnos mucho:

• Escuchar antes de responder
• Preguntar antes de interpretar
• Separar hechos, opiniones y emociones
• Preparar conversaciones importantes, no improvisarlas
• Escribir con frases más claras y menos ambiguas
• Sustituir “esto va mal” por datos, ejemplos y contexto
• Explicar no solo el qué, sino también el para qué
• Cuidar especialmente las conversaciones donde hay desacuerdo, presión o cambios de prioridad

En equipos ágiles esto se ve muy rápido: pedir lo que necesitamos, preguntar lo que no entendemos, escuchar activamente y hacer el mensaje más claro puede evitar muchos bloqueos que después confundimos con problemas de proceso.

Aquí conecta muy bien una idea de la ”comunicación no violenta” de Marshall Rosenberg: observar sin juzgar, expresar lo que sentimos, identificar qué necesitamos y formular peticiones claras. No siempre es fácil, pero puede cambiar por completo la calidad de una conversación. De hecho, cuando en Paradigma Digital trabajamos la matriz de habilidades de nuestra comunidad de metodología y agilidad, la “comunicación no violenta” de la que hablábamos antes, el feedback y el nivel de interlocución aparecían como capacidades clave para acompañar mejor a equipos, clientes y organizaciones.

Una mala conversación puede generar mucho retrabajo. Puede hacer que un equipo avance en direcciones distintas y deteriorar la confianza. Convertir una diferencia legítima en un conflicto personal o hacer que una decisión se ejecute sin un compromiso real, excluyendo información importante solo porque nadie se atrevió a decirla.

Y al revés, una buena conversación puede desbloquear más que una herramienta nueva, ya que puede aclarar expectativas, reducir ruido, hacer visible una tensión antes de que escale, generar confianza y ayudar a tomar mejores decisiones.

Conclusión

La inteligencia emocional nos ayuda a responder mejor a lo que ocurre en las relaciones. La comunicación efectiva nos ayuda a convertir información, decisiones y conversaciones en entendimiento compartido.

Y juntas nos permiten colaborar mejor, especialmente cuando el contexto se complica.

En Rev by Paradigma intentamos cuidar mucho estas capacidades, tanto en la forma en la que acompañamos a equipos y organizaciones como en nuestra propia manera de trabajar. Gestionar mejor nuestras reacciones, escuchar con más intención, comunicar con claridad y generar conversaciones de calidad es clave: forma parte de cómo entendemos en Paradigma la colaboración y el acompañamiento al cambio.

Lo trabajamos y lo entrenamos a través de formaciones internas, comunidades de práctica, espacios de feedback, mentoring, dinámicas de aprendizaje compartido y procesos internos que nos ayudan a seguir desarrollando nuestras capacidades profesionales y relacionales.

Al final, colaborar mejor no depende solo de tener buenas herramientas o buenos procesos. Depende también de cómo pensamos, cómo conversamos, cómo nos escuchamos y cómo somos capaces de sostener relaciones de confianza cuando aparecen la presión, la incertidumbre o el desacuerdo.

Desde la gestión del stock y la cadena de suministro hasta la experiencia de compra, la ciberseguridad o la relación con los clientes, cada vez son más los procesos que dependen de una infraestructura tecnológica sólida.

Pero transformar una compañía de retail implica un reto añadido: innovar sin comprometer la operación diaria de las tiendas. ¿Cómo modernizar los sistemas, incorporar inteligencia artificial y ganar agilidad sin perder de vista la rentabilidad y las necesidades del negocio?

En este episodio de “Apasionados por la tecnología”, entrevistamos a Sebastien Herrbach, Supply & Development Director en Brico Depôt Iberia, y a Miguel Carrasco, Retail & CPG Director en Paradigma Digital.

De departamento de soporte a palanca estratégica del negocio

Durante años, la tecnología en el retail se ha percibido como una función separada del negocio, asociada principalmente a infraestructuras, sistemas y costes. Sin embargo, esta visión ha cambiado radicalmente.

Hoy, prácticamente todos los procesos de una compañía como Brico Depôt tienen una base tecnológica: desde el abastecimiento de productos y la gestión del inventario hasta la compra en tienda física, el comercio electrónico o el marketplace.

La tecnología ya no interviene únicamente para hacer más eficientes los procesos existentes, también participa en la toma de decisiones y en la definición de la estrategia de la compañía.

Un factor importante en esta evolución ha sido la integración de las áreas de Supply Chain y Tecnología bajo una misma dirección. Esta estructura permite conectar mejor las necesidades operativas con las capacidades tecnológicas y evita que los departamentos trabajen como silos independientes.

En este contexto, los datos también han adquirido un papel fundamental. Brico Depôt lleva años trabajando en su Data Lake y esta inversión ha permitido cambiar el tipo de conversaciones dentro de la organización: se ha pasado de dedicar gran parte del tiempo a discutir de dónde proceden los datos y cómo se han medido a utilizarlos como base para tomar decisiones.

La tecnología gana así credibilidad cuando deja de percibirse como una inversión puramente técnica y demuestra su impacto en el negocio.

Ciberseguridad: proteger un negocio cada vez más conectado

A medida que aumenta la digitalización, también lo hace la superficie de exposición a posibles ataques. En una compañía retail, una incidencia tecnológica puede tener consecuencias que van mucho más allá de los sistemas: puede afectar a las tiendas, los pedidos, la disponibilidad de productos o la confianza de los clientes.

Para Brico Depôt, la ciberseguridad es una prioridad creciente. La cuestión ya no es tanto si una organización sufrirá un incidente, sino cuándo puede ocurrir y cuál será su dimensión.

Hay varios aspectos especialmente sensibles:

• La reputación y la confianza del cliente. Un incidente puede afectar directamente a la percepción de la marca y tener consecuencias en el negocio.
• La protección de los datos. Los programas de fidelización, las páginas web y los distintos canales digitales hacen que las compañías gestionen cada vez más información de sus clientes.
• La seguridad de proveedores y aplicaciones. La incorporación de nuevas soluciones requiere auditorías y controles para garantizar que cumplen los requisitos de seguridad.
• La protección de las tiendas físicas. Los dispositivos conectados y las intervenciones técnicas en los establecimientos también pueden convertirse en puntos de entrada.

A todo esto se suma la evolución de las amenazas impulsadas por la inteligencia artificial. Los intentos de suplantación ya no se limitan a correos electrónicos o mensajes fraudulentos: también pueden utilizar voces, vídeos y videollamadas falsas.

Ante este escenario, la seguridad no puede depender únicamente de herramientas técnicas. La formación y la concienciación de los/as empleados/as son fundamentales.

Brico Depôt trabaja con campañas internas de phishing y acciones de sensibilización para que los equipos comprendan que proteger la compañía también forma parte de su responsabilidad diaria.

Inteligencia artificial: innovar con control y propósito

La inteligencia artificial abre nuevas oportunidades para mejorar la eficiencia de las organizaciones, pero incorporarla a una compañía con una operativa tan exigente como el retail requiere hacerlo de forma ordenada.

En Brico Depôt han creado un comité de inteligencia artificial con dos objetivos principales. El primero es identificar oportunidades de mejora en los distintos departamentos, tanto en las oficinas centrales como en las tiendas.

La idea es detectar tareas manuales, procesos administrativos o actividades que requieren mucho trabajo y que podrían agilizarse mediante soluciones de IA.

El segundo objetivo es garantizar que esta adopción se realiza dentro de un marco seguro, respetando la privacidad, la normativa y las necesidades de cumplimiento de la compañía.

En este sentido, la pertenencia al grupo Kingfisher también aporta oportunidades. El grupo ha firmado un acuerdo con Google para desarrollar agentes específicos en un entorno controlado, de manera que las distintas compañías puedan aprovechar las posibilidades de la IA sin perder de vista la seguridad.

Este equilibrio es especialmente importante en un sector donde la innovación debe convivir con una operación que no puede detenerse. La tecnología tiene que ayudar a mejorar el negocio, pero también debe integrarse de forma responsable y sostenible.

De los buscadores tradicionales a la búsqueda con inteligencia artificial

La forma en la que los consumidores descubren productos y buscan información también está cambiando. Hasta ahora, el recorrido habitual pasaba por realizar una búsqueda en Google y llegar desde ahí a la página web de una compañía. Sin embargo, la inteligencia artificial está introduciendo una nueva forma de interactuar con la información.

Un cliente que quiere reformar su cocina, por ejemplo, puede acudir directamente a una herramienta de IA y preguntarle por dónde empezar, qué materiales necesita o qué opciones debería valorar.

Esto supone un cambio importante para las empresas. Ya no basta con ofrecer información sobre las características de un producto; en muchos casos, los clientes necesitan orientación para resolver un proyecto completo.

Preguntar a una IA no es exactamente lo mismo que realizar una búsqueda tradicional. La manera de formular las consultas y el tipo de respuestas que se esperan son diferentes. Por eso, las compañías tendrán que adaptar sus canales digitales para responder a necesidades más complejas y conversacionales.

En Brico Depôt ya están trabajando en esta dirección junto a Google, con iniciativas orientadas a facilitar la interacción con los clientes y acompañarlos en sus proyectos.

El futuro del retail: una experiencia conectada de principio a fin

La transformación tecnológica del retail no consiste simplemente en incorporar nuevas herramientas o digitalizar procesos. Supone conectar la tecnología con las necesidades reales del negocio y construir una experiencia coherente para el cliente, independientemente del canal que utilice.

El uso de datos para tomar decisiones, la flexibilidad que aporta el cloud, la protección de los sistemas y la incorporación responsable de la inteligencia artificial son algunas de las piezas que están definiendo esta evolución.

Pero, como muestra el caso de Brico Depôt, uno de los cambios más relevantes estará en la relación entre el mundo físico y el digital. El cliente quiere informarse y avanzar en sus proyectos desde cualquier lugar, pero sigue valorando el asesoramiento, la confianza y la experiencia que ofrece una tienda.

El desafío para las compañías será conseguir que todos esos puntos de contacto funcionen como una única experiencia, apoyada en una tecnología que aporte valor tanto al negocio como a las personas.

La conclusión es que el problema no está en la app, sino en la capa que hay debajo. Ese "debajo" tiene un lado que el alumno no ve, y es donde profundizamos en este artículo: la trastienda, la sala de máquinas donde el personal de la universidad sostiene, a mano, lo que la fachada digital promete de puertas afuera.

Porque el mismo dato que al alumno le toca escribir varias veces, alguien, dentro de la universidad, también lo teclea de manera repetida. Y esa persona no es el villano de esta historia: es su principal víctima.

Varios sistemas, varias versiones del mismo alumno y ninguna definitiva

La información en la universidad suele vivir fragmentada en silos por sistema. Admisiones tiene la suya en el CRM de captación; secretaría, en el sistema de gestión académica; el cobro, en la plataforma de pagos; la actividad docente, en el campus virtual...

Cada uno manda sobre su parcela y ninguno conoce el estado de los demás. El alumno es una sola persona, pero dentro de la universidad existen varios registros que divergen entre sí, se actualizan a ritmos distintos y nunca se han cruzado contra un identificador común.

No es un problema abstracto de modelo de datos. Es la razón por la que un tutor que quiere entender la situación de un alumno (cómo va, si ha pagado, si pidió una beca, si da señales de abandono…) tiene que abrir varias pantallas y reconstruir a mano una historia que ningún sistema le cuenta entera.

Es la razón por la que, cuando dos departamentos discuten una cifra, la reunión se centra en arbitrar qué sistema es la fuente buena. Y es la razón por la que las decisiones de rectorado se toman, más de lo que se admite, sobre exportaciones parciales a Excel en vez de sobre una vista consolidada.

El personal como middleware humano

Cuando dos sistemas no exponen una interfaz común, hace falta una capa intermedia que traduzca entre ambos: un middleware. En muchas universidades, ese middleware es una persona.

Es quien exporta un listado del sistema de admisiones y lo importa en el de gestión académica. Quien reintroduce a mano los datos del alumno del CRM a la plataforma de pagos porque no hay integración entre ambos.

Quien mantiene la hoja de cálculo paralela (la que el equipo usa de verdad) porque el sistema oficial no da la vista que la operativa necesita.

Cada una de esas tareas es un conector implementado en carne y hueso: existe porque, en algún punto, dos sistemas que deberían intercambiar datos se quedaron mudos y alguien tuvo que sincronizarlos a mano.

Es un trabajo invisible y, sobre todo, un recurso cualificado mal empleado: personas con criterio dedicando sus mejores horas a extraer, cuadrar y volver a cargar datos a golpe de copiar y pegar.

Y conviene decir algo con claridad: esto no se resuelve con más formación. En la mayoría de las universidades el equipo domina sus herramientas; el verdadero freno es la adopción, no el conocimiento.

El límite no es que no sepan usarlas, es que la herramienta les obliga a hacer a mano un proceso que debería estar automatizado. Formar mejor a alguien para una tarea que no debería existir no elimina la tarea.

Por qué el mismo dato acaba escrito varias veces

Merece la pena entender el origen, porque es la consecuencia lógica de cómo se construyó el mapa de sistemas.

Las universidades no compraron su tecnología de golpe ni bajo un plano común. La fueron acumulando por capas y por necesidades: primero el ERP académico, luego el campus virtual, más tarde un CRM de captación, después la sede electrónica para cumplir con la administración electrónica.

Coexisten el sistema de gestión académica, el campus virtual, el CRM, la sede, la web institucional, los entornos de Microsoft o Google, biblioteca y recursos humanos, y ninguno se compró, implantó o se gobierna pensando en los demás.

Cuando toca integrarlos, la vía por defecto es el punto a punto: un puente a medida entre el sistema A y el B, otro entre el B y el C, otro entre el A y el C. Es una vía que no escala.

Con cuatro sistemas los puentes son manejables; con doce se convierten en una maraña que nadie mantiene y que se rompe en cadena cada vez que uno de ellos se actualiza.

Llega un punto en que sale “más barato” absorber la diferencia con una persona que construir y mantener otra integración frágil. Así es como el trabajo manual deja de ser una chapuza puntual y se consolida como la arquitectura de integración de facto.

A esto se añade un límite que ya apuntábamos en el post anterior: buena parte de las plataformas compartidas sobre las que se apoyan las universidades solo permiten incrustar servicios mediante iframes o webviews, sin exponer APIs propias sobre las que integrar de verdad.

Comparten pantalla, pero no comparten los datos. Y encima está la capa de permisos: alumnos, PDI, PAS y externos conviven bajo un mismo modelo de roles que no encaja bien con ninguno, de modo que las excepciones se acaban resolviendo, otra vez, a mano.

El resultado es que el dato del alumno no tiene una única fuente de verdad. Se escribe en admisiones, se replica en secretaría, se vuelve a teclear en pagos. Tres veces el mismo dato son tres oportunidades de introducir una inconsistencia y ninguna forma fiable de saber cuál de las tres versiones es la buena.

La factura que no aparece en ningún presupuesto y que todos pagan

Esta trastienda tiene un coste real, aunque no figure en ninguna partida. Lo más visible es el tiempo, pero debajo hay costes más caros y más silenciosos:

• El error humano, que en un proceso manual y a suficiente volumen no es un riesgo sino una certeza estadística: se propaga por los sistemas que beben de ese dato hasta que alguien lo detecta (o hasta que lo detecta el alumno, que es peor).
• La inconsistencia entre fuentes, que convierte cada dato en objeto de negociación entre áreas.
• Y el más caro: decisiones tomadas sobre información incompleta, porque no hay vista consolidada y cada quien decide con el trozo que le tocó ver.

Hay además una capa normativa que aprieta y que vuelve esto cada vez menos sostenible. La LOSU, el Esquema Nacional de Interoperabilidad, el RGPD y el Reglamento de IA no son recomendaciones: son obligaciones crecientes.

Un dato disperso en varios silos, sincronizado a mano y sin trazabilidad de quién lo modificó, cuándo y con qué base, es un dato difícil de gobernar y casi imposible de auditar.

Y por encima de todo, el coste de oportunidad. Un equipo que gasta su capacidad en mantener sincronizados los sistemas (en hacer de pegamento entre piezas que no encajan) es un equipo que no está trabajando en detectar a tiempo un abandono, en rediseñar un proceso ni en atender lo que de verdad importa.

Cuando el dato se mueve sin que nadie lo empuje

Conviene aterrizar el escenario opuesto, porque no es una utopía: es lo que ya se está construyendo en varias universidades españolas.

Un alumno escribe "necesito el certificado de notas para una beca" y el proceso se resuelve solo: se genera, se firma y se envía, sin abrir un formulario ni pasar por back office.

Un tutor consulta el historial completo de un alumno y recibe una respuesta única y coherente, no varias pantallas que tiene que cruzar de cabeza. El dato del estudiante se captura una sola vez, en el momento del ingreso, y a partir de ahí viaja solo: el alta en admisiones dispara el alta académica, que activa el expediente, que conecta con pagos, sin que nadie vuelva a teclearlo. Cuando algo cambia, cambia en un único sitio y se propaga al resto.

La diferencia no está en tener sistemas "mejores", sino en cómo se conectan. En lugar de la maraña de puentes punto a punto, una capa de orquestación por la que el dato fluye una sola vez y queda disponible, gobernado, para todos los procesos que lo necesiten.

Y sin arrancar lo que ya existe: el sistema académico, el campus virtual y el CRM no se reemplazan, se orquestan sobre una base común que los pone a hablar. Encima de esa capa, lo repetitivo se automatiza y lo que exige criterio queda para las personas.

Cambio de rol en los equipos: de teclear datos a tomar decisiones

Cuando lo mecánico se resuelve en la plataforma, el rol del equipo cambia de naturaleza. El PAS deja de ser el conector humano que introduce datos y pasa a supervisar que el sistema los trata bien; deja de ejecutar el trámite en cadena para ocuparse de la excepción, del caso que no encaja en ningún flujo y necesita criterio.

No es que trabaje más rápido haciendo lo mismo: es que deja de hacer lo que nunca debió ser su trabajo.

Esto importa especialmente ahora que la IA agéntica entra en la conversación, porque la pregunta que angustia a todo el mundo "¿esto sustituye a mi equipo?" tiene aquí una respuesta concreta.

Un agente que automatiza el certificado de notas no sustituye a secretaría: la libera de emitir mil certificados para que atienda a los mil alumnos. El agente puede proponer becar a un estudiante en riesgo, pero la decisión final la confirma una persona, y queda registrado quién decidió qué y por qué.

El rol no desaparece: sube de nivel, de la tramitación a la supervisión y el criterio. Y ese salto solo es posible si por debajo hay una capa que gobierne quién puede hacer qué y deje rastro de cada acción; algo que un mosaico de sistemas sueltos, cada uno con su propia lógica de permisos, no puede ofrecer.

Alumnado, equipo y dirección sufren el mismo problema… sin saberlo

La experiencia rota que sufre el alumno y la carga manual que soporta el equipo no son dos problemas: son el mismo, mirado desde dos ventanas. Los dos nacen de una tecnología que se fue sumando sin un plan común y de una dependencia de plataformas que la universidad no termina de controlar.

El alumno lo vive como fricción; el equipo, como sobrecarga; el rectorado, como decisiones a ciegas y riesgo normativo. Tres síntomas, una sola causa.

Por eso ninguno se arregla por separado, y desde luego no pidiéndole al equipo que corra más ni sumando otra herramienta al mosaico. Se arregla en los cimientos: recuperando el control del dato y de cómo las piezas encajan entre sí.

Al final, lo que está en juego no es el tiempo, es el talento: en qué lo gasta un equipo, si en pelear con sus propios sistemas o en las personas para las que la universidad existe.

Si mañana dirección necesitara saber cuántos alumnos están hoy en riesgo de dejarlo, ¿saldría de un sistema, o habría que pedirle a alguien que cruzara varias hojas de cálculo para averiguarlo?

La respuesta a esa pregunta dice más sobre lo digital que es una universidad que cualquier cosa que se vea en su web.

No digo que esté mal. De hecho, los modelos generativos actuales son perfectamente capaces de resolver muchas de estas tareas y disponen de mecanismos de salida estructurada bastante potentes. Pero hay una pregunta que creo que merece la pena hacerse: ¿tiene sentido utilizar un modelo diseñado para generar lenguaje cuando lo único que necesitamos es tomar una decisión entre opciones conocidas?

Esta es, precisamente, la propuesta de Jev, el primer modelo público de una nueva familia que TypeSafe denomina System One Models. Ya se han escrito otros posts sobre Jev pero en este post, además de contar qué es y por qué me parece interesante desde el punto de vista de arquitectura de software, como suele ser habitual, comparto también un repositorio con una pequeña PoC para que podáis jugar con Jev.

¿Qué es Jev? ¿De dónde nace y quién está detrás?

El 15 de septiembre de 2026, TypeSafe AI presentó Jev, su primer modelo público de la familia System One Models.

La compañía está impulsada por Diogo Almeida, fundador de TypeSafe y antiguo investigador de OpenAI. La idea de partida, explicada en el anuncio de lanzamiento, es bastante sencilla: los modelos generativos han alcanzado un nivel extraordinario para conversar, escribir, programar o razonar, pero buena parte de la automatización empresarial necesita decisiones que puedan consumir otros programas, no textos que tenga que interpretar una persona.
De ahí nace una propuesta diferente: construir modelos especializados en recibir un contexto y responder preguntas bien definidas mediante resultados tipados.

El nombre System One hace referencia al Sistema 1 descrito por Daniel Kahneman en Thinking, Fast and Slow: una forma de pensamiento rápida e intuitiva, frente al Sistema 2, más deliberativo. La referencia sirve para entender la intención de TypeSafe, pero no significa que Jev reproduzca literalmente el funcionamiento de la cognición humana.

¿Y por qué Jev? Según TypeSafe, el nombre es un homenaje a William Stanley Jevons, conocido, entre otras cosas, por la paradoja que lleva su apellido: cuando una tecnología se vuelve más eficiente, su consumo total puede aumentar en lugar de reducirse. Aplicado a la IA, la hipótesis es que abaratar radicalmente cada decisión permitirá introducir inteligencia en muchos más procesos.

Creo que esta última idea es especialmente interesante: quizá no se trate solo de sustituir un LLM por algo más barato, sino de hacer viables decisiones que hoy ni siquiera nos planteamos automatizar.

¿Qué características tiene?

Para entender Jev, hay que cambiar ligeramente la forma de pensar. En lugar de pedirle que “lea este texto y responda con un JSON”, definimos dos elementos:

• state: el contexto sobre el que queremos decidir. Puede contener texto o una estructura de datos.
• questions: las preguntas que debe resolver, con el tipo de respuesta y los criterios definidos previamente.

La aplicación establece el espacio de respuestas posibles; Jev evalúa el contexto y devuelve sus decisiones.

Tres primitivas: Choice, Score y Noul

La interfaz de System One se articula alrededor de tres primitivas:

Podéis revisar el comportamiento y los campos de salida en la documentación oficial de System One. Hay un detalle importante: Noul no es simplemente un booleano, sino una señal numérica que podemos interpretar mediante un umbral definido por nuestra aplicación. Igualmente, un Score puede ser continuo, aunque los criterios estén organizados por niveles.

Varias decisiones en una sola llamada

Otra característica especialmente útil es la posibilidad de plantear varias preguntas sobre el mismo contexto. Imaginemos que recibimos esta alerta:

El servicio de pagos está caído para todos los clientes. Los logs muestran agotamiento del pool de conexiones de base de datos y no existen indicios de acceso no autorizado.

Podríamos solicitar, en una única petición, la prioridad (Score de 0 a 4), el riesgo de seguridad (Noul) y el equipo responsable (Choice entre BACKEND, PLATFORM y SECURITY). El resultado sería algo parecido a esto (ejemplo conceptual, no una respuesta real de la API):

{
  "priority": 4,
  "security_risk": 0.03,
  "team": "BACKEND"
}

Es decir, no necesitamos tres llamadas ni un texto explicativo para disponer de las tres decisiones. El código que consume el resultado puede determinar qué hacer después.

Respuestas tipadas, incertidumbre y eficiencia

TypeSafe pone el foco en otras tres características:

• Contrato de salida conocido: las preguntas y sus valores válidos están delimitados de antemano. Esto reduce los problemas de integración derivados de recibir respuestas que no respeten el contrato.
• Señales de incertidumbre: dependiendo de la primitiva, el modelo ofrece valores probabilísticos, distribuciones o confianza. No son garantías de acierto y deben validarse con datos reales.
• Optimización para decisiones: Jev no redacta una explicación palabra a palabra. Según sus creadores, esta diferencia permite reducir sustancialmente costes y tiempos de respuesta en las tareas para las que está diseñado.

En su presentación oficial, TypeSafe comunicó latencias orientativas de 70 a 500 ms y una tarifa pública de 0,042 USD por millón de tokens de entrada, sin coste de tokens de salida. Son cifras publicadas por el proveedor, no una promesa de rendimiento en cualquier entorno ni una tarifa contractual garantizada. Conviene comprobar las condiciones vigentes antes de presupuestar.

Un último matiz: garantizar que una respuesta respete el esquema no significa garantizar que la decisión sea correcta. Un clasificador puede devolver perfectamente BILLING cuando la categoría que esperábamos era OTHER.

¿Por qué es diferente de un LLM tradicional?

Un LLM generativo está diseñado para producir contenido. Jev está diseñado para emitir decisiones acotadas que otro software pueda utilizar directamente.

Esto no quiere decir que Claude, GPT o Gemini no puedan devolver resultados estructurados. Pueden hacerlo mediante herramientas, function calling o esquemas de salida. La diferencia es el objetivo nativo del modelo y su interfaz de interacción, no la imposibilidad de obtener JSON de un LLM.

Usando un LLM, el espacio de respuesta está potencialmente abierto, aunque como indico, se pueda intentar restringir. En Jev, el espacio de respuesta está ya definido por las propias preguntas. Además, un punto que tenemos que tener en cuenta es que Jev no te va a generar una explicación del razonamiento. Un LLM sí te puede decir qué le ha llevado a esa respuesta e incluso referencias a las citas asociadas.

La idea principal que tenemos que tener en mente es que Jev no tiene por qué competir frontalmente o sustituir a los LLM sino que en una arquitectura real pueden ser perfectamente complementarios.

Por ejemplo, un LLM puede diseñar una solución, redactar una respuesta o sintetizar un documento mientras que Jev puede decidir qué flujo ejecutar, qué categoría corresponde o si conviene derivar una operación a revisión humana.

Esto recuerda un principio de arquitectura bastante clásico: utilizar cada componente para aquello que hace mejor, evitando añadir capacidades que el problema no necesita. Ojo: siempre que podamos utilizar mecanismos deterministas siempre deberíamos optar por utilizarlos. Más sencillos de implementar, depurar, probar y desplegar.

¿Para qué casos de uso puede ser una buena opción respecto a un LLM?

Creo que donde de verdad tiene potencial es en los escenarios que cumplen condiciones como estas:

• Disponen de muchos eventos o entradas
• Necesitan tomar decisiones repetibles
• Tienen un espacio de respuesta conocido
• Se busca reducir coste o latencia.

Dentro de estos condicionantes encontramos casos como:

• Clasificación y routing: por ejemplo, determinar si un correo corresponde a facturación, soporte o ventas; enviar tickets al equipo correcto; clasificar solicitudes; o decidir qué modelo generativo usar para cada tarea.
• Scoring y priorización: por ejemplo, valorar la madurez de oportunidades comerciales, ordenar incidencias según impacto y urgencia, o identificar solicitudes que merecen revisión prioritaria.
• Guardrails semánticos: por ejemplo, detectar si una instrucción parece intentar saltarse una aprobación o incumplir una regla expresada en lenguaje natural. La detección sería una señal adicional; no reemplaza los controles deterministas de seguridad.
• Verificación de contenido y flujos de agentes: por ejemplo, evaluar si una respuesta cumple determinados criterios o si debe escalarse a un humano; introducir puntos de decisión acotados en flujos más amplios.
• Decisiones múltiples sobre un mismo evento: por ejemplo, ante una incidencia, determinar a la vez prioridad, riesgo de seguridad y equipo responsable.

Desde mi punto de vista de arquitecto, para mí no deja de ser un componente/servicio de decisión semántica que convive con reglas de negocio, APIs, eventos y modelos generativos, que es necesario en escenarios en los que un if/else convencional se queda corto, pero un LLM completo parece excesivo.

Eso sí, no sustituye a las reglas deterministas cuando podemos expresar y verificar completamente la decisión mediante código.

¿Cuándo puede no ser una buena opción?

A veces, al analizar una tecnología nueva, nos centramos tanto en sus ventajas que dejamos de mirar el otro lado. En este caso creo que conviene ser especialmente cuidadosos. Por ejemplo:

• Generación de contenido
• Requisitos de explicabilidad
• Soberanía y control

Veamos estos escenarios con más detalle.

Generación de contenido

Tenemos que tener claro que Jev no es un modelo generativo. Por lo tanto, si necesitamos redactar un informe, desarrollar una arquitectura, explicar alternativas técnicas, programar, resumir un documento o mantener una conversación, Jev no es el modelo adecuado para producir ese artefacto.

Podría participar en decisiones del flujo, pero la generación seguiría correspondiendo a un LLM u otro sistema especializado.

La explicabilidad es un must

Jev no proporciona una explicación de por qué ha elegido una categoría o ha asignado una puntuación. Podemos obtener señales asociadas a la decisión, pero no una descripción verificable de su razonamiento interno.

Pensemos en un correo que Jev clasifica como BILLING cuando un analista lo consideraría OTHER. Podemos saber qué devolvió y compararlo con la etiqueta esperada. Lo que no podemos pedirle es que nos detalle cuáles fueron sus razones internas para escoger esa opción.

La explicabilidad asociada a la IA es un requisito de mucha importancia en determinados contextos por lo que es un punto a tener muy en cuenta.

Una alternativa: Jev decide y un LLM explica

Podemos plantear una arquitectura híbrida:

1. Jev toma la decisión sobre el contexto disponible.
2. La aplicación devuelve esa decisión al consumidor.
3. Se publica un evento o se encola una tarea, identificada con el ID de la decisión.
4. Un modelo generativo económico, como Claude Haiku, recibe el contexto, la decisión y las señales disponibles y elabora una justificación basada en las evidencias del texto.
5. La explicación se almacena asociada a la decisión para consulta posterior.

Este modelo híbrido solo es aplicable si la explicación no es necesaria para continuar ya que podemos generarla de manera asíncrona y mantener fuera del camino crítico la latencia del segundo modelo. En este caso, no eliminamos la latencia de la explicación, la desacoplamos de la latencia de la decisión. Además, por otro lado, incorporamos un coste adicional, una dependencia y la necesidad de gestionar colas, reintentos y errores.

Ojo, existe una limitación todavía más importante: la justificación que redacte el LLM (ej: Haiku) sería una explicación posterior (post-hoc) no el razonamiento interno de Jev. Puede resultar útil para interpretar las evidencias y facilitar la revisión, pero también podría construir un argumento que no sea fiel al motivo real de la predicción.

Por eso, en procesos regulados o críticos que exijan una explicación validada antes de actuar, no podemos simplemente moverla a segundo plano y dar el requisito por resuelto.

Cuando necesitamos control absoluto del despliegue o soberanía del dato

Como he comentado anteriormente, en el momento en que estoy escribiendo el artículo, si necesitamos ejecutar el modelo sin conectividad externa, dentro de nuestra infraestructura o en una ubicación contractual concreta que TypeSafe no pueda ofrecer, Jev puede no cumplir los requisitos, independientemente de lo bien que clasifique.

Hablemos de la madurez, ¿es usable en producción?

Jev es un producto muy reciente: su presentación pública se produjo en septiembre de 2026. Obviamente, no estamos hablando de una tecnología con años de adopción generalizada, sino de una propuesta que está evolucionando rápidamente.

Eso no significa que no pueda utilizarse en producción. TypeSafe ya ha publicado el caso de Jack & Jill, una plataforma de empleo que, según su propio testimonio, sustituyó un modelo Gemini por Jev en una etapa de matching de candidatos. El caso reporta un 88 % menos de coste y una reducción del tiempo de procesamiento manteniendo una calidad comparable en esa tarea. Es un caso de cliente publicado por el proveedor: interesante como referencia, pero no equivale a una certificación independiente ni implica que esos ahorros sean extrapolables a otros sistemas.

TypeSafe continúa publicando versiones y funcionalidades. Por ejemplo, en el anuncio de Jev 1.14 diferencia las capacidades que considera suficientemente probadas de otras experimentales, como determinadas opciones multimodales o de contexto extendido.

Pero, ¿tiene soporte empresarial?

Aquí hay un matiz que creo que merece un apartado propio, especialmente si estamos pensando en introducir Jev en una empresa grande y/o muy tradicional.

No podemos decir que TypeSafe no tenga soporte empresarial ya que dispone de una página específica para empresas con contacto comercial, capacidad para solicitar mayores límites de consumo y referencias a opciones como la retención cero de datos. Sin embargo, disponer de un canal comercial no equivale a tener confirmadas todas las garantías empresariales que exigiríamos antes de una adopción crítica:

• SLA contractual
• Soporte 24×7
• Tiempos de respuesta ante incidentes
• Despliegue privado
• Cumplimiento específico
• Portabilidad
• Compromisos de continuidad

Sí que es cierto que Typesafe se está moviendo en este ámbito. En el anuncio de su ronda de financiación del 9 de octubre de 2026, TypeSafe señala expresamente que añadirá más funcionalidades empresariales. Es una señal positiva de inversión y dirección de producto, pero también indica que la oferta continúa evolucionando y que saben que falta cierta madurez para un producto empresarial.

En mi opinión, en este momento, en un contexto empresarial, iría por utilizar Jev sin demasiadas reservas en una PoC controlada, pero condicionar el paso a producción crítica a una revisión comercial, legal, de seguridad y de operación. No basta con que el modelo sea rápido y acierte nuestro dataset.

Si falla el servicio un sábado por la noche, ¿a quién llamamos?, ¿qué tiempo de recuperación nos garantizan?, ¿qué hacemos si cambian las condiciones de la API?, ¿qué datos pueden tratar y en qué región? Esas respuestas deben estar por escrito, no inferirse de una página de marketing.

Mi lectura es que Jev merece ser evaluado para producción en casos acotados, pero exige especial atención a su madurez operativa y a las garantías contractuales. Antes de adoptarlo para una función crítica, revisaría al menos:

• Calidad sobre nuestro dominio: dataset representativo, etiquetas revisadas y pruebas con entradas ambiguas y fuera de distribución.
• Versionado: fijar versiones cuando la estabilidad sea necesaria y repetir evaluaciones antes de migrar.
• Comportamiento ante fallos: timeouts, límites de consumo, circuit breakers y fallbacks.
• Seguridad y privacidad: clasificación de los datos enviados, residencia, retención y acuerdos de tratamiento.
• Observabilidad: tiempos, costes, errores técnicos, errores de decisión y evolución temporal.
• Control de negocio: umbrales, aprobaciones humanas y reglas deterministas antes de acciones de riesgo.
• Garantías del proveedor: SLA, soporte, límites y continuidad del servicio.

Conviene recordar que una decisión probabilística no debe convertirse automáticamente en una autorización. Si Jev indica que una acción parece segura, nuestro sistema sigue siendo responsable de comprobar permisos, políticas y restricciones.

Otro punto importante: ¿está disponible como modelo nativo en los grandes proveedores?

En el momento en que estoy escribiendo este artículo, no he encontrado documentación oficial que confirme Jev como modelo seleccionable y administrado de forma nativa en Amazon, Google, Azure… Por tanto, no lo presentaría como una capacidad disponible en esas plataformas.

Si una organización quiere utilizarlo desde alguna de esas nubes, el escenario respaldado por la documentación pública es el consumo de la API de TypeSafe desde la aplicación. Cualquier acuerdo específico de despliegue privado o distribución mediante terceros debe confirmarse con el proveedor.

¿Se puede ejecutar localmente?

Tampoco he encontrado que se pueda ejecutar localmente. Esta limitación importa en organizaciones con requisitos estrictos de aislamiento, soberanía del dato o despliegue completamente on-premise.

En resumen: podemos desarrollar y desplegar nuestro software donde queramos, pero la inferencia de Jev, según la oferta pública documentada, depende del servicio de TypeSafe.

¿Y si realmente no necesitáramos Jev?

La clasificación de texto, el scoring y la detección de anomalías existían mucho antes de ChatGPT. Por tanto, dependiendo del contexto, es posible que no necesitemos ni Jev ni un LLM. Pensemos en el caso de clasificar correos. Una alternativa clásica sería entrenar un modelo supervisado a partir de mensajes etiquetados. Podemos empezar con TF-IDF y regresión logística, pasar a un SVM, combinar embeddings con un clasificador o ajustar un modelo encoder como ModernBERT. No todos requieren la misma cantidad de datos, hardware o esfuerzo de operación.

Otra posibilidad es utilizar soluciones gestionadas: Amazon Comprehend Custom Classification permite entrenar clasificadores con categorías propias y Google Cloud Document AI Custom Classifier ofrece opciones de clasificación documental, desde modelos preentrenados hasta entrenamiento personalizado. En abierto, enfoques como SetFit permiten ajustar clasificadores con relativamente pocos ejemplos y modelos de embeddings.

La comparación, por tanto, no debería limitarse a Jev frente a un LLM:

No hay un ganador universal. Si disponemos de millones de correos históricos bien etiquetados y las clases apenas cambian, un clasificador especializado desplegado en nuestra infraestructura podría ser una opción excelente. Si, por el contrario, estamos explorando un proceso nuevo, tenemos pocas etiquetas y necesitamos cambiar los criterios con frecuencia, Jev puede reducir muchísimo la fricción inicial.

Tampoco sería correcto afirmar que el ML tradicional es necesariamente más lento de desarrollar o más caro de operar en todos los escenarios. Hay herramientas AutoML, modelos preentrenados y enfoques few-shot que han reducido mucho esa barrera. Y hay modelos supervisados que permiten inspeccionar qué variables han influido en una predicción, aunque eso tampoco garantiza por sí solo una explicación causal.

Como decía antes, tenemos que recordar siempre el principio de arquitectura de utilizar cada componente para aquello que hace mejor. En esta época de gran cambio y de gran velocidad en el cambio, el trabajo de arquitectura a la hora de diseñar soluciones es más importante que nunca: ¿qué necesitamos realmente? ¿un clasificador tradicional entrenado con nuestros datos, un LLM con salida estructurada o una API de decisiones como Jev o Decisions API?

La respuesta dependerá de calidad, coste, latencia, explicabilidad, privacidad, madurez y posibilidades de despliegue.

¿Hay reacciones en el sector?

La industria está avanzando hacia resultados cada vez más estructurados, modelos más pequeños y servicios especializados, aunque no todos siguen el mismo camino.

Laya, el competidor open source

Otro proyecto que merece la pena conocer es Laya, impulsado por Convai Innovations. Su planteamiento es muy similar al de Jev: tomar decisiones semánticas sobre un contexto mediante preguntas acotadas, en lugar de generar texto libre. De hecho, utiliza las mismas primitivas: Choice, Score y Noul, y puede resolver varias preguntas en una sola evaluación.

La diferencia más interesante está en el modelo de distribución. Laya es un proyecto open source, con código y pesos disponibles públicamente y una licencia Apache 2.0 declarada en su repositorio. Esto permite descargar el modelo y ejecutarlo localmente, dentro de un contenedor Docker o en infraestructura propia, en lugar de depender necesariamente de un servicio de inferencia externo.

Desde el punto de vista empresarial, de control y soberanía, esto puede ser bastante relevante ya que podemos controlar dónde se procesan los datos, qué versión ejecutamos y cómo integramos el modelo. Imaginemos una aseguradora que necesita clasificar documentación o priorizar incidencias y no puede enviar determinados datos a una API de terceros. Laya abre la posibilidad de desplegar ese componente dentro de sus propios límites de red.

Pero esto no es “gratis” ya que open source no equivale a una solución lista para producción empresarial. Como cualquier otro despliegue, hay que tener en cuenta que hay que proporcionar y analizar los costes asociados a la infraestructura, energía, personal…, hay que gestionar la capacidad, escalado, monitorización…, hay que mantener el modelo y las nuevas versiones que se generen del mismo, la responsabilidad operativa y el soporte cae del lado de la propia empresa y, al ser un proyecto Open Source, no tenemos soporte empresarial y tampoco tenemos la garantía de que vaya a ser mantenido en el tiempo (ojo, puede ser interesante que participemos como contribuidores).

Tampoco debemos olvidar la calidad de las decisiones. Necesitaríamos contrastar sus resultados con nuestro propio dataset, incluyendo textos ambiguos, distintos idiomas, distribuciones de categorías y casos donde conviene escalar a revisión humana. La precisión, la calibración y el comportamiento ante errores importan más que el hecho de ser abierto o propietario.

En mi opinión, Laya tiene mucho sentido como candidato para PoCs y para escenarios donde la ejecución local sea un requisito, pero para producción crítica exigiría el mismo rigor que a Jev: pruebas representativas, garantías de continuidad, controles de seguridad y un modelo de soporte claro.

OpenAI Decisions API y GPT-6 Luna

Según el registro oficial de cambios de OpenAI, el 6 de octubre de 2026 se lanzó en beta la Decisions API con el modelo gpt-6-luna. Decisions API es una interfaz específica para evaluar entradas y devolver decisiones tipadas, con preguntas acotadas. Su planteamiento se parece bastante más al de System One de TypeSafe.

La correspondencia entre conceptos resulta llamativa y la forma de invocación es similar a la de System One: hay que indicar el modelo, las entradas y las preguntas/instrucciones. Las dos propuestas permiten trabajar con decisiones acotadas y múltiples preguntas sobre un contexto. La documentación de OpenAI describe además decisiones sobre texto e imágenes y señales de probabilidad o confianza en determinados tipos de respuesta.

OpenAI afirma que esta API puede ser aproximadamente diez veces más rápida que utilizar su Responses API para este tipo de tareas. Hay que interpretar bien esa cifra: es una comparación publicada por OpenAI frente a otra API propia, no una medición independiente contra Jev. Tampoco podemos concluir de ella que Luna sea más preciso, más rápido o más barato que Jev en nuestro escenario concreto.

Manos a la obra: Jev Decision Lab

Como es habitual en mis publicaciones, intento no dejar un post en algo meramente teórico y siempre procuro acompañarlo de algo “práctico”.

En este caso, he preparado este repositorio Jev Decision Lab. Consiste en una PoC que compara a Jev con Claude Haiku y Claude Sonnet sobre un conjunto de situaciones donde podemos medir resultados. Además, he incluído Laya para que lo puedas ejecutar en local.

No pretende ser un benchmark universal ni demostrar que Jev gana siempre. Su objetivo es poder jugar con ello y ver cuándo una decisión acotada puede resolverse sin recurrir a un modelo generativo generalista, y qué sucede con la calidad, el coste y el tiempo de respuesta.

Para que la PoC sea más guiada y sencilla de usar, he incluído una serie de casos de uso en los que la comparación tiene sentido:

Por otro lado, en la PoC hay dos modos de uso:

• Playground, donde podemos introducir nuestro propio texto, seleccionar proveedores y comparar una ejecución individual.
• Test Scenarios, donde podemos ejecutar baterías repetidas sobre un dataset de referencias. La versión del proyecto que utilizo incluye 30 escenarios por caso de uso (210 en total), permite seleccionar proveedores, repetir las pruebas y subir un dataset JSON propio, que se valida antes de iniciar el proceso.

En el repositorio está el README con las instrucciones completas, la descripción de los casos y los detalles de implementación.

Importante: las etiquetas del dataset son ejemplos preparados para la PoC, no un conjunto revisado de forma independiente. Un 95 % de coincidencia con estas etiquetas no equivale a "95 % de precisión en producción". Los costes son estimaciones, y el rendimiento depende también de la red y de los servicios externos.

Conclusiones

Después de revisar la propuesta de TypeSafe y desarrollar la PoC, me quedo con varias ideas.

• No siempre se requiere generación: como suele pasar cuando hay hype, hemos normalizado utilizar LLM para cualquier entrada de lenguaje natural, pero hay problemas cuyo resultado es simplemente una decisión entre opciones conocidas. Merece la pena distinguir ambos escenarios.
• Latencia y coste son ventajas potenciales pero hay que revisar por completo el escenario: los datos publicados por TypeSafe llaman la atención y justifican probarlo pero, la decisión de arquitectura tiene que estar basada en los requisitos del escenario, del propio dataset de información que manejemos, de las latencias y nuestros criterios de calidad requeridos .
• La explicabilidad es un punto clave en la decisión: podemos pedir a otro modelo que elabore una justificación, incluso de forma asíncrona, pero eso no convierte la explicación en el razonamiento verificable de Jev. En determinados contextos, esta diferencia marca el “go” o “no go” a Jev.
• La madurez, el soporte y el modelo de despliegue (y la soberanía) cuentan en un entorno empresarial: es cierto que hay casos reales en producción ya con Jev pero es una herramienta reciente que depende de la oferta de TypeSafe. Para organizaciones con requisitos estrictos de soberanía, operación o continuidad, el análisis no termina en la precisión del modelo o de las características indicadas por el fabricante en su web sino que también es necesario disponer de características de uso empresarial sólidas.
• No olvidemos otras alternativas como ML tradicional: un buen clasificador supervisado, o incluso reglas convencionales, puede ser la solución más razonable. Antes de introducir otra API deberíamos medir también esas opciones.

Por tanto, en lugar de que la primera pregunta que nos hacemos al diseñar una solución sea: “¿qué LLM utilizamos para resolver este problema?”, deberíamos empezar preguntando “¿qué tipo de inteligencia necesita realmente este problema?”. Si necesitamos generar, explicar o diseñar, un LLM tiene mucho sentido. Si necesitamos clasificar, priorizar o decidir dentro de límites definidos, propuestas como Jev abren una alternativa que merece ser explorada. Si el conjunto es predecible y está muy bien definido, vayamos a soluciones deterministas.

Pero, en un entorno en el que las herramientas evolucionan a gran velocidad, ¿qué papel deben desempeñar las personas? ¿Qué habilidades necesitarán los profesionales del futuro?

En este episodio de “Apasionados por la tecnología”, hablamos con Jose María Visconti, vicedecano de ESIC Business & Marketing School, sobre la transformación del marketing, la evolución del talento y los retos que plantea la inteligencia artificial en las empresas y en la formación.

El marketing como motor estratégico del negocio

Durante mucho tiempo, el marketing se ha entendido como un complemento de las ventas. Sin embargo, su papel ha evolucionado hasta convertirse en una función estratégica que ayuda a definir el rumbo de las compañías.

Una de sus principales aportaciones está en la construcción de activos intangibles, como la marca. Aunque su retorno sea más difícil de medir que el de otros recursos, una marca sólida puede generar ventajas competitivas y mejorar la rentabilidad a largo plazo.

Esta visión exige superar la perspectiva cortoplacista. Recortar la inversión en marketing puede parecer una decisión inocua cuando se busca reducir costes, pero sus consecuencias pueden aparecer con el tiempo. Construir una marca requiere continuidad y una estrategia conectada con los objetivos del negocio.

Además, la tecnología ha estrechado la relación entre marketing y los departamentos tecnológicos. Los/as responsables de marketing necesitan cada vez más herramientas para analizar datos, conocer al cliente y tomar decisiones con precisión.

Por eso, el perfil del CMO evoluciona hacia un rol en el que la tecnología y la estrategia empresarial tienen un peso creciente.

Inteligencia artificial: automatizar tareas para potenciar el talento

La IA está transformando la manera de trabajar, especialmente en sectores como las agencias y las consultoras, donde los equipos deben adaptarse con rapidez a las necesidades de cada cliente.

Esta transformación no implica necesariamente reducir las plantillas, sino reorganizar los equipos para aprovechar mejor la combinación de talento humano y tecnología.

La IA tiene un espacio natural en tareas repetitivas, cálculos, análisis elementales, extracción de información y tratamiento de datos en formatos definidos. Son actividades en las que la automatización puede ahorrar tiempo y aportar precisión.

El valor diferencial de las personas, en cambio, seguirá estando en la estrategia, la creatividad y la exploración de nuevas posibilidades. La imaginación, la curiosidad y la capacidad de cuestionar lo establecido son cualidades que permiten abrir caminos que todavía no existen.

El reto no consiste, por tanto, en utilizar la IA para hacer más de lo mismo, sino en liberar tiempo y capacidad para pensar de otra manera, identificar oportunidades y redefinir qué significa aportar valor.

Formarse para trabajar con IA, no solo para utilizarla

La inteligencia artificial también está obligando a revisar los modelos educativos. Si una herramienta puede realizar en minutos tareas que antes requerían un gran esfuerzo, ¿cómo se evalúa lo que realmente ha aprendido un alumno?

En el ámbito de la formación, la cuestión ya no es si se utiliza la IA, sino cómo y para qué. Tanto profesorado como estudiantes recurren a estas herramientas, por lo que resulta necesario establecer criterios claros sobre su uso.

Uno de los desafíos es diseñar evaluaciones que permitan comprobar que el alumnado ha adquirido las competencias necesarias, sin que la IA oculte sus carencias.

En lugar de valorar únicamente el resultado final (por ejemplo, un plan de marketing), puede ser más relevante analizar el proceso: cómo se han formulado las instrucciones, qué herramientas se han utilizado y cómo se han revisado y validado sus respuestas.

Este cambio requiere marcos de referencia que definan cuándo tiene sentido apoyarse intensivamente en la IA y cuándo es importante que el estudiante demuestre sus capacidades sin esa ayuda.

También refuerza la importancia de las habilidades que a veces se han denominado soft skills: saber comunicar, hacer buenas preguntas, persuadir, liderar y comprender los límites éticos de la tecnología.

En un contexto en el que obtener una respuesta es cada vez más sencillo, saber qué preguntar y cómo interpretar el resultado gana relevancia.

La autenticidad como ventaja competitiva en un mundo generado por IA

Las herramientas de inteligencia artificial permiten producir más contenido y hacerlo con mayor rapidez. Pero esta abundancia plantea un nuevo problema para las marcas: si todas utilizan las mismas tecnologías de formas similares, sus mensajes pueden acabar pareciéndose demasiado.

Captar la atención exige autenticidad y diferenciación. La IA puede ayudar a las empresas a generar contenidos y mejorar procesos, pero no debería borrar aquello que las hace reconocibles.

La clave está en encontrar el equilibrio entre lo que aporta la tecnología y lo que hace única a cada compañía: su identidad, sus valores, su manera de relacionarse con las personas y la coherencia entre lo que comunica y lo que hace.

La gestión de los datos también forma parte de este reto. La personalización necesita información, pero el uso de esos datos plantea preguntas sobre privacidad y consentimiento.

En definitiva, disponer de más tecnología y más información no garantiza una mejor experiencia de cliente. La diferencia estará en cómo las marcas utilizan esos recursos para construir relaciones relevantes y auténticas.

¿Qué tecnologías marcarán los próximos años?

La inteligencia artificial seguirá extendiéndose, aunque no debemos dar por hecho que su coste y sus condiciones actuales se mantendrán en el futuro. Las empresas deben tener en cuenta que las decisiones basadas únicamente en el bajo coste de las herramientas podrían cambiar de sentido si su uso se encarece.

Junto a la IA, anticipa oportunidades en ámbitos como la realidad aumentada y virtual, la robótica, la automatización y la computación cuántica. Tecnologías que hoy tienen aplicaciones limitadas podrían adquirir mayor relevancia a medida que evolucionen las capacidades de procesamiento y se desarrollen nuevos casos de uso.

Aunque el alcance y el ritmo de estos cambios todavía están por ver, la idea central es clara: las organizaciones necesitan prepararse para un escenario en evolución constante, sin perder de vista el propósito de la tecnología.

En este episodio nos adentramos en la caja negra de la IA para recuperar cuatro casos que muestran sus limitaciones: desde un chatbot que parecía comprender las emociones humanas hasta algoritmos capaces de amplificar el caos financiero o reproducir prejuicios sociales.

1 ELIZA, el chatbot que parecía entendernos (pero no)

En 1966, el investigador del MIT Joseph Weizenbaum creó ELIZA, uno de los primeros programas capaces de mantener conversaciones. Su truco era sencillo: reformulaba las frases de los usuarios y respondía con preguntas, sin comprender realmente lo que le contaban.

A pesar de sus limitaciones, algunas personas llegaron a confiar en él y a compartir sus problemas personales. Así nació el llamado efecto ELIZA: nuestra tendencia a atribuir inteligencia y empatía a una máquina solo porque responde de forma convincente.

La lección sigue vigente: que una IA parezca entendernos no significa que realmente lo haga.

2 Un algoritmo médico que interpretó el asma como una falsa ventaja

Un sistema de IA, diseñado para predecir el riesgo de mortalidad de pacientes con neumonía, detectó que quienes también padecían asma presentaban mejores resultados. El problema es que interpretó esa correlación como si el asma fuera un factor protector, sin tener en cuenta que estos pacientes podían recibir una atención médica más intensiva.

El algoritmo identificó un patrón en los datos, pero no comprendió el contexto que lo explicaba. Este caso demuestra que una correlación no implica causalidad y que, especialmente en medicina, las recomendaciones de una IA deben evaluarse cuidadosamente antes de aplicarse.

3 Flash Crash: los algoritmos que amplificaron el pánico financiero en EE. UU.

El 6 de mayo de 2010, los mercados financieros estadounidenses sufrieron una caída repentina y extrema. La interacción entre grandes órdenes de venta y sistemas automatizados de negociación contribuyó a intensificar el desplome, mientras los precios fluctuaban a una velocidad difícil de gestionar para los operadores humanos.

El episodio, conocido como Flash Crash, puso de manifiesto que la automatización puede amplificar movimientos inesperados cuando varios sistemas interactúan sin controles suficientes. La velocidad es una ventaja, pero también puede multiplicar las consecuencias de un error.

4 COMPAS, el algoritmo judicial que heredó nuestros prejuicios

En Estados Unidos, el sistema COMPAS se ha utilizado para evaluar el riesgo de reincidencia de personas acusadas de delitos y ayudar en determinadas decisiones judiciales.

En 2016, una investigación de ProPublica detectó diferencias raciales relevantes en sus errores de predicción: las personas negras tenían más probabilidades de ser clasificadas incorrectamente como de alto riesgo.

El caso abrió un debate sobre los sesgos de los algoritmos y la supuesta neutralidad de las matemáticas. Si una IA aprende de datos históricos que reflejan desigualdades, puede reproducirlas y darles una apariencia de objetividad.

¿Qué nos enseñan estos errores?

Aunque pertenecen a ámbitos muy diferentes, los cuatro casos comparten una misma advertencia: la inteligencia artificial no es infalible ni necesariamente objetiva.

Los algoritmos pueden confundir correlaciones con causas, aprender de datos sesgados o desencadenar consecuencias imprevistas. Por eso, desarrollar soluciones de IA no consiste únicamente en conseguir que funcionen, sino también en comprender sus limitaciones, evaluar sus resultados y establecer mecanismos de supervisión.

No existe una estrategia de chunking universalmente ganadora. El rendimiento varía significativamente según el dominio, la estructura del texto y el modelo de embeddings que usemos. Por tanto, optimizar esta etapa no es una tarea trivial de configuración inicial, sino un proceso activo de auditoría.

El mayor riesgo reside en el "truncamiento ciego", un fenómeno silencioso donde los fragmentos exceden la ventana del modelo y son recortados durante la vectorización, degradando la búsqueda sin generar errores. Auditar este comportamiento y medir la relevancia de las respuestas con consultas reales es indispensable.

Este proceso es una inversión necesaria de tiempo y análisis que permite asegurar que el sistema no esté limitando su potencial desde la propia fase de indexación.

¿El problema? Nunca has medido el splitter

Seguramente hayas visto esta línea de código o una que se le parece mucho. Está en el repositorio de casi todos los RAG que llevan un tiempo en producción:

splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)

Esa línea determina cómo se fragmenta cada documento antes de su indexación y establece el tamaño de los segmentos. Es una configuración crucial: un sistema RAG no recupera documentos completos, sino fragmentos y, por lo tanto, la calidad de las respuestas depende directamente de cómo realice ese recorte.

Estos mil caracteres y los doscientos de solape de ejemplo suelen ser herencia del tutorial que consultaste al iniciar el proyecto (¡y lo sabes!). Aunque te pueda sorprender, no voy a criticar el uso de esa configuración por defecto.

Un troceado recursivo bien parametrizado es difícil de superar, algo que respaldan incluso fuentes que podrían beneficiarse de afirmar lo contrario, como demostraré a continuación con datos objetivos.

El enemigo del chunking es otro, y es bastante más incómodo: haber elegido esa configuración una vez y no haberla medido nunca.

Una de las decisiones con mayor impacto en la calidad de respuesta del sistema se toma habitualmente por defecto, replicando configuraciones externas sin evaluación previa. Su manifestación más frecuente es reaccionar sintomáticamente ante fallos en la recuperación sustituyendo el splitter por un algoritmo más complejo, omitiendo una validación cuantitativa previa de su impacto real.

Mi postura es que el chunking no es una decisión de arquitectura que se toma el primer día, es un parámetro que se mide sobre los documentos propios.

Por eso este artículo no va a dar un chunk_size recomendado, va a dar la forma de medir el tuyo. El fallo no es ni de estrategia ni de método, el fallo es de medición.

¡Ah! y si piensas que el RAG ha muerto, pásate por otra publicación en donde discutimos sobre ello.

La ventana fija, una estrategia sorprendentemente robusta

El troceado recursivo con una ventana y solapamiento fijo nos puede parecer una estrategia muy básica, de principiantes, pero es un método que funciona. En 2024 Chroma publicó una evaluación de estrategias de chunking sobre cinco colecciones de texto (Smith y Troynikov, 2024). Curiosamente, el resultado que más se cita de ese informe es justo el que peor le venía a ellos.

El método de chunking recursivo a 200 tokens obtuvo un 88,1 % de recall. Sorprendentemente, el chunker semántico de la propia Chroma se queda en 87,3%.

Destaquemos un aspecto: quien hizo este estudio es una empresa que vende bases de datos vectoriales y cuyos resultados nos dicen que la heurística de toda la vida recupera algo más que el chunker sofisticado que ella misma propone.

La conclusión que escriben los autores es la concesión entera: las heurísticas simples funcionan bien en la práctica cuando están bien parametrizadas.

Hay un segundo aspecto menos citado pero determinante que debemos tener en cuenta. Evaluar el chunking con rigor va mucho más allá de cambiar un parámetro y comprobar que la demo sigue respondiendo. Aunque el estándar tradicional exige construir un dataset (ground truth) sobre tu propio corpus, un proceso costoso y difícil de escalar, no es el único camino.
Hoy existen alternativas validadas en la literatura: desde la síntesis automatizada de casos de prueba (Ragas, ARES), hasta el análisis aislado del retriever mediante métricas clásicas de recuperación de información como Hit Rate, MRR o NDCG (benchmark BEIR), pasando por la auditoría de relevancia contextual mediante el paradigma LLM-as-a-judge.

Además, y esto ya es una opinión sin datos por detrás, el chunking se percibe como fontanería previa al trabajo interesante. Se despacha en la primera semana del proyecto para pasar cuanto antes a la ingeniería de prompt, re-ranking o sistema agéntico.

Cuatro estrategias sobre el mismo documento: cuál gana y qué rompe cada una

Pongamos de ejemplo un análisis sencillo, un ejercicio de juguete para ilustrar los conceptos. No pretendemos realizar aquí una investigación profunda, sino mostrar los pasos prácticos para evaluar nuestro chunking y cómo algunos factores a menudo ignorados afectan a la calidad de las respuestas.

He aplicado cuatro estrategias de chunking sobre un mismo documento: una política interna sobre “Días libres, vacaciones y ausencias.pdf” de Paradigma Digital. Contiene 9 páginas, 18.638 caracteres con títulos, preguntas frecuentes y listas numeradas. El documento tipo de cualquier empresa.

El documento es interno, solo voy a publicar las cifras y los cortes, no el texto. El modelo empleado para la prueba es paraphrase-multilingual-MiniLM-L12-v2 (con una longitud máxima de secuencia de 128 tokens).

Al evaluar cómo fragmentar un documento, nos encontramos con cuatro enfoques principales, cada uno con un equilibrio distinto entre costo, predictibilidad y coherencia contextual. Como ilustra la figura 1, estas estrategias generan rangos de tamaño muy dispares sobre el mismo documento, lo que condiciona directamente la efectividad de la recuperación:

• Ventana fija: es la opción más económica y predecible. Al segmentar por un conteo rígido, ignora la estructura de las frases. Su robustez depende casi totalmente del solapamiento (overlap) para recuperar el contexto entre fragmentos.
• Recursiva: implementa una jerarquía de separadores (párrafos, frases, caracteres). Esto, aparentemente, es una mejora notable frente a la fija, ya que intenta respetar la lógica del texto, logrando fragmentos más consistentes y una fragmentación más "limpia" al arrancar en el inicio de los párrafos.
• Estructural: aprovecha la sintaxis (títulos, encabezados) para extraer unidades con sentido completo. Es extremadamente efectiva cuando la extracción es precisa, pero altamente dependiente de la calidad del parser. Cualquier error tipográfico puede convertir una línea suelta en un falso encabezado, rompiendo la coherencia de los bloques.
• Semántica: es la más sofisticada, al agrupar el texto según la similitud de significado. Genera los bloques temáticamente más coherentes, pero es la opción más costosa y difícil de controlar, ya que el tamaño del fragmento deja de ser un parámetro ajustable para convertirse en una consecuencia del contenido, creando desde ruido (bloques mínimos con 2 caracteres como se observa en la Figura 1) hasta fragmentos excesivamente largos.

No existe una estrategia ganadora absoluta. Cada método gana en algo y rompe en otra cosa dependiendo de la naturaleza del texto. La elección no debe ser un sorteo basado en la popularidad del método, sino una decisión fundamentada en cómo cada estrategia gestiona las unidades de información de tu corpus.

Resultados del análisis

Lo primero que podemos observar y analizar es la longitud de los fragmentos para cada una de las estrategias. Esto nos sirve para hacernos una idea de la disparidad en los tamaños resultantes, lo cual es el primer indicador de cómo cada estrategia afecta la granularidad de la información.

En la figura 1 se muestra el rango de resultados aplicados al documento de referencia.

En la figura 1 tenemos más datos del proceso. Por cada estrategia obtenemos un número de chunks específico: 72, 56, 50 y 22 fragmentos, y ninguna de las cuatro merece la pena desecharla de buenas a primeras. Menos fragmentos no es un indicador mejor.

Esto nos lleva al dilema fundamental de la granularidad: un compromiso constante entre el contexto general y los detalles finos. Fragmentos demasiado pequeños ganan en precisión para consultas directas, pero corren el riesgo de perder el hilo conductor necesario para entender la respuesta completa.

Por el contrario, fragmentos excesivamente extensos preservan el contexto, pero a menudo "diluyen" la información relevante, dificultando que el sistema localice el dato concreto. Encontrar el punto de equilibrio no es una ciencia exacta, sino un ajuste fino que depende totalmente de cómo está estructurada la información en tu corpus.

En la siguiente tabla también se puede observar cuántos tokens ocupa cada uno de esos fragmentos en comparación con los 128 tokens de longitud de ventana que establece el modelo utilizado. Este límite marca el umbral del fenómeno de truncamiento ciego, que introduce un sesgo semántico peligroso al comprometer la representación vectorial del fragmento.

Es un problema de "ceguera parcial": el LLM recibe la información completa, pero el sistema de recuperación, que actúa como filtro de entrada, nunca llegó a procesar esa información durante la fase de búsqueda. Esto explica, a veces, por qué el sistema puede recuperar un fragmento aparentemente relevante basándose únicamente en su inicio, pero ofrecer una respuesta pobre porque el núcleo de la información estaba en los tokens descartados.

Tabla 1. Comparativa de las cuatro estrategias de chunking aplicadas sobre el documento “Días libres, vacaciones y ausencias.pdf”.

Y aquí está el motivo por el que este fallo sobrevive años dentro de un sistema en producción: lo que excede la ventana se descarta al vectorizar sin error y sin aviso.

Es un proceso totalmente silencioso, no se generan excepciones, advertencias ni errores en los logs del sistema. El fragmento entra en el índice, ocupa su vector y se comporta con toda normalidad. Solo que ese vector representa sus primeros 128 tokens y nada más.

El texto completo sí llega al LLM, porque viaja en el payload. Pero no participó en la búsqueda. Lo que decidió si ese fragmento se recuperaba o no fue un fragmento del fragmento, es decir, una pérdida de información descomunal.

La Figura 2 ilustra este fenómeno. El umbral de 128 tokens no diferencia entre estrategias eficaces e ineficaces. En su lugar, atraviesa la distribución de aquellas que, por su naturaleza, se ajustan mejor a la estructura del documento.

Por tanto, antes de analizar métricas de recuperación o ajustar el tamaño de ventana, la auditoría del truncamiento es un paso obligatorio. Si tus fragmentos están siendo cortados ciegamente por el modelo de embeddings, cualquier optimización posterior será en vano porque el sistema estará indexando información incompleta.

Evaluar este fenómeno es, en última instancia, la primera prueba de estrés para verificar si tu estrategia de chunking es realmente funcional o si está limitando el potencial de tu RAG desde el primer día. Ese es el primer dato que conviene tener sobre la mesa antes de discutir qué estrategia es mejor.

Calibración del tamaño de fragmento: la insuficiencia del score de similitud como criterio de relevancia

En este caso solo las estrategias fija y recursiva permiten fijar el tamaño del fragmento. Esta calibración solo tiene sentido con estas estrategias que suelen ser las más habituales cuando se comienza por a crear un sistema RAG.

Se ha indexado el mismo documento con tres configuraciones de tamaño y solape, medidas en palabras, y se ha lanzado una consulta de las que hace cualquier empleado: ¿cuántos días de vacaciones pendientes se pueden arrastrar y hasta cuándo?

El score que podemos observar en la tabla 2 es la similitud coseno entre el vector de la pregunta y el vector del fragmento top-1, calculada sobre un índice construido desde cero para cada configuración. No mide si la respuesta está completa, solo la cercanía geométrica entre los dos.

Tabla 2. Resultado de la consulta piloto sobre tres configuraciones de tamaño y solape, mismo documento.

Los resultados muestran tres cosas a la vez:

1. Con fragmentos demasiado pequeños (30 palabras) la respuesta queda repartida entre varios trozos y el sistema devuelve un texto de otra página, un fallo que nada arregla después.
2. El score tampoco distingue al ganador correcto: 60 palabras saca 0,7704 frente a 0,7690 de 120 palabras, una diferencia de ruido, y el que "gana" es el que corta la respuesta a la mitad, mientras el que "pierde" trae el plazo completo.
3. El tamaño determina el coste: al pasar de 30 a 120 palabras los fragmentos bajan de 124 a 39, así que hay menos que indexar y comparar, a cambio de enviar más tokens en cada consulta.

Lo que enseña este ejemplo podríamos resumirlo en una frase: un sistema puede devolver un score alto, sobre el documento correcto y en la página correcta, y aun así entregar una respuesta a la que le falta información.

Esta falta de información puede ser “rellenada” por el LLM en su respuesta y es otro foco de alucinaciones a los que debemos prestar atención.

Ahora la letra pequeña, antes de que la escriba nadie en los comentarios. Esto es una consulta, un documento y un top-1. Es decir, ilustra un mecanismo, no lo mide. Con otra pregunta, el orden de los scores puede cambiar y el ganador de esta tabla no es una recomendación de tamaño para nadie. Es la prueba de que hay que medir el corpus y no copiar configuraciones de nadie.

Qué dice la investigación a escala más reciente

Hasta ahora hemos analizado un caso de “juguete”, un documento, un experimento rápido y una consulta de muestra. Es momento de contrastar estas observaciones con la evidencia a escala y evaluar si las técnicas emergentes realmente superan los problemas de truncamiento que hemos detectado.

En este estudio de Shaukat et al. (2026) se ha medido con 1.080 configuraciones, aplicando 36 estrategias de chunking, seis dominios y cinco modelos de embeddings, con la recuperación aislada del resto del sistema. Los resultados del estudio, después de todo ese volumen, es lo que venimos diciendo en el post, no hay ganador único. Por ejemplo, la estrategia del troceado dinámico domina en Biología, Salud y Física. La agrupación por párrafos gana en Legal y Matemáticas. Y en el dominio de Agricultura ningún método destaca con claridad.

De esta investigación se extrae una conclusión fundamental: no existe una estrategia universal, ya que la eficacia de cada método depende intrínsecamente del dominio, del corpus.

Además, es un error intentar compensar una estrategia de segmentación deficiente mediante el uso de modelos de embeddings más avanzados.

Dado que el chunking y los embeddings operan de forma multiplicativa y no como alternativas excluyentes, una mala segmentación limitará irremediablemente el rendimiento de cualquier modelo, independientemente de su coste o sofisticación.

La pregunta que sí tiene respuesta

La pregunta con la que casi todos llegamos a este tema es: ¿cuál es la mejor estrategia de chunking? Es la pregunta equivocada y sigue sin respuesta tal y como hemos visto en este post.

La estrategia ideal no es inmutable: su rendimiento oscila según el dominio, el modelo de embeddings y la estructura de tus documentos.

Por eso, la pregunta clave no es cuál es la mejor, sino qué cuota de precisión estamos perdiendo al no auditar nuestra propia configuración de chunking.

Resolver esta cuestión es un proceso que requiere tiempo y un análisis consciente. Dedicar unos días a auditar cuántos fragmentos exceden la ventana del modelo, preparar consultas representativas junto a expertos de negocio y probar distintas configuraciones, entre otras cosas, es una inversión que merece la pena. No es necesario un benchmark complejo, lo que realmente se requiere es dedicación.

La esencia de este artículo se resume en una única máxima: no adoptes una estrategia de chunking por inercia, mide la tuya.

Y si conoces a alguien que montó su RAG hace año y medio y desde entonces no ha vuelto a abrir el fichero donde vive el splitter, compárteselo. Es quien más tiene que ganar dedicando unos días a esta revisión.

Referencias

• Es, S., James, J., Anke, L. E., & Schockaert, S. (2024, March). Ragas: Automated evaluation of retrieval augmented generation. In Proceedings of the 18th conference of the european chapter of the association for computational linguistics: system demonstrations (pp. 150-158).
• Ford, D. (2024, 19 de septiembre). Introducing contextual retrieval. Anthropic.
• Günther, M., Mohr, I., Williams, D. J., Wang, B., y Xiao, H. (2024). Late chunking: Contextual chunk embeddings using long-context embedding models. arXiv:2409.04701.
• Lu, W., Chen, K., Qiao, R., y Sun, X. (2025). HiChunk: Evaluating and enhancing retrieval-augmented generation with hierarchical chunking [Preprint]. arXiv:2509.11552.
• Merola, C., y Singh, J. (2025). Reconstructing context: Evaluating advanced chunking strategies for retrieval-augmented generation. Second Workshop on Knowledge-Enhanced Information Retrieval (KEIR), ECIR 2025. Preprint: arXiv:2504.19754.
• Saad-Falcon, J., Khattab, O., Potts, C., & Zaharia, M. (2024, June). Ares: An automated evaluation framework for retrieval-augmented generation systems. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers) (pp. 338-354).
• Shaukat, M. A., Adnan, M., y Kuhn, C. C. N. (2026). A systematic investigation of document chunking strategies and embedding sensitivity [Preprint]. arXiv:2603.06976.
• Smith, B., y Troynikov, A. (2024). Evaluating chunking strategies for retrieval [Informe técnico]. Chroma.
• Thakur, N., Reimers, N., Rücklé, A., Srivastava, A., & Gurevych, I. (2021). Beir: A heterogenous benchmark for zero-shot evaluation of information retrieval models. arXiv preprint arXiv:2104.08663.
• Zheng, L., Chiang, W. L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., ... & Stoica, I. (2023). Judging llm-as-a-judge with mt-bench and chatbot arena. Advances in neural information processing systems, 36, 46595-46623.

En el episodio de hoy, analizamos las cinco noticias más relevantes del mes que están redefiniendo el panorama tecnológico global.

1 OpenAI resuelve 372 problemas matemáticos sin resolver y publica las demostraciones en GitHub

En un movimiento histórico para la comunidad científica, OpenAI ha publicado en GitHub un catálogo con 372 familias de resultados matemáticos y más de 700 manuscritos generados autónomamente por un nuevo modelo interno de frontera.

• Resolución de problemas abiertos: el sistema ha logrado avances significativos en conjeturas complejas (como avances parciales sobre la hipótesis de Riemann o la conjetura de Kakeya), formalizando más de 200 de estos hallazgos directamente en el lenguaje de verificación Lean.
• Cómputo por solución: cada demostración requirió, en promedio, tres horas de cómputo de alto nivel mediante procesos de razonamiento profundo.
• Impacto en la comunidad académica: para evitar la saturación de las revisiones por pares tradicionales, OpenAI ha colaborado con el Institute for Advanced Study (IAS) para establecer nuevos marcos de evaluación y validación de matemáticas generadas por IA.

2 Gemini 4 Argon: Google lanza su nuevo modelo para trabajo pesado y ciberseguridad

Google ha presentado Gemini 4 Argon, una variante de su arquitectura de nueva generación diseñada específicamente para razonamiento continuo de largo horizonte, ciberseguridad defensiva, finanzas e ingeniería de software avanzada.

• Enfoque en agentes a largo plazo: Argon está optimizado para ejecutar tareas complejas que requieren planificar y mantener contexto de trabajo a lo largo de horas o días sin degradar su rendimiento.
• Capacidades clave: sobresale en la revisión e integración en repositorios completos de código, la identificación de vulnerabilidades en infraestructura crítica y el análisis financiero multidimensional.
• Disponibilidad: se encuentra disponible globalmente mediante la API de Gemini, Google Cloud y los entornos empresariales de Google AI Studio.

3 Mistral Large 4 devuelve a Europa a la primera línea de los modelos abiertos

La compañía francesa Mistral AI ha lanzado Mistral Large 4, reafirmando el liderazgo europeo en el desarrollo de IA soberana y de pesos abiertos (open weights).

• Arquitectura Mixture-of-Experts (MoE): con una estructura nativamente multimodal de aproximadamente 1 billón de parámetros (activando cerca de 49B-52B parámetros por token), logra eficiencias de inferencia excepcionales.
• Soberanía de datos: permite a empresas y gobiernos desplegar un modelo con rendimiento de clase mundial en su propia infraestructura local o nube privada, evitando la dependencia exclusiva de proveedores cerrados.
• Multilingüismo y razonamiento: destaca especialmente en procesamiento multilingüe avanzado y en comprensión contextual profunda para sectores altamente regulados.

4 Microsoft y Nvidia preparan ordenadores Windows diseñados para agentes locales

La alianza entre Microsoft y Nvidia se consolida con el anuncio de una nueva categoría de hardware: Copilot+ PC NPU-X, PCs específicamente arquitecturadas para ejecutar agentes de IA de forma 100% local.

• Procesamiento de agentes híbrido: los nuevos equipos integran arquitecturas NPU y GPU unificadas capaces de ejecutar modelos agénticos locales sin enviar datos sensibles a la nube.
• Integración con el SO: Windows integrará capas de ejecución de agentes autónomos que podrán gestionar archivos, automatizar tareas en aplicaciones de escritorio y procesar contextos visuales en tiempo real de forma privada y con latencia ultrabaja.

5 Claude Opus 5.5 destaca sobre el resto de modelos actuales

Anthropic ha coronado el mes con la presentación de Claude Opus 5.5, posicionándolo como el modelo de frontera más potente del mercado para tareas complejas de conocimiento y programación agéntica.

• Seguridad y "Preserved Thinking": integra un sistema dinámico de salvaguardas que redirige consultas sensibles a versiones previas y añade capas de protección en su API para evitar la extracción de su cadena interna de razonamiento.
• Eficiencia operativa: a pesar de su enorme incremento de capacidad, Anthropic ha logrado reducir los costes de inferencia y aumentar la velocidad de respuesta frente a sus antecesores.

Octubre demuestra que la carrera de la IA ha superado la fase de los chatbots para adentrarse de lleno en la era de la ejecución autónoma y el razonamiento científico profundo.

Ya sea resolviendo problemas matemáticos sin respuesta durante décadas, desplegando agentes locales en PCs o compitiendo con modelos de pesos abiertos de nivel frontier, las herramientas actuales están listas para asumir flujos de trabajo complejos de principio a fin.

Escalar la optimización web sin destruir la experiencia de usuario ni degradar la infraestructura requiere superar la experimentación impulsiva en cliente. En este post analizamos cómo alinear estos tres departamentos mediante un marco de "Safe-UX": una estrategia basada en guardarraíles estricta (Design Tokens, arquitecturas Edge/Server-Side y System Prompts acotados) para entregar hiperpersonalización dinámica a velocidad sub-100ms.

Este es el segundo post de la serie sobre personalización dinámica sin arruinar la UX. Si no has leído la primera parte de la serie, te dejo el link a mano:

• Personalización dinámica con IA sin arruinar UX: la evolución de CRO y el impacto de GenAI en el workflow

El riesgo para UX: la fragmentación de la interfaz y la pérdida de consistencia en el Design System

El pilar sobre el que se sostiene una buena experiencia de usuario es la predictibilidad, una de las premisas fundamentales de las heurísticas de usabilidad de Nielsen Norman Group. Cuando un producto digital cuenta con un Design System consolidado, los patrones visuales, la jerarquía tipográfica y las interacciones responden a una lógica unificada que reduce la carga cognitiva del usuario.

La introducción de variantes dinámicas impulsadas por IA sin un control estricto pone en riesgo esta consistencia:

• Incoherencia visual y de componentes: si los modelos generativos modifican layouts, espacios o estilos de forma autónoma, la interfaz corre el riesgo de convertirse en un mosaico de componentes desalineados. Una alteración menor en un botón o en la disposición de una tarjeta de producto puede romper las guías de estilo globales del producto.
• Fragmentación de la experiencia de marca: si dos usuarios experimentan versiones de una misma web con tonos de voz, composiciones o flujos completamente diferentes, se diluye la identidad de marca. El usuario pierde la referencia visual reconocible, lo que puede derivar en una menor percepción de calidad y confianza.

El riesgo para Tech: latencia, llamadas a APIs externas en renderizado y el temido flicker effect que arruina los Core Web Vitals (CLS/LCP)

Para los equipos de ingeniería, la inyección de modificaciones dinámicas en tiempo real representa un reto constante de arquitectura y rendimiento web.

Cuando la lógica de optimización e IA se ejecuta en el lado del cliente (client-side), surgen fricciones de rendimiento técnicas críticas:

• Flicker Effect (FOOC/FOUC). Al cargar la página, el navegador renderiza primero la versión original y, milisegundos después, el script de experimentación aplica la variante generada por la IA. Este salto o parpadeo visual degrada la experiencia percibida y dispara la métrica de Cumulative Layout Shift (CLS), un problema común al implementar scripts en cliente que requiere estrategias específicas para prevenir el parpadeo de la página.
• Impacto en latencia y LCP. La dependencia de llamadas asíncronas a APIs externas o modelos de lenguaje durante el renderizado añade milisegundos de bloqueo. Esto retrasa la aparición del contenido principal (Largest Contentful Paint - LCP) y penaliza directamente la puntuación en Core Web Vitals, afectando al posicionamiento orgánico (SEO).
• Sobrecarga de scripts client-side. La acumulación de librerías JS y etiquetas pesadas para evaluar variantes en el navegador degrada la capacidad de respuesta y el rendimiento en dispositivos móviles o conexiones lentas.

El riesgo para Marketing / Negocio: alucinaciones o copys inadecuados que perjudiquen el posicionamiento de marca

Desde la perspectiva de negocio y marketing, la automatización del copywriting en tiempo real ofrece una agilidad sin precedentes, pero introduce riesgos reputacionales y comerciales significativos:

• Alucinaciones y afirmaciones no verificadas: los modelos de lenguaje pueden generar copys persuasivos pero inexactos, atribuyendo al producto características que no posee, precios incorrectos o condiciones de servicio no aprobadas por el equipo legal.
• Desalineación con el posicionamiento estratégico: un modelo enfocado de forma agresiva en maximizar la conversión a corto plazo puede recurrir a patrones como la urgencia artificial, el exceso de agresividad comercial o un lenguaje desalineado con los valores de la empresa.
• Promesas de valor inconsistentes: si el mensaje adaptado que ve el usuario en la landing page no coincide exactamente con la oferta real del producto o el servicio posterior, la conversión inicial terminará derivando en altas tasas de cancelación (churn) y descrédito de marca.

Guardarraíles para una IA Generativa "Safe-UX": 3 buenas prácticas

1 Alineación con el Design System: uso de componentes modulares predefinidos (tokens y componentes atómicos)

Para evitar la fragmentación visual y garantizar que las variantes dinámicas respeten la identidad de la marca, la IA Generativa no debe construir código HTML o CSS desde cero. Como destacan análisis sobre Design Systems preparados para IA, la clave reside en restringir la capacidad de actuación del modelo al ecosistema cerrado del propio sistema de diseño:

• Gobierno mediante Design Tokens: la IA debe interactuar exclusivamente con las variables de diseño preestablecidas. Siguiendo especificaciones como las del W3C Design Tokens Format, en lugar de permitir que el modelo invente un código de color Hex o una tipografía libre, se le limita a invocar tokens existentes.
• Composición atómica: el modelo de IA opera sobre componentes modulares aprobados por el equipo de UX/UI (botones, tarjetas, acordeones, banners). La IA únicamente decide qué variante de componente mostrar o qué contenido insertar dentro de sus slots predefinidos.
• Validación de accesibilidad automatizada: al utilizar componentes que ya llevan integrados los estándares de accesibilidad (ratios de contraste, etiquetas ARIA, navegabilidad por teclado), se garantiza que las variaciones generadas continúen siendo accesibles para todos los usuarios.

2 Modelos con restricciones (Prompt Engineering y Fine-Tuning): delimitar el tono de voz y reglas de negocio

Para mitigar el riesgo de alucinaciones, inexactitudes legales o desviaciones en el lenguaje, la generación de copy debe estar cercada por reglas de control estrictas en la capa de modelo:

• Estructuración de prompts de sistema (System Prompts): definición clara de las fronteras de comunicación. El prompt de sistema debe incluir el libro de estilo de la marca, palabras prohibidas, estructuras sintácticas permitidas y el tono de voz (Tone of Voice) adecuado para cada perfil de usuario.
• RAG (Retrieval-Augmented Generation) y bases de datos cerradas: la IA no debe generar respuestas basándose únicamente en su entrenamiento general. Debe consultar en tiempo real una base de conocimientos auditada (fichas técnicas de producto, condiciones legales, FAQs aprobadas) para asegurar que cualquier afirmación sobre el producto sea rigurosamente cierta.
• Fine-Tuning y clasificadores de contenido: utilizar modelos afinados previamente con el histórico de copys de alto rendimiento de la empresa o implementar un modelo clasificador intermedio que evalúe y rechace la variante generada si no cumple con las métricas de alineación de marca antes de ser mostrada.

3 Arquitectura Edge / Server-Side: procesar la personalización antes de la entrega al navegador para mantener la velocidad <100ms

El rendimiento técnico y la velocidad de carga son factores críticos que impactan directamente en la tasa de conversión y en la visibilidad orgánica dentro de estrategias como la validación técnica de experimentos web y la optimización para SEO Generativo (GEO). Para eliminar el parpadeo de pantalla (flicker effect) y proteger los Core Web Vitals, la lógica de optimización debe desplazarse fuera del navegador del usuario:

• Procesamiento en el Edge (CDNs dinámicas): mover las llamadas al modelo de IA y las reglas de personalización a nodos Edge cercanos a la ubicación geográfica del usuario, utilizando tecnologías como los Worker scripts y HTMLRewriter de Cloudflare.
• Renderizado Server-Side (SSR): el servidor o el nodo Edge evalúa las señales del visitante, consulta la variante al modelo y entrega el HTML ya modificado al navegador en una sola respuesta.
• Zero-Flicker y latencia <100ms: al entregar el documento HTML listo para ser dibujado por el navegador, se elimina por completo el salto visual (CLS = 0) y el tiempo de respuesta se mantiene por debajo del umbral recomendado para interacciones instantáneas, conservando intacta la puntuación de Largest Contentful Paint (LCP).

Casos de uso prácticos (E-commerce, SaaS y Lead Gen)

E-commerce: landing pages dinámicas que adaptan el beneficio principal según la categoría de producto previa consumida

En el comercio electrónico, uno de los mayores problemas de conversión es la desconexión entre el contenido genérico de la página de inicio o landing page y los intereses específicos detectados en las sesiones de navegación del usuario.

Mediante la integración de motores de IA y personalización contextual, es posible reestructurar la propuesta visual y narrativa en tiempo real:

• Reorganización del hero section. Si las interacciones previas del usuario se han concentrado en calzado deportivo de alta gama, el banner principal de la landing page adaptará de forma autónoma el titular, la imagen de fondo y la propuesta de valor hacia atributos como "durabilidad, rendimiento y amortiguación". Por el contrario, si el comportamiento previo refleja búsquedas de moda urbana, el mensaje pivotará hacia "tendencias, diseño y estilo".
• Social proof condicional. La sección de reseñas y testimonios filtra dinámicamente las valoraciones más relevantes según el perfil de compra. En lugar de mostrar opiniones aleatorias, presenta comentarios verificados sobre la categoría específica que el visitante ha explorado recientemente, acelerando la decisión de compra.
• Cross-selling contextual sin fricción. La IA predice el producto complementario con mayor probabilidad de conversión y adapta el bloque de recomendación situándolo en zonas estratégicas de la página, evitando la sobrecarga de oferta genérica.

SaaS B2B: formularios inteligentes que adaptan sus campos y mensajes según la industria detectada vía IP/Reverse-DNS

En los entornos SaaS B2B, los formularios extensos para la solicitud de demos o pruebas gratuitas generan una fricción considerable que reduce la tasa de captura de leads. Por otro lado, los formularios demasiado cortos dificultan la cualificación de los prospectos por parte del equipo comercial.

La combinación de bases de datos de inteligencia firmo-gráfica (como Clearbit Reveal o Albacross) con IA Generativa permite resolver esta tensión mediante la personalización de formularios y páginas de captura en el momento del acceso:

• Identificación de empresa en tiempo real. Cuando un usuario corporativo accede al sitio web, el sistema procesa su dirección IP mediante resolución de DNS inversa (Reverse-DNS Lookup) e identifica la empresa, el sector de actividad y el volumen estimado de empleados.
• Acortamiento dinámico de formularios (Form Shortening). Si el sistema de inteligencia de datos reconoce la empresa de origen, oculta los campos manuales como "Sector", "Nombre de empresa" o "Número de empleados". El usuario solo necesita introducir su correo profesional, reduciendo drásticamente el número de campos y aumentando la conversión.
• Adaptación contextual de la propuesta de valor. La IA reformula el titular superior del formulario y la llamada a la acción (CTA). Para una empresa del sector financiero, el texto puede destacar "Cumplimiento normativo y seguridad bancaria", mientras que para una startup tecnológica enfatizará la "Escalabilidad e integración vía API en minutos".

Media / Servicios: recomendaciones de contenidos y call-to-actions (CTA) según la fase de funnel del usuario

En plataformas de medios digitales, portales de servicios o estrategias de Inbound Marketing, tratar a todos los lectores por igual provoca la pérdida de oportunidades para hacerlos avanzar hacia la conversión o la suscripción.

El uso de modelos de clasificación apoyados por IA permite adaptar la arquitectura de contenidos y los botones de acción según el nivel de madurez digital del visitante.

Conclusión: el equilibrio del triángulo es el nuevo estándar del CRO

El éxito de una estrategia de CRO con IA Generativa no depende de la sofisticación del modelo de lenguaje ni de la velocidad con la que generamos variantes, sino de la solidez del marco defensivo que construimos a su alrededor.
La tensión entre Marketing, UX y Tecnología deja de ser un cuello de botella en el momento en que se establecen reglas de juego claras:

• Marketing y Negocio obtienen la relevancia contextual y el rendimiento necesario alineando los modelos a bases de conocimiento cerradas (RAG) para eliminar las alucinaciones comerciales.
• UX y Producto protegen la consistencia visual y la identidad de marca obligando a la IA a operar únicamente dentro de componentes atómicos y Design Tokens predefinidos.
• Tecnología garantiza la velocidad y el cumplimiento estricto de los Core Web Vitals desplazando el procesamiento hacia arquitecturas en el Edge y Server-Side Rendering, alcanzando tiempos de respuesta imperceptibles.

Personalizar a escala ya no consiste en alterar la web al vuelo de manera caótica. El verdadero futuro de la optimización digital pasa por crear un sistema vivo donde la automatización e inteligencia artificial operan dentro de un entorno controlado, invisible para el usuario en términos de latencia, pero de máximo impacto en la conversión.

Referencias

• Nielsen Norman Group. (s.f.). Consistency and Standards: 10 Usability Heuristics
• Google Web.dev. (s.f.). Optimize Cumulative Layout Shift (CLS)
• Optimizely Glossary. (s.f.). Server-Side Testing vs. Client-Side Performance
• VWO Blog. (s.f.). Understanding VWO SmartCode and Preventing Page Flicker
• Harvard Business Review. (2023). Managing the Risks of Generative AI in Marketing
• McKinsey & Company. (s.f.). The Value of Getting Personalization Right—or Wrong—Is Multiplying
• HubSpot Blog. (s.f.). Personalized Calls to Action Perform 202% Better Than Basic CTAs
• Validación técnica de experimentos web, Ideario Digital
• Guia de SEO generativo, Ideario Digital

Una de las versiones arrancó con su contexto escrito desde el principio: una especificación y un archivo que le decía al agente cómo era el proyecto (arquitectura, convenciones, qué respetar). La otra empezó con poco más que un README de instalación, y así estuvo durante meses.

El resultado lo contaba el propio repositorio. La versión con contexto tenía una arquitectura limpia, coherente, sin cabos sueltos. La otra, decisiones tomadas sobre la marcha, gestión de errores a medias, varios TO-DOs abandonados en el código y un documento de arquitectura que apareció tarde, cuando el desorden ya estaba hecho. La variable que las separó fue solamente el contexto.

Continuando con el mensaje de lo importante que es especificar para que el modelo no divague, ya que un agente siempre va a rellenar los huecos de información con lo primero que le sirva, el contexto cobra mayor importancia porque es lo que decide si esos huecos se rellenan con información de tu proyecto o con invenciones que le encajen.

Para no hablar en abstracto, vamos a usar el mismo ejemplo que recorre toda la serie: una app de gastos compartidos. Ya sabes, esas para repartir la cuenta de un viaje o de una cena entre varias personas. Su MVP es modesto a propósito: crear un grupo por evento, añadir un gasto indicando quién pagó, repartirlo de forma configurable, ver una pantalla de balance que diga quién le debe a quién y liquidar.

Lo que no entra en la v1 también está decidido: nada de pagos reales dentro de la app, nada de multidivisa, nada de modo offline. Sobre esa app iremos colgando todo lo que sea relevante sobre el contexto, porque las ideas bonitas se entienden de verdad cuando chocan con una feature concreta.

¿Qué es “el contexto” de una app en realidad?

El contexto de una app es el contrato que el agente lee antes de tocar el código, los documentos que le dicen cómo funciona esta app en concreto. No es un README de instalación ni documentación de adorno, es lo que convierte un “hazme una pantalla” en “hazme una pantalla que encaje aquí”.

Merece la pena decirlo porque cuesta verlo. Es fácil pensar que el contexto era “contarle al agente qué hace la app” y no es eso, o no solo eso. El contexto es contarle qué decisiones ya están tomadas para que no las vuelva a tomar él. En la app de gastos compartidos, que el reparto pueda ser por partes iguales, por porcentajes o por importes fijos es una decisión de producto que el agente debe respetar, no reinventar cada vez que toca esa zona.

En nuestros proyectos, este contrato vive en tres capas a nivel de cada app:

Llevado a un archivo, el contrato de la app de gastos compartidos se parece a esto. Es el CONTEXTO.md que dejamos en la raíz del repo para que el agente lo lea antes que cualquier otra cosa:

# CONTEXTO — App de gastos compartidos

## Qué es
Repartir gastos de un evento (viaje, cena) entre varias personas.
MVP:
- Crear un grupo por evento.
- Añadir un gasto indicando quién pagó.
- Reparto configurable: partes iguales / porcentajes / importes fijos.
- Pantalla de balance: quién debe a quién.
- Liquidar.
Fuera de la v1 (NO implementar):
- Pagos reales dentro de la app.
- Multidivisa.
- Modo offline.

## Cómo está hecha
Clean Architecture. Capas: ui / domain / data.
- ui    → pantallas y estado, sin lógica de negocio.
- domain→ casos de uso y reglas (el reparto vive aquí).
- data  → repositorios y fuentes de datos.

## Persistencia
Base de datos local → fuente de verdad de los datos.
Backend → solo sincronización entre dispositivos.
PROHIBIDO llamar al backend desde la UI. La UI habla con domain;
domain habla con data; data decide local vs. backend.

## Convenciones
Estado de pantalla: loading / error / data.
Errores: nunca un TODO; siempre un manejo real.

Ninguna de estas especificaciones es exótica, la mitad del archivo describe cosas que la app no hace. Ese “fuera de la v1” pesa tanto como el MVP, porque es lo que evita que el agente, en cuanto huela un campo de importe, te monte la conversión de divisas que nadie le ha pedido. Lo decisivo no es qué pone, sino que esté escrito antes de que el agente empiece a decidir por su cuenta.

Sin contexto, el agente no se para. Improvisa

Un agente IA sin contexto no se para a preguntar, improvisa una arquitectura plausible y sigue adelante. Como nunca dice “no sé”, rellena cada decisión que no le dimos con lo que supone razonable, y lo que supone casi nunca coincide con lo que ya tenemos montado.

En la versión sin contexto, eso se tradujo en lo previsible: errores resueltos “para salir del paso” con un TO-DO en lugar de un manejo real, ninguna regla sobre cuándo usar la base de datos local y cuándo el backend y patrones que cambiaban de una pantalla a otra. El agente no se equivocó según su propia lógica, el problema es que no tenía la nuestra.

Se ve más claro bajándolo a una feature de la app de gastos. Imaginemos que le pedimos añadir el reparto por porcentajes a un grupo. Sin contexto, un encargo así:

Añade que un gasto se pueda repartir por porcentajes entre los miembros del grupo

El agente, que es servicial hasta el agobio, hace de todo a la vez: mete la lógica del reparto dentro del widget de la pantalla, llama directamente al backend para “guardar los porcentajes”, se inventa un modelo nuevo en lugar de tocar el gasto que ya existe y, de paso, deja un “//TO-DO: validar que sumen 100%” por si acaso.

Funciona en la demo pero el resultado fue el incumplimiento de tres principios fundamentales en una única funcionalidad: acabé con la lógica de negocio incrustada en la interfaz, una conexión al backend que vulneraba el contrato y código de dominio redundante.

No lo hizo de mala fe, le pedimos un reparto… sin decirle dónde vive el reparto en nuestra app. Y donde no hay regla, hay improvisación.

El agente no improvisa porque sea malo. Improvisa porque no le dimos la información que necesitaba y tuvo que improvisar.

Con el CONTEXTO.md delante, ni siquiera hace falta pedir lo mismo de otra forma. El mismo encargo, ahora interpretado a través del contrato, suena así:

Añade el reparto por porcentajes a un gasto. 
- La regla del reparto va en domain (caso de uso), nunca en la UI.
- Reutiliza el modelo de gasto que ya existe; no crees uno nuevo.
- Persiste en la BD local; el backend solo sincroniza (no lo llames desde aquí).
- Estado de pantalla: loading / error / data. Sin TO-DO: valida que sumen 100%.

La diferencia no está en que escribamos más, sino en que esas cuatro líneas ya estaban escritas una vez, en el contrato, y el agente las arrastra a cada tarea. La pieza encaja en lugar de aterrizar de cualquier manera. Y lo mejor: la próxima feature (el filtro de gastos por persona, pongamos) hereda exactamente las mismas reglas sin que las repitamos.

La trampa del contexto a posteriori

Documentar la arquitectura después de escribir el código no es montar el contexto, es hacerle la autopsia. En la versión que salió mal, ese documento llegó tarde, con el grueso del código ya escrito. No dirigió ni una sola de aquellas decisiones, sino que se limitó a describir, con buena letra, el desorden que ya existía.

Y ahí está el matiz que más gente se salta: un contrato que firmas después del trabajo no es un contrato, es un acta. El contexto solo cumple su función (evitar que el agente improvise) si existe antes que el código que se supone que debe guiar.

Lo digo por experiencia. En la versión que salió mal, llegamos a tener un documento de arquitectura con diagramas, capas bien nombradas, todo. Y no servía de nada porque describía un código que ya había decidido otra cosa.

Documentar a posteriori es hacer la autopsia porque aprendes qué mató al proyecto, pero el proyecto ya está en la camilla. La feature del balance, por ejemplo, en esa versión calculaba quién debe a quién en tres sitios distintos y ningún documento posterior iba a unificar eso por mí.

Cómo montar el contexto antes de empezar

El contexto se monta al principio, antes del código y en las tres capas que ya vimos: qué es, cómo está hecha y qué no se toca. No tiene por qué ser largo, tiene que existir antes que la primera línea. En nuestras apps mejor montadas, cada una arranca con su carpeta de documentación (especificación, decisiones, diseño) validada antes de programar nada.

En la práctica, para la app de gastos compartidos eso fue una sesión corta con el agente discutiendo el contrato, no escribiendo código. Algo tan tonto como esto antes del primer commit:

repo/
|–– CONTEXTO.md       <-- qué es, cómo está hecha, qué no se toca
|–– docs/
|   |–– spec.md       <-- el MVP detallado: grupos, gastos, reparto, balance
|   |__ decisiones.md <-- por qué BD local como fuente de verdad
|__ (todavía sin una sola línea de código)

Parece poca cosa, pero con media hora de definición nos estamos ahorrando semanas de pelear con un agente que tira para donde no quieres. Cuando luego le pedimos la pantalla de balance, no tuvimos que explicarle de nuevo que el cálculo de “quién debe a quién” vive en domain porque ya lo sabía.

Para que el contrato funcione:

• Escríbelo antes del primer commit, no a mitad de camino.
• Mantenlo corto: decisiones y reglas, no una enciclopedia.
• Actualízalo cuando una decisión cambie, no cuando ya rompió algo.

El contexto es un contrato vivo, no un documento de archivo.

Y una advertencia, porque el péndulo se va fácil al otro extremo: el contexto no es un volcado de todo lo que sabes. Si metes una enciclopedia, el agente se pierde igual que si no metes nada. El contexto es el contrato, las decisiones y las reglas que de verdad lo atan, no cada detalle de implementación. Lo que no condiciona una decisión, sobra.

El contexto no es solo para apps nuevas, también para una funcionalidad

La mayor parte del tiempo no construimos una app de cero, añadimos una funcionalidad a una que ya existe. Y ahí el contexto importa igual, o incluso es más importante. El agente necesita saber dónde encaja esa pieza, qué reutilizar y qué dejar en paz o reinventará lo que ya tenemos montado.

Un ejemplo de andar por casa en la app de gastos que podría funcionar es pedirle “añade un filtro de gastos por persona en la pantalla del grupo”. Sin contexto de la funcionalidad, el agente puede montarnos una capa de datos nueva, duplicar el repositorio de gastos que ya existe o resolver el filtro con un patrón distinto al del resto de la app. Funciona, pero acabamos con dos formas de hacer lo mismo. Es la bola de nieve otra vez, ahora a escala de feature.

Con contexto de la funcionalidad, el encargo cambia de naturaleza:

Añade un filtro de gastos por persona en la pantalla del grupo.
- Filtra usando el GastoRepository que ya existe; no crees otra fuente.
- Sigue el patrón de la pantalla de listado de gastos.
- El filtrado es lógica de dominio: resuélvelo en el caso de uso, no en el widget.
- No toques el modelo de gasto.

El agente deja de inventar y se limita a colocar la pieza en su sitio. Es el mismo salto que con el reparto por porcentajes, pero a una escala todavía más pequeña y por eso más fácil de olvidar darle contexto, que es justo cuando muerde.

El contexto de una funcionalidad:

• Dónde encaja: la pantalla o el módulo y el patrón que debe seguir.
• Qué reutilizar: los repositorios, componentes o utilidades que ya existen.
• Qué no tocar: lo que queda fuera del alcance de esta feature.

Es el mismo contrato, una talla más pequeña

Es la misma idea de “definir y acotar” del primer artículo de la serie, pero aplicada al contexto: cada tarea, por pequeña que sea, tiene su porción de contexto. Dársela antes de empezar es lo que evita que el agente, por ayudarte con una funcionalidad, nos ensucie las otras veinte.

Dolor o boost: cambia cómo le hablamos al agente

Montar el contexto cambia, sobre todo, tu forma de comunicarte con el agente. Sin contexto, en cada sesión repetimos las mismas reglas, corregimos los mismos desvíos y vigilamos cada salida por si se ha inventado algo. Con contexto, señalamos la tarea y el agente se mantiene en los raíles que escribimos una vez.

Con la app de gastos se nota en que dejamos de escribir mensajes de tres párrafos explicando la arquitectura cada vez. Pasamos de “monta esto, pero recuerda que la lógica va en domain, y no llames al backend, y reutiliza el repositorio, y por favor nada de TO-DOs…” a, simplemente, “añade el filtro por persona” y el contrato hacía el resto del trabajo en cada prompt.

Esa es la diferencia entre que la IA sea un dolor o un acelerador. No la marca el modelo que uses, sino si le dimos el contrato antes de pedirle que trabaje. Es, en el fondo, la diferencia entre dirigir y rezar.

En esta serie, el contexto nace de la fase de definición del primer artículo y prepara las siguientes: el diseño, el stack, la spec y el desarrollo. El paso inmediato es darle al agente capacidades reutilizables (las skills), que se apoyan precisamente en este contrato para saber cómo y dónde actuar. Pero el orden no cambia nunca: primero el contrato, después la primera línea de código.

Sin embargo, garantizar esa conectividad sigue siendo un reto especialmente complejo en las zonas rurales, donde la baja densidad de población dificulta la rentabilidad de los despliegues.

En este episodio de ‘Apasionados por la tecnología’, hablamos con Manuel Garnelo, CTO de ASTEO, sobre el papel de los operadores neutros, los desafíos técnicos de llevar fibra óptica a entornos rurales y cómo la IA puede transformar tanto el consumo de datos como la operación de las redes.

Operadores neutros: construir la red para conectar a toda la población rural

¿Qué es exactamente un operador neutro y qué aporta al mercado de las telecomunicaciones? Su modelo se basa en separar dos actividades: el despliegue y la operación de la infraestructura, por un lado, y la comercialización de servicios al cliente final, por otro.

ASTEO construye y mantiene redes de fibra óptica que alquila a otros operadores, que son quienes comercializan sus servicios y gestionan a los usuarios. Esta especialización permite que cada parte se centre en aquello que mejor sabe hacer: ASTEO en desplegar infraestructura de forma eficiente, incluso en entornos de baja densidad de población, y los operadores comerciales en captar clientes y atender sus necesidades.

El modelo también permite que varios operadores utilicen una misma infraestructura. De esta manera, la red puede dar servicio a más clientes y mejorar su rentabilidad, algo especialmente importante en zonas donde desplegar fibra supone una inversión considerable.

El reto de llevar fibra óptica a las zonas rurales

Diseñar una red de telecomunicaciones para una gran ciudad no es lo mismo que hacerlo para un entorno rural. La diferencia principal está en la densidad de población: mientras que en un edificio de una ciudad una única conexión puede dar servicio a cientos de hogares, en una zona rural es necesario desplegar infraestructura a lo largo de una superficie mucho mayor para conectar al mismo número de viviendas.

A este desafío se suma otro menos visible, pero fundamental: transportar el tráfico de datos desde poblaciones alejadas hasta los puntos de interconexión con Internet.

En el caso de ASTEO, esa conexión con su centro de intercambio de datos en Madrid requiere una red de transporte propia que permita llevar el tráfico desde distintas provincias hasta la capital.

Pero no todo son dificultades. La colaboración con las instituciones locales y los programas públicos de apoyo al despliegue rural también facilitan que la conectividad llegue a lugares donde, de otro modo, sería difícil justificar la inversión.

El objetivo va más allá de extender una infraestructura tecnológica: se trata de conseguir que vivir fuera de las grandes ciudades no implique renunciar a los servicios digitales.

Venus: una red de transporte preparada para crecer

Para conectar sus despliegues rurales con los grandes puntos de intercambio de datos, ASTEO ha desarrollado Venus, una red de transporte o backbone de fibra óptica que conecta distintas zonas de la península ibérica.

Inicialmente concebida para dar soporte a las redes de fibra hasta el hogar, esta infraestructura permite transportar distintos tipos de datos y conectar territorios que abarcan provincias como Burgos, Segovia, Salamanca, Cáceres y Badajoz.

Venus también está vinculada a un proyecto de conectividad internacional. ASTEO ha sido adjudicataria de un programa financiado con fondos europeos, denominado CEF, para desarrollar un corredor digital redundante de alta capacidad entre Lisboa y Madrid.

El proyecto contempla dos rutas, una por Badajoz y otra por Salamanca, que conectarán Madrid con Lisboa y facilitarán la conexión con los cables submarinos que llegan a la capital portuguesa desde América y África.

Esta infraestructura ilustra cómo una red concebida para conectar poblaciones rurales puede adquirir un papel más amplio dentro del ecosistema de telecomunicaciones, al contribuir también al transporte de datos entre regiones y grandes nodos digitales.

Más datos, más velocidad: cómo evolucionarán las redes de fibra

El crecimiento del tráfico de datos es uno de los grandes retos que afronta el sector. Según explica Manuel, existe una tendencia sostenida a que el consumo de ancho de banda aumente de forma significativa, impulsado por nuevos servicios y por el uso cada vez más intensivo de Internet.

La fibra óptica ofrece una ventaja importante para responder a esta evolución. Los cables constituyen una infraestructura duradera, capaz de soportar grandes incrementos de capacidad mediante distintas tecnologías de transmisión.

Esto significa que no siempre es necesario sustituir el tendido físico para aumentar el volumen de datos que puede transportar una red.

La evolución se concentra, en buena medida, en los equipos activos que gestionan y encaminan el tráfico. ASTEO dispone actualmente de conexiones preparadas para soportar velocidades de hasta 10 Gbps y prevé que la demanda pueda llevar a necesitar capacidades de hasta 50 Gbps.

Actualizar esos equipos será necesario a medida que cambien las necesidades, pero la infraestructura de fibra seguirá siendo la base sobre la que construir esas mejoras.

La clave está, por tanto, en diseñar redes con una visión a largo plazo y distinguir entre los elementos que pueden evolucionar tecnológicamente y aquellos que están preparados para perdurar durante décadas.

La inteligencia artificial multiplicará las necesidades de conectividad
La IA no solo necesita capacidad de cómputo: también requiere una infraestructura de comunicaciones capaz de transportar grandes volúmenes de información con una latencia reducida.

El crecimiento de los centros de datos destinados a ejecutar aplicaciones de IA incrementará el intercambio de datos entre estas instalaciones. A la vez, las aplicaciones que llegarán a los usuarios finales podrían generar nuevas formas de consumo que hoy apenas podemos anticipar.

Estas aplicaciones no son únicamente una cuestión de potencia de cálculo. También necesitan que los datos puedan desplazarse entre dispositivos, redes y centros de procesamiento con las prestaciones adecuadas.

Por eso, la expansión de la inteligencia artificial convierte la infraestructura de telecomunicaciones en una pieza todavía más importante de la transformación digital.

IA para anticipar problemas y optimizar las redes

Más allá del aumento del tráfico, la inteligencia artificial abre nuevas posibilidades para diseñar, dimensionar y operar redes de telecomunicaciones. El análisis de grandes volúmenes de datos puede ayudar a detectar patrones, anticipar posibles incidencias y prever las necesidades de capacidad.

En lugar de limitarse a reaccionar cuando aparece un problema, los operadores podrán avanzar hacia una gestión más predictiva.

Otro ámbito de aplicación es la automatización de tareas operativas. La IA podría llegar a identificar fallos recurrentes y corregirlos automáticamente, reduciendo la intervención manual en determinados procesos.

La evolución, por tanto, no consiste solo en construir redes con más capacidad, sino también en gestionarlas de forma más inteligente. La combinación de infraestructura física, análisis de datos y automatización puede ayudar a mejorar la eficiencia y anticiparse a las necesidades futuras.

Fibra, 5G y otras tecnologías: infraestructuras complementarias

En un ecosistema en el que conviven la fibra óptica, las redes móviles y las comunicaciones por satélite, es fácil pensar en estas tecnologías como alternativas que compiten entre sí. Sin embargo, desde la perspectiva de ASTEO, su relación es principalmente complementaria.

Un ejemplo claro es el 5G: las antenas móviles necesitan conexiones de transporte que permitan llevar el tráfico de datos hasta el resto de la red. La fibra desempeña ese papel y constituye una infraestructura fundamental para sostener el crecimiento de las comunicaciones móviles.

La llegada de futuras generaciones, como el 6G, podría incrementar aún más las necesidades de capacidad. Para ASTEO, esto representa una oportunidad: cuanto más crezcan los servicios móviles, mayor será también la necesidad de redes de fibra que los conecten.

Cada tecnología responde a unas necesidades específicas, pero todas dependen de una infraestructura de comunicaciones capaz de integrarlas. En este contexto, la fibra funciona como la columna vertebral que permite que el conjunto del ecosistema digital siga creciendo.

Conectividad rural para reducir la brecha digital

La extensión de la fibra óptica también tiene implicaciones económicas y sociales. Durante años, el despliegue de redes se concentró principalmente en las grandes ciudades, bajo la premisa de que las zonas rurales ofrecían una rentabilidad menor.

Sin embargo, el teletrabajo y el consumo generalizado de servicios digitales han cambiado esa perspectiva. Las personas que viven en pueblos pequeños necesitan acceder a plataformas de vídeo, realizar videoconferencias y utilizar las mismas aplicaciones que quienes viven en una gran ciudad. También quieren aprovechar las posibilidades que abre la inteligencia artificial.

Una conectividad de calidad contribuye a que vivir y trabajar fuera de los grandes núcleos urbanos sea una opción viable. Puede facilitar el teletrabajo, favorecer la actividad económica local y reducir la necesidad de desplazarse diariamente a las ciudades.

Desde esta perspectiva, llevar fibra a las zonas rurales no consiste únicamente en ampliar la cobertura de una red: significa crear condiciones para que esos territorios puedan participar plenamente en la economía digital.

Shakira acaba de finalizar su gira Las Mujeres Ya No Lloran World Tour con una residencia histórica de trece conciertos durante cuatro semanas en Madrid, reuniendo a más de 600.000 personas. La apuesta no consistía simplemente en repetir muchas veces el mismo concierto, sino en crear una experiencia única alrededor del estadio Macondo Park, una ciudad efímera que ha extendido la experiencia hacia territorios como la gastronomía, la literatura, la moda y la cultura.

La música sigue estando en el centro, por supuesto, pero el producto crece alrededor de una comprensión mucho más amplia de aquello que conecta con su comunidad a través del conocimiento sobre qué opinan sus fans en las redes sociales, cómo se escuchan sus canciones en las plataforma digitales e incluso desde qué lugares están dispuestos a viajar sus seguidores y qué otras experiencias buscan vivir cuando van a uno de sus conciertos.

Algo parecido acaba de ocurrir a pocos kilómetros de distancia, con el Gran Premio de España de F1 en el nuevo circuito madrileño Madring. La organización no se ha limitado a recibir una carrera existente, sino que ha estrenado un nuevo trazado construido para el Gran Premio y concebido desde el principio como algo más que un circuito.

Combinando zonas urbanas y permanentes, así como una curva peraltada que aspira a convertirse en su icono, ha sido capaz de ofrecer una experiencia alrededor de la carrera con conciertos, gastronomía y fan zones. La competición sigue siendo 57 vueltas y 22 coches buscando la meta, pero alrededor se ha diseñado deliberadamente una nueva experiencia gracias a un profundo entendimiento sobre qué mueve realmente a la afición cuando no están mirando la pista y de cómo convertir una carrera de dos horas en un fin de semana que nadie quiera perderse.

Detrás de ambos ejemplos hay una idea que debería hacernos repensar cómo entendemos la innovación: no gana quien acumula más datos ni quien incorpora la última tecnología, sino quien sabe convertir lo que conoce en algo que los demás no pueden ofrecer. Porque la tecnología se compra, los modelos de IA estarán cada vez más al alcance de todo el mundo y los datos no van a dejar de multiplicarse.

Lo que no se puede comprar tan fácilmente es el conocimiento que una organización ha construido durante años sobre sus clientes, su negocio y su manera de hacer las cosas. Y, sobre todo, su capacidad para conectar ese conocimiento con el contexto adecuado y transformarlo en experiencias, oportunidades y decisiones que marquen la diferencia. La tecnología puede ser la misma para todo el mundo. Lo que cada organización sabe y es capaz de hacer con ello, no.

¿Y qué tiene que ver todo esto con una entidad financiera? Mucho más de lo que parece. Pocas industrias acumulan tanto conocimiento sobre sus clientes como la banca: cómo cobran, cómo pagan, qué necesitan, qué riesgos asumen y cómo evolucionan sus circunstancias. Y, sin embargo, buena parte de ese patrimonio sigue atrapado en sistemas, procesos y departamentos que apenas se hablan entre sí.

Mientras tanto, los clientes empiezan a exigir algo diferente: ya no basta con ofrecerles productos y facilitarles operaciones, esperan que su banco entienda mejor su situación, se anticipe a sus necesidades y les acompañe en las decisiones que realmente importan.

El reto ya no es seguir acumulando información, sino conseguir que todo ese conocimiento empiece a trabajar. Convertir lo que una entidad sabe en lo que es capaz de hacer por sus clientes. Porque ahí está la oportunidad de transformar uno de sus activos más valiosos, y a menudo más desaprovechados, en su nueva ventaja competitiva. Mejor dicho, su nueva ventaja cognitiva.

Un banco cognitivo no es un banco con más IA

Conviene aclararlo pronto, porque la inteligencia artificial tiene cierta facilidad para convertir cualquier idea interesante en una colección de pruebas y demos. Un banco cognitivo no es una entidad que añade un chatbot, reparte copilotos o pone unos cuantos agentes a trabajar sobre los procesos de siempre. Es una organización capaz de conectar datos, conocimiento y contexto para comprender mejor a sus clientes, anticipar necesidades, tomar mejores decisiones y, cuando tenga sentido, actuar con autonomía dentro de unos límites claros.

Y esta es precisamente la idea que en Paradigma impulsamos con los Productos Cognitivos: transformar el conocimiento diferencial de una organización en capital cognitivo y utilizarlo para construir productos que entienden el contexto, recomiendan, deciden o actúan, aprenden con cada interacción y mantienen siempre el control en manos de la organización.

Pero el verdadero terremoto no lo está provocando la tecnología, sino el cambio en las expectativas de los clientes. Después de años adaptándose a los procesos, menús y aplicaciones de sus bancos, ahora empiezan a exigir justo lo contrario: que sea el banco quien les entienda, se anticipe y se adapte a ellos. Y ese cambio está empezando a mover las placas tectónicas del sector financiero en España.

Durante años, hemos celebrado que un cliente pudiera hacer prácticamente cualquier operación desde su móvil. Pero ahora empieza a pedir algo bastante más incómodo: que sea el banco quien le entienda y se adapte a él, y no al revés. Ya no se trata solo de ofrecer mejores productos o aplicaciones más sencillas, sino de anticipar necesidades, comprender el contexto y estar presente justo cuando se puede aportar valor al cliente. Y eso empieza a cambiarlo todo: quién interactúa con el banco, dónde se produce esa relación y hasta dónde puede llegar su negocio.

Al fin y al cabo, si Shakira ha entendido que la experiencia no termina con la última canción y la Fórmula 1 que hay mucho más allá de la bandera a cuadros, ¿por qué la experiencia financiera debería terminar cuando el cliente pulsa “Confirmar operación”? Pocas industrias acumulan tanto conocimiento sobre sus clientes como la financiera. El reto es dejar de tenerlo repartido por todas partes y empezar a convertirlo en mejores experiencias, oportunidades y decisiones. Pasar de gestionar transacciones a comprender todo lo que ocurre alrededor de ellas. Ahí empieza la verdadera banca cognitiva.

Y no hablamos de ciencia ficción ni de otra bonita presentación sobre el futuro, hablamos de cuatro señales que están cambiando las reglas del negocio y una quinta que merece jugar en otra categoría: la que nos recuerda que, por mucha inteligencia que incorporemos, la transformación seguirá dependiendo de las personas.

1 Te damos la bienvenida a la era agéntica: tu próximo interlocutor puede que no sea humano

Durante años, la banca trabajó con empeño por mover a sus clientes a sus canales desatendidos para ciertas operaciones. Primero al cajero, después a la web y finalmente a la app. “Hazlo tú mismo”, nos decían. Pues bien, hoy en día se está comenzando a dar la vuelta a la tortilla: son los clientes quienes empiezan a llevar a los bancos a sus propios canales desatendidos: sus asistentes o agentes de IA.

Imagina pedirle a tu agente de IA: “Busca un préstamo personal para el viaje familiar de Navidad, compara cinco bancos con buenas valoraciones y dime cuál encaja mejor con nuestros planes”. Y que, en lugar de abrir cinco aplicaciones, el asistente hable con los sistemas (o agentes) de esas entidades. Empiezas informándote y terminas operando o incluso contratando directamente. Ojo, no es ciencia ficción. Desde febrero de 2026, BBVA tiene una aplicación dentro de ChatGPT en Italia y Alemania para consultar y comparar cuentas, tarjetas y productos de ahorro. Por ahora.

Y aquí viene la sacudida: ese “nuevo representante” de los clientes no se emociona con la campaña de su banco, no necesita recorrer ocho pantallas y puede comparar ofertas en segundos. Después de tantos años intentando desintermediar la banca, quizá estemos entrando en su etapa más intermediada. Quien decide qué propuestas llegan al cliente podría ser su propio asistente.

Por eso, la carrera no empieza por construir un ejército de agentes, empieza por hacer algo mucho menos vistoso: ofrecer información de producto clara y accesible para las máquinas, abrir interfaces fiables y explorar qué decisiones pueden delegarse con identidad, consentimiento y límites claros. Podrás tener la mejor aplicación bancaria del mundo, pero ¿de qué te servirá si la IA de tu cliente ni siquiera se plantee abrirla?

2 El fin del banco como destino: no compitas solo con productos, orquesta ecosistemas

Durante años asumimos que una relación bancaria digital comenzaba cuando un cliente entraba en la sucursal o abría la aplicación en su móvil, pero esa frontera empieza a desdibujarse. Una financiación puede aparecer mientras compramos un coche, un seguro al contratar un viaje y una solución de tesorería dentro del ERP con el que una pyme opera su negocio día a día.

El canal se disuelve y el negocio empieza a comportarse como un ecosistema. No es simplemente otro canal de venta: es un cambio en el modelo de distribución comercial y, de paso, en la relación con el cliente. La banca deja de esperar a que alguien venga a buscar un producto y empieza a aparecer donde surge una necesidad. Y en ese escenario bancos, comercios, fabricantes y plataformas pueden compartir una misma experiencia. La pregunta incómoda es quién la lidera y quién acaba poniendo el balance sin conocer al cliente.

En España, Cajamar ya da algunas pistas con su Plataforma Tierra, un ecosistema para el sector agroalimentario que combina conocimiento, información de mercados, formación y herramientas digitales. Con más de 30.000 usuarios registrados y 1,2 millones de visitas, demuestra que la relación con un agricultor puede empezar mucho antes de que necesite financiación.

Eso cambia también qué significa competir. Ya no basta con ofrecer un préstamo atractivo: importa estar presente cuando se decide invertir, comprar o crecer, y entender el contexto para ofrecer algo útil. La oportunidad no exige construir mañana el gran ecosistema de la banca: puede empezar por identificar un momento de necesidad, conectar un servicio relevante o asociarse con quien ya está ahí. La diferencia estará en aprovechar lo que sabemos de cada cliente para ofrecerle lo que realmente necesite, cuando lo necesite. Porque puedes tener el mejor producto financiero, pero si no estás donde se toman las decisiones, quizá ni siquiera entres en la conversación.

3 Finanzas de precisión: la segmentación ha muerto, a no ser que sean segmentos propios

La banca lleva años afinando segmentos, ofertas y modelos predictivos, y no lo ha hecho precisamente mal. Pero los nuevos modelos de IA abren una nueva partida: pasar de ofrecer lo mejor para alguien parecido a ti a ofrecer lo que tiene sentido para ti, justo ahora. Personalización con contexto y en tiempo real.

Materia prima no falta. Está el conocimiento explícito (objetivos, preferencias o planes que el cliente comparte) y el tácito, que se desprende de sus cobros, pagos, hábitos e interacciones, e incluso conocimiento que solo está en la cabeza del gestor personal. El banco ya atesora buena parte de esas señales. El salto está en conectarlas, con los permisos y seguridad adecuada, para anticipar una tensión de liquidez, proponer una inversión solo cuando tiene sentido o decidir que hoy es mejor no vender nada.

Revolut ya ha movido ficha este mismo verano a través de Pragma, un modelo desarrollado de la mano de Nvidia que aprende de los comportamientos financieros. En evaluaciones iniciales con datos históricos, comunica recomendaciones de producto un 41% más relevantes y 2,3 veces más precisión al identificar riesgos de impago. Son resultados preliminares, pero apuntan a algo que nuestro sentido común ya anticipaba: comprender mejor el contexto mejora lo que ofreces y las decisiones que tomas.

Y después llega la parte visible: contenidos, explicaciones o incluso vídeos generados con IA para cada cliente, ajustando el tono, el canal y el momento. Pero ojo, no se trata de fabricar un millón de anuncios distintos para seguir el mismo fondo o campaña de financiación al consumo. Se trata de adaptar también el servicio: qué propones, cuándo y por qué. Se puede empezar por un momento concreto, conectar el conocimiento necesario y comprobar si la respuesta aporta valor.

Si a cada cliente le hablas de forma diferente, pero le acabas ofreciendo la misma campaña del trimestre, no has construido banca cognitiva. Solo has automatizado el marketing.

4 Tu próxima ventaja competitiva podrá venir de Bruselas, no solo de Silicon Valley

Se me ocurren pocas industrias más reguladas que la banca. Y con razón: gestionar dinero ajeno exige confianza. Pero tenemos la manía de mirar a Silicon Valley para imaginar el futuro y a Bruselas para averiguar qué nos frenará. ¿Y si estuviéramos mirando la regulación por el lado equivocado?

Ya hay señales. DORA obliga a reforzar la resiliencia digital y vigilar a los proveedores tecnológicos; MiCA establece reglas comunes para los servicios con cripto activos y PSD3, todavía en camino, apuntará a unos pagos más competitivos y seguros. Estas obligaciones también pueden abrir negocios que antes resultaban difíciles de desarrollar con confianza.

En España tenemos un buen laboratorio para comprobarlo: el sandbox financiero, que desde 2021 ha recibido más de 110 proyectos, de los cuales 40 han llegado a probarse en condiciones reales. Y este mismo verano se ha presentado una reforma para abrir las solicitudes todo el año y agilizar los plazos. Todavía es una propuesta, pero el mensaje es claro: innovar con supervisión no debería ser una carrera de obstáculos.

En la banca cognitiva, esto importa aún más. Cuando una IA pasa de informar a recomendar o actuar, no basta con que acierte. Hay que saber qué información utilizó, qué autorizó el cliente y dónde están los límites. Ahí el conocimiento propio, conectado y gobernado, puede convertirse en una ventaja difícil de copiar.

No hace falta esperar al próximo reglamento ni embarcarse en una transformación de cinco años, se puede empezar por una decisión concreta, probarla con controles y sentar a negocio, riesgos y tecnología a la misma mesa. Mientras unos bancos siguen calculando cuánto les costará cumplir la próxima regulación, otros ya están diseñando el negocio que esa regulación hará posible.

5 Menos personas trabajando como máquinas y más máquinas haciendo extraordinarias a las personas

En la carrera por automatizarlo todo, podemos olvidar un detalle importante: los clientes siguen siendo personas. Y quienes trabajan en el banco, también. La banca cognitiva no debería sacar humanos de la ecuación, sino liberar su talento para escuchar, decidir y generar confianza.

Klarna, la entidad financiera de origen sueco, nos dejó una lección de esas que escuecen. En 2024 celebraba que su asistente de IA atendía dos tercios de las conversaciones con sus clientes, con un trabajo equivalente al de 700 agentes. Un año después, su CEO reconoció que priorizar el ahorro había perjudicado la calidad y anunció más atención humana. Porque resolver un caso no siempre significa cuidar una relación.

La oportunidad está en construir organizaciones híbridas: agentes que buscan información, preparan decisiones y ejecutan tareas de la mano de personas que aportan criterio, empatía y responsabilidad. Pero cuidado, esos agentes serán tan diferenciales como el conocimiento propio que los alimente. Si trabajan solo con un modelo genérico, tu competencia tendrá esa misma inteligencia a un clic de distancia. La ventaja aparecerá al conectar la IA con la experiencia de tus profesionales, el contexto de tus clientes y lo aprendido en miles de decisiones. Eso sí es dar superpoderes a un gestor.

Y nada de soltar un ejército de agentes y cruzar los dedos. Esta nueva fuerza de trabajo necesita gobierno: permisos, límites, trazabilidad, supervisión y responsables claros. Se puede empezar por un proceso concreto, medir calidad y hacer que el conocimiento crezca con cada interacción. Podrás poner la IA más avanzada del mundo al volante, pero si no aprovecha lo que solo tu banco sabe ni mantiene a las personas al mando, no estás construyendo banca cognitiva. Estarás poniendo tu banco en piloto automático.

Una nueva oportunidad cognitiva

Después de estas cinco sacudidas, sería fácil reducir todo esto a una nueva arquitectura tecnológica llena de cajas, flechas y siglas. Y sí, habrá que hablar de APIs y patrones de integración para conectar ecosistemas, de protocolos como A2A para que los agentes colaboren, de grafos de conocimiento y capas semánticas para que los datos tengan sentido y de seguridad y gobierno para que todo funcione con garantías. Pero cuidado: tener todas las piezas tecnológicas no significa haber entendido qué partida queremos ganar.

El verdadero reto es bastante menos vistoso que una buena demo. El conocimiento de una entidad está repartido entre sistemas transaccionales, CRM, herramientas de riesgo, documentos, decisiones históricas y, sobre todo, personas que llevan años entendiendo el negocio. Conectarlo, estructurarlo y ponerlo a trabajar para que cada gestor, producto o agente pueda tomar mejores decisiones es mucho más difícil que desplegar el último modelo de IA, y también es mucho más valioso.

Por eso, quizá estamos empezando demasiadas conversaciones por el lugar equivocado. En vez de preguntarnos dónde podemos colocar un nuevo agente o qué procesos podemos automatizar, deberíamos hacernos una pregunta bastante más incómoda: ¿qué decisiones importantes de nuestro negocio mejorarían radicalmente si fuéramos capaces de aprovechar todo lo que ya sabemos? Ahí es donde negocio y tecnología deberían empezar a trabajar juntos. No hace falta esperar a tenerlo todo resuelto, podemos empezar por una decisión relevante, conectar el conocimiento necesario, medir el impacto y aprender de cada interacción.

Las canciones de Shakira seguirán sonando y los monoplazas de Fórmula 1 volverán a rugir en Madrid el año que viene. Aparentemente, más de lo mismo. Pero hay algo que habrá cambiado: a todo lo que ya sabían sobre sus públicos se sumará lo aprendido en cada concierto, cada carrera y cada experiencia. Y, si saben aprovecharlo, la próxima edición no empezará de cero, empezará sabiendo más.

Con la banca estoy convencido que sucederá lo mismo. Seguiremos financiando proyectos, gestionando ahorros y evaluando riesgos. Pero cada interacción, cada decisión y cada resultado enriquecerá ese patrimonio de conocimiento, permitiéndonos comprender mejor a nuestros clientes y ofrecerles experiencias cada vez más relevantes.

Los modelos de IA estarán al alcance de todo el mundo, pero lo que una organización aprende con cada decisión no se descarga de ningún marketplace. En Paradigma creemos que ahí está la verdadera oportunidad: convertir el conocimiento acumulado durante décadas en un capital cognitivo que no deje de crecer y que nos permita construir, cada día, una nueva ventaja competitiva. Una nueva ventaja cognitiva.

Desechar la generación de texto libre para poner foco en el determinismo probabilístico cambia por completo las reglas del juego en la arquitectura corporativa. Esa es exactamente la premisa de Jev, el nuevo modelo "System One" que TypeSafe AI presenta el 15 de septiembre de 2026, una IA que abandona por completo la redacción de texto para centrarse en evaluar información en paralelo y devolver decisiones estrictamente tipadas en milisegundos.

Si ya sabes lo que es un LLM y te cansa usar un motor de razonamiento costoso para tareas de lógica condicional, este es el contexto que necesitas para entender cómo optimizar tus automatizaciones.

¿Por qué seguimos forzando a los LLMs a estructurar datos?

Pedirle a una red generativa que devuelva un objeto estructurado es usar un cañón para matar moscas. Las arquitecturas autorregresivas calculan el próximo token basándose en un historial secuencial de palabras previas. Si intentamos automatizar el enrutamiento de peticiones de soporte hacia nuestra base de datos, solemos instruir al modelo con reglas kilométricas pidiendo que respete las comillas del JSON y no añada ruido. Terminamos construyendo analizadores sintácticos muy frágiles, que intentan interpretar respuestas algorítmicas totalmente impredecibles.

Cuando el modelo falla al cerrar una etiqueta, el sistema entra en un bucle sin fin de reintentos. Reaccionar frente a este tipo de fallos de formato rompe cualquier flujo transaccional. Hablamos de latencias de inferencia que escalan desde los tres hasta los trescientos segundos de espera. Ninguna plataforma comercial asumiría mantener al usuario esperando medio minuto para ejecutar una lógica condicional sencilla. Este enfoque convierte la capa analítica de la empresa en una caja negra.

¿Cuándo utilizar a Jev y cuándo a tu LLM clásico?

La teoría psicológica de Kahneman define un pensamiento intuitivo rápido frente a un razonamiento deliberado lento. El modelo Jev de TypeSafe AI materializa este concepto eliminando la capacidad neuronal de generar lenguaje. Esta arquitectura evalúa los estados de entrada frente a un esquema estático utilizando muestreos en paralelo. Entender esta división taxonómica permite diseñar sistemas compuestos mucho más ágiles.

Veamos exactamente dónde brilla Jev y dónde fracasa frente a un motor generativo tradicional.

• Para el enrutamiento de tickets masivos o el triaje, Jev es la opción ganadora. Los sistemas de soporte corporativo reciben información desordenada donde los equipos de análisis de texto fallan estrepitosamente y resultan demasiado lentos. Enviar un mensaje sobre un cobro duplicado y pedirle al algoritmo que evalúe la urgencia devuelve una clasificación tipada exacta en milisegundos. Utilizar aquí un modelo de frontera generativo sería despilfarrar presupuesto de computación.
• El control robótico de interfaces (RPA) y los agentes web requieren decisiones iterativas instantáneas. Experimentos de la comunidad integrando a Jev en proyectos de navegación autónoma demuestran ciclos completos de reserva de vuelos en unos siete segundos. La latencia operativa mediana cae hasta la franja de los 150 milisegundos, permitiendo coordinar bucles de reactividad donde un modelo clásico provocaría el colapso del sistema.
• El procesamiento de Big Data exige este tipo de arquitecturas por motivos estrictamente económicos. Emplear una red autorregresiva tradicional para llevar a cabo esta tarea requeriría horas de procesamiento y la revisión posterior de miles de registros JSON vulnerables a errores tipográficos.

Existen escenarios donde desplegar Jev carece totalmente de sentido por su propia ceguera estructural.

• Si necesitas redactar un resumen, participar en un hilo conversacional o escribir código fuente base, este sistema resulta computacionalmente inútil. Carece de la fase de decodificación iterativa necesaria para articular un discurso textual. Aquí sí necesitas utilizar un modelo generativo y dejarle razonar.
• Las industrias reguladas que exigen explicabilidad analítica enfrentan un bloqueo similar. Cuando deniegas una póliza de seguros o rechazas una solicitud de crédito, un organismo auditor exigirá un razonamiento trazable redactado en lenguaje natural. Jev devuelve porcentajes matemáticos de confianza sin argumentar el motivo de su elección. Para cumplir con normativas estrictas de transparencia financiera, necesitarás ineludiblemente la argumentación de un LLM.

¿Cómo cambia esto nuestra forma de diseñar infraestructuras?

Dejar atrás el infierno operativo de las integraciones exige repensar el diseño de nuestra infraestructura. En lugar de darle tanto peso y dedicar tantos esfuerzos en la parte de prompting, ahora necesitarás parametrizar esquemas estrictos de decisión.

El equipo de backend ya no interactúa con un generador de caracteres. Operar bajo un modelo de muestreo paralelo requiere configurar evaluaciones binarias que el motor resolverá sin emitir palabras. La declaración del esquema nos demuestra un determinismo técnico que retira de producción las costosas rutinas de validación sintáctica de cadenas de texto.

Eso sí, tienes que contemplar ciertas limitaciones del diseño original. El presupuesto de memoria contextual maneja un límite de 64.000 tokens en cada llamada y la arquitectura no acepta imágenes de forma nativa.

Conclusiones

Mantener arquitecturas monolíticas que intentan resolver todo tipo de casuísticas penaliza seriamente la competitividad comercial. Hemos forzado a LLMs a comportarse como simples enrutadores pagando facturas inasumibles.

Incorporar arquitecturas como la de Jev dentro de nuestro pipeline ayuda a disminuir estos costes, aporta una mayor veracidad en las respuestas, elimina prácticamente a cero las alucinaciones, y reduce los tiempos de despliegue.

Referencias

• Jev System One Model by TypeSafe - AY Automate
• A deep dive into Jev, TypeSafe's System One model - Flavio Copes
• What Is Jev? A Guide to TypeSafe AI's System One Model - LangChain
• TypeSafe AI's Jev: What "System One Models" Actually Are

En este contexto, la tecnología y el dato han dejado de ser solo herramientas de soporte para convertirse en piezas estratégicas del negocio.

En este episodio entrevistamos a Sergio Peinado, CIO de Ontime, y con él hablamos de todos estos retos y de cómo se está preparando el sector logístico para los próximos años.

La tecnología ya no es solo un área de soporte

Durante años, el departamento de tecnología recibía las decisiones del negocio y se encargaba de ejecutarlas. Ese modelo está cambiando.

En compañías donde la tecnología tiene un papel estratégico, los equipos tecnológicos participan cada vez más en la definición de los propios procesos y en la toma de decisiones.

La clave está en entender primero qué necesita el negocio y, a partir de ahí, decidir qué tecnología puede aportar valor. No se trata de incorporar inteligencia artificial porque sea una tendencia, ni de migrar sistemas a la nube simplemente porque sea una prioridad tecnológica. La pregunta debe ser siempre qué problema se quiere resolver y qué beneficio aporta la solución.

Esta evolución requiere perfiles capaces de moverse entre ambos mundos. Personas que entiendan las necesidades del negocio y, al mismo tiempo, conozcan las posibilidades que ofrece la tecnología para responder a ellas.

En este modelo, figuras como los Business Relationship Managers adquieren especial importancia. Su función es actuar como puente entre tecnología y negocio, entender las necesidades de cada área y traducirlas en soluciones tecnológicas viables.

La tecnología deja así de ser un mero ejecutor para convertirse en un socio estratégico del negocio.

El reto de convertir millones de datos en decisiones

La logística genera una cantidad enorme de información. Vehículos, remolques, almacenes, sensores, sistemas de gestión, plataformas financieras o herramientas comerciales producen datos continuamente. El reto no consiste únicamente en recopilar toda esa información, sino en convertirla en un dato único, fiable y accionable.

En operaciones de transporte, por ejemplo, conocer en tiempo real dónde se encuentra cada vehículo, cuál es su disponibilidad o qué conductor está asociado permite tomar decisiones mucho más precisas.

Una nueva carga puede asignarse al vehículo más adecuado teniendo en cuenta factores como la proximidad, la disponibilidad o la posibilidad de reducir los kilómetros recorridos en vacío.

Precisamente, este último aspecto resulta especialmente relevante en un negocio con márgenes tan ajustados. Una pequeña mejora en la utilización de los vehículos puede tener un impacto significativo cuando se multiplica por miles de desplazamientos.

Para conseguirlo, es necesario construir una verdadera estrategia de datos. No basta con disponer de diferentes sistemas y generar informes, es necesario establecer quién es responsable de cada dato, cuál es su calidad, cómo se genera y qué indicadores deben utilizarse para tomar decisiones.

Un Data Lake que centralice y haga trazable la información permite, además, acabar con uno de los problemas habituales en las empresas: que diferentes áreas trabajen con versiones distintas de la realidad. Cuando negocio, operaciones y finanzas manejan datos diferentes, buena parte del tiempo se acaba dedicando a discutir qué cifra es correcta en lugar de utilizarla para decidir.

Y esta cuestión es especialmente importante ahora que la inteligencia artificial empieza a ocupar un lugar central. Sin datos de calidad, la IA no puede ofrecer resultados de calidad.

Inteligencia artificial: menos ruido y más casos de uso

La inteligencia artificial está abriendo nuevas posibilidades en el sector logístico, pero su valor no está necesariamente en los proyectos más espectaculares. En muchos casos, el impacto aparece en procesos cotidianos y muy concretos.

Uno de los primeros ámbitos es el de la productividad interna. Herramientas basadas en IA pueden actuar como asistentes para equipos administrativos, ayudándoles a automatizar tareas y aumentando su capacidad de trabajo.

Otro gran ámbito es la relación con el cliente. Cuando una compañía gestiona cientos de miles de envíos, ofrecer una atención personalizada a través de canales tradicionales resulta difícil de escalar.

Los agentes conversacionales permiten atender consultas a través de canales como WhatsApp, correo electrónico o teléfono, acceder a la información disponible sobre cada cliente y ofrecer respuestas más rápidas.

La IA también puede ayudar al propio equipo de atención al cliente. Mientras un agente mantiene una conversación, el sistema puede recuperar información sobre el cliente, su historial y posibles respuestas, proporcionando contexto en tiempo real y reduciendo el trabajo manual.

Pero quizá uno de los campos con mayor potencial sea el de la predicción y optimización de las operaciones. La IA puede ayudar a determinar qué vehículo y qué conductor son más adecuados para una determinada carga, predecir la demanda o automatizar procesos como la concertación de entregas.

En el caso de las entregas voluminosas, por ejemplo, la concertación de una cita con el cliente puede realizarse mediante IA sin necesidad de intervención humana. El sistema puede contactar con el destinatario, acordar una hora y registrar la información necesaria para continuar con el proceso.

Y hay una idea especialmente importante detrás de estos ejemplos: la IA no tiene por qué trabajar sola. Puede combinarse con tecnologías más tradicionales, como RPA, para construir procesos automatizados de principio a fin.

La inteligencia artificial puede encargarse de interpretar una llamada o un correo electrónico, extraer la información necesaria y, a continuación, un proceso RPA puede utilizar esos datos para ejecutar las operaciones correspondientes en los sistemas corporativos.

Ciberseguridad en un ecosistema cada vez más conectado

La digitalización también amplía la superficie de ataque. En logística, esto adquiere una dimensión especial por la enorme cantidad de dispositivos conectados que participan en las operaciones.

Vehículos, sensores, almacenes y diferentes sistemas corporativos forman un ecosistema tecnológico que debe estar protegido. Además, las compañías logísticas manejan información de empresas pertenecientes a sectores especialmente sensibles, como banca, seguros, alimentación, industria o telecomunicaciones.

Por eso, la ciberseguridad deja de ser únicamente una cuestión interna para convertirse también en una responsabilidad dentro de la cadena de suministro. Una compañía logística puede no ser el objetivo final de un ataque, pero sí convertirse en una posible puerta de entrada hacia otros actores.

La inversión en seguridad, certificaciones y controles se convierte así en un elemento estratégico para poder trabajar con clientes cada vez más exigentes y operar en entornos críticos.

El siguiente gran salto: los vehículos autónomos

Si la automatización y la inteligencia artificial ya están transformando las operaciones actuales, el siguiente gran cambio podría llegar de la mano de los vehículos autónomos.

La tecnología necesaria ya existe en buena medida. El principal obstáculo no es únicamente técnico, sino también regulatorio. La llegada de vehículos capaces de operar sin conductor tendría implicaciones importantes para el transporte de mercancías, especialmente en un sector que afronta además un problema creciente de disponibilidad de profesionales.

Su impacto podría ir mucho más allá de sustituir determinadas tareas. Los vehículos autónomos podrían permitir crear nuevas formas de distribución urbana, realizar determinadas rutas durante la noche y reducir parte de la congestión asociada al transporte de mercancías en las grandes ciudades.

Un posible escenario sería el de vehículos autónomos que circulasen durante la noche y fueran capaces de realizar operaciones en puntos de recogida o lockers sin intervención humana. La combinación de autonomía, datos e inteligencia artificial podría cambiar radicalmente la forma en la que se mueve la mercancía dentro de las ciudades.

Eso sí, para que ese futuro sea viable será necesario resolver cuestiones regulatorias, de seguridad y de convivencia con el resto de usuarios de las vías.

Tecnología con propósito

La transformación tecnológica del sector logístico no pasa por adoptar cada nueva tecnología que aparece en el mercado. Pasa por entender dónde puede aportar valor y cómo puede ayudar a resolver problemas reales.

La inteligencia artificial, el cloud, los datos, la automatización o los vehículos autónomos son herramientas. El verdadero reto para los responsables tecnológicos consiste en conectarlas con la estrategia de negocio y utilizarlas para conseguir objetivos concretos.

Entre ellos hay una generación que no recuerda un mundo sin móvil: pide la cena desde una app, ve la serie que le recomienda una plataforma antes de buscarla y no ha pisado una oficina bancaria en su vida.

Para ellos, que un servicio funcione solo, recuerde quién es y no le obligue a repetir tres veces el mismo proceso, no es un lujo, es lo normal.

La competencia ya no es la universidad de al lado, son plataformas como Amazon o Netflix

Durante años, una universidad se comparaba en experiencia con otras universidades. Esa comparación se acabó. Hoy el alumno mide a su universidad con la misma vara con la que mide Netflix, Amazon o la app de su banco: servicios que le conocen, anticipan lo que necesita y le resuelven sin fricción.

Es una comparación injusta (nadie espera que una universidad funcione como una empresa de streaming), pero es la que hace y la que manda. Y cuando la experiencia digital no está a ese nivel, el alumno piensa que la universidad no funciona. Y a veces lo dice donde más duele: en la encuesta de satisfacción o en la conversación con el amigo que está decidiendo dónde matricularse el año que viene.

Por eso, la experiencia digital ha dejado de ser un asunto interno de sistemas para convertirse en un asunto de atracción y de permanencia.

Cuatro sistemas para una sola gestión

Sigamos al alumno. Para consultar una nota, pagar un recibo o pedir un certificado pasa del sistema de gestión académica al aula virtual, de ahí a la sede electrónica, y a veces al CRM que le escribió cuando aún era candidato.

Cada uno con su dirección, su aspecto y su acceso. Cada uno preguntándole quién es, como si no acabara de decírselo al anterior. Nadie lo diseñó así, cada sistema se compró en su momento para resolver un problema concreto, y lo resuelve.

Lo que no se diseñó es cómo iban a hablar entre ellos. Y el que acaba haciendo de enlace entre unos y otros es el alumno.

Desde dentro, sin embargo, no siempre se percibe así. Tres de cada cuatro universidades consideran que su nivel de transformación digital es adecuado y equiparable al de otros sectores (Fundación CYD, 2023).

Y no por falta de esfuerzo: se ha invertido mucho, pero sobre todo en lo que se ve (conectividad, aulas equipadas, pantallas...). Como resume el informe Espacios de Educación Superior 2025, se ha avanzado en infraestructura, pero no se ha repensado el modelo.

Por qué una app nueva no arregla esto

Cuando la experiencia falla, la respuesta natural es una app mejor. Tiene lógica: la app es lo que se ve y lo que recibe las quejas. Pero la app es solo la capa de experiencia y no se sostiene sola.

Si por debajo el sistema académico, el aula virtual, el CRM y la sede no comparten datos ni identidad, la app nueva los reúne en la pantalla sin unirlos de verdad: muchas veces, cada servicio aparece como la ventana de otro sistema metida dentro de la app.

El alumno lo nota enseguida: cambia el aspecto, pero sigue identificándose otra vez, sigue sin encontrar sus cosas en el mismo sitio y sigue saliendo a otro sistema a mitad de un trámite.

Se puede rediseñar la pantalla muchas veces, pero si el trámite sigue pasando por cuatro sistemas que no se conocen, la experiencia seguirá rota. Es la diferencia entre repintar la fachada y arreglar la instalación que hay detrás de la pared.

Cinco señales de que el problema no está en la pantalla

Estas cinco señales no hablan de arquitectura ni de tecnología: hablan de lo que pasa en un curso normal. Si reconoces varias, el problema no está en la superficie:

1. El alumno escribe el mismo dato más de una vez a lo largo del curso, en sistemas distintos, porque unos no saben lo que ya guardaron otros.
2. Un trámite habitual obliga a salir de la app y entrar en otro sitio, con otro login, para poder terminarlo.
3. Cambiar algo de la plataforma depende de un tercero: de sus plazos, sus prioridades y su presupuesto, no de los tuyos.
4. Nadie tiene, en una sola pantalla, la foto completa de un alumno: admisiones, secretaría y el equipo docente ven piezas distintas de la misma persona.
5. La última mejora digital fue una app o un rediseño, no un cambio en cómo se conectan los sistemas por debajo.

Ninguna de estas señales, por sí sola, es grave. El problema es cuando se juntan, porque entonces dejan de ser incidencias sueltas y pasan a ser el mismo síntoma repetido: la distancia entre lo que un alumno da por hecho y lo que se encuentra.

La urgencia no está en quien llega hoy

Entonces, llegan a la universidad y quieren consultar el horario, pedir una beca, reservar una sala de estudio… Y que el proceso sea sencillo, rápido y eficaz.

Los nacidos a partir de 2013 (la llamada Generación Alfa), empezarán a llegar a la universidad hacia 2031. Para la Z, una experiencia fragmentada es una decepción; para la Alfa, que no habrá conocido otra cosa, será un defecto.

Cinco años parecen mucho. No lo son para esta decisión: una plataforma académica no se cambia cada dos años. Se elige, se implanta y se arrastra una década.

La decisión de ecosistema que una universidad tome este año es la que recibirá a esos alumnos. Hoy no se decide cómo atender a quien está en el aula: se decide cómo atender a quien todavía está en primaria.