Plano de 90 dias para colocar IA para trabalhar na empresa
Um manual para escolher um processo, testar com dados seguros, medir resultado e decidir em 90 dias se a IA deve avançar, mudar ou ser interrompida.
Por Cesar A. Machado · · 15 min
Escolha um fluxo frequente, mensurável e reversível; deixe decisões de alto impacto fora do primeiro piloto.
Registre tempo, qualidade, retrabalho e exceções antes do teste para não confundir novidade com resultado.
Mantenha aprovação humana e fontes rastreáveis enquanto a saída da IA puder afetar clientes, dinheiro ou direitos.
Defina previamente limites de custo, erro e incidente que pausam o piloto sem depender do entusiasmo da equipe.
Escale apenas depois de duas semanas estáveis e entregue ao processo um dono, um runbook e uma rotina de auditoria.
O que precisa existir no dia 90
Em 90 dias, uma empresa de 20 a 100 funcionários consegue colocar IA para trabalhar se limitar o projeto a um processo recorrente, nomear um responsável de negócio, medir o trabalho atual antes da mudança, testar com entradas reais e seguras, manter revisão humana e decidir por critérios escritos. O resultado esperado não é “ter IA”: é operar um fluxo delimitado com menos tempo ou retrabalho, qualidade igual ou melhor, custo conhecido, exceções encaminhadas e registro suficiente para explicar cada decisão. Se esses sinais não aparecerem, a decisão correta é ajustar ou interromper. O plano começa com um problema observável e termina com uma decisão operacional. Em cada fase, a equipe produz um artefato que a fase seguinte consome: inventário, baseline, mapa de risco, conjunto de teste, registro do piloto, comparação e runbook. Essa sequência impede que uma opinião favorável substitua evidência. Para uma empresa desse porte, um patrocinador pode acumular a decisão orçamentária, mas o dono do processo e o responsável técnico não devem desaparecer: alguém responde pelo resultado diário e alguém responde pelo funcionamento e pelo desligamento.
Este plano serve para usos assistivos, como classificar solicitações, resumir documentos internos autorizados, preparar primeira versão de respostas ou localizar informação em uma base aprovada. O primeiro ciclo não deve aprovar crédito, contratar ou demitir, emitir orientação médica ou jurídica, movimentar dinheiro, publicar automaticamente para clientes nem tomar decisão exclusivamente automatizada sobre pessoas. Nesses casos, impacto, regulação e necessidade de revisão especializada mudam o projeto.
Escolha um fluxo, não uma ferramenta
Pilotos fracassam cedo quando começam pela ferramenta e procuram um problema depois. A causa é simples: uma demonstração produz texto convincente, mas não revela a variação das entradas, as regras tácitas, os sistemas envolvidos nem quem responde pelo erro. Comece pelo inventário de trabalho. Durante cinco dias úteis, peça aos líderes de atendimento, vendas, financeiro, operações e RH que indiquem tarefas repetidas, volume semanal, tempo por unidade, atrasos, retrabalho, fonte consultada e consequência de uma resposta errada.
Dê preferência ao fluxo frequente, com texto ou documentos relativamente padronizados, resultado conferível em poucos minutos e retorno fácil ao modo manual. Evite o processo raro, mal documentado ou cuja qualidade só aparece meses depois. Um bom primeiro caso pode ser transformar e-mails de suporte em categoria, urgência sugerida e rascunho de resposta, sem enviar nada. A fonte oficial continua sendo o sistema de atendimento; a IA apenas propõe.
Critério
Pergunta de verificação
Sinal favorável
Motivo para adiar
Valor operacional
Há volume ou fila suficiente?
Pelo menos dezenas de casos por semana
Evento raro ou sem baseline
Verificabilidade
Alguém confere a saída rapidamente?
Resposta certa pode ser comparada com regra ou fonte
Resultado subjetivo sem padrão
Risco
O erro é reversível antes do efeito?
Humano aprova antes de cliente, pagamento ou cadastro
Efeito automático sobre dinheiro, pessoa ou direito
Dados
A entrada pode ser usada com base legal e controle?
Conjunto autorizado, minimizado e com acesso restrito
Segredo, dado sensível ou contrato incerto
Integração
É possível pilotar sem alterar sistemas críticos?
Exportação controlada ou ambiente de teste
Dependência de mudança estrutural imediata
O patrocinador escolhe um ?nico caso com base no conjunto, n?o apenas na economia projetada. Registre tamb?m o que fica fora: canais n?o atendidos, tipos de documento, idiomas, clientes, decis?es e dados proibidos. Essa fronteira evita que um teste de rascunho se transforme silenciosamente em atendimento autom?tico. Fa?a uma pontua??o de 1 a 5 para valor, verificabilidade, reversibilidade, preparo dos dados e esfor?o t?cnico. N?o transforme a soma em verdade matem?tica: use-a para comparar op??es e expor diverg?ncias. Um caso com alto valor e baixa reversibilidade pode perder para outro menor, por?m test?vel. Registre a decis?o, os participantes e as premissas. A sa?da concreta ? um termo de abertura de uma p?gina com objetivo ?nico, m?trica prim?ria, limites de seguran?a, popula??o eleg?vel, dura??o, or?amento m?ximo e dono da decis?o final.
Dias 1 a 15: linha de base, dono e fronteiras
O dono do processo mede uma amostra recente e representativa, idealmente distribuída por dias e pessoas. Para cada caso, registre minutos de trabalho, espera, correção posterior, conclusão correta na primeira tentativa e motivo da exceção. Não some “horas poupadas” por estimativa de memória. Cronometre uma amostra e informe tamanho e período. A saída desta etapa é uma ficha de baseline com volume semanal, mediana de tempo, taxa de retrabalho, taxa de erro relevante e custo direto conhecido.
Desenhe o percurso real: gatilho, entrada, validações, consulta a fontes, decisão, aprovação, gravação em sistema e comunicação. Ao lado de cada etapa, escreva responsável e sistema de registro. Marque regras determinísticas — prazo, limite, permissão, cálculo, status — que devem continuar em código ou procedimento, não no modelo. Marque também dependências externas, como API, e-mail ou base de conhecimento, com timeout e alternativa manual.
Papel
Responsabilidade no piloto
Entrega até o dia 15
Patrocinador
Define objetivo, orçamento e apetite a risco
Termo de abertura e decisão final
Dono do processo
Responde pela qualidade e pela rotina
Baseline, regras e fila de exceções
TI ou fornecedor técnico
Configura acesso, logs, integração e desligamento
Ambiente controlado e inventário técnico
Privacidade e segurança
Avalia dados, contrato, acesso e incidente
Restrições de uso e resposta a incidente
Usuários do piloto
Executam casos e explicam correções
Amostra anotada e feedback estruturado
Antes de enviar qualquer dado, confirme finalidade, hipótese legal aplicável, minimização, retenção, localização quando relevante, uso do conteúdo pelo fornecedor, suboperadores, exclusão, exportação de logs e controle de acesso. A LGPD exige medidas técnicas e administrativas desde a concepção até a execução. Para o primeiro piloto, substitua identificadores quando possível, remova campos desnecessários e proíba contas pessoais ou ferramentas não aprovadas. Peça evidência contratual e configuração, não apenas resposta comercial. Verifique autenticação multifator, perfis por função, possibilidade de desativar usuários, criptografia, histórico de incidentes disponível, canal de suporte, prazo de notificação, continuidade e destino dos dados ao encerrar. Se o fornecedor muda modelo ou política sem aviso, trate isso como risco de alteração do processo. Privacidade e segurança aprovam o padrão de dados; o patrocinador aceita o risco residual; usuários não podem ampliar o uso por conveniência.
Pare antes do primeiro teste se ninguém souber quais dados pessoais entram, quem é o controlador e o operador, onde as entradas ficam armazenadas ou como revogar acessos. “É só um piloto” não reduz a obrigação de proteger dados.
Dias 16 a 30: conjunto de teste e protótipo controlado
O dono do processo separa casos históricos autorizados em três grupos: construção, validação e desafio. Inclua casos comuns, bordas, entradas incompletas, solicitações conflitantes e conteúdo que tenta desviar a instrução. Remova dados desnecessários. Para cada item, anote a saída esperada, a fonte usada, os erros inaceitáveis e quando encaminhar a uma pessoa. O grupo de validação não deve ser ajustado toda vez que o resultado desapontar; ele existe para impedir que a equipe “ensine para a prova”. O tamanho depende da variedade, não de um número universal. Comece com quantidade suficiente para conter todas as categorias relevantes e aumente enquanto aparecem erros novos. Se há seis categorias e duas exceções críticas, uma amostra de dez casos é fraca, mesmo que todos passem. Duas pessoas podem anotar parte da mesma amostra e comparar discordâncias; desacordo alto indica regra operacional ambígua. Resolva a ambiguidade antes de atribuir ao modelo um erro que a própria equipe não consegue definir.
O protótipo recebe apenas o necessário, produz saída estruturada e mostra a fonte quando a tarefa depende de conhecimento. Campos como categoria, confiança operacional, justificativa curta e motivo de encaminhamento facilitam a validação. Temperatura, versão do modelo, instruções, base consultada e data devem ser registradas para reproduzir o teste. Se a solução usa busca interna, respostas sem evidência retornam “não localizado” em vez de completar lacunas.
Execute o conjunto várias vezes quando houver variação de resposta. Teste indisponibilidade do provedor, documento ilegível, entrada acima do limite, ausência de permissão, repetição da mesma requisição e interrupção no meio. Uma escrita posterior precisa de chave de idempotência ou checagem de duplicidade. Uma chamada externa precisa de timeout e mensagem útil. A saída da fase é um relatório por categoria de erro, não uma seleção das melhores respostas. Defina severidade. Erro leve exige edição de forma; moderado altera informação mas é detido na revisão; grave poderia gerar dano financeiro, contratual, reputacional ou a um titular. Conte o caso na pior severidade aplicável e preserve exemplos para regressão. O responsável técnico corrige mecanismo; o dono corrige regra ou fonte; privacidade e segurança avaliam incidentes. Entradas maliciosas, como instruções escondidas em documentos para ignorar regras, devem ser tratadas como conteúdo não confiável, nunca como comando autorizado.
Se sua equipe precisa transformar esse inventário em um piloto com fronteiras, métricas e responsabilidades claras, solicite um diagnóstico em https://blog.cesarmachado.com/contato. O objetivo da conversa é delimitar o caso e os critérios de decisão, não vender uma ferramenta antes do problema.
Dias 31 a 60: operação assistida com usuários reais
Libere o piloto para um grupo pequeno e treinado, em paralelo ao processo vigente. Toda saída que possa chegar a cliente, alterar cadastro ou orientar ação continua exigindo aprovação identificada. O usuário vê a fonte, corrige a sugestão e marca o motivo: dado ausente, regra ambígua, fonte desatualizada, interpretação errada, formato inadequado ou falha técnica. Texto livre sozinho dificulta descobrir a causa. Treinamento deve caber no trabalho: uma sessão curta, exemplos aprovados, lista do que não inserir e exercício de pausa. O usuário precisa saber que fluência não é certeza, como conferir evidência e onde registrar discordância. Durante a primeira semana, o dono observa uso real e remove atalhos perigosos. Baixa adoção pode indicar interface ruim, caso irrelevante, falta de confiança ou incentivo desalinhado; não conclua imediatamente que “as pessoas resistem à tecnologia”. Entreviste quem usa e quem deixou de usar.
Cada execução recebe identificador, horário, usuário, versão da configuração, tipo de entrada, resultado, duração, custo quando disponível, decisão humana e erro classificado. Não registre conteúdo pessoal integral sem necessidade; associe o identificador ao sistema oficial e aplique retenção. O log operacional responde “o que ocorreu”; o registro de auditoria responde “quem aprovou qual efeito”. Restringir e revisar acessos é parte do piloto.
Faça uma reunião semanal de 30 minutos com dono do processo, representante dos usuários e responsável técnico. Compare qualidade, tempo, adoção, exceções, incidentes e custo com o baseline. Escolha no máximo duas mudanças por semana e versione instruções ou fontes. Se tudo muda ao mesmo tempo, não é possível atribuir melhora ou regressão. O patrocinador recebe uma página com tendência e decisão: continuar, corrigir, reduzir escopo ou pausar.
Dias 61 a 75: corrigir causas e provar estabilidade
Separe falha do modelo de falha do processo. Dado ausente pede validação de entrada; regra fixa pede lógica determinística; fonte desatualizada pede governança de conteúdo; falta de permissão pede controle de acesso; resposta inventada pede restrição de fonte, teste e encaminhamento. Trocar o modelo pode ajudar em capacidade ou latência, mas não corrige ownership, base ruim ou regra contraditória. Toda correção deve indicar causa, mudança, responsável e teste de regressão.
Depois das correções, congele a configuração por duas semanas úteis. Meça o fluxo sem demonstrações preparadas e sem supervisão extraordinária. Compare a mesma definição de sucesso usada no baseline. Se novos funcionários precisam de horas de ajuda informal, inclua esse tempo. Se revisores apenas transferiram o trabalho para outra fila, conte espera e correção. O ganho precisa sobreviver ao custo total da operação.
Use poucas métricas ligadas ao objetivo: tempo mediano por caso, conclusão correta na primeira tentativa, minutos de revisão humana, retrabalho posterior, proporção encaminhada, custo por caso, adoção entre elegíveis, disponibilidade e incidentes por severidade. Média de tempo pode esconder poucos casos muito longos; por isso, acompanhe também percentil 90 quando o volume permitir. Satisfação ajuda, mas não substitui qualidade observada. Defina numerador, denominador, fonte, frequência e responsável por cada indicador. “Taxa de acerto” pode significar casos sem nenhuma edição, casos aprovados após correção ou campos corretos; são medidas diferentes. Para taxa de conclusão correta na primeira tentativa, use casos aprovados sem correção substantiva divididos por casos elegíveis processados. Apresente volume junto da porcentagem: 100% em quatro casos não equivale a estabilidade. Guardrails não entram em média com benefício; um incidente crítico pode interromper o piloto mesmo quando o tempo melhora.
Dias 76 a 90: decidir, documentar e entregar à operação
No dia 76, o patrocinador convoca a decisão com evidência congelada. “Avançar” exige benefício líquido, qualidade dentro do limite, ausência de risco crítico aberto e capacidade operacional. “Ajustar” exige hipótese específica e novo prazo curto. “Interromper” é o resultado certo quando o caso não paga seu custo, depende de correção humana excessiva ou permanece inseguro. Evite o limbo do piloto eterno: toda decisão tem data, responsável e condição de revisão. O dossiê de decisão deve mostrar baseline e janela estável lado a lado, tamanho das amostras, mudança absoluta e relativa, custo total, exceções e incidentes. Liste custos únicos separadamente dos recorrentes: configuração, integração, limpeza de dados, treinamento e revisão não desaparecem porque a licença é barata. Registre efeitos deslocados: um atendimento mais rápido que aumenta correções no financeiro não é ganho. Quando a evidência for inconclusiva, prefira extensão pequena com hipótese testável a uma expansão de escopo.
Para avançar, entregue um runbook: objetivo e escopo, entrada permitida, fluxo normal, fontes, papéis, acessos, limites de custo, painel, tratamento de exceção, contato do fornecedor, procedimento de pausa, resposta a incidente e retorno manual. Registre versão do modelo e da regra. Defina quem revisa amostras semanalmente, quem atualiza a base e quem pode reativar após falha. Inclua no runbook três exercícios: retirar acesso de uma pessoa, operar um dia sem o provedor e investigar uma saída errada pelo identificador. Se qualquer exercício depender da memória de quem construiu, a passagem ainda não terminou. Defina retenção dos registros e calendário de revisão mensal no início, trimestral depois de estabilidade. Mudanças relevantes exigem revalidação do conjunto de desafio. O fornecedor técnico pode manter a solução, mas a empresa conserva acesso aos registros, à configuração e ao procedimento de desligamento.
Escalar significa ampliar uma dimensão por vez: usuários, volume, tipos de entrada ou automação. Mantenha um grupo de comparação quando possível e repita testes após mudança de modelo, instrução, fonte ou integração. A gestão de risco é contínua, como propõe o NIST AI RMF nas funções governar, mapear, medir e gerenciar. O dia 90 encerra a descoberta do primeiro caso; não encerra o monitoramento.
Cenário hipotético: triagem de atendimento
Cenário hipotético, não caso real. Uma distribuidora com 48 funcionários recebe 600 solicitações por mês. Premissas: o piloto atua em 40% delas, ou 240 casos/mês; cada caso elegível consome hoje 12 minutos; com classificação e rascunho assistidos, passa a consumir 7 minutos, já incluindo revisão humana; custo-hora carregado usado apenas para planejamento: R$ 45; licença e uso do serviço: R$ 900 por mês. Período de comparação: um mês estável após duas semanas de operação. Unidade principal: horas de trabalho por mês.
Fórmula: horas brutas liberadas = 240 casos × (12 − 7) minutos ÷ 60 = 20 horas/mês. Valor bruto de capacidade = 20 horas × R$ 45/hora = R$ 900/mês. Benefício financeiro direto estimado = R$ 900 − R$ 900 de serviço = R$ 0/mês, antes de implantação, treinamento, segurança e suporte. Portanto, esse piloto não se justifica por redução direta de custo. Pode haver valor em prazo ou qualidade, mas isso precisa ser medido separadamente, por exemplo pela queda de solicitações fora do SLA.
Limites: horas liberadas n?o equivalem automaticamente a redu??o de folha ou receita; volume, mix e tempo variam; a amostra pode conter sazonalidade; custo-hora ? premissa gerencial, n?o dado de mercado; qualidade n?o foi monetizada. Crit?rios hipot?ticos para avan?ar: pelo menos 20% de redu??o no tempo mediano, qualidade igual ou superior ao baseline, zero envio sem aprova??o, nenhum incidente de dado, custo total de at? R$ 1.200/m?s e menos de 15% de casos devolvidos por erro. Dois erros graves semelhantes ou um incidente de acesso pausam o piloto. Se a meta principal fosse prazo, a empresa poderia definir outra equa??o: taxa fora do SLA = solicita??es eleg?veis conclu?das ap?s o prazo ? solicita??es eleg?veis conclu?das no per?odo. Compararia baseline e piloto com o mesmo SLA e popula??o. Ainda assim, correla??o n?o prova que a IA causou a mudan?a; altera??es de equipe, demanda e mix devem ser registradas. Para monetizar capacidade, a gest?o precisaria declarar o uso poss?vel das 20 horas ? absorver crescimento, reduzir hora extra ou executar trabalho antes adiado ? e verificar se isso realmente ocorreu. O c?lculo ? uma hip?tese de decis?o, n?o uma promessa de retorno.
O texto compilado da Lei nº 13.709/2018 sustenta os princípios de finalidade, necessidade, segurança, prevenção e prestação de contas, além da exigência de medidas técnicas e administrativas desde a concepção e do registro de operações de tratamento. https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709compilado.htm
O perfil de IA generativa NIST AI 600-1 sustenta os riscos específicos considerados no plano, como confabulação, exposição ou inferência de informação sensível, conteúdo danoso e necessidade de monitoramento, avaliação e controles ajustados ao contexto. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
Se o próximo passo é sair de testes dispersos e construir um primeiro fluxo com baseline, governança e decisão de go/no-go, descreva o processo em https://blog.cesarmachado.com/contato. A conversa pode começar pelo gargalo, pelos dados disponíveis e pelo risco aceitável.
Ao fim de 90 dias, o ativo mais importante não é o prompt: é a evidência de que um fluxo delimitado melhorou sem transferir custo, erro ou risco para outra pessoa.
Plano de 90 dias para implementar IA na empresa
Cezao Blog
PROGRESSO
OBRA DO HERO · AGUARDANDO ARQUIVOSobra-base.png + obra-rx.png mesma dimensão e alinhamento
ENGENHARIA DE IA
Cezao Blog
Sistemas de IA aplicados a processos reais de empresas de 20 a 100 funcionários.
MOVA O CURSOR SOBRE A OBRACEZAO BLOG · ENGENHARIA DE IA
Experiência aplicada em software, operação e governança de sistemas de IA. Os projetos são descritos pelo problema e pela engenharia envolvida, preservando informações internas.
{{ item.num }}{{ item.tag }}
{{ item.title }}
{{ item.text }}
Como o trabalho acontece
{{ item.num }}
{{ item.title }}
{{ item.text }}
Para empresas de 20 a 100 pessoas
O ponto de partida é um processo específico, com responsável, volume e impacto identificáveis. A solução precisa caber na capacidade da equipe, produzir evidência e preservar controle sobre decisões importantes.
→{{ item }}
Tecnologias e camadas
A FERRAMENTA SEGUE O PROCESSO
{{ item }}
PRÓXIMO PASSO
Comece por um processo concreto.
Descreva o processo, o volume aproximado e o principal gargalo. A conversa começa avaliando se IA é adequada e qual é o menor piloto capaz de produzir evidência.
Ferramentas
Clique em uma ferramenta para abrir. Conteúdo de cada uma a definir.
Kit atual
{{ t.num }}
{{ t.title }}
{{ t.desc }}
{{ t.state }}
Portfólio
Projetos de software e ecossistemas construídos com engenharia de IA. Conteúdo de cada caso a definir.
{{ caseCount }}
Projetos
capa do projeto{{ p.num }}
{{ p.kind }} · {{ p.year }}
{{ p.title }}
{{ p.desc }}
{{ tg.label }}
ABRIR CASO
{{ detail.num }}{{ detail.kind }}
{{ detail.title }}
{{ detail.desc }}
{{ m.k }}
{{ m.v }}
imagem principal do caso
{{ bl.title }}
{{ bl.hint }}
Briefing
3 PASSOS · CERCA DE 1 MINUTO
Toque nas opções que descrevem seu projeto. Só o último passo pede digitação.
Briefing recebido
Obrigado. Retorno pelo e-mail informado com as próximas perguntas.
