Design Systems que documentam a IA: quatro princípios emergem entre os líderes

O que está emergindo não é um novo módulo de design system, mas uma reescrita silenciosa da sua lógica central. Design systems tradicionais documentam componentes para humanos, com tokens, exemplos e princípios visuais. Agora, os líderes como IBM (Carbon para IA), AWS e Microsoft estão integrando IA como um 'co-autor' do sistema: não só como ferramenta, mas como parte ativa da interface, da explicação e até da falha. O rótulo visual de conteúdo gerado por IA na Carbon não é um adesivo estético; é um contrato de confiança explícito com o usuário, feito com gradientes sutis e micro-interações que evitam a sensação de 'caixa preta'. Já a camada de explicabilidade não é um modal secundário, é um componente interativo, acionável em três níveis (resumo, justificativa técnica, fonte de dados), alinhado ao que o CEVIU já apontou em maio: o design precisa falar tanto com quem entende de modelos quanto com quem só quer saber se pode confiar.

Essa virada também explica por que o artigo de 2 de junho sobre fluxos de trabalho com IA, onde equipes testam código antes do design ou prototipam antes de escrever, ganha nova luz: esses processos só escalam quando o design system já incorpora regras para IA desde a raiz. Sem isso, cada time vira seu próprio 'mini-sistema', repetindo erros de sinalização, controle e recuperação. E o alerta de 29 de maio sobre 'activation cliffs' em produtos de IA agora faz sentido como consequência direta da ausência desses quatro princípios: sem sinalizar, sem explicar, sem controle humano e sem plano B, o primeiro erro da IA vira o último acesso do usuário.

Em 28 de maio, o CEVIU questionava se devíamos projetar para humanos ou máquinas, um dilema teórico. Em 4 de junho, a convergência entre IBM, AWS, GitLab e Microsoft transformou essa pergunta em prática: projetar para ambos é obrigatório, e o design system virou o ponto de mediação. Antes, a documentação de IA era esporádica (como no caso do SAP Fiori citado nas buscas) ou limitada a prompts isolados. Agora, há padrões compartilhados de sinalização visual, estrutura de explicabilidade em camadas e protocolos de fallback, algo inexistente na cobertura anterior. Também houve mudança de foco: o artigo de 2 de junho tratava IA como acelerador de tarefas; este mostra que ela exige novos contratos de uso, novos componentes de interface e novos critérios de qualidade, como a 'degradação graciosa', conceito ausente nas análises anteriores.

Porque 75% dos designers já usam IA diariamente, mas 62% reclamam da saída inconsistente, e isso não é problema técnico, é falha de design. Um sistema que não sinaliza, não explica e não permite correção eficiente transforma cada interação com IA em um ato de fé. Isso alimenta a 'lacuna de confiança' descrita em 29 de maio e explica por que 91% dos designers usam IA, mas poucos conseguem levar seus produtos ao estágio de adoção contínua. Projetar para falhas não é pessimismo: é reconhecer que a IA opera em probabilidades, e o papel do designer é construir pontes entre a incerteza do modelo e a necessidade humana de previsibilidade. Quando o design system não documenta isso, o ônus cai inteiro sobre o usuário, e sobre o time de produto, que herda bugs de experiência que parecem técnicos, mas são de comunicação.