Ollama na empresa: como rodar um modelo local sem improvisar

Ollama na empresa: como rodar um modelo local sem improvisar

Usar Ollama na empresa é viável quando o servidor tem dono, hardware dimensionado para a carga real, acesso controlado, rede fechada e um processo de atualização. Fora disso, ele continua sendo uma ótima ferramenta de teste, mas não uma infraestrutura. Se ninguém quer assumir esse trabalho, uma API com contrato e logs costuma ser a escolha mais prudente.

Principais pontos

• Ollama resolve bem a execução de modelos abertos em uma máquina sua, mas não entrega sozinho governança, autenticação de usuários nem monitoramento.
• O hardware precisa ser dimensionado pelo uso real (quantas pessoas, quais tarefas, que tamanho de contexto), não pelo que roda bem em uma demonstração.
• Nunca exponha o servidor diretamente à internet ou a toda a rede interna: coloque um proxy com autenticação na frente e limite quem chega até ele.
• Modelos e versões mudam o comportamento das respostas, então atualização exige teste prévio, registro de versão e possibilidade de voltar atrás.
• Se a equipe não tem quem opere o servidor, ou o volume é baixo e irregular, uma API com contrato costuma ser mais segura e mais barata de manter.

O que muda quando o Ollama sai do notebook de quem testa?

No notebook de um desenvolvedor, o Ollama tem um único usuário, dados de teste e nenhuma consequência se travar. Na empresa, as três coisas mudam ao mesmo tempo: várias pessoas passam a depender dele, os dados passam a ser reais e a indisponibilidade vira problema de operação.

A pergunta útil deixa de ser "o modelo responde bem?" e passa a ser "quem cuida disso na segunda-feira de manhã?". Isso inclui quem atualiza, quem libera acesso, quem olha o log quando algo estranho acontece e quem decide desligar. Sem essas respostas, o projeto depende de uma pessoa e de uma máquina, e esse é o tipo de improviso que gera incidente.

Há também a questão do tipo de trabalho. Rodar um modelo local faz sentido para tarefas bem delimitadas: resumir documentos internos, classificar mensagens, extrair campos de textos, apoiar a busca em uma base própria. Para tarefas que exigem raciocínio longo ou ferramentas complexas, modelos abertos pequenos podem ficar abaixo do necessário, e isso precisa ser medido com exemplos da sua operação, não presumido.

Como dimensionar o hardware sem chutar?

O ponto central é a memória. O modelo precisa caber na memória da placa de vídeo (ou na memória do sistema, com desempenho bem menor) e ainda sobrar espaço para o contexto da conversa. Quanto maior o texto enviado a cada pedido, mais memória é consumida além do próprio modelo. Para entender por que o tamanho do texto pesa, vale ler sobre tokens em IA e sobre janela de contexto.

Um roteiro simples para dimensionar:

• Defina as tarefas: o que será pedido ao modelo e com que tamanho típico de entrada e saída.
• Defina a concorrência: quantas pessoas ou sistemas podem pedir ao mesmo tempo no horário de pico, não na média.
• Teste com os modelos candidatos, em versões quantizadas (compactadas) e não quantizadas, comparando qualidade nas suas próprias amostras.
• Meça tempo de resposta com carga simultânea, porque um modelo rápido para uma pessoa pode ficar lento para dez.
• Deixe folga: a máquina de produção não deve operar no limite de memória.

Outros itens costumam ser esquecidos: fonte de energia estável, refrigeração, espaço em disco para vários modelos, backup da configuração e um plano para o caso de a máquina falhar. Se o fluxo for crítico, um único servidor é um ponto único de falha, e isso precisa ser aceito conscientemente ou resolvido com redundância.

Se a carga for irregular (muitos pedidos em alguns horários, quase nenhum no resto), o hardware dedicado fica parado boa parte do tempo. Isso entra na conta da decisão entre local e API, tema que o artigo LLM local ou API trata com mais detalhe.

Quem pode acessar o modelo e como controlar isso?

Por padrão, o servidor do Ollama escuta apenas no endereço local da própria máquina, e a variável de ambiente OLLAMA_HOST permite mudar isso. É nesse momento que muita instalação vira risco: alguém altera a configuração para que outros computadores acessem o servidor e esquece que o serviço não foi pensado para atender usuários diretamente. Confirme na documentação da versão que você usa o que ela oferece de autenticação, porque o desenho típico é colocar uma camada na frente.

Essa camada pode ser um proxy reverso ou um gateway interno que faça:

• Autenticação de quem chama, por usuário ou por sistema, com credenciais individuais e revogáveis.
• Autorização por perfil: quem pode usar qual modelo e para qual finalidade. As boas práticas do OWASP sobre autorização ajudam a estruturar isso.
• Limite de uso por pessoa ou sistema, para que um script em laço não derrube o servidor para todos.
• Registro de quem chamou, quando e para qual finalidade, sem necessariamente guardar o conteúdo completo das conversas.

O registro merece atenção própria. Guardar tudo ajuda a investigar problemas, mas cria uma base nova de dados pessoais e sigilosos. Decida o que registrar, por quanto tempo e quem pode ler. Para dados de pessoas, a LGPD continua valendo mesmo com o modelo rodando dentro de casa: rodar localmente reduz o envio a terceiros, mas não elimina a necessidade de finalidade, minimização e controle de acesso. Quando o uso envolver dados sensíveis ou decisões sobre pessoas, avalie o RIPD para projetos de IA. Orientações oficiais podem ser acompanhadas no site da ANPD.

Por fim, uma regra de política interna: defina o que pode e o que não pode ser colocado no modelo local. Ter o servidor na empresa não torna todo dado automaticamente adequado para ele. O raciocínio é parecido com o da política de uso de ChatGPT na empresa, só que com um perímetro diferente.

Que cuidados de segurança de rede são indispensáveis?

Pense no servidor do modelo como qualquer serviço interno sensível. Os cuidados básicos são conhecidos, mas costumam ser pulados em projetos de IA porque "é só um teste".

• Não publique a porta do Ollama na internet, nem por conveniência temporária. Se for preciso acesso remoto, use VPN ou um proxy autenticado.
• Separe o servidor em uma rede ou segmento próprio, com regras de firewall que permitam apenas os sistemas que realmente precisam chamá-lo.
• Use criptografia em trânsito entre o proxy e os clientes.
• Mantenha o sistema operacional, os drivers da placa de vídeo e o próprio Ollama atualizados, com janela de manutenção combinada.
• Guarde chaves e credenciais fora do código e fora de arquivos soltos no servidor.
• Restrinja quem tem acesso administrativo à máquina, porque quem baixa modelos e altera configuração controla o que o sistema responde.

Há ainda um risco que rede nenhuma resolve: o conteúdo. Se o modelo lê e-mails, PDFs ou páginas externas, um texto malicioso pode tentar induzir comportamentos indevidos, o que se chama injeção de prompt. O guia do OWASP sobre prevenção de injeção de prompt e a lista OWASP Top 10 para aplicações com LLM são boas referências. A regra prática: quanto mais ações o modelo puder executar, mais limites e aprovação humana ele precisa. Um modelo que apenas sugere texto para revisão é bem mais simples de proteger do que um que altera registros ou envia mensagens.

Se o plano inclui agentes com ferramentas, o checklist de segurança do OpenClaw Gateway mostra o tipo de evidência que vale exigir antes de qualquer exposição.

Como tratar atualização de Ollama e de modelos?

Existem duas camadas de atualização, e ambas mudam o comportamento do sistema. A primeira é o próprio Ollama, que recebe correções e melhorias. A segunda são os modelos: uma versão nova, ou um modelo diferente com o mesmo nome comercial, pode responder de outro jeito, ser mais lento ou usar mais memória.

Por isso, evite o "atualizar e ver o que acontece" em produção. Um processo mínimo:

• Registre a versão do Ollama e a identificação exata de cada modelo em uso.
• Mantenha um conjunto de exemplos reais (anonimizados) com respostas esperadas, para comparar antes e depois de qualquer mudança.
• Teste a atualização em um ambiente separado, com o mesmo conjunto de exemplos.
• Só promova para produção se a qualidade e o tempo de resposta se mantiverem dentro do combinado.
• Guarde a versão anterior e saiba como voltar a ela rapidamente.
• Escolha um responsável por acompanhar os avisos de segurança do software e dos modelos que você usa.

Com esse conjunto de exemplos, você também ganha uma forma objetiva de comparar modelos quando surgir uma opção melhor, em vez de decidir por impressão ou por moda.

Passo a passo para um piloto local responsável

O método que aplicamos em projetos de IA vale aqui: mapear, limitar, pilotar e transferir. Em termos de Ollama, fica assim.

• Mapear: descreva o processo atual, quem faz, quanto tempo leva e onde estão os dados. Defina a linha de base antes de ligar qualquer modelo.
• Limitar: escolha um único fluxo, os dados mínimos necessários e as ações permitidas. Comece com o modelo apenas sugerindo, com um humano decidindo.
• Pilotar: rode o fluxo real em um ambiente controlado, com logs, um conjunto de exemplos e uma métrica de sucesso combinada de antemão. O artigo sobre como medir um piloto de automação com IA detalha esse desenho.
• Transferir: ao final, documente a operação (quem atualiza, quem acessa, como voltar atrás) e decida com base nos resultados: expandir, ajustar ou parar.

Cenário ilustrativo: uma distribuidora quer que o modelo resuma chamados internos de suporte de TI e sugira a categoria. Os chamados trazem nomes de funcionários e, às vezes, dados pessoais. A empresa escolhe rodar localmente para manter esse conteúdo dentro da rede, coloca o servidor atrás de um proxy autenticado, libera acesso só ao sistema de chamados e mantém a categoria final sob decisão do atendente. Depois de algumas semanas, compara as sugestões com as categorias escolhidas por pessoas e decide se amplia o uso. Se ninguém na equipe pudesse manter o servidor, a mesma tarefa poderia ir para uma API com contrato adequado de tratamento de dados.

Quando uma API é mais prudente do que rodar o Ollama?

Rodar localmente não é automaticamente mais seguro nem mais barato. Uma API é, em geral, a escolha mais prudente nestes casos:

• Não existe uma pessoa ou equipe responsável por operar, atualizar e proteger o servidor.
• O volume de uso é baixo ou muito irregular, e o hardware ficaria ocioso.
• A tarefa exige qualidade que os modelos abertos que cabem no seu hardware não entregam nos seus testes.
• Você precisa de disponibilidade e suporte contratuais que um servidor único não oferece.
• O fluxo é crítico e não há orçamento de tempo para redundância e monitoramento.

Por outro lado, manter o modelo local tende a fazer mais sentido quando há restrição real sobre onde os dados podem ficar, uso previsível e constante, tarefas bem definidas que modelos menores resolvem e uma equipe técnica disposta a operar o serviço. Muitas empresas acabam num meio-termo: dados sensíveis tratados localmente e tarefas gerais enviadas a uma API, com regras claras sobre o que vai para onde.

Se a dúvida for qual modelo comercial escolher quando a API vencer, o artigo ChatGPT, Claude ou Gemini para empresas ajuda a comparar critérios. Para estruturar o risco de qualquer das duas rotas, o AI Risk Management Framework do NIST oferece um vocabulário útil.

Perguntas frequentes

O Ollama é seguro para usar com dados da empresa? Ele pode ser, desde que o servidor fique em rede fechada, atrás de autenticação, com acesso restrito e registro de uso. O software sozinho não resolve a política de dados: é a configuração e o processo ao redor que determinam o nível de segurança. Para dados pessoais, a LGPD continua se aplicando.

Preciso de uma placa de vídeo dedicada? Em geral, sim, para uso por várias pessoas com boa velocidade, porque a memória da placa define quais modelos cabem e com que rapidez respondem. Rodar apenas no processador pode servir para testes ou tarefas em lote sem urgência. O correto é testar seus modelos e suas tarefas na máquina candidata antes de comprar.

Posso deixar vários funcionários usando o mesmo servidor? Pode, desde que haja uma camada de autenticação e limites de uso na frente, e que o hardware tenha sido dimensionado para o pico de simultaneidade. Sem isso, uma pessoa pode degradar o serviço para todas, e não há como saber quem acessou o quê. Também vale definir quais dados podem ser enviados.

Como decidir entre Ollama e uma API? Compare responsabilidade operacional, sensibilidade dos dados, regularidade do volume e qualidade necessária, usando amostras reais da sua operação. Se não houver quem opere o servidor ou se o uso for baixo e irregular, a API tende a ser mais prudente. Se os dados precisam ficar internos e o uso é constante, o modelo local passa a ser uma opção séria.

Fontes

• OWASP: Top 10 para aplicações com LLM
• OWASP: prevenção de injeção de prompt
• OWASP: guia de autorização
• NIST: AI Risk Management Framework