Cuando todos
tengan IA,
¿dónde estará
la ventaja?

Hay dos maneras igualmente pobres de leer una publicación sobre el futuro: creerla porque parece venir de alguien bien conectado o descartarla porque no es un artículo científico. Una conversación informal puede detectar algo que todavía no aparece en una estadística. También puede sobrerrepresentar una burbuja, una moda o los intereses de quien la cuenta. Lo útil es reconocer qué clase de información tenemos delante.

El texto público de Isenberg confirma el carácter del material: son impresiones de conversaciones con fundadores y ejecutivos, acompañadas de sus propias interpretaciones. Es una fuente primaria de lo que él afirma haber observado, no una verificación independiente de los ingresos o del desempeño de las empresas mencionadas. Esa diferencia debe mantenerse incluso cuando la idea resulte convincente. [1]

De la observación a una hipótesis que se pueda probar

Una observación describe algo percibido: varios equipos hablan de problemas con sus datos. Una hipótesis propone una explicación o una relación comprobable: la mala calidad de los datos limita el rendimiento de los agentes. Un insight es una comprensión que cambia nuestra interpretación o una decisión: antes de comprar otra herramienta, quizá debamos examinar la información con la que trabajará. Llamarlo insight no lo vuelve verdadero; su utilidad y su evidencia son preguntas distintas.

Que una hipótesis sea plausible significa que existe un mecanismo razonable por el que podría ocurrir y que no contradice la evidencia disponible. No significa que sea probable en un porcentaje conocido, que sucederá pronto ni que ya esté validada. Decir que un negocio puede ganar ventaja con datos mejor organizados es plausible. Afirmar cuánto ganará y en qué fecha exige bastante más.

El sesgo del lugar desde el que miramos

Un grupo de emprendedores de San Francisco no representa a todas las empresas de Estados Unidos, menos aún a las de Quito o América Latina. Hay selección del entorno, selección de las historias que se cuentan y selección de las historias que se publican. Además, una empresa que consiguió crecer puede atribuir su éxito a una herramienta, aunque también hayan influido su capital, sus contactos o un canal de distribución previo.

Por eso, en esta lectura separaremos documentación de capacidades, resultados de estudios concretos y propuestas estratégicas propias. También conservaremos un registro de las afirmaciones que no podemos dar por demostradas. La finalidad no es apagar la curiosidad, sino impedir que el entusiasmo se convierta en una decisión costosa sin pasar por una prueba.

Imagina que mañana aparece un modelo que cuesta menos y resuelve mejor la tarea central de tu producto. ¿Tu negocio mejora porque ahora puede servir mejor al cliente, o empeora porque el cliente ya no necesita tu producto? Esa pregunta, inspirada en las observaciones originales, obliga a distinguir entre aprovechar la IA y depender de que la IA todavía tenga limitaciones.

Pensemos en dos servicios hipotéticos. El primero cobra por convertir una instrucción sencilla en un texto genérico. El segundo ayuda a una empresa a responder solicitudes complejas: consulta información autorizada, verifica condiciones, prepara una propuesta y deja trazabilidad para que alguien la apruebe. Una mejora del modelo podría sustituir gran parte del primer servicio y, al mismo tiempo, mejorar el segundo. Pero esa diferencia no está garantizada: una plataforma también podría integrar las funciones del segundo.

La arquitectura tampoco es inmune a quedar obsoleta

Sería un error reemplazar el dogma de «el modelo lo es todo» por el de «el modelo no importa». Anthropic ha documentado cómo decisiones de diseño de un entorno de agentes, útiles para una generación de modelos, pueden resultar innecesarias o perjudiciales para otra. Su explicación de Managed Agents enfatiza separar componentes para poder modificarlos. Es una experiencia de ingeniería, no una prueba de que una determinada empresa vaya a ganar el mercado. [3]

Nuestra inferencia es que una ventaja más defendible no consiste en acumular complejidad alrededor de un modelo. Consiste en resolver una necesidad importante y mantener la capacidad de reorganizar la solución. Algunas piezas deberían ser fáciles de sustituir; otras merecen acumular aprendizaje: el conocimiento del proceso, las evaluaciones del trabajo, las relaciones comerciales y las decisiones documentadas.

Una prueba práctica de dependencia

Describe qué compra realmente tu cliente sin mencionar el nombre de ninguna herramienta. Después pregunta qué parte de ese resultado podría obtener directamente de una plataforma generalista y qué parte depende de información, integración o criterio que esa plataforma no tiene. Finalmente, identifica cuánto costaría cambiar de proveedor de IA sin perder calidad, historial ni control.

Intercambiar modelos no es cambiar una marca en un menú. Puede requerir adaptar instrucciones, formatos, herramientas y límites de contexto, y repetir las pruebas. La portabilidad tiene un costo. Su valor aparece cuando reduce una dependencia importante; no cuando añade varias integraciones que casi nunca se utilizan.

La decisión estratégica, por tanto, no es «construir siempre» o «comprar siempre». Es elegir qué capacidad conviene poseer, qué componente conviene contratar y qué dependencia conviene poder abandonar. Un negocio pequeño puede tener una arquitectura sólida sin desarrollar su propio modelo ni una plataforma gigantesca.

Un modelo puede redactar una respuesta. Un sistema puede utilizarla para hacer algo. Esa transición parece pequeña cuando se observa una demostración, pero cambia por completo el diseño del trabajo. Ya no basta con preguntar si el texto es bueno: importa qué información utilizó, qué acción ejecutó, bajo qué permisos y cómo sabemos que terminó correctamente.

Anthropic distingue entre flujos de trabajo, donde el recorrido está definido por código, y agentes, donde el modelo decide dinámicamente parte del recorrido y el uso de herramientas. También recomienda empezar por la solución más simple que resuelva la tarea, porque la autonomía añade costos, latencia y posibilidades de error. No todas las automatizaciones necesitan convertirse en agentes. [2]

Qué es el harness, explicado sin misterio

La palabra inglesa harness puede traducirse como arnés, pero aquí resulta más claro hablar del entorno de ejecución y control. Es el conjunto de mecanismos que conecta el modelo con herramientas, estado de la tarea, contexto, restricciones y recuperación. La metáfora «modelo como procesador y harness como sistema operativo» ayuda a imaginar capas. No debe tomarse como una equivalencia técnica exacta.

En nuestro esquema de trabajo hay tres niveles. En el nivel del objeto está la tarea concreta: preparar una cotización. En el nivel del sistema están el catálogo, el inventario, los datos del cliente y el proceso de revisión. En el nivel del gobierno se decide quién puede autorizar un descuento, qué se registra y quién responde si algo sale mal. Optimizar el primer nivel ignorando los otros dos produce una demostración atractiva y una operación frágil.

MCP conecta; no ordena la empresa por ti

El Model Context Protocol es un estándar abierto para conectar aplicaciones de IA con fuentes de información y herramientas. Su documentación describe esa función de integración. [4] De ello no se deduce que los datos conectados sean correctos, que el usuario esté autorizado a todo o que sea necesario mover cada archivo a una única base de datos.

Una empresa puede mantener sus sistemas separados y ofrecer accesos delimitados. La unidad que importa es la del significado y las reglas: saber qué registro es válido, qué operación se permite y cómo se verifica. Un conector es una puerta. No es, por sí solo, el inventario de la casa, el reglamento ni la cerradura.

El criterio de diseño es sencillo: usa reglas explícitas cuando ya conoces la respuesta que debe dar el sistema; reserva la flexibilidad del modelo para la interpretación y las situaciones donde aporte valor. Más autonomía no es necesariamente mejor arquitectura.

La idea de que el valor se desplaza del software hacia los datos resulta atractiva. Tiene una parte razonable: copiar una interfaz no copia necesariamente años de información operativa ni el conocimiento de cómo utilizarla. Pero también puede conducir a una nueva forma de acumulación: conservarlo todo esperando que algún día alguien lo compre.

Para una pequeña empresa, proponemos una prueba menos espectacular y más útil. Un dato merece atención cuando puede mejorar una decisión o una acción. No basta con tener el teléfono de un cliente; importa saber si desea recibir comunicaciones, qué solicitó, qué se le ofreció y qué ocurrió después. Tampoco basta con registrar una venta; puede ser necesario distinguir el ingreso del margen, la reserva del pago y el pedido del despacho.

El problema suele empezar en las definiciones

Imagina que ventas llama «cliente activo» a quien escribió este mes, administración a quien tiene una factura pendiente y dirección a quien compró en el trimestre. Ninguno de esos usos es necesariamente absurdo, pero mezclarlos en un indicador produce una conclusión confusa. Un modelo puede explicar con elegancia un número cuyo significado nadie acordó.

En un piloto, revisaríamos cinco condiciones: procedencia conocida, significado compartido, actualización suficiente, permiso de uso y relación con una decisión. No son una fórmula de valoración financiera. Son criterios para evitar que una integración convierta errores dispersos en respuestas rápidas y convincentes.

Ordenar no significa construir un proyecto interminable

No proponemos limpiar toda la organización antes de hacer una prueba. Es preferible seleccionar un proceso importante y preparar el conjunto mínimo de datos que necesita. Por ejemplo: catálogo vigente, estado de inventario, condiciones comerciales y responsable de aprobación. El resto puede incorporarse cuando la aplicación demuestre utilidad.

Ese enfoque introduce una disciplina económica: el costo de preparar un dato debe compararse con su valor para una decisión. Si un campo se registra durante meses y nadie lo consulta, quizá esté mal definido o no sea necesario. Si una variable explica repetidamente un error caro, su calidad merece prioridad.

Poseer información no equivale a poder venderla

Las historias sobre licenciar correos, conversaciones o código de una empresa cerrada no deben convertirse en una recomendación de negocio automática. Antes de reutilizar cualquier conjunto se necesita revisar derechos, contratos, confidencialidad y protección de datos. Tampoco debe suponerse que quitar nombres vuelve irreidentificable la información. El análisis jurídico depende del contenido, la finalidad y la jurisdicción; para Ecuador, la autoridad de referencia es la SPDP. [12]

La oportunidad más cercana puede no ser vender los datos a un laboratorio. Puede ser usarlos legítimamente para dejar de perder oportunidades, mejorar una decisión de inventario o entender por qué los clientes no regresan. Menos espectacular no significa menos valioso.

Repetir el contexto en cada interacción desgasta. Volver a explicar el tono de una marca, una decisión ya tomada o el estado de una tarea interrumpida consume tiempo y aumenta las posibilidades de contradicción. Por eso la memoria resulta una promesa tan convincente. Pero «recordar más» es una medida demasiado pobre para definir una buena memoria empresarial.

Podemos distinguir tres funciones. La memoria de trabajo mantiene el estado de una tarea en curso. La memoria del negocio permite recuperar información autorizada y decisiones vigentes. El aprendizaje del sistema modifica instrucciones, evaluaciones o modelos a partir de evidencia. Están relacionados, pero no son intercambiables: guardar una conversación no significa que el modelo haya aprendido de ella.

En su trabajo sobre agentes de larga duración, Anthropic describe mecanismos para conservar progreso y facilitar que una nueva sesión continúe una tarea. Ese resultado respalda la importancia de gestionar el estado de trabajo, no la idea de una memoria perfecta o de una comprensión completa de la organización. [5]

Un recuerdo equivocado también puede persistir

Supongamos que hace seis meses se aprobó una promoción excepcional. Si el agente la recupera como una política actual, la continuidad se convierte en un error comercial. Por eso proponemos que una memoria operativa conserve, cuando corresponda, fuente, fecha, responsable, vigencia y relación con versiones anteriores. «Se dijo en un chat» no debería bastar para convertir una afirmación en una regla oficial.

Existe además un riesgo de seguridad específico. OWASP documenta que información no confiable puede contaminar memoria o contexto persistente e influir en acciones posteriores. Una instrucción maliciosa no necesita ejecutarse en la primera conversación para causar problemas. [6] Nuestra consecuencia de diseño es separar lo que un agente leyó de aquello que la organización autorizó como instrucción.

Los errores son materia prima, no aprendizaje automático

Un registro de fallos puede ayudar a construir una evaluación mejor. Pero para que sea útil necesitamos entender la tarea, el resultado esperado, el resultado real y la causa probable. También necesitamos poder utilizar legítimamente ese registro. Un archivo de conversaciones sin clasificar no explica por sí mismo qué comportamiento debe cambiar.

La ventaja acumulativa que nos interesa no es una base de datos cada vez mayor. Es una organización capaz de convertir experiencia en mejores reglas, información y pruebas, conservando la posibilidad de corregir, eliminar y transferir lo aprendido.

Si puedes generar veinte propuestas en pocos minutos, el problema deja de ser solamente producir. También necesitas escoger. Y elegir no equivale a preferir la versión que suena mejor. Una propuesta puede ser persuasiva y prometer algo imposible; un informe puede tener una estructura impecable y apoyar su conclusión en datos equivocados.

En este contexto, el «buen gusto» mencionado en las observaciones originales resulta insuficiente como descripción profesional. Lo traduciríamos como la capacidad de reconocer calidad relevante para un propósito y convertir parte de ese juicio en criterios que otros puedan aplicar. En un diseño editorial importa la legibilidad; en una cotización, la exactitud y las condiciones; en una investigación, la correspondencia entre evidencia y conclusión.

Qué es una evaluación de agentes

Una evaluación consiste en una tarea de prueba y un mecanismo para juzgar su resultado. La documentación de Anthropic diferencia el recorrido del agente de lo que realmente quedó hecho, y analiza distintos tipos de calificadores. Esa distinción evita confundir un relato convincente de éxito con un resultado verificado. [7]

Para nuestro ejemplo comercial, una evaluación podría comprobar que el precio coincide con el catálogo vigente, que no se ofreció un producto inexistente y que una excepción pasó por aprobación. La calidad del lenguaje sería otro criterio, no un sustituto de los anteriores. No todos los elementos deben juzgarse con otro modelo: algunas verificaciones son más claras con reglas o consultas directas.

Hay que probar también cuando algo sale mal

Un conjunto de pruebas que contiene únicamente solicitudes normales puede ocultar precisamente lo que hace riesgoso un sistema. Probaríamos datos incompletos, clientes homónimos, instrucciones ambiguas, herramientas sin respuesta y solicitudes fuera de permisos. También comprobaríamos que el agente sabe detenerse sin afirmar que terminó.

La repetición importa. Un único acierto demuestra que algo es posible, no que sea confiable. Conviene repetir tareas, probar variaciones y conservar casos que el equipo no haya utilizado para ajustar la solución. De lo contrario, podemos optimizar para una colección de ejemplos conocidos y confundir esa adaptación con un desempeño general.

Para un profesional experto, aquí aparece una posible fuente de diferenciación: formular problemas, reconocer excepciones, diseñar comprobaciones y asumir responsabilidad sobre un entregable. No demuestra que todas las organizaciones vayan a contratar un «evaluador de IA». Sí ofrece una manera concreta de convertir conocimiento especializado en una capacidad que puede ponerse a prueba.

Un error en un borrador puede corregirse antes de que alguien lo vea. El mismo error en un correo enviado, un reembolso o un archivo eliminado tiene consecuencias distintas. La evaluación de un agente no puede centrarse solo en la calidad de su razonamiento: debe considerar el alcance de lo que puede hacer.

OWASP ha publicado marcos específicos para la seguridad de aplicaciones generativas y agénticas, y en septiembre de 2026 anunció nuevos recursos de control de agentes. Esto confirma que permisos, identidad y comportamiento en ejecución son problemas reconocidos de ingeniería. No significa que seguir una lista elimine el riesgo o certifique automáticamente una aplicación. [8]

No toda acción merece el mismo permiso

Proponemos separar cuatro niveles: consultar información, preparar un borrador, ejecutar una acción reversible y realizar una acción de consecuencias elevadas. Un agente que puede resumir solicitudes no necesita, por esa razón, modificar precios o acceder a todas las cuentas. El permiso debe responder a la tarea, no al entusiasmo por demostrar autonomía.

También importa quién autoriza. Que una instrucción aparezca en un correo recibido no la convierte en una orden válida para el sistema. Que un documento diga «ignora las reglas anteriores» no modifica la política de la empresa. La frontera entre contenido que se analiza e instrucciones que se obedecen merece un diseño explícito.

Una revisión humana puede ser real o decorativa

Si el sistema entrega cien aprobaciones por hora sin mostrar qué cambió, quién resultará afectado y por qué importa, la persona puede terminar aprobando mecánicamente. La solución no es agregar un botón de confirmación a cualquier flujo. Es concentrar la revisión en excepciones relevantes, presentar evidencia comprensible y dejar tiempo y autoridad para rechazar.

La trazabilidad y la recuperación completan el cuadro. Necesitamos distinguir intentos de resultados, evitar duplicados cuando una operación se repite y conservar una forma de detener el proceso. Son criterios propuestos de ingeniería responsable, no una promesa de que todo error pueda revertirse.

Auditorías y seguros: posibilidad, no permiso para descuidarse

La idea de seguros específicos para agentes merece investigación comercial. Sin embargo, este artículo no da por demostrada una obligación general de asegurarlos ni una cobertura universal disponible. Aun cuando exista una póliza aplicable, el contrato, las exclusiones y los controles exigidos importan. Transferir parte del riesgo económico no sustituye diseñar bien el sistema.

Una empresa pequeña no necesita imitar toda la burocracia de una gran organización. Necesita identificar qué puede salir mal, limitar el alcance y poder demostrar qué ocurrió. La simplicidad útil es reducir riesgo y complejidad; no eliminar las responsabilidades.

La promesa de un agente que te observa durante una semana y después realiza tu trabajo entero es poderosa porque parece eliminar el costo de explicarle lo que haces. Pero contiene varios problemas distintos: registrar acciones, inferir objetivos, reconocer excepciones, obtener permisos y actuar correctamente en situaciones nuevas. Demostrar una de esas capacidades no demuestra las demás.

Imagina a una persona que aprende a preparar presupuestos mirando tu pantalla. Puede copiar el recorrido normal. Quizá no vea por qué rechazaste a un proveedor, qué acuerdo verbal modifica una condición o cuándo un cliente necesita una excepción. El conocimiento importante no siempre está en el clic. También está en el contexto, en lo que decides no hacer y en las consecuencias que estás dispuesto a asumir.

La unidad de análisis debe ser el trabajo verificable

En vez de preguntar si un agente puede reemplazar «a un administrador», conviene identificar tareas y responsabilidades. Clasificar un documento, preparar una conciliación y autorizar un pago requieren capacidades y controles diferentes. Una ocupación reúne tareas, coordinación, relaciones y responsabilidad. No es una sola prueba que pueda aprobarse con una buena demostración.

El plazo de doce meses de las imágenes debe permanecer como pronóstico de su autor, no como calendario de implementación. Lo mismo sucede con la idea de que en 2027 los agentes actuarán de forma proactiva en todos los ámbitos. Proponemos observar avances concretos en procesos delimitados, en lugar de convertir una fecha llamativa en un compromiso empresarial.

Proactividad no significa adivinar el consentimiento

Hay una diferencia entre detectar que un vuelo cambió, preparar alternativas y comprar otro billete. Un diseño responsable puede anticipar el problema y dejar la decisión económica bajo reglas previamente acordadas. El sistema debe saber cuándo una preferencia histórica no basta para autorizar una nueva operación.

En un negocio, el equivalente sería detectar falta de inventario y recomendar una compra, en vez de comprometer dinero sin límites claros. Esa distinción permite aprovechar la anticipación sin confundir iniciativa con autoridad. El nivel de autonomía apropiado depende de la reversibilidad, la magnitud del daño y la capacidad de comprobar el resultado.

Cuando la IA entra en el mundo físico

El material también menciona robótica, diseño asistido por computadora y fabricación. Son temas diferentes. Generar un diseño no demuestra que pueda fabricarse de manera segura; producir una pieza no demuestra que cumpla tolerancias o requisitos de uso. Una demostración de software y una operación física no comparten necesariamente el mismo costo del error.

No damos por verificadas la afirmación de que «Astra fue el primer modelo» capaz de hacer CAD ni la idea de que los problemas difíciles de la IA ya sean únicamente de implementación. La frase puede describir la experiencia de una empresa, pero no resuelve por sí sola preguntas de investigación, generalización o seguridad en todo el sector.

La oportunidad razonable es trabajar con capacidades concretas, entornos definidos y pruebas del resultado. El objetivo no debería ser conseguir que una máquina haga todo lo que vio, sino que haga de manera útil y controlada aquello que podemos especificar y comprobar.

La afirmación de que alguien reprodujo varias aplicaciones multimillonarias llama la atención, pero reúne objetos diferentes. Una interfaz, una colección de funciones, una operación de servicio y una empresa no son la misma cosa. Una reproducción visual no acredita seguridad, soporte, continuidad, integración ni clientes dispuestos a utilizarla.

La hipótesis que sí merece examinarse es más acotada: si ciertas funciones se vuelven más fáciles de reproducir, puede aumentar la presión sobre los productos que se diferencian principalmente por esas funciones. Eso no implica la desaparición de todo el software por suscripción. Algunas empresas pueden conservar valor en integración, cumplimiento, soporte, confianza o conveniencia. Otras pueden perderlo.

El crecimiento puede esconder una fuga

También debemos separar nuevas ventas de permanencia. Una empresa puede crecer porque atrae clientes más rápido de lo que los pierde. Durante un tiempo, la cifra total sube y oculta que el producto no se convierte en un hábito útil. Por eso, la preocupación por retención es una buena pregunta; no es evidencia de que todas las empresas de IA retengan mal.

Una cohorte es un grupo de clientes que comparte un momento de entrada. Seguirla ayuda a distinguir curiosidad inicial de utilidad sostenida. En modelos con precios variables conviene separar retención de clientes, retención de ingresos y ampliaciones de contrato. Ninguna de ellas, por sí sola, describe todo el negocio.

El costo del servicio no desaparece dentro de la IA

Para valorar una oferta proponemos mirar también inferencia, herramientas, revisión, soporte, correcciones y adquisición de clientes. Un resultado que parece barato puede exigir muchas comprobaciones. Una suscripción que vende bien puede consumir más trabajo del fundador del que el precio permite sostener.

Los ingresos por persona pueden aportar información, pero necesitan contexto: ¿incluyen contratistas?, ¿qué costos computacionales existen?, ¿cuánto soporte se externaliza?, ¿cuánto margen queda? Un equipo pequeño no es automáticamente eficiente, del mismo modo que uno grande no es automáticamente improductivo. La métrica relevante depende de la decisión que queremos tomar.

La cifra de USD 1.000 millones de ingresos en doce meses y la comparación con un «nuevo unicornio» permanecen aquí como retórica del material inicial, no como norma del mercado. Ingreso, facturación anualizada, ingreso recurrente anual, valoración y beneficio son conceptos distintos. Mezclarlos vuelve vistoso un relato y poco útil una evaluación.

La pregunta operativa es menos glamorosa: después de probar tu solución, ¿el cliente obtiene un resultado que necesita de nuevo y cuyo costo puedes atender de manera sostenible? Ahí empieza la diferencia entre un lanzamiento y un negocio.

Hay una confusión frecuente entre terminar antes una tarea, producir más durante una jornada y mejorar el resultado económico de una organización. Son cambios relacionados, pero no idénticos. Para pasar del primero al tercero hace falta saber qué se hace con el tiempo liberado, qué demanda existe y qué costos adicionales aparecen.

La evidencia no cabe en un multiplicador universal

METR encontró que, en su estudio con desarrolladores experimentados de código abierto y tareas de comienzos de 2025, usar IA alargó el tiempo de realización un 19%. En febrero de 2026 explicó que su experimento posterior ofrecía una estimación poco fiable por problemas de selección y medición, aunque consideraba probable una mayor aceleración. No es evidencia de que la IA siempre ralentice ni de que siempre multiplique la productividad. [9]

En otro contexto, Dillon y colaboradores estudiaron la introducción de IA en herramientas de trabajo dentro de 66 empresas. Observaron cambios en actividades individuales, como el tiempo de correo, sin una transformación equivalente de todas las actividades coordinadas. Es un estudio de un entorno y una herramienta concretos, con participación de investigadores vinculados al proveedor. No permite trasladar sus efectos sin más a otra ocupación o a una microempresa ecuatoriana. [10]

Ambos trabajos ayudan a formular una pregunta mejor que «¿cuánto acelera la IA?»: ¿a quién, en qué tarea, con qué calidad, frente a qué alternativa y contando qué tiempo? Una impresión subjetiva, una prueba controlada y una mejora en el margen son evidencias diferentes.

El cuello de botella puede estar en otra parte

Supongamos que redactar una propuesta baja de cuatro horas a una. Es una mejora importante para esa tarea. Pero si el cliente tarda diez días en enviar la información o si nadie hace seguimiento después, el proceso comercial no se acelera en la misma proporción. La intervención correcta podría ser mejorar la recogida de información o el seguimiento, no generar propuestas todavía más rápido.

Por eso merece revisarse el modelo de cobro, sin convertir «cobrar por valor» en otra fórmula mágica. Un precio por proyecto puede alinear mejor alcance y resultado, pero exige definir entregables, revisiones y responsabilidades. Una remuneración vinculada al resultado puede ser inadecuada cuando el profesional no controla las variables que lo determinan. No se trata de ocultar que se usa IA ni de prometer efectos que no dependen del servicio.

La unidad que proponemos medir

Para una prueba operativa, mediríamos el costo por resultado aceptado: costo de herramientas y ejecución, más preparación, revisión, corrección y soporte atribuibles, dividido entre los resultados que cumplen los criterios. Lo acompañaríamos con tiempo total de ciclo, errores críticos y satisfacción. Esta es una propuesta de medición, no una métrica suficiente para todos los negocios.

El tiempo ahorrado puede tener valor aunque no se convierta inmediatamente en dinero: reducir sobrecarga, mejorar calidad o recuperar tiempo personal son objetivos legítimos. Lo que no conviene es vender ese ahorro como un aumento de rentabilidad sin demostrar el mecanismo que conecta ambas cosas.

Una de las ideas más sugerentes del material es que un producto podría tener que superar dos decisiones: la selección de un agente y la confianza de la persona a la que ese agente ayuda. No conviene convertirla en una ley universal de compra. Sí permite pensar en un cambio de interfaz: una parte de la comparación podría ocurrir antes de que alguien visite tu página.

Existe infraestructura concreta en esta dirección. El Agentic Commerce Protocol define mecanismos para que agentes y comercios coordinen transacciones. Su documentación aclara expresamente que implementar el protocolo no garantiza que los productos aparezcan en una plataforma de IA. Es una distinción central: compatibilidad técnica no equivale a distribución comercial. [11]

Ser comprensible para una máquina y confiable para una persona

Para una empresa de servicios, nuestra propuesta inicial es bastante convencional: explicar con claridad qué hace, para quién, bajo qué condiciones y con qué evidencia. Para un comercio: describir bien el producto, mantener precios y disponibilidad coherentes y hacer visibles entrega, devoluciones y medios de contacto. No es una garantía de posicionamiento en agentes; es una base de información útil para humanos y sistemas.

Un catálogo legible por máquinas no corrige una oferta confusa. Un texto lleno de palabras de moda no demuestra experiencia. Una reseña fabricada no se vuelve aceptable porque ayude a aparecer en una búsqueda. La nueva interfaz no elimina la necesidad de una propuesta honesta y de una operación que la cumpla.

La distribución es un sistema, no solo una publicación

En nuestro marco, distribución significa poder llegar de manera repetible a las personas adecuadas y facilitarles una decisión. Incluye canal, mensaje, evidencia, seguimiento y experiencia de compra. Una empresa puede producir mucho contenido y no tener un mecanismo para convertir una conversación en un diagnóstico o una solicitud en una propuesta.

También hay un intercambio importante: una plataforma puede acercar nuevos clientes y, al mismo tiempo, aumentar la dependencia de sus reglas. Antes de dedicar recursos a un nuevo canal, conviene preguntar quién controla la relación, qué datos se reciben, qué costos existen y qué sucede si el canal deja de estar disponible.

No confundamos una señal cultural con una estrategia financiable

Las anécdotas de autobuses publicitarios, fiestas con DJs o fundadores que terminan convertidos en creadores de contenido pueden describir un ambiente. No prueban que esa sea una vía eficiente para una empresa pequeña. Tampoco hemos encontrado una base que permita sostener que solo cincuenta personas saben escalar estos negocios.

Para una firma especializada, un caso documentado que explique un problema, una intervención y sus límites puede ser más útil que imitar el espectáculo. Para un profesional, enseñar cómo verifica una conclusión puede reforzar confianza mejor que exhibir la cantidad de herramientas que utiliza. Son propuestas que deben contrastarse con respuesta comercial real, no supuestos de éxito.

La pregunta de fondo permanece: ¿cómo llegará la persona adecuada, qué comprenderá al encontrarte y qué evidencia tendrá para confiar? Esa secuencia importa con o sin un agente en medio.

No necesitamos asumir que Quito reproducirá la trayectoria de Silicon Valley para encontrar aplicaciones útiles. La pregunta local es qué problema suficientemente importante puede resolverse con las capacidades disponibles, con qué recursos y bajo qué condiciones. No presentamos una tasa de adopción ecuatoriana ni una previsión de ventas: estos casos son ejemplos de diseño para orientar una prueba.

Ruta empresa: una distribuidora que pierde continuidad comercial

Imaginemos una pequeña distribuidora quiteña con solicitudes por correo y mensajería, un catálogo que cambia y cotizaciones en varias hojas de cálculo. La dirección quiere «un agente de ventas». Antes de construirlo, preguntaríamos dónde se pierde valor: ¿en el tiempo de respuesta, en errores de precio, en oportunidades olvidadas o en falta de inventario?

Supongamos que el problema elegido son solicitudes completas que quedan sin seguimiento. El primer piloto no necesita negociar de forma autónoma. Puede identificar esas solicitudes, relacionarlas con el registro correcto y preparar una lista priorizada con evidencia. El responsable conserva la decisión de contactar y el sistema no mezcla datos de otras empresas ni envía mensajes sin autorización.

Si el principal problema fuera inventario inexistente o una oferta poco competitiva, el agente de seguimiento no lo resolvería. La herramienta elegida debe responder al diagnóstico, no imponerlo. Esa es la diferencia entre una compra tecnológica y una intervención empresarial.

Ruta profesional: una consultora que necesita producir sin perder criterio

Ahora imaginemos una profesional independiente que prepara análisis y propuestas para clientes. Su problema no es la falta de ideas, sino la dispersión de fuentes, las revisiones repetidas y la dificultad para mantener consistencia. No necesita necesariamente un agente que trabaje sin supervisión. Podría necesitar una biblioteca autorizada, una plantilla de análisis y un mecanismo de verificación.

El flujo propuesto separa recopilación, contraste, borrador y revisión. La IA puede ayudar a localizar relaciones y estructurar argumentos; la profesional conserva la responsabilidad de validar fuentes, reconocer incertidumbre y asegurar que el entregable responda al problema real. La memoria se organiza por cliente y proyecto, con información que no debe pasar de un encargo a otro.

Dos públicos, una lógica; no una oferta indiferenciada

La empresa compra continuidad, control y resultados operativos. La profesional busca precisión, capacidad intelectual y calidad de servicio. Pueden compartir principios de arquitectura, pero requieren métricas, ejemplos y acompañamientos distintos. Tratar a ambos como «personas que quieren aprender IA» borra la necesidad concreta por la que podrían pagar.

En ambos casos, cualquier tratamiento de información personal debe revisarse frente a la normativa vigente aplicable. La SPDP mantiene el registro oficial de resoluciones en Ecuador; antes de implementar hay que comprobar su versión actual y, cuando corresponda, obtener asesoría especializada. Este artículo no sustituye una evaluación jurídica, de seguridad o sectorial. [12]

La oportunidad que proponemos explorar para X Market Lab es esa traducción: pasar de una necesidad real a un sistema de trabajo evaluable. Que la oportunidad exista conceptualmente no demuestra demanda. Las conversaciones con clientes, los pilotos y las decisiones de compra deberán confirmarla o corregirla.

Un escenario no es una predicción disfrazada. Es una descripción coherente de lo que podría ocurrir bajo ciertas condiciones, útil para preparar decisiones. Los siguientes escenarios son propuestas de X Market Lab para el horizonte 2027–2029. No asignamos probabilidades ni afirmamos que ese plazo marque un punto de llegada. Además, pueden coexistir.

Escenario A · La capacidad se vuelve más accesible

Si modelos y herramientas permiten resolver ciertas tareas con menor costo y menor dificultad, más organizaciones podrían adaptar soluciones por sí mismas. En este escenario, algunas funciones aisladas perderían valor diferencial. Nuestra hipótesis es que aumentaría la importancia relativa de escoger el problema, integrar el proceso y demostrar resultados, siempre que los clientes valoren y paguen esas capacidades.

Señales para observar: costo total por tarea aceptada, tiempo necesario para adaptar una solución y proporción de casos que requieren intervención. Respuesta prudente: mantener separables los componentes y evitar que toda la oferta dependa de una limitación temporal del modelo.

Escenario B · Las plataformas absorben más funciones

Si proveedores generales incorporan memoria, conectores y flujos especializados, algunas soluciones independientes podrían quedar presionadas. No se deduce que todas desaparezcan. Podrían conservar espacio las que resuelvan requisitos específicos, ofrezcan confianza verificable o integren procesos que una plataforma no cubra de forma conveniente.

Señales para observar: funciones que pasan a estar incluidas, cambios de precios, acceso a datos y condiciones de integración. Respuesta prudente: saber qué se puede exportar, mantener documentados los contratos de datos y no confundir facilidad inicial con ausencia de dependencia.

Escenario C · La confianza limita el ritmo de delegación

Si los costos de error, las exigencias de los clientes o los requisitos de gobierno pesan más, la autonomía completa podría avanzar de forma desigual. Habría procesos donde bastaría un borrador asistido y otros donde una ejecución restringida sería aceptable. La ventaja podría estar en demostrar confiabilidad para una tarea concreta, no en anunciar el mayor número de agentes.

Señales para observar: incidentes, rechazos de compra por falta de controles, carga de revisión y requisitos contractuales. Respuesta prudente: permisos mínimos, pruebas de excepción, responsables claros y evidencia de resultados.

Lo que tiene sentido en los tres

Hay decisiones que no requieren acertar el escenario ganador: mejorar la definición de un proceso, conocer el costo completo, conservar información con procedencia y probar antes de ampliar. Son inversiones que proponemos por su utilidad transversal, no porque garanticen inmunidad frente al cambio.

En cambio, desarrollar una plataforma compleja sobre la promesa de que «en un año todos delegarán todo» concentra demasiados supuestos. También sería arriesgado no aprender nada hasta que el futuro esté claro. Entre ambos extremos existe una estrategia de opciones pequeñas: pruebas reversibles que producen conocimiento sin comprometer recursos desproporcionados.

La salida de esta lectura no debería ser una lista interminable de herramientas. Debería ser una decisión delimitada: qué problema vas a estudiar, qué intervención pequeña merece una prueba y qué resultado justificaría continuar. Proponemos un piloto de treinta días como estructura de trabajo; no como promesa de transformación empresarial ni como muestra suficiente para validar todo un mercado.

Primera semana · Elegir y medir

Selecciona un proceso frecuente cuyo resultado pueda comprobarse. Describe quién lo inicia, qué información usa, qué entrega y quién acepta el resultado. Mide el desempeño actual durante un período razonable para su volumen: tiempo, errores, correcciones y costo aproximado. Registra también las excepciones. Si apenas ocurren unos pocos casos, treinta días quizá no basten para evaluar la intervención.

Define antes de probar qué sería una mejora útil y qué fallo obligaría a detenerse. El criterio debe responder al negocio. Reducir tiempo un 10% puede no justificar mantenimiento; evitar un error importante puede ser valioso aunque la velocidad cambie poco. Los umbrales se acuerdan, no se inventan después de ver los resultados.

Segunda semana · Preparar la mínima solución

Organiza solo la información necesaria y selecciona la intervención más simple. Puede ser una plantilla mejor, una automatización determinista, una consulta asistida o un agente. Trabaja primero con datos sintéticos o autorizados. Un conjunto inicial de veinte a treinta casos de prueba puede ayudar a descubrir defectos, pero no demuestra confiabilidad estadística ni cubre por sí mismo situaciones raras.

Prueba el caso normal, la información incompleta y el fallo de una herramienta. Comprueba qué se conserva cuando se interrumpe el trabajo. Revisa accesos y límites. No compenses una mala definición del proceso agregando más instrucciones y más agentes hasta que una demostración salga bien.

Tercera semana · Comparar con supervisión

Ejecuta una prueba limitada con revisión humana, siempre dentro de los permisos acordados. Compara tareas semejantes y documenta cambios de volumen o dificultad que puedan distorsionar el resultado. Cuando sea viable, alterna o asigna casos entre el proceso habitual y la nueva solución. No compares un día excepcionalmente malo del método anterior con la mejor demostración del nuevo.

Cuenta el tiempo de preparación, espera, revisión y corrección. Registra las tareas rechazadas, no solo las que terminaron bien. Pide a quien recibe el resultado que lo evalúe contra criterios conocidos. Una mejora que solo reconoce quien construyó el sistema necesita más contraste.

Cuarta semana · Decidir y transferir

Al cerrar el mes, elige entre mantener, modificar, ampliar de forma limitada o detener. Documenta qué se probó, con qué versión, cuáles fueron los resultados y qué sigue sin saberse. Deja instrucciones para otra persona: cómo utilizar el proceso, comprobar el resultado, reconocer un fallo y volver al método anterior.

Un piloto técnicamente correcto no valida automáticamente una oferta comercial. Para eso hacen falta señales adicionales: necesidad persistente, disposición a pagar, uso repetido y costos de servicio sostenibles. Tampoco una venta aislada demuestra retención. Cada prueba debe responder a la pregunta que realmente puede resolver.

La idea que merece quedarse

Las observaciones originales son interesantes porque apuntan a una transición posible: de competir por acceso a una herramienta a competir por la capacidad de convertirla en trabajo confiable. Pero esa transición no premia automáticamente a quien recopila más datos, construye más agentes o publica más contenido. Todo ello puede producir complejidad sin valor.

La ventaja que proponemos construir es una capacidad organizada para entender, decidir, ejecutar, comprobar y aprender. Para una empresa, significa mejores resultados con costos y riesgos controlados. Para un profesional, significa ampliar su capacidad sin abandonar el criterio. Para ambos, significa dejar de medir la adopción por la cantidad de herramientas y empezar a medirla por lo que cambia en la realidad.