Argumentos a favor del modelo «Zero Trust» a escala local

Por Sarang Warudkar - Gestor técnico sénior de marketing de productos

13 de noviembre de 2026 5 Minutos de lectura

La IA se ha trasladado al interior de su red. Su SSE, en cambio, no.

El modelo «zero trust» cobró verdadero impulso cuando los trabajadores pasaron a trabajar a distancia y las aplicaciones se trasladaron a la nube. Los «Cloud Access Security Brokers» (CASB) y, posteriormente, los mercados más amplios de « Security Service Edge » (SSE) y «Secure Access Service Edge» (SASE) crecieron rápidamente porque respondían al riesgo de aquel momento: que un atacante con credenciales robadas pudiera acceder a los recursos corporativos en la nube desde cualquier lugar. Zero Trust Network Access (ZTNA) surgió de la misma manera, cuando los proveedores de SSE ampliaron sus plataformas en la nube para ofrecer una alternativa más económica y menos vulnerable que la VPN. El principio era acertado y sigue siéndolo: validar al usuario, el dispositivo, la ubicación y el contexto circundante, en lugar de confiar únicamente en una credencial.

Lo que ha cambiado no es el principio, sino el lugar donde se lleva a cabo el trabajo.

¿Por qué se volvió a realizar el trabajo en el interior?

Cuatro cambios han propiciado que una parte cada vez mayor de la actividad empresarial vuelva a desarrollarse en redes privadas.

1. Los empleados han vuelto a la oficina. Según una encuesta de Gallup de mayo de 2026, el 74 % de los empleados trabaja en la oficina o en régimen híbrido, el 22 % de ellos a tiempo completo en la oficina y el 52 % en régimen híbrido, con una asistencia de 2,3 días a la semana. En la actualidad, hay más sesiones empresariales que comienzan y terminan en la misma red corporativa que en cualquier otro momento desde 2019.
2. La IA les ha seguido hasta la infraestructura de la empresa. La IA se ha trasladado a la infraestructura de la empresa a medida que el aumento de los costes de los tokens, los problemas de control y las preocupaciones sobre la privacidad de los datos empujan a las cargas de trabajo hacia el ámbito interno. Cuando un modelo de IA se entrena con datos internos —como los de I+D, la lógica de fijación de precios y los registros de clientes—, absorbe la propiedad intelectual fundamental de la empresa y, en la práctica, se convierte en una copia funcional de sus secretos comerciales. Dado que los consejos de administración no están dispuestos a dejar esos activos en servidores de terceros, ejecutar modelos privados y herramientas de IA internas dentro de centros de datos privados es ahora una práctica habitual.
3. Gran parte de las acciones que llevan a cabo estos sistemas nunca traspasan el perímetro. Gartner incluye datos propios en 1 de cada 6 solicitudes de IA (Amenaza de ciberseguridad: compromiso de aplicaciones de IA, 2026), y esa proporción no mejora en absoluto cuando el modelo es interno en lugar de público. Un copiloto interno no tiene nada que filtrar. Accede al almacén de documentos, al sistema de gestión de incidencias y a la base de datos de clientes, ya que para eso se diseñó. Un agente al que se le ha asignado una tarea dispone de credenciales permanentes y actúa con mucha mayor rapidez que la persona que lo autorizó, frente a los sistemas de su propio segmento de red.
4. La soberanía también supone el regreso del modelo operativo. Gartner prevé que el 50 % de las multinacionales, y más del 75 % de las multinacionales no estadounidenses, tengan requisitos de soberanía digital para 2028 (Análisis de previsiones: IaaS en la nube soberana, a nivel mundial, 2025). Una organización que haya implantado un modelo interno precisamente para mantener el material regulado bajo su propia jurisdicción tiene motivos fundados para cuestionar cualquier arquitectura que desvíe la interacción a otro lugar para su inspección.

Cuándo deja de ser adecuado el cumplimiento normativo basado en la nube

La integración de controles de acceso de «confianza cero» en un servicio prestado en la nube tiene todo el sentido del mundo cuando el usuario se encuentra a distancia o la aplicación está en la nube. Sin embargo, tiene mucho menos sentido cuando ambos extremos se encuentran dentro del mismo edificio.

Desviar una sesión interna —o tráfico de agente que se mueve a la velocidad de la máquina— hacia un punto de presencia en la nube para su inspección y aplicación de políticas, solo para enviarlo directamente de vuelta a una aplicación privada o una fuente de datos situada dos plantas más abajo, no resulta viable desde el punto de vista arquitectónico. Aumenta la latencia, consume capacidad de la WAN y crea una dependencia del circuito de Internet para tareas que nunca tuvieron que salir de las instalaciones. La disponibilidad se convierte en una decisión de seguridad, lo cual rara vez es lo que se desea.

El ZTNA en la nube presenta una segunda vulnerabilidad, menos evidente. Por lo general, concede acceso de «confianza cero» a la red, en lugar de a la aplicación concreta que el usuario realmente necesita. La sesión cuenta con privilegios excesivos desde el momento en que se admite, y el movimiento lateral dentro de ese segmento no se ve restringido. Un control implementado para eliminar la confianza implícita acaba reintroduciéndola un nivel más abajo.

Nada de esto es nuevo para el equipo de redes. La segmentación y la visibilidad del tráfico este-oeste han sido un objetivo desde hace años, pero implementar un modelo «zero trust» local sin afectar al comportamiento de los usuarios ni al nivel de riesgo ha supuesto un reto. Lamentablemente, las capacidades de la próxima generación de SSE —como el acceso a nivel de aplicación, la inspección web y TLS, y los controles basados en los datos— han estado a menudo fuera del alcance para proteger las redes internas. Esta brecha es de carácter arquitectónico más que conceptual, razón por la cual subsanarla es una tarea de ingeniería más que una nueva doctrina.

Ahora que los flujos de trabajo de datos se ejecutan a la velocidad de las máquinas en las redes locales, el control de acceso a nivel de aplicación local y la inspección en línea local dejan de ser una mera aspiración para convertirse en un requisito de diseño híbrido. Protegen los datos críticos allí donde realmente se almacenan y circulan, y garantizan la continuidad de la actividad empresarial cuando la conexión a la nube falla.

¿Qué se consigue realmente al acercar los servicios de ejecución?

La proliferación de datos locales se hace evidente. Las herramientas internas de IA llegan sin un registro de adquisición y pasan a ser fundamentales para el negocio antes de que nadie las incluya en el inventario. Las copias de material regulado se acumulan en almacenes vectoriales, conjuntos de ajuste fino y unidades compartidas que ningún control orientado a la nube llega a detectar, ya que nada en ese flujo de trabajo traspasa ningún límite. La inspección de la infraestructura y los flujos de trabajo locales es la única forma de detectarlo.

El acceso se restringe desde la red hasta la aplicación. La autorización por aplicación en el punto de control local elimina el exceso de privilegios que deja la gestión a nivel de red, y lo hace para el usuario de la oficina, que actualmente es el usuario menos supervisado del entorno.

La exposición específica a la IA pasa a ser abordable. La inyección de comandos, los intentos de «jailbreak» y el material propio pegado o escrito discretamente en un comando solo pueden ser gestionados por algo que se encuentre en la ruta de la interacción a nivel del navegador. Cuando dicha interacción nunca sale del sitio web y no hay nada en el sitio que se interponga en su camino, los controles no tienen sobre qué actuar. Volver a incluir el tráfico local en el ámbito de aplicación es lo que hace que la seguridad de la IA sea aplicable, independientemente de dónde se ejecute en última instancia el control en sí.

La resiliencia mejora en lugar de deteriorarse. Un sitio que aplica las medidas de seguridad de forma local sigue realizando inspecciones y aplicando la política de acceso incluso cuando falla la conexión con la nube. Una arquitectura exclusivamente en la nube que se enfrenta a la misma interrupción del servicio debe elegir entre detener el trabajo o permitir que continúe, y nadie toma esa decisión de forma acertada con tan poca antelación.

Ámbitos en los que SSE debe ponerse al día

Nada de esto es una previsión. La gente ya está en las oficinas. Los modelos ya se están ejecutando en la infraestructura de las empresas. Los organismos reguladores ya están planteando cuestiones relacionadas con la soberanía y no dan señales de perder interés.

Lo que aún no se ha tenido en cuenta es dónde deben ubicarse los controles de SSE. La inspección y la aplicación de medidas de SSE en la nube siguen partiendo de la base de que el riesgo se encuentra a la salida del edificio, lo cual refleja cada trimestre una realidad cada vez menos fiel a la realidad.

Pida a su proveedor que le ayude a comprender cómo protegen el funcionamiento local basado en inteligencia artificial; qué controles se ejecutan en las instalaciones, cuáles se ejecutan en la nube y qué ocurre con cada uno de ellos cuando se interrumpe la conexión entre ambos.

Descubra cómo la nueva plataforma Skyhigh Hybrid Mesh SSE está ampliando el modelo «Zero Trust» dentro de la oficina para proteger mejor la IA.

Volver a Blogs