Construa um Analista de Dados de IA com Python Isolado e Acesso Controlado a Pacotes

Um analista de dados de IA precisa de Python isolado quando conjuntos de dados fornecidos pelo usuário, código gerado por modelo, instalações de pacotes, gráficos gerados e saídas para download devem ser executados em um ambiente isolado e observável. O fluxo de implementação prática é: fazer upload de um arquivo, inspecionar o esquema com código confiável, pedir um plano ao modelo, revisar o Python gerado, executá-lo em um sandbox restrito, validar os artefatos de saída e mostrar ao usuário o que aconteceu.

Arquitetura do Analista de Dados de IA: Upload, Análise, Revisão

O padrão do produto é simples na superfície: um usuário faz upload de um CSV, faz uma pergunta em linguagem natural e espera tabelas úteis, gráficos e arquivos para download. Nos bastidores, o aplicativo está executando um pequeno fluxo de trabalho de agente com efeitos colaterais reais. O modelo planeja a análise e elabora o Python, enquanto o aplicativo decide qual código, pacotes, arquivos, acesso à rede e saídas são permitidos.

Construa a primeira versão em torno de um caminho claro:

1. Aceitar um upload de CSV para um trabalho de análise.
2. Criar um espaço de trabalho sandbox com escopo para o trabalho.
3. Executar código próprio de inspeção de esquema antes de pedir Python ao modelo.
4. Pedir ao modelo um plano de análise e, em seguida, um script que siga suas regras de arquivo e pacote.
5. Executar o script com limites de tempo, memória, disco, pacote e rede.
6. Coletar apenas artefatos validados de um diretório de saída conhecido.
7. Mostrar ao usuário a resposta, gráficos, avisos, logs e arquivos selecionados para download.

Essa separação mantém as responsabilidades claras. O modelo propõe e explica a análise. O backend aplica a política do produto e a orquestração. O sandbox executa o código com arquivos, pacotes, tempo, memória, acesso à rede e segredos restritos.

O que é Executado Dentro de um Sandbox Python para Análise de Dados?

Coloque o espaço de trabalho de análise dentro do sandbox, não dentro do seu servidor de aplicação principal. O sandbox deve receber um pacote de entrada estreito para um trabalho de análise: o arquivo enviado, um pequeno manifesto, um script gerado e qualquer configuração de tempo de execução aprovada. O backend do aplicativo deve manter autenticação, faturamento, identidade do usuário, armazenamento de longo prazo e segredos de produção fora desse espaço de trabalho.

Para um analista de dados de IA, o sandbox geralmente gerencia estas tarefas:

Tarefa do sandbox	Por que pertence a ele
Preparação de arquivos	O CSV enviado pode ser escaneado e copiado para um diretório de trabalho isolado antes que o Python o toque.
Inspeção de esquema	O aplicativo pode inferir nomes de colunas, tipos, taxas de nulos, contagem de linhas e valores de amostra sem expor o arquivo completo ao modelo.
Execução Python	O código gerado pelo modelo é executado longe do servidor da aplicação e pode ter tempo limitado.
Preparação de pacotes	Apenas dependências aprovadas são instaladas ou disponibilizadas para o trabalho.
Renderização de gráficos	Imagens de plotagem são escritas como arquivos e revisadas antes do download.
Empacotamento de resultados	Os artefatos finais podem ser coletados de um diretório de saída conhecido.
Limpeza	Arquivos temporários, código gerado e estado da sessão podem ser deletados ou expirados.

Mantenha o prompt do modelo menor que os dados. Envie um resumo do esquema, algumas linhas representativas se a política permitir, descrições de colunas, intenção do usuário e restrições como “não treine um modelo” ou “use apenas pacotes aprovados”. O conjunto de dados bruto deve permanecer no sistema de arquivos do sandbox, a menos que seu produto tenha um motivo específico e revisado para expor mais.

Como o Upload de CSV e a Inspeção de Esquema Devem Funcionar?

Comece tratando cada upload como entrada não confiável. Valide o tipo de arquivo, tamanho, codificação, delimitador, contagem de linhas, contagem de colunas e fórmulas suspeitas antes que o modelo se envolva. Um CSV ainda pode conter valores que disparam a execução de fórmulas de planilha quando abertos posteriormente, portanto, os arquivos exportados também devem ser sanitizados para o formato de destino.

Um fluxo de upload prático se parece com isso:

1. O usuário faz upload de um CSV para o aplicativo.
2. O backend armazena o arquivo original sob uma chave de objeto ou caminho de preparação com escopo para o trabalho.
3. O backend cria uma sessão sandbox para o trabalho.
4. O backend copia o arquivo para um diretório de trabalho do sandbox.
5. Um pequeno script de inspeção determinístico lê o arquivo e produz um resumo do esquema.
6. O modelo recebe o resumo do esquema, a pergunta do usuário, as bibliotecas permitidas e os requisitos de saída.

A etapa de inspeção deve ser um código determinístico que você possui, não código gerado pelo modelo. Pode produzir um resumo JSON compacto como este:

{
  "file": "sales.csv",
  "rows": 84231,
  "columns": [
    {"name": "order_date", "type": "date", "null_rate": 0.01},
    {"name": "region", "type": "string", "sample_values": ["NA", "EMEA", "APAC"]},
    {"name": "revenue", "type": "number", "null_rate": 0.0}
  ],
  "safe_sample_rows": 5
}

Esse resumo dá ao modelo contexto suficiente para elaborar uma análise sem entregar o conjunto de dados inteiro. Para cargas de trabalho sensíveis, reduza ou remova valores de amostra, mascare colunas ou exija que o usuário aprove quais colunas podem ser usadas.

Como o Modelo Gera e Executa Python com Segurança?

O modelo deve produzir um plano antes de produzir código. Um bom plano nomeia as colunas que usará, as transformações que pretende executar, os gráficos que espera criar e os arquivos de saída que escreverá. Isso dá ao seu aplicativo um ponto de verificação para política e revisão do usuário.

Após o plano ser aceito, peça Python que siga um contrato restrito:

• Ler arquivos de entrada apenas de um diretório input/.
• Escrever artefatos apenas em um diretório output/.
• Usar apenas pacotes aprovados.
• Evitar chamadas de rede, a menos que a política do trabalho as permita explicitamente.
• Imprimir um resumo estruturado no final.
• Falhar claramente quando colunas obrigatórias estiverem ausentes.

Em um nível conceitual, o loop de orquestração se parece com isso:

job = create_analysis_job(user_id, uploaded_file)
sandbox = create_sandbox(job_id=job.id, timeout_seconds=300)

copy_file_to_sandbox(uploaded_file, sandbox_path="/work/input/data.csv")
schema = run_owned_schema_inspector(sandbox, "/work/input/data.csv")

plan = ask_model_for_analysis_plan(
    user_question=job.question,
    schema=schema,
    allowed_packages=["pandas", "numpy", "matplotlib"],
    output_contract={"directory": "/work/output", "formats": ["png", "csv", "json"]},
)

review_policy(plan)

script = ask_model_for_python(plan=plan, schema=schema)
review_static_code_policy(script)

result = run_python_in_sandbox(
    sandbox=sandbox,
    script=script,
    working_dir="/work",
    timeout_seconds=120,
    memory_limit_mb=1024,
)

artifacts = collect_outputs(sandbox, "/work/output")
review_outputs(artifacts)
return_answer_to_user(result.summary, artifacts)

Isso é pseudocódigo, não um contrato de SDK de produto. O ponto é o limite: o código gerado é revisado, executado com tempo limite, restrito a diretórios conhecidos e seguido pela coleta e revisão da saída.

Se o script falhar, envie a mensagem de erro e um pequeno trecho de código de volta ao modelo para reparo. Não envie logs ilimitados. O reparo de erros deve manter a mesma política de pacote, arquivo, rede e saída da primeira tentativa.

Acesso Controlado a Pacotes Python para Análise de Dados de IA

O acesso a pacotes é onde muitas demonstrações de analistas de dados de IA se tornam arriscadas. Um modelo pode pedir uma biblioteca porque a viu em um tutorial, porque um nome de pacote parece plausível ou porque o prompt do usuário a sugeriu. Seu aplicativo não deve transformar essas sugestões em instalações irrestritas de pacotes.

Use uma política que corresponda à sensibilidade dos dados:

Política de pacote	Melhor adequação	Compensação
Apenas imagem pré-construída	Cargas de trabalho de produção com necessidades de análise previsíveis	Menor flexibilidade, superfície de revisão mais simples
Pacotes em lista de permissões	A maioria dos assistentes de análise CSV	Bom equilíbrio para pandas, plotagem e pacotes de estatísticas comuns
Instalações com versão fixa	Trabalhos de análise reproduzíveis	Requer manutenção de pacotes e revisão de vulnerabilidades
Mirror interno em cache	Fluxos de trabalho empresariais ou de dados regulamentados	Mais trabalho operacional, melhor controle sobre a cadeia de suprimentos
Instalações aprovadas pelo usuário	Ferramentas exploratórias para usuários confiáveis	Mais flexível, mas mais lento e precisa de avisos claros

Para uma primeira versão de produção, comece com um ambiente pré-construído ou uma pequena lista de permissões. A maioria das perguntas sobre CSV pode ser respondida com um pequeno conjunto de bibliotecas: pandas, numpy, matplotlib, seaborn, scipy e, às vezes, scikit-learn. Se um trabalho precisar de outro pacote, peça ao modelo que explique o motivo e, em seguida, encaminhe essa solicitação por meio de aprovação humana ou um fluxo de trabalho de revisão de pacotes.

Registre o nome do pacote, versão, registro de origem, tempo de instalação e o motivo pelo qual o pacote foi solicitado. Se sua equipe de segurança usar scanners de dependência ou registros privados, integre-se a esse processo em vez de permitir que o agente o ignore.

Como Validar Gráficos e Arquivos de Saída

Arquivos gerados fazem parte da experiência do produto, mas também fazem parte do limite de confiança. Um gráfico pode estar errado. Um CSV pode conter valores semelhantes a fórmulas. Um notebook pode incluir código oculto. Um ZIP pode conter caminhos inesperados. Trate as saídas como artefatos a serem inspecionados, não apenas arquivos para download.

Defina um contrato de saída simples:

{
  "required_files": ["summary.json"],
  "optional_files": ["chart-*.png", "filtered-data.csv"],
  "blocked_extensions": [".exe", ".sh", ".bat", ".html"],
  "max_total_size_mb": 25
}

Para cada trabalho concluído, colete arquivos apenas do diretório de saída esperado. Valide o tipo MIME, extensão, tamanho e caminho. Para imagens, gere miniaturas para visualização. Para exportações CSV, escape fórmulas de planilha se o arquivo puder ser aberto no Excel ou no Google Sheets. Para resumos JSON, valide contra um esquema antes de usá-los na interface.

Dê aos usuários uma etapa de revisão antes de baixar ou compartilhar resultados. A tela de revisão deve mostrar:

• A pergunta original.
• O nome do conjunto de dados e o esquema usado.
• As etapas de análise em linguagem simples.
• Os gráficos e tabelas gerados.
• Quaisquer colunas excluídas por motivos de política.
• Avisos, erros, novas tentativas ou solicitações de pacotes.

O modelo pode escrever uma explicação narrativa, mas o aplicativo deve fundamentar essa explicação em arquivos e logs da execução do sandbox.

Pontos de Verificação de Segurança Antes da Produção

Um analista de dados de IA é uma ferramenta interna útil somente se as equipes de segurança e plataforma puderem raciocinar sobre o que ele pode fazer. A revisão deve cobrir isolamento, limites de recursos, política de pacotes, comportamento de rede, segredos, logs e exclusão.

Use esta lista de verificação antes de ir além de um protótipo:

Ponto de verificação	Pergunta a ser respondida
Limite de isolamento	O que separa o código e os arquivos de um usuário do host e de outros usuários?
Acesso a arquivos	O código gerado pode ler apenas o diretório do trabalho ou pode ver armazenamento mais amplo?
Limites de recursos	O que limita o tempo de CPU, memória, disco, contagem de processos e tempo de parede?
Política de rede	O acesso à rede de saída está desligado, na lista de permissões, com proxy ou totalmente aberto?
Política de pacotes	Quais pacotes podem ser instalados, de onde e com quais controles de versão?
Limite de segredos	As chaves de API, credenciais de banco de dados e tokens de serviço são mantidos fora do sandbox, a menos que explicitamente definidos?
Logs	Comandos, instalações de pacotes, erros, leituras/gravações de arquivos e artefatos de saída são registrados?
Revisão humana	Quais planos, trechos de código, solicitações de pacotes e saídas precisam de aprovação?
Limpeza	Quando o estado do sandbox, arquivos enviados, scripts gerados, logs e saídas são excluídos?

Evite alegações absolutas como “o código não pode escapar” ou “os dados não podem vazar”. O padrão prático é mais concreto: defina o limite, documente os controles, teste modos de falha e mantenha trilha de auditoria suficiente para investigar comportamentos inesperados.

Para política de rede e pacotes, lembre-se de que a instalação de dependências é uma forma de saída de rede, a menos que os pacotes venham de uma imagem pré-construída ou espelho controlado. Se o conjunto de dados for sensível, o acesso à rede deve ser bloqueado ou estritamente permitido por padrão. Se o analista precisar de dados externos ao vivo, faça disso uma ferramenta separada com seu próprio caminho de aprovação e registro.

Usando o Novita Agent Sandbox como Camada de Execução

O Novita Agent Sandbox fornece ambientes de execução isolados e com estado para agentes de IA. A documentação atual do Novita descreve suporte para executar código, instalar dependências, acessar arquivos, usar navegadores e preservar o estado de execução entre sessões. Para um analista de dados de IA, essas primitivas mapeiam diretamente para a parte de execução da arquitetura: criar um espaço de trabalho de trabalho, mover arquivos para dentro, executar código de análise, coletar artefatos e limpar ou preservar o estado com base no design da sessão.

A documentação do SDK e CLI do Novita Agent Sandbox lista suporte oficial de SDK para Python e JavaScript/TypeScript, o que se ajusta a backends de aplicativos comuns. A documentação do sistema de arquivos do sandbox descreve um sistema de arquivos isolado com espaço de armazenamento fixo de 20 GB para sandboxes, útil para preparar arquivos CSV e artefatos gerados dentro de um espaço de trabalho com escopo de trabalho.

Mantenha a distinção clara:

• A orientação de implementação neste artigo descreve uma arquitetura geral para aplicativos de analista de dados de IA.
• O Novita Agent Sandbox pode fornecer a camada de execução do sandbox para esses fluxos de trabalho.
• Seu aplicativo ainda é responsável pela autenticação do usuário, política de retenção de dados, aprovação de pacotes, política de rede, revisão de saída e decisões de publicação/implantação.

Essa separação ajuda as equipes a construir com um modelo de responsabilidade claro. O modelo sugere e explica a análise. O aplicativo aplica a política do produto. O sandbox fornece o tempo de execução controlado onde código, arquivos, pacotes, gráficos e logs podem ser manipulados longe do servidor principal da aplicação.

Conclusão

O design mais forte de analista de dados de IA não é “deixar o modelo executar Python”. É um loop controlado: inspecionar o conjunto de dados, pedir um plano ao modelo, revisar o código gerado, executá-lo em um sandbox, coletar artefatos validados, mostrar ao usuário o que aconteceu e limpar o estado quando o trabalho é concluído. Essa estrutura mantém a experiência do usuário rápida enquanto dá às equipes de engenharia e segurança pontos de verificação concretos para avaliar antes da produção.

Para equipes construindo esse padrão, comece pequeno: upload CSV, inspeção de esquema, uma pequena lista de permissões de pacotes, saída de gráficos, limites de tempo rigorosos e uma tela de revisão visível. Adicione acesso mais amplo a pacotes, ferramentas de rede, persistência e automação somente depois que os limites forem documentados e testados.

Perguntas Frequentes

Por que um analista de dados de IA precisa de um sandbox?

Ele precisa de um sandbox porque o fluxo de trabalho combina arquivos não confiáveis, Python gerado por modelo, solicitações de pacotes, geração de gráficos e artefatos para download. Executar esse trabalho em um ambiente separado dá ao seu aplicativo um lugar para aplicar controles de arquivo, recurso, pacote, rede, registro e limpeza.

O modelo deve ver o CSV completo?

Geralmente não. Comece enviando ao modelo um resumo do esquema, amostras seguras, descrições de colunas e a pergunta do usuário. Mantenha o arquivo bruto no sandbox, a menos que seu produto tenha um motivo revisado para expor mais dados ao modelo.

As instalações de pacotes podem ser permitidas?

Sim, mas devem ser controladas. Use uma imagem pré-construída, lista de permissões, versões fixas, espelho privado ou fluxo de trabalho de aprovação. Não deixe que o código gerado pelo modelo instale pacotes arbitrários da internet pública sem revisão.

Quais arquivos o aplicativo deve retornar aos usuários?

Retorne apenas arquivos validados de um diretório de saída conhecido, como imagens de gráficos, JSON de resumo e exportações CSV sanitizadas. Bloqueie extensões inesperadas, arquivos grandes, caminhos ocultos e artefatos que não faziam parte do contrato de saída.

Isso é uma garantia de conformidade?

Não. Um sandbox é uma parte da arquitetura de execução. A conformidade e a aprovação de segurança dependem de seus dados, modelo de ameaça, controles, registro, retenção, processo de revisão e ambiente de implantação.

Artigos recomendados

• Execute Codex ou um Agente de Codificação em um Sandbox Seguro
• Servidores MCP em Sandboxes Isolados: Compensações de Sistema de Arquivos, Segredos e Rede
• Firecracker para Sandboxes de Agentes de IA: Benefícios, Limites e Perguntas de Avaliação