Apresentação da Arquitetura Quantum Core na DevConf 2026

Sistemas de IA são particularmente eficazes a produzir primeiras impressões. Uma geração bem escolhida, uma conversa fluida ou um asset criado em segundos demonstram potencial de forma imediata. O trabalho de engenharia começa quando essa capacidade precisa de ser repetida por dezenas de pessoas, integrada em ferramentas existentes, auditada, versionada e executada novamente semanas depois sem depender da memória de quem montou a demonstração.

É esse segundo problema que a arquitetura Quantum Core procura colocar no centro da apresentação. Em produção, valor não vem apenas da qualidade máxima de uma saída. Vem da relação entre qualidade, tempo, custo, previsibilidade e capacidade de intervenção. Um modelo excelente que não consegue respeitar identidade visual, rastrear fontes, reproduzir uma decisão ou encaixar num pipeline de aprovação pode ser menos útil do que um sistema tecnicamente mais modesto, mas controlável.

A sessão é, portanto, uma discussão sobre sistemas. Modelos continuam importantes, mas deixam de ser a arquitetura inteira. Entram em cena filas de trabalho, armazenamento de contexto, regras de aprovação, versionamento, observabilidade, políticas de segurança, métricas de qualidade e interfaces suficientemente simples para que artistas e designers não precisem de compreender toda a infraestrutura subjacente.

O princípio central é desacoplar o pedido criativo do fornecedor ou modelo específico. Um utilizador descreve uma tarefa — rever uma localização, gerar uma variante, analisar um asset, produzir uma sugestão de código — e o sistema transforma essa intenção num job estruturado. O job inclui contexto, assets autorizados, parâmetros, versão do workflow e critérios de saída. Só então uma política de routing decide que ferramenta ou modelo deve executar cada etapa.

Essa separação reduz dependência tecnológica. Modelos podem mudar rapidamente; pipelines de estúdio não deveriam precisar de ser redesenhados a cada lançamento. Se a interface entre produção e inferência for estável, um componente pode ser substituído, comparado ou executado em hardware diferente sem alterar a forma como a equipa trabalha.

Também permite combinar abordagens. Uma única tarefa pode usar visão para classificar um asset, um modelo de linguagem para estruturar recomendações e ferramentas determinísticas para validar dimensões, naming ou formatos. Chamar tudo isto simplesmente de 'IA' esconde o ponto mais importante: cada componente tem garantias, custos e modos de falha diferentes.

À medida que conteúdo assistido por IA entra em produção, a equipa precisa de conseguir responder a perguntas básicas: que ficheiros foram usados como referência, que modelo produziu a versão atual, que prompt ou configuração foi aplicado, quem aprovou o resultado e que alterações manuais aconteceram depois. Sem essa cadeia, o conteúdo torna-se difícil de reproduzir e ainda mais difícil de auditar.

A arquitetura proposta trata proveniência como metadata de primeira classe. Um output não é apenas uma imagem, texto ou clip; é um artefacto acompanhado por uma história mínima de produção. Essa história pode permanecer ligada ao sistema mesmo quando o ficheiro final é exportado para Unity, Unreal, um DCC ou outro repositório interno.

A utilidade não é apenas jurídica ou administrativa. Proveniência melhora engenharia. Quando uma regressão aparece, é possível comparar workflows. Quando um resultado é particularmente bom, a equipa sabe que configuração o produziu. E quando um modelo precisa de ser descontinuado, torna-se viável identificar que assets dependem dele.

Dizer que existe supervisão humana é fácil. O desafio é definir onde ela acontece. Nem todas as tarefas precisam da mesma aprovação. Uma sugestão de naming pode ser aplicada automaticamente; uma alteração de diálogo principal pode exigir um escritor; uma modificação de rosto pode exigir direção de arte; uma mudança em código pode precisar de review e testes antes de entrar no branch principal.

Por isso, o workflow deve carregar níveis de risco e gates explícitos. O sistema pode permitir execução automática em tarefas reversíveis e de baixo impacto, pedir aprovação em transformações visuais importantes e bloquear operações que ultrapassem permissões. Essa política deve ser configurável por projeto, porque o mesmo modelo pode ser adequado para prototipagem e inaceitável para um asset final.

O objetivo não é criar burocracia digital. É tornar visível onde uma decisão humana é parte da definição de qualidade. Quando isso está codificado, a equipa consegue aumentar automação sem perder responsabilidade.

Modelos mudam, drivers mudam, dependências mudam e prompts são ajustados. Em sistemas não determinísticos, uma alteração pequena pode melhorar um conjunto de casos e degradar outro. Sem datasets de referência e métricas repetíveis, a organização descobre regressões apenas quando um artista percebe que 'as coisas estão diferentes'.

A proposta da Quantum Core é tratar avaliação como parte do deployment. Workflows relevantes mantêm exemplos de referência, limites de aceitação e comparações entre versões. Para tarefas visuais, isso pode envolver métricas de estrutura, qualidade e consistência combinadas com revisão humana. Para texto, pode incluir terminologia, formato, aderência a instruções e testes de casos adversariais. Para código, compilação, testes e análise estática continuam a ter precedência sobre qualquer avaliação subjetiva do modelo.

Nenhuma métrica isolada define qualidade artística ou editorial. O papel do sistema é detectar mudanças, tornar desvios visíveis e reduzir a quantidade de trabalho que precisa de ser revisto às cegas. A decisão final continua ligada ao propósito do asset.

Estúdios possuem anos de investimento em version control, DCCs, engines, naming, scripts, processos de aprovação e ferramentas internas. Uma arquitetura que exige substituir tudo para adotar IA cria risco desnecessário. A estratégia apresentada privilegia módulos que entram nos pontos onde existe benefício mensurável e devolvem resultados aos sistemas que a equipa já utiliza.

Isto significa trabalhar com adaptadores e contratos claros. Um módulo pode receber assets de uma pasta monitorizada, de uma API ou de uma extensão do DCC; outro pode enviar resultados para uma review queue; um terceiro pode apenas produzir métricas. A adoção deixa de ser uma migração única e torna-se uma sequência de integrações pequenas que podem ser avaliadas separadamente.

Essa abordagem é especialmente importante numa área em que a tecnologia se move mais depressa do que ciclos de produção de jogos. Infraestrutura precisa de sobreviver a modelos. Caso contrário, cada melhoria tecnológica reinicia a curva de integração.

Mais do que apresentar uma lista de funcionalidades, a sessão pretende discutir escolhas arquiteturais que continuam abertas para toda a indústria: quando inferência local justifica o custo de hardware; como equilibrar privacidade e observabilidade; que dados devem ser guardados para reproduzir uma geração; como comparar modelos sem transformar benchmarks em objetivos artificiais; e até que ponto automação pode ser introduzida sem empobrecer autoria.

Há também uma questão organizacional. IA atravessa disciplinas que historicamente trabalharam com ferramentas e métricas diferentes. Arte, narrativa, localização, engenharia e produção precisam de uma linguagem comum para falar de qualidade, risco e aprovação. Uma plataforma de orquestração só é útil se tornar essa comunicação mais clara, não se adicionar mais uma camada opaca entre equipas.

É nesse ponto que uma conferência técnica oferece maior valor: não como palco para afirmar que os problemas estão resolvidos, mas como ambiente para confrontar decisões de implementação com equipas que enfrentam restrições diferentes. A maturidade de uma arquitetura é medida também pela qualidade das perguntas que ela consegue suportar.