Jay Chaudhry & Zscaler: Zero Trust diseñado para la escala en la nube

Qué explica esta historia (más allá del perfil de un fundador)

Esto no es una biografía de Jay Chaudhry. Es una historia práctica sobre cómo Zscaler ayudó a remodelar la seguridad empresarial —y por qué sus decisiones (técnicas y comerciales) importaron.

Aprenderás dos cosas en paralelo:

• Un modelo de seguridad: cómo funciona el “Zero Trust” cuando tus apps y usuarios están repartidos entre servicios en la nube, oficinas y hogares.
• Un modelo de negocio: cómo una compañía de seguridad se adopta en grandes empresas que cambian despacio, compran a través de partners y evitan migraciones riesgosas.

Qué significa “seguridad empresarial moderna” (en cristiano)

La seguridad empresarial moderna es el conjunto de controles que permite a los empleados usar Internet y aplicaciones internas de forma segura, sin asumir que algo es seguro solo porque está “dentro” de la red corporativa. Se trata menos de construir un muro más grande alrededor de un centro de datos y más de comprobar quién se conecta, a qué se conecta y si esa conexión debe permitirse—cada vez.

Los tres pilares a los que volveremos una y otra vez

1. Entrega en la nube: las funciones de seguridad se trasladan de aparatos on‑premise a un servicio que puede escalar globalmente.
2. Zero Trust: el acceso se basa en identidad, contexto y políticas—no en la ubicación de la red.
3. Distribución: la seguridad empresarial se difunde según la realidad de la compra: partners de canal, actores incumbentes y despliegues repetibles.

Qué te llevarás

Al final, podrás explicar la apuesta central de Zscaler en una frase, reconocer dónde Zero Trust reemplaza el pensamiento de la era VPN y ver por qué la estrategia de distribución puede importar tanto como el diseño del producto.

Jay Chaudhry en una página: la lente del fundador

Jay Chaudhry es un emprendedor en serie conocido por ser el fundador y CEO de Zscaler, una compañía que ayudó a empujar la seguridad empresarial desde “proteger la red corporativa” hacia “asegurar usuarios y apps dondequiera que estén”. Antes de Zscaler, fundó y vendió varias startups de seguridad, lo que le dio una visión directa de cómo cambiaban rápidamente el comportamiento de los atacantes y la TI empresarial.

El problema que decidió perseguir

El enfoque de Chaudhry con Zscaler fue sencillo: a medida que el trabajo y las aplicaciones se movían fuera de la red corporativa (hacia Internet público y servicios en la nube), el viejo modelo de enrutar todo a través de un centro de datos central para inspección empezó a fallar.

Ese cambio creó un dilema doloroso para los equipos de TI:

• Si obligas a que todo el tráfico regrese a la sede, el rendimiento se resiente y los usuarios buscan maneras de evitar los controles.
• Si permites que los usuarios vayan directo a las apps en la nube, la visibilidad y la aplicación de políticas se debilitan.

La premisa fundacional de Zscaler fue que la seguridad debía seguir al usuario, no al edificio.

Visión liderada por el fundador que dio forma a una categoría

Lo que destaca es cómo la visión del producto liderada por el fundador influyó en la estrategia desde el inicio:

• Entrega cloud‑first en lugar de enviar appliances que los clientes debían mantener.
• Aplicación de políticas a escala acercando la inspección al punto donde se conectan los usuarios.
• Un punto de vista arquitectónico claro: reducir la confianza implícita, validar el acceso de forma continua y tratar Internet y la nube como el entorno por defecto.

Esto no fue un cambio de marketing; impulsó decisiones de producto, alianzas y la forma en que Zscaler explicaba el “por qué” a compradores corporativos conservadores. Con el tiempo, esa claridad ayudó a convertir “seguridad entregada desde la nube” y “Zero Trust” de ideas a partidas presupuestarias—algo que las grandes empresas podían comprar, desplegar y estandarizar.

Por qué el antiguo modelo perimetral empezó a fallar

Durante años, la seguridad empresarial se construyó alrededor de una idea simple: mantener “las cosas buenas” dentro de la red corporativa y poner un muro alrededor. Ese muro solía ser una pila de appliances on‑premise—firewalls, proxies web, prevención de intrusiones—colocados en unos pocos centros de datos. Los empleados remotos entraban por VPN, que efectivamente “extendía” la red interna a dondequiera que estuvieran.

El modelo pre‑nube en la práctica

Cuando la mayoría de las apps vivían en los centros de datos de la compañía, esto funcionaba razonablemente bien. El tráfico web y de aplicaciones fluía por los mismos puntos de estrangulamiento, donde los equipos de seguridad podían inspeccionar, registrar y bloquear.

Pero el modelo asumía dos cosas que empezaron a no ser ciertas:

• Los usuarios estaban principalmente en oficinas, en redes gestionadas.
• Las aplicaciones estaban mayoritariamente dentro del perímetro.

Por qué se rompió: usuarios ambulantes, SaaS y la web abierta

A medida que los empleados se volvieron más móviles y la adopción de SaaS se aceleró, los patrones de tráfico se invirtieron. Personas en cafeterías necesitaban acceso rápido a Office 365, Salesforce y decenas de herramientas basadas en navegador—a menudo sin tocar nunca un centro de datos corporativo.

Para seguir aplicando políticas, muchas empresas "backhauleaban" el tráfico: enviar las solicitudes de Internet y SaaS de un usuario a la sede primero, inspeccionarlas y luego reenviarlas. El resultado fue previsible: bajo rendimiento, usuarios insatisfechos y una presión creciente para abrir excepciones en los controles.

Los dolores que sintieron primero los equipos de seguridad

La complejidad se disparó (más appliances, más reglas, más excepciones). Las VPN se sobrecargaron y se volvieron riesgosas cuando otorgaban acceso amplio a la red. Y cada nueva sucursal u adquisición significaba otro despliegue de hardware, más planificación de capacidad y una arquitectura más frágil.

Ese hueco—necesitar seguridad consistente sin obligar a que todo pase por un perímetro físico—creó la oportunidad para la seguridad entregada desde la nube que pudiera seguir al usuario y a la aplicación, no al edificio.

Seguridad entregada desde la nube: la apuesta central

La apuesta definitoria de Zscaler era simple de decir pero difícil de ejecutar: entregar seguridad como un servicio en la nube, posicionado cerca de los usuarios, en lugar de como cajas dentro de la red de la empresa.

En este contexto, “seguridad en la nube” no significa proteger solo servidores en la nube. Significa que la propia seguridad se ejecuta en la nube—de modo que un usuario en una sucursal, en casa o en móvil se conecta a un punto de presencia (PoP) cercano, y la política se aplica allí.

Qué significa “inspección en línea” (sin jerga)

“Inlining” es como redirigir el tráfico por un punto de control de seguridad en el camino hacia su destino.

Cuando un empleado visita un sitio web o una app en la nube, su conexión se dirige primero al servicio. El servicio inspecciona lo que puede (según la política), bloquea destinos riesgosos, escanea en busca de amenazas y luego reenvía el tráfico permitido. La meta es que los usuarios no necesiten “estar en la red corporativa” para obtener protección de nivel corporativo—la seguridad viaja con el usuario.

Por qué esto atrae a las empresas

La seguridad entregada desde la nube cambia la realidad diaria para los equipos de TI y seguridad:

• Despliegue más simple: menos appliances que enviar, montar y mantener en cada ubicación.
• Actualizaciones más rápidas: las protecciones se actualizan de forma central, sin esperar ciclos de actualización on‑prem.
• Política consistente: un conjunto de reglas para oficinas, trabajadores remotos y múltiples nubes.

Este modelo también se alinea con cómo trabajan las empresas hoy: el tráfico a menudo va directo a SaaS y a Internet público, no “de vuelta a la sede” primero.

Los trade‑offs (sin hype)

Poner a un tercero en línea plantea preocupaciones reales que los equipos deben evaluar:

• Confianza y manejo de datos: qué se inspecciona, registra, descifra (si acaso) y cómo se retiene.
• Diferencias de visibilidad: algunos equipos echan de menos la sensación táctil del “equipo en la sala”, aunque los paneles mejoren.
• Dependencia del servicio: las caídas o problemas de rendimiento regionales pueden convertirse rápidamente en problemas de negocio.

La apuesta central, entonces, no es solo técnica: es la confianza operativa de que un proveedor en la nube puede aplicar políticas de forma fiable, transparente y a escala global.

Zero Trust, explicado para lectores no técnicos

Zero Trust es un principio simple: nunca asumas que algo es seguro solo porque está “dentro de la red de la empresa.” En su lugar, verifica siempre quién es el usuario, en qué dispositivo está y si debe acceder a una app o dato específico—cada vez que importe.

El cambio: de “acceso a la red” a “acceso a la app”

El pensamiento tradicional de VPN es como dar a alguien una tarjeta que abre todo el edificio una vez pasado el control. Tras la conexión VPN, muchos sistemas tratan al usuario como “interno”, lo que puede exponer más de lo deseado.

Zero Trust invierte ese modelo. Es más como dar acceso a una sala para una tarea. No te "unirás a la red" de forma amplia; solo podrás alcanzar la app para la que estás aprobado.

Ejemplos sencillos del día a día

Un contratista necesita acceso a una herramienta de gestión de proyectos por dos meses. Con Zero Trust, se le permite esa única app—sin dejarle una vía hacia nóminas o herramientas administrativas internas.

Un empleado usa su propio portátil (BYOD) mientras viaja. Las políticas Zero Trust pueden exigir comprobaciones de inicio de sesión más fuertes o bloquear el acceso si el dispositivo está desactualizado, no cifrado o muestra signos de compromiso.

El trabajo remoto se vuelve más fácil de asegurar porque la decisión de seguridad sigue al usuario y a la app, no a la oficina física.

Lo que Zero Trust no es

Zero Trust no es un producto único que compras y “enciendes”. Es un enfoque de seguridad implementado mediante herramientas y políticas.

Tampoco significa “no confiar en nadie” de forma hostil. En la práctica, significa que la confianza se gana continuamente mediante comprobaciones de identidad, postura del dispositivo y el principio de mínimo privilegio—así los errores y brechas no se propagan automáticamente.

Un mapa de alto nivel del enfoque de Zscaler

Zscaler es más fácil de entender como un “punto de control” en la nube que se sitúa entre las personas y lo que intentan alcanzar. En lugar de confiar en un límite de red corporativa, evalúa cada conexión según quién es el usuario y cómo es la situación, y aplica la política adecuada.

Los bloques constructivos centrales

La mayoría de los despliegues se describen con cuatro piezas simples:

• Usuarios: empleados, contratistas, socios—cualquier identidad que inicie sesión.
• Apps y destinos: sitios de Internet (SaaS, web) y apps privadas (sistemas internos).
• Políticas: reglas como “finanzas puede acceder a nóminas”, “bloquear cargas de archivos riesgosas” o “exigir comprobaciones más fuertes fuera de la red”.
• Aplicación en la nube: un servicio de seguridad en la nube aplica esas políticas cerca de donde se conectan los usuarios, en lugar de reenviar el tráfico a un único centro de datos.

Dos carriles: Internet vs. acceso a apps privadas

Conceptualmente, Zscaler divide el tráfico en dos carriles:

• Seguridad Internet/SaaS (secure web gateway): protege la navegación y el uso de apps en la nube—filtrando, inspeccionando y controlando lo que entra y sale de la sesión del usuario.
• Acceso a apps privadas: proporciona conectividad específica a aplicaciones internas sin poner al usuario “en la red” como una VPN tradicional.

Esa separación importa: un carril trata del uso seguro de Internet; el otro, del acceso preciso a sistemas internos.

“Identidad + contexto” sin palabras de moda

Las decisiones no se basan en una dirección IP de oficina confiable. Se basan en señales como quién es el usuario, salud del dispositivo (gestionado vs. no gestionado, parcheado vs. desactualizado) y desde dónde/cómo se conectan.

A qué se traducen estos resultados

Si se hace bien, este enfoque reduce la superficie de ataque expuesta, limita el movimiento lateral si algo sale mal y convierte el control de acceso en un modelo de políticas más simple y consistente—especialmente cuando el trabajo remoto y las pilas de apps cloud‑first son el estándar.

Secure Web Gateway: el lado de Internet de la historia

Cuando la gente habla de “seguridad empresarial”, a menudo imagina apps privadas y redes internas. Pero gran parte del riesgo está en el lado abierto de Internet: empleados visitando sitios de noticias, haciendo clic en enlaces de correo, usando herramientas basadas en navegador o subiendo archivos a apps web.

Una Secure Web Gateway (SWG) es la categoría creada para hacer ese acceso cotidiano a Internet más seguro—sin obligar a que todo el tráfico del usuario pase por una oficina central.

Qué problema resuelve una SWG

En lo más simple, una SWG actúa como un punto de control entre los usuarios y la web pública. En lugar de confiar en lo que el dispositivo alcanza, la pasarela aplica políticas e inspección para reducir la exposición a sitios maliciosos, descargas riesgosas y fugas accidentales de datos.

Protecciones típicas incluyen:

• Filtrado de URL: permitir/denegar por categoría, reputación o política
• Bloqueo de malware: detener archivos conocidos malos, scripts sospechosos y destinos de phishing
• Controles de datos: detectar y prevenir que datos sensibles se suban a lugares no aprobados

Por qué la SWG en la nube se aceleró con SaaS y usuarios móviles

El impulso vino cuando el trabajo se alejó de oficinas fijas hacia SaaS, navegadores y dispositivos móviles. Si los usuarios y las apps están en todas partes, reenviar tráfico a un perímetro corporativo añade latencia y crea puntos ciegos.

La SWG entregada desde la nube encajó con la nueva realidad: la política sigue al usuario, el tráfico se inspecciona cerca de donde se conectan y los equipos de seguridad obtienen control consistente en sedes, sucursales y trabajo remoto—sin tratar a Internet como una excepción.

Reemplazando el pensamiento VPN con acceso centrado en apps

Las VPN se diseñaron cuando “estar en la red” equivalía a “poder alcanzar las apps”. Ese modelo mental se rompe cuando las apps viven en múltiples nubes, SaaS y en una base cada vez menor on‑prem.

Acceso a apps privadas sin exponer la red

El acceso centrado en la app invierte la predeterminación. En lugar de colocar a un usuario dentro de la red interna (y luego confiar en que la segmentación funcione), el usuario se conecta solo a una aplicación específica.

Conceptualmente, funciona como una conexión intermediada: el usuario demuestra quién es y qué puede usar, y entonces se crea un camino corto y controlado hacia esa app—sin publicar rangos de IP internos en Internet y sin dar al usuario visibilidad amplia “interna”.

Por qué la segmentación por app gana la mayoría de los días

La segmentación de red es potente, pero en organizaciones reales suele ser frágil: fusiones, VLANs planas, apps legacy y excepciones se acumulan. La segmentación por app es más fácil de razonar porque se mapea a la intención del negocio:

• Los usuarios de finanzas pueden acceder a la app de finanzas.
• Los contratistas pueden alcanzar una herramienta de proyecto.
• Los administradores pueden llegar a consolas privilegiadas—con controles más estrictos.

Esto reduce la confianza implícita y hace que las políticas de acceso sean legibles: puedes auditar por aplicación y grupo de usuarios en vez de rastrear rutas y subredes.

Un camino de adopción común

La mayoría de los equipos no reemplazan la VPN de la noche a la mañana. Un despliegue práctico suele verse así:

1. Comenzar con una app interna que cause dolor con la VPN (help desk, portal de desarrolladores, herramienta de RR. HH.).
2. Ampliar a un departamento, luego repetir con el siguiente conjunto de apps.
3. Mantener la VPN como respaldo durante la transición y reducir su uso con el tiempo.

Resultados de negocio medibles

Cuando el acceso centrado en apps se hace bien, las ganancias aparecen rápido: menos tickets por VPN, reglas de acceso más claras que seguridad y TI pueden explicar, y una experiencia de usuario más fluida—especialmente para empleados remotos e híbridos que solo quieren que la app funcione sin “conectarse a la red” primero.

Distribución: cómo escala realmente la seguridad empresarial

Los grandes productos de seguridad no se vuelven estándares empresariales por sí solos. En la práctica, “distribución” en seguridad empresarial significa las rutas que un proveedor usa para llegar, ganar y desplegar con éxito dentro de organizaciones grandes—a menudo a través de otras empresas.

Qué incluye realmente la “distribución”

En seguridad, la distribución típicamente abarca:

• Partners de canal y revendedores que presentan el producto, lo empaquetan con otras herramientas y ayudan a navegar la compra.
• Integradores de sistemas (SIs) y proveedores de servicios gestionados (MSPs) que diseñan despliegues, conectan identidad y redes, y gestionan operaciones day‑2.
• Alianzas tecnológicas (proveedores de identidad, endpoints, plataformas en la nube) que facilitan los despliegues y fortalecen la confianza del comprador.

Estos no son complementos opcionales. Son las tuberías que conectan a un proveedor con presupuestos, decisores y capacidad de implementación.

Por qué el canal importa más de lo que muchos esperan

Las grandes empresas compran con cautela. Los partners proporcionan:

• Confianza y validación (“ya lo hemos implementado antes”)
• Ayuda en la implementación cuando los equipos internos están saturados
• Alcance de compra mediante listas de proveedores aprobados y contratos existentes
• Cobertura geográfica y por vertical sin construir una enorme fuerza de ventas directa en todas partes

Para una plataforma como Zscaler, la adopción a menudo depende del trabajo real de migración—mover usuarios fuera de patrones legacy de VPN, integrar identidad y afinar políticas. Los partners pueden hacer que ese cambio parezca manejable.

Cómo la entrega en la nube cambia la dinámica de venta

La entrega en la nube transforma el negocio de instalaciones únicas a suscripción, expansión y renovaciones. Eso cambia la distribución: los partners dejan de ser solo “cerradores de tratos”. Pueden ser socios de despliegue continuo cuyos incentivos se alinean con los resultados del cliente—si el programa está bien diseñado.

Qué observar (para equipos que evalúan proveedores)

Fíjate en los incentivos a partners, la calidad de la capacitación a partners (formación, playbooks, soporte de co‑venta) y cómo funcionan las transferencias de customer success una vez firmado el contrato. Muchos despliegues fallan no porque el producto sea débil, sino porque la propiedad entre proveedor, partner y cliente queda difusa.

Tiempo de categoría: nube, trabajo remoto y SASE/SSE

La compra de seguridad rara vez empieza con “necesitamos mejor seguridad”. Normalmente arranca con un cambio en la red que rompe las antiguas suposiciones: más apps migran a SaaS, sucursales adoptan SD‑WAN o el trabajo remoto se vuelve permanente. Cuando el tráfico ya no fluye por una oficina central, el modelo de “proteger todo en la sede” se transforma en conexiones lentas, excepciones desordenadas y puntos ciegos.

Por qué el momento de la categoría importó

A Zscaler a menudo se le menciona en las mismas conversaciones que SASE y SSE porque esas etiquetas describen un cambio en cómo se entrega la seguridad:

• SSE (Security Service Edge), en términos sencillos: controles de seguridad entregados desde la nube para que los usuarios tengan protección consistente dondequiera que estén.
• SASE (Secure Access Service Edge): la misma idea, más la parte de redes (a menudo SD‑WAN) para que conectividad y seguridad se planifiquen juntas.

El verdadero “beneficio traducido” no es la sigla—es operaciones más simples: menos cajas on‑prem, actualizaciones de políticas más fáciles y acceso directo a apps sin reenviar tráfico por un centro de datos.

Checklist práctico: cuándo evaluar estas soluciones

Una compañía típicamente evalúa enfoques estilo SSE/SASE cuando:

• Una migración a la nube incrementa significativamente el tráfico hacia Internet y SaaS
• Un despliegue SD‑WAN cambia el enrutamiento de sucursales y expone brechas en los controles existentes
• La capacidad de VPN y la experiencia de usuario son problemas crónicos (especialmente para contratistas)
• Las políticas de seguridad difieren entre oficinas porque las herramientas se despliegan sitio por sitio
• El equipo necesita onboarding más rápido para nuevas ubicaciones, adquisiciones o usuarios remotos
• Las auditorías requieren visibilidad clara sobre quién accedió a qué app y desde dónde

Cuando esos desencadenantes aparecen, la categoría “llega” de forma natural—porque la red ya cambió.

Realidades de implementación: qué hace que los despliegues funcionen o fracasen

Comprar una plataforma Zero Trust suele ser la parte fácil. Hacerla funcionar sobre redes desordenadas, aplicaciones heredadas y gente real es donde los proyectos triunfan—o se estancan.

Los obstáculos de adopción más comunes

Las apps legacy son la ofensa recurrente. Los sistemas antiguos pueden asumir “dentro de la red = confiable”, depender de listas de IP hardcoded o fallar cuando el tráfico se inspecciona.

Los otros frenos son humanos: gestión del cambio, rediseño de políticas y debates sobre “quién posee qué”. Pasar de acceso amplio a reglas precisas por app obliga a los equipos a documentar cómo se trabaja realmente—y eso puede sacar a la luz brechas largamente ignoradas.

Stakeholders que debes involucrar temprano

Los despliegues van mejor cuando seguridad no intenta operar sola. Espera coordinar con:

• Equipos de seguridad y redes (enrutamiento del tráfico, decisiones de segmentación)
• TI/help desk (postura de dispositivos, onboarding, soporte a usuarios)
• Cumplimiento/riesgo (registro, manejo de datos, expectativas de auditoría)
• Propietarios de aplicaciones del negocio (qué es crítico, qué puede romper, qué va a cambiar pronto)

Estrategia piloto que reduce el riesgo

Comienza con un grupo de bajo riesgo (por ejemplo, un solo departamento o un subconjunto de contratistas) y define métricas de éxito por adelantado: menos tickets de VPN, acceso más rápido a apps, reducción medible en la superficie de ataque expuesta o mayor visibilidad.

Ejecuta el piloto por iteraciones: migra una categoría de apps a la vez, afina políticas y luego expande. La meta es aprender rápido sin convertir a la empresa entera en un entorno de pruebas.

Realidades operativas: trabajo day‑2

Planea el logging y la resolución de problemas desde el día uno: dónde viven los logs, quién puede consultarlos, cuánto tiempo se retienen y cómo las alertas se integran en la respuesta a incidentes. Si los usuarios no pueden obtener ayuda cuando “la app está bloqueada”, la confianza cae rápido—aunque el modelo de seguridad sea sólido.

Un acelerador práctico (y a menudo pasado por alto) son herramientas internas: portales simples para solicitudes de excepciones, revisiones de acceso, inventarios de apps, seguimiento de despliegues e informes. Los equipos cada vez más construyen estas "apps glue" ligeras internamente en lugar de esperar la roadmap del proveedor. Plataformas como Koder.ai pueden ayudar a prototipar y lanzar estas herramientas web internas rápidamente vía flujos de trabajo impulsados por chat—útil cuando necesitas un dashboard React con backend en Go/PostgreSQL y iteraciones rápidas según maduran políticas y procesos.

Riesgos y compensaciones a considerar (sin hype)

Mover controles de seguridad de appliances que posees a una plataforma en la nube puede simplificar operaciones—pero también cambia los modos de falla que estás asumiendo. Tomar una buena decisión no es tanto “Zero Trust vs. legado” como entender los nuevos modos de fallo.

Riesgo de concentración (un proveedor, muchas funciones)

Si una plataforma provee seguridad web, acceso a apps privadas, aplicación de políticas y logging, reduces el número de herramientas—pero también concentras el riesgo. Una disputa contractual, un cambio de precios o una carencia de producto puede tener un radio de impacto mayor que cuando esas piezas están repartidas.

Dependencia de rendimiento y disponibilidad

La seguridad en la nube añade un salto extra entre usuarios y apps. Cuando funciona bien, los usuarios casi no lo notan. Cuando una región tiene una caída, problema de enrutamiento o capacidad, la “seguridad” puede parecer “Internet caído”. Esto es menos sobre un proveedor y más sobre depender de conectividad siempre disponible.

La mala configuración sigue siendo el riesgo #1

Zero Trust no es un escudo mágico. Políticas mal acotadas (demasiado permisivas, demasiado restrictivas o inconsistentes) pueden aumentar la exposición o interrumpir el trabajo. Cuanto más flexible sea el motor de políticas, más disciplina se requiere.

Cómo los compradores reducen estos riesgos

Los despliegues por fases ayudan: comienza con un caso de uso claro (p. ej., un subconjunto de usuarios o una categoría de apps), mide latencia y resultados de acceso y luego expande. Define políticas en lenguaje claro, implementa monitorización y alertas desde el inicio y planifica redundancia (enrutamiento multi‑región, accesos break‑glass y rutas de fallback documentadas).

Gobernanza que realmente importa

Sabe qué tipos de datos proteges (regulados vs. generales), alinea controles a necesidades de cumplimiento y programa revisiones periódicas de acceso. La meta no es comprar por miedo—es asegurarse de que el nuevo modelo falle de forma segura y predecible.

Conclusiones clave: qué pueden copiar equipos y fundadores

1) Una tesis de producto clara vence a una larga lista de funciones

La lección repetible de Zscaler es foco: mover la aplicación de políticas de seguridad a la nube y hacer que el acceso dependa de la identidad. Al evaluar proveedores (o construir uno), haz una pregunta simple: “¿Cuál es la apuesta arquitectónica que simplifica todo lo demás?” Si la respuesta es “depende”, espera que la complejidad aparezca luego en costo, tiempo de despliegue y excepciones.

2) Claridad de categoría es una estrategia de crecimiento

“Zero Trust” funcionó porque se tradujo en una promesa práctica: menos suposiciones de confianza implícita, menos enredos de red y mejor control a medida que las apps se movían fuera del local. Para los equipos, esto significa comprar resultados, no palabras de moda. Escribe tus resultados deseados (por ejemplo, “sin acceso entrante”, “mínimo privilegio a apps”, “política consistente para usuarios remotos”) y mapea cada uno a capacidades concretas que puedas probar.

3) Los partners escalan la seguridad empresarial más rápido que solo ventas directas

La seguridad empresarial se difunde por redes de confianza: revendedores, GSIs, MSPs y marketplaces de nube. Los fundadores pueden copiar esto construyendo un producto listo para partners desde temprano—empaquetado claro, márgenes previsibles, playbooks de despliegue y métricas compartidas. Los líderes de seguridad también pueden aprovechar partners: úsalos para la gestión del cambio, integración de identidad y migraciones por fases en lugar de intentar capacitar a todos los equipos internamente.

4) Guía práctica para líderes de seguridad que consideran nube/Zero Trust

Comienza con un caso de uso de alto volumen (a menudo acceso a Internet o una app crítica), mide antes/después y expande.

Preguntas clave de despliegue:

• ¿Cuál es la “fuente de la verdad” para identidad (y membresías de grupos)?
• ¿Cómo manejarás apps legacy, contratistas y BYOD?
• ¿Cuál es el plan para la propiedad de políticas: seguridad, redes o compartida?

5) Guía práctica para fundadores sobre distribución y creación de categoría

No te limites a “vender seguridad”—vende una ruta de migración. La historia ganadora suele ser: dolor → primer paso más simple → victoria medible → expansión. Construye el onboarding y los informes que hagan visible el valor en 30–60 días.

Un patrón amigo del fundador es complementar el producto core con apps compañeras rápidas de construir (flujos de evaluación, trackers de migración, calculadoras de ROI, portales para partners). Si quieres crearlas sin rehacer una pila legacy, Koder.ai está pensado para “vibe‑coding” de aplicaciones full‑stack desde chat—útil para llevar herramientas internas o para clientes a producción rápido y luego iterar conforme evoluciona la distribución.

Si quieres profundizar, ve a /blog/zero-trust-basics y /blog/sase-vs-sse-overview. Para ideas de empaquetado, visita /pricing.