Desafíos de programar con IA: del entorno técnico a la escalabilidad

Programar con inteligencia artificial (IA) ha dejado de ser cosa de laboratorios o equipos de investigación. Hoy cualquier desarrollador medio acaba tocando, de una forma u otra, modelos de lenguaje (LLM), agentes, almacenes vectoriales o pipelines de datos. El cambio de escala viene con una lista de retos que no se resuelven afinando el prompt: gestión de datos, control del modelo, seguridad, coste de infraestructura y operación continua. Repasamos los más relevantes y cómo encajan en el día a día de un equipo técnico.

Entender el entorno antes de tocar el modelo

El primer error habitual es saltar al código del modelo sin tener claro el resto del sistema. Una aplicación con IA no es solo el LLM o la red neuronal: incluye la fuente de datos, el preprocesado, el almacén vectorial si se usa retrieval augmented generation (RAG), la capa de orquestación, los guardrails, las métricas y la auditoría. Subestimar ese andamiaje suele acabar en demos brillantes que se rompen el primer día en producción.

El equipo necesita decidir desde el principio si la lógica vivirá dentro del modelo (instrucciones largas, fine-tuning) o fuera (código determinista que llama al modelo solo cuando hace falta). Esa separación se nota después en coste, mantenibilidad y depuración. Quien ya ha pasado por varias generaciones de modelos lo sabe: lo que ayer ajustabas en el prompt hoy lo mueves al código, y al revés, según el modelo de turno mejore en una capacidad concreta.

Modelos: del aprendizaje profundo clásico a los LLM y los SLM

Hace una década el desafío era entrenar redes neuronales convolucionales para visión o recurrentes para texto. Hoy la mayoría de los equipos no entrena el modelo desde cero: parte de modelos preentrenados de OpenAI, Anthropic, Google, Meta o Mistral y los adapta. El reto se desplaza a tres preguntas concretas: qué modelo elegir, cómo personalizarlo y dónde ejecutarlo.

La elección de modelo dejó de ser binaria entre «grande y caro» o «pequeño y limitado». Conviven modelos de frontera tipo GPT-5.5 o Claude para tareas de razonamiento y modelos pequeños (SLM, small language models) que corren en una GPU modesta o incluso en CPU. De ahí que cada vez más arquitecturas mezclen ambos: el modelo grande actúa de orquestador y los pequeños resuelven subtareas concretas con menor latencia y coste. Profundizamos en este enfoque en el artículo sobre correr IA en local frente a la nube, donde el equilibrio entre privacidad, latencia y coste se nota especialmente.

La personalización se mueve en una escala con varios escalones: prompt engineering, RAG con datos propios, fine-tuning supervisado, RLHF y, en el caso más avanzado, entrenamiento parcial. La decisión no es solo técnica, es económica. Un buen RAG resuelve el 80 % de los casos de uso empresariales sin tocar pesos del modelo y sin ataduras con el proveedor.

Datos: el cuello de botella real

La calidad del modelo importa menos que la calidad de los datos que lo alimentan. Aun así, los equipos siguen subestimando esta parte. Los problemas habituales se repiten:

• Datos sucios o inconsistentes: campos vacíos, codificaciones distintas, duplicados, fechas mal normalizadas.
• Sesgos históricos: el modelo aprende lo que había en el dataset, incluidos los prejuicios.
• Deriva (drift) en producción: la realidad cambia, el modelo se queda viejo y nadie se entera hasta que las métricas caen.
• Fugas entre train y test: validaciones optimistas que en producción no se reproducen.
• Falta de etiquetado: para tareas supervisadas sigue siendo necesario, y caro.

La consecuencia práctica es que cualquier proyecto serio dedica más tiempo a preparar datos que a entrenar o ajustar modelos. Quien no monta un data pipeline reproducible, con versionado tipo DVC o LakeFS y tests de calidad sobre los datos, termina arrastrando deuda técnica que multiplica los fallos.

Seguridad y privacidad: del cifrado al prompt injection

El mapa de riesgos se ha ampliado mucho desde que los modelos generativos llegaron al circuito empresarial. A los clásicos (cifrado en tránsito y en reposo, autenticación robusta, control de acceso por roles, registro de auditoría) se suman amenazas específicas de IA:

• Prompt injection: un atacante introduce instrucciones en una entrada (web, PDF, correo) que el modelo termina obedeciendo.
• Exfiltración de datos: el modelo, con acceso a herramientas, puede revelar información sensible si no hay aislamiento por contexto.
• Envenenamiento de datos: corromper la fuente de entrenamiento o de RAG para sesgar la salida.
• Ataques al modelo: extracción de pesos, inversión de modelo, jailbreaks de los guardrails.
• Cumplimiento normativo: el AI Act europeo y el RGPD obligan a documentar riesgos, datasets y decisiones automatizadas en sistemas considerados de alto riesgo.

Tratar al modelo como si fuese una librería fiable es un error. Conviene aplicar el mismo principio que con cualquier servicio externo: mínimos privilegios, validación de entrada y salida, sandboxing de las herramientas que el agente puede invocar y registros que permitan reconstruir lo que pasó cuando algo va mal. Para detectar datos sensibles antes de que entren al modelo o salgan en una respuesta empiezan a aparecer piezas específicas como el Privacy Filter abierto de OpenAI, útil tanto en pipelines de entrenamiento como en filtros de inferencia.

Despliegue, latencia y coste de inferencia

La escalabilidad ya no es solo cuestión de soportar más usuarios. La inferencia de un LLM mediano puede costar varios céntimos por petición y consumir GPU de forma intensiva. Cuando el producto crece, la factura de IA puede pasar a ser la partida principal de la infraestructura, por encima del cómputo clásico o del almacenamiento. La carrera por capacidad de cómputo ha llegado a tal punto que en Europa la IA empieza a chocar con un límite mucho más prosaico, la electricidad disponible, como cuenta este análisis sobre la carrera europea de la IA y el límite eléctrico publicado en Revista Cloud.

Las palancas para controlar este coste son varias y suelen combinarse:

• Routing de modelos: enviar las consultas triviales a SLM y reservar el modelo grande para lo difícil.
• Caché semántica: detectar preguntas similares ya respondidas y servir la respuesta cacheada.
• Cuantización y distillation: reducir el tamaño de los modelos sin perder demasiada calidad.
• Inferencia local o privada: para casos sensibles o de gran volumen estable, ejecutar en infraestructura propia sale más barato a medio plazo.
• Streaming y respuestas parciales: bajar la latencia percibida sin tocar la latencia real.

Llevar agentes IA a producción añade otra capa. Plataformas como las que Microsoft despliega en Foundry para agentes o las soluciones agénticas que OpenAI promueve con GPT-5.5 exigen pensar en límites de ejecución, presupuestos por conversación y trazabilidad de cada herramienta invocada. Y donde haya integración por Model Context Protocol (MCP), conviene revisar quién publica el servidor y qué permisos delega antes de conectarlo a un agente real.

Operación continua: monitorizar, evaluar, mejorar

Un modelo que funciona el día del despliegue no es lo mismo que un modelo que sigue funcionando seis meses después. La evaluación continua exige una batería de tests propios sobre casos de uso reales, no benchmarks genéricos. Conviene medir al menos tres dimensiones: calidad de la respuesta (con jueces humanos o con otro modelo como evaluador), latencia y coste por petición, y tasa de errores críticos como alucinaciones o fugas de datos.

La observabilidad específica de IA —trazas de prompt, herramientas usadas, tokens consumidos por sesión— ya forma parte de las plataformas modernas. Sin esa visibilidad, el equipo no puede mejorar el sistema, solo apagar fuegos cuando un cliente reporta un fallo.

Equipos y procesos, no solo código

Los proyectos que cuajan suelen tener perfiles cruzados: ingeniería de software, datos, MLOps, seguridad y producto. Los que se quedan en la fase demo dependen casi siempre de una persona heroica que sabe de modelos pero no acaba pasando ese conocimiento al resto. Documentar decisiones, versionar prompts, automatizar tests y compartir métricas pesa tanto como elegir el modelo correcto.

Preguntas frecuentes

¿Necesito entrenar mi propio modelo de IA para crear una aplicación seria?

En la mayoría de los casos no. Los modelos preentrenados de OpenAI, Anthropic, Google, Meta o Mistral cubren la mayor parte de las necesidades. Para incorporar conocimiento propio se suele recurrir a RAG y, solo cuando hace falta, a fine-tuning. Entrenar desde cero solo tiene sentido si tienes datos muy específicos y restricciones legales o de soberanía que lo justifiquen.

¿Qué lenguaje y librerías se usan hoy para programar con IA?

Python sigue siendo el lenguaje dominante por su ecosistema (Hugging Face Transformers, PyTorch, LangChain, LlamaIndex, vLLM). Para servicios en producción se combinan Python, TypeScript o Go en la capa de orquestación y Rust o C++ en componentes críticos de inferencia. La elección depende más del equipo y la operación que de la tarea.

¿Cómo se controlan las alucinaciones de un LLM?

Con varias capas combinadas: instrucciones claras, RAG con fuentes verificadas, validadores de salida (esquemas JSON, reglas de negocio), evaluación automática con otro modelo y revisión humana en los flujos sensibles. Ningún modelo elimina al cien por cien las alucinaciones, así que el diseño del sistema debe asumir que pueden ocurrir.

¿Es viable correr un LLM dentro de la propia infraestructura?

Sí, y cada vez más. Modelos abiertos como Llama, Mistral, Qwen o DeepSeek funcionan razonablemente bien en GPU de consumo o en servidores con una o dos GPU profesionales. Para casos con datos sensibles o volúmenes muy estables, la inferencia local suele compensar frente a pagar por API. La contrapartida es asumir tú el coste operativo del cluster.

¿Qué obligaciones impone el AI Act a quien programa con IA?

El reglamento europeo de IA clasifica los sistemas por nivel de riesgo. Para los sistemas de alto riesgo (selección de personal, scoring crediticio, infraestructuras críticas) exige documentación técnica, registros, supervisión humana y evaluación previa al despliegue. También marca obligaciones de transparencia para los modelos generativos. Conviene revisar el texto en eur-lex.europa.eu antes de diseñar el sistema, no después.