IA na Empresa em 30 Dias

Um piloto pequeno, mensurável e seguro

Este playbook gratuito não promete transformar a empresa inteira em um mês. Ele ajuda você a escolher um problema real, testar uma primeira solução e terminar o ciclo sabendo se deve ampliar, corrigir ou parar.

Você vai trabalhar com seis elementos:

gargalo frequente;
responsável de negócio;
linha de base;
fluxo delimitado;
revisão humana;
reunião de decisão.

Sem isso, a empresa compra tecnologia antes de entender o trabalho.

> O primeiro projeto não precisa provar que IA resolve tudo. Precisa provar valor em um caso e ensinar a empresa a implantar melhor.

Antes do dia 1: monte o grupo mínimo

Defina três papéis, mesmo que uma pessoa acumule mais de um:

dono do resultado: responde pela métrica de negócio;
dono do processo: conhece a rotina e as exceções;
apoio técnico: configura ferramenta, acesso e registro.

Reserve duas reuniões: 45 minutos no início e 45 minutos no dia 30. Combine também uma revisão semanal de 20 minutos.

Crie uma pasta ou documento com:

ficha do caso;
linha de base;
fontes autorizadas;
casos de teste;
registro de falhas;
decisão final.

Dias 1 a 3: liste problemas, não ferramentas

Procure situações que já custam tempo, receita, qualidade ou velocidade:

lead que esfria;
atendimento que repete perguntas;
proposta que demora;
documento que ninguém encontra;
fechamento que exige consolidação manual;
relatório que chega tarde;
tarefa previsível que ocupa pessoa qualificada;
informação que precisa ser copiada entre sistemas.

Liste até dez situações. Não escreva “usar um agente”. Escreva o trabalho e o impacto.

Ficha de oportunidade

Dias 4 e 5: escolha o primeiro caso

Dê notas de 1 a 5 para:

valor econômico;
frequência;
facilidade de medir;
disponibilidade de dados;
reversibilidade;
risco.

Priorize valor, frequência, dados e reversibilidade. Trate risco alto como sinal para reduzir autonomia ou escolher outro piloto.

Um bom primeiro caso:

acontece toda semana;
possui início e fim claros;
gera saída verificável;
usa fontes controladas;
admite revisão humana;
não toma decisão irreversível sozinho.

Escreva:

“Hoje, a equipe gasta ou perde X por causa de Y. Vamos testar Z por N dias e medir W, mantendo H sob revisão humana.”

Dias 6 a 8: meça a linha de base

Antes de testar, acompanhe uma amostra real. Use de três a cinco métricas:

tempo total;
tempo de espera;
volume;
erro ou retrabalho;
conversão;
receita recuperada;
custo por caso;
satisfação;
percentual transferido.

Registre a fonte e a regra de cálculo. Uma linha de base aproximada, porém honesta, é melhor que um número perfeito inventado.

Exemplo

Caso: preparação de propostas.

18 propostas por mês;
75 minutos de trabalho por proposta;
2,5 dias entre diagnóstico e envio;
22% retornam por falta de informação;
revisão final feita pelo responsável comercial.

Dias 9 e 10: desenhe o fluxo

Observe uma execução e registre:

1. gatilho;

2. dados de entrada;

3. decisões;

4. fontes consultadas;

5. ações;

6. saída;

7. exceções;

8. passagem para uma pessoa.

Separe regra, automação e interpretação. Nem todo passo precisa de IA.

Exemplo:

regra valida e-mail e campo obrigatório;
automação salva no CRM;
IA resume contexto e sugere classificação;
pessoa aprova prioridade alta;
sistema registra próximo passo.

Dias 11 e 12: organize contexto e dados

Defina uma fonte de verdade para políticas, preços, catálogo e procedimento. Remova versões conflitantes. Para cada fonte, registre dono e data de revisão.

Classifique dados:

públicos;
internos;
pessoais;
sensíveis;
proibidos no piloto.

Use a menor permissão possível. Um piloto de proposta não precisa acessar folha de pagamento. Um agente de atendimento não precisa poder excluir cadastro.

Pergunte:

existe consentimento ou base adequada para o uso?
o fornecedor pode treinar com esses dados?
o conteúdo fica retido por quanto tempo?
quem consegue revisar ou apagar?
o log registra o necessário sem expor demais?

Dias 13 e 14: escreva o contrato do piloto

Uma página deve conter:

objetivo;
usuários;
intenções atendidas;
entradas obrigatórias;
fontes autorizadas;
ações permitidas;
ações proibidas;
saída esperada;
critérios de qualidade;
sinais de escalada;
métricas;
responsável.

Defina claramente quando a solução deve dizer “não sei”, pedir dado ou transferir.

Dias 15 a 17: monte a primeira versão

Comece pelo menor fluxo que produz valor. Evite conectar todos os sistemas de uma vez.

Ordem recomendada:

1. entrada manual controlada;

2. saída estruturada;

3. revisão humana;

4. registro do resultado;

5. uma integração necessária;

6. automação adicional após estabilidade.

Versione instruções e fontes. Registre qual versão produziu cada teste.

Dias 18 e 19: teste antes de envolver clientes

Crie de 20 a 30 casos:

caminho normal;
informação faltante;
política conflitante;
pedido fora do escopo;
linguagem ambígua;
integração indisponível;
tentativa de obter informação proibida;
alto impacto.

Avalie:

tarefa concluída;
dado correto;
fonte correta;
ação permitida;
formato útil;
transferência adequada;
ausência de promessa indevida.

Falha crítica não deve ser compensada por média alta. Vazamento, ação proibida e condição comercial inventada bloqueiam o piloto.

Dias 20 a 24: rode produção assistida

Limite:

uma equipe;
um canal;
um tipo de caso;
horário e volume;
revisão definida.

Na primeira fase, revise todas as saídas com impacto externo. Para tarefas internas de baixo risco, use amostragem alta.

Registre falhas por causa:

contexto ausente;
instrução ambígua;
fonte desatualizada;
ferramenta errada;
permissão excessiva;
caso fora do escopo;
revisão humana falhou.

Corrija o sistema, não apenas a frase final.

Dias 25 a 27: meça adoção e custo total

Além da qualidade, observe:

pessoas realmente usam?
em qual momento abandonam?
a revisão consome quanto tempo?
o resultado entra no sistema correto?
clientes ou equipe repetem trabalho?
qual custo por caso concluído?

Inclua ferramenta, modelo, integração, revisão, manutenção e correção. Automação que economiza dez minutos e cria quinze de conferência não provou retorno.

Dias 28 e 29: prepare a decisão

Compare linha de base e piloto. Monte uma página:

Liste:

ganhos observados;
falhas críticas e altas;
custo total;
adesão;
riscos;
dependências;
próximos testes.

Evite escolher apenas exemplos bons. Mostre a distribuição e os casos em que o fluxo falhou.

Dia 30: ampliar, corrigir ou parar

Ampliar

Use quando qualidade, risco, custo e adoção estão aceitáveis. Aumente uma dimensão por ciclo: volume, usuários, integração ou autonomia.

Corrigir

Use quando o valor é plausível, mas existe falha específica solucionável. Defina novo teste e condição de aprovação.

Parar

Use quando o caso não possui dados, retorno, adesão ou segurança suficiente. Parar cedo preserva capital e gera aprendizado.

Registre a decisão, o responsável e a próxima data de revisão.

Três pilotos adequados para começar

Preparação de reunião comercial

Consolidar histórico, dados do CRM, pendências e perguntas. A pessoa valida antes da reunião.

Triagem de atendimento

Identificar intenção, coletar campos, consultar FAQ aprovado e transferir exceções com resumo.

Relatório operacional diário

Reunir indicadores autorizados, apontar desvios e preparar perguntas para o gestor, sem tomar decisão financeira sozinho.

Templates

Ficha do caso

Registro de teste

Registro semanal

Checklist de encerramento

O caso cabe em uma frase.
Existe dono de negócio.
A linha de base foi registrada.
Escopo e exclusões estão claros.
Dados e permissões foram revisados.
Casos de teste incluem exceções.
Revisão humana está definida.
Métricas incluem qualidade, custo e adoção.
Falhas foram classificadas.
A decisão foi registrada.

O ativo mais valioso do primeiro projeto é a capacidade de escolher, testar, medir e evoluir tecnologia sem depender de entusiasmo ou medo.