Está claro que sua empresa precisa acelerar a adoção da IA. O que está menos claro é como fazer isso sem que seja um vale-tudo. Afinal, seus melhores funcionários não estão esperando que você estabeleça padrões; eles já estão usando IA ativamente. Sim, seus desenvolvedores estão inserindo código no ChatGPT, independentemente de qualquer política que você esteja planejando. Pesquisas recentes sugerem que os desenvolvedores estão adotando a IA mais rápido do que seus líderes conseguem padronizá-la; essa lacuna, e não a velocidade do desenvolvedor, é o risco real.
Isto cria o que Phil Fersht chama de “lacuna de velocidade da IA”: o abismo entre as equipes que adotam freneticamente a IA para vencer e a liderança central hesitando sobre o risco de começar. Parece familiar? É novamente uma “TI sombra”, mas desta vez é alimentada pelos seus dados.
Escrevi sobre os custos ocultos da expansão tecnológica, seja a liberdade irrestrita do desenvolvedor, que levou a uma infraestrutura incontrolável, ou a atração da multicloud que se transformou em um pântano de pesadelos de interoperabilidade e custos excessivos. Quando cada desenvolvedor e cada equipe escolhe sua própria nuvem, seu próprio banco de dados ou sua própria ferramenta SaaS, você não obtém inovação – você obtém o caos.
Este pode ser o status quo, mas é uma receita para o fracasso. Qual é a alternativa?
O problema com plataformas oficiais
A tentação para uma equipe de plataforma é ver esse caos e reagir construindo um portão. “Pare! Ninguém avança até que tenhamos construído a plataforma oficial de IA empresarial.” Eles então passarão 18 meses avaliando fornecedores, padronizando em um único modelo de linguagem grande (LLM) e construindo um fluxo de trabalho monolítico e prescrito.
Boa sorte com isso.
Quando lançarem aquela verdadeira plataforma para governar a todos, ela estará irremediavelmente obsoleta. Caramba, no ritmo atual da IA, ela corre o risco de obsolescência antes da adoção. O modelo que padronizaram terá sido superado cinco vezes por alternativas mais novas, mais baratas e mais poderosas. Seus desenvolvedores, há muito frustrados, terão percorrido inteiramente a plataforma, usando seus cartões de crédito pessoais para acessar as APIs mais recentes, criando um ponto cego enorme, inseguro e não monitorado bem no coração do negócio.
Tentar construir um portão único e monolítico para IA não funcionará. A paisagem está se movendo muito rápido. As necessidades são muito diversas. O modelo que se destaca em resumir documentos legais é péssimo para escrever Python. Não se pode confiar no modelo que é ótimo para textos de marketing para projeções financeiras. Mesmo dentro da engenharia, o modelo brilhante na refatoração de Java é inútil para escrever manifestos K8s.
O problema, porém, não é o desejo para uma plataforma; é o definição de um.
De plataformas prescritas a produtos combináveis
Bryan Ross escreveu recentemente um excelente post sobre “caminhos dourados” que captura perfeitamente esse dilema. (Ele se baseia em outros argumentos anteriores para esses chamados caminhos dourados, como este no blog Platform Engineering.) Ele argumenta que precisamos mudar nosso pensamento de “portões” para “guarda-corpos”. O problema, na sua opinião, é que as equipes de plataforma muitas vezes erram o que os desenvolvedores realmente precisar.
Como escreve Ross: “A maioria das equipes de plataforma pensa em termos de ‘a plataforma’ — uma oferta única e coesa que as equipes usam ou não. Os desenvolvedores pensam em termos dos recursos de que precisam agora para o problema que estão resolvendo”. Então, como você equilibra esses interesses conflitantes? Sua sugestão: “Pensar plataforma como produto significa oferecer blocos de construção combináveis. A chave para a adoção modular é tratar sua plataforma como um produto com APIs, não como um fluxo de trabalho prescrito”.
Ross resolve o problema. Agora, o que fazemos sobre isso?
Em vez de pedir a uma comissão que escolha o modelo, as equipes de plataforma devem, em vez disso, construir um conjunto de serviços ou APIs combináveis que canalizem a velocidade do desenvolvedor. Na prática, tudo isso começa com um padrão de interface de fato. Um padrão de fato é a API estilo OpenAI, agora suportada por vários back-ends (por exemplo, vLLM). Isto não significa que você abençoa um único provedor; isso significa que você dá às equipes um contrato comum, provavelmente liderado por um gateway de API, para que elas possam trocar de mecanismo sem reescrever sua pilha.
Esse gateway também é o lugar perfeito para impor resultados estruturados como regra. “Apenas me dê um texto” é bom para uma demonstração, mas não funciona em produção. Se você deseja integrações duráveis, padronize as saídas restritas por JSON aplicadas pelo esquema. A maioria das pilhas modernas suporta isso, e é a diferença entre uma demonstração fofa e um sistema pronto para produção.
Esse mesmo gateway se torna seu plano de controle para observabilidade e custos. Não invente um novo “registro de IA”; em vez disso, use algo como as convenções semânticas emergentes de genAI do OpenTelemetry para que prompts, IDs de modelo, tokens, latência e custo sejam rastreáveis nas mesmas ferramentas que os engenheiros de confiabilidade do site já usam. Essa visibilidade é precisamente o que permite barreiras de custo eficazes.
A base crítica de tudo isto é a governação do acesso aos dados. Esta é uma área onde você precisa ser resoluto, mantendo identidade e segredos onde já moram. Exija a recuperação de segredos em tempo de execução (sem chaves incorporadas) e unifique a autorização para o gerenciamento de identidade e acesso de sua empresa. O objetivo é minimizar novas superfícies de ataque, absorvendo a IA em padrões reforçados e existentes.
Por fim, permita saídas do caminho dourado, mas com obrigações: registro extra, uma revisão de segurança direcionada e orçamentos mais apertados. Como Ross recomenda, inclua a substituição na plataforma, como um sinalizador “prosseguir com justificativa”. Registre essas exceções, revise-as semanalmente e use esses dados para evoluir as proteções.
Plataforma como produto, não polícia
Por que essa postura de “guarda-corpos sobre portões” funciona tão bem para a IA? Porque o alvo móvel da IA torna a previsão centralizada uma estratégia perdedora. Os comitês não podem aprovar o que ainda não entendem, e os fornecedores mudarão de acordo com o seu documento de padrões de qualquer maneira. Os guardrails abrem espaço para aprender fazendo com segurança. Isto é o que as empresas inteligentes já aprenderam com a adoção da nuvem: as restrições produtivas superam o controle imaginário.
Como argumentei, limitar cuidadosamente as escolhas permite que os desenvolvedores se concentrem na inovação, em vez do código colado que se torna necessário depois que as equipes de desenvolvimento constroem em diversas direções. Isso é duplamente verdadeiro com a IA. A carga cognitiva de seleção de modelos, higiene imediata, padrões de recuperação e gerenciamento de custos é alta; o trabalho da equipe da plataforma é baixá-lo.
Os caminhos dourados permitem que você avance na velocidade de seus melhores desenvolvedores, ao mesmo tempo que protege a empresa das piores surpresas. Mais importante ainda, esta abordagem vai ao encontro da sua organização onde ela estiver. Os indivíduos que já estão experimentando IA obtêm uma rampa de acesso segura e rápida que não parece um posto de controle. As equipes de plataforma obtêm a conformidade, a visibilidade e os controles de custos necessários sem se sentirem frustradas pelo processo. E a liderança obtém aquilo de que as empresas estão famintas neste momento: uma forma de transformar mil experiências desconexas num programa coerente, medido e governável.
