Sobre el escenario, un agente atiende una solicitud, consulta documentos y ejecuta una acción en pocos segundos. En la empresa, esa misma secuencia debe lidiar con permisos de acceso, un software antiguo y una factura. El RAISE Summit, la cita parisina dedicada a la inteligencia artificial, ofrece un punto de partida útil para analizar esa brecha entre la promesa y el funcionamiento en producción. Con la vista puesta en septiembre de 2026, la cuestión ya no es solo qué puede producir un modelo, sino en qué condiciones se le puede confiar una tarea. Este análisis se apoya en avances documentados antes de esa fecha; las proyecciones hacia septiembre de 2026 son prospectivas, y no una crónica de futuros anuncios.
¿El modelo más potente es el adecuado?
La carrera por los modelos ha instaurado un hábito: comparar las puntuaciones y elegir al primero de la clasificación. Sin embargo, una empresa no compra un puesto en el podio. Busca, por ejemplo, extraer cláusulas contractuales o responder correctamente a consultas sobre un catálogo. Estas tareas requieren capacidades distintas. Un rendimiento medio elevado en pruebas públicas no garantiza ni el dominio de un vocabulario sectorial ni la solidez ante documentos mal estructurados.
Primera pregunta que hay que plantear tras una demostración: ¿con qué conjunto de evaluación se ha validado el sistema? Se necesitan casos representativos, errores conocidos, documentos recientes y situaciones en las que la respuesta correcta sea abstenerse. En el caso de un asistente de soporte, medir únicamente la satisfacción aparente puede ocultar respuestas convincentes pero falsas. También hay que hacer un seguimiento de las resoluciones efectivas y las correcciones humanas.
Las familias Llama, Mistral o Qwen han convertido el uso de modelos de pesos abiertos en una opción creíble en numerosos escenarios. Eso no significa automáticamente software libre, ausencia de restricciones o funcionamiento gratuito. Por su parte, una API propietaria puede acelerar la puesta en marcha, al tiempo que genera una dependencia de las tarifas, las versiones y las condiciones del proveedor. La decisión adecuada debe tener en cuenta el sistema completo, no solo la disponibilidad de los pesos.
RAG, adaptación, agentes: preguntar por qué
La generación aumentada por recuperación, o RAG, consiste en proporcionar al modelo información buscada en una base documental. Puede actualizar las respuestas sin volver a entrenar el modelo. Pero desplaza parte del problema: ¿están los documentos correctamente segmentados, indexados y filtrados según los permisos? Si el motor recupera un procedimiento obsoleto, el mejor generador puede producir una respuesta incorrecta con una seguridad impecable.
La adaptación de un modelo mediante entrenamiento adicional responde a otras necesidades, como estabilizar un formato o especializar un comportamiento. No sustituye necesariamente a una fuente documental actualizada. En cuanto a los agentes, capaces de encadenar llamadas a herramientas, añaden nuevos puntos de fallo. Un error de lectura puede convertirse en una modificación incorrecta en un software empresarial.
La pregunta útil pasa a ser: ¿por qué esta arquitectura y no una solución más sencilla? Un motor de búsqueda clásico, unas reglas explícitas o un modelo pequeño y especializado pueden bastar. Cuando un agente es necesario, sus permisos deben estar limitados, sus acciones deben ser trazables y las operaciones sensibles deben someterse a validación. La autonomía no es una cualidad absoluta: es un nivel de riesgo que hay que justificar.
La inferencia: la factura después de los aplausos
El entrenamiento acapara la atención, pero la inferencia —la ejecución del modelo en cada uso— determina la economía cotidiana del servicio. Una demostración con unas pocas consultas no dice casi nada sobre el coste cuando llegan miles de usuarios a la vez. Con una API, las tarifas suelen depender de los volúmenes de texto procesados y generados. Con alojamiento propio, hay que pagar los aceleradores, la memoria, la operación y la capacidad reservada, incluso cuando esta queda parcialmente sin utilizar.
Por tanto, el coste relevante no es solo el del millón de tokens. Es el coste por tarea completada correctamente. Un modelo más barato que multiplique los intentos puede acabar saliendo más caro. Un agente que inicia varias búsquedas y verificaciones transforma una solicitud en una cadena de llamadas. Los enfoques que dedican más capacidad de cálculo al razonamiento acentúan esta disyuntiva: una posible respuesta mejor también se paga en tiempo y recursos.
- ¿Cuántas llamadas y tokens hacen falta para completar una tarea real?
- ¿Qué latencia se observa en las horas de mayor carga, especialmente entre los usuarios que reciben el peor servicio?
- ¿Qué proporción de los resultados requiere una corrección humana?
- ¿Cómo cambia el coste cuando el uso se duplica o los documentos se alargan?
El almacenamiento en caché, la agrupación de solicitudes y la asignación de tareas sencillas a modelos pequeños pueden reducir el gasto. La cuantización, que disminuye la precisión numérica de los parámetros, puede reducir las necesidades de memoria. Pero cada optimización exige una nueva evaluación: un ahorro técnico solo tiene valor si preserva la calidad que requiere la actividad.
La infraestructura no se limita a las GPU
Los aceleradores se han convertido en el símbolo de la competencia en IA. Sin embargo, disponer de GPU no basta. La memoria disponible, los intercambios entre máquinas, el almacenamiento y la capacidad de suministrar datos al modelo influyen en el rendimiento. Los contextos largos y las conversaciones simultáneas también consumen memoria durante la ejecución. Una infraestructura adecuada para una prueba aislada puede saturarse bajo una carga interactiva.
Hay que preguntar dónde están los márgenes: capacidad realmente disponible, plazos de ampliación, suministro eléctrico, refrigeración y continuidad del servicio. En un proyecto alojado por un proveedor, estas restricciones siguen presentes, aunque se transfieran a este. Los límites de procesamiento, los compromisos de disponibilidad y las opciones de conmutación por error pasan a formar parte del producto.
La soberanía también merece una definición precisa. Un centro de datos situado en Francia no resuelve por sí solo las cuestiones de jurisdicción, acceso administrativo o dependencia del software. ¿Por dónde pasan las solicitudes? ¿Quién conserva los registros? ¿Quién controla las claves de cifrado? ¿Se puede migrar a otro proveedor sin reconstruir toda la aplicación? Estas respuestas valen más que una etiqueta de «soberanía».
La fiabilidad se construye después de la demostración
Un servicio de IA evoluciona: los datos cambian, los usuarios encuentran usos imprevistos y una nueva versión del modelo modifica las respuestas. Por tanto, hay que prever una supervisión continua, pruebas de regresión y la posibilidad de volver a una versión anterior. Los documentos recuperados también pueden contener instrucciones maliciosas: la inyección de prompts resulta especialmente preocupante cuando el sistema dispone de herramientas o accesos sensibles.
En el contexto europeo, el Reglamento de IA aprobado en 2024 añade un marco cuya aplicación es progresiva. Las obligaciones dependen, entre otros factores, del papel de la organización y del uso en cuestión. Sin confundir el cumplimiento jurídico con la seguridad técnica, documentar los límites, los datos y la supervisión facilita ambos. A un proveedor hay que pedirle pruebas de ese trabajo, no solo una declaración de conformidad.
¿Y ahora qué? En septiembre de 2026, una prolongación plausible de estas tendencias sería una selección más pragmática de los proyectos: varios modelos en lugar de uno solo, una autonomía gradual y presupuestos calculados por resultado útil. No es una evolución garantizada. El RAISE Summit puede servir como punto de encuentro entre ambición y realidad, siempre que cada demostración vaya seguida de tres peticiones sencillas: muestren los errores, detallen el coste total y expliquen cómo funciona el sistema cuando aumenta la carga. Ahí es donde empieza la industrialización.
