La inteligencia artificial está derribando una de las barreras históricas de la economía corporativa: convertir una necesidad en una aplicación funcional. Para los comités de dirección, esta abundancia abre posibilidades extraordinarias, pero introduce un riesgo silencioso. Cuando prácticamente todo se puede programar, el verdadero dilema deja de ser técnico y se transforma en una estricta decisión de asignación de capital: determinar dónde vale la pena comprometer tiempo, balance, talento y atención directiva.
Por MA Nautilius
Imagine una sesión de comité ejecutivo cuyo desenlace, hasta hace apenas unos años, habría sido completamente predecible.
El director comercial expone con frustración las limitaciones del CRM corporativo. Argumenta que la plataforma no refleja la cadencia real de las ventas, exige demasiados clics en la operación diaria y los reportes directivos carecen de la granularidad que el negocio demanda. Alguien en la mesa, buscando romper la inercia, formula una propuesta audaz: «¿Por qué no desarrollamos nuestro propio sistema a la medida?».
Cinco años atrás, la conversación habría muerto en ese mismo instante.
El filtro no era ideológico; era puramente económico y operativo. Implicaba justificar escuadras de desarrolladores dedicados, meses de arquitectura de bases de datos, diseño de interfaces, gestión de ciberseguridad, permisos, APIs, aplicaciones móviles y presupuestos de soporte continuos. La fricción técnica operaba como una barrera natural de contención.
En 2026, la misma reunión puede tomar un curso radicalmente distinto.
Un equipo ágil, apalancado en agentes de programación (coding agents), puede presentar un prototipo funcional en días. Los modelos actuales pueden ayudar a generar esquemas de datos, flujos lógicos, interfaces, pruebas automatizadas y documentación técnica. Lo que antes podía exigir un proyecto formal de desarrollo hoy puede comenzar con lenguaje natural y ciclos de prototipado mucho más cortos.
De pronto, construir la plataforma parece una decisión obvia, accesible e innovadora.
Y es justamente ahí donde comienza el riesgo de erosión de valor.
El hecho de que una organización pueda construir su propio software no responde a la pregunta que salvaguarda el retorno de inversión:
¿Debería construirlo?
La distancia entre ambas preguntas no es una sutileza retórica; puede marcar la diferencia entre convertir la inteligencia artificial en una ventaja competitiva sostenible o utilizarla para acelerar inversiones que nunca debieron hacerse.
Durante décadas, la restricción técnica funcionó como filtro para muchas iniciativas. Al disminuir ese dique, también se reduce la fricción que impedía fondear desarrollos poco justificados. La paradoja del nuevo paradigma es clara: cuanto más barata se vuelve la ejecución técnica, más valioso se vuelve el criterio directivo.
La frontera que se desplaza: de la escasez a la ilusión de autonomía
Esta disyuntiva ya aparece en los datos.
En agosto de 2026, The State of AI 2026 de McKinsey reportó que 32% de los encuestados dijo que su organización había decidido no comprar uno o más productos o funcionalidades de software porque podía construirlos internamente mediante herramientas agentivas de programación. Cerca de dos de cada diez organizaciones estaban escalando agentes de programación; entre las empresas con ingresos superiores a mil millones de dólares, la proporción alcanzaba 31%.
El dato merece un análisis riguroso.
Durante los últimos treinta años, la industria tecnológica operó bajo una premisa fundacional: las empresas identificaban una necesidad y acudían a especialistas para resolverla. Ecosistemas como Microsoft, SAP, Oracle, Zoho o Salesforce florecieron sobre una base económica elemental: resolver colectivamente problemas de infraestructura y software que resultaba costoso resolver de forma individual.
Los agentes de IA no destruyen ese principio, pero están moviendo la frontera entre comprar y construir.
En un análisis complementario sobre quince organizaciones intensivas en IA, McKinsey documentó una tensión creciente: muchas empresas siguen comprando herramientas comerciales para aquello que no genera diferenciación, mientras organizaciones con mayor capacidad técnica ya pueden crear tableros, flujos y agentes personalizados en horas en lugar de meses. La frontera se volvió mucho más dinámica.
Cuando construir era costoso, muchos malos proyectos morían por inviabilidad presupuestaria. Hoy, una mala idea puede superar con mucha mayor facilidad el filtro técnico. Pero que una aplicación funcione en pantalla no significa que merezca capital.
El CRM que podemos programar, pero que quizá no deberíamos financiar
Retomemos la escena de la sala de juntas.
El prototipo del CRM interno está proyectado en la pantalla. Funciona. La navegación es intuitiva, el embudo comercial luce impecable y el equipo de innovación demuestra cómo un agente de IA redacta correos de seguimiento automáticos. El entusiasmo en la sala es comprensible: la organización está presenciando algo tangible.
Es el momento exacto en el que un Director Financiero o un miembro del Consejo debería interrumpir la sesión y plantear la pregunta de rigor:
¿Contra qué estamos comparando realmente esta inversión?
El error analítico consiste en contrastar únicamente el costo marginal de generar código con el valor de las licencias anuales de un proveedor consolidado. Esa comparación es incompleta.
El análisis financiero exige considerar el Costo Total de Propiedad (TCO) a lo largo del ciclo de vida del activo.
Una plataforma comercial madura no vende solamente pantallas y formularios; incorpora años de investigación y desarrollo en seguridad, esquemas de gobernanza, auditoría de acceso, mantenimiento de APIs, disponibilidad, actualizaciones y evolución continua.
Programar la primera versión de un software interno se ha vuelto mucho más accesible. Gestionar su obsolescencia, parches de seguridad y deuda técnica a lo largo de los años no desaparece por ello.
El análisis de McKinsey sobre empresas intensivas en IA advierte precisamente este punto: las herramientas personalizadas pueden ser baratas de construir, pero mantenerlas no lo es. Permitir que cada equipo cree soluciones propias sin disciplina puede terminar generando una factura posterior de mantenimiento y complejidad.
El costo que no figura en la cotización: asignación de capital y oportunidad
Aun si concediéramos el escenario más optimista —que programar internamente ese CRM resultara más barato que pagar una suscripción corporativa—, la decisión seguiría necesitando justificación.
Porque todavía falta auditar uno de los activos más escasos de cualquier organización: el costo de oportunidad.
La inteligencia artificial puede ampliar enormemente la capacidad de cómputo y ejecución, pero los recursos críticos de una empresa continúan siendo finitos: el ancho de banda cognitivo del equipo directivo tiene un límite; la atención de los mejores ingenieros y líderes de proceso no es elástica; la capacidad de una organización para asimilar cambios estructurales es restringida; y cada peso asignado a un desarrollo interno compite contra otras iniciativas estratégicas.
Cuando una empresa distrae a su mejor talento en replicar un sistema que el mercado ya resuelve con madurez, el daño potencial no es solamente el dinero desembolsado en programación. También importa aquello que la empresa dejó de hacer mientras invertía en ese proyecto.
¿Pudo ese mismo equipo diseñar un modelo propio sobre datos históricos para anticipar la fuga de clientes clave? ¿Pudo transformar un proceso logístico que estrangula los márgenes de entrega? ¿Pudo crear una experiencia digital diferenciada que resulte más difícil de replicar?
La inteligencia artificial no elimina el problema de asignación de recursos; aumenta la necesidad de rigor estratégico para decidir dónde aplicar capital humano y financiero.
Más allá del dogma binario: la arquitectura híbrida
Frente a este riesgo, la tentación opuesta sería caer en un conservadurismo estéril y decretar que la empresa jamás debe programar nada propio.
Esa simplificación tampoco resiste el análisis.
Boston Consulting Group sostiene que una estrategia puramente de comprar o construir resulta demasiado rígida para el entorno actual y propone un enfoque híbrido de buy and build: aprovechar productos consolidados para ganar velocidad y estabilidad, mientras se desarrollan selectivamente capacidades propietarias donde existe suficiente valor estratégico.
La decisión deja de ser ideológica y se convierte en arquitectónica. Un ERP maduro puede operar como columna vertebral transaccional mientras la compañía desarrolla encima un modelo propio para optimizar compras. Un CRM consolidado, como el ecosistema Zoho, puede administrar contactos, permisos, trazabilidad y embudos mientras la empresa construye un agente conectado a conocimiento y datos propios para apoyar decisiones comerciales específicas.
Comprar y construir dejan de competir necesariamente en el presupuesto. Pueden integrarse en un diseño coherente.
Dónde ser propietario: el activo que la IA no puede clonar fácilmente
Esta lógica nos conduce al núcleo de la estrategia corporativa moderna: ¿qué activos tecnológicos debe poseer realmente una organización?
Una empresa debería considerar asumir la propiedad, el mantenimiento y el riesgo de un software cuando exista una razón económica o estratégica suficiente: diferenciación, datos o conocimiento propios, integración crítica, flexibilidad necesaria o una economía total superior a las alternativas disponibles.
McKinsey encontró un patrón consistente entre las compañías intensivas en IA estudiadas: cuando una capacidad ayuda a crear una ventaja defendible basada en datos, conocimiento especializado o propiedad intelectual que una herramienta comercial no puede replicar, existe una razón fuerte para construirla. Para buena parte del resto del stack, muchas compañías continúan aprovechando soluciones de mercado.
Pensemos en el caso del CRM. Registrar prospectos, coordinar actividades y administrar oportunidades son funciones ampliamente estandarizadas. Por sí solas aportan poca diferenciación.
Sin embargo, si tras dos décadas en el mercado una empresa posee información histórica que le permite identificar patrones particulares y anticipar necesidades de sus clientes, ahí puede existir un activo distintivo.
El activo no es la interfaz gráfica donde se visualiza al cliente. El activo puede ser la inteligencia acumulada, el modelo de datos y la orquestación del proceso.
Eso sí puede justificar inversión propietaria. Reconstruir la infraestructura básica sobre la que corre esa inteligencia puede no hacerlo.
La paradoja de la ejecución: cuando tener la idea y codificarla deja de ser suficiente
Durante décadas, la capacidad de transformar una visión de negocio en un producto de software funcional confería una ventaja importante. El mercado premiaba a quien podía superar la barrera de la ejecución técnica.
La IA está reduciendo esa barrera.
Tener una idea y programarla ya no construye, por sí mismo, un foso defensivo (moat). Si herramientas similares de IA están disponibles para competidores, la defensa de una empresa debe buscarse también en aquello que rodea al software: distribución, confianza y reputación de marca, profundidad y exclusividad de los datos, costos de cambio, integración en las operaciones del cliente, conocimiento especializado y velocidad de aprendizaje organizacional.
Cualquier proyecto de desarrollo interno que justifique su existencia únicamente con «podemos programarlo» debería responder una pregunta más exigente: ¿qué parte de este activo seguirá siendo difícil de copiar cuando otros tengan acceso a capacidades técnicas semejantes?
El espejismo de la «Fábrica de Aplicaciones»
Existe un escenario aún más peligroso que no innovar: la hiperactividad tecnológica desarticulada.
Ocurre cuando una compañía adopta la IA con entusiasmo, pero sin una arquitectura común. Marketing crea agentes, Finanzas desarrolla aplicaciones internas, Operaciones automatiza flujos en herramientas desconectadas y Ventas incorpora plataformas independientes para acelerar la prospección.
Durante los primeros meses, la organización puede experimentar una euforia de productividad. Hay presentaciones, demostraciones y una percepción generalizada de transformación.
Meses después pueden aparecer múltiples versiones de la verdad en bases de datos aisladas, agentes alimentados con contextos contradictorios, procesos críticos dependientes de aplicaciones huérfanas y una arquitectura cada vez más difícil de gobernar. La organización construyó aplicaciones, pero no necesariamente construyó un sistema.
La investigación de DORA sobre 2025 describe la IA como un amplificador: puede mejorar el throughput, pero también perjudicar la estabilidad cuando la base organizacional y técnica no es sólida.
Producir más código no equivale a generar más valor. Multiplicar herramientas no equivale a operar mejor. A la empresa puede no faltarle tecnología; puede faltarle arquitectura.
La disciplina de la asignación: el marco de los cinco caminos
Para un Director General o un Consejo de Administración, el debate tecnológico no debería comenzar por la comparación de herramientas o cotizaciones de desarrollo. Debe comenzar en la economía del negocio.
Toda iniciativa tecnológica puede evaluarse a través de cinco caminos estratégicos:
| Camino | Criterio de aplicación | Racional económico |
|---|---|---|
| 1. Comprar | Cuando la necesidad es estándar y el mercado ofrece soluciones maduras. | Reduce el tiempo de llegada a valor y distribuye el costo de I+D y mantenimiento en un proveedor especializado. |
| 2. Configurar | Cuando la funcionalidad base existe, pero requiere adaptarse a la lógica operativa de la empresa. | Permite adaptar procesos sin asumir la propiedad completa del sistema base. |
| 3. Integrar | Cuando el valor reside en conectar sistemas para que datos y procesos fluyan con coherencia. | Aprovecha inversiones existentes y reduce silos operativos. |
| 4. Construir | Cuando existe una razón económica o estratégica suficiente para desarrollar una capacidad propia. | Asume conscientemente mantenimiento y riesgo a cambio de diferenciación, control o economía superior. |
| 5. No hacer | Cuando la iniciativa es atractiva técnicamente pero no justifica los recursos que exige. | Preserva capital, foco directivo y evita complejidad innecesaria. |
Las cinco preguntas del Consejo antes de aprobar un desarrollo
Un consejo directivo no necesita auditar código fuente para gobernar las decisiones tecnológicas. Requiere aplicar el mismo rigor con el que evalúa cualquier otra asignación significativa de recursos.
- ¿Qué métrica financiera u operativa concreta esperamos transformar?
Si los promotores del proyecto solo describen funcionalidades, todavía no existe un caso de negocio suficientemente claro. La justificación debería conectar con margen, ingresos, costos, riesgo, ciclo de conversión de efectivo, retención, experiencia del cliente o capacidad operacional. - ¿Qué parte de este problema ya resolvió la industria del software?
La existencia de una solución comercial no obliga a comprarla, pero eleva el estándar de justificación para reconstruirla. - ¿Qué ventaja económica defendible obtenemos al poseer esta capacidad?
Debe existir una razón concreta: propiedad intelectual, datos propios, conocimiento especializado, integración crítica, flexibilidad o una economía total superior. - ¿Cuál es el Costo Total de Propiedad a tres años, incluyendo el costo de oportunidad?
El presupuesto debería contemplar ciberseguridad, mantenimiento, gobierno del dato, integraciones, evolución y el costo de desviar talento de otras prioridades. - Si un competidor desarrolla una herramienta parecida usando IA, ¿dónde queda nuestra ventaja?
Si la ventaja desaparece con la réplica del software, quizá el activo estratégico se encuentre en otra parte.
La emergencia del Arquitecto del Sistema Operativo Empresarial
Cuando una compañía asimila este nivel de rigor, se vuelve evidente la necesidad de una disciplina que suele estar fragmentada en el organigrama tradicional.
Alguien debe observar el conjunto.
No la base de datos por separado. No el CRM en aislamiento. No la última prueba de concepto con agentes de IA. Se necesita una función capaz de articular cómo estrategia de negocio, procesos, personas, datos y capacidades tecnológicas convergen en un sistema de ejecución.
A esta función la denominamos el Arquitecto del Sistema Operativo Empresarial.
No nos referimos al software que arranca una computadora. Nos referimos a la infraestructura viva mediante la cual una empresa transforma decisiones directivas en ejecución operativa y ejecución operativa en resultados.
Toda empresa opera mediante un sistema de este tipo, aunque jamás lo haya diseñado deliberadamente. En muchas organizaciones, ese sistema creció por sedimentación: un ERP comprado por Finanzas años atrás, un CRM implementado parcialmente, hojas de cálculo que sostienen parte de la operación, mensajería utilizada para gestionar excepciones y personas indispensables que compensan con esfuerzo las fallas del diseño estructural.
Todo puede mantenerse a flote hasta que la empresa intenta escalar, internacionalizarse o incorporar inteligencia artificial. Entonces aparece una realidad incómoda: los agentes conectados a procesos caóticos pueden acelerar también los errores.
La labor del arquitecto no consiste en saturar a la empresa de tecnología. Consiste en diseñar coherencia entre los objetivos económicos y las capacidades operativas. En ocasiones, su contribución más valiosa para los accionistas puede consistir en detener a tiempo un desarrollo innecesario.
Zherpa: criterio y arquitectura antes que acumulación de software
Ésta es la convicción sobre la que opera Zherpa.
Zherpa es una firma independiente de arquitectura de negocio e implementación. Nuestro trabajo no comienza seleccionando software; comienza entendiendo el negocio. Conectamos estrategia, procesos, el ecosistema Zoho, CRM, automatización, datos e inteligencia artificial gobernada para convertir inversión tecnológica en capacidad operativa y resultados medibles.
No partimos de la presunción de que una compañía deba construirlo todo ni de que deba resolverlo todo con una suscripción estándar. El valor de la arquitectura está precisamente en trazar esa línea con criterio: aprovechar plataformas sólidas donde el mercado ya resolvió el problema, integrar información para reducir islas de datos y orientar la capacidad de innovación hacia aquellas capas donde existe una razón empresarial para ser diferente.
En Zherpa, el éxito de una intervención no se mide por el número de líneas de código entregadas, sino por la capacidad del sistema resultante para ampliar la ejecución con control, continuidad y retorno medible.
La ventaja no pertenecerá a quien construya más, sino a quien elija mejor
La historia empresarial de los próximos años probablemente no se definirá por qué compañías logren programar la mayor cantidad de aplicaciones internas. Las capacidades fundamentales de IA están cada vez más disponibles para un número mayor de organizaciones.
La asimetría competitiva puede estar en la lucidez estratégica de la dirección: en la disciplina para no reinventar lo que el mercado ya resuelve adecuadamente; en la claridad para invertir capital donde existe diferenciación real; en la capacidad de estructurar datos y procesos antes de desplegar agentes; y en saber qué batallas tecnológicas no merece la pena pelear.
Antes de autorizar la siguiente partida presupuestal para software a la medida, conviene regresar a la pregunta esencial.
La cuestión no es solamente si su equipo puede construirlo.
La verdadera cuestión es: ¿por qué merece existir en su empresa?
Zherpa: arquitectura de negocio antes que acumulación tecnológica
Si su consejo directivo o comité ejecutivo está evaluando inversiones en desarrollos propios, adopción de agentes de IA, migraciones de CRM o modernización de su plataforma operativa con Zoho, conviene comenzar por la arquitectura del negocio.
Conozca el enfoque de Zherpa y, si necesita identificar fugas de valor, madurez operativa y prioridades, realice el Diagnóstico Zherpa.
