Crea un analista de datos de IA con Python en sandbox y acceso controlado a paquetes

Un analista de datos de IA necesita Python en sandbox cuando los conjuntos de datos proporcionados por el usuario, el código generado por el modelo, las instalaciones de paquetes, los gráficos generados y las salidas descargables deben ejecutarse en un entorno aislado y observable. El flujo de implementación práctico es: cargar un archivo, inspeccionar el esquema con código de confianza, pedirle al modelo un plan, revisar el código Python generado, ejecutarlo en un sandbox restringido, validar los artefactos de salida y mostrar al usuario lo que sucedió.

Arquitectura del analista de datos de IA: Cargar, analizar, revisar

El patrón del producto es simple en apariencia: un usuario sube un CSV, hace una pregunta en lenguaje natural y espera tablas, gráficos y archivos descargables útiles. Internamente, la aplicación ejecuta un flujo de trabajo de agente pequeño con efectos secundarios reales. El modelo planifica el análisis y redacta el código Python, mientras que la aplicación decide qué código, paquetes, archivos, acceso a la red y salidas están permitidos.

Construye la primera versión alrededor de un camino claro:

1. Aceptar una carga CSV para un trabajo de análisis.
2. Crear un espacio de trabajo sandbox con alcance al trabajo.
3. Ejecutar código propio de inspección de esquema antes de pedirle Python al modelo.
4. Pedirle al modelo un plan de análisis, luego un script que siga tus reglas de archivos y paquetes.
5. Ejecutar el script con límites de tiempo, memoria, disco, paquetes y red.
6. Recoger solo artefactos validados de un directorio de salida conocido.
7. Mostrar al usuario la respuesta, gráficos, advertencias, registros y archivos seleccionados para descargar.

Esa separación mantiene las responsabilidades claras. El modelo propone y explica el análisis. El backend aplica la política del producto y la orquestación. El sandbox ejecuta el código con archivos, paquetes, tiempo, memoria, acceso a la red y secretos restringidos.

¿Qué se ejecuta dentro de un sandbox de Python para análisis de datos?

Coloca el espacio de trabajo de análisis dentro del sandbox, no dentro de tu servidor de aplicación principal. El sandbox debe recibir un paquete de entrada reducido para un trabajo de análisis: el archivo cargado, un manifiesto pequeño, un script generado y cualquier configuración de tiempo de ejecución aprobada. El backend de la aplicación debe mantener la autenticación, facturación, identidad del usuario, almacenamiento a largo plazo y secretos de producción fuera de ese espacio de trabajo.

Para un analista de datos de IA, el sandbox normalmente posee estas tareas:

Tarea del sandbox	Por qué pertenece allí
Almacenamiento de archivos	El CSV cargado puede escanearse y copiarse en un directorio de trabajo aislado antes de que Python lo toque.
Inspección de esquema	La aplicación puede inferir nombres de columnas, tipos, tasas de nulos, cantidad de filas y valores de muestra sin exponer el archivo completo al modelo.
Ejecución de Python	El código generado por el modelo se ejecuta lejos del servidor de la aplicación y se puede limitar en tiempo.
Preparación de paquetes	Solo se instalan o ponen a disposición del trabajo las dependencias aprobadas.
Renderizado de gráficos	Las imágenes de los gráficos se escriben como archivos y se revisan antes de la descarga.
Empaquetado de resultados	Los artefactos finales pueden recogerse de un directorio de salida conocido.
Limpieza	Los archivos temporales, el código generado y el estado de la sesión pueden eliminarse o permitirse que expiren.

Mantén el prompt del modelo más pequeño que los datos. Envía un resumen del esquema, algunas filas representativas si la política lo permite, descripciones de columnas, intención del usuario y restricciones como “no entrenar un modelo” o “usar solo paquetes aprobados”. El conjunto de datos sin procesar debe permanecer en el sistema de archivos del sandbox a menos que tu producto tenga una razón específica y revisada para exponer más.

¿Cómo deberían funcionar la carga de CSV y la inspección del esquema?

Comienza tratando cada carga como entrada no confiable. Valida el tipo de archivo, tamaño, codificación, delimitador, cantidad de filas, cantidad de columnas y fórmulas sospechosas antes de que el modelo intervenga. Un CSV aún puede contener valores que desencadenen la ejecución de fórmulas de hoja de cálculo cuando se abra más tarde, por lo que los archivos exportados también deben sanitizarse para el formato de destino.

Un flujo de carga práctico se ve así:

1. El usuario carga un CSV en la aplicación.
2. El backend almacena el archivo original bajo una clave de objeto o ruta de almacenamiento temporal con alcance al trabajo.
3. El backend crea una sesión de sandbox para el trabajo.
4. El backend copia el archivo en un directorio de trabajo del sandbox.
5. Un pequeño script de inspección determinista lee el archivo y produce un resumen del esquema.
6. El modelo recibe el resumen del esquema, la pregunta del usuario, las bibliotecas permitidas y los requisitos de salida.

El paso de inspección debe ser código determinista que tú poseas, no código generado por el modelo. Puede producir un resumen 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
}

Ese resumen le da al modelo suficiente contexto para redactar un análisis sin entregarle todo el conjunto de datos. Para cargas de trabajo sensibles, reduce o elimina los valores de muestra, enmascara columnas o requiere que el usuario apruebe qué columnas se pueden usar.

¿Cómo genera y ejecuta el modelo Python de manera segura?

El modelo debe producir un plan antes de producir código. Un buen plan nombra las columnas que usará, las transformaciones que pretende ejecutar, los gráficos que espera crear y los archivos de salida que escribirá. Esto le da a tu aplicación un punto de control para la política y la revisión del usuario.

Después de que el plan sea aceptado, pide Python que siga un contrato estricto:

• Leer archivos de entrada solo desde un directorio input/.
• Escribir artefactos solo en un directorio output/.
• Usar solo paquetes aprobados.
• Evitar llamadas de red a menos que la política del trabajo lo permita explícitamente.
• Imprimir un resumen estructurado al final.
• Fallar claramente cuando falten columnas requeridas.

A nivel conceptual, el bucle de orquestación se ve así:

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)

Esto es pseudocódigo, no un contrato de SDK de producto. El punto es el límite: el código generado se revisa, se ejecuta con un tiempo de espera, se restringe a directorios conocidos, y después se recogen y revisan las salidas.

Si el script falla, envía el mensaje de error y un pequeño extracto del código de vuelta al modelo para su reparación. No envíes registros ilimitados. La reparación de errores debe mantener la misma política de paquetes, archivos, red y salida que el primer intento.

Control de acceso a paquetes Python para análisis de datos con IA

El acceso a paquetes es donde muchas demostraciones de analistas de datos de IA se vuelven riesgosas. Un modelo puede pedir una biblioteca porque la vio en un tutorial, porque un nombre de paquete parece plausible o porque el prompt del usuario lo sugirió. Tu aplicación no debe convertir esas sugerencias en instalaciones de paquetes sin restricciones.

Usa una política que coincida con la sensibilidad de los datos:

Política de paquetes	Mejor ajuste	Compensación
Solo imagen preconstruida	Cargas de trabajo de producción con necesidades de análisis predecibles	Menor flexibilidad, superficie de revisión más simple
Paquetes en lista blanca	La mayoría de los asistentes de análisis CSV	Buen equilibrio para pandas, gráficos y paquetes estadísticos comunes
Instalaciones con versión fija	Trabajos de análisis reproducibles	Requiere mantenimiento de paquetes y revisión de vulnerabilidades
Espejo interno en caché	Flujos de trabajo empresariales o regulados	Más trabajo operativo, mejor control sobre la cadena de suministro
Instalaciones aprobadas por el usuario	Herramientas exploratorias para usuarios de confianza	Más flexible, pero más lento y necesita advertencias claras

Para una primera versión de producción, comienza con un entorno preconstruido o una lista blanca corta. La mayoría de las preguntas sobre CSV se pueden responder con un conjunto pequeño de bibliotecas: pandas, numpy, matplotlib, seaborn, scipy y a veces scikit-learn. Si un trabajo necesita otro paquete, haz que el modelo explique por qué, luego canaliza esa solicitud a través de una aprobación humana o un flujo de trabajo de revisión de paquetes.

Registra el nombre del paquete, la versión, el registro de origen, el tiempo de instalación y la razón por la que se solicitó el paquete. Si tu equipo de seguridad utiliza escáneres de dependencias o registros privados, intégrate con ese proceso en lugar de permitir que el agente lo omita.

Cómo validar gráficos y archivos de salida

Los archivos generados son parte de la experiencia del producto, pero también son parte del límite de confianza. Un gráfico puede estar mal. Un CSV puede contener valores similares a fórmulas. Un notebook puede incluir código oculto. Un ZIP puede contener rutas inesperadas. Trata las salidas como artefactos que inspeccionar, no solo como archivos para descargar.

Define un contrato de salida simple:

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

Para cada trabajo completado, recoge archivos solo del directorio de salida esperado. Valida el tipo MIME, extensión, tamaño y ruta. Para imágenes, genera miniaturas para vista previa. Para exportaciones CSV, escapa las fórmulas de hoja de cálculo si el archivo puede abrirse en Excel o Google Sheets. Para resúmenes JSON, valida contra un esquema antes de usarlos en la interfaz de usuario.

Dale a los usuarios un paso de revisión antes de que descarguen o compartan resultados. La pantalla de revisión debe mostrar:

• La pregunta original.
• El nombre del conjunto de datos y el esquema utilizado.
• Los pasos de análisis en lenguaje sencillo.
• Los gráficos y tablas generados.
• Las columnas excluidas por razones de política.
• Advertencias, errores, reintentos o solicitudes de paquetes.

El modelo puede escribir una explicación narrativa, pero la aplicación debe fundamentar esa explicación en archivos y registros de la ejecución del sandbox.

Puntos de control de seguridad antes de producción

Un analista de datos de IA es una herramienta interna útil solo si los equipos de seguridad y plataforma pueden razonar sobre lo que se le permite hacer. La revisión debe cubrir aislamiento, límites de recursos, política de paquetes, comportamiento de red, secretos, registros y eliminación.

Usa esta lista de verificación antes de pasar de un prototipo:

Punto de control	Pregunta a responder
Límite de aislamiento	¿Qué separa el código y los archivos de un usuario del host y de otros usuarios?
Acceso a archivos	¿Puede el código generado leer solo el directorio del trabajo, o puede ver almacenamiento más amplio?
Límites de recursos	¿Qué limita el tiempo de CPU, memoria, disco, número de procesos y tiempo de reloj?
Política de red	¿El acceso a la red de salida está desactivado, en lista blanca, con proxy o completamente abierto?
Política de paquetes	¿Qué paquetes se pueden instalar, desde dónde y con qué controles de versión?
Límite de secretos	¿Las claves de API, credenciales de base de datos y tokens de servicio se mantienen fuera del sandbox a menos que se alcancen explícitamente?
Registros	¿Se registran comandos, instalaciones de paquetes, errores, lecturas/escrituras de archivos y artefactos de salida?
Revisión humana	¿Qué planes, fragmentos de código, solicitudes de paquetes y salidas necesitan aprobación?
Limpieza	¿Cuándo se eliminan el estado del sandbox, los archivos cargados, los scripts generados, los registros y las salidas?

Evita afirmaciones absolutas como “el código no puede escapar” o “los datos no pueden filtrarse”. El estándar práctico es más concreto: define el límite, documenta los controles, prueba los modos de fallo y mantén suficiente rastro de auditoría para investigar comportamientos inesperados.

Para la política de red y paquetes, recuerda que la instalación de dependencias es una forma de salida de red a menos que los paquetes provengan de una imagen preconstruida o un espejo controlado. Si el conjunto de datos es sensible, el acceso a la red debe bloquearse o estar en lista blanca estricta de forma predeterminada. Si el analista necesita datos externos en vivo, conviértelo en una herramienta separada con su propio proceso de aprobación y registro.

Uso de Novita Agent Sandbox como capa de ejecución

Novita Agent Sandbox proporciona entornos de ejecución aislados y con estado para agentes de IA. Los documentos actuales de Novita describen compatibilidad para ejecutar código, instalar dependencias, acceder a archivos, usar navegadores y preservar el estado de ejecución entre sesiones. Para un analista de datos de IA, esos primitivos se asignan directamente a la parte de ejecución de la arquitectura: crear un espacio de trabajo de trabajo, mover archivos, ejecutar código de análisis, recoger artefactos y limpiar o preservar el estado según el diseño de la sesión.

La documentación del SDK y CLI de Novita Agent Sandbox enumera soporte oficial del SDK para Python y JavaScript/TypeScript, lo que se ajusta a los backends de aplicaciones comunes. La documentación del sistema de archivos del sandbox describe un sistema de archivos aislado con 20 GB de espacio de almacenamiento fijo para sandboxes, útil para almacenar archivos CSV y artefactos generados dentro de un espacio de trabajo con alcance al trabajo.

Mantén clara la distinción:

• La guía de implementación en este artículo describe una arquitectura general para aplicaciones de analista de datos de IA.
• Novita Agent Sandbox puede proporcionar la capa de ejecución del sandbox para esos flujos de trabajo.
• Tu aplicación sigue siendo responsable de la autenticación del usuario, la política de retención de datos, la aprobación de paquetes, la política de red, la revisión de salidas y las decisiones de publicación/despliegue.

Esa separación ayuda a los equipos a construir con un modelo de responsabilidades limpio. El modelo sugiere y explica el análisis. La aplicación aplica la política del producto. El sandbox proporciona el tiempo de ejecución controlado donde el código, archivos, paquetes, gráficos y registros pueden manejarse lejos del servidor principal de la aplicación.

Conclusión

El diseño más sólido para un analista de datos de IA no es “dejar que el modelo ejecute Python”. Es un bucle controlado: inspeccionar el conjunto de datos, pedirle al modelo un plan, revisar el código generado, ejecutarlo en un sandbox, recoger artefactos validados, mostrar al usuario lo que sucedió y limpiar el estado cuando el trabajo termina. Esa estructura mantiene la experiencia del usuario rápida mientras proporciona a los equipos de ingeniería y seguridad puntos de control concretos para evaluar antes de producción.

Para los equipos que construyen este patrón, comiencen pequeño: carga CSV, inspección de esquema, una lista blanca corta de paquetes, salida de gráficos, tiempos de espera estrictos y una pantalla de revisión visible. Agreguen acceso más amplio a paquetes, herramientas de red, persistencia y automatización solo después de que los límites estén documentados y probados.

FAQ

¿Por qué un analista de datos de IA necesita un sandbox?

Necesita un sandbox porque el flujo de trabajo combina archivos no confiables, código Python generado por el modelo, solicitudes de paquetes, generación de gráficos y artefactos descargables. Ejecutar ese trabajo en un entorno separado le da a tu aplicación un lugar para aplicar controles de archivos, recursos, paquetes, red, registro y limpieza.

¿Debería el modelo ver el CSV completo?

Generalmente no. Comienza enviando al modelo un resumen del esquema, muestras seguras, descripciones de columnas y la pregunta del usuario. Mantén el archivo sin procesar en el sandbox a menos que tu producto tenga una razón revisada para exponer más datos al modelo.

¿Se pueden permitir las instalaciones de paquetes?

Sí, pero deben controlarse. Usa una imagen preconstruida, lista blanca, versiones fijas, espejo privado o flujo de trabajo de aprobación. No dejes que el código generado por el modelo instale paquetes arbitrarios desde internet público sin revisión.

¿Qué archivos debería devolver la aplicación a los usuarios?

Devuelve solo archivos validados de un directorio de salida conocido, como imágenes de gráficos, JSON de resumen y exportaciones CSV sanitizadas. Bloquea extensiones inesperadas, archivos grandes, rutas ocultas y artefactos que no formaban parte del contrato de salida.

¿Esto es una garantía de cumplimiento?

No. Un sandbox es una parte de la arquitectura de ejecución. La aprobación de cumplimiento y seguridad depende de tus datos, modelo de amenazas, controles, registro, retención, proceso de revisión y entorno de despliegue.

Artículos recomendados

• Ejecuta Codex o un agente de codificación en un sandbox seguro
• Servidores MCP en sandboxes aislados: sistema de archivos, secretos y compensaciones de red
• Firecracker para sandboxes de agentes de IA: beneficios, límites y preguntas de evaluación