Gestão de mudanças na ISO 9001:2026: a linha nova do requisito 6.3 que não dá para preencher depois

Pergunte a qualquer gestor da qualidade se ele costuma ser a última pessoa da empresa a saber que algo mudou. A resposta chega antes da pergunta terminar. Foi assim na live semanal da Templum sobre o requisito 6.3, conduzida por Daniela Albuquerque, sócia-diretora técnica da empresa: a plateia inteira confirmou no chat, e a partir daí a conversa deixou de ser sobre texto de norma e passou a ser sobre um risco concreto. Porque na revisão 2026 há uma linha nova no 6.3 — e ela é a única do requisito que não dá para preencher depois.

Por que o 6.3 existe: o intervalo entre o diagnóstico e a promessa

A revisão 2026 da ISO 9001 não trouxe grandes mudanças de texto — e é justamente isso que faz do 6.3 um problema maior do que parece. Nas principais mudanças da nova versão, o que se vê é consolidação: a alínea de mudanças climáticas incorporada ao corpo do requisito 4.1, um ajuste de redação nas partes interessadas, a exigência de que a alta direção promova cultura da qualidade e comportamento ético, a separação entre riscos e oportunidades na 6.1 e o 9.3.3 que deixa de falar em "saídas" para falar em "resultados" da análise crítica. Nada perto do salto que foi a revisão de 2015.

Antes de olhar a linha nova, vale entender de onde o requisito vem — porque isso explica por que ele é obrigatório e não opcional. Percorra o Planejar do PDCA na ordem em que a norma o escreve. A empresa decide adotar um sistema de gestão coerente com o seu direcionamento estratégico. Para saber que sistema é esse, olha para dentro e para fora: contexto, o que ela faz bem e pode potencializar, o que faz mal e precisa fortalecer. Olha para quem tem interesse naquele resultado e mapeia necessidades e expectativas. Fecha o escopo. Define os processos necessários para operar. Passa pela liderança e pela política da qualidade. Avalia o que pode dar errado no caminho e o que não faz hoje e poderia alavancar o negócio. Desdobra tudo em objetivos da qualidade.

No fim desse percurso, a empresa sabe duas coisas: onde está e onde precisa chegar. O intervalo entre as duas é a mudança. O 6.3 existe para planejar a travessia desse intervalo — ele é a saída do planejamento, não um capítulo à parte dele. É por isso que uma empresa que faz planejamento e não faz gestão de mudanças está, na prática, prometendo um destino sem organizar a viagem.

Lindo na teoria. Na prática, a área da qualidade raramente consegue acompanhar a mudança na velocidade em que ela acontece.

A dor que todo gestor reconhece — e por que a IA piora

O diagnóstico da live é desconfortável e honesto: não é que a qualidade seja a última a saber. É que, cada vez mais, ninguém sabe. Quanto mais a tecnologia avança, mais a informação se descentraliza — e mais barato fica testar e experimentar sem pedir licença para ninguém.

Quando o sistema de gestão vivia em papel sob a guarda do gestor da qualidade, o controle era involuntário e eficiente: para mudar um procedimento, alguém tinha que pedir o documento. Esse pedágio desapareceu. Hoje uma boa parte das decisões operacionais é tomada fora do ambiente gerenciado — inclusive dentro dos próprios motores de inteligência artificial, em rotinas que cada pessoa montou para si. Daniela deu o exemplo dela mesma: uma rotina própria de avaliação de notícias e cenário, construída fora da plataforma que a empresa usa, na qual ela toma decisões que parecem pequenas de dentro e são grandes quando vistas do contexto da empresa.

É aí que o requisito 6.3 deixa de ser tema de auditoria e passa a ser tema de arquitetura. A conclusão da live não é "recentralize o controle" — é o contrário. Chegou a hora de descentralizar a gestão de verdade e usar a gestão de mudanças como o mecanismo que faz isso sem perder o rastro: se cada gestor é ator da sua própria mudança, cada gestor também é responsável por registrá-la. Uma participante descreveu esse arranjo já funcionando na empresa dela — cada gestora responde pela mudança que impacta o sistema de gestão. É esse o destino.

O que a norma manda avaliar antes de mudar

Quando há uma mudança planejada que afeta o sistema de gestão, o 6.3 pede que quatro coisas sejam consideradas — todas antes de implementar:

• Propósito das mudanças e suas potenciais consequências. Por que estamos mudando, e o que essa mudança arrasta atrás de si.
• A integridade do sistema de gestão da qualidade. O que essas consequências fazem com o conjunto — é a pergunta que a auditoria devolve mais tarde, e é a que tem o preço mais alto.
• A disponibilidade de recursos. Existem pessoas, orçamento, competência e infraestrutura para sustentar o estado novo — não para chegar nele, para sustentá-lo.
• A alocação ou realocação de responsabilidades e autoridades. Quem responde pelo quê depois que a mudança acontecer.

Nada disso é novidade em relação à versão anterior, e é comum ver esses quatro itens preenchidos com desenvoltura. O problema é que a maioria das empresas os preenche depois.

A linha nova: comunicar antes de implementar

Aprovada a mudança, o texto em revisão acrescenta duas obrigações: comunicar a mudança e avaliar a sua eficácia.

Avaliar eficácia é terreno conhecido — já se faz para risco, para oportunidade, para não conformidade. A comunicação é que muda o jogo, e por um motivo que não tem nada de burocrático: ela é a única evidência do requisito que não pode ser produzida retroativamente.

Vale reconstruir o hábito que essa linha quebra, porque ele é quase universal. Faltam duas semanas para a auditoria. Você está repassando o plano com o time e, no meio da conversa, lembra: mudou o gestor daquele departamento, trocou aquela máquina, saiu a revisão daquele documento, o organograma não é mais aquele. Nada disso passou por gestão de mudanças. Então você abre o formulário, registra a mudança, avalia os impactos com honestidade — muitas vezes descobrindo ali um impacto que ninguém tinha verificado — e chega na auditoria com o registro em ordem. Não é fraude; é o sistema de gestão correndo atrás do prejuízo, e funcionava.

Com a comunicação exigida antes da implementação, esse conserto deixa de existir. Uma mudança que já aconteceu não tem como ter sido comunicada antes de acontecer, e é isso que torna a linha nova o calcanhar de Aquiles do requisito. Na leitura da live, esse detalhe de uma frase pesa mais, no dia a dia da operação, que cultura da qualidade, comportamento ético ou a separação de riscos e oportunidades.

Um esclarecimento que a plateia pediu e que evita o excesso oposto: comunicar não é comunicar a empresa toda. São os envolvidos — as pessoas afetadas pela mudança. Quem são elas é resultado da própria avaliação de propósito, consequências e risco; se essa avaliação foi feita direito, a lista de destinatários já está nela.

Por que isso ameaça a integridade do sistema de gestão

Uma mudança sem registro, isolada, é uma não conformidade menor — e o mundo segue. O risco aparece na repetição. Se o auditor encontra, ao longo da auditoria, várias mudanças que não foram avaliadas nem comunicadas, e nenhuma delas pode ganhar evidência de comunicação retroativa, a conclusão que ele tira não é sobre os casos: é sobre o conjunto. O que fica em questão é a integridade do sistema de gestão — o território da não conformidade maior.

Faz sentido que seja assim. Um sistema de gestão que não sabe o que mudou dentro de casa não está gerenciando nada; está descrevendo um passado. E o custo desse diagnóstico não é o retrabalho de um formulário — é o certificado.

É por isso que a saída não passa por disciplina. Continuar tratando gestão de mudanças como "abrir um formulário a cada mudança, manualmente" não escala num ambiente em que a informação se descentraliza todo mês. Não é falta de esforço do gestor da qualidade: é um processo desenhado para um volume de mudança que já não é o nosso.

Quer isso avaliado na sua empresa?

Receba um diagnóstico gratuito do seu sistema de gestão da qualidade e veja o que o auditor encontraria hoje.

Falar com a Olívia

Mudança intencional e mudança não intencional: 6.3, 8.1, 8.5.6 e 8.3.6

A norma fala de mudança em mais de um lugar, e confundi-los é a origem de metade da bagunça. São dois regimes distintos:

Mudança intencional (planejada) — requisito 6.3. É a que sai do planejamento: você sabe que vai mudar, avalia, aprova, comunica, executa. Vem do topo do PDCA e caminha na sequência descrita acima.

Mudança não intencional — requisitos 8.1 e 8.5.6. O 8.1 pede que a organização controle as mudanças planejadas e analise criticamente as consequências das não intencionais, tomando ação para mitigar efeitos adversos; o 8.5.6 complementa esse controle dentro da produção e provisão de serviço. É a mudança que ninguém planejou e que aconteceu: uma exigência regulatória nova, a saída repentina de uma pessoa-chave, uma ruptura de fornecimento que obriga a alterar a linha de produção, um evento climático. O exemplo que a live usou é o mais reconhecível: alerta da Defesa Civil, todo mundo em casa — e o prazo de entrega continua de pé.

A régua para identificar uma mudança não intencional é o 8.5. A norma pede que a operação aconteça sob condições controladas e lista quais controles isso exige: processo definido, procedimento, instrução de trabalho, recursos, pessoas competentes. Qualquer coisa que altere essas condições controladas durante a operação é uma mudança não intencional. E, na maior parte das vezes, ela é um gancho: a operação sai do padrão, faz o que precisa ser feito e volta ao ponto anterior.

Mudança em projeto e desenvolvimento — requisito 8.3.6. É o mais antigo e o mais bem resolvido dos três; quem trabalha com P&D já o endereça por hábito.

O ponto que importa: intencional e não intencional desembocam no mesmo tratamento. Avaliar propósito, consequências, recursos, responsáveis; comunicar; verificar eficácia. A única diferença é o momento da aprovação — uma você aprova antes de acontecer, a outra já aconteceu e você entra no ciclo a partir dali. Por isso vale separá-las explicitamente no sistema de gestão, com nomes diferentes: "mudanças planejadas" para as do 6.3 e "controle de mudanças" para as que nascem dentro da operação de cada processo. Sem essa separação, as duas competem pelo mesmo formulário e nenhuma das duas é bem tratada.

As nove etapas do fluxo de tratamento

O fluxo apresentado na live vale para os dois regimes. Duas etapas são novas na revisão 2026 — a sexta e a nona:

1. Identificar a mudança — planejada ou não.
2. Classificar o tipo — intencional ou não intencional. Determina o resto do caminho.
3. Avaliar propósito, consequências e riscos.
4. Definir recursos e responsáveis.
5. Planejar e aprovar — o que será executado a partir dessa mudança.
6. Comunicar os envolvidos — novo, e antes da execução. Note a posição: seis, não oito.
7. Executar a mudança.
8. Atualizar processos e documentos — a informação documentada afetada.
9. Verificar a eficácia — novo. A mudança entregou o que prometia?

É comum uma empresa com processo maduro chegar até a quinta ou a sétima etapa. As duas que sobram são as que a revisão acrescentou, e não é coincidência: são as duas que exigem que a mudança continue viva depois de implementada. O sintoma clássico de quem não as tem é o registro esquecido — a mudança foi anotada em algum lugar, ninguém voltou, e semanas depois, perto da auditoria, alguém descobre que as etapas nunca foram atualizadas. Isso acontece porque cada parte do fluxo vive num lugar diferente.

Como descentralizar sem perder o controle

Se o formulário manual não escala e a comunicação não pode ser retroativa, a única saída é fazer a mudança nascer registrada — no ponto e no momento em que ela acontece, por quem a faz. Quatro decisões de desenho sustentam isso, e nenhuma delas depende de qual ferramenta a empresa usa:

1. Defina a lista de itens que disparam o fluxo. Não é "toda mudança" — é uma lista nominal e revisável do que, ao ser alterado, entra em gestão de mudanças: procedimento, organograma, departamento, escopo, descrição de cargo, indicador, matriz de partes interessadas, instrução de trabalho. E vale incluir itens que não parecem ser da qualidade: se uma alteração no plano de contas do financeiro afeta como um processo é medido, o gestor da qualidade precisa saber — não para opinar sobre finanças, para avaliar o impacto no sistema.

2. Nomeie o papel autorizador e dê a ele um prazo. Alguém precisa avaliar a mudança e dizer o que tem de ser feito por causa dela, dentro de um número definido de dias. Sem prazo, a fila vira arquivo.

3. Escreva a regra de comunicação antes de precisar dela. Para cada tipo de mudança: quem recebe (solicitante, autorizador, gestor do processo, colaboradores do departamento afetado, quem ocupa determinado cargo) e por qual canal. Regra definida uma vez é o que transforma comunicação em evidência automática, em vez de um e-mail que alguém lembrou de mandar.

4. Faça o registro nascer no ponto da mudança. A pessoa que altera o documento é a que descreve propósito, consequências potenciais, impacto na integridade do sistema, recursos, responsabilidades e grau de risco — no ato de alterar, não num formulário separado que ela abriria depois. É essa inversão que torna o registro possível em escala: o custo de registrar passa a ser pago por quem muda, no momento em que muda, e não pela qualidade, semanas depois, tentando reconstruir o que aconteceu.

O ganho colateral é grande: com as mudanças registradas e datadas ao longo do período, a análise crítica pela direção chega com a pauta de mudanças pronta, em vez de começar por uma arqueologia de e-mails.

O que fazer antes da norma ser publicada

A ISO 9001:2026 ainda não foi publicada — a discussão trabalha com o texto em revisão, e a publicação oficial é esperada para setembro. Isso dá uma janela curta, e o que cabe nela é o seguinte:

• separe, no seu sistema de gestão, mudança planejada (6.3) de controle de mudanças na operação (8.1 e 8.5.6) — com fluxos e nomes distintos;
• escreva a lista nominal de itens cuja alteração dispara gestão de mudanças, e submeta essa lista aos gestores de processo, não só à qualidade;
• acrescente ao seu fluxo as duas etapas novas: comunicação antes da execução e verificação de eficácia depois;
• defina, por tipo de mudança, quem é comunicado e por qual canal — e deixe a regra escrita, para que a evidência seja um subproduto do processo;
• faça um teste honesto de estoque: liste as mudanças dos últimos três meses que passaram por fora do fluxo. O tamanho dessa lista é a medida do seu risco;
• e desloque a responsabilidade pelo registro para quem executa a mudança. Enquanto ela morar na qualidade, o registro vai continuar chegando depois do fato.

A régua para saber se você está pronto é uma pergunta só: se o auditor escolher três mudanças que aconteceram no último trimestre, você consegue mostrar que cada uma foi avaliada e comunicada antes de ser implementada? Enquanto a resposta for não, o requisito 6.3 está sendo cumprido para trás — e essa é exatamente a folga que a revisão 2026 fecha. Para o texto do requisito em si, vale complementar com o requisito 6.3 item por item.