Puedo crear una empresa bastante sofisticada sin construir prácticamente ninguna de las tecnologías que la hacen posible.
Puedo alquilar infraestructura en la nube, comprar un ERP, utilizar un CRM, conectar una pasarela de pago, contratar herramientas de analítica, automatizar procesos y usar modelos de inteligencia artificial.
Desde fuera, la empresa puede parecer profundamente tecnológica.
Y quizá lo sea en un sentido importante.
Pero hay otra pregunta que me interesa más:
¿usar tecnología significa tener capacidad tecnológica?
La diferencia parece semántica mientras todo funciona.
El proveedor responde. La API está disponible. El precio es asumible. La persona que lo configuró sigue trabajando con nosotros.
Entonces acceso y capacidad pueden parecer prácticamente lo mismo.
La distancia aparece cuando necesitamos cambiar algo.
Cuando el proveedor modifica condiciones. Cuando queremos integrar una pieza que nadie había previsto. Cuando un sistema falla y no sabemos por qué. Cuando hay que migrar. Cuando queremos adaptar el producto a una necesidad propia. Cuando desaparece la persona que entendía cómo estaban conectadas las cosas.
Ahí descubrimos qué parte de aquello que llamábamos nuestra tecnología estaba realmente dentro de la organización.
Y qué parte simplemente estábamos utilizando.
Podemos comprar el resultado de una capacidad
Martin Bell y Keith Pavitt hicieron en 1992 una distinción que me resulta especialmente útil.
Hablaban de capacidad de producción y capacidad tecnológica. Su argumento central era que disponer de capacidad productiva utilizando una tecnología no conduce automáticamente a acumular la capacidad tecnológica necesaria para generar y gestionar cambios posteriores.
Su trabajo no estaba escrito pensando en SaaS, ChatGPT ni pymes españolas.
No quiero fingir que sí.
Me interesa la estructura de la idea.
Podemos comprar el resultado de una capacidad sin haber construido la capacidad.
Un restaurante puede utilizar una plataforma de reservas sin saber construir software.
Una empresa puede utilizar un modelo de inteligencia artificial sin saber entrenarlo.
Yo puedo conducir un coche sin saber diseñar un motor.
No hay nada malo en ello.
La especialización funciona precisamente porque no necesitamos construir cada pieza que utilizamos.
El error aparece cuando confundimos acceso con acumulación.
Puedo acceder durante años a una capacidad externa y aprender muy poco sobre ella.
También puedo utilizar tecnología de otros y, durante ese proceso, aprender a integrarla, evaluarla, modificarla, sustituirla y decidir mejor.
La tecnología externa no impide construir capacidad interna.
Pero tampoco la crea automáticamente.
La facilidad de uso esconde la dificultad de construir
El software moderno ha hecho algo extraordinario.
Ha convertido capacidades complejísimas en botones.
Crear una cuenta. Añadir una tarjeta. Importar datos. Usar.
Detrás puede haber décadas de ingeniería, centros de datos, protocolos, equipos de seguridad y miles de personas.
Yo veo una interfaz.
Eso democratiza tecnología.
También puede producir una ilusión.
Como la experiencia es sencilla, parece que la capacidad también lo es.
Pero utilizar una herramienta bien diseñada y construir aquello que permite que funcione son cosas radicalmente distintas.
Incluso entre utilizarla y operarla existe una distancia enorme.
Sé escribir en un procesador de texto.
Eso no significa que pueda mantener la infraestructura que lo sirve.
Sé pedir una respuesta a un modelo.
Eso no significa que sepa evaluar un sistema de IA en producción.
Sé crear una automatización.
Eso no significa que haya diseñado una arquitectura que pueda mantenerse cuando aparezcan cien automatizaciones.
Cuanto mejor funciona la abstracción, menos vemos aquello de lo que dependemos.
Esa es una de sus virtudes.
También uno de sus riesgos.
Una empresa puede tener mucha tecnología y poca capacidad
Esta distinción se parece a la que aparecía cuando pensaba en digitalización.
Comprar herramientas puede mejorar una empresa.
No tengo ninguna intención de negar eso.
Una pyme no necesita desarrollar su propio CRM para utilizar bien un CRM.
Pero la pregunta importante aparece después.
¿Qué queda dentro?
¿Sabemos por qué elegimos esa herramienta? ¿Entendemos nuestros datos? ¿Sabemos integrarla? ¿Podemos detectar cuándo está fallando? ¿Podemos cambiarla? ¿Sabemos qué procesos dependen de ella? ¿Existe alguien que pueda reconstruir el sistema?
Ahí la tecnología empieza a convertirse en capacidad.
Y también aparece la infraestructura.
No únicamente servidores.
Infraestructura puede ser una arquitectura de datos, identidades, permisos, documentación, estándares, procesos, personas y conocimiento operativo.
Una empresa puede utilizar diez herramientas modernas y seguir dependiendo de exportaciones manuales, contraseñas compartidas y una persona que recuerda cómo arreglar cada excepción.
Desde fuera parece más tecnológica.
Por dentro quizá solo ha acumulado más piezas.
La infraestructura no tiene por qué ser nuestra
Aquí hay una trampa importante.
Si sigo el argumento demasiado lejos, podría parecer que tener capacidad exige poseerlo todo.
Servidores propios. Software propio. Modelos propios. Equipo propio.
No.
Eso sería convertir autonomía en autarquía.
Una empresa puede construir una infraestructura excelente sobre tecnología de terceros.
Puede utilizar AWS, Microsoft, Odoo, Stripe o un modelo externo y conservar un grado alto de capacidad sobre su propio sistema.
Propiedad y capacidad no son lo mismo.
Lo que me interesa es otra cosa.
¿Entendemos qué depende de cada pieza? ¿Podemos mover nuestros datos? ¿Tenemos documentación? ¿Conocemos las alternativas? ¿Sabemos qué ocurriría si desaparece?
¿La decisión de seguir utilizando ese proveedor es nuestra o simplemente ya no sabemos salir?
Una dependencia comprendida puede ser una elección.
Una dependencia que no entendemos se parece mucho a una capacidad hasta que deja de funcionar.
El dinero puede comprar inversión sin comprar aprendizaje
Aquí el debate sobre NextGenerationEU me parece útil.
No porque quiera convertir este artículo en una evaluación de los fondos europeos.
No tengo base para hacerlo.
Pero el programa permite ver una diferencia que solemos borrar.
El dinero puede provocar inversión que, de otro modo, quizá no habría ocurrido.
El Banco de España encontró en enero de 2025 que el 45% de las empresas encuestadas con proyectos financiados por NextGenerationEU declaraba que no habría realizado esas inversiones sin el programa y otro 31% que solo habría realizado una parte.
Eso importa.
La financiación puede desbloquear una decisión.
Puede pagar software, maquinaria, consultoría, formación o infraestructura.
Pero después queda otra pregunta.
¿Qué capacidad ha quedado cuando termina la inversión?
Podemos subvencionar una licencia.
No podemos subvencionar directamente diez años de experiencia.
Podemos pagar una implantación.
No podemos comprar de golpe el criterio que aparece después de mantenerla, equivocarse, corregirla y entender qué partes del sistema importan realmente.
El capital puede crear las condiciones para aprender.
No puede saltarse el aprendizaje.
Por eso me resulta útil una frase bastante simple:
capital no es capacidad.
No significa que el capital no importe.
Significa exactamente lo contrario.
Puede ser necesario.
Solo que no contiene automáticamente aquello que esperamos obtener de él.
El verdadero resultado aparece cuando se acaba el proyecto
Imaginemos una empresa que recibe ayuda para implantar un nuevo sistema.
Pasan dieciocho meses.
La herramienta está instalada. Los datos se han migrado. La consultora ha terminado. El expediente se cierra.
¿Qué queda?
Si queda únicamente la herramienta, tenemos adopción.
Puede haber sido una buena adopción.
Puede ahorrar horas.
Puede mejorar resultados.
No necesito llamarla fracaso.
Pero si además la organización entiende mejor sus procesos, ha definido sus datos, sabe operar el sistema, puede evaluar alternativas, ha documentado decisiones y tiene personas capaces de modificarlo, entonces ha ocurrido algo más.
Ha acumulado capacidad.
La diferencia no siempre se ve el día de la inauguración.
A veces aparece dos años después.
Cuando cambia el negocio.
Cuando falla una integración.
Cuando entra un proveedor nuevo.
Cuando hay que sustituir una pieza.
Cuando alguien pregunta por qué el sistema funciona así y existe una respuesta mejor que:
porque siempre se ha hecho así.
He acabado imaginando cinco niveles
Otra vez he terminado construyendo categorías.
No son una taxonomía académica.
Bell y Pavitt no propusieron estos cinco niveles.
Son mi manera de ordenar el problema.
El primero es usar.
Tenemos acceso a una tecnología y podemos utilizarla para una tarea.
Eso ya tiene valor.
El segundo es integrar.
La herramienta deja de ser una isla. Entra en nuestros datos, procesos, permisos y flujos de trabajo.
El tercero es operar.
Sabemos mantener lo que hemos integrado. Detectar problemas. Controlar costes. Gestionar seguridad. Documentar. Resolver incidencias.
El cuarto es construir.
Podemos crear o modificar una parte del sistema.
No todo.
La pieza que necesita ser nuestra.
Y el quinto es conservar capacidad de decisión.
Este es el más difícil.
No significa control absoluto.
Significa que las dependencias críticas no nos han dejado sin margen.
Podemos cambiar, negociar, auditar, sustituir, entender y decidir.
Los niveles no son una escalera perfecta.
Una empresa puede operar muy bien tecnología que nunca construirá.
Puede construir un componente y depender completamente de otro.
Puede tener gran capacidad técnica y una arquitectura imposible de cambiar.
El modelo se rompe.
Bien.
Me ayuda precisamente porque hace visibles preguntas que una palabra como «tecnológica» esconde.
No necesitamos construir nuestros propios tornillos digitales
Hay una obsesión peligrosa con lo propio.
Software propio. Cloud propio. IA propia. Todo propio.
A veces tiene sentido.
Muchas otras es una forma carísima de demostrar independencia mientras reinventamos algo que otro hace mucho mejor.
No creo que una empresa tecnológicamente madura sea la que menos depende de terceros.
Creo que es la que sabe de qué depende.
Y ha decidido conscientemente qué dependencias acepta.
Externalizar nóminas no convierte a una empresa en incapaz.
Externalizar todo el conocimiento sobre su arquitectura crítica y no saber siquiera qué pedir al proveedor quizá sí sea otro problema.
La cuestión no es quién escribió el código.
Es dónde reside la capacidad de decidir qué hacer con él.
Por eso una pyme y un país no pueden utilizar exactamente la misma definición de soberanía o capacidad.
La escala cambia.
La criticidad cambia.
Las consecuencias cambian.
Una pyme puede permitirse depender completamente de un proveedor para el correo.
Un hospital tendrá otras exigencias para determinados sistemas.
Un Estado otras.
No existe un nivel universal de autonomía.
Existe una pregunta:
¿qué no podemos permitirnos dejar de entender?
La inteligencia artificial hace la distinción más difícil
La IA está reduciendo todavía más la distancia entre querer una capacidad y acceder a ella.
Hace pocos años, construir un sistema capaz de resumir miles de documentos, escribir código, clasificar texto o responder preguntas sobre información no estructurada requería muchísimo trabajo especializado.
Ahora muchas de esas cosas empiezan con una API.
Eso es extraordinario.
Y precisamente por eso resulta todavía más fácil confundir uso con capacidad.
Una empresa puede decir:
hacemos inteligencia artificial.
¿Significa que utiliza ChatGPT? ¿Que ha integrado modelos en procesos? ¿Que sabe evaluarlos? ¿Que ha construido datos y controles alrededor? ¿Que puede sustituir un proveedor? ¿Que entiende cuándo no debería utilizarlos?
Todas las respuestas pueden ser tecnológicamente válidas.
No significan lo mismo.
La OCDE sigue encontrando en las pymes españolas una diferencia entre la disponibilidad o adopción de tecnología y las capacidades necesarias para aprovechar herramientas digitales más avanzadas; su informe sobre España se publicó en noviembre de 2025, por tanto es anterior a esta fecha editorial.
Cuando la barrera de acceso cae, la capacidad se desplaza.
Ya no está únicamente en conseguir la herramienta.
Está en saber qué hacer con ella.
Utilizar bien tecnología externa también puede construir capacidad
Hay una versión demasiado dura de este artículo que no quiero escribir.
Sería esta:
si no construyes la tecnología, no tienes capacidad.
No me la creo.
Una organización puede aprender muchísimo precisamente utilizando sistemas desarrollados por otros.
Puede desarrollar criterio, arquitectura, conocimiento de dominio, capacidad de integración, gobernanza, operación y evaluación.
Puede incluso llegar a construir algo propio después porque años de uso le han permitido entender qué pieza merece ser propia.
La dependencia y el aprendizaje no son incompatibles.
El error sería pensar que la compra produce automáticamente el aprendizaje.
A veces ocurre.
A veces no.
Puedes utilizar durante diez años una tecnología y seguir sin saber qué harías si mañana desaparece.
También puedes utilizarla durante dos años y haber construido suficiente conocimiento para sustituirla.
La diferencia no está en la factura.
Está en lo que la organización ha acumulado mientras pagaba la factura.
Quizá estamos midiendo la parte más fácil
Una licencia se cuenta.
Un servidor se cuenta.
Una inversión tiene un importe.
Una implantación tiene una fecha.
La capacidad es más incómoda.
Está repartida entre personas, procesos, infraestructura, experiencia y decisiones.
Puede desaparecer cuando se va un equipo.
Puede degradarse.
Puede quedar atrapada en un proveedor.
Puede crecer sin que compremos nada nuevo.
Quizá por eso tendemos a medir tecnología observando objetos.
Tiene sentido.
Lo que no deberíamos hacer es olvidar qué pregunta responde cada indicador.
Saber cuántas empresas utilizan determinada tecnología nos dice algo sobre adopción.
No nos dice automáticamente cuánto han aprendido.
Y entonces aparece una pregunta que cada vez me interesa más:
¿qué sabe hacer ahora esta organización que antes no sabía hacer?
No cuántas herramientas tiene.
Qué sabe hacer.
Tener tecnología es fácil. Acumular capacidad tarda
Comprar puede ocurrir en una tarde.
Acumular capacidad es más lento.
Hay que utilizar, integrar, equivocarse, mantener, documentar, formar, cambiar, descubrir dependencias y decidir qué partes merece la pena construir y cuáles conviene seguir comprando.
Eso explica por qué podemos gastar mucho dinero en tecnología y seguir teniendo organizaciones frágiles.
Y también por qué una empresa pequeña puede construir una capacidad extraordinaria utilizando principalmente tecnología de terceros.
No depende únicamente de lo que posees.
Depende de aquello que has aprendido a hacer.
Después de darle vueltas, mi definición provisional sería esta:
tener capacidad tecnológica significa haber acumulado suficiente conocimiento, infraestructura, organización y experiencia para utilizar una tecnología con criterio, adaptarla a nuestras necesidades y conservar un grado suficiente de decisión sobre aquello que depende de ella.
No es una definición académica.
Es mi mapa.
Y seguramente tiene agujeros.
Pero me sirve más que contar licencias.
Ser tecnológico tampoco era comprar tecnología
Empiezo a ver el mismo error en sitios distintos.
Queremos digitalización y contamos herramientas.
Queremos inteligencia artificial y contamos usuarios.
Queremos modernización y contamos inversión.
Queremos capacidad y contamos infraestructura.
Todo eso importa.
El problema empieza cuando el medio ocupa el lugar del resultado.
Una empresa puede comprar una capacidad externa y obtener muchísimo valor.
No necesita fingir que la ha construido.
Puede decir simplemente:
puedo hacer esto porque utilizo esta tecnología.
La pregunta estratégica viene después.
¿Qué parte necesito entender? ¿Qué parte necesito poder cambiar? ¿Qué parte puedo entregar tranquilamente a otro? ¿Qué dependencia puedo aceptar? ¿Cuál no?
No necesitamos construirlo todo.
No necesitamos controlarlo todo.
Necesitamos saber qué podemos permitirnos no entender.
Y conservar capacidad de decisión suficiente sobre aquello que no podemos permitirnos dejar de entender.
Referencias
Bell, M. y Pavitt, K. (1992). Accumulating Technological Capability in Developing Countries. The World Bank Economic Review, 6(suppl. 1), 257–281. DOI: 10.1093/wber/6.suppl_1.257.
Vial, G. (2019). Understanding digital transformation: A review and a research agenda. The Journal of Strategic Information Systems, 28(2), 118–144. DOI: 10.1016/j.jsis.2019.01.003.
Fernández Cerezo, A., Puente Díaz, S. y Veiga-Duarte, R. (2025). La debilidad de la inversión empresarial en España tras la pandemia: un análisis basado en la EBAE. Banco de España, Boletín Económico 2025/T1. Publicado el 29 de enero de 2025.
OECD (2025). OECD Economic Surveys: Spain 2025. OECD Publishing. DOI: 10.1787/abc5c435-en. Publicado el 26 de noviembre de 2025.
Deja una respuesta