Construa por Último: Uma Regra de Compras para Ferramentas de Governança de IA: Adote Primeiro, Apoie o que Pode Ser Adquirido, Construa Somente Quando uma Busca Documentada Falhou

A missão se encaixa e o esforço afundado não justificam nada. A única coisa que justifica construir é uma busca que falhou e foi documentada.

O Reflexo

A sequência é familiar o suficiente para ser recitada. Uma lacuna de governança surge durante uma auditoria. Nada no mercado se encaixa perfeitamente. Alguém já construiu algo adjacente antes. Aparece uma planilha, depois um script, depois um aplicativo interno com dois mantenedores e nenhum roteiro. Dezoito meses depois, ele sustenta uma obrigação de conformidade e um dos mantenedores saiu.

Ninguém tomou uma decisão ruim. Cada passo foi localmente razoável, e o agregado é uma dependência não financiada em um caminho de controle regulamentado. A regra que eu estabeleço para mim mesmo é: adotar primeiro, apoiar o que pode ser legitimamente obtido externamente, construir como último recurso. Forte de propósito, porque o reflexo que ele combate é forte e a falha que ele previne surge anos após a decisão que a causou.

Os Três Portões

A regra só é útil como perguntas que alguém responde antes do primeiro commit.

Isso existe? Não "um produto resolve isso exatamente", pois isso quase sempre é não e é a pergunta errada. Algo resolve 70%, sendo que o restante é processo e não software? A maioria das lacunas de governança é respondida por uma ferramenta existente mais uma decisão que ninguém quer tomar, e construir nos permite evitar essa decisão. Busque produtos comerciais, projetos de código aberto, organismos de padrões com implementações de referência e o item adjacente construído para um problema vizinho. Este último contém a maioria das respostas perdidas.

Podemos apoiar? Uma ferramenta que não podemos operar não é uma resposta. Este portão pergunta sobre licenciamento que sobrevive ao nosso caso de uso, manutenção que não depende de um voluntário ascendente, tratamento de dados que atende às nossas obrigações e um caminho de saída. Uma dependência que não podemos abandonar é aquela que precificamos mal. Apoiar também significa contribuir: financiar ou corrigir os últimos 30% geralmente supera a construção de 100%, e deixa a capacidade onde outra pessoa a mantém.

A lacuna sobrevive ao contato? Após os dois primeiros portões, reformule-a em uma frase. Muitas vezes, ela encolheu para algo que não é um problema de software: uma política nunca escrita, um limite que ninguém estabeleceria, uma função ausente no organograma. Esses não se fecham com a construção. Construir sobre eles produz uma ferramenta que codifica a decisão não tomada e torna mais difícil revisitá-la.

Missão se Encaixa Não Justifica Nada

Dois argumentos surgem aqui, e ambos precisam ser recusados claramente.

O primeiro é o encaixe na missão. "Isto é central para o que fazemos, então devemos ser donos disso." Ser dono e construir são decisões diferentes, e a segunda não decorre da primeira. Uma empresa cuja missão é o julgamento jurídico não escreve, portanto, seu próprio sistema de gerenciamento de documentos. A competência central defende o controle da interface e dos dados, não a autoria da implementação.

O segundo é o esforço afundado. "Já dedicamos quatro meses a isso." Quatro meses nos dizem sobre o passado e nada sobre os próximos quatro. Parece que dizem, e é por isso que isso precisa de uma regra e não de um julgamento no momento.

Ambos são do tipo razoável que sobrevive a uma reunião, razão pela qual os portões são respondidos por escrito primeiro.

Documentando a Busca

Os portões valem pouco sozinhos. O que torna a regra composta é o artefato: um registro do que foi buscado, o que foi encontrado e por que não se encaixou. Seis meses depois, alguém encontra a mesma lacuna de outra direção e, sem o registro, faz a mesma busca mal e constrói uma segunda ferramenta.

Um registro utilizável tem quatro partes e cabe em uma página:

A lacuna, em uma frase, como declarada antes da busca.
O que foi avaliado, incluindo ferramentas adjacentes consideradas e deixadas de lado.
Por que cada uma falhou em um portão, nomeando qual portão.
A data, porque isso caduca.

Esta última parte é mais importante do que parece: uma decisão de construir justificada por uma busca de dois anos atrás não é justificada por nada.

Nós Aplicamos Isso em Nós Mesmos

Prefiro declarar a versão estranha à elogiosa. Cada componente do nosso portfólio existe porque uma capacidade estava faltando no trabalho real e a busca não foi suficiente. Essa é exatamente a alegação que um fundador faz com muita facilidade, então a regra se aplica mais fortemente a nós. O teste de adotar primeiro não fica mais fácil porque nós já escrevemos a coisa. Onde um padrão ou projeto externo pode cobrir parte do que construímos, o movimento certo é adotá-lo e aposentar o nosso. Algumas dessas decisões ainda estão abertas.

Quando Construir Está Certo

A regra não é "nunca construir". Construir é por último e feito deliberadamente, quando a busca falhou no registro, a lacuna sobreviveu ao terceiro portão e a construção tem um dono, um orçamento e um estado final. O que isso previne é o outro caminho, onde chegamos a uma dependência interna personalizada sem nunca termos decidido isso.

Na próxima vez que uma lacuna de governança aparecer, o primeiro artefato não deve ser um protótipo. Deve ser a página dizendo o que já existe.

Pronto para saber quais lacunas de capacidade são reais antes de construir para elas? Saiba mais sobre PAICE para organizações ou faça uma avaliação individual para ver isso em primeira mão.

Leitura Recomendada

Governança AI Collaboration - Onde a política termina e a ferramenta começa
Construindo Seu Kit de Ferramentas de IA Collaboration - Montando a partir do que existe
Construindo o Caso de Negócio para IA Collaboration Avaliação - O que a aquisição precisa
Guia Executivo para Prontidão em IA Collaboration - O que vale a pena ser dono