IA Automatiza a Parte Fácil dos Design Systems, mas a Governança Continua Humana

Você já deve ter visto o post no LinkedIn: alguém monta um "design system↳Design system5 conteúdosComo desenvolvemos o novo Design System do AsaasProduto & UX · jul 2024UX e Código: Por que designers que conhecem programação têm uma vantagem estratégicaProduto & UX · abr 2025A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → completo" em 20 minutos com Claude, ou 15 com Gemini. A jornalista Anna Lefour, da UX Collective, confessa que caiu nessa isca: tentou reproduzir o feito e percebeu que estava confundindo um UI kit com um design system de verdade (o relato completo está aqui). A confusão não é dela só: é o erro mais comum de quem mede design system pela quantidade de componentes.

Depois de ouvir duas palestras na UXDX Berlin, em maio de 2026, Lefour entrevistou três pessoas que vivem esse problema todo dia: Marianne Ashton-Booth, Head of Product Design na ITV; David Sward, Chief Design Officer na Siemens; e Nicolas Chatelain, freelancer especializado em Design System e Design Ops. As três falas, lidas juntas, me convencem de uma coisa: a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → resolveu exatamente a parte que sempre foi a mais fácil de um design system, e deixou a parte difícil ainda mais exposta.

A parte fácil já foi automatizada, e isso nunca foi o problema

Nicolas Chatelain resume sem rodeios: a UI é a parte fácil de um design system. Qualquer pessoa, hoje, monta um kit de componentes com uma ferramenta de IA generativa.

A parte mais difícil, a que decide se um design system funciona ou não, é governança e adoção.

Nicolas Chatelain, freelancer especializado em Design System e Design OpsThe hardest part, the one that makes a DS work or not, is governance and adoption.

Marianne Ashton-Booth viu o mesmo padrão em outro contexto. Na ITV, quando um design system falha, segundo ela, quase nunca é por causa dos componentes: eles costumam estar bem. O que quebra são as camadas invisíveis por baixo, confiança, comunicação, priorização, relacionamento e crença compartilhada entre quem desenha e quem decide o roadmap.

Um dado sustenta essa leitura: o relatório da Zeroheight sobre o estado dos design systems, publicado no início de 2026, mostra que 59% dos profissionais atribuem a adoção do sistema à comunicação e à comunidade ao redor dele, não à qualidade técnica dos componentes. Nenhuma ferramenta de IA generativa mexe nesse número.

O gargalo não sumiu, só trocou de endereço

David Sward lidera o design system de uma companhia com centenas de produtos dependendo dele. Um erro ali custa, segundo ele, algumas centenas de milhões de euros para corrigir. Seu problema hoje é outro.

Meu maior problema é tentar desacelerar as pessoas com IA.

David Sward, Chief Design Officer na SiemensMy biggest problem is trying to slow people down with AI.

Isso não significa frear a adoção da IA em si: significa manter times dentro das regras de segurança e compliance de uma empresa grande, enquanto a velocidade de produção sobe. Em resumo: quando a IA tira o gargalo da produção, ele reaparece na revisão, na validação, em quem garante que tudo continua coerente. Nicolas Chatelain viu isso de um jeito mais radical: em um projeto para um grupo internacional, times de produto turbinados por IA passaram a produzir mais rápido que o time central de design system, cuja estratégia original era travar tudo.

Com IA, é um retrocesso total. Temos que ficar muito mais flexíveis, porque amanhã as pessoas vão conseguir criar um kit em cinco minutos. Se a gente se tornar inútil, elas vão achar um jeito ainda mais fácil de nos driblar.

Nicolas Chatelain, freelancer especializado em Design System e Design OpsWith AI, it's a total rollback. We have to become much more flexible, because tomorrow people could create a kit in five minutes. If we become useless, they'll find an even easier way to bypass us.

Uma saída técnica para isso são os slots do Figma, que deixam times colocarem conteúdo próprio dentro de um componente padronizado sem quebrar o padrão. Na ITV, a saída foi organizacional: "representantes de design system" em design e engenharia, pessoas com peso para tomar decisões finais sem travar o fluxo. Não existe uma resposta única, e isso já é um dado: o tipo de gargalo que aparece depende do risco da organização e de quanto a IA já foi aceita internamente, não de qual ferramenta de IA generativa foi escolhida.

Preparar o sistema para máquina não é resolver quem manda nele

A parte mais parecida com "futuro" do relato de Lefour já é presente: tornar o design system legível por máquina. O time de Nicolas Chatelain passou o segundo semestre de 2025 observando ferramentas como V0 e Lovable, concluiu que ainda era cedo para adotá-las, e decidiu preparar o sistema em vez de trocar de ferramenta: migrou os tokens para o padrão DTCG (Design Tokens Community Group), o formato compartilhado de cor, espaçamento e tipografia que permite que qualquer ferramenta, e qualquer agente de IA, leia os mesmos valores.

Um estudo de campo publicado em julho de 2026 por Kaelig Deloumeau-Prigent analisou 21 design systems open-source e encontrou um descompasso relevante:

• 20 dos 21 sistemas já oferecem um servidor MCP (Model Context Protocol), oficial ou mantido pela comunidade, que permite a um agente de IA consultar o design system diretamente em vez de adivinhar qual componente ou token usar;
• apenas 3 configuraram o Figma Code Connect, que liga um componente do Figma ao código real que o implementa.

Ou seja: muito mais sistemas deixam a IA lê-los do que sistemas que conseguem amarrar seus componentes de volta ao design. Isso é exatamente o oposto do que o discurso de "design system pronto para IA" costuma vender. Preparar o formato dos tokens é trabalho técnico necessário, mas não resolve quem decide o que entra no sistema, nem quem aceita o pull request que muda um componente usado em cinquenta produtos.

Código como fonte da verdade: a aposta que eu acho certa, com uma ressalva

Lefour chega a uma conclusão que eu assino: o código, não o arquivo de design, está virando a fonte da verdade dos design systems. Nicolas Chatelain é categórico sobre isso.

Hoje, a fonte da verdade tem que ser o código. Com certeza.

Nicolas Chatelain, freelancer especializado em Design System e Design OpsToday, the source of truth has to be the code. Absolutely.

Trabalhar a partir do código remove uma camada de abstração entre a IA e a produção. O argumento aparece também no artigo "Code as the Source of Truth", de Tony Ward, citado por Lefour: o ponto central não é tirar humano do processo, é manter "um especialista no assunto envolvido em cada etapa do caminho". David Sward concorda, e explica por quê isso importa na prática, não só em princípio.

Você não pode remover um humano do loop e depois esperar que ele volte a operar o sistema se não entender em que estado o sistema está.

David Sward, Chief Design Officer na SiemensYou can't remove a human from the loop and then expect them to step back in to operate the system if they don't understand the state the system is in.

Aqui está a ressalva que eu adiciono ao argumento de Lefour: código como fonte da verdade só funciona se a revisão de código virar, de fato, decisão de governança, e não checklist automatizado. Se ninguém com autoridade sobre o sistema entende o estado dele, trocar o arquivo de design pelo repositório não resolve nada, só muda onde o problema mora.

Onde eu discordo um pouco do otimismo do texto

O ponto mais fraco da conclusão de Lefour, na minha leitura, é tratar "preparar o sistema para IA" (tokens em DTCG, servidor MCP) como se isso já fosse parte da solução de governança. Não é. É pré-requisito técnico, necessário mas insuficiente: o mesmo estudo que mostra 20 de 21 sistemas com MCP mostra só 3 com Code Connect, e o relatório da Zeroheight mostra que adoção se explica por comunicação, não por infraestrutura de tokens.

Um agente de IA que lê seu design system perfeitamente ainda pode ser instruído, por um time apressado, a ignorar o componente certo e gerar um atalho "só dessa vez". O que impede isso não é o MCP: é exatamente a confiança, a priorização e a crença compartilhada que Marianne Ashton-Booth descreve como as camadas que quebram primeiro. Ela mesma fecha o argumento sem deixar margem para dúvida.

Pode ser que partes de um design system fiquem mais geradas ou automatizadas por IA. Mas um design system não é só essa parte, sabe, é também as pessoas e o processo. E essa é a parte que eu acho que a gente ainda vai manter.

Marianne Ashton-Booth, Head of Product Design na ITVThere might be parts of a design system that become more AI-generated or automated. But a design system isn't just that part, you know, it's the people and it's the process as well. And that's the bit that I think we'll still retain.

O que eu levaria para um design system aqui no Brasil

Se você mantém ou vai montar um design system agora, a pergunta que vale fazer não é "qual ferramenta de IA generativa usar nos componentes". É outra: quando o seu time duplicar a velocidade de produção de telas, quem vai revisar essa velocidade toda, e com que autoridade?

Algumas perguntas concretas para levar à próxima reunião de design system:

1. Nossos tokens já seguem um padrão legível por máquina (como DTCG), ou cada ferramenta interpreta cor e espaçamento do seu jeito?
2. Se expusermos um servidor MCP, quem garante que ele reflete o código em produção, e não um Figma desatualizado?
3. Quem tem autoridade para aceitar ou recusar um componente gerado por IA antes dele ir para produção, e essa pessoa está disponível na velocidade que o time pede?
4. O problema que trava a adoção hoje é falta de componente, ou falta de confiança em quem decide sobre eles?

A resposta da sua empresa para essas perguntas vai divergir da resposta da ITV, da Siemens ou do cliente de Nicolas Chatelain, porque cada contexto tem seu próprio nível de risco e sua própria maturidade com IA. Mas a pergunta em si não muda: a IA tirou a desculpa de que construir componentes é o trabalho difícil. O que sobra, governança, confiança, critério sobre o que entra na fonte da verdade, sempre foi, e continua sendo, trabalho de gente.

Fonte: UX Collective