- Arquitetura do Analista de Dados de IA: Upload, Análise, Revisão
- O que é executado dentro de um Sandbox Python para Análise de Dados?
- Como devem funcionar o upload de CSV e a inspeção de esquema?
- Como o modelo gera e executa Python com segurança?
- Acesso Controlado a Pacotes Python para Análise de Dados de IA
- Como Validar Gráficos e Arquivos de Saída
- Pontos de Verificação de Segurança Antes da Produção
- Usando o Novita Agent Sandbox como Camada de Execução
- Conclusão
- Perguntas Frequentes
- Artigos recomendados
Um analista de dados de IA precisa de Python em sandbox 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 ao modelo um plano, 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 receber tabelas úteis, gráficos e arquivos para download. Nos bastidores, o aplicativo executa 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 quais códigos, pacotes, arquivos, acesso à rede e saídas são permitidos.
Construa a primeira versão em torno de um caminho claro:
- Aceitar um upload de CSV para um trabalho de análise.
- Criar um workspace de sandbox com escopo para o trabalho.
- Executar código de inspeção de esquema próprio antes de pedir ao modelo o Python.
- Pedir ao modelo um plano de análise e, em seguida, um script que siga suas regras de arquivo e pacote.
- Executar o script com limites de tempo, memória, disco, pacote e rede.
- Coletar apenas artefatos validados de um diretório de saída conhecido.
- 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 workspace de análise dentro do sandbox, não dentro do servidor principal do seu aplicativo. O sandbox deve receber um pacote de entrada restrito 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 workspace.
Para um analista de dados de IA, o sandbox geralmente lida com estas tarefas:
| Tarefa do sandbox | Por que pertence aí |
|---|---|
| Preparação de arquivos | O CSV enviado pode ser verificado 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 do aplicativo e pode ser limitado no tempo. |
| Preparação de pacotes | Apenas dependências aprovadas são instaladas ou disponibilizadas para o trabalho. |
| Renderização de gráficos | As imagens dos gráficos são gravadas 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 excluídos 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 devem funcionar o upload de CSV e a inspeção de esquema?
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 acionam 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 é assim:
- O usuário faz upload de um CSV para o aplicativo.
- O backend armazena o arquivo original em uma chave de objeto ou caminho de preparação com escopo para o trabalho.
- O backend cria uma sessão de sandbox para o trabalho.
- O backend copia o arquivo para um diretório de trabalho no sandbox.
- Um pequeno script de inspeção determinístico lê o arquivo e produz um resumo do esquema.
- 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 de sua propriedade, não um código gerado pelo modelo. Ele 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 fornece ao modelo contexto suficiente para elaborar uma análise sem fornecer todo o conjunto de dados. 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, solicite 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 isto:
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 um 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 erro 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 solicitar 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 pacotes | 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 estatísticos comuns |
| Instalações com versão fixa | Trabalhos de análise reproduzíveis | Requer manutenção de pacotes e revisão de vulnerabilidades |
| Espelho interno em cache | Fluxos de trabalho de dados empresariais ou 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 lista de permissões curta. 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 para explicar 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, horário 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
Os 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 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 da 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 apenas se as equipes de segurança e plataforma puderem entender 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 responder |
|---|---|
| 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 um armazenamento mais amplo? |
| Limites de recursos | O que limita o tempo de CPU, memória, disco, contagem de processos e tempo real? |
| Política de rede | O acesso à rede de saída está desativado, em lista de permissões, 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 escopo? |
| Logs | Os 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 afirmaçõ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 de um espelho controlado. Se o conjunto de dados for sensível, o acesso à rede deve ser bloqueado ou rigorosamente listado como permitido por padrão. Se o analista precisar de dados externos ao vivo, torne isso 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 workspace 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, que se adequa 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 workspace 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 do aplicativo.
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 ao modelo um plano, 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 for 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 que constroem esse padrão, comece pequeno: upload de CSV, inspeção de esquema, uma lista de permissões de pacotes curta, saída de gráficos, timeouts rigorosos e uma tela de revisão visível. Adicione acesso mais amplo a pacotes, ferramentas de rede, persistência e automação somente após os limites serem 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 permita 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 aprovação de conformidade e segurança depende dos seus dados, modelo de ameaça, controles, registro, retenção, processo de revisão e ambiente de implantação.
