O risco de comprar AI é isto virar um projeto de desenvolvimento sem fim, medido em scope e sprints e cobrado à hora. A forma de o evitar é comprar o resultado: começar por um diagnóstico pago que encontra onde vale a pena remover o trabalho, construir um ou dois sistemas num sprint de âmbito fechado, e depois mantê-los a correr, com preço ao valor e não às horas de build. Compra-se horas removidas e margem recuperada, não linhas de código. Aqui fica como estruturar isto para se manter focado.
Porque os projetos de AI derivam para trabalho de dev caro
Sem estrutura, uma iniciativa de AI desliza para o formato de um projeto de software. O scope expande, os prazos esticam, e a fatura chega à hora, o mesmo modelo de uma dev shop. Isso serve o fornecedor e raramente o comprador, porque premeia o esforço e não o resultado, e põe o risco de as coisas demorarem mais inteiramente do lado do comprador.
O problema mais fundo é que começa pela pergunta errada. Um projeto de software pergunta “o que devemos construir”. A pergunta certa para começar é “onde é que o trabalho repetitivo nos custa tempo e dinheiro, e removê-lo vale mais do que custa”. Responder a isso primeiro faz o build tornar-se pequeno, específico e delimitado. Saltar isso é pagar para construir algo que ninguém confirmou que valia a pena construir.
Os três passos
Passo 1: um diagnóstico pago
Antes de qualquer build, um trabalho curto e pago mapeia onde vive o trabalho repetitivo e quanto vale removê-lo. Termina numa lista priorizada de oportunidades, ordenadas pelo esforço de as automatizar face às horas e à margem que devolveriam. Às vezes a linha mais valiosa dessa lista é a que diz que uma dada tarefa ainda não vale a pena automatizar. O diagnóstico ser pago importa: significa que o trabalho é avaliado pelo seu próprio valor, e não oferecido para ganhar um build maior.
Passo 2: um sprint de implementação
Depois um sprint focado, uma questão de semanas em vez de um programa sem fim, com limites definidos e entrega real: um ou dois sistemas em produção. O objetivo desses limites é impedir o projeto de se tornar aquilo que devia evitar. Não se está a encomendar uma plataforma, está-se a pôr um sistema específico a trabalhar numa tarefa específica.
Passo 3: operação e evolução
Uma vez em produção, o sistema é mantido a correr e melhorado à medida que o negócio muda. As regras ajustam-se, novos tipos de documento ou de pedido acrescentam-se, os limiares mexem-se à medida que os acordos se mexem. Isto é contínuo, porque um sistema que nunca é mantido desatualiza-se, mas é manutenção de um ativo que funciona, não um build sem fim.
Cobrar o valor, não as horas
O preço segue o resultado. Em vez de uma fatura por horas de build, o modelo é uma fee que cobre o custo operacional mais uma performance fee ligada ao resultado. Isto alinha o trabalho com o que de facto se quer, horas removidas e margem recuperada, e põe parte da remuneração do fornecedor do mesmo lado do resultado do cliente. Um fornecedor a cobrar à hora ganha mais quando o projeto demora mais. Um fornecedor pago ao resultado ganha mais quando o sistema funciona e continua a funcionar.
É a mesma lógica comercial que aplicamos ao resto do negócio: uma fee base que cobre o custo operacional mais uma performance fee ligada aos KPIs acordados com o cliente. Vale a pena ser claro sobre o que “valor” significa aqui, horas de trabalho removidas, erros evitados, margem recuperada, medidos face a uma base acordada no início, e não uma promessa vaga de transformação.
Resolver isto antes de qualquer código
As perguntas que decidem se um sistema pode de facto ir para produção não costumam ser técnicas, e pertencem ao início, não ao fim. Três em particular. Onde ficam alojados os dados, e sob que condições de subcontratação. Quem pode ver e aprovar o quê. E durante quanto tempo os originais são guardados, e o que acontece quando esse prazo passa. Para trabalho confidencial ou regulado, isto significa alojamento na jurisdição certa, um contrato de subcontratação em condições, um fornecedor de modelo com retenção zero, e registo de acessos. Um sistema que trata documentos ou dados de clientes não pode ir para produção sem isto resolvido, por isso resolvê-lo primeiro poupa construir algo que depois não se pode usar.
Perguntas a fazer a um fornecedor
Uma lista curta separa um parceiro genuinamente focado no resultado de uma dev shop a vender AI. O trabalho começa por um diagnóstico, ou logo por um build? O primeiro build tem limites fechados, ou fica em aberto? O preço está ligado ao resultado, ou às horas? Onde vivem as decisões, em regras explícitas que se podem editar, ou dentro do modelo? Qual é a métrica de sucesso, e é a percentagem de trabalho feito sem intervenção em vez de uma demonstração que impressionou uma vez? E as questões de dados, alojamento e retenção estão a ser levantadas agora, ou deixadas para depois? As respostas dizem depressa se se está a comprar um resultado ou a inscrever-se num projeto.
O que se compra, no fim, é uma tarefa específica tirada a pessoas específicas, de forma fiável. Como estes sistemas são de facto construídos, e o princípio que os mantém dignos de confiança, está em sistemas de AI que fazem o trabalho repetitivo do negócio.
Perguntas frequentes
Quanto custa construir um sistema de AI?
A resposta útil não é um preço de build mas uma comparação de valor: o que o trabalho repetitivo custa hoje face ao que vale removê-lo. Com preço ao resultado, uma fee que cobre o custo operacional mais uma performance fee ligada ao resultado, em vez de uma fatura aberta por horas de build.
Como impeço um projeto de AI de se tornar um trabalho de desenvolvimento sem fim?
Começar por um diagnóstico pago, depois um sprint de âmbito fechado a entregar um ou dois sistemas em produção, depois manutenção de um ativo que funciona. Esse limite e o preço ao resultado são o que o impede de derivar para trabalho de dev sem fim.
O que deve ficar acordado antes de o desenvolvimento começar?
Onde ficam alojados os dados e sob que condições, quem pode ver e aprovar o quê, e durante quanto tempo os originais são guardados. Para trabalho confidencial, isso significa a jurisdição certa, um contrato de subcontratação, um fornecedor de modelo com retenção zero e registo de acessos, resolvidos antes do código.
Como sei se um fornecedor vende resultados e não horas?
Perguntar se começa por um diagnóstico, se o primeiro build tem limites fechados, se o preço está ligado ao resultado, onde vivem as decisões, e qual é a métrica de sucesso. Respostas focadas no resultado parecem muito diferentes de um projeto cobrado à hora.
Quer AI sem um projeto sem fim?
Começa por um diagnóstico, não por um build. Numa sessão de estratégia, encontramos onde um sistema focado se pagaria a si próprio.
