Los 8 principales software de servidor SFTP

Comparamos 8 implementaciones de servidor SFTP en un entorno de pruebas controlado, centrándonos en el rendimiento de transferencia, la concurrencia, la sobrecarga de conexión, las cargas de trabajo de archivos pequeños, la eficiencia de recursos y la experiencia operativa.

Si ya utiliza SFTP pero desea un enfoque de transferencia de archivos más preparado para la empresa, considere las soluciones MFT.

Resultados del benchmark de software de servidor SFTP

Rendimiento de transferencia

Costo operativo

Nota: Las puntuaciones más bajas indican un mejor rendimiento.

Lea la metodología para conocer nuestro entorno de pruebas y los procesos de puntuación.

SFTPGo

SFTPGo es un servidor SFTP basado en Go distribuido como un binario independiente, con configuración disponible a través de JSON, variables de entorno, una interfaz de administración web y una API REST. Admite backends de almacenamiento local, S3, Google Cloud Storage y Azure Blob, e incluye funciones operativas como cuotas, reglas de eventos, autenticación de dos factores y métricas de Prometheus.

Figura 1: Ejemplo de inicio de sesión de SFTPGo.

Requirió una configuración mínima durante el benchmark. El principal problema fue un límite de conexiones por host predeterminado que rechazó escrituras durante la prueba de archivos pequeños, pero deshabilitar ese límite resolvió el problema.

Una vez configurado, SFTPGo combinó un alto rendimiento de transferencia con la latencia de handshake más baja del grupo evaluado (25 ms en p50, menos de la mitad del servidor siguiente más rápido) y un bajo consumo de memoria por sesión (0.091 MB, aproximadamente 145× por debajo de OpenSSH). Su rendimiento con múltiples flujos también escaló bien sin adoptar un modelo de proceso por conexión. Esa combinación lo convirtió en el resultado de propósito general más sólido de este benchmark.

Figura 2: Panel de administración de SFTPGo.

HPN-SSH

HPN-SSH es un derivado de OpenSSH orientado al rendimiento. Se instala junto a los binarios de OpenSSH del sistema y conserva esencialmente el mismo modelo de configuración, añadiendo un comportamiento específico de HPN destinado principalmente a redes de alto ancho de banda y alta latencia. Para los administradores familiarizados con OpenSSH, las diferencias operativas son pequeñas.

El paquete inició automáticamente un servicio hpnssh.service durante la instalación, que ocupó el puerto asignado a la instancia de benchmark de OpenSSH hasta que el servicio fue detenido y enmascarado. Aparte de ese conflicto, se comportó de manera similar a OpenSSH.

Ofreció el mayor resultado de subida de un único flujo (167.4 MB/s, aunque MINA con 166.9 MB/s y SFTPGo con 165.3 MB/s terminaron dentro del 1.3 %) y el arranque de proceso más rápido del benchmark (0.88 s), pero heredó el modelo de memoria fork-por-conexión de OpenSSH. Bajo el límite de 6 GB de memoria impuesto, falló cuando la prueba de sesiones concurrentes alcanzó 300 conexiones.

El benchmark se ejecutó íntegramente sobre loopback, por lo que no prueba el entorno en el que HPN-SSH está específicamente diseñado para distinguirse. Una latencia de red cercana a cero elimina la mayor parte de la restricción del producto ancho de banda-retardo a la que apuntan sus modificaciones de ventana más grande. Por tanto, su ventaja en WAN queda fuera del alcance de estos resultados.

Apache MINA SSHD

Apache MINA SSHD se diferencia de los demás porque es una biblioteca Java, a diferencia de un servidor SFTP listo para ejecutar. Para el benchmark, tuvimos que escribir un servidor utilizando los componentes sshd-core y sshd-sftp y luego compilarlo como un JAR independiente con Maven. La aplicación controla las claves de host, la autenticación, el soporte SFTP y la configuración de cifrado, en lugar de un archivo de configuración de servidor convencional.

Esto supuso más trabajo de configuración que cualquier demonio empaquetado. La compilación requirió un objetivo explícito de compilador Java moderno, y la autenticación Ed25519 necesitó una dependencia adicional. El autenticador estándar de claves autorizadas también rechazó el archivo de claves del benchmark debido a sus comprobaciones de permisos, por lo que el servidor de pruebas utilizó una ruta de comparación de claves personalizada.

Sin embargo, una vez en ejecución, MINA se desempeñó bien: produjo el resultado de descarga más sólido (172.4 MB/s), un bajo consumo de memoria por sesión y la segunda mejor eficiencia de CPU medida en la prueba de eficiencia de recursos (132.8 % por Gbps, detrás del 119.4 % de OpenSSH). La principal penalización en tiempo de ejecución fue el tiempo de arranque de la JVM (3.39 s hasta la primera conexión). Por tanto, es un componente de implementación atractivo para aplicaciones que necesitan un endpoint SFTP integrado, pero no un sustituto directo de un producto SFTP orientado al administrador.

OpenSSH

OpenSSH sirvió como implementación de referencia. Estaba presente en el sistema de pruebas Ubuntu y no requirió ninguna instalación adicional de servidor. SFTP se expone a través de internal-sftp, mientras que los usuarios, las claves públicas, las reglas de chroot y los controles de acceso utilizan los mecanismos estándar de cuentas de OpenSSH y sshd_config.

Los problemas operativos fueron problemas familiares de OpenSSH, no inestabilidad en el subsistema SFTP en sí. Una propiedad o permisos incorrectos activaron StrictModes, y el servicio systemd de HPN-SSH ocupó inicialmente el puerto del benchmark. Tras eliminar ese conflicto, el servidor se ejecutó de manera consistente.

OpenSSH gestionó la carga de trabajo de archivos pequeños mejor que cualquier otra implementación evaluada (4.466 archivos por segundo, 42 % por delante del servidor siguiente más rápido) y registró el menor costo de CPU por unidad de rendimiento con 119.4 % por Gbps, pero su arquitectura de fork-por-conexión utilizó comparativamente más memoria por sesión activa (13.283 MB).

Sus resultados de rendimiento de archivos grandes requieren una aclaración adicional: esta instancia del benchmark escribió en el directorio personal del usuario del sistema en disco, mientras que los demás servidores evaluados utilizaron tmpfs. Por tanto, sus valores absolutos de rendimiento T1 y T2 y la cifra de CPU por Gbps normalizada frente a ellos no deben tratarse como directamente equivalentes al resto del grupo.

ProFTPD

ProFTPD proporciona SFTP a través de mod_sftp. No trata SFTP como su protocolo principal. Su sistema de configuración de estilo Apache es maduro y flexible, y el servidor más amplio puede combinar FTP, FTPS y SFTP con autenticación SQL o LDAP y controles de acceso granulares.

También fue el servidor más problemático de configurar durante este benchmark. mod_sftp tuvo que cargarse explícitamente, la política de sobrescritura predeterminada bloqueaba las subidas, la validación de shell afectó al usuario del benchmark y un proceso ProFTPD obsoleto impidió que una instancia posterior se enlazara a su puerto.

Su ruta SFTP produjo el menor rendimiento de descarga (77.2 MB/s) y, con diferencia, la mayor latencia de handshake entre los servidores medidos (423 ms en p50, 3.6× el siguiente más lento). La excepción fue el escalado de flujos paralelos: el rendimiento agregado aumentó sustancialmente a medida que crecía la concurrencia, alcanzando 3.51× el flujo único con cuatro flujos, lo que dio a ProFTPD la mayor relación de escalado en esa prueba. Estos resultados tienen más sentido en entornos que necesitan sus capacidades multiprotocolo maduras que en despliegues que eligen un servidor específicamente por el rendimiento SFTP.

SFTPPlus

SFTPPlus es una plataforma comercial de transferencia de archivos gestionada construida sobre Python y Twisted. Incluye su propio entorno de ejecución de Python y utiliza un formato de configuración legible basado en INI. Además de SFTP, admite FTPS, HTTPS y WebDAV, junto con funciones administrativas, de automatización, auditoría, integración de directorios y alta disponibilidad que se esperan de un producto MFT.

La instalación en sí fue sencilla, pero la gestión de procesos introdujo varios problemas específicos del benchmark. Iniciar como root requirió una configuración de cuenta explícita, el lanzador en primer plano dependía de ejecutarse desde el directorio de instalación y el nombre del proceso en tiempo de ejecución difería de lo que esperaba la lógica de monitoreo inicial.

El rendimiento reflejó prioridades diferentes a las de los servidores orientados al rendimiento: SFTPPlus tuvo un consumo incremental de memoria excepcionalmente bajo por sesión (0.028 MB, el más bajo medido) y una buena latencia de establecimiento de conexión (52 ms en p50), pero subidas de archivos grandes relativamente lentas (41.8 MB/s), gestión de archivos pequeños (244 archivos por segundo) y arranque de proceso (7.49 s, más del doble que el servidor siguiente más lento).

Wing FTP Server

Wing FTP Server es un servidor nativo comercial con una interfaz de administración basada en web y soporte para FTP, FTPS, SFTP, HTTP y HTTPS. La configuración se organiza en torno a dominios y usuarios, con la interfaz web como ruta principal de gestión; también están disponibles la configuración XML y una interfaz de consola basada en Lua.

Figura 3: Panel de administración de Wing FTP.

La interfaz gráfica era más fácil de abordar que la mayoría de las configuraciones basadas en texto, pero varios comportamientos complicaron la automatización. La llamada de creación de dominio en Lua falló repetidamente sin un error útil; rechazó una clave de cliente Ed25519. Al mismo tiempo, RSA-3072 funcionó, y una asignación de directorio personal creada a través de la interfaz gráfica no persistió hasta que la añadimos manualmente.

El rendimiento medido fue notablemente asimétrico: las descargas fueron considerablemente más rápidas que las subidas (129.7 MB/s frente a 34 MB/s, una brecha de 3.8× y la cifra de subida más baja del benchmark), el procesamiento de archivos pequeños fue el más lento del grupo (90 archivos por segundo, frente a 244 del siguiente más lento), y el consumo de CPU en relación con el rendimiento logrado fue alto (433.7 % por Gbps, casi el doble que el servidor siguiente más alto). El uso de memoria por sesión, en cambio, se mantuvo bajo (0.107 MB) porque el servidor utiliza una arquitectura de hilos en lugar de fork-por-conexión.

Figura 4: Editor de usuarios de Wing FTP.

CrushFTP

CrushFTP 11.5.2 se instaló correctamente y aceptó conexiones SFTP mediante autenticación de clave pública Ed25519, pero no pudo incluirse en la comparación de rendimiento. Cada subida falló con un error del lado del servidor 550 openFile error:Denied! a pesar de los permisos de escritura en el sistema de archivos y una configuración de usuario válida.

Figura 5: Ejemplo de inicio de sesión de CrushFTP.

La investigación señaló al estado de registro instalado como la causa probable, porque las escrituras se denegaron globalmente en lugar de en una ruta específica, pero no lo verificamos de manera concluyente. No intentamos omitir ni falsificar la licencia.

Se requiere una licencia de prueba o de producción válida antes de que CrushFTP pueda probarse en las mismas condiciones que los demás servidores, por lo que no podemos extraer ninguna conclusión de rendimiento de esta ejecución.

Figura 6: Interfaz web de CrushFTP.

Metodología del benchmark de software de servidor SFTP

Objetivo de la prueba

El benchmark compara el comportamiento del lado del servidor de las implementaciones SFTP en condiciones controladas. Limitamos o aislamos el almacenamiento, la latencia de red, el rendimiento del cliente, la CPU disponible y la memoria cuando fue posible, para que las diferencias entre las implementaciones de servidor siguieran siendo visibles.

Esto hace deliberadamente que el benchmark sea más limitado que una prueba de transferencia de producción de extremo a extremo. En particular, el uso de loopback y almacenamiento respaldado por memoria pretendía exponer los costes de procesamiento de protocolos, cifrado, concurrencia, arquitectura de procesos y gestión de conexiones, en lugar del rendimiento de la WAN o del sistema de almacenamiento.

Entorno de prueba

Separar la afinidad de CPU del cliente y del servidor redujo la contención directa de CPU entre el generador de carga y el servidor. El límite de memoria de 6 GB proporcionó un límite consistente para la prueba de sesiones concurrentes e hizo visible el costo de los diseños de proceso por conexión. tmpfs eliminó el rendimiento normal del disco en la mayoría de las pruebas, mientras que loopback eliminó la variabilidad física de la red.

Antes de probar las implementaciones SFTP, medimos de forma independiente los límites máximos aproximados del host. AES-128-GCM alcanzó 2.737 MB/s, ChaCha20-Poly1305 1.430 MB/s, las escrituras secuenciales en almacenamiento 2.687 MB/s, las escrituras aleatorias aproximadamente 263.000 IOPS y la red de loopback 1.889 MB/s. Por tanto, los resultados SFTP sustancialmente por debajo de estos valores pueden interpretarse como limitados principalmente por el servidor y la ruta del protocolo, y no por esos subsistemas de hardware individuales.

Implementación del cliente

El comando sftp estándar de OpenSSH no se utilizó como generador principal de transferencias porque, en este entorno, su comportamiento de flujo único se estancó en aproximadamente 90 MB/s. En ese punto, el benchmark habría estado midiendo una limitación del cliente en lugar de diferencias entre servidores.

En cambio, las pruebas utilizaron un cliente Go personalizado basado en github.com/pkg/sftp. Realiza lecturas y escrituras concurrentes para que el servidor se convierta en el lado limitante de la transferencia. El tamaño del paquete SFTP se mantuvo en 32 KB, igualando los valores predeterminados habituales de OpenSSH y pkg/sftp. Durante el desarrollo probamos una configuración de 256 KB, pero provocó fallos en las conexiones OpenSSH, por lo que no la utilizamos.

T1: Rendimiento de flujo único

T1 midió la ruta básica de transferencia de archivos grandes. Subimos un único archivo de 3 GB y lo descargamos, registrando cada dirección de forma independiente. Repetimos cada medición tres veces y conservamos la mediana. Las cachés del sistema de archivos se descartaron entre repeticiones.

Esta prueba no pretendía estimar el rendimiento real de la WAN. Con el cliente y el servidor en la misma máquina, ofrece una visión controlada de la rapidez con la que cada servidor puede procesar un flujo SFTP sostenido cuando se han eliminado la red y, para la mayoría de las implementaciones, los límites del disco físico.

T1b: Comparación de cifrados

T1b repitió la carga de trabajo de descarga forzando AES-128-GCM o ChaCha20-Poly1305 desde el lado del cliente. Esto expuso diferencias en el soporte de cifrado y en la forma en que cada implementación interactúa con las capacidades criptográficas de la CPU del host.

Registramos los cifrados no compatibles o las transferencias fallidas como resultados faltantes. El host admite aceleración AES, por lo que el entorno de pruebas favorece naturalmente las implementaciones eficientes de AES-GCM, pero los resultados siguieron dependiendo de la implementación.

T2: Escalado de flujos paralelos

T2 midió cómo cambiaba el rendimiento agregado cuando la misma carga de trabajo se dividía entre uno, dos y cuatro flujos simultáneos. La cantidad total de datos transferidos se mantuvo fija en 3 GB; por tanto, aumentar el número de flujos modificó la concurrencia.

La relación entre cuatro flujos y un flujo se utilizó como principal indicador de escalado. Un resultado cercano a uno sugiere que las conexiones adicionales apenas aumentan el rendimiento, mientras que una relación mayor indica que el servidor puede aprovechar capacidad de ejecución adicional bajo carga paralela. Como la carga útil total era fija, la prueba enfatiza la concurrencia y la utilización de la CPU, en lugar de recompensar una carga de trabajo mayor.

T3: Carga de trabajo de archivos pequeños

Las transferencias secuenciales grandes no representan cargas de trabajo dominadas por operaciones de sistema de archivos y protocolo. Por tanto, T3 subió 20.000 archivos de 4 KB cada uno y midió los archivos completados por segundo.

A este tamaño, el ancho de banda de transferencia masivo no es el costo principal. Cada archivo requiere una secuencia de operaciones SFTP y trabajo de metadatos del sistema de archivos, lo que hace que la prueba sea sensible a la sobrecarga de apertura, creación, cierre y gestión de solicitudes. Complementa a T1 en lugar de servir como otra medición de rendimiento.

T4: Sobrecarga de conexión y autenticación

T4 realizó 500 sesiones secuenciales. En cada iteración se establecía una conexión, se autenticaba mediante clave pública y se desconectaba sin ejecutar una transferencia sostenida.

Registramos la latencia de conexión como valores p50, p95 y p99, junto con los inicios de sesión completados por segundo. Esto aísla el establecimiento de sesiones SSH/SFTP y hace visibles las diferencias arquitectónicas, incluido el costo adicional de gestión de procesos asociado a los servidores que bifurcan por cada conexión.

Probamos la autenticación de clave pública. Dejamos los mecanismos de contraseña, teclado interactivo, certificado, GSSAPI/Kerberos y autenticación multifactor fuera del benchmark actual, por lo que T4 no debe generalizarse a esos mecanismos de autenticación.

T5: Sesiones concurrentes y escalado de memoria

T5 aumentó progresivamente el número de sesiones simultáneas de 50 hacia 500 y registró tanto el mayor número sostenible de conexiones como la memoria residente consumida por sesión. Todos los servidores se ejecutaron bajo el mismo límite de memoria de 6 GB.

Esta prueba fue particularmente útil para distinguir arquitecturas de servidor. Las implementaciones derivadas de OpenSSH y otras con fork-por-conexión crean una sobrecarga de proceso por sesión sustancial. En cambio, las implementaciones basadas en eventos, en goroutines o en hilos pueden compartir considerablemente más estado entre conexiones. Cuando un servidor fallaba antes de alcanzar la parte superior de la rampa, el punto de fallo se conservaba como parte del resultado, no como una extrapolación de una capacidad superior.

El límite de 500 sesiones es un límite de este entorno de pruebas. No es una afirmación sobre la capacidad máxima de los servidores que lo completaron. Medir su verdadero límite superior requeriría un host más grande y una rampa de conexiones sustancialmente mayor.

T6: Eficiencia de recursos

T6 midió el uso de CPU y de memoria mientras una transferencia continua estaba activa. La utilización de la CPU y el RSS se muestrearon en todo el árbol de procesos del servidor cada 0.5 segundos, en lugar de monitorear únicamente el proceso padre.

La eficiencia de la CPU se normalizó como porcentaje de CPU por Gbps de rendimiento logrado. Esto proporciona contexto: un bajo consumo de CPU es útil si el servidor también transfiere datos a una velocidad significativa.

T7: Arranque en frío

T7 midió el tiempo transcurrido desde el inicio del proceso del servidor hasta que aceptó su primera conexión. Esto captura una sobrecarga de arranque que es en gran medida irrelevante para demonios de larga duración, pero que puede importar en entornos de prueba desechables, contenedores, servicios de corta duración y flujos de trabajo de despliegue automatizado.

La medición también expone diferencias de tiempo de ejecución que en su mayoría desaparecen una vez que un proceso está caliente, en particular entre pequeños demonios nativos y aplicaciones que deben inicializar una JVM o un entorno de ejecución basado en Python antes de aceptar conexiones.

Interpretación de los resultados

Los valores faltantes indican funcionalidad no compatible o una medición que no pudimos completar; no inferimos valores de reemplazo.

El entorno de loopback es especialmente importante al interpretar T1 y T2. Las clasificaciones relativas y el comportamiento de escalado son útiles en este host controlado, pero no trate las cifras absolutas de MB/s como predicciones para una red real. La latencia, la pérdida de paquetes, el producto ancho de banda-retardo, el almacenamiento remoto y el comportamiento del cliente pueden cambiar materialmente el resultado.

OpenSSH también requiere una aclaración específica: su cuenta de benchmark escribió en un directorio personal respaldado por disco en lugar del tmpfs utilizado por las demás implementaciones. Por tanto, sus cifras absolutas de T1 y T2 no son estrictamente comparables con las de los otros servidores, aunque las mediciones siguen siendo útiles para comprender su comportamiento en la configuración probada.

Soluciones de transferencia de archivos gestionadas para SFTP

Si desea más funciones administrativas y mayor facilidad de uso, también puede elegir soluciones de transferencia de archivos gestionadas:

JSCAPE

JSCAPE proporciona una plataforma de transferencia de archivos gestionada con capacidades de servidor SFTP, permitiendo intercambios de archivos cifrados y seguros a través de redes. También admite el protocolo OFTP2 para la transmisión segura de datos en la industria automotriz y otras industrias.

Stonebranch

Stonebranch de La función de Protocolo de Transferencia Segura de Archivos (SFTP) es parte de su solución de transferencia de archivos gestionada (MFT) y proporciona transferencias de datos seguras, confiables y automatizadas. Al admitir diversos entornos de TI, incluidos mainframes, plataformas en la nube y sistemas híbridos, la función de software de servidor SFTP garantiza el cifrado y el cumplimiento de los estándares de seguridad de la industria, lo que la hace adecuada tanto para intercambios de archivos internos como externos.

Diplomat MFT de Coviant Software

Diplomat MFT de Coviant Software es una plataforma de transferencia de archivos gestionada local construida en torno a SFTP como su capa principal de transporte seguro, con cifrado PGP como capacidad de primera clase. Coviant Diplomat MFT está diseñado para organizaciones de industrias reguladas, como salud, servicios financieros, gobierno y fabricación, que necesitan automatización de flujos de trabajo sin código, herramientas de cumplimiento integradas y un modelo de implementación estable y autoalojado.

Cerberus FTP Server

Cerberus FTP Server es una solución basada en Windows diseñada para configuraciones locales o en la nube. Incluye integración AD/LDAP, SSO, transferencias de cliente web y cumplimiento de estándares de cifrado como FIPS 140-2. Las funciones esenciales incluyen escaneo automatizado, automatización basada en eventos y soporte para cumplimiento de HIPAA.

GoAnywhere MFT

GoAnywhere MFT proporciona una solución SFTP segura para transferencias de archivos, haciendo hincapié en el cifrado y el cumplimiento. Su objetivo es garantizar la integridad y confidencialidad de los datos, con funciones para la gestión de claves, autenticación y registro, dirigido a organizaciones que priorizan intercambios de datos seguros y regulados.

Lecturas adicionales

• Las 10 mejores soluciones de transferencia de archivos gestionadas (MFT)
• Las 6 mejores soluciones de software AS2: selecciones a partir de 400+ reseñas
• Axway Managed File Transfer: aspectos clave a considerar

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Cita este benchmark

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Ermut, Sıla},
  title  = {{Los 8 principales software de servidor SFTP}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/sftp-server-software}},
  note   = {AIMultiple. Recuperado el 20 de Agosto de 2026}
}

Registro de cambios

11 actualizaciones

1. 202620 de Ago

   Se añadió una sección de metodología de benchmark sobre ocho servidores SFTP.

2. 3 de Abr

   Se reemplazó la sección de Files.com por una nueva sección sobre Diplomat MFT de Coviant Software.

3. 12 de Ene

   Se añadieron Stonebranch y Files.com a la lista de soluciones de servidor SFTP.

4. 202525 de Sep

   Eliminado Globalscape MFT y MOVEit Managed File Transfer de la lista de soluciones analizadas.

5. 15 de Sep

   Eliminado MOVEit Managed File Transfer de la lista de software de servidor SFTP.

6. 6 de Mar

   Eliminada la Figura 1 y la Figura de la sección Cerberus.

7. 15 de Ene

   Se añadió Stonebranch a la sección "Los 8 mejores programas de servidor SFTP en 2026".

8. 20243 de Oct

   Se añadieron JSCAPE, Cerberus FTP, MOVEit, GoAnywhere MFT, Files.com, Thru y SolarWinds SFTP/SCP Server a la introducción.

9. 2 de Jul

   Se añadió un enlace a soluciones SFTP gratuitas en la introducción.

10. 28 de May

    Se añadió Cerberus FTP Server a la lista de las principales soluciones de servidor SFTP.

11. 24 de Abr

    Se añadió JSCAPE a la lista de software de servidor SFTP.

Cem Dilmegani

Analista Principal

Síguenos

Cem ha sido el analista principal en AIMultiple desde 2017.

El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]

A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.

Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.

Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.

Ver perfil completo

Investigado por

Sıla Ermut

Analista de la industria

Síguenos

Sıla Ermut es analista de la industria en AIMultiple y cubre modelos de IA, infraestructura de IA, gobernanza de IA y aplicaciones empresariales de IA. Su investigación se centra principalmente en el uso de la IA en marketing, atención sanitaria, cadenas de suministro y sostenibilidad.
Anteriormente trabajó como reclutadora en empresas de gestión de proyectos y consultoría. Sıla tiene un máster en Psicología Social y una licenciatura en Relaciones Internacionales.

Ver perfil completo

Sé el primero en comentar

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario