Construye un Analista de Datos AI con Python en Sandbox y Acceso Controlado a Paquetes

Construye un Analista de Datos AI con Python en Sandbox y Acceso Controlado a Paquetes

Un analista de datos AI 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áctica es: cargar un archivo, inspeccionar el esquema con código confiable, pedir un plan al modelo, revisar el Python generado, ejecutarlo en un sandbox restringido, validar los artefactos de salida y mostrar al usuario lo que sucedió.

Arquitectura del Analista de Datos AI: Cargar, Analizar, Revisar

El patrón del producto es simple en apariencia: un usuario carga un CSV, hace una pregunta en lenguaje natural y espera tablas útiles, gráficos y archivos descargables. Debajo del capó, la aplicación ejecuta un pequeño flujo de trabajo de agente con efectos secundarios reales. El modelo planifica el análisis y redacta 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. Acepta una carga CSV para un trabajo de análisis.
  2. Crea un espacio de trabajo sandbox con ámbito de trabajo.
  3. Ejecuta código propio de inspección de esquema antes de pedir Python al modelo.
  4. Pide al modelo un plan de análisis y luego un script que siga tus reglas de archivos y paquetes.
  5. Ejecuta el script con límites de tiempo, memoria, disco, paquetes y red.
  6. Recoge solo artefactos validados de un directorio de salida conocido.
  7. Muestra al usuario la respuesta, gráficos, advertencias, registros y archivos seleccionados para descarga.

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 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 principal de aplicación. 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 AI, el sandbox generalmente se encarga de estas tareas:

Tarea del sandbox Por qué pertenece allí
Preparación de archivos El CSV cargado se puede escanear y copiar 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 aplicaciones 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 se pueden recoger de un directorio de salida conocido.
Limpieza Los archivos temporales, el código generado y el estado de la sesión se pueden eliminar o dejar expirar.

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, la 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 de 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 se involucre. 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 deben desinfectarse también 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 preparación con ámbito de 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 Python el Modelo de Forma 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 se acepte el plan, 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 luego 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 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.

Acceso Controlado a Paquetes de Python para Análisis de Datos con AI

El acceso a paquetes es donde muchas demostraciones de analistas de datos AI 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 debería 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 con datos regulados Más trabajo operativo, mejor control sobre la cadena de suministro
Instalaciones aprobadas por el usuario Herramientas exploratorias para usuarios confiables 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 pequeño conjunto 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é, y luego dirige esa solicitud a través de aprobación humana o un flujo de trabajo de revisión de paquetes.

Registra nombre del paquete, versión, registro de origen, 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 dejar 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 equivocado. Un CSV puede contener valores similares a fórmulas. Un cuaderno puede incluir código oculto. Un ZIP puede contener rutas inesperadas. Trata los artefactos como elementos a 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 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.

Proporciona 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 basar 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 AI 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 ir más allá 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 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, cantidad de procesos y tiempo de reloj?
Política de red ¿Está el acceso de red saliente desactivado, en lista blanca, 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 ¿Se mantienen las claves de API, credenciales de base de datos y tokens de servicio fuera del sandbox a menos que estén explícitamente definidos?
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 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 egreso 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 estar bloqueado o en lista blanca estricta por defecto. Si el analista necesita datos externos en vivo, conviértelo en una herramienta separada con su propia aprobación y ruta de registro.

Usando Novita Agent Sandbox como Capa de Ejecución

Novita Agent Sandbox proporciona entornos de ejecución aislados y con estado para agentes AI. La documentación actual de Novita describe soporte para ejecutar código, instalar dependencias, acceder a archivos, usar navegadores y conservar el estado de ejecución entre sesiones. Para un analista de datos AI, esos primitivos se asignan directamente a la parte de ejecución de la arquitectura: crear un espacio de trabajo para el trabajo, mover archivos, ejecutar código de análisis, recoger artefactos y limpiar o conservar 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 de SDK para Python y JavaScript/TypeScript, lo que se ajusta a 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 preparar archivos CSV y artefactos generados dentro de un espacio de trabajo con ámbito de trabajo.

Mantén la distinción clara:

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

Esa separación ayuda a los equipos a construir con un modelo de responsabilidad limpio. El modelo sugiere y explica el análisis. La aplicación aplica la política del producto. El sandbox proporciona el entorno 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 de analista de datos AI no es “dejar que el modelo ejecute Python”. Es un bucle controlado: inspeccionar el conjunto de datos, pedir 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 de paquetes corta, 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 AI necesita un sandbox?

Necesita un sandbox porque el flujo de trabajo combina archivos no confiables, 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 instalaciones de paquetes?

Sí, pero deben ser controladas. Usa una imagen preconstruida, lista blanca, versiones fijas, espejo privado o flujo de trabajo de aprobación. No permitas 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 desinfectadas. Bloquea extensiones inesperadas, archivos grandes, rutas ocultas y artefactos que no formaban parte del contrato de salida.

¿Es esto 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 implementación.

Artículos recomendados