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 deseja uma abordagem de transferência de arquivos mais pronta para empresas, considere soluções de MFT.

Resultados do benchmark de softwares de servidor SFTP

Desempenho de transferência

Custo operacional

Nota: pontuações mais baixas indicam melhor desempenho.

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

SFTPGo

SFTPGo é um servidor SFTP baseado em Go distribuído como um binário autônomo, com configuração disponível por meio de JSON, variáveis de ambiente, uma interface web de administração e uma API REST. Ele suporta armazenamento local, S3, Google Cloud Storage e backends 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 rejeitou gravações durante o teste de arquivos pequenos, mas desativar 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, aproximadamente 145× abaixo do OpenSSH). Seu desempenho multi-stream também escalou bem sem adotar um modelo de processo por conexão. Essa combinação o tornou o resultado de propósito geral mais forte deste benchmark.

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

HPN-SSH

HPN-SSH é um derivado do OpenSSH orientado a desempenho. Ele é instalado junto com os binários de sistema do OpenSSH 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 de benchmark do OpenSSH até o serviço ser interrompido e mascarado. Fora esse conflito, ele se comportou de forma semelhante ao OpenSSH.

Ele entregou o maior resultado de upload de fluxo único (167.4 MB/s, embora MINA com 166.9 MB/s e SFTPGo com 165.3 MB/s tenham terminado dentro de 1,3%) e a inicialização de processo mais rápida no benchmark (0.88 s), mas herdou o modelo de memória fork-por-conexão do OpenSSH. Sob o limite de 6 GB de memória imposto, 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 no qual o HPN-SSH foi projetado especificamente para se destacar. A latência de rede quase zero remove a maior parte da restrição de produto largura de 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 demais porque é uma biblioteca Java, diferente de 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 autônomo com 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 introduziu mais trabalho de configuração do que qualquer daemon empacotado. A compilação exigiu um alvo de compilador Java moderno explícito, 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, no entanto, o MINA teve bom desempenho: produziu o maior 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 para um produto SFTP voltado a administradores.

OpenSSH

O OpenSSH serviu como implementação de referência. Ele 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 e sshd_config do OpenSSH.

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

O OpenSSH lidou com a carga de trabalho de 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 throughput em 119,4% por Gbps, mas sua arquitetura fork-por-conexão usou comparativamente mais memória por sessão ativa (13.283 MB).

Os resultados de throughput de arquivos grandes exigem uma qualificação adicional: esta instância de 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 throughput 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 do campo.

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.

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

Seu caminho SFTP produziu o menor throughput 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× o próximo mais lento). A exceção foi a escalabilidade de fluxos paralelos: o throughput agregado aumentou substancialmente à medida que a concorrência aumentou, atingindo 3.51× o 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 multiprotocolo 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 vem 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 iniciador em primeiro plano dependia de ser executado 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 dos servidores orientados a throughput: o SFTPPlus teve consumo de memória incremental excepcionalmente baixo por sessão (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), manipulação 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 uma 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 foi 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 no 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 em relação ao throughput alcançado foi alto (433,7% por Gbps, quase o dobro do próximo servidor mais alto). O uso de memória por sessão, por outro lado, permaneceu baixo (0.107 MB) porque o servidor usa uma arquitetura baseada em threads em vez de fork-por-conexão.

Figura 4: editor de usuários 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 falharam com uma resposta do lado do servidor 550 openFile error:Denied! apesar das permissões graváveis do sistema de arquivos e de uma configuração de home de usuário válida.

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 foram negadas globalmente em vez de em um caminho específico, mas não verificamos isso de forma conclusiva. Não tentamos contornar ou falsificar o licenciamento.

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

Figura 6: interface web do CrushFTP.

Metodologia do benchmark de softwares 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, throughput do cliente, CPU disponível e memória onde 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 baseado em memória foram planejados para expor custos de processamento de protocolo, criptografia, concorrência, arquitetura de processo e 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 6 GB de memória forneceu um limite consistente para o teste de sessões concorrentes e tornou visível o custo dos designs de processo por conexão. O tmpfs removeu o throughput normal de disco da maioria dos testes, enquanto o loopback removeu a variabilidade da rede física.

Antes de testar as implementações de SFTP, medimos os tetos aproximados do host de forma independente. AES-128-GCM atingiu 2.737 MB/s, ChaCha20-Poly1305 1.430 MB/s, gravações sequenciais no 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 caminho do servidor e do 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ência porque, neste ambiente, seu comportamento de fluxo único estagnou em aproximadamente 90 MB/s. Nesse ponto, o benchmark estaria medindo uma limitação do cliente em vez de diferenças entre servidores.

Em vez disso, os testes usaram um cliente Go personalizado baseado em 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, correspondendo aos 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: Throughput 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 a intenção de estimar o throughput WAN do mundo real. 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, de disco físico foram removidos.

T1b: Comparação de cifras

O T1b repetiu a carga de trabalho de download forçando AES-128-GCM ou ChaCha20-Poly1305 a partir 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, portanto 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 o throughput agregado mudou quando a mesma carga de trabalho foi 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, mudou a concorrência.

A razão de quatro fluxos para um fluxo foi usada como principal indicador de escalabilidade. Um resultado próximo de um sugere que conexões adicionais pouco fazem para aumentar o throughput, 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 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 ao overhead de abrir, criar, fechar e manipular solicitações. Ele complementa o T1 em vez de servir como outra medição de throughput.

T4: Overhead 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ão 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 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 rodaram sob o mesmo limite de 6 GB de memória.

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

O teto de 500 sessões é um limite 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 deles exigiria um host maior e uma rampa de conexão 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 o processo pai.

A eficiência de CPU foi normalizada como porcentagem de CPU por Gbps de throughput alcançado. 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 o início do processo do servidor até que ele aceitasse sua primeira conexão. Isso captura o overhead de inicialização que é amplamente irrelevante para daemons de longa duração, mas pode importar 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 praticamente ausentes quando um processo está aquecido, particularmente entre pequenos daemons nativos e aplicações que devem inicializar uma JVM ou um runtime baseado em Python antes de aceitar conexões.

Interpretação dos 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 largura de banda-atraso, armazenamento remoto e comportamento do cliente podem alterar materialmente o resultado.

O OpenSSH também exige uma qualificação específica: sua conta de benchmark gravou em um diretório home baseado 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 aos outros servidores, embora as medições permaneçam úteis para entender seu comportamento na configuração testada.

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

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

JSCAPE

O 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 suporta o protocolo OFTP2 para transmissão segura de dados nos setores automotivo e outros.

Stonebranch

O recurso de Protocolo de Transferência Segura de Arquivos (SFTP) da Stonebranch faz parte de sua solução de transferência gerenciada de arquivos (MFT) e fornece transferências de dados seguras, confiáveis e automatizadas. Com suporte a vários ambientes de TI, incluindo mainframes, plataformas de nuvem e sistemas híbridos, o recurso de software de servidor SFTP garante criptografia e conformidade com 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 auto-hospedada construída em torno do SFTP. Ele hospeda seu próprio servidor SFTP para parceiros de entrada, conecta-se a servidores SFTP de parceiros e aplica criptografia OpenPGP por transação.

O Edge Gateway fica na DMZ e aceita conexões de parceiros, enquanto o servidor Diplomat que executa fluxos de trabalho permanece na rede interna. Nenhuma credencial ou arquivo é armazenado na borda, e o firewall interno não precisa de regras de entrada. Ele é implantado principalmente em setores regulamentados, como saúde, serviços financeiros, governo, varejo e manufatura.

A versão 9.5.1 (outubro de 2026) adiciona controle de algoritmos SSH tanto no servidor quanto no lado do parceiro. Os administradores podem ativar, desativar e reordenar os algoritmos de troca de chaves, assinatura, cifra, HMAC e compactação, e algoritmos obsoletos são desativados por padrão.

Clientes SFTP de entrada são verificados em relação à reputação de IP de Inteligência de Ameaças. Uma nova lista de substituição admite parceiros verificados em endereços de nuvem compartilhados sem desativar o bloqueio. A opção TOTP adicionada para usuários do Portal de Transferência Web na mesma versão não se aplica ao SFTP, que ainda depende de autenticação baseada em chave e regras de acesso por IP.

Cerberus FTP Server

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

GoAnywhere MFT

O GoAnywhere MFT fornece 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, 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)
• Top 6 soluções de software AS2: escolhas de mais de 400 avaliações
• Axway Transferência Gerenciada de Arquivos: 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  = oct,
  howpublished    = {\url{https://aimultiple.com/sftp-server-software}},
  note   = {AIMultiple. Acessado em 27 outubro 2026}
}

Registro de alterações

11 atualizações

202620252024

1. 20 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.

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