Zscaler despide al 3% de su plantilla para vender más seguridad basada en IA

Zscaler va a eliminar aproximadamente el 3% de su plantilla mundial para financiar más contratación comercial. La decisión afecta a unos 261 empleados, tomando como referencia los más de 8.700 trabajadores que la compañía tenía el 31 de julio de 2026, y llega pese a que el proveedor de seguridad cloud cerró su último trimestre fiscal con un crecimiento de ingresos del 24,9%.

La paradoja merece atención: una empresa que vende protección frente a amenazas digitales no está recortando porque el mercado de la ciberseguridad se haya evaporado. Está moviendo recursos desde la capacidad interna hacia la adquisición de clientes, la cobertura de empresas medianas y la venta de productos cuyo consumo depende cada vez menos del número de usuarios y cada vez más del uso de datos, cargas de trabajo y capacidades de inteligencia artificial.

El segundo párrafo de esta historia es más incisivo que el titular. El recorte no demuestra debilidad de la demanda de seguridad; demuestra una batalla por convertir crecimiento técnico en distribución rentable. Zscaler parece asumir que tiene tecnología, mercado potencial y productos nuevos, pero que todavía necesita más cobertura comercial para transformar esos activos en contratos, renovaciones y expansión de consumo.

El anuncio, comunicado el 3 de septiembre de 2026, funciona así como una pequeña radiografía del mercado. El gasto en seguridad impulsado por la IA existe, pero no se convierte automáticamente en contratos. Los proveedores tienen que demostrar valor, encontrar al comprador correcto y vender soluciones más complejas a organizaciones que todavía están intentando decidir qué significa exactamente proteger agentes, modelos y flujos de datos automatizados.

El recorte no responde a una caída de ingresos

Los números publicados por Zscaler no describen una compañía en contracción. En el trimestre terminado el 31 de julio de 2026, sus ingresos ascendieron a 898,2 millones de dólares, frente a los 719,2 millones del mismo trimestre de 2025. La mejora fue del 24,9%.

La pérdida neta se redujo de 17,6 millones a 3,4 millones de dólares. El beneficio neto no ajustado alcanzó 198,2 millones, un 35,1% más que los 146,7 millones registrados un año antes. El beneficio por acción no ajustado fue de 1,19 dólares, frente a 0,89 dólares. También superó las previsiones de los analistas citadas en la información original: 1,19 dólares frente a 1,09, y 898,2 millones de ingresos frente a una estimación de 877,6 millones.

La reacción bursátil fue menos entusiasta. La acción cayó 3,80 dólares, un 2,14%, hasta 174 dólares en la negociación posterior a los resultados. Es una señal incómoda para la dirección: superar las expectativas trimestrales no basta si el mercado quiere una aceleración más convincente de la captación de nuevos clientes y una demostración clara de que el gasto en IA se traducirá en crecimiento sostenible.

Zscaler prevé asumir entre 30 y 33 millones de dólares en indemnizaciones y prestaciones asociadas a los despidos. Si se utiliza el punto medio de esa horquilla, el coste equivale a unos 120.000 dólares por cada puesto afectado. La división sirve para dimensionar el anuncio, no para calcular el coste laboral anual de cada persona: incluye conceptos de salida y beneficios, pero no productividad perdida, reorganización ni eventuales contrataciones posteriores.

El mensaje financiero es claro: la compañía considera que puede obtener un retorno mayor colocando dinero en vendedores especializados que manteniendo esos puestos. El mensaje comercial es todavía más importante. Según las declaraciones de la dirección recogidas en la comunicación de resultados y en la llamada con analistas, el problema no es únicamente el producto, sino la capacidad de llevarlo a más compradores y convertir oportunidades en contratos.

La frase sobre el «cuello de botella comercial» es una interpretación de esos datos, no una categoría contable publicada por Zscaler. La dirección habló de aumentar la cobertura, captar nuevos clientes y reforzar las ventas a empresas medianas; de ahí se desprende que la distribución y la conversión son prioridades. Conviene mantener la distinción: el hecho publicado es el recorte y la reasignación de recursos; la lectura sobre el cuello de botella pertenece al análisis.

Qué dijo la compañía y dónde comprobarlo

La fuente primaria para las cifras es el comunicado de resultados de Zscaler correspondiente al trimestre terminado el 31 de julio de 2026, publicado el 3 de septiembre de 2026 y disponible en su página de resultados trimestrales. La presentación empleada por la dirección para explicar las prioridades comerciales debe consultarse en la sección de presentaciones a inversores, junto con el material fechado en septiembre de 2026.

Las declaraciones de Jay Chaudhry no deben confundirse con una obligación contractual ni con una previsión garantizada. Su intervención en la llamada de resultados del 3 de septiembre de 2026 —la transcripción y la grabación se publican en la sección de eventos y presentaciones de Zscaler— sirve para identificar la tesis de la dirección: más cobertura comercial, más especialización y una mayor penetración en organizaciones de menor tamaño.

El documento donde se detalla el recorte y su coste es la comunicación corporativa y la información presentada por la compañía a la Securities and Exchange Commission. El comprador, analista o periodista puede contrastar la cifra en la página de filings de Zscaler en la SEC, revisando el documento fechado el 3 de septiembre de 2026 y cualquier actualización posterior sobre los costes de reestructuración. Esta precisión importa: una noticia sobre despidos puede mezclar una estimación inicial de indemnizaciones con el gasto finalmente reconocido.

Hay, por tanto, tres capas de información. Los ingresos de 898,2 millones de dólares, la plantilla de referencia, los 261 puestos y la horquilla de 30 a 33 millones son hechos publicados. La explicación de que la empresa busca más clientes nuevos y más ventas de expansión procede de declaraciones de la dirección. La conclusión de que el mercado está premiando la distribución rentable más que el simple crecimiento de producto es una inferencia razonable, pero sigue siendo una inferencia.

La verdadera apuesta: vender seguridad a empresas que aún no compran

Jay Chaudhry, fundador, presidente y consejero delegado de Zscaler, ya había reconocido en junio que la empresa no estaba atrayendo suficientes clientes nuevos. La respuesta consiste en reforzar la cobertura de mercado en varios frentes: ejecutivos de cuentas especializados por producto o solución, más presencia geográfica, vendedores dirigidos a clientes empresariales de menor tamaño y recursos adicionales para socios de canal.

La compañía quiere ampliar su alcance hacia empresas con entre 2.000 y 10.000 usuarios mediante distribuidores y revendedores externos. No es una modificación menor del organigrama. Vender directamente a grandes multinacionales y vender a una empresa de tamaño medio a través de un canal exige ciclos comerciales, mensajes, precios, soporte y modelos de implantación distintos.

Una gran entidad puede disponer de arquitectos de seguridad, equipos de compras especializados y presupuesto para integrar varias plataformas. Una organización de 2.000 usuarios puede tener un equipo de seguridad mucho más pequeño, depender de un proveedor de servicios gestionados y necesitar una justificación operativa antes de aprobar una plataforma adicional. El canal puede reducir el coste de acceso, pero también introduce otra capa de gobernanza: el cliente debe entender quién presta el servicio, quién administra las políticas y quién responde cuando la protección falla.

Aquí aparece una tensión que el entusiasmo comercial suele ocultar. Zscaler quiere crecer en empresas medianas porque existe un mercado amplio sin cubrir; esos compradores, precisamente por tener menos margen operativo, suelen exigir una propuesta más sencilla, un despliegue más rápido y una responsabilidad contractual más clara. La especialización comercial puede ayudar a vender. No sustituye la evidencia técnica que el comprador necesita para convertir una demostración en una dependencia operativa.

La empresa también habla de sus equipos de take-up, una unidad comercial creada aproximadamente tres años antes para captar nuevos logotipos y ampliar ventas en clientes existentes. El director financiero, Kevin Rubin, señaló que se añadirán personas tanto para nuevas cuentas como para ventas adicionales. La oportunidad declarada es significativa: Zscaler afirma que trabaja sobre una base de 4.600 empresas de un universo objetivo de 20.000.

Ese dato no equivale a 15.400 clientes listos para firmar. Es un mercado potencial, no una cartera de oportunidades garantizadas. Sí ilustra, en cambio, el problema que la compañía intenta resolver: en los segmentos inferiores del mercado empresarial, la cobertura comercial era más limitada que en la parte alta.

La IA está cambiando qué se vende y cómo se cobra

La estrategia no consiste simplemente en contratar más vendedores para vender las mismas licencias. Zscaler está orientando su oferta hacia seguridad de IA, protección de datos y herramientas para cargas de trabajo cloud. Según las explicaciones de la dirección, estos productos generan cada vez más ingresos sobre la base del consumo y no del número tradicional de usuarios.

La distinción importa. Un producto de acceso seguro diseñado originalmente para usuarios, como ZIA o ZPA, se podía relacionar con el tamaño de la plantilla. Una empresa puede tener 2.000 empleados y ejecutar una cantidad muy distinta de cargas de trabajo, procesar volúmenes de datos diferentes o desplegar cientos de agentes automatizados. El número de personas deja de ser un indicador suficiente del valor consumido y, por tanto, del precio potencial.

Para el proveedor, eso puede ampliar el mercado. Para el comprador, desplaza el riesgo desde la negociación inicial hacia la operación diaria. Una licencia por usuario permite hacer una previsión relativamente estable. Un servicio vinculado a peticiones, volumen de datos, cargas de trabajo o funciones de IA exige saber qué métrica se factura, qué unidad es imponible, qué redondeos se aplican y qué ocurre cuando el uso se separa de la previsión.

El comprador debería exigir, como mínimo, una definición contractual de la unidad de consumo, un método de medición reproducible, acceso a datos de uso exportables y alertas antes de alcanzar los umbrales contratados. Si el proveedor puede cambiar la métrica mediante una actualización del producto, la cláusula debe exigir aviso previo, periodo de transición y una opción de terminación o renegociación cuando el cambio altere materialmente el coste.

También hay que separar telemetría, metadatos y contenido. Que un servicio inspeccione tráfico no responde por sí solo a estas preguntas: ¿se conserva el contenido?, ¿durante cuánto tiempo?, ¿en qué regiones se procesa?, ¿se utiliza para entrenar modelos?, ¿qué subencargados intervienen?, ¿puede el cliente impedir determinados usos? La respuesta debe figurar en el contrato, el anexo de tratamiento de datos y la documentación técnica aplicable, no quedarse en una frase tranquilizadora de una demostración.

La evidencia que el comprador debe exigir

La siguiente tabla no sustituye una revisión jurídica ni técnica. Su utilidad es más prosaica: impedir que una promesa comercial se convierta en una dependencia sin documentación verificable.

El agente que convirtió una previsión razonable en una factura incómoda

Imaginemos una escena operativa, no una hipótesis de laboratorio. Una empresa despliega un agente que clasifica alertas, consulta un modelo externo y reintenta automáticamente las solicitudes que reciben una respuesta incompleta. Durante la prueba, el equipo calcula el coste con 10.000 peticiones diarias. El agente se conecta después a un repositorio histórico, vuelve a procesar documentos ya analizados y, ante un error de autenticación, repite cada llamada varias veces.

Nadie ha cambiado el contrato. Nadie ha aprobado una ampliación presupuestaria. Pero el contador sí ha cambiado. El lunes por la mañana, el equipo de seguridad observa más actividad; finanzas la descubre cuando llega una alerta de consumo o, en el peor caso, la factura. El proveedor puede decir que ha cobrado exactamente lo medido. El cliente puede responder que la medición no estaba vinculada a un control de cambio ni a una autorización humana. Los dos pueden tener razón y el contrato seguir siendo malo.

El control no consiste en prohibir la automatización. Consiste en colocar una barrera entre la capacidad técnica y el gasto: presupuesto por entorno, límites por agente, claves separadas, alertas escalonadas, circuit breaker, aprobación para reintentos masivos y conciliación diaria entre los registros del proveedor, la plataforma cloud y el sistema financiero. En servicios críticos, el equipo que administra las políticas de seguridad no debería ser el único que pueda ampliar el consumo.

La escena tiene una segunda consecuencia. Si el agente envía contenido sensible a un servicio externo, la discusión ya no es solo financiera. Entran en juego la base jurídica, las instrucciones del responsable del tratamiento, la minimización, la retención y las transferencias internacionales. Un modelo de consumo mal definido puede producir una factura inesperada; una arquitectura de datos mal gobernada puede producir un incidente de privacidad.

Qué cambia para un cliente financiero de la Unión Europea

Para un banco, una aseguradora, una entidad de pago o cualquier otra organización incluida en el ámbito de DORA, la adquisición de una plataforma de seguridad cloud no termina con el informe SOC 2 o una certificación. El Reglamento (UE) 2022/2554 exige integrar el riesgo de terceros TIC en el marco de gestión de riesgos y establece requisitos contractuales concretos, especialmente cuando el servicio apoya una función crítica o importante.

El artículo 28 de DORA exige que las entidades financieras gestionen el riesgo TIC de terceros como parte de su marco de riesgo operativo. La relación comercial debe apoyarse en una estrategia, una política de uso de servicios TIC y un registro de información sobre los contratos. El cliente tiene que saber qué servicio está comprando, qué proceso depende de él, qué datos atraviesan la plataforma y qué sustitutos existen.

El artículo 29 aborda la evaluación previa de los acuerdos de servicios TIC. Para el comprador, eso traduce la pregunta «¿funciona el producto?» en otras más incómodas: ¿qué pasa si el proveedor deja de prestar el servicio?, ¿hay una concentración excesiva en una tecnología o región?, ¿la entidad puede recuperar la operación?, ¿el proveedor tiene capacidad financiera y técnica suficiente?, ¿qué dependencia crean sus subcontratistas?

El artículo 30 es el punto contractual decisivo. Los acuerdos sobre servicios TIC deben describir, entre otros elementos, la localización de la prestación y del tratamiento de datos, la protección de la información, la asistencia en incidentes, la cooperación con la autoridad competente, los derechos de acceso, inspección y auditoría, los niveles de servicio y las condiciones de terminación. Cuando la función es crítica o importante, la exigencia de detalle aumenta.

La entidad no debería aceptar una cláusula de auditoría que permita únicamente recibir un informe anual preparado por el proveedor si ese informe no cubre la función contratada o no permite verificar incidentes, subcontratistas y continuidad. DORA no exige que cada cliente pueda desmontar físicamente el centro de datos, pero sí que sus derechos de supervisión sean efectivos y proporcionados al riesgo. Un derecho que solo existe en papel es decoración contractual.

El artículo 31 regula la supervisión de proveedores TIC críticos por las autoridades europeas de supervisión. El hecho de que un proveedor pueda quedar bajo esa supervisión no descarga al cliente de su responsabilidad. Tampoco garantiza que el servicio pueda sustituirse en una semana. La entidad seguirá necesitando un plan de salida, pruebas de recuperación y una valoración de concentración por proveedor, región, producto y subcontratista.

La continuidad exige mirar más allá de la disponibilidad declarada. Un servicio puede tener un SLA de disponibilidad elevado y, aun así, dejar al cliente sin capacidad operativa si se pierden políticas, registros, integraciones o claves. El análisis debe cubrir la indisponibilidad, la degradación parcial, la pérdida de conectividad, la corrupción de configuración y el bloqueo de la cuenta administrativa. En cada caso hay que definir qué funciona localmente, cuánto tiempo puede operar la entidad y qué evidencia queda para reconstruir el incidente.

Los artículos 17 a 23 de DORA, sobre gestión, clasificación y notificación de incidentes relacionados con las TIC, también tienen una traducción práctica. El proveedor debe suministrar información suficientemente rápida y precisa para que la entidad clasifique un incidente, determine su impacto y cumpla sus obligaciones de notificación. Un contrato que promete «notificación sin demora» pero no define canales, campos, reloj de inicio, soporte forense y actualizaciones periódicas deja demasiado trabajo para el momento menos apropiado.

La concentración merece un tratamiento específico. Si la misma plataforma controla acceso, inspecciona tráfico, protege aplicaciones y suministra telemetría, una interrupción puede afectar varias capas a la vez. No basta con contar proveedores legales. Hay que mapear funciones, dependencias técnicas, subcontratistas comunes, regiones y mecanismos de autenticación. El riesgo está en el grafo, no en la lista de nombres del departamento de compras.

Para entidades sometidas a NIS2, el artículo 21 exige medidas de gestión de riesgos que incluyen seguridad de la cadena de suministro, gestión de incidentes, continuidad, gestión de crisis y seguridad en la adquisición, desarrollo y mantenimiento de sistemas. La plataforma puede ser un control de seguridad y, simultáneamente, un componente de la cadena de suministro que debe gobernarse. El producto no demuestra por sí solo el cumplimiento; lo demuestra la combinación de configuración, monitorización, evidencias y respuesta.

La venta de IA no resuelve la pregunta de responsabilidad

Proteger una aplicación que llama a un modelo, controlar los permisos de un agente, filtrar información sensible antes de enviarla a un servicio externo y detectar comportamientos anómalos no son exactamente la misma función. Agruparlas bajo la etiqueta de seguridad de IA puede ser útil comercialmente, pero no debe borrar las diferencias técnicas ni asignar al proveedor una responsabilidad que el contrato no contempla.

El comprador debe exigir una matriz que vincule cada capacidad con un control: autenticación del agente, autorización de herramientas, aislamiento de entornos, inspección de entradas y salidas, prevención de filtración, registro de decisiones, detección de abuso y respuesta. También debe aclarar qué parte ejecuta el proveedor, qué parte queda en manos del cliente y qué ocurre cuando el modelo externo cambia su comportamiento o sus límites.

La cuestión de los datos es igualmente concreta. Si la solución procesa prompts, respuestas, documentos, identificadores o telemetría, el cliente necesita conocer la finalidad, el plazo de conservación, las regiones de tratamiento, los subencargados y las medidas de borrado. Bajo el RGPD, los artículos 28 y 32 resultan especialmente relevantes para la relación con encargados y la seguridad del tratamiento; el artículo 33 fija la notificación de violaciones de datos personales a la autoridad de control, cuando proceda, en un plazo de 72 horas desde que el responsable tenga constancia.

Ese reloj no empieza cuando el proveedor termina su análisis de marketing. El contrato debe establecer cómo comunica indicios, qué información inicial aporta y cómo actualiza la evaluación. Una plataforma de seguridad que no entrega logs utilizables o que tarda demasiado en explicar qué ocurrió puede ser técnicamente sofisticada y operacionalmente insuficiente.

Un plan 30/60/90 para no comprar a ciegas

En los próximos 30 días: inventariar consumo y dependencias

El primer mes no debe dedicarse a renegociar frases abstractas. Hay que construir una línea base. El cliente debe identificar qué productos utiliza, qué funciones son críticas, qué equipos administran políticas, qué datos se procesan, qué regiones intervienen y qué integraciones dejarían de funcionar si el servicio se interrumpe.

En paralelo, debe reconciliar tres fuentes: factura del proveedor, registros de uso de la plataforma y datos internos de cloud, identidad y seguridad. Si no coinciden, hay que documentar por qué. El inventario debe registrar usuarios, cargas de trabajo, agentes, APIs, automatizaciones, subcontratistas y cuentas con capacidad de ampliar el consumo. Conviene nombrar un responsable único, pero con participación de compras, finanzas, seguridad, privacidad, arquitectura y continuidad. Si nadie puede decir quién aprueba un aumento de consumo, el control ya tiene una grieta.

En 60 días: renegociar controles y evidencias

Con la línea base disponible, el cliente debe llevar al proveedor una lista cerrada de cambios: definición de métricas, acceso a exportaciones, alertas, límites, retención, subencargados, auditoría, SLA, notificación de incidentes, asistencia forense y terminación. No hay que pedir «más transparencia»; hay que pedir campos, frecuencias, plazos y formatos.

La renegociación debe distinguir entre los controles que el proveedor puede activar y los que requieren arquitectura del cliente. Una alerta de consumo no sustituye un límite técnico. Un informe de auditoría no sustituye una prueba de recuperación. Un SLA de disponibilidad no sustituye un procedimiento para restaurar políticas. Cada control debe tener propietario, evidencia y una frecuencia de prueba.

En 90 días: probar portabilidad, continuidad y sustitución

El tercer mes debe acabar con una prueba, no con una reunión. El cliente debe exportar políticas, configuraciones, logs, inventarios y evidencias en los formatos acordados. Debe comprobar cuánto tarda la operación y qué elementos no pueden recuperarse. Si el proveedor cobra por la asistencia de salida, ese coste debe estar cuantificado antes de que exista una urgencia.

La prueba de continuidad debe incluir una caída parcial, la pérdida de una cuenta administrativa, una interrupción regional y un fallo de una integración crítica. Para cada escenario hay que medir el tiempo de detección, el tiempo de recuperación, la capacidad de operar en modo degradado y la calidad de los registros. La prueba de sustitución no exige comprar inmediatamente un segundo proveedor, pero sí demostrar qué arquitectura, políticas y controles tendrían que reconstruirse.

El resultado debe presentarse al comité de riesgos o al órgano equivalente con tres decisiones: qué consumo se acepta, qué dependencia se mitiga y qué condición contractual impide renovar. Sin esa escalada, el ejercicio se quedará en un inventario técnicamente impecable que nadie usa para decidir.

Lo que este movimiento dice realmente del mercado

El caso de Zscaler contradice una lectura simplista del gasto en ciberseguridad. No basta con decir que la amenaza crece y que los presupuestos crecerán con ella. La competencia se está trasladando a la conversión comercial: qué proveedor consigue entrar en la arquitectura del cliente, qué plataforma sustituye herramientas existentes y quién puede demostrar un impacto medible en operaciones, riesgo o cumplimiento.

La compañía obtuvo un 57% de sus ingresos trimestrales en América, un 27% en EMEA y un 16% en Asia-Pacífico, según Kevin Rubin. Esa distribución explica por qué la expansión geográfica aparece junto a la especialización por producto. La venta de seguridad cloud no depende únicamente de una campaña global. Cambian los ciclos de compra, los requisitos de residencia de datos, los socios de integración y la presión regulatoria en cada región.

El recorte, leído junto con esas cifras, apunta a una empresa que quiere vender más con una estructura comercial diferente, no a una empresa que haya dejado de creer en su producto. Eso no garantiza que la estrategia funcione. Más vendedores pueden aumentar la cobertura; también pueden acelerar la firma de contratos cuyo consumo, dependencia y coste de salida todavía no están bien entendidos por el comprador.

Ahí está la parte que normalmente desaparece de las presentaciones a inversores. Para el proveedor, el éxito puede medirse en nuevos logotipos, expansión y consumo anualizado. Para el cliente, el éxito debe medirse en previsibilidad presupuestaria, controles de acceso, evidencia de cumplimiento, continuidad y capacidad de sustitución. Son métricas relacionadas, pero no idénticas. Una venta rentable para Zscaler puede ser una mala compra para una entidad que no ha limitado sus agentes ni documentado su salida.

Conclusión: el contrato no puede correr más que los controles

Durante los próximos 30 días, el cliente debe revisar seis cosas sin delegarlas por completo en compras: consumo real, soporte recibido, responsables internos, datos tratados, SLA aplicable y ruta de salida. Debe saber qué se factura, quién puede aumentar el uso, qué ocurre durante una caída, qué información conserva el proveedor y cuánto costaría abandonar el servicio. Si no puede responder a esas preguntas con documentos y registros, todavía no conoce su dependencia.

La expansión comercial de Zscaler puede ser una buena noticia para el mercado si produce más competencia y mejores capacidades de seguridad. También puede acelerar una tendencia menos cómoda: productos que pasan de una licencia relativamente estable a un servicio de consumo conectado a datos, automatizaciones y agentes. En ese modelo, el riesgo no aparece únicamente en la negociación del precio. Aparece el sábado por la noche, cuando un proceso automático multiplica peticiones, cuando una subcontrata cambia de región o cuando una caída deja al equipo sin políticas y sin logs.

La perspectiva propia es esta: para el cliente, el riesgo no es que Zscaler venda más. El riesgo es que el contrato evolucione más rápido que sus controles financieros y de resiliencia. La respuesta no consiste en frenar la IA ni en desconfiar de cada plataforma cloud. Consiste en exigir una unidad de medida verificable, límites que funcionen, derechos de auditoría efectivos, continuidad probada y una salida que exista fuera del PowerPoint. En ciberseguridad, comprar capacidad es sencillo. Comprar capacidad sin comprar una dependencia incontrolada es el trabajo serio.