
Tem uma cena que se repete em quase toda área de TI que eu conheço. Uma fila de pedidos que nunca anda na velocidade que o negócio queria. A TI vira uma fábrica de demanda. Entra solicitação de um lado, sai entrega do outro, e o gargalo é sempre a capacidade de quem produz. Por anos a gente tratou isso como um problema de tamanho de time.
Aí a IA entrou no ciclo e mexeu com a premissa toda. A barreira técnica caiu, eu repito isso sempre. De repente não é só o time de TI que consegue gerar uma solução. Uma área de negócio também consegue. E a primeira reação de quem olha de fora é comemorar, porque enfim a fila vai desafogar. A minha reação foi outra. Se mais gente pode gerar, a pergunta deixa de ser "quem produz?" e passa a ser "quem garante que o que foi produzido dá pra sustentar?".
Quando todo mundo pode gerar, o gargalo muda de lugar
Escrevi há pouco sobre o conceito de harness, a ideia da Birgitta Böckeler de que um agente é igual a modelo mais o arnês que envolve esse modelo. São os trilhos que limitam o que ele pode tocar e os sensores que percebem quando ele saiu da linha. Aquele texto ficou no nível do agente, de uma máquina trabalhando. Mas a mesma lógica sobe de escala.
Porque quando você democratiza a geração, não democratiza junto o critério. Uma área de negócio que monta a própria automação resolve o problema dela hoje e cria, sem querer, um artefato sem dono amanhã. Shadow IT sempre existiu. Com IA, ele ganha esteroides. Aparece solução rápida, desconectada, sem responsável formal, sem ninguém para manter quando quebrar. O ganho de velocidade de um lado vira passivo silencioso do outro.
E é aqui que a conversa sobre plataforma interna deixa de ser papo de infraestrutura e vira decisão estratégica. Se mais gente vai gerar, alguém precisa cuidar de que exista um caminho seguro por onde gerar. Esse alguém é a TI, só que num papel diferente do que ela vinha ocupando.
Curadora de capacidades, não fábrica de demanda
A virada que eu defendo é simples de enunciar e difícil de praticar. A TI deixa de ser fábrica de demanda e passa a ser curadora de capacidades. Em vez de produzir cada solução sob encomenda, ela cuida do conjunto de capacidades que outras pessoas usam para produzir com segurança, sejam desenvolvedores, áreas de negócio ou agentes.
Curar é um verbo que eu gosto porque carrega responsabilidade sem carregar gargalo. O curador de um acervo não pinta os quadros. Ele escolhe o que entra, organiza, garante a procedência e tira de circulação o que não se sustenta. Traduzindo pra TI, é cuidar de quais APIs estão homologadas, quais dados podem ser tocados, quais caminhos de implementação são recomendados e o que é proibido. A TI para de ser o pintor de cada quadro e passa a ser quem garante que a galeria inteira tem padrão.
Isso não é abdicar de controle. É mudar onde o controle mora. Em vez de revisar cada entrega no fim da fila, a TI desenha o trilho por onde as entregas passam. O controle deixa de ser um portão e vira o formato da estrada.
A plataforma interna é o harness em escala de empresa
A forma concreta dessa estrada é a plataforma interna de desenvolvimento, o IDP na sigla em inglês. E aqui eu junto as duas ideias. O IDP corporativo é a forma organizacional daquele harness que eu descrevi no nível do agente. Os mesmos dois tipos de trilho aparecem, só que agora servindo a empresa inteira.
Tem os guias, que agem antes. São o catálogo de APIs homologadas, os ambientes já segregados e os golden paths, aqueles caminhos recomendados de implementação que, em vez de viverem num documento que ninguém lê, viram modelos executáveis que a pessoa simplesmente segue. E tem os sensores, que agem depois. São a verificação automática de aderência aos padrões, a observabilidade que rastreia a origem de cada artefato e a trilha de auditoria que diz quem gerou o quê, quando e a partir de qual especificação.
Vale a mesma lei velha da cibernética que eu trouxe pro harness do agente. Quem controla um sistema precisa ter pelo menos tanta variedade quanto o sistema que controla. Uma plataforma pobre demais estrangula a geração e mata justamente o ganho que se foi buscar. Uma plataforma opaca demais mascara o que precisaria ser revisado. O desenho de um bom IDP é justamente encontrar essa variedade compatível, liberando o suficiente para a velocidade acontecer sem deixar de enxergar o que está acontecendo.
O detalhe que muda tudo é que esses controles ficam embutidos no fluxo, não pendurados como uma etapa de aprovação. O desenvolvedor não pede licença para a governança, e a área de negócio e o agente também não. Eles andam por um caminho que já é governado por construção. É o que eu chamo de governança invisível, o controle que você sente como facilidade e não como burocracia.
Governança que habilita antes, em vez de aprovar depois
Essa é a parte que costuma travar nas empresas, porque ela exige uma mudança de instinto. O instinto antigo da governança é "aprovar antes de fazer". O instinto que a era da IA pede é "permitir dentro de limites seguros". A diferença não é de rigor, é de momento. Você não relaxa o controle. Você o move para a frente da fila, embutido na plataforma, em vez de deixá-lo como pedágio no fim.
Dá pra ser proporcional ao risco, inclusive. Nas camadas de autonomia que eu já defendi, o controle é leve onde a criticidade é baixa, como numa automação departamental ou num relatório, e rigoroso onde ela é alta, como num sistema de núcleo. A plataforma é o que torna essa proporcionalidade prática, porque aplica o guardrail certo para cada tipo de solução sem exigir que um humano leia tudo. É a mesma ideia que frameworks de risco como o do NIST defendem, a de tratar risco como algo que se gerencia por desenho e não como um carimbo no final.
Quando isso funciona, acontece uma coisa que parecia contraditória. A fila desafoga e o controle aumenta ao mesmo tempo. As áreas de negócio constroem o que precisam nas camadas de menor criticidade, a TI para de ser gargalo, e mesmo assim ninguém chega em produção por fora do trilho. O atrito entre negócio e TI cai não porque alguém afrouxou, mas porque o caminho seguro virou o caminho mais fácil.
O que isso mudou no meu trabalho
Mudou a pergunta que eu faço primeiro. Antes, diante de uma demanda, eu pensava em como entregá-la. Hoje eu penso em qual capacidade aquela demanda revela, e se vale a pena curá-la na plataforma para que a próxima pessoa com o mesmo problema não precise abrir um chamado. É uma troca de horizonte, do caso único para o caminho reutilizável.
E mudou o que eu considero arquitetura de verdade. Desenhar a plataforma, escolher o que entra no catálogo, transformar um bom padrão em golden path executável, ligar a observabilidade que rastreia origem, tudo isso deixou de ser tarefa de bastidor e virou o trabalho mais alavancado que eu faço. Porque é ali que uma boa decisão para de ser minha e vira uma capacidade que a empresa inteira herda.
A barreira técnica caiu, mas cair a barreira não fez sumir o critério. Numa empresa onde qualquer um pode gerar, o que separa velocidade de bagunça é existir uma curadoria. A plataforma interna é essa curadoria feita engenharia. É o harness do tamanho da organização, a forma de dar liberdade a muita gente sem abrir mão da responsabilidade pelo todo.
Referências
- Birgitta Böckeler – Engineering an agent harness (martinfowler.com)
- CNCF – Platforms White Paper
- Google Cloud – Golden paths for engineering execution consistency
- Google Cloud – Platform engineering control mechanisms
- DORA – 2025 AI-Assisted Software Development Report (Google Cloud)
- NIST – AI Risk Management Framework
- Cory Hymel – The AI-Native Software Development Lifecycle (modelo V-Bounce), arXiv 2408.03416