O avanço recente dos modelos de linguagem e das ferramentas de desenvolvimento assistido por IA está mudando não só a forma de escrever software, mas também quem consegue iniciar software útil dentro das empresas.

Durante muito tempo, sistemas corporativos nasceram dentro de um circuito relativamente estável: demanda formal, priorização, time dedicado, validação longa e liberação institucional. Esse circuito continua existindo. O que mudou é que ele deixou de ser a única origem possível.

Hoje, alguém muito próximo de um gargalo operacional consegue montar em poucos dias um protótipo que integra etapas de fluxo, organiza informação dispersa, reduz retrabalho ou automatiza uma tarefa que a instituição já conhecia, mas não tinha conseguido tratar no tempo da operação.

O ponto mais importante aqui não é que IA passou a escrever código.

O ponto mais importante é que o conhecimento do problema passou a gerar solução de forma muito mais rápida.

Se a operação já consegue construir protótipos úteis, qual passa a ser o verdadeiro problema das empresas?

O principal atrito não é técnico. É de governança.

O custo de experimentação caiu, a velocidade de prototipagem aumentou e a distância entre quem sofre o problema e quem tenta resolvê-lo diminuiu drasticamente. Isso faz com que ferramentas úteis comecem a ser usadas antes de qualquer avaliação mais formal de arquitetura, segurança, compliance ou integração institucional.

Quando isso acontece, o conflito com TI e Segurança da Informação não é acidente. É consequência direta do modelo atual de governança.

Durante décadas, construir software interno exigia uma combinação relativamente rara de tempo, conhecimento técnico e acesso a infraestrutura. Mesmo problemas simples podiam ficar anos sem solução porque dependiam de orçamento, fila de prioridade e capacidade de desenvolvimento central.

Agora, boa parte desse custo inicial caiu.

Profissionais assistenciais, administrativos ou operacionais já conseguem construir protótipos funcionais com ferramentas de IA generativa, automação e desenvolvimento assistido, mesmo sem formação tradicional em engenharia de software. Nem sempre esses protótipos são bons. Nem sempre devem escalar. Mas muitos já resolvem algo real logo na primeira versão.

Quando resolvem, começam a circular.

E começam a circular por um motivo pragmático: melhoraram algum pedaço do trabalho diário.

É comum tratar a reação de TI e Segurança da Informação como se fosse simples resistência cultural. Essa leitura é fraca.

Essas áreas foram estruturadas para um cenário em que sistemas eram menos numerosos, mais centralizados e mais previsíveis. Sua função continua sendo proteger dados, garantir estabilidade, controlar acesso, assegurar conformidade regulatória e reduzir risco operacional.

Sob essa lógica, aplicações criadas rapidamente, fora do fluxo tradicional e muitas vezes próximas de dados sensíveis parecem exatamente o tipo de problema que os processos dessas áreas foram desenhados para conter.

A resistência inicial, portanto, faz sentido dentro do modelo vigente.

O que tende a ficar inviável é imaginar que esse movimento possa ser bloqueado de forma pura e duradoura.

O custo de criar caiu demais.

Mais do que isso: em muitos casos, a aderência local de quem conhece o trabalho diário passa a ser maior do que a de plataformas corporativas mais lentas, mais genéricas e mais distantes da fricção concreta.

Quando o protótipo nasce perto da operação, ele costuma incorporar nuance de fluxo que projetos mais centralizados demoram mais para enxergar. Isso não elimina seus riscos. Mas explica por que ele pode gerar valor antes de gerar legitimidade institucional.

Se esse diagnóstico estiver correto, o novo desafio das empresas deixa de ser impedir que a operação crie software.

Passa a ser absorver isso com segurança.

Isso muda o papel de TI e SI. Em vez de atuarem apenas como barreira de entrada, essas áreas passam a ter um papel mais útil quando funcionam como estruturas de:

Em outras palavras, a governança deixa de ser apenas autorização prévia de criação e passa a ser também capacidade de absorção posterior.

O modelo mais plausível daqui para frente não parece ser o retorno à centralização completa, nem a celebração ingênua de software paralelo.

Parece ser um modelo híbrido.

Nele, protótipos continuam nascendo perto da operação, impulsionados por ferramentas de IA e pela queda do custo de experimentação. Ao mesmo tempo, TI e SI entram como camadas de validação, endurecimento, integração, observabilidade e escalabilidade.

Isso não elimina conflito. Mas desloca o conflito para um terreno mais produtivo.

Em vez de discutir apenas se alguém podia ou não iniciar a solução, a empresa passa a discutir como transformar um protótipo útil em componente institucionalmente aceitável.

Essa transição expõe um descompasso importante.

Durante muito tempo, governança foi desenhada para controlar um processo de criação relativamente lento.

Agora, a criação ficou muito mais rápida.

Quando a governança continua operando com a mesma cadência anterior, o resultado é previsível: surgem soluções úteis antes da estrutura formal conseguir reagir a elas.

É aí que o debate costuma piorar. De um lado, aparece a tentação de romantizar qualquer protótipo rápido como inovação inevitável. De outro, aparece a tentação de tratar qualquer criação fora do fluxo central como ameaça a ser imediatamente bloqueada.

Nenhuma das duas posições ajuda muito.

O principal efeito organizacional da IA sobre software interno talvez não seja automatizar código. Seja redistribuir a capacidade de iniciar software útil.

Se isso já está acontecendo, o problema das empresas deixa de ser proteger um monopólio central de criação.

Passa a ser construir mecanismos maduros para validar, endurecer e institucionalizar aquilo que nasce perto da operação sem abrir mão de arquitetura, segurança e governança.