Executar um LLM on-premise é apenas o primeiro passo.
Se o objetivo é a análise de planilhas por IA, apenas o endpoint do modelo não basta. Um usuário de negócios não quer enviar JSON bruto para um servidor de inferência interno. Ele quer fazer o upload de um arquivo, fazer uma pergunta, obter uma resposta confiável, gerar um gráfico e saber de onde vieram os números.
Isso exige uma arquitetura em torno do modelo.
Este guia explica os principais componentes de um sistema de IA para planilhas on-premise.
Arquitetura de referência
Uma arquitetura prática de IA para planilhas on-premise funciona assim:
A ordem pode variar, mas o princípio é consistente: o LLM deve raciocinar e explicar, enquanto sistemas controlados cuidam do acesso aos dados, computação, segurança e auditabilidade.
Identidade e controle de acesso
Comece pela identidade.
Cada resposta da IA deve estar vinculada a um usuário, um espaço de trabalho, um arquivo e uma decisão de permissão.
Implementações corporativas geralmente precisam de:
- SSO via SAML ou OIDC
- Controle de acesso baseado em funções (RBAC)
- Mapeamento de grupos do provedor de identidade
- Permissões ao nível de workspace
- Permissões ao nível de arquivo
- Listas de permissão (allowlists) de datasets
- Controles de administrador
Se o sistema se conecta a bancos de dados ou armazenamento de objetos, ele não deve ignorar as permissões existentes. A IA não deve se tornar um atalho para burlar a governança.
Ingestão de planilhas
A ingestão de planilhas é mais complexa do que parece.
Um arquivo real pode conter:
- Múltiplas abas
- Abas ocultas
- Fórmulas
- Células mescladas
- Cabeçalhos inconsistentes
- Intervalos nomeados
- Comentários
- Formatação usada como significado
- Planilhas protegidas
- Gráficos e tabelas dinâmicas
- Links externos
- Macros
Um sistema de produção deve processar essa estrutura de forma suficiente para evitar que o modelo tenha uma visão distorcida dos dados.
Por segurança, arquivos com macros devem ser tratados com cautela. Se o sistema executar qualquer código, deve fazê-lo em um sandbox. Em muitas implementações, as macros devem ser verificadas, bloqueadas ou tratadas apenas como metadados, em vez de executadas.
Compreensão da planilha
Após a ingestão, o sistema deve construir uma representação útil do arquivo.
Isso pode incluir:
- Resumos das abas
- Limites das tabelas
- Nomes de colunas e tipos inferidos
- Amostras de linhas
- Mapas de dependência de fórmulas
- Métricas detectadas
- Intervalos de datas
- Valores ausentes
- Anomalias
- Relacionamentos entre abas ou arquivos
Essa representação é o que o modelo deve ver primeiro. Enviar uma planilha inteira em um prompt costuma ser ineficiente e arriscado.
O objetivo é dar ao modelo contexto suficiente para planejar o próximo passo, não fazer com que ele memorize o arquivo inteiro.
Camada de computação determinística
Para IA em planilhas, este é um dos componentes mais importantes.
O modelo não deve calcular números críticos internamente. Ele deve acionar ferramentas.
A camada de computação pode incluir:
- Fórmulas de planilha
- SQL
- DuckDB
- pandas
- Polars
- Warehouse pushdown
- Geração de gráficos
- Verificações de validação
Por exemplo, se um usuário solicitar os principais clientes por receita, o modelo identifica os campos corretos e gera uma consulta. A camada de computação executa a consulta. O modelo, então, explica o resultado.
Essa separação melhora a precisão, a velocidade e a auditabilidade.
Servindo modelos privados
A camada do modelo pode ser servida de várias formas.
vLLM é amplamente utilizado para inferência auto-hospedada de alto rendimento e oferece um servidor compatível com OpenAI.
KServe é útil quando a organização deseja um serviço de inferência nativo de Kubernetes e serviços padronizados.
NVIDIA NIM fornece microsserviços de inferência otimizados para infraestrutura acelerada pela NVIDIA.
Ollama é útil para pilotos e testes locais, embora implementações em produção geralmente exijam maior escalabilidade, controle de acesso e observabilidade.
A camada do modelo deve ser tratada como infraestrutura interna:
- Autenticada
- Com controle de versão
- Monitorada
- Isolada por controles de rede
- Configurada com políticas claras de retenção de dados
- Avaliada antes de atualizações de modelo
Orquestração de IA
A camada de orquestração decide como o sistema utiliza o modelo e as ferramentas.
Ela gerencia:
- Templates de prompt
- Seleção de modelos
- Seleção de ferramentas
- Construção de contexto
- Perguntas de esclarecimento
- Validação de consultas
- Sandboxing de código
- Lógica de repetição (retry)
- Formatação de respostas
É nesta camada que muitos controles de segurança residem.
Por exemplo, se o modelo gerar SQL, o sistema deve validar se o SQL é apenas para leitura, limitado às tabelas permitidas e se não é excessivamente oneroso. Se o modelo gerar Python, o sistema deve executá-lo em um sandbox com acesso à rede desativado, a menos que explicitamente permitido.
Auditabilidade
Logs de auditoria não são opcionais em implementações sérias.
Um log útil deve incluir:
- Usuário
- Carimbo de data/hora (timestamp)
- Planilha ou dataset acessado
- Prompt
- Nome e versão do modelo
- Consulta, fórmula ou código gerado
- Saídas das ferramentas
- Resposta final
- Decisões de permissão
- Erros e fallbacks
Isso não significa que cada valor sensível deve ser armazenado para sempre. A retenção deve ser configurável. Mas o sistema precisa de rastreabilidade suficiente para revisão, depuração e conformidade.
Observabilidade
As equipes técnicas precisam monitorar tanto a infraestrutura quanto a qualidade das respostas.
Métricas de infraestrutura:
- Latência
- Utilização de GPU
- Profundidade da fila
- Uso de tokens
- Erros do modelo
- Tempo de execução das ferramentas
- Uso de armazenamento
Métricas de qualidade:
- Precisão das respostas
- Qualidade das citações
- Validade das fórmulas
- Taxa de sucesso das consultas
- Correções dos usuários
- Relatos de alucinação
- Falhas em pedidos de esclarecimento
Sem observabilidade, as equipes não conseguem saber se o analista de IA está melhorando ou produzindo resultados pouco confiáveis silenciosamente.
Erros comuns
Tratar o modelo como o motor da planilha
Isso leva a totais alucinados e respostas frágeis. Use ferramentas para cálculos.
Recuperar primeiro e filtrar depois
As permissões devem ser aplicadas antes que o contexto chegue ao modelo.
Ignorar a complexidade das planilhas
Demos com arquivos CSV não provam que o sistema consegue lidar com arquivos Excel reais.
Logar dados sensíveis em excesso
A auditabilidade é importante, mas os logs também devem seguir regras de retenção e privacidade.
Construir em torno de um único modelo
Os modelos mudam rapidamente. Construa o fluxo de trabalho de forma que o modelo possa ser substituído.
Plano de implementação em fases
Uma implementação realista pode ocorrer em etapas:
- Protótipo com planilhas de amostra ou editadas.
- Validação de tarefas de análise comuns e casos de falha.
- Adição de computação determinística para todo o trabalho numérico.
- Conexão de identidade e permissões antes de usar arquivos reais.
- Implantação de um endpoint de modelo privado via vLLM, KServe, NIM ou outra stack aprovada.
- Adição de logs de auditoria e monitoramento.
- Piloto com uma equipe, geralmente finanças, operações ou relatórios de vendas.
- Avaliação dos resultados comparando com respostas conhecidas antes da expansão.
Isso evita o erro comum de transformar uma demo de modelo em um sistema de produção antes que a camada de governança exista.
Onde o RowSpeak se encaixa
O RowSpeak atua como a camada de fluxo de trabalho sobre os endpoints de modelos privados e a execução de dados governada.
O servidor do modelo fornece o raciocínio. O RowSpeak fornece a experiência de planilha: upload de arquivos, perguntas em linguagem natural, gráficos, resumos, relatórios e fluxos de análise voltados ao usuário, como relatórios semanais de vendas.
Para implementações on-premise, essa separação é valiosa. A TI pode controlar o modelo e a infraestrutura. Os usuários de negócios podem trabalhar através de uma interface projetada para análise de planilhas em vez de chamadas de API brutas, seja o resultado final um dashboard de IA ou um relatório financeiro.
Consideração final
Um endpoint de LLM on-premise é infraestrutura. Um analista de planilhas por IA on-premise é uma experiência de produto somada à governança.
O modelo é importante, mas a arquitetura ao seu redor determina se o sistema é confiável. Para um exemplo específico de modelo, consulte o guia sobre auto-hospedagem do DeepSeek para o RowSpeak.
Fontes e leituras adicionais
- Servidor vLLM compatível com OpenAI: https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
- KServe: https://kserve.github.io/website/
- NVIDIA NIM: https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
- Biblioteca Ollama: https://ollama.com/library
- llama.cpp: https://github.com/ggml-org/llama.cpp
