Presentación de la Arquitectura Quantum Core en DevConf 2026

Los sistemas de IA son especialmente eficaces produciendo primeras impresiones. Una generación bien elegida, una conversación fluida o un asset creado en segundos demuestran potencial de forma inmediata. El trabajo de ingeniería empieza cuando esa capacidad debe repetirse por decenas de personas, integrarse en herramientas existentes, auditarse, versionarse y ejecutarse de nuevo semanas después sin depender de la memoria de quien montó la demostración.

Ese segundo problema es el que la arquitectura Quantum Core pretende situar en el centro de la presentación. En producción, el valor no procede únicamente de la calidad máxima de un output. Procede de la relación entre calidad, tiempo, coste, predictibilidad y capacidad de intervención. Un modelo excelente que no puede respetar identidad visual, rastrear fuentes, reproducir una decisión o encajar en un pipeline de aprobación puede ser menos útil que un sistema técnicamente más modesto, pero controlable.

La sesión es, por tanto, una conversación sobre sistemas. Los modelos siguen siendo importantes, pero dejan de ser toda la arquitectura. Entran en escena colas de trabajo, almacenamiento de contexto, reglas de aprobación, versionado, observabilidad, políticas de seguridad, métricas de calidad e interfaces suficientemente sencillas para que artistas y diseñadores no necesiten comprender toda la infraestructura subyacente.

El principio central es desacoplar la petición creativa de un proveedor o modelo concreto. Un usuario describe una tarea —revisar una localización, generar una variante, analizar un asset, producir una sugerencia de código— y el sistema transforma esa intención en un job estructurado. El job incluye contexto, assets autorizados, parámetros, versión del workflow y criterios de salida. Solo entonces una política de routing decide qué herramienta o modelo debe ejecutar cada etapa.

Esa separación reduce la dependencia tecnológica. Los modelos pueden cambiar rápidamente; los pipelines de estudio no deberían tener que rediseñarse con cada lanzamiento. Si la interfaz entre producción e inferencia permanece estable, un componente puede sustituirse, compararse o ejecutarse en hardware distinto sin cambiar la forma en que trabaja el equipo.

También permite combinar enfoques. Una sola tarea puede utilizar visión para clasificar un asset, un modelo de lenguaje para estructurar recomendaciones y herramientas deterministas para validar dimensiones, naming o formatos. Llamar a todo esto simplemente 'IA' oculta el punto más importante: cada componente tiene garantías, costes y modos de fallo distintos.

A medida que el contenido asistido por IA entra en producción, el equipo necesita responder preguntas básicas: qué archivos se usaron como referencia, qué modelo produjo la versión actual, qué prompt o configuración se aplicó, quién aprobó el resultado y qué cambios manuales ocurrieron después. Sin esa cadena, el contenido se vuelve difícil de reproducir y todavía más difícil de auditar.

La arquitectura propuesta trata la procedencia como metadata de primera clase. Un output no es únicamente una imagen, texto o clip; es un artefacto acompañado por una historia mínima de producción. Esa historia puede permanecer vinculada al sistema incluso cuando el archivo final se exporta a Unity, Unreal, un DCC u otro repositorio interno.

La utilidad no es únicamente jurídica o administrativa. La procedencia mejora la ingeniería. Cuando aparece una regresión, es posible comparar workflows. Cuando un resultado es especialmente bueno, el equipo sabe qué configuración lo produjo. Y cuando un modelo debe retirarse, resulta viable identificar qué assets dependen de él.

Decir que existe supervisión humana es sencillo. El reto consiste en definir dónde ocurre. No todas las tareas necesitan la misma aprobación. Una sugerencia de naming puede aplicarse automáticamente; un cambio en diálogo principal puede requerir un guionista; una modificación facial puede exigir dirección de arte; un cambio de código puede necesitar review y pruebas antes de entrar en la rama principal.

Por eso, el workflow debe incluir niveles de riesgo y gates explícitos. El sistema puede permitir ejecución automática en tareas reversibles y de bajo impacto, pedir aprobación en transformaciones visuales importantes y bloquear operaciones que excedan permisos. Esa política debería configurarse por proyecto, porque el mismo modelo puede ser adecuado para prototipado e inaceptable para un asset final.

El objetivo no es crear burocracia digital. Es hacer visible dónde una decisión humana forma parte de la definición de calidad. Cuando eso queda codificado, el equipo puede aumentar la automatización sin perder responsabilidad.

Los modelos cambian, los drivers cambian, las dependencias cambian y los prompts se ajustan. En sistemas no deterministas, una modificación pequeña puede mejorar un conjunto de casos y degradar otro. Sin datasets de referencia y métricas repetibles, la organización descubre regresiones únicamente cuando un artista percibe que 'las cosas se sienten diferentes'.

La propuesta de Quantum Core es tratar la evaluación como parte del deployment. Los workflows relevantes mantienen ejemplos de referencia, límites de aceptación y comparaciones entre versiones. Para tareas visuales, eso puede implicar métricas de estructura, calidad y consistencia combinadas con revisión humana. Para texto, puede incluir terminología, formato, cumplimiento de instrucciones y casos adversariales. Para código, compilación, pruebas y análisis estático siguen teniendo prioridad sobre cualquier valoración subjetiva del modelo.

Ninguna métrica aislada define calidad artística o editorial. El papel del sistema es detectar cambios, hacer visibles las desviaciones y reducir la cantidad de trabajo que debe revisarse a ciegas. La decisión final sigue vinculada al propósito del asset.

Los estudios acumulan años de inversión en version control, DCCs, engines, naming, scripts, procesos de aprobación y herramientas internas. Una arquitectura que exige sustituir todo para adoptar IA crea un riesgo innecesario. La estrategia presentada prioriza módulos que entran en puntos donde existe un beneficio medible y devuelven resultados a los sistemas que el equipo ya utiliza.

Eso implica trabajar con adaptadores y contratos claros. Un módulo puede recibir assets de una carpeta monitorizada, una API o una extensión del DCC; otro puede enviar resultados a una review queue; un tercero puede limitarse a producir métricas. La adopción deja de ser una migración única y se convierte en una secuencia de integraciones pequeñas que pueden evaluarse de forma independiente.

Este enfoque es especialmente importante en un área donde la tecnología avanza más rápido que los ciclos de producción de videojuegos. La infraestructura debe sobrevivir a los modelos. De lo contrario, cada mejora tecnológica reinicia la curva de integración.

Más que presentar una lista de funcionalidades, la sesión pretende discutir decisiones arquitectónicas que siguen abiertas para toda la industria: cuándo la inferencia local justifica el coste de hardware; cómo equilibrar privacidad y observabilidad; qué datos deben conservarse para reproducir una generación; cómo comparar modelos sin convertir benchmarks en objetivos artificiales; y hasta qué punto puede introducirse automatización sin empobrecer la autoría.

También existe una cuestión organizativa. La IA atraviesa disciplinas que históricamente han trabajado con herramientas y métricas diferentes. Arte, narrativa, localización, ingeniería y producción necesitan un lenguaje común para hablar de calidad, riesgo y aprobación. Una plataforma de orquestación solo es útil si hace esa comunicación más clara, no si añade otra capa opaca entre equipos.

Es en ese punto donde una conferencia técnica ofrece mayor valor: no como escenario para afirmar que los problemas están resueltos, sino como entorno para confrontar decisiones de implementación con equipos que trabajan bajo restricciones diferentes. La madurez de una arquitectura también se mide por la calidad de las preguntas que puede sostener.