O piloto funcionou. Essa nunca foi a questão. A demo foi bem, a acurácia era defensável, os usuários gostaram, e depois ele passou cinco meses numa fila e silenciosamente parou de ser mencionado. Ninguém o matou. Ele expirou. Se você já viu isso acontecer duas vezes, provavelmente concluiu que a organização é disfuncional, e quero argumentar por uma explicação menos satisfatória: o piloto foi escopado para responder a uma pergunta que ninguém estava travado esperando.

A demo responde "o modelo consegue fazer isso?". A organização nunca teve dúvida sobre isso. O que ela não sabe é quem é responsável quando o modelo erra, para onde vão os dados, o que acontece na renovação, e quem assina. Essas perguntas têm donos, esses donos têm filas, e nenhum deles viu seu piloto chegando.

Procurement não é o vilão

A leitura de engenharia é que procurement é um imposto: pessoas avessas a risco desacelerando um valor óbvio. Essa leitura é confortável e majoritariamente errada, e sustentá-la é caro, porque você não consegue desenhar em torno de um processo que decidiu que é ilegítimo.

Procurement é a função que pergunta se a empresa consegue conviver com essa coisa por três anos. Toda pergunta que ela faz codifica um incidente anterior, geralmente um que é anterior a você. O fornecedor que foi adquirido e triplicou o preço. A ferramenta com uma violação de dados que ninguém conseguiu escopar porque não havia inventário do que ela continha. A renovação que se auto-executou para um produto que duas pessoas usavam. Não são hipóteses para quem está revisando seu formulário. São o motivo pelo qual o formulário existe.

O atrito é real, e parte dele é genuinamente desperdício. Mas a resposta correta a um portão lento é entrar nele cedo com boas respostas, não torcer para que ele não esteja lá.

Os quatro portões que realmente travam as coisas

Revisão de segurança

O questionário não é realmente sobre a configuração TLS do seu fornecedor. Ele está tentando estabelecer o que a ferramenta consegue alcançar e o que acontece quando ela se comporta mal. Ferramentas de IA pontuam mal aqui por uma razão estrutural: elas pedem acesso de leitura amplo para serem úteis. "Ler todo documento no tenant para poder responder perguntas sobre eles" é um requisito de produto legítimo e um pedido de acesso genuinamente alarmante, e os dois fatos são verdadeiros ao mesmo tempo.

O piloto que passa por esse portão é o que consegue declarar seu modelo de permissão numa frase. Somente leitura por padrão, com acesso de escrita como uma etapa separada e explicitamente consentida, é uma revisão fundamentalmente mais fácil do que um único escopo que faz as duas coisas, não importa quão bom seja o log de auditoria. Se a ferramenta não consegue descrever seu raio de impacto, a segurança vai descobrir, devagar, por escrito, ao longo de seis semanas.

Contratos de processamento de dados

É aqui que a maioria dos pilotos de IA de fato morre, e morre numa pergunta: nossos dados são usados para treinar seus modelos?

Se a resposta leva um parágrafo, a resposta é funcionalmente sim, e o jurídico vai ler assim. O DPA precisa de subprocessadores nomeados, retenção declarada em dias, exclusão na rescisão especificada, e a pergunta de treino respondida numa cláusula só. Toda ressalva adiciona um ciclo de revisão, e ciclos de revisão levam duas semanas cada porque quem está lendo tem outras quarenta coisas para fazer.

O problema que se acumula é que fornecedores de IA trocam de subprocessador com mais frequência do que a cadência do DPA presume. Uma troca de provedor de modelo é uma emenda. Ninguém planeja a emenda.

A camada específica de IA

Nova, de mais ou menos no ano passado, e aplicada de forma inconsistente: uma revisão interna de IA pedindo uma classificação de risco, uma descrição de supervisão humana, e evidência de que você conhece suas obrigações. Onde ela existe, costuma ser o portão mais rápido, porque é nova o suficiente para o dono ter tempo. Onde ainda não existe, suas perguntas são feitas mesmo assim, ad hoc, por quem quer que tenha percebido, no pior momento possível. Conforme as obrigações de transparência de 2 de agosto chegam, espere que esse portão se formalize em mais lugares, e espere que isso seja uma melhoria, porque um portão definido com fila vale mais que uma objeção indefinida levantada num comitê diretor.

Propriedade do orçamento

O matador mais silencioso. Um piloto roda no orçamento discricionário de alguém ou num tier gratuito. Produção precisa de um item de linha, um centro de custo, e um dono que vai defendê-lo no próximo ciclo. Se o patrocinador do piloto é um engenheiro entusiasmado em vez de alguém com orçamento, não há caminho do piloto para a produção independente dos resultados, e isso costuma ser visível no primeiro dia para qualquer um que olhar.

Por que o próprio piloto arma a armadilha

Pilotos são desenhados para serem fáceis de começar, e as coisas que os tornam fáceis de começar são as que os tornam impossíveis de terminar. Dados sintéticos ou anonimizados, para que a pergunta do DPA nunca surja. Um tenant de sandbox, para que o modelo de acesso nunca seja revisado. Um tier gratuito, para que nenhum dono de orçamento seja necessário. Um time entusiasmado, para que nenhuma pergunta de responsabilidade seja feita.

Cada uma dessas escolhas adia um portão em vez de passar por ele. Depois o piloto tem sucesso e todos os quatro chegam de uma vez, no momento em que todo mundo acredita que a parte difícil acabou e o trabalho restante é papelada. A organização não andou um milímetro em direção à produção, e agora também está decepcionada.

Escope pilotos para os portões

A correção não é mais governança no piloto. É escolher um piloto cujo sucesso responda às perguntas que travam o deployment.

  • Use dados reais num tenant real, no menor escopo possível. Um departamento, dados de produção, modelo de permissão real. Um piloto com dados reais e três usuários passa por mais portões do que um piloto com dados sintéticos e trezentos, porque produz respostas em vez de promessas.
  • Faça o DPA ser lido na semana um, não na semana doze. Mande para o jurídico antes da demo. Se a cláusula de treino for um problema, você aprendeu o resultado pelo preço de um e-mail em vez de um trimestre.
  • Nomeie o dono do orçamento antes de começar. Se ninguém for assumir o item de linha, rode o piloto como pesquisa e diga isso em voz alta. É uma coisa legítima de se fazer. O que não é legítimo é chamar isso de caminho para produção.
  • Escreva as respostas de segurança antes do questionário chegar. Modelo de permissão, fluxo de dados, subprocessadores, retenção, exclusão. Uma página. A maior parte do atraso de seis semanas é ida e volta, e ida e volta é latência, não trabalho.
  • Rode os portões em paralelo com a construção. Eles são limitados por fila, não por esforço. Nada no jurídico lendo um DPA exige que seu código já exista.

Isso torna os pilotos mais lentos para começar e dramaticamente mais prováveis de terminar, e essa troca só fica óbvia depois que você já perdeu um. O contra-argumento é real: sobrecarregar trabalho exploratório com portões mata a exploração, e alguns pilotos merecem ser experimentos baratos que morrem rápido. Tudo bem. Só seja honesto sobre qual tipo você está rodando, porque a falha que estou descrevendo não é um experimento ruim. É um bom experimento que todo mundo confundiu com um plano de deployment.

A conclusão

Pilotos de IA raramente morrem de acurácia. Eles morrem porque a demo respondeu a uma pergunta que ninguém estava travado esperando, enquanto a revisão de segurança, o DPA, a camada de IA, e a propriedade do orçamento ficaram intocados até o fim e chegaram juntos. Procurement não é obstrução; é a organização perguntando se consegue conviver com isso por três anos, e essas perguntas estão vindo quer você as tenha agendado ou não. Escope o piloto para que ter sucesso signifique passar por um portão. Os times que lançam não são os com melhores modelos. São os que começaram o relógio de doze semanas na semana um.

Leia isto a seguir

A versão de infraestrutura dessa história, por que migrações de plataforma travam nas mesmas filas, está nas notas de campo em ercan.cloud. O hub está em ercanermis.com.