IA generativa en producción: qué cambia al salir del piloto

Publicado: 2026-06-22 · Actualizado: 2026-10-28

Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative

Qué cambia al llevar IA generativa del piloto a producción: evaluación, latencia, costes de API, observabilidad, seguridad, gobierno de datos y mantenimiento.

Pasar IA generativa de un piloto a producción cambia, sobre todo, la forma de medir el éxito. El piloto demuestra que un modelo puede hacer la tarea con ejemplos escogidos; la producción exige que la haga con entradas reales, a escala, con una latencia aceptable, un coste por uso controlado y la posibilidad de explicar qué pasó cuando falla. El modelo suele ser lo que menos cambia: lo que se añade a su alrededor es evaluación, observabilidad, seguridad, gobierno de datos y mantenimiento.

En la práctica supone un conjunto de pruebas con casos reales que se ejecuta antes de cada cambio, objetivos de latencia por tipo de tarea, límites de gasto, una traza de cada llamada al modelo, validación de las salidas antes de que lleguen a otros sistemas, reglas sobre qué datos salen hacia el proveedor y un responsable que mantenga el sistema cuando cambien el modelo, la API o las fuentes.

A continuación: una tabla comparativa, cada frente explicado con sus fuentes, un ejemplo hipotético y los costes.

Qué cambia entre un piloto y producción: tabla comparativa

Aspecto	En el piloto	En producción
Datos de prueba	Ejemplos escogidos por el equipo	Entradas reales: largas, incompletas, ambiguas o con instrucciones maliciosas
Calidad	Impresión de que «funciona»	Conjunto de evaluación versionado, criterios de acierto y un umbral para publicar cambios
Latencia	Se tolera esperar	Objetivo por tipo de tarea, con streaming o proceso en segundo plano
Coste	Pocas llamadas, sin seguimiento	Coste por tarea terminada, límites por usuario y alertas de gasto
Observabilidad	Mensajes en la consola	Traza de cada petición: versión del prompt, modelo, contexto, tokens, latencia, resultado y valoración
Seguridad	Usuarios de confianza	Entradas no confiables, validación de salidas y permisos mínimos
Datos	Copias de prueba	Contrato con el proveedor, región, retención, datos personales y permisos de acceso
Mantenimiento	Sin responsable	Propietario del sistema y revisión de cambios de modelo, API y fuentes

Ninguna fila es exótica: es lo que se exige a cualquier software en producción. La diferencia es que un modelo de lenguaje no siempre responde igual a la misma entrada, así que la calidad se comprueba de forma continua.

Evaluación: medir la calidad antes de cada cambio

La evaluación es lo que más separa un piloto de un producto: sin ella, cambiar el prompt, el modelo o la recuperación de documentos es una apuesta. Las buenas prácticas de evaluación de OpenAI proponen evaluar pronto y a menudo, registrar todo para sacar casos de los logs y desconfiar de las evaluaciones basadas en impresiones. La guía de Anthropic para diseñar evaluaciones pide pruebas que reflejen la distribución real de la tarea, con sus casos límite, y prefiere muchas preguntas con corrección automática a pocas revisadas a mano.

Un conjunto de evaluación útil se construye así:

Casos reales y anonimizados: los típicos, los difíciles y los que ya fallaron. Los casos límite que cita Anthropic —entradas irrelevantes, demasiado largas o ambiguas— suelen concentrar buena parte del trabajo.
Un criterio de acierto por caso: campos que deben aparecer, fuentes que hay que citar, acciones prohibidas o tono esperado.
Corrección automática donde se pueda: código para formato y campos, y un modelo evaluador para lo subjetivo, calibrado antes con valoraciones humanas, como recomienda OpenAI.
Umbral y regresión: el conjunto se ejecuta con cada cambio y no se publica nada que empeore el resultado.
Crecimiento continuo: cada fallo detectado en producción se convierte en un caso nuevo.

Hay más detalle sobre métodos de prueba en testing de sistemas de IA.

Latencia: diseñar para la espera

Un usuario acepta esperar a un resumen largo, pero no a una sugerencia mientras escribe. Mide el tiempo hasta el primer token, que marca la sensación de respuesta con streaming, y el tiempo total de la tarea, que suele incluir varias llamadas. En su guía para reducir la latencia, Anthropic aconseja conseguir primero un prompt que funcione y optimizar después.

La guía de optimización de latencia de OpenAI resume las palancas en siete principios; los más útiles en empresa son:

Usar un modelo más pequeño en los pasos sencillos, como clasificar o extraer.
Generar menos tokens: respuestas breves y estructuras simples.
Enviar menos contexto: solo los fragmentos relevantes, no documentos enteros.
Hacer menos peticiones y paralelizar las que no dependen entre sí.
Hacer esperar menos al usuario: streaming, pasos visibles y estados de carga.
No usar un modelo cuando no hace falta: respuestas precalculadas, reglas o una interfaz específica.

Lo que no necesita respuesta inmediata puede ir a una cola, y algunos proveedores ofrecen procesamiento por lotes más barato, como la Batch API de OpenAI, con resultados en un plazo de hasta 24 horas.

Costes de API: controlar el coste por tarea

Los modelos se pagan por tokens de entrada y de salida, y en producción una tarea rara vez es una sola llamada: suele haber recuperación de contexto, generación, validación y algún reintento. Por eso la métrica útil es el coste por tarea terminada, no el precio por llamada. Las medidas que más lo controlan son:

Elegir el modelo por paso: uno pequeño para clasificar o extraer y uno más capaz solo donde la calidad lo exige.
Aprovechar la caché de prompts: según la documentación de OpenAI, reutiliza el comienzo idéntico de un prompt y abarata los tokens repetidos, así que conviene poner primero las instrucciones y el material estable, y al final lo variable.
Limitar el contexto: recuperar pocos fragmentos relevantes y resumir los historiales largos.
Poner límites y alertas: OWASP recoge el consumo sin control como Unbounded Consumption (LLM10:2025) y recomienda cuotas por usuario, topes al tamaño de las entradas, tiempos máximos y vigilancia del consumo.

Antes de abrir el sistema a todos los usuarios, calcula el coste con tus volúmenes reales y la tarifa vigente del modelo en tres escenarios: bajo, medio y alto.

Observabilidad: poder explicar cada respuesta

Cuando una respuesta sale mal hay que poder saber por qué: si el prompt era ambiguo, si el contexto recuperado estaba incompleto, si la entrada venía mal formada o si el modelo no sabía hacer la tarea. Para eso, cada petición debe dejar una traza con:

La versión del prompt y del modelo.
Los documentos o datos recuperados y las herramientas llamadas.
Los tokens consumidos, el coste y la latencia de cada paso.
La salida, el resultado de su validación y la valoración del usuario, si la hay.

Para no atarse a una herramienta concreta, OpenTelemetry está definiendo convenciones semánticas para IA generativa: trazas, métricas y eventos para las llamadas a modelos y para MCP. Y como esas trazas guardan lo que escriben los usuarios, que puede incluir datos personales, necesitan permisos de acceso y plazo de conservación.

Seguridad: el modelo no es una fuente de confianza

El OWASP Top 10 para aplicaciones con LLM 2025 es una referencia habitual para revisar estos sistemas. Al pasar a producción hay tres riesgos que conviene revisar siempre:

Inyección de instrucciones (LLM01:2025): las órdenes pueden venir del usuario o escondidas en un documento, una web o un correo. Ni RAG ni el ajuste fino la eliminan del todo; OWASP recomienda mínimo privilegio, funciones privilegiadas en código, aprobación humana en acciones de alto riesgo, separar el contenido externo y pruebas adversarias.
Manejo inadecuado de la salida (LLM05:2025): lo que genera el modelo se valida como cualquier entrada de usuario antes de llegar a una base de datos, un navegador u otro sistema, con consultas parametrizadas y codificación según el contexto.
Divulgación de información sensible (LLM02:2025): el modelo puede repetir lo que tiene en su contexto, así que no debe recibir lo que el usuario no podría ver.

Las salidas estructuradas ayudan, pero no bastan. Structured Outputs de OpenAI garantiza que la respuesta cumple el esquema JSON indicado, no que los datos sean correctos: las reglas de negocio, como importes, fechas o la existencia de un cliente, se siguen comprobando en código.

Gobierno de datos y cumplimiento

Antes de producción hay que decidir qué datos salen hacia el proveedor y en qué condiciones: si se usan para entrenar, cuánto se conservan y dónde se procesan. Por ejemplo, la documentación de OpenAI sobre datos en la API indica que por defecto no los usa para entrenar, que conserva registros hasta 30 días para vigilar abusos y que ofrece residencia de datos en Europa con condiciones. Cada proveedor tiene su equivalente, y conviene leerlo antes de firmar.

Si las peticiones contienen datos personales, el tratamiento entra en el RGPD: base jurídica, contrato de encargo con el proveedor, minimización y plazos de conservación, también para los logs. El artículo 50 del Reglamento europeo de IA obliga a diseñar los sistemas que interactúan con personas para que estas sepan que hablan con una IA, salvo que resulte evidente, y el artículo 4 pide medidas para favorecer la alfabetización en IA del personal. Para repartir responsabilidades sirve el AI RMF del NIST, un marco voluntario. La vigencia de las fuentes también es gobierno de datos; lo tratamos en cómo preparar los datos de tu empresa para IA.

Mantenimiento: el sistema cambia aunque no lo toques

Un sistema con IA generativa depende de piezas que no controlas. Los proveedores retiran modelos: según su página de retirada de modelos, Anthropic avisa con al menos 60 días de antelación antes de retirar un modelo publicado y recomienda probar las aplicaciones con los nuevos mucho antes. También cambian las API: Anthropic ha retirado los parámetros temperature, top_p y top_k en su versión de API 2026-10-21. Y están los cambios propios: políticas, documentos o sistemas nuevos.

Fijar versiones de modelo y de API, y cambiarlas solo después de pasar la evaluación.
Mantener al día las fuentes: documentos que se actualizan, se reindexan y se retiran cuando caducan.
Revisar cada mes una muestra de respuestas reales y añadir los fallos al conjunto de evaluación.
Revisar costes y límites a medida que crece el uso.
Tener una capa propia de orquestación entre la aplicación y el modelo, para cambiar de proveedor sin rehacer el producto.

Ejemplo hipotético: un asistente de soporte que pasa a producción

Este escenario es hipotético e ilustrativo, no un caso de cliente. Una empresa de software B2B ha probado un asistente que redacta respuestas a tickets con su documentación; con tickets escogidos y pocas personas probándolo, parecía funcionar. Para abrirlo a todo el equipo de soporte, el plan incluiría:

Evaluación: tickets reales anonimizados, incluidos los incompletos o que mezclan dos problemas, con criterios de acierto revisados por soporte.
Latencia: el borrador se genera en segundo plano al entrar el ticket, para que esté listo cuando alguien lo abre.
Coste: un modelo pequeño clasifica y uno más capaz redacta solo cuando hace falta; las instrucciones fijas van al principio para aprovechar la caché.
Seguridad: el texto del ticket se trata como contenido no confiable y el asistente nunca envía nada: propone y una persona envía.
Datos y observabilidad: las trazas guardan referencias en lugar de datos personales completos, con acceso restringido y plazo de conservación.
Mantenimiento: una persona de soporte mantiene el conjunto de evaluación y revisa cada mes una muestra.

Nada de esto cambia el modelo. Cambia todo lo que lo rodea, y es lo que permite saber si el asistente ahorra tiempo de verdad.

Cuánto cuesta llevar IA generativa a producción

Estos son los rangos de desarrollo de nuestro informe de precios 2026 para los proyectos de IA generativa más habituales:

Automatización acotada con IA (documentos, correos, CRM o clasificación con revisión humana): 10.000-20.000 €, en 4-6 semanas.
Chatbot o asistente con RAG, con fuentes y panel de gestión: 10.000-25.000 €, en 4-8 semanas.
Copiloto interno integrado en CRM, helpdesk o herramientas internas, con permisos por rol: 20.000-50.000 €, en 6-12 semanas.

Los costes recurrentes son tres: el uso de modelos por API, desde unos 100 € al mes con poco volumen y entre 2.000 y 5.000 € al mes con volumen alto; la infraestructura cloud, entre 50 y 500 € al mes según tráfico y datos; y el mantenimiento evolutivo y correctivo, entre el 15 y el 25 % del coste de desarrollo al año. El desglose está en cuánto cuesta automatizar procesos con IA.

Si ya tienes un piloto, parte del trabajo está hecho, pero rara vez la parte más cara: suelen faltar la evaluación, la integración con los sistemas reales y los controles. Una auditoría técnica de IA ayuda a ver qué se aprovecha.

Preguntas frecuentes

¿Qué cambia al pasar IA generativa de un piloto a producción?

Cambia el criterio de éxito: ya no basta con que funcione con ejemplos escogidos. Hay que evaluar con casos reales antes de cada cambio, controlar latencia y coste por tarea, registrar cada llamada, validar las salidas, decidir qué datos van al proveedor y nombrar un responsable.

¿Cómo se evalúa un sistema de IA generativa?

Con casos reales anonimizados, incluidos los difíciles, y un criterio de acierto por caso. Se corrige de forma automática donde se puede, con revisión humana por muestreo, y se ejecuta con cada cambio de prompt, modelo o fuentes.

¿Cómo se controla el coste de la IA generativa en producción?

Midiendo el coste por tarea terminada, usando en cada paso el modelo más pequeño que cumpla, aprovechando la caché de prompts, limitando el contexto y fijando cuotas con alertas. El uso por API va desde unos 100 € al mes con poco volumen hasta 2.000-5.000 € con volumen alto.

¿Qué hay que registrar para observar un sistema de IA generativa?

Conviene registrar la versión del prompt y del modelo, el contexto recuperado, herramientas llamadas, tokens, coste, latencia, salida, resultado de la validación y valoración del usuario, con acceso restringido y plazo de conservación.

¿Qué mantenimiento necesita un sistema de IA generativa?

Seguir los cambios y retiradas de modelos y API, mantener al día las fuentes, ampliar la evaluación con los fallos detectados y vigilar costes y límites. Como referencia, supone entre el 15 y el 25 % del coste de desarrollo al año.