Implantar IA em um processo: como desenhar o piloto e parar

Implantar IA em um processo significa limitar o piloto a um fluxo de trabalho específico, com um grupo pequeno de pessoas, por um período fechado, com um número medido antes de começar. O desenho mínimo tem seis elementos: o processo escolhido, o grupo que executa (de três a oito pessoas costuma bastar), o número de antes, a regra de revisão, a data de encerramento e os critérios de parada. Sem os dois últimos, o piloto não termina — ele apenas perde a atenção e vira um recurso ligado que ninguém avalia. E piloto que não termina não gera decisão: gera custo recorrente sem dono.

A tentação de fazer diferente é forte, e ela tem um nome: medo de parecer tímido. Ligar IA para a empresa inteira parece ambicioso e é operacionalmente mais simples — basta um clique de administrador. O problema aparece quando chega a hora de responder se funcionou. E existe um segundo problema, menos óbvio e mais caro, que este texto trata em detalhe: o desenho do piloto muda o enquadramento regulatório da sua empresa, e isso está escrito em norma brasileira em vigor.

Este artigo traz o método com as fontes que sustentam cada etapa, separando com rigor o que já obriga a sua empresa no Brasil do que é apenas referência estrangeira ou voluntária. Declaro o interesse comercial: a Audatia é revenda oficial do ClickUp no Brasil e presta consultoria, treinamento e sustentação em monday.com — as duas plataformas aparecem aqui apenas onde a mecânica de cobrança de IA delas é relevante para o critério de custo.

Qual é o tamanho certo do piloto

Pequeno o bastante para você conseguir conversar individualmente com todo mundo que participou. Na prática, isso é um grupo de três a oito pessoas, um processo, e de seis a dez semanas.

O grupo não deve ser formado só por entusiastas. Um piloto composto apenas de gente animada com IA gera um resultado que não se repete quando o recurso chega à equipe inteira. Inclua pelo menos uma pessoa cética e competente — ela vai encontrar em duas semanas o que o resto do time encontraria em seis meses.

Há também um argumento de método a favor do escopo pequeno, e ele vem do framework de gestão de risco de IA do NIST, o instituto de padrões dos Estados Unidos: as métricas devem ser escolhidas começando pelos riscos mais significativos, e aquilo que não será ou não pode ser medido precisa ser documentado. Traduzindo para quem tem pouco tempo: você não precisa medir tudo. Precisa medir o que mais importa e escrever o que decidiu não medir.

Como implantar IA em um processo: o ciclo em quatro movimentos

Vale entender o mecanismo antes das etapas, porque ele explica por que a ordem importa. O framework do NIST organiza gestão de risco de IA em quatro funções, e elas traduzem bem para linguagem de operação.

Repare no padrão: as duas funções que as empresas pulam com mais frequência são a primeira e a terceira — justamente as que não produzem nada visível. Ligar a ferramenta é a parte fácil e é a única que aparece na reunião. Duas ressalvas de rigor sobre esta seção: o framework do NIST é voluntário e estrangeiro, não obriga ninguém no Brasil, e o próprio documento avisa que as ações dele não constituem uma lista de verificação nem uma sequência obrigatória de passos. Uso como referência de método, não como norma.

O que medir antes de ligar qualquer coisa

O número de antes. É a etapa mais chata e a única insubstituível: depois que o recurso está ligado, ninguém consegue reconstruir com honestidade quanto tempo o processo levava.

O NIST é direto nesse ponto e vale a citação: sistemas de IA devem ser testados antes de sua implantação e regularmente durante a operação. E vai além, reconhecendo o caso específico deste artigo — quando a IA vai aumentar ou substituir atividade humana, é preciso alguma forma de métrica de linha de base humana para comparação. O mesmo trecho admite, com honestidade, que sistematizar isso é difícil, porque a IA executa tarefas diferentes e de formas diferentes das humanas. Ou seja: a comparação nunca é perfeita. Mas nenhuma comparação é pior que uma comparação imperfeita.

Três medições costumam bastar, e todas podem ser feitas de forma tosca sem prejuízo.

• Tempo de ciclo: pegue as últimas 20 execuções do processo e some quanto tempo cada uma levou do gatilho à entrega. Se não houver registro, cronometre as próximas 10.
• Retrabalho: dessas execuções, quantas voltaram para correção, e quantas vezes.
• Volume: quantas execuções por semana. Serve para saber se a amostra do piloto é grande o suficiente para significar algo.

Colete a linha de base a partir dos registros que já existem, antes de anunciar o piloto. O passado não sabia que ia ser medido — e essa é a única amostra que você tem imune ao efeito de estar sendo observado.

Se você não consegue medir nenhuma das três, o problema apareceu antes da IA: o processo não é rastreável. Nesse caso o piloto muda de objeto — ele passa a ser fazer o processo virar rastreável, e a IA fica para depois. Esse é o quarto passo do Método Núcleo→Escala, e ele não é opcional.

Há ainda um motivo jurídico para medir, e ele costuma surpreender. A LGPD lista, entre seus princípios, a responsabilização e prestação de contas — definida na lei como a demonstração, pelo agente, da adoção de medidas eficazes e capazes de comprovar o cumprimento das normas de proteção de dados, inclusive da eficácia dessas medidas. Sem linha de base, não existe como demonstrar eficácia de coisa nenhuma.

Por que o número do depois costuma mentir

Um processo que passou dez semanas sendo observado melhora sozinho, porque as pessoas prestam atenção nele. Existe um nome para isso na literatura de gestão — efeito Hawthorne —, e eu prefiro não fingir que sei o tamanho dele no seu caso: a interpretação clássica dos experimentos originais foi contestada por reanálises dos próprios dados, e não há número confiável para aplicar.

O que dá para afirmar com segurança é mais simples e não precisa de literatura: no piloto, a equipe sabe que está sendo medida. A pessoa que opera aquele processo sabe que aquele mês é “o mês da IA”. Logo, o número do depois carrega atenção, novidade e esforço extra somados ao efeito da ferramenta. Isso não é uma teoria psicológica — é uma variável que você não controlou.

O NIST descreve o mesmo risco de outro ângulo, e essa formulação é citável: abordagens de medição podem ser simplificadas demais, manipuladas, carecer de nuance crítica ou passar a ser usadas de formas inesperadas. Quatro antídotos de desenho resolvem a maior parte disso:

• Extrair a linha de base retroativamente, dos registros que já existem, antes de anunciar o piloto.
• Manter uma faixa comparável do mesmo processo fora do piloto, no mesmo período, medida do mesmo jeito.
• Preferir métricas difíceis de inflar — retrabalho, erro detectado depois, prazo real — a métricas autorreportadas como “senti que economizei tempo”.
• Ler o número na semana 6, não na semana 2, quando o entusiasmo já passou.

Quem participa e quem decide

Três papéis, e eles não podem ser a mesma pessoa em empresa acima de vinte pessoas.

• Quem executa — o grupo do piloto. Usa e reporta.
• Quem responde pelo processo — o dono da área. Decide se a saída da IA é aceitável e o que fazer quando não é.
• Quem administra — quem liga, desliga, define permissão e olha consumo. Em quase toda empresa, é a mesma pessoa que administra as licenças.

O papel que costuma ficar vago é o segundo. Sem alguém que responda “isso aqui está bom o suficiente para sair da empresa?”, cada pessoa do piloto aplica um critério diferente, e o resultado agregado não significa nada. O NIST toca nesse ponto ao exigir que abordagens, pessoal e documentação estejam definidos para identificar e acompanhar riscos — o detalhe que interessa é a palavra “pessoal”: monitorar exige alguém nomeado, não só um painel.

A regra de revisão — e o que a lei brasileira realmente exige

Antes de ligar, escreva uma frase por tipo de saída: o que pode sair sem conferência, o que precisa de conferência de quem executa, e o que precisa de aprovação de quem responde pela área.

Essa tabela é o coração do piloto. E aqui existe uma precisão jurídica que muda o jeito de escrevê-la, porque circula bastante informação errada a respeito.

A LGPD garante revisão de decisão automatizada, mas não determina que o revisor seja humano. O art. 20 diz que o titular tem direito a solicitar a revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais que afetem seus interesses — incluídas as decisões destinadas a definir perfil pessoal, profissional, de consumo e de crédito. A redação original previa revisão “por pessoa natural”; essa expressão saiu do texto, e o parágrafo que o Congresso reinseriu para restaurá-la foi vetado. Dentro do art. 20, a palavra “humano” não aparece — e, mais que isso, não há requisito nenhum sobre quem revisa, como revisa ou em quanto tempo.

Duas consequências práticas. A primeira: se você quer revisão humana no seu processo, quem garante isso é a sua regra escrita, não a lei. A segunda, que é o contrapeso: a lei não dispensa nada. O caput exige a revisão, e o § 1º impõe ao controlador o dever de fornecer, sempre que solicitadas, informações claras e adequadas sobre os critérios e procedimentos usados na decisão automatizada, observados os segredos comercial e industrial. E o § 2º dá à autoridade nacional o poder de auditar aspectos discriminatórios quando a empresa se recusa a explicar invocando segredo comercial.

A palavra que aciona tudo isso é “unicamente”. Se existe decisão humana efetiva no fluxo, o gatilho do art. 20 não se aciona — e é por isso que a sua tabela de revisão é, ao mesmo tempo, desenho de processo e desenho de exposição.

Uma ressalva honesta sobre essa leitura: se uma revisão humana meramente formal, de carimbo, descaracteriza o “unicamente” é discutido em doutrina, e eu não localizei decisão da autoridade nem jurisprudência consolidada sobre o ponto. Trate como leitura do texto legal e boa prática de risco, não como questão pacificada. O antídoto prático é medível dentro do próprio piloto: se o revisor nunca discorda da IA, a revisão provavelmente não está acontecendo. Acompanhe a taxa de discordância como métrica.

E vale o alerta de escopo: se o seu piloto for em crédito, cobrança ou seguros, existe camada regulatória adicional que este artigo não cobre. Só como exemplo do que muda, a lei do cadastro positivo garante ao cadastrado o direito de solicitar ao consulente a revisão de decisão realizada exclusivamente por meios automatizados — e o dever recai sobre a empresa que consultou e decidiu.

O desenho do piloto muda o enquadramento regulatório

Esta é a parte que eu não vejo escrita em lugar nenhum e que, para empresa de pequeno porte, é o argumento mais concreto a favor do piloto pequeno.

A resolução da autoridade nacional que criou o regime simplificado para agentes de tratamento de pequeno porte define quando um tratamento é de alto risco: quando ele atende, cumulativamente, a pelo menos um critério geral e um critério específico. Entre os gerais estão o tratamento em larga escala e o que possa afetar significativamente interesses e direitos fundamentais dos titulares. Entre os específicos estão o uso de tecnologias emergentes ou inovadoras e as decisões tomadas unicamente com base em tratamento automatizado.

E a mesma resolução determina que não podem se beneficiar do tratamento jurídico diferenciado os agentes de pequeno porte que realizem tratamento de alto risco.

A leitura prática é que o piloto pequeno com humano no fluxo não é só mais fácil de avaliar — ele é mais barato do ponto de vista de obrigação. Perder o regime simplificado significa perder as flexibilizações que ele concede, como a dispensa de indicar encarregado e o registro simplificado das operações. Duas ressalvas: essa é a leitura do texto da resolução aplicada ao caso típico, e o enquadramento concreto depende dos seus dados; e a mesma resolução diz expressamente que a flexibilização não isenta o agente de pequeno porte do cumprimento dos demais dispositivos da LGPD, incluindo princípios, bases legais e direitos dos titulares.

Quais são os critérios de parada

Escritos antes de começar, e em papel — não porque alguém vá auditar, mas porque no meio do piloto todo mundo fica com apego ao projeto. O NIST recomenda exatamente isso, e com um detalhe que vale copiar: definir os limites aceitáveis de desempenho e já incluir as ações de correção de rumo para quando o sistema operar fora deles. Limite e consequência são escritos juntos, e antes.

Três bastam.

1. Parada por dano. Se uma saída errada chegar ao cliente sem passar por revisão, o piloto para no mesmo dia e a regra de revisão é reescrita antes de religar.
2. Parada por abandono. Se, na quarta semana, menos da metade das execuções estiver passando pelo caminho novo sem alguém cobrar, para. O caminho novo não está mais fácil que o antigo, e nenhum treinamento resolve isso.
3. Parada por custo. Se o consumo projetado para a equipe inteira ultrapassar o teto que você definiu antes, para e recalcula.

O terceiro critério ganhou peso quando as plataformas de gestão passaram a cobrar IA por crédito consumido, e não só por assento — modelo em que a conta muda quando a equipe descobre um recurso novo, porque o consumo escala com comportamento e não com número de pessoas. As duas plataformas com que eu trabalho cobram de formas diferentes, e isso muda o que “teto de custo” significa: no monday.com a cota de créditos é da conta e o consumo por agentes passou a valer para os planos Profissional e inferiores desde 8 de junho de 2026, com o corporativo isento por ora; no ClickUp a camada de IA é complemento por membro, com uma moeda própria de créditos em que cada execução de agente consome de 100 a 300. Se quiser observar o consumo real antes de definir o teto, dá para abrir uma conta de teste no ClickUp ou no monday.com e rodar o processo do piloto por uma semana só olhando o painel de uso.

O que monitorar depois que ligou

Piloto não acaba quando a ferramenta entra no ar — essa é a parte que mais se perde. O NIST descreve o que a fase de operação exige, e a lista vira checklist direto: monitoramento contínuo, testes periódicos, recalibração por quem entende do processo, registro dos incidentes e erros reportados, detecção de comportamentos novos e um canal de correção para quem foi afetado.

A segunda linha merece destaque porque é grátis de coletar e quase ninguém coleta: o NIST lista explicitamente os quase-acidentes entre o que o monitoramento ajuda a identificar. Registrar as vezes em que alguém pegou o erro da IA antes de ele sair é o sinal mais antecipado de que o piloto vai dar errado.

Há ainda um alerta de método que separa “testamos e funcionou” de “colocamos em produção”: medições feitas em ambiente controlado, antes da implantação, podem divergir dos riscos que emergem no uso real. É por isso que o piloto existe em vez de só uma demonstração — e por isso o monitoramento depois não é opcional.

Como decidir se expande

Na data de encerramento, com os três números na mesa e uma pergunta desconfortável: se ninguém tivesse feito nada, o resultado seria muito diferente?

A regra operacional para responder isso está no material de apoio do próprio NIST: comparar as métricas observadas em produção com as mesmas métricas coletadas nos testes de antes, e documentar a diferença. É a prova de que a linha de base não é enfeite — ela existe para ser subtraída depois. E é por isso que a métrica do piloto precisa ser a mesma métrica do antes, medida do mesmo jeito.

Expandir significa ligar para todo mundo?

Não. Expandir tem duas direções, e elas custam coisas diferentes: mais gente no mesmo processo ou mesmo método em outro processo. A primeira é barata e previsível. A segunda recomeça o ciclo do zero — inclusive a medição de antes.

O erro caro é fazer as duas ao mesmo tempo, porque devolve exatamente o problema que o piloto existia para evitar: variáveis demais se movendo juntas. E vale lembrar o que a seção regulatória mostrou: expandir para a empresa inteira pode ser justamente o movimento que faz o tratamento cruzar o critério de larga escala.

Quando não vale fazer piloto

O método tem custo, e há casos em que ele é maior que o risco que evita.

Quando o processo não é rastreável. Já dito e vale repetir porque é o caso mais comum: sem registro, não há linha de base, e sem linha de base o piloto não produz decisão. O trabalho é anterior.

Quando a IA é assistente pessoal, não etapa de processo. Alguém usar um assistente para escrever melhor um e-mail não é piloto — é ferramenta individual. Medir isso com o aparato deste artigo é desperdício.

Quando o processo muda toda semana. Piloto compara antes e depois. Se o processo mudou de forma no meio, os dois números medem coisas diferentes.

Quando ninguém responde pela área. Sem a pessoa que decide se a saída é aceitável, o piloto gera opinião, não resultado.

Quando a decisão já está tomada. Se a empresa vai adotar de qualquer jeito, por decisão de sócio ou exigência de matriz, chame de implantação e faça implantação — com regra de revisão e monitoramento. Chamar de piloto um projeto sem possibilidade de reprovação só gasta a credibilidade do próximo.

O que já vale no Brasil e o que ainda não vale

Registro isso separado porque a confusão entre as duas coisas é a fonte mais comum de erro em texto sobre IA — e porque metade do que eu citei aqui não obriga ninguém.

E uma última nota de honestidade metodológica: não existe fonte primária brasileira que prescreva metodologia de piloto — escopo pequeno, linha de base antes, critérios de parada, decisão de expandir. A LGPD dá as obrigações; o método é escolha de gestão informada por referências estrangeiras e voluntárias. Preferi dizer isso a apresentar boa prática como imposição legal.

Vale ainda saber que documentar tem efeito monetário previsto na própria lei: entre os critérios de dosimetria das sanções, a LGPD manda considerar a adoção reiterada e demonstrada de mecanismos e procedimentos internos capazes de minimizar o dano, a adoção de política de boas práticas e governança, e a pronta adoção de medidas corretivas. O caderno do piloto — regra de revisão, critérios de parada, registro dos incidentes — é peça de defesa, não papelada.

Perguntas frequentes

Próximo passo

Antes de escolher a ferramenta, responda quatro coisas: qual é o processo, quem responde por ele, qual é o número de antes e o que faz você desligar. Se a quarta resposta não existir, o piloto ainda não está desenhado — está agendado.

Se o travamento for a etapa de medição — “não temos como saber quanto tempo esse processo leva hoje” —, o trabalho é anterior e é de estrutura: é o que a consultoria resolve ao definir o que a empresa passa a registrar, e o que o treinamento sustenta depois, quando a regra de revisão precisa virar hábito de quem opera.

Para entender por que tantos pilotos morrem na passagem para produção, maturidade de IA: do piloto à escala trata do vão entre as duas coisas. Se você ainda não escolheu o processo, volte para por onde começar com IA na empresa. E o desenho da regra de revisão dentro das plataformas está em agente supervisionado: quem aprova o quê.

Fontes

• Brasil — Lei nº 13.709/2018 (LGPD), em especial os arts. 3º, 6º, 20, 37 e 52
• Brasil — Lei nº 12.414/2011 (Cadastro Positivo), art. 5º
• Presidência da República — Mensagem nº 288/2019 (razões do veto ao § 3º do art. 20)
• ANPD — Resolução CD/ANPD nº 2/2022, arts. 3º, 4º e 6º
• NIST — AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1
• NIST — AI RMF Playbook, função Measure
• ClickUp Help Center — How are AI Super Credits consumed?
• monday.com Support — AI Credits

*Este texto não é orientação jurídica. As leituras de dispositivos legais aqui são interpretações do texto em vigor, e o enquadramento concreto do seu caso depende dos dados tratados e do setor — processos de crédito, cobrança e seguros têm camada regulatória adicional não coberta aqui. O framework do NIST é voluntário e norte-americano, e é usado como referência de método, não como obrigação. Cotas e regras de cobrança de IA das plataformas são condição de cada fabricante e mudam sem aviso. A Audatia é revenda oficial de licenças ClickUp no Brasil, segundo a regra do fabricante de mínimo de 10 usuários, e não revende licenças do monday.com, atuando em consultoria, treinamento e sustentação.