Conselhos aprovam projetos de tecnologia por dois motivos ruins: porque a apresentação foi boa e porque ninguém na sala se sentiu autorizado a expor a própria falta de familiaridade técnica. As perguntas abaixo resolvem o segundo problema. Nenhuma delas exige conhecimento técnico para ser feita, e todas exigem conhecimento real para serem respondidas.
Use na ordem. As quatro primeiras eliminam a maioria dos projetos ruins antes de você gastar tempo com as outras oito.
Valor
- Qual número da nossa operação muda, e em quanto? A resposta precisa ser uma linha do DRE ou um indicador operacional com dono, valor atual e valor esperado. "Ganho de eficiência" e "melhor experiência" não são respostas. Se ninguém consegue nomear o número, o projeto não tem tese, tem entusiasmo.
- Como saberemos, em 90 dias, que estamos no caminho certo ou errado? Todo projeto deveria carregar um marco de leitura precoce. Sem ele, o primeiro sinal de fracasso chega junto com a fatura final.
- Qual é a alternativa mais barata que resolveria 70% disso? Faça a pergunta mesmo sabendo que a resposta pode ser desagradável. Em operações de médio porte, uma mudança de processo ou uma integração costuma capturar a maior parte do valor prometido por um projeto de IA, a uma fração do custo. Se ninguém avaliou a alternativa barata, o comparativo apresentado é retórico.
- O que acontece se não fizermos nada por 12 meses? Se a resposta honesta for "pouco", você acabou de descobrir que este não é o projeto mais importante da fila.
Dado
- Os dados que este modelo precisa existem hoje, com qualidade auditada? A pergunta de controle é sempre a mesma: alguém já mediu a taxa de preenchimento, de duplicidade e de erro nessa base? "Temos os dados" quase nunca sobrevive à segunda pergunta.
- Quem é o dono do dado, e ele concordou com este uso? Dado sem dono declarado é dado que ninguém corrige. E uso não acordado com a área que gera o dado é a causa mais comum de projeto que funciona no piloto e morre na escala.
- Se o modelo errar, quem percebe e quanto tempo leva? Modelos degradam em silêncio. Um projeto de IA sem plano de monitoramento e sem responsável por revisar as saídas não é um ativo, é um passivo com aparência de automação.
Risco
- Qual dado pessoal, sensível ou de terceiro entra neste processo, e sob qual base legal? Se a resposta demorar, pare a aprovação. Imagem de pessoas, dado de menores, informação de cliente e dado de fornecedor sob contrato de confidencialidade são as quatro fontes mais frequentes de exposição não mapeada.
- Este projeto nos deixa dependentes de um único fornecedor? Pergunte especificamente: se trocarmos de fornecedor em 24 meses, o que perdemos, quanto custa a saída e de quem é a propriedade dos modelos, dos dados de treino e da documentação. A resposta precisa estar em contrato, não em relação de confiança.
- Qual decisão humana está sendo substituída, e quem responde por ela depois? Automatizar uma decisão não transfere a responsabilidade por ela. Se a resposta não nomear uma pessoa ou um comitê, o projeto está criando um vazio de accountability.
Execução
- Quem, do nosso time, precisa dedicar tempo a isso, e quantas horas por semana? O custo mais subestimado de projeto de tecnologia é a atenção dos gestores da operação. Se o plano não declara essas horas, ele já está atrasado no dia da aprovação.
- Quem defende este projeto tem incentivo financeiro na sua aprovação? Não é acusação, é higiene de governança. Fornecedor que revende licença, integrador que fatura por hora e área interna medida por entrega de projeto têm interesses legítimos, mas não neutros. Se a única avaliação técnica disponível vem de quem vende, você não tem contraditório, tem proposta comercial com aparência de parecer.
Como usar isto na prática
Envie as doze perguntas a quem vai apresentar, antes da reunião. O objetivo não é constranger ninguém em público, é fazer o trabalho subir de qualidade antes de consumir o tempo do conselho. Um bom proponente agradece a lista. Um proponente que reclama dela acabou de responder à pergunta 12.
Um projeto de IA que responde bem a estas doze perguntas raramente falha por motivo técnico. E um projeto que não responde raramente falha por motivo técnico também: falha porque nunca foi um projeto, foi uma intenção.
Se três ou mais respostas exigirem um "vamos levantar e retornar", isso não significa que o projeto é ruim. Significa que a decisão está sendo tomada cedo demais, e que o que falta é diagnóstico, não coragem.
Este documento é livre para circular
Você pode encaminhar, imprimir, adaptar ao seu comitê e usar sem citar a fonte. Se quiser, conduzimos essa conversa junto com a sua diretoria em uma sessão de 90 minutos, sem custo e sem apresentação institucional.
Agendar a sessão de 90 minutos