Integrar IA no es lo mismo que ser AI-Native. La mayoría de las organizaciones lleva meses añadiendo capas de inteligencia artificial sobre procesos, estructuras y arquitecturas que no han cambiado en absoluto. El resultado es más velocidad sobre los mismos cimientos, cuando los mismos cimientos son el problema. Este artículo, no es una declaración sobre eficiencia; es una declaración sobre dónde está el valor cuando la ejecución deja de ser un problema.
Blockbuster no quebró por hacer las cosas mal. Quebró por hacer demasiado bien algo que había dejado de importar. Nokia tampoco era incompetente. Optimizaba con brillantez un modelo que el mercado ya había abandonado. Son los casos de libro sobre disrupción que todo el mundo conoce y casi nadie aplica a sí mismo. Víctor Guillán los trae al escenario del Product & Tech Leadership Summit Madrid 2026 no como historia, sino como espejo: entramos en una fase donde la competencia histórica de una organización puede ser exactamente su mayor vulnerabilidad.
General Partner y CTO en The Lab Ventures, Víctor Guillán es de los pocos perfiles que combina la visión del inversor con la del Product Builder. En el Summit presentó tres tesis que, tomadas en conjunto, dibujan con bastante precisión un mapa de dónde está la mayoría de las organizaciones y a dónde necesitan llegar.
Tesis 1: El producto AI-Native no es una versión mejorada del producto que ya tienes
Durante años, el software empresarial ha funcionado como un sistema de registro: captura lo que ocurre, almacena el estado actual, genera informes. Pero pierde lo más importante: el porqué.
Esa pérdida de contexto, que siempre ha existido, se vuelve crítica en el momento en que los agentes de IA tienen que operar sobre esa base. Un agente no puede proponer la siguiente mejor acción si solo tiene acceso a snapshots de estado. Necesita trazas de decisión: el razonamiento, las aprobaciones, la lógica detrás de cada movimiento. La diferencia entre un sistema de registro y un sistema de inteligencia no es la cantidad de datos, es la calidad del contexto que preserva.
Dharmesh Shah lo llama "system of record for decisions". Aaron Levie habla de "the era of context". Víctor lo aterriza de forma más directa: "los productos que no capturen el porqué detrás de cada acción serán reemplazables. Los que lo hagan construirán una ventaja competitiva que no se copia de la noche a la mañana."
La implicación para los equipos de producto es más profunda de lo que parece: la infraestructura deja de ser algo que ocurre entre bastidores y se convierte en parte del producto mismo. En un producto AI-Native, decisiones como: qué modelo de IA responde en cada momento, cómo evalúa el sistema si la respuesta fue correcta, o qué información se le pasa como contexto son decisiones de producto, no de ingeniería delegada. Si esas piezas fallan o están mal diseñadas, el usuario lo nota de inmediato.
Dicho de otra forma: ya no vale con que producto diseñe la experiencia y delegue lo técnico. Cuando la IA es el corazón del producto, entender cómo funciona ese corazón es trabajo de cualquiera que tome decisiones sobre él.
La distinción que más se malinterpreta
Poner un copiloto encima de un proceso existente, añadir un chatbot a un CRM o integrar generación de contenido en un flujo de marketing; todo eso es IA integrada. Y funciona, en el sentido de que mejora la eficiencia sobre lo que ya había.
El problema es que no cambia nada estructural. Es como poner un GPS en un carruaje de caballos después de que llegaron los coches. El GPS mejora la experiencia de ir en carruaje, pero no resuelve que el carruaje ya no es el vehículo correcto.
Un producto AI-Native no añade inteligencia encima de una arquitectura existente. La reconstruye en torno a ella. Y esa diferencia se manifiesta en tres cosas muy concretas:
-
El contexto fluye entre sistemas en lugar de perderse entre aplicaciones aisladas.
-
Los agentes crean trabajo en lugar de limitarse a completarlo.
-
El sistema aprende con el tiempo en lugar de resetear su estado con cada interacción.
El ejemplo es claro: un CRM tradicional sabe que se aprobó un descuento. No captura la lógica que hay detrás porque registra el estado y no el razonamiento. Un CRM AI-Native capturaría la lógica detrás de esa decisión, la preservaría como contexto para decisiones futuras y propondría activamente la siguiente acción al comercial basándose en patrones acumulados.
El primero ayuda. El segundo transforma.
Tesis 2: El bloqueo no es tecnológico. Es organizacional.
Si el primer error es técnico, el segundo es organizacional. Y es el más difícil de corregir porque requiere tocar algo que las organizaciones protegen por encima de casi todo: su estructura.
La tecnología ya existe. Está disponible, es accesible y mejora cada semana. Lo que no existe todavía en la mayoría de las organizaciones es el rediseño de procesos, estructuras y flujos de trabajo que permita que esa tecnología funcione de forma sistémica. Las empresas están llenas de individuos que usan IA — a veces muy bien — pero los procesos, los flujos de trabajo y las estructuras no se han rediseñado en torno a ella. El conocimiento se queda en la persona, pero no se acumula en la organización.
Víctor describe este gap con un modelo de madurez de tres etapas:
1. Cada persona usa la IA a su manera, sin contexto compartido, con una variación de adopción de hasta 10 veces entre distintos miembros del mismo equipo.
2. Los prompts, flujos y habilidades se comparten a nivel de equipo; el conocimiento empieza a acumularse institucionalmente.
3. La IA opera como sistema operativo de la empresa: flujos estandarizados e inteligencia institucional que trasciende a cualquier individuo.
La mayoría de las organizaciones están atascadas en la etapa 1. Y el salto a la etapa 2 es donde empieza la ventaja competitiva real.
Lo que eso implica en términos de estructura es radical. Las nueve funciones típicas de una empresa de producto digital (ingeniería, producto, diseño, ventas, marketing, CX, finanzas, RRHH, legal) tienden en este modelo hacia tres mega-funciones: I+D, GTM y G&A. Los roles humanos que permanecen dentro de cada una son más senior, más transversales y más responsables. Los agentes cubren el razonamiento y la acción. El ratio experto-generalista, que hoy está en torno a 1:6, se encamina hacia 1:25 y en algunos contextos hacia 1:100.
PM e ingeniería convergen hacia el mismo perfil. El Product Builder que combina pensamiento de UX, criterio de negocio y capacidad de orquestación de agentes, no es una especialización nueva. Es la fusión de dos roles que siempre debieron estar más cerca y que la era de los agentes termina de colapsar.
Hay una advertencia que merece especial atención: quienes más saben de IA no siempre son los más indicados para liderar este cambio. La maldición del conocimiento puede dificultar ver con claridad qué necesita cambiar en la organización.
Tesis 3: Estás construyendo la fábrica que construye tu software
La tercera tesis es la más técnica y, en cierto sentido, la más inmediata. Porque el cambio en cómo se desarrolla software ya está ocurriendo.
El modelo tradicional de desarrollo (SDLC) funciona sobre una lógica secuencial: planificación cerrada, código, QA después del diseño, despliegue. Cada fase espera a que termine la anterior. El cuello de botella es el ritmo humano.
Con agentes, esa lógica se rompe. Los agentes escriben, refactorizan y prueban código en paralelo. Los objetivos evolucionan dinámicamente y los bucles de feedback son en tiempo real. Víctor lo llama ADLC (Agentic Development Life Cycle) y lo sitúa como el mayor cambio en desarrollo de software desde la interfaz gráfica.
El desarrollador deja de ser el ejecutor y pasa a ser el diseñador de la fábrica que construye el software. Ya no trabaja con una IA de apoyo, orquesta un sistema de agentes. La transición es de un modelo de 1 IA más 1 desarrollador, secuencial y síncrono, a varios agentes más 1 orquestador, en paralelo y asíncrono.
Y aquí aparece el giro más relevante. El cuello de botella ya no es la generación, si no la verificación.
A esto se suma el giro 80/20, quizás el concepto más malinterpretado de todo el ciclo de vida de un producto con IA. En software tradicional, el 80% del esfuerzo ocurre antes del lanzamiento. En sistemas de IA, ocurre al revés. Las organizaciones que planifican IA como si fuera software tradicional — invierten en construir, celebran el lanzamiento y dan el trabajo por terminado — se llevan la sorpresa después. Los primeros 30 a 60 días post-despliegue son una fase de calibración, no de mantenimiento rutinario.
Lo que escasea no es la capacidad computacional
Víctor cierra su charla con algo que resume todo lo anterior: la cuestión no es si la IA transformará tu organización. Es a quién mantienes y qué construyes a su alrededor.
Tener acceso a agentes potentes no genera ventaja por sí mismo. Un ejército de agentes de IA en manos de alguien sin criterio no crea un producto ni transforma una empresa. El criterio, el pensamiento estratégico, el gusto; eso es lo que escasea. Y escasea más que nunca precisamente porque la capacidad de generar se ha democratizado.
Geoff Charles, CPO de Ramp, una de las organizaciones de producto más AI-Native del mundo, lo formula sin rodeos: "Mi trabajo es automatizar mi trabajo. Ese es el trabajo de todos a partir de ahora."
No es una declaración sobre eficiencia. Es una declaración sobre dónde está el valor cuando la ejecución deja de ser problema.
¿Ya has integrado IA en tu producto? Descarga el Framework UX para funcionalidades de IA y mide confianza, valor percibido y adopción post-lanzamiento.
.jpg)
