A inteligência artificial está repetindo uma história que muitas empresas já viveram
Durante anos, empresas enfrentaram um problema que começava de maneira aparentemente inofensiva: alguém de uma área de negócio precisava resolver uma dificuldade operacional e criava uma planilha no Excel.
No início, era uma solução simples. Uma macro automatizava um cálculo, consolidava informações ou eliminava algumas tarefas repetitivas.
O resultado era tão positivo que outras pessoas começavam a utilizar aquela planilha.
Com o tempo, ela ganhava novas funcionalidades, passava a concentrar informações importantes e, sem que ninguém percebesse, transformava-se em um sistema essencial para a operação.
Até que chegava o dia em que algo parava de funcionar.
O funcionário que havia criado a solução já não estava na empresa. Ninguém entendia completamente as fórmulas, as macros ou as dependências daquele arquivo.
O que começou como uma iniciativa de produtividade havia se transformado em um risco operacional.
Agora estamos diante de uma situação semelhante, mas com um potencial de impacto muito maior.
A inteligência artificial permite que profissionais sem formação em programação desenvolvam aplicações, automatizem processos, criem interfaces e integrem serviços utilizando comandos em linguagem natural.
É o fenômeno que ganhou força com o chamado vibe coding.
E aqui existe uma questão que considero fundamental para qualquer gestor:
Estamos democratizando o desenvolvimento de software ou criando uma nova geração de sistemas corporativos que ninguém conseguirá manter?
A resposta depende menos da capacidade da inteligência artificial e muito mais da maneira como as empresas estão incorporando essa tecnologia.
O que acontece quando funcionários começam a criar sistemas com IA?
Funcionários criando sistemas com IA representam uma evolução do desenvolvimento descentralizado de software. Profissionais de diferentes áreas conseguem construir aplicações com ferramentas de inteligência artificial, mesmo sem conhecimento aprofundado de programação.
Esse movimento pode acelerar a inovação, reduzir tarefas manuais e resolver problemas que antes ficavam meses aguardando prioridade no departamento de TI.
Entretanto, quando essas aplicações passam a utilizar dados corporativos, executar processos críticos ou atender múltiplos usuários sem supervisão técnica, surgem riscos relacionados à segurança, manutenção, integração, escalabilidade e continuidade operacional.
O problema não está em permitir que funcionários criem soluções com IA. Está em transformar essas soluções em sistemas corporativos sem os controles necessários para sustentá-las.
Essa distinção precisa fazer parte da estratégia de tecnologia das empresas.
Das macros do Excel ao vibe coding: a história está se repetindo
A comparação entre as macros do Excel e os sistemas criados com inteligência artificial não é apenas uma analogia tecnológica.
Ela revela um padrão de comportamento organizacional.
Quando a área de TI não consegue atender todas as demandas na velocidade desejada, as áreas de negócio procuram alternativas.
Isso aconteceu com as planilhas eletrônicas, com ferramentas de automação, com plataformas low-code e no-code e agora acontece com a inteligência artificial generativa.
A diferença está na complexidade das soluções que cada tecnologia permite construir.
Antes, uma planilha automatizava tarefas. Agora, a IA pode criar aplicações inteiras
Uma macro do Excel normalmente automatizava atividades dentro de um ambiente relativamente limitado.
Com ferramentas de desenvolvimento assistido por IA, um funcionário pode criar uma aplicação web com autenticação, banco de dados, integrações externas e funcionalidades de negócio.
Essa mudança amplia enormemente o alcance das soluções.
Imagine um analista financeiro que utiliza IA para desenvolver uma ferramenta de aprovação de despesas.
Inicialmente, a aplicação atende apenas sua equipe.
Depois, outras áreas começam a utilizá-la. Novas funcionalidades são adicionadas, regras de aprovação são implementadas e informações financeiras passam a circular pelo sistema.
Em determinado momento, a empresa já depende daquela aplicação para executar um processo importante.
Mas algumas perguntas podem continuar sem resposta:
-
Quem é responsável pela segurança dos dados?
-
Como as permissões dos usuários são controladas?
-
Existe documentação das regras de negócio?
-
Quem corrige problemas quando a aplicação apresenta falhas?
-
Como garantir que uma alteração não comprometa processos existentes?
-
O que acontece se o funcionário responsável deixar a empresa?
Essas perguntas não tornam a iniciativa inválida.
Elas mostram que criar um software e assumir a responsabilidade por sua operação são atividades diferentes.
A inteligência artificial reduziu a barreira de criação, não a complexidade do software
Essa é uma das principais interpretações equivocadas que observo nas discussões sobre desenvolvimento com IA.
Existe uma percepção crescente de que, se uma aplicação pode ser criada em poucas horas, ela também será simples de manter.
Não necessariamente.
A inteligência artificial pode acelerar a geração de código, mas não elimina automaticamente questões como arquitetura, segurança, testes, observabilidade, qualidade dos dados e evolução das regras de negócio.
Na prática, a facilidade de criação pode esconder uma complexidade que só aparece quando a aplicação começa a crescer.
E quanto maior a dependência operacional, maior o custo de descobrir essas limitações tarde demais.
O novo shadow IT: sistemas que nascem fora da governança corporativa
O conceito de shadow IT descreve o uso de tecnologias, aplicações e serviços sem o conhecimento ou a aprovação das estruturas responsáveis pela tecnologia da informação.
Historicamente, esse fenômeno estava associado à contratação de softwares, utilização de serviços em nuvem e criação de ferramentas paralelas.
Com a inteligência artificial, o cenário evoluiu.
Agora, os próprios funcionários podem desenvolver aplicações completas fora dos processos tradicionais de engenharia de software.
Isso cria uma nova dimensão para o shadow IT.
Por que os sistemas criados com IA podem representar um risco maior?
Porque a empresa pode não perceber que uma aplicação experimental se tornou parte de sua infraestrutura operacional.
Um sistema desenvolvido informalmente pode começar a armazenar informações de clientes, consumir APIs corporativas, utilizar credenciais privilegiadas ou executar operações em sistemas internos.
Se não houver visibilidade sobre essas aplicações, a organização também perde capacidade de avaliar riscos.
Considere um exemplo hipotético.
Um profissional comercial desenvolve com IA uma aplicação para consolidar oportunidades de vendas.
A ferramenta funciona bem e rapidamente ganha adesão.
Para facilitar o trabalho, o funcionário conecta a aplicação ao CRM, importa dados de clientes e cria rotinas automáticas de atualização.
A empresa agora possui uma nova aplicação manipulando informações comerciais relevantes.
Mas quem valida o tratamento desses dados? Quem monitora acessos? Quem garante que as integrações continuarão funcionando após uma atualização do CRM?
A ausência dessas respostas representa um problema de governança.
Uma aplicação não precisa ter sido desenvolvida oficialmente pela TI para gerar riscos corporativos. Basta que ela passe a participar de um processo importante.
Os cinco riscos mais relevantes dos sistemas corporativos criados com IA
Ao avaliar o uso de inteligência artificial no desenvolvimento de aplicações internas, considero essencial separar ganhos de produtividade dos riscos de sustentação.
Nem toda aplicação criada com IA apresenta problemas. O risco aumenta quando sua importância operacional cresce sem que a maturidade técnica acompanhe essa evolução.
1. Segurança e privacidade dos dados corporativos
Um software pode funcionar corretamente do ponto de vista do usuário e ainda apresentar vulnerabilidades importantes.
Autenticação, autorização, proteção de dados, gerenciamento de credenciais e validação de entradas exigem cuidados específicos.
Imagine uma aplicação interna que utiliza informações de clientes e permite consultar históricos de atendimento.
Se os controles de acesso não forem implementados corretamente, usuários podem visualizar informações que não deveriam estar disponíveis para eles.
Dependendo dos dados tratados e do contexto, esse cenário também pode gerar obrigações relacionadas à Lei Geral de Proteção de Dados (LGPD).
A IA pode auxiliar na implementação de mecanismos de segurança, mas o fato de gerar código não garante que todos os controles estejam corretos.
O impacto empresarial pode envolver exposição de informações, interrupções operacionais, custos de correção e danos à confiança de clientes.
2. Dependência do funcionário que criou a aplicação
Assim como acontecia com as macros do Excel, o conhecimento sobre uma aplicação pode ficar concentrado em uma única pessoa.
A diferença é que agora esse funcionário pode ter criado uma solução com banco de dados, integrações e dezenas de regras de negócio.
Sem documentação, versionamento e responsáveis definidos, a continuidade do sistema fica vulnerável.
Se o profissional mudar de função ou deixar a empresa, a organização pode descobrir que depende de uma aplicação que ninguém compreende completamente.
Nesse cenário, o problema não é apenas encontrar alguém que consiga ler o código.
É recuperar o entendimento das decisões, regras e dependências que sustentam o funcionamento do software.
3. Arquitetura construída sem planejamento
Muitas aplicações começam pequenas e crescem conforme surgem novas necessidades.
Uma ferramenta criada para atender cinco usuários pode passar a atender cinquenta ou quinhentos.
Uma integração inicialmente simples pode se transformar em uma cadeia de dependências entre sistemas.
Sem uma arquitetura adequada, cada funcionalidade adicional pode aumentar o acoplamento e dificultar futuras mudanças.
O resultado pode ser uma aplicação que funciona no presente, mas se torna progressivamente mais cara de evoluir.
O risco não está necessariamente na arquitetura inicial ser simples, mas em não revisá-la quando a importância e a complexidade da aplicação aumentam.
4. Ausência de testes e validação contínua
A facilidade de gerar novas funcionalidades pode incentivar mudanças rápidas, sem uma estratégia consistente de testes.
Isso aumenta a possibilidade de regressões, falhas de integração e comportamentos inesperados.
Imagine uma aplicação que calcula comissões comerciais.
Uma alteração solicitada para atender uma nova regra pode modificar involuntariamente o cálculo de contratos antigos.
Sem testes automatizados e validação das regras de negócio, o problema pode ser identificado apenas depois de produzir resultados incorretos.
Em aplicações que executam processos financeiros, comerciais ou operacionais, essas falhas podem gerar consequências relevantes.
5. Falta de governança sobre o ciclo de vida do software
Todo sistema corporativo precisa de responsáveis.
Alguém deve decidir sobre prioridades, acompanhar incidentes, administrar acessos, planejar atualizações e avaliar riscos.
Quando uma aplicação surge informalmente, essas responsabilidades podem simplesmente não existir.
O software continua sendo utilizado, mas ninguém possui uma visão completa de sua importância para a empresa.
Isso dificulta decisões sobre investimento, manutenção, substituição e continuidade.
E um software sem responsável definido pode se transformar em um passivo tecnológico.
O maior erro seria proibir os funcionários de desenvolver com IA
Diante desses riscos, algumas empresas podem considerar restringir completamente a criação de aplicações pelas áreas de negócio.
Na minha visão, essa seria uma resposta equivocada.
A inteligência artificial está tornando o desenvolvimento de software mais acessível. Esse movimento pode representar uma oportunidade importante para empresas que precisam acelerar processos e reduzir gargalos operacionais.
O desafio não é impedir a inovação descentralizada.
É estabelecer critérios para que ela aconteça de maneira segura.
Nem toda aplicação precisa seguir o mesmo processo
Uma ferramenta individual para organizar tarefas não precisa necessariamente passar pelos mesmos controles de um sistema financeiro utilizado por toda a empresa.
A governança deve ser proporcional ao risco.
Uma forma prática de organizar esse processo é classificar as aplicações conforme seu impacto.
Aplicações de uso individual
São ferramentas utilizadas por um único profissional para organizar informações, automatizar atividades pessoais ou melhorar sua produtividade.
Quando não manipulam dados sensíveis, não executam operações críticas e não possuem integrações relevantes, podem funcionar com diretrizes básicas de segurança e uso de IA.
O importante é estabelecer limites claros sobre quais informações podem ser utilizadas e quais serviços são permitidos.
Aplicações departamentais
São soluções utilizadas por uma equipe ou departamento para executar atividades internas.
Nesse estágio, já considero importante manter um inventário das aplicações, identificar responsáveis e avaliar o tratamento dos dados.
Também é necessário compreender quais processos dependem da ferramenta e quais seriam as consequências de uma indisponibilidade.
Aplicações corporativas
São sistemas compartilhados entre diferentes departamentos ou integrados a outras plataformas empresariais.
Aqui, a necessidade de engenharia de software se torna mais evidente.
Arquitetura, documentação, testes, controle de acesso, versionamento e processos de suporte devem fazer parte da avaliação.
A empresa precisa garantir que a aplicação possa evoluir sem comprometer outros processos.
Aplicações críticas para o negócio
São sistemas cuja indisponibilidade, falha ou comprometimento pode provocar impactos financeiros, operacionais, legais ou reputacionais relevantes.
Nesse cenário, considero indispensável uma abordagem formal de engenharia, segurança, monitoramento e continuidade operacional.
A aplicação precisa ter responsáveis definidos, processos de manutenção e critérios claros de qualidade.
A criticidade de um sistema deve ser determinada pelo impacto que ele pode causar ao negócio, não pela ferramenta utilizada para desenvolvê-lo.
Essa classificação ajuda a preservar a velocidade de inovação sem ignorar os riscos.
O objetivo não deve ser burocratizar qualquer iniciativa.
Deve ser identificar o momento em que um experimento precisa se transformar em um produto de software administrado profissionalmente.
Como criar uma governança para sistemas desenvolvidos com inteligência artificial
Acredito que as empresas precisam começar a tratar o desenvolvimento assistido por IA como uma capacidade organizacional.
Isso significa definir políticas, responsabilidades e processos adequados ao novo cenário.
Criar um inventário das aplicações desenvolvidas internamente
O primeiro passo é conhecer o que está sendo construído.
As empresas precisam identificar quais aplicações foram criadas pelas áreas de negócio, quais dados utilizam, quais sistemas acessam e quem responde por elas.
Sem essa visibilidade, qualquer iniciativa de governança fica limitada.
Estabelecer critérios para entrada em produção
Uma aplicação experimental pode ser útil para validar uma ideia.
Mas, antes de atender processos relevantes, precisa passar por avaliações proporcionais ao risco, incluindo segurança, qualidade, integração e continuidade.
Isso permite que a inovação avance sem transformar protótipos em dependências críticas por acidente.
Definir responsáveis técnicos e de negócio
O responsável de negócio deve compreender a finalidade da aplicação, suas regras e seus resultados esperados.
Já a responsabilidade técnica envolve garantir condições adequadas de operação, manutenção e evolução.
Essas duas dimensões precisam estar conectadas.
Incorporar práticas de engenharia de software
Versionamento de código, testes automatizados, documentação, revisão de segurança, monitoramento e processos de implantação continuam relevantes.
A inteligência artificial pode acelerar parte dessas atividades.
Mas não elimina a necessidade de executá-las.
Criar um caminho para profissionalizar aplicações que deram certo
Nem toda solução desenvolvida por funcionários deve ser descartada ou reconstruída.
Algumas podem representar excelentes oportunidades de inovação.
Quando uma aplicação demonstra valor e passa a ganhar importância, a empresa deve avaliar sua arquitetura, seus riscos e sua capacidade de evolução.
Dependendo do cenário, pode ser suficiente melhorar a estrutura existente. Em outros casos, será necessário refatorar componentes ou reconstruir partes da solução.
A decisão precisa considerar custo, risco e valor de negócio.
Quando um sistema criado com IA precisa de uma software house?
Uma aplicação desenvolvida com IA pode precisar de uma software house quando deixa de ser um experimento e passa a sustentar processos relevantes, integrar sistemas corporativos, manipular dados sensíveis ou exigir disponibilidade, segurança e evolução contínua.
Nessas situações, o principal desafio deixa de ser gerar funcionalidades rapidamente.
Passa a ser garantir que o software continue confiável conforme a operação cresce.
O papel das software houses está mudando
Durante muito tempo, o desenvolvimento de software esteve fortemente associado à capacidade de transformar requisitos em código.
A inteligência artificial está acelerando essa etapa.
Isso não significa que a engenharia de software perdeu relevância.
Significa que o valor está cada vez mais associado à capacidade de tomar boas decisões técnicas e conectar tecnologia aos objetivos empresariais.
Arquitetura, integração, segurança, qualidade, escalabilidade e sustentação passam a ter importância ainda maior.
Na Plathanus, é dessa perspectiva que considero necessário olhar para o avanço da IA.
O desenvolvimento de software não deve ser avaliado apenas pela velocidade com que uma aplicação fica pronta.
Ele precisa ser avaliado pela capacidade de gerar resultados sustentáveis para o negócio.
Código pode estar se tornando mais rápido e barato de produzir. Mas decisões técnicas equivocadas continuam custando caro.
O que CEOs, CIOs e CTOs deveriam fazer agora?
Se eu estivesse estruturando uma política corporativa para aplicações desenvolvidas com inteligência artificial, começaria por cinco decisões.
1. Mapear as aplicações existentes
Antes de criar novas regras, é necessário descobrir o que já está sendo utilizado.
Isso inclui aplicações desenvolvidas por funcionários, ferramentas de automação, integrações independentes e soluções experimentais que passaram a atender processos operacionais.
O objetivo é compreender o tamanho da dependência tecnológica que existe fora dos sistemas oficialmente administrados.
2. Definir limites de autonomia
As empresas precisam estabelecer quais tipos de aplicações podem ser desenvolvidos diretamente pelas áreas de negócio.
Essa autonomia deve considerar os dados utilizados, a complexidade das integrações e o impacto potencial de falhas.
A intenção não é impedir a experimentação, mas definir em quais situações a participação da TI se torna necessária.
3. Classificar os riscos
Nem todas as aplicações representam o mesmo nível de exposição.
Uma ferramenta individual de produtividade possui características diferentes de uma aplicação responsável por aprovações financeiras.
Por isso, a classificação deve considerar criticidade operacional, dados utilizados, integrações, quantidade de usuários e consequências de indisponibilidade.
4. Criar um processo de evolução
Quando um protótipo demonstra valor, a empresa precisa ter um caminho para transformá-lo em uma solução sustentável.
Isso pode envolver avaliação de arquitetura, revisão de segurança, documentação, implementação de testes e definição de responsáveis.
Em alguns casos, será necessário realizar ajustes pontuais. Em outros, uma modernização mais ampla.
O importante é não permitir que o crescimento da aplicação aconteça sem acompanhamento técnico.
5. Medir resultados e sustentabilidade
A produtividade inicial é apenas uma parte do valor entregue por um software.
Também é necessário acompanhar custos de manutenção, frequência de incidentes, esforço de evolução e dependências operacionais.
Uma aplicação que economiza tempo no início, mas exige correções constantes, pode não representar o ganho esperado.
A verdadeira eficiência deve ser medida ao longo do ciclo de vida do software, não apenas no momento de sua criação.
O futuro não será definido por quem consegue criar mais sistemas com IA
Acredito que estamos entrando em uma fase em que desenvolver aplicações será cada vez mais acessível.
Profissionais de diferentes áreas terão condições de transformar ideias em protótipos funcionais com uma velocidade que, até pouco tempo atrás, parecia improvável.
Isso representa uma evolução importante.
Mas existe uma diferença entre criar uma solução que funciona hoje e construir uma aplicação preparada para continuar funcionando daqui a alguns anos.
As macros do Excel deixaram uma lição importante para muitas empresas: soluções individuais podem se tornar dependências corporativas sem que exista uma decisão formal para isso.
A inteligência artificial amplia essa possibilidade.
Agora, em vez de planilhas complexas, podemos ter aplicações completas, com bancos de dados, integrações e processos automatizados.
Por isso, considero que a pergunta mais importante não é se devemos permitir que funcionários desenvolvam sistemas com IA.
A pergunta é:
Como garantir que a velocidade de criação não se transforme em uma dívida tecnológica que a empresa terá de pagar no futuro?
As organizações que encontrarem esse equilíbrio terão melhores condições de aproveitar a inteligência artificial de forma consistente.
Porque o verdadeiro diferencial competitivo não estará apenas na capacidade de criar software.
Estará na capacidade de transformar software em resultados confiáveis, seguros e sustentáveis.
Como a Plathanus pode ajudar sua empresa
Na Plathanus, enxergamos a engenharia de software como parte da estratégia de crescimento e eficiência das empresas.
Se sua organização já utiliza inteligência artificial para criar aplicações internas, ou está avaliando como ampliar essa prática, vale analisar se essas soluções possuem a estrutura necessária para crescer com segurança.
Podemos apoiar a avaliação técnica, a evolução de aplicações existentes, a integração com sistemas corporativos e o desenvolvimento de soluções sob medida.
Antes que um protótipo se transforme em um sistema crítico sem governança, vale entender quais riscos precisam ser tratados.
Entre em contato com a Plathanus e converse com nosso time sobre como estruturar uma estratégia de desenvolvimento de software que combine velocidade, segurança e sustentabilidade.
Perguntas frequentes (FAQ)
É seguro permitir que funcionários desenvolvam sistemas com inteligência artificial?
Pode ser seguro, desde que existam políticas claras, controles proporcionais ao risco e avaliação técnica para aplicações que utilizam dados corporativos ou executam processos importantes. A segurança depende da arquitetura, dos acessos, do tratamento dos dados e dos processos de manutenção, não apenas da ferramenta de IA utilizada.
O que é vibe coding e quais são seus riscos para empresas?
Vibe coding é uma abordagem de desenvolvimento na qual a inteligência artificial gera código a partir de instruções em linguagem natural, muitas vezes com pouca análise direta do código produzido. Em empresas, os riscos surgem quando aplicações são utilizadas sem revisão técnica, testes, documentação ou controles de segurança adequados.
Qual é a relação entre shadow IT e inteligência artificial?
A inteligência artificial facilita a criação de aplicações fora dos processos tradicionais da TI. Quando essas soluções são desenvolvidas ou utilizadas sem visibilidade e governança corporativa, passam a integrar o universo de shadow IT, criando riscos de segurança, manutenção e conformidade.
Sistemas criados com IA precisam de desenvolvedores profissionais?
Nem sempre. Protótipos e ferramentas simples podem ser desenvolvidos por profissionais de diferentes áreas. Entretanto, aplicações críticas, com integrações complexas, dados sensíveis ou exigências de disponibilidade, precisam de engenharia, revisão e sustentação técnica compatíveis com seu risco.
Quando uma empresa deve profissionalizar um sistema criado por funcionários?
Quando a aplicação passa a atender múltiplos usuários, sustentar processos importantes, armazenar dados relevantes ou exigir continuidade operacional. Nesse momento, é recomendável avaliar arquitetura, segurança, documentação, testes, responsabilidades e custos de manutenção.
Como evitar que aplicações criadas com IA se tornem dívidas técnicas?
A empresa deve manter um inventário das aplicações, estabelecer critérios de risco, definir responsáveis, adotar práticas de engenharia e criar um processo para avaliar e evoluir soluções que se tornam importantes. A prevenção começa antes de uma aplicação experimental assumir funções críticas.
Palavra-chave principal: funcionários criando sistemas com IA
Palavras-chave secundárias: vibe coding, shadow IT, governança de IA, sistemas criados com inteligência artificial, desenvolvimento de software com IA, dívida técnica, software corporativo.
