Objetivos de la unidad

Al finalizar esta unidad el alumnado sera capaz de:

• Identificar y catalogar los componentes de software que forman un sistema de IA en produccion
• Documentar versiones, licencias y dependencias siguiendo estandares de trazabilidad
• Comparar sistemas operativos, entornos de ejecucion y librerías de ML segun el caso de uso
• Gestionar el inventario de licencias y cumplir con las obligaciones de propiedad industrial
• Aplicar medidas de ergonomía cognitiva y prevencion del tecnoestrés en el puesto de trabajo

Resultado de aprendizaje: Administra la informacion de los componentes de las aplicaciones para garantizar su localizacion, control y disponibilidad.

Componentes generales — Sistemas operativos para IA

Ubuntu 22.04 LTS es la distribucion de referencia en entornos de IA por su amplia compatibilidad con drivers NVIDIA y repositorios de ML.

Componentes generales — Entornos de ejecucion GPU

Librerias de ML — PyTorch y TensorFlow

Librerias de ML — scikit-learn y ONNX Runtime

ONNX Runtime permite servir modelos de PyTorch o TF sin dependencia del framework original, reduciendo la huella de produccion.

Frameworks de despliegue — Triton y TF Serving

Frameworks de despliegue — BentoML y TorchServe

BentoML es especialmente adecuado para equipos que trabajan con multiples frameworks a la vez y necesitan empaquetar modelos como microservicios autocontenidos.

Herramientas MLOps — MLflow y DVC

Herramientas MLOps — Apache Airflow y Kubeflow

Para sistemas de IA en produccion, la combinacion MLflow + Airflow + Triton cubre el ciclo completo desde el experimento hasta el servicio.

Formatos de modelos — ONNX y GGUF

ONNX (Open Neural Network Exchange)

• Formato de intercambio estandar para redes neuronales impulsado por Microsoft y Meta.
• Permite exportar modelos de PyTorch o TensorFlow y ejecutarlos en ONNX Runtime, OpenVINO o TensorRT.
• Version actual: ONNX 1.16 (opset 20). Soporta FP32, FP16, INT8, BF16.
• Uso tipico: inferencia multiplataforma, despliegue en edge e IoT.

GGUF (GPT-Generated Unified Format)

• Formato binario de la libreria llama.cpp para modelos de lenguaje cuantizados.
• Reemplaza al formato GGML. Incluye metadatos del modelo (arquitectura, tokenizador, hiperparametros) en una unica cabecera.
• Soporta cuantizacion: Q4_K_M, Q5_K_M, Q8_0, F16... ideal para inferencia en CPU o GPU consumer.
• Uso tipico: ejecucion de LLM en hardware limitado sin dependencias de Python.

Formatos de modelos — SafeTensors y PMML

SafeTensors

• Formato de almacenamiento de tensores disenado por Hugging Face como alternativa segura a pickle.
• Evita la ejecucion de codigo arbitrario al cargar pesos: no utiliza serializacion Python.
• Carga rapida mediante mapeo de memoria (mmap). Compatible con PyTorch, JAX, TensorFlow y NumPy.
• Uso tipico: distribucion de pesos de modelos en Hugging Face Hub y entornos de produccion seguros.

PMML (Predictive Model Markup Language)

• Estandar XML del Data Mining Group para describir modelos de ML clasico.
• Version actual: PMML 4.4.1. Soporta regresion, arboles de decision, SVM, redes neuronales simples.
• Permite portabilidad entre herramientas: scikit-learn (via sklearn2pmml), R, SAS, KNIME.
• Uso tipico: integracion de modelos en sistemas de negocio (ERP, CRM) que no ejecutan Python.

Documentacion de versiones — Ficha de componente (YAML)

Cada componente de un sistema de IA debe disponer de una ficha tecnica registrada en el repositorio de configuracion:

componente:
  nombre: "PyTorch"
  version: "2.3.1"
  tipo: "libreria-ml"
  fabricante: "Meta AI / Linux Foundation"
  licencia: "BSD-3-Clause"
  url_licencia: "https://github.com/pytorch/pytorch/blob/main/LICENSE"
  fecha_instalacion: "2025-03-15"
  entorno: "produccion"
  servidor: "gpu-server-01.empresa.local"
  ruta_instalacion: "/opt/conda/envs/inference/lib/python3.11/site-packages/torch"
  dependencias:
    - "CUDA 12.1"
    - "cuDNN 8.9.7"
    - "numpy>=1.24"
    - "filelock"
    - "typing-extensions>=4.8"
  hash_verificacion: "sha256:a1b2c3d4..."
  responsable: "equipo-mlops"
  proximo_revision: "2025-09-15"
  notas: "Instalado con soporte ROCm desactivado. Ver ticket INC-2041."

Documentacion de versiones — Campos obligatorios del registro

El registro corporativo de componentes de IA debe incluir como minimo los siguientes campos para cumplir con los requisitos de trazabilidad:

Trazabilidad de la arquitectura de software

La trazabilidad permite reconstruir en cualquier momento el estado exacto del sistema. Se representa mediante un arbol de dependencias:

Sistema de inferencia (produccion)
├── SO: Ubuntu 22.04.4 LTS
│   ├── kernel: 5.15.0-112-generic
│   └── glibc: 2.35
├── Runtime GPU: CUDA 12.1.1
│   ├── Driver NVIDIA: 535.183.01
│   └── cuDNN: 8.9.7
├── Entorno Python: conda env "inference" (Python 3.11.8)
│   ├── torch==2.3.1+cu121
│   │   ├── numpy==1.26.4
│   │   └── filelock==3.13.1
│   └── tritonclient==2.45.0
│       ├── grpcio==1.62.1
│       └── protobuf==4.25.3
└── Servidor de inferencia: Triton 2.45.0
    └── Backend TensorRT: 10.0.1.6

Herramientas: pip freeze, conda env export, pip-audit, syft (SBOM), syft + grype para vulnerabilidades.

Control de licencias — Tipos y obligaciones

Atencion AGPL-3.0: Si se modifica un componente AGPL y se expone como servicio web, se debe publicar el codigo fuente completo. Muchas empresas prohíben el uso de AGPL en produccion.

Control de licencias — Inventario y propiedad industrial

Inventario de licencias

• Mantener un archivo LICENSES.csv en el repositorio con todos los componentes de terceros.
• Herramientas de escaneo automatico: pip-licenses, license-checker (Node), fossa, TLDR Legal.
• Integrar el escaneo en el pipeline CI/CD como paso obligatorio antes del despliegue.

Propiedad industrial en sistemas de IA

• Los modelos entrenados con datos propietarios son activos de la empresa: documentar la cadena de custodia del dataset.
• Verificar las condiciones de uso de modelos base (Llama 3, Mistral, Falcon): algunas imponen restricciones de uso comercial o de escala.
• Los pesos de un modelo entrenado por la empresa pueden registrarse como obra derivada o secreto industrial.
• La documentacion tecnica (fichas de componentes, diagramas de arquitectura) tiene valor probatorio en caso de litigio.

Gestion de dependencias y recuperacion ante fallos

Exportacion del entorno de produccion

# Con pip — genera requirements.txt con versiones exactas
pip freeze > requirements_prod_20250615.txt

# Con conda — incluye dependencias del sistema y canales
conda env export --no-builds > environment_prod_20250615.yml

# Solo dependencias directas (sin transitivas)
pip list --format=freeze --not-required > requirements_direct.txt

Recreacion del entorno (rollback)

# Recrear entorno conda exacto
conda env create -f environment_prod_20250615.yml -n inference_restore

# Recrear entorno pip en venv
python3.11 -m venv venv_restore
source venv_restore/bin/activate
pip install -r requirements_prod_20250615.txt

Guardar los archivos de entorno en el repositorio de configuracion junto a la ficha de componentes. Versionar con fecha en el nombre.

Riesgos psicosociales y tecnoestrés

La administracion de sistemas de IA implica alta carga cognitiva: multiples herramientas, actualizaciones frecuentes, incidencias en produccion y presion temporal. El tecnoestrés es el malestar psicologico derivado de la interaccion con la tecnologia.

Factores de riesgo identificados

• Interrupciones frecuentes por alertas y tickets
• Exigencia de disponibilidad fuera del horario laboral (oncall)
• Obsolescencia rapida de conocimientos (actualizaciones continuas de frameworks)
• Ambiguedad de rol en equipos donde convergen perfiles de software, datos y sistemas

Senales de alerta

• Dificultad para desconectar del trabajo al finalizar la jornada
• Irritabilidad o ansiedad ante nuevas actualizaciones o cambios de herramienta
• Errores frecuentes por falta de concentracion
• Fatiga visual persistente al final del dia

El reconocimiento de estos riesgos es el primer paso para aplicar medidas preventivas colectivas e individuales.

Ergonomia visual y pausas activas

Actividad practica

Auditoria de dependencias y documentacion de componentes

Objetivo: Auditar las dependencias de un entorno Python de inferencia y generar la ficha de componente siguiendo la plantilla YAML de la unidad.

Pasos:

1. Activar el entorno virtual proporcionado por el instructor (conda activate inference_lab)
2. Ejecutar pip freeze > requirements_auditoria.txt y examinar la salida
3. Identificar los 5 componentes principales (framework ML, runtime, servidor de inferencia, librerias de soporte, herramienta MLOps)
4. Para cada componente, verificar la licencia con pip-licenses --format=markdown
5. Completar la plantilla YAML de ficha de componente para al menos 3 componentes
6. Generar el arbol de dependencias con pipdeptree --graph-output png > arbol_dependencias.png
7. Identificar si algun componente usa licencia GPL o AGPL y documentar las implicaciones

Entregable: Archivo ZIP con requirements_auditoria.txt, 3 fichas YAML y un informe breve en Markdown con la tabla de licencias y las implicaciones detectadas.

Puntos clave

• Los sistemas de IA en produccion combinan componentes de distintas categorias: SO, runtime GPU, librerías de ML, frameworks de despliegue y herramientas MLOps. Cada categoria tiene sus propios ciclos de version y licencias.
• La ficha de componente en YAML es la unidad basica de trazabilidad: nombre, version, licencia, dependencias, entorno y responsable son campos obligatorios.
• ONNX es el formato de interoperabilidad entre frameworks; SafeTensors es el estandar seguro para distribuir pesos; GGUF permite inferencia de LLM en hardware limitado.
• Las licencias copyleft (especialmente AGPL-3.0) pueden imponer obligaciones legales en servicios web. El escaneo automatico de licencias debe integrarse en CI/CD.
• La exportacion del entorno (pip freeze, conda env export) y su almacenamiento versionado son la base de la recuperacion ante fallos.
• El tecnoestrés y la fatiga visual son riesgos reales en la administracion de sistemas de IA. La organizacion debe implementar medidas preventivas: pausas activas, gestion de notificaciones y ergonomia del puesto.

Criterios de evaluacion

Navegación

← UD1 · Integración de componentes fí…  ·  Volver al módulo  ·  UD3 · Implementación de componentes… →