Top 8 softwares de servidor SFTP

Comparamos 8 implementações de servidor SFTP em um ambiente de teste controlado, com foco em desempenho de transferência, concorrência, sobrecarga de conexão, cargas de trabalho com arquivos pequenos, eficiência de recursos e experiência operacional.

Se você já usa SFTP, mas quer uma abordagem de transferência de arquivos mais pronta para empresas, considere soluções MFT.

Resultados do benchmark de software de servidor SFTP

Desempenho de transferência

Custo operacional

Nota: pontuações menores indicam melhor desempenho.

Leia a metodologia para saber mais sobre nosso ambiente de teste e os processos de pontuação.

SFTPGo

SFTPGo é um servidor SFTP baseado em Go distribuído como um binário independente, com configuração disponível por meio de JSON, variáveis de ambiente, uma interface web de administração e uma API REST. Ele oferece suporte a armazenamento local, S3, Google Cloud Storage e backends do Azure Blob, e inclui recursos operacionais como cotas, regras de eventos, autenticação de dois fatores e métricas do Prometheus.

Figura 1: Exemplo de login do SFTPGo.

Ele exigiu configuração mínima durante o benchmark. O principal problema foi um limite padrão de conexões por host que recusou gravações durante o teste com arquivos pequenos, mas desabilitar esse limite resolveu o problema.

Uma vez configurado, o SFTPGo combinou alto desempenho de transferência com a menor latência de handshake do grupo testado (25 ms no p50, menos da metade do servidor mais rápido seguinte) e baixo consumo de memória por sessão (0.091 MB, cerca de 145× abaixo do OpenSSH). Seu desempenho com múltiplos fluxos também escalou bem sem adotar um modelo de processo por conexão. Essa combinação fez dele o resultado de uso geral mais forte neste benchmark.

Figura 2: Painel de administração do SFTPGo.

HPN-SSH

O HPN-SSH é um derivado do OpenSSH orientado a desempenho. Ele é instalado junto com os binários do OpenSSH do sistema e mantém essencialmente o mesmo modelo de configuração, adicionando comportamento específico do HPN destinado principalmente a redes de alta largura de banda e alta latência. Para administradores familiarizados com o OpenSSH, as diferenças operacionais são pequenas.

O pacote iniciou automaticamente um serviço hpnssh.service durante a instalação, que ocupou a porta atribuída à instância OpenSSH do benchmark até que o serviço fosse interrompido e mascarado. Fora esse conflito, ele se comportou de forma semelhante ao OpenSSH.

Ele entregou o maior resultado de upload em fluxo único (167.4 MB/s, embora MINA com 166.9 MB/s e SFTPGo com 165.3 MB/s tenham terminado com uma diferença de 1.3%) e a inicialização de processo mais rápida do benchmark (0.88 s), mas herdou o modelo de memória fork-per-connection do OpenSSH. Sob o limite de memória imposto de 6 GB, ele falhou quando o teste de sessões concorrentes atingiu 300 conexões.

O benchmark foi executado inteiramente em loopback, portanto não testa o ambiente em que o HPN-SSH foi especificamente projetado para se destacar. A latência de rede quase zero remove a maior parte da restrição de produto banda-atraso que suas modificações de janela maior visam. Portanto, sua vantagem em WAN permanece fora do escopo desses resultados.

Apache MINA SSHD

O Apache MINA SSHD difere dos outros porque é uma biblioteca Java, e não um servidor SFTP pronto para executar. Para o benchmark, tivemos que escrever um servidor usando os componentes sshd-core e sshd-sftp e depois compilá-lo como um JAR independente com o Maven. A aplicação controla chaves de host, autenticação, suporte a SFTP e configuração de cifras, em vez de um arquivo de configuração de servidor convencional.

Isso exigiu mais trabalho de configuração do que qualquer daemon empacotado. A compilação exigiu um alvo explícito de compilador Java moderno, e a autenticação Ed25519 precisou de uma dependência adicional. O autenticador padrão de chaves autorizadas também rejeitou o arquivo de chave do benchmark devido às suas verificações de permissão, então o servidor de teste usou um caminho personalizado de comparação de chaves.

Uma vez em execução, porém, o MINA teve bom desempenho: produziu o melhor resultado de download (172.4 MB/s), baixo consumo de memória por sessão e a segunda melhor eficiência de CPU medida no teste de eficiência de recursos (132.8% por Gbps, atrás dos 119.4% do OpenSSH). A principal penalidade em tempo de execução foi o tempo de inicialização da JVM (3.39 s até a primeira conexão). Portanto, é um componente de implementação atraente para aplicações que precisam de um endpoint SFTP embarcado, mas não um substituto direto de um produto SFTP voltado para administradores.

OpenSSH

O OpenSSH serviu como implementação de referência. Ele já estava presente no sistema de teste Ubuntu e não exigiu instalação adicional de servidor. O SFTP é exposto por meio do internal-sftp, enquanto usuários, chaves públicas, regras de chroot e controles de acesso usam os mecanismos padrão de contas do OpenSSH e do sshd_config.

Os problemas operacionais eram problemas familiares do OpenSSH, não instabilidade no subsistema SFTP em si. Propriedade ou permissões incorretas acionavam o StrictModes, e o serviço systemd do HPN-SSH inicialmente ocupou a porta do benchmark. Após eliminar esse conflito, o servidor funcionou de forma consistente.

O OpenSSH lidou com a carga de trabalho com arquivos pequenos melhor do que qualquer outra implementação testada (4.466 arquivos por segundo, 42% à frente do servidor mais rápido seguinte) e registrou o menor custo de CPU por unidade de vazão, com 119.4% por Gbps, mas sua arquitetura de fork por conexão usou comparativamente mais memória por sessão ativa (13.283 MB).

Os resultados de vazão para arquivos grandes exigem uma ressalva adicional: esta instância do benchmark gravou no diretório home do usuário do sistema em disco, enquanto os outros servidores testados usaram tmpfs. Portanto, seus valores absolutos de vazão T1 e T2 e o valor de CPU por Gbps normalizado em relação a eles não devem ser tratados como diretamente equivalentes ao restante dos participantes.

ProFTPD

O ProFTPD fornece SFTP por meio do mod_sftp. Ele não trata o SFTP como seu protocolo principal. Seu sistema de configuração no estilo Apache é maduro e flexível, e o servidor mais amplo pode combinar FTP, FTPS e SFTP com autenticação SQL ou LDAP e controles de acesso granulares.

Ele também foi o servidor mais problemático de configurar durante este benchmark. O mod_sftp teve que ser carregado explicitamente, a política padrão de substituição bloqueou uploads, a validação de shell afetou o usuário do benchmark e um processo antigo do ProFTPD impediu que uma instância posterior se vinculasse à sua porta.

Seu caminho SFTP produziu a menor vazão de download (77.2 MB/s) e, de longe, a maior latência de handshake entre os servidores medidos (423 ms no p50, 3.6× a do próximo mais lento). A exceção foi a escalabilidade de fluxos paralelos: a vazão agregada aumentou substancialmente à medida que a concorrência cresceu, atingindo 3.51× a vazão de fluxo único com quatro fluxos, dando ao ProFTPD a maior taxa de escalabilidade nesse teste. Esses resultados fazem mais sentido em ambientes que precisam de seus recursos maduros de múltiplos protocolos do que em implantações que escolhem um servidor especificamente para desempenho de SFTP.

SFTPPlus

O SFTPPlus é uma plataforma comercial de transferência gerenciada de arquivos construída em Python e Twisted. Ele é fornecido com seu próprio runtime Python e usa um formato de configuração legível baseado em INI. Além do SFTP, ele suporta FTPS, HTTPS e WebDAV, juntamente com funções administrativas, de automação, auditoria, integração de diretórios e alta disponibilidade esperadas de um produto MFT.

A instalação em si foi simples, mas o gerenciamento de processos introduziu vários problemas específicos do benchmark. Iniciar como root exigiu uma configuração explícita de conta, o launcher em primeiro plano dependia da execução a partir do diretório de instalação e o nome do processo em tempo de execução era diferente do que a lógica de monitoramento inicial esperava.

O desempenho refletiu prioridades diferentes das dos servidores orientados a vazão: o SFTPPlus teve consumo incremental de memória por sessão excepcionalmente baixo (0.028 MB, o menor medido) e boa latência de estabelecimento de conexão (52 ms no p50), mas uploads de arquivos grandes relativamente lentos (41.8 MB/s), processamento de arquivos pequenos (244 arquivos por segundo) e inicialização de processo (7.49 s, mais que o dobro do servidor mais lento seguinte).

Wing FTP Server

O Wing FTP Server é um servidor nativo comercial com interface de administração baseada na web e suporte a FTP, FTPS, SFTP, HTTP e HTTPS. A configuração é organizada em torno de domínios e usuários, com a interface web servindo como o principal caminho de gerenciamento; configuração XML e uma interface de console baseada em Lua também estão disponíveis.

Figura 3: Painel de administração do Wing FTP.

A GUI era mais fácil de abordar do que a maioria das configurações baseadas em texto, mas vários comportamentos complicaram a automação. A chamada de criação de domínio em Lua falhou repetidamente sem um erro útil; ela rejeitou uma chave de cliente Ed25519. Ao mesmo tempo, RSA-3072 funcionou, e um mapeamento de diretório home criado pela GUI não persistiu até que o adicionássemos manualmente.

O desempenho medido foi notavelmente assimétrico: os downloads foram consideravelmente mais rápidos que os uploads (129.7 MB/s contra 34 MB/s, uma diferença de 3.8× e o menor valor de upload do benchmark), o processamento de arquivos pequenos foi o mais lento do grupo (90 arquivos por segundo, contra 244 do próximo mais lento), e o consumo de CPU relativo à vazão alcançada foi alto (433.7% por Gbps, quase o dobro do servidor com o próximo valor mais alto). O uso de memória por sessão, por outro lado, permaneceu baixo (0.107 MB) porque o servidor usa arquitetura com threads, em vez de fork por conexão.

Figura 4: Editor de usuário do Wing FTP.

CrushFTP

O CrushFTP 11.5.2 foi instalado com sucesso e aceitou conexões SFTP usando autenticação de chave pública Ed25519, mas não pôde ser incluído na comparação de desempenho. Todos os uploads falhavam com uma resposta 550 openFile error:Denied! do lado do servidor, apesar das permissões graváveis do sistema de arquivos e de uma configuração válida de home do usuário.

Figura 5: Exemplo de login do CrushFTP.

A investigação apontou o estado de registro instalado como a causa provável, porque as gravações eram negadas globalmente, e não em um caminho específico, mas não verificamos isso de forma conclusiva. Não tentamos contornar ou falsificar licenciamento.

Uma licença de avaliação ou de produção válida é necessária antes que o CrushFTP possa ser testado nas mesmas bases que os outros servidores, portanto não podemos tirar nenhuma conclusão de desempenho dessa execução.

Figura 6: Interface web do CrushFTP.

Metodologia do benchmark de software de servidor SFTP

Objetivo do teste

O benchmark compara o comportamento do lado do servidor das implementações de SFTP sob condições controladas. Restringimos ou isolamos armazenamento, latência de rede, vazão do cliente, CPU disponível e memória sempre que possível, para que as diferenças entre as implementações de servidor permanecessem visíveis.

Isso deliberadamente torna o benchmark mais restrito do que um teste de transferência de produção de ponta a ponta. Em particular, o loopback e o armazenamento apoiado em memória foram planejados para expor processamento de protocolo, criptografia, concorrência, arquitetura de processos e custos de gerenciamento de conexões, em vez de desempenho de WAN ou de sistema de armazenamento.

Ambiente de teste

Separar a afinidade de CPU do cliente e do servidor reduziu a contenção direta de CPU entre o gerador de carga e o servidor. O teto de memória de 6 GB forneceu um limite consistente para o teste de sessões concorrentes e tornou visível o custo de projetos de processo por conexão. O tmpfs removeu a vazão normal de disco da maioria dos testes, enquanto o loopback removeu a variabilidade física da rede.

Antes de testar as implementações SFTP, medimos de forma independente os limites aproximados do host. AES-128-GCM atingiu 2.737 MB/s, ChaCha20-Poly1305 1.430 MB/s, gravações sequenciais em armazenamento 2.687 MB/s, gravações aleatórias aproximadamente 263.000 IOPS e rede em loopback 1.889 MB/s. Portanto, resultados de SFTP substancialmente abaixo desses valores podem ser interpretados como limitados principalmente pelo servidor e pelo caminho de protocolo, e não por esses subsistemas de hardware individuais.

Implementação do cliente

O comando sftp padrão do OpenSSH não foi usado como principal gerador de transferências porque, neste ambiente, seu comportamento de fluxo único estabilizou em cerca de 90 MB/s. Nesse ponto, o benchmark estaria medindo uma limitação do cliente, e não as diferenças entre servidores.

Em vez disso, os testes usaram um cliente Go personalizado baseado no github.com/pkg/sftp. Ele realiza leituras e gravações concorrentes para que o servidor se torne o lado limitante da transferência. O tamanho do pacote SFTP permaneceu em 32 KB, igualando os padrões normais usados pelo OpenSSH e pelo pkg/sftp. Testamos uma configuração de 256 KB durante o desenvolvimento, mas ela causou falhas nas conexões OpenSSH, então não a usamos.

T1: Vazão de fluxo único

O T1 mediu o caminho básico de transferência de arquivos grandes. Enviamos um único arquivo de 3 GB e o baixamos, registrando cada direção de forma independente. Repetimos cada medição três vezes e mantivemos o resultado mediano. Os caches do sistema de arquivos foram descartados entre as repetições.

Este teste não teve como objetivo estimar a vazão real de WAN. Com o cliente e o servidor na mesma máquina, ele fornece uma visão controlada da rapidez com que cada servidor pode processar um fluxo SFTP sustentado quando os limites de rede e, para a maioria das implementações, do disco físico são removidos.

T1b: Comparação de cifras

O T1b repetiu a carga de trabalho de download forçando AES-128-GCM ou ChaCha20-Poly1305 do lado do cliente. Isso expôs diferenças no suporte a cifras e na forma como cada implementação interage com as capacidades criptográficas da CPU do host.

Registramos cifras não suportadas ou transferências com falha como resultados ausentes. O host suporta aceleração AES, então o ambiente de teste naturalmente favorece implementações eficientes de AES-GCM, mas os resultados permaneceram dependentes da implementação.

T2: Escalabilidade de fluxos paralelos

O T2 mediu como a vazão agregada mudava quando a mesma carga de trabalho era dividida entre um, dois e quatro fluxos simultâneos. O total de dados transferidos permaneceu fixo em 3 GB; aumentar o número de fluxos, portanto, alterou a concorrência.

A relação entre quatro fluxos e um fluxo foi usada como principal indicador de escalabilidade. Um resultado próximo de um sugere que conexões adicionais pouco fazem para aumentar a vazão, enquanto uma razão maior indica que o servidor pode usar capacidade de execução adicional sob carga paralela. Como a carga útil total foi fixa, o teste enfatiza a concorrência e a utilização de CPU, em vez de recompensar uma carga de trabalho maior.

T3: Carga de trabalho com arquivos pequenos

Transferências sequenciais grandes não representam cargas de trabalho dominadas por operações de sistema de arquivos e de protocolo. Portanto, o T3 enviou 20.000 arquivos de 4 KB cada e mediu os arquivos concluídos por segundo.

Nesse tamanho, a largura de banda de transferência em massa não é o principal custo. Cada arquivo exige uma sequência de operações SFTP e trabalho de metadados do sistema de arquivos, tornando o teste sensível à sobrecarga de abertura, criação, fechamento e tratamento de solicitações. Ele complementa o T1, em vez de servir como outra medição de vazão.

T4: Sobrecarga de conexão e autenticação

O T4 realizou 500 sessões sequenciais. Cada iteração estabeleceu uma conexão, autenticou usando uma chave pública e desconectou sem executar uma transferência sustentada.

Registramos a latência de conexão como valores p50, p95 e p99, juntamente com os logins concluídos por segundo. Isso isola o estabelecimento de sessões SSH/SFTP e torna visíveis as diferenças arquiteturais, incluindo o custo extra de gerenciamento de processos associado a servidores que fazem fork para cada conexão.

Testamos a autenticação por chave pública. Deixamos os caminhos de autenticação por senha, teclado interativo, certificado, GSSAPI/Kerberos e multifator fora do benchmark atual, portanto o T4 não deve ser generalizado para esses mecanismos de autenticação.

T5: Sessões concorrentes e escalabilidade de memória

O T5 aumentou progressivamente o número de sessões simultâneas de 50 para 500 e registrou tanto a maior contagem sustentável de conexões quanto a memória residente consumida por sessão. Todos os servidores foram executados sob o mesmo limite de memória de 6 GB.

Esse teste foi particularmente útil para distinguir arquiteturas de servidor. Implementações derivadas do OpenSSH e outras com fork por conexão criam uma sobrecarga substancial de processo por sessão. Por outro lado, implementações orientadas a eventos, baseadas em goroutines ou com threads podem compartilhar consideravelmente mais estado entre as conexões. Quando um servidor falhava antes de chegar ao topo da rampa, o ponto de falha era mantido como parte do resultado, e não extrapolado como uma capacidade maior.

O teto de 500 sessões é uma limitação deste ambiente de teste. Não é uma afirmação sobre a capacidade máxima dos servidores que o concluíram. Medir o limite superior real exigiria um host maior e uma rampa de conexões substancialmente mais alta.

T6: Eficiência de recursos

O T6 mediu o uso de CPU e memória enquanto uma transferência contínua estava ativa. A utilização de CPU e o RSS foram amostrados em toda a árvore de processos do servidor a cada 0.5 segundos, em vez de monitorar apenas o processo pai.

A eficiência de CPU foi normalizada como porcentagem de CPU por Gbps de vazão alcançada. Isso fornece contexto: baixo consumo de CPU é útil se o servidor também estiver transferindo dados a uma taxa significativa.

T7: Inicialização a frio

O T7 mediu o tempo decorrido desde a inicialização do processo do servidor até que ele aceitasse sua primeira conexão. Isso captura a sobrecarga de inicialização que é amplamente irrelevante para daemons de longa duração, mas pode ser importante para ambientes de teste descartáveis, contêineres, serviços de curta duração e fluxos de trabalho de implantação automatizados.

A medição também expõe diferenças de tempo de execução que estão em grande parte ausentes quando um processo já está aquecido, principalmente entre pequenos daemons nativos e aplicações que precisam inicializar uma JVM ou um runtime baseado em Python antes de aceitar conexões.

Interpretando os resultados

Valores ausentes indicam funcionalidade não suportada ou uma medição que não conseguimos concluir; não inferimos valores substitutos.

O ambiente de loopback é especialmente importante ao interpretar T1 e T2. Classificações relativas e comportamento de escalabilidade são úteis neste host controlado, mas não trate os valores absolutos de MB/s como previsões para uma rede real. Latência, perda de pacotes, produto banda-atraso, armazenamento remoto e comportamento do cliente podem alterar materialmente o resultado.

O OpenSSH também exige uma ressalva específica: a conta do benchmark gravou em um diretório home apoiado em disco, em vez do tmpfs usado pelas outras implementações. Portanto, seus números absolutos de T1 e T2 não são estritamente comparáveis com os dos outros servidores, mesmo que as medições continuem úteis para entender seu comportamento na configuração testada.

Soluções de transferência gerenciada de arquivos para SFTP

Se você quer mais recursos administrativos e facilidade de uso, também pode escolher soluções de transferência gerenciada de arquivos:

JSCAPE

JSCAPE fornece uma plataforma de transferência gerenciada de arquivos com capacidades de servidor SFTP, permitindo trocas de arquivos seguras e criptografadas entre redes. Ele também oferece suporte ao protocolo OFTP2 para transmissão segura de dados nos setores automotivo e outros.

Stonebranch

Stonebranch tem o recurso Secure File Transfer Protocol (SFTP) como parte de sua solução de Transferência Gerenciada de Arquivos (MFT) e oferece transferências de dados seguras, confiáveis e automatizadas. Com suporte a vários ambientes de TI, incluindo mainframes, plataformas em nuvem e sistemas híbridos, o recurso de software de servidor SFTP garante criptografia e conformidade com os padrões de segurança do setor, tornando-o adequado para trocas de arquivos internas e externas.

Diplomat MFT da Coviant Software

Diplomat MFT da Coviant Software é uma plataforma de transferência gerenciada de arquivos on-premise construída em torno do SFTP como sua camada central de transporte seguro, com criptografia PGP como recurso de primeira classe. A Coviant Diplomat MFT é projetada para organizações em setores regulamentados, como saúde, serviços financeiros, governo e manufatura, que precisam de automação de fluxo de trabalho no-code, ferramentas de conformidade integradas e um modelo de implantação estável e auto-hospedado.

Cerberus FTP Server

Cerberus FTP Server é uma solução baseada em Windows projetada para configurações on-premise ou em nuvem. Ele oferece integração AD/LDAP, SSO, transferências via cliente web e conformidade com padrões de criptografia como FIPS 140-2. Os recursos essenciais incluem varredura automatizada, automação orientada a eventos e suporte a conformidade com HIPAA.

GoAnywhere MFT

O GoAnywhere MFT oferece uma solução SFTP segura para transferências de arquivos, com ênfase em criptografia e conformidade. Ele visa garantir a integridade e a confidencialidade dos dados, com recursos para gerenciamento de chaves, autenticação e registro de logs, atendendo a organizações que priorizam trocas de dados seguras e regulamentadas.

Leitura adicional

• Top 10 soluções de Transferência Gerenciada de Arquivos (MFT)
• As 6 melhores soluções de software AS2: escolhas a partir de 400+ avaliações
• Axway Managed File Transfer: principais pontos a considerar

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Cite este benchmark

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

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

Registro de alterações

11 atualizações

1. 202620 Ago

   Adicionada uma seção de metodologia de benchmark sobre oito servidores SFTP.

2. 3 Abr

   Substituída a seção Files.com por uma nova seção sobre o Diplomat MFT da Coviant Software.

3. 12 Jan

   Adicionados Stonebranch e Files.com à lista de soluções de servidor SFTP.

4. 202525 Set

   Removido Globalscape MFT e MOVEit Managed File Transfer da lista de soluções analisadas.

5. 15 Set

   Removido MOVEit Managed File Transfer da lista de software de servidor SFTP.

6. 6 Mar

   Removidas a Figura 1 e a Figura da seção Cerberus.

7. 15 Jan

   Adicionado Stonebranch à seção "Os 8 principais softwares de servidor SFTP em 2026".

8. 20243 Out

   Adicionado JSCAPE, Cerberus FTP, MOVEit, GoAnywhere MFT, Files.com, Thru e SolarWinds SFTP/SCP Server à introdução.

9. 2 Jul

   Adicionado um link para soluções SFTP gratuitas na introdução.

10. 28 Mai

    Adicionado Cerberus FTP Server à lista das principais soluções de servidor SFTP.

11. 24 Abr

    Adicionado JSCAPE à lista de software de servidor SFTP.

Cem Dilmegani

Analista Principal

Siga-nos

Cem é o analista principal da AIMultiple desde 2017.

O trabalho de Cem na AIMultiple foi citado por publicações globais líderes, incluindo Business Insider, Forbes, Morning Brew e Washington Post, por empresas globais como Deloitte e HPE, ONGs como o World Economic Forum e organizações supranacionais como a European Commission. [1], [2], [3], [4], [5]

Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas sobre suas decisões de tecnologia na McKinsey & Company e na Altman Solon por mais de uma década. Ele também publicou um relatório da McKinsey sobre digitalização.

Ele liderou a estratégia de tecnologia e as compras de uma operadora de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de deep tech Hypatos, que atingiu uma receita recorrente anual de 7 dígitos e uma avaliação de 9 dígitos partindo do zero em 2 anos. O trabalho de Cem na Hypatos foi coberto por publicações de tecnologia líderes como TechCrunch e Business Insider.

Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou como engenheiro da computação pela Bogazici University e possui um MBA pela Columbia Business School.

Ver perfil completo

Pesquisado por

Sıla Ermut

Analista do Setor

Siga-nos

Sıla Ermut é analista do setor na AIMultiple, cobrindo models de IA, infraestrutura de IA, governança de IA e aplicações empresariais de IA. Sua pesquisa se concentra principalmente no uso de IA em marketing, saúde, cadeias de suprimentos e sustentabilidade.
Ela trabalhou anteriormente como recrutadora em empresas de gerenciamento de projetos e consultoria. Sıla possui mestrado em Psicologia Social e bacharelado em Relações Internacionais.

Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

Nome

Endereço de email

Comentário

0/450

Postar comentário