Infraestructura informática hasta 2030: para qué deben prepararse las empresas

Qué está documentado y qué sigue siendo un escenario

Una inversión con una vida útil de cinco años necesita una visión de futuro. No necesita afirmar que para entonces toda tecnología nueva se utilizará en todas partes. Este artículo distingue las capacidades técnicas documentadas, las previsiones de fuentes identificadas y nuestros propios escenarios de decisión. De ellos se derivan comprobaciones concretas para la planificación actual.

Un plan fiable también identifica lo que no puede predecir: los futuros precios de RAM, la familia de procesadores más económica o las funciones de una tarifa concreta de nube. En su lugar, prevea reservas, puntos de comparación y periodos de reevaluación. Así la decisión sigue siendo aplicable cuando cambia un supuesto.

La energía se convierte en una cuestión de arquitectura

La AIE estima que el consumo eléctrico mundial de los centros de datos en 2024 fue de unos 415 TWh. En el escenario base de su informe Energy and AI de 2025, aumenta hasta aproximadamente 945 TWh en 2030. Es una evolución modelizada con incertidumbres, no una medición ya observada para 2030. El informe describe, entre otras cosas, distintos supuestos sobre el uso de IA y la eficiencia. AIE: Energía e inteligencia artificial, resumen ejecutivo (2025) ↗

Para una pequeña empresa, esto no implica ninguna previsión concreta del precio eléctrico. Sin embargo, en la práctica merece la pena una medición inicial rigurosa: ¿qué sistemas funcionan continuamente, cuáles solo realizan unas pocas horas de trabajo productivo y qué reservas se necesitan ante fallos? Consolidar puede ahorrar energía, pero aumenta el número de aplicaciones que dependen de un solo equipo. El plan ante fallos debe crecer al mismo tiempo.

En su pilar de sostenibilidad, AWS recomienda ajustar la cantidad de hardware y servicios a la carga real y elegir recursos adecuados y eficientes. Una métrica interna útil podría ser la energía o el coste por pedido procesado correctamente. Un consumo bajo en reposo ayuda poco si la aplicación tarda mucho más en realizar la misma tarea. AWS: hardware y servicios en el pilar de sostenibilidad ↗

La IA cambia la cuestión de la memoria, pero no toda aplicación necesita una GPU

Un asistente documental puede utilizar servicios externos de modelos, ejecutar localmente un modelo menor o combinar ambos enfoques. La arquitectura adecuada depende de los datos, el tiempo de respuesta, la frecuencia de uso y el software que el equipo pueda operar. Disponer de un acelerador propio solo está bien justificado cuando una prueba demuestra una demanda sostenible. El tamaño que aparece en el nombre de un modelo no es un requisito completo de hardware.

Un cálculo sencillo ilustra el límite: ocho mil millones de parámetros de dos bytes cada uno requieren aproximadamente 16 GB solo para los pesos. Es un límite inferior matemático bajo ese supuesto de memoria. El entorno de ejecución, los resultados intermedios, el almacenamiento del contexto y las solicitudes concurrentes necesitan espacio adicional. Otra representación de los pesos puede cambiar la necesidad; sin pruebas de calidad, eso no supone recomendar un método concreto de compresión ni una tarjeta gráfica determinada.

Mida el piloto con documentos habituales, longitudes de contexto realistas y la concurrencia esperada. Evalúe conjuntamente calidad de respuesta, duración, requisitos de memoria y coste. Un modelo que responde rápido pero produce regularmente resultados empresariales inutilizables no es una solución eficiente. Incluya también la preparación de los datos y la revisión humana; ese trabajo no desaparece porque el modelo se ejecute en su propio servidor.

Observar nuevas arquitecturas de memoria sin depender de ellas

Para CXL 2.0, CXL Consortium describe la ampliación de memoria y la asignación gestionada de recursos de memoria agrupados. La plataforma, los dispositivos de memoria, el software y posiblemente los conmutadores trabajan conjuntamente. Es una arquitectura técnica documentada, no una promesa de que cualquier placa base existente pueda actualizarse. CXL Consortium: agrupación de memoria con CXL 2.0 ↗

Nuestra valoración: estos enfoques pueden interesar a entornos donde la memoria costosa está distribuida de manera desigual entre numerosos sistemas. No está demostrado el beneficio adicional para un único servidor de archivos pequeño. Compruebe latencias reales, compatibilidad, soporte y esfuerzo de administración. Más capacidad a través de otra ruta de datos no equivale automáticamente a RAM conectada directamente para todas las aplicaciones.

Ya puede preparar lo que resulta útil con independencia de futuros estándares: medir el consumo de RAM por aplicación, fijar presupuestos de memoria razonables y distinguir cuellos de botella de configuraciones defectuosas. Sin comprender su carga, tampoco podrá valorar la rentabilidad de un nuevo método de memoria. Por tanto, sigue siendo valiosa una vía clara de ampliación para la plataforma actual.

La portabilidad surge de dependencias probadas

Tener más opciones entre plataformas de CPU o modelos de alojamiento solo ayuda si la aplicación funciona realmente en ellas. Docker documenta compilaciones multiplataforma para distintas arquitecturas de destino. Esto no hace automáticamente que una imagen de contenedor pueda ejecutarse en cualquier arquitectura: las dependencias y los binarios deben corresponder a la plataforma de destino. Docker: compilaciones multiplataforma ↗

Por eso, al modernizar, haga algo más que generar la imagen: pruebe los flujos de trabajo más importantes en la plataforma de destino prevista. Esto incluye controladores de bases de datos, generación de documentos y bibliotecas externas. Una interfaz abierta facilita el cambio, pero no sustituye un modelo de datos exportable ni la migración de las correspondencias de usuarios y sus permisos.

Para equipos pequeños, una arquitectura manejable con un despliegue documentado puede ser una preparación de futuro mejor que otra plataforma de orquestación. Si resulta necesario escalar, el equipo debe poder gestionarlo. Kubernetes utiliza solicitudes de recursos para programar la ubicación de contenedores y límites para controlar su consumo; también allí siguen siendo necesarias la planificación de capacidad y una configuración adecuada. Kubernetes: gestionar recursos de pods y contenedores ↗

Tres escenarios para la próxima ronda de inversión

Defina un desencadenante para cada escenario. Por ejemplo, revisar la ampliación si el margen cae por debajo del límite acordado durante varios ciclos de carga representativos. Un pico aislado, en cambio, primero necesita explicación. Para un piloto de IA, el desencadenante podría ser un beneficio demostrado en tareas recurrentes. Una gran atención pública no lo sustituye.

Preparación concreta para los próximos 90 días

1. Días 1–30: inventariar aplicaciones, responsabilidades y plazos de soporte. Registrar tendencias de CPU, RAM, almacenamiento y costes durante un ciclo empresarial significativo.
2. Días 31–60: probar una recuperación real y una exportación de datos. Documentar las mayores dependencias manuales y elegir un experimento de mejora limitado.
3. Días 61–90: evaluar el experimento según criterios definidos previamente. Considerar conjuntamente coste, calidad y operación, y ampliar solo cuando se demuestre el beneficio.

Este calendario es una estructura propia y debe ajustarse a la capacidad disponible. El resultado más importante es una ficha de decisión actualizada: qué funciona, dónde están los límites, cuánto cuesta operar y qué supuesto se probará después. Las nuevas tecnologías pueden evaluarse con esa referencia, en vez de reiniciar el plan tras cada anuncio.

Una infraestructura preparada para el futuro no necesita hoy todas las capacidades de mañana. Necesita margen suficiente para desarrollos justificados, recuperación probada y la capacidad de cambiar datos y aplicaciones de forma ordenada. Estas propiedades siguen siendo útiles aunque no se cumplan determinadas previsiones de mercado para 2030.