Perspectivas 2026–2027: infraestructura IT para PyMEs en Latinoamérica y el sur de Europa

Ninguna de estas cinco fuerzas es nueva en sí misma — la conectividad satelital existe hace años, la inteligencia artificial lleva un buen tiempo en boca de todos, NIS2 ya tiene guía propia en este mismo sitio. Lo que cambió es que las cinco están actuando al mismo tiempo sobre la misma PyME, y ninguna de ellas se puede resolver comprando un producto puntual. Es un cambio de cómo se diseña la infraestructura, no de qué caja se compra.

• Conectividad satelital que dejó de ser un parche de emergencia y pasó a ser infraestructura primaria en sitios remotos.
• IA operativa y agentes que empiezan a tomar decisiones sobre la red, no solo a generar reportes.
• Presión regulatoria — NIS2, protección de datos — que ya no es solo un tema de la casa matriz europea.
• Trabajo distribuido que dejó de ser una excepción pandémica y se volvió arquitectura permanente.
• Costo de energía que empezó a pesar en decisiones de diseño que antes eran puramente técnicas.

Durante años, la conectividad satelital fue el plan B: el enlace de respaldo que se activaba cuando la fibra o el 4G fallaban, con latencia alta y un costo que solo se justificaba en sitios verdaderamente aislados. Eso cambió. Las constelaciones satelitales de órbita baja bajaron la latencia a niveles que soportan videollamadas y aplicaciones en tiempo real, y el equipo de instalación pasó de ser un proyecto de ingeniería civil a una antena que se monta en un día.

Lo que estamos viendo en terreno es que la conectividad satelital dejó de ser el respaldo del respaldo para convertirse en el enlace primario de sitios donde antes directamente no había alternativa — pozos petroleros, estancias, embarcaciones, centros de salud rurales. Y en sitios que sí tienen fibra u otras alternativas terrestres, cada vez más operaciones la usan como segundo enlace activo en un esquema de failover automático, no como una antena guardada en un depósito para el día que se corte la fibra.

Durante mucho tiempo, 'IA en la infraestructura' significó un dashboard con gráficos más lindos. Lo que estamos empezando a ver en el campo es distinto: agentes que no solo alertan sobre una anomalía en la red, sino que ejecutan la primera línea de respuesta — reiniciar un servicio, aislar un dispositivo comprometido, escalar automáticamente cuando el patrón supera un umbral conocido. La diferencia entre monitorear y operar.

Esto no es ciencia ficción de laboratorio: es la misma lógica de automatización que ya usamos para backups, failover de conectividad y alertas proactivas, extendida a decisiones más finas. La PyME que hoy diseña su infraestructura pensando solo en 'que la vea un humano en un dashboard' está construyendo sobre una arquitectura que en poco tiempo va a quedar corta frente a una que ya nació pensada para que un agente pueda operar sobre ella — con la supervisión humana en el lugar correcto: aprobando, no ejecutando cada paso manualmente.

Ya escribimos una guía completa sobre NIS2 porque el tema lo amerita, así que acá no vamos a repetir el detalle técnico. Lo que sí vale la pena decir en este informe es cómo cambió la conversación en el terreno: hace dos años, NIS2 era un tema que preguntaban las empresas europeas con casa matriz en la Unión Europea. Hoy lo preguntan PyMEs latinoamericanas que le venden a un cliente europeo, o que forman parte de una cadena de suministro que sí está alcanzada.

El patrón que se repite es siempre el mismo: no es la ley la que empuja el cambio, es el cliente. Un cuestionario de seguridad que llega junto con un contrato, una cláusula nueva que antes no estaba, una auditoría de proveedor que antes no existía. La protección de datos personales — más allá de NIS2 puntualmente — sigue la misma lógica: cada vez más contratos, en cada vez más países, exigen evidencia de gestión de riesgo que antes era opcional.

El trabajo remoto dejó de ser la excepción de 2020 y se volvió, en la mayoría de las operaciones que vemos, una condición estructural: personal técnico que opera un sitio remoto sin estar físicamente ahí, equipos administrativos repartidos entre oficina y casa, proveedores que necesitan acceso puntual a un sistema sin quedarse con una llave permanente.

Lo que cambia con esto no es solo 'permitir VPN' — es rediseñar el control de acceso desde cero: quién entra, a qué, por cuánto tiempo, con qué nivel de autenticación. Las operaciones que siguen tratando el acceso remoto como una excepción puntual — una VPN que se activa 'para el que la necesite' — son las que después terminan con una superficie de ataque que nadie audita porque nadie la diseñó a propósito.

• Acceso segmentado por rol, no una VPN plana que abre toda la red interna.
• MFA como piso mínimo, no como opción para 'los sistemas críticos'.
• Accesos de proveedor con vencimiento automático, no permanentes por comodidad.

Hasta hace poco, el costo de la energía era una línea del presupuesto de operaciones, no una variable de diseño técnico. Eso cambió en las operaciones que vemos en Argentina, Chile e Italia: el consumo eléctrico de racks, UPS, sistemas de refrigeración y equipamiento de red empezó a entrar en la conversación desde el primer dibujo del proyecto, no como un ajuste posterior.

Esto se nota especialmente en sitios remotos que dependen de generación propia — solar, generador diésel, o una combinación — donde cada watt que consume un switch o un access point tiene un costo de infraestructura de generación asociado, no solo un costo de factura. Elegir equipamiento por eficiencia energética, y no solo por especificación técnica, se volvió parte del criterio de selección, no un detalle secundario.

En sitios conectados a la red eléctrica pública, el driver es distinto pero la conclusión es la misma: diseñar para consolidar equipamiento, reducir redundancia innecesaria y dimensionar UPS y climatización con el costo operativo en mente, no solo con la capacidad técnica.

En Argentina, donde el equipo DITAP tiene la mayor parte de su historia operativa, el patrón más consistente lo vemos en oil & gas: operaciones en zonas donde la conectividad terrestre es cara, lenta de desplegar, o directamente inexistente, y donde la conectividad satelital pasó de ser una excepción a ser el punto de partida del diseño de red, no el plan de contingencia.

En hospitality, el cambio lo notamos en la exigencia del huésped: hace unos años, un WiFi lento generaba una queja verbal en recepción. Hoy genera una reseña pública, y la reseña pesa en la próxima reserva. Eso llevó a que los hoteles que antes veían la red como un gasto de mantenimiento la empiecen a tratar como parte de la experiencia del producto — con la misma seriedad que la limpieza de la habitación o la calidad del desayuno.

En Chile, la geografía manda: operaciones en zonas de acceso complicado, con distancias grandes entre sitios y condiciones climáticas que no perdonan una instalación mal hecha. Ahí es donde más se nota la maduración de la conectividad satelital que mencionamos antes — no como curiosidad tecnológica, sino como la diferencia entre un sitio operativo y un sitio aislado.

En salud, el patrón que vemos es continuidad operativa llevada al extremo: un centro de salud rural no puede darse el lujo de un corte de conectividad de horas, porque de eso depende una historia clínica, una teleconsulta, o directamente una comunicación de emergencia. La infraestructura ahí no es un tema de IT — es un tema de continuidad del cuidado, y así la tratamos cuando la diseñamos.

En Italia, donde DITAP tiene presencia directa, el driver dominante es regulatorio: NIS2 no es una hipótesis, es una conversación que ya está pasando en las mesas donde nos sentamos. La diferencia frente a Latinoamérica no es la tecnología en sí — es la velocidad con la que una PyME italiana necesita poder mostrar evidencia de gestión de riesgo cuando se lo pide un cliente o un socio de negocio.

Eso empuja decisiones que en otros contextos todavía se posponen: documentar procesos que antes eran tácitos, formalizar la segmentación de red que 'funcionaba pero no estaba escrita en ningún lado', y tratar la seguridad gestionada no como un costo extra sino como el requisito de entrada para seguir vendiéndole a ciertos clientes.

• Documentación de procesos de seguridad como requisito comercial, no solo técnico.
• Auditorías de proveedor que antes no existían y ahora son rutina.
• Decisiones de infraestructura que se toman con la cadena de suministro en mente, no solo con la operación propia.

Si tu operación es un solo sitio — una oficina, un hotel, una planta — la prioridad de los próximos 12 meses no es escalar infraestructura que todavía no necesitás. Es cerrar las brechas básicas que hoy generan el riesgo más alto por menor esfuerzo: conectividad redundante, backup verificado — no solo configurado —, y seguridad gestionada que no dependa de que una sola persona se acuerde de aplicar el parche.

El error más común que vemos en single-site es invertir en features avanzadas antes de resolver lo elemental: un firewall gestionado y un esquema de backup 3-2-1 hacen más por tu resiliencia real que cualquier herramienta de IA operativa que todavía no tenés la base para aprovechar.

Si operás varias sedes, sucursales u hoteles, el problema no suele ser la falta de infraestructura — es la falta de estándar. Cada sitio nuevo hereda las decisiones técnicas de quien lo abrió, y el resultado típico es una operación con calidad despareja y visibilidad fragmentada: nadie en la casa matriz puede responder, con confianza, 'qué firewall tenemos en la sucursal tres' sin llamar a alguien.

La prioridad de los próximos 12 meses es la estandarización con monitoreo centralizado: el mismo criterio técnico en cada sede, visible desde un solo panel, con conectividad redundante en cada sitio para no depender de un único enlace por ubicación.

Si tu operación está abriendo sitios nuevos a un ritmo rápido, el riesgo no es técnico en el sentido clásico — es de deuda técnica acumulada. Cada apertura apurada sin un estándar previo es una decisión que alguien va a tener que deshacer en dos años, con el costo de hacerlo sobre una operación que ya está en producción.

La prioridad acá es invertir en un playbook de apertura de sede repetible — red, seguridad, conectividad y monitoreo definidos antes de que se abra el primer sitio nuevo del año — y en una arquitectura cloud que escale con la operación sin obligar a rediseñar cada vez que se suma un sitio.

Todo lo que describimos en este informe — conectividad satelital madura, presión regulatoria, trabajo distribuido, costo de energía — converge en un mismo punto: la infraestructura que se diseña hoy tiene que poder ser operada, en parte, por agentes de IA mañana. No como una promesa de marketing, sino como un requisito de arquitectura: redes documentadas, segmentadas y con APIs claras, en lugar de configuraciones tribales que solo entiende la persona que las armó.

En DITAP diseñamos infraestructura AI-native desde el primer diagrama: eso significa monitoreo con datos estructurados que un agente puede leer, automatización con límites y permisos explícitos, y documentación que no vive solo en la cabeza de un técnico. Es la misma disciplina que aplicamos a NIS2 o a un backup 3-2-1 — no vender lo que no hacemos, y construir lo que sí hacemos para que dure más de un ciclo de hardware.

Si te reconociste en alguna de las cinco fuerzas de este informe, el siguiente paso natural es una conversación técnica de 45 minutos donde revisamos tu infraestructura actual contra este mismo marco — sin diagnóstico genérico, con hallazgos concretos para tu operación.