Citizen development em IA é o programa formal e sancionado que dá a colaboradores sem background técnico acesso a ferramentas de IA aprovadas — com trilha de capacitação, sandbox e processo de aprovação por risco — para construir suas próprias automações, agentes e aplicações internas. É o contraponto proativo ao shadow AI: em vez de proibir o uso informal de IA por áreas de negócio (o que, como este blog já mostrou, não funciona), a empresa canaliza essa mesma energia para um caminho visível, seguro e governado. Este guia é para quem lidera T&D, enablement ou tecnologia e precisa decidir entre bloquear a criatividade das áreas ou estruturar um programa que a torne segura — com os quatro pilares que sustentam um programa de citizen development que não vira um novo passivo de governança.
O que é citizen development em IA, exatamente
Citizen development é o termo, cunhado originalmente pela Gartner na década de 2010 para plataformas low-code/no-code, para colaboradores de área de negócio — sem formação em engenharia de software — que constroem suas próprias ferramentas digitais. A onda de IA generativa e agêntica ampliou o escopo: hoje, um "citizen developer" não monta só um formulário ou um painel — ele configura um agente que lê e-mail, resume contrato ou automatiza uma etapa de atendimento, usando linguagem natural em vez de código.
A diferença entre citizen development com governança e o uso informal que já acontece em toda empresa não é a atividade em si — é a estrutura ao redor dela. Os quatro elementos que separam um programa formal de uma zona cinzenta são:
- Ferramentas aprovadas, com contrato de tratamento de dados e log de uso sob controle da empresa — não a conta pessoal do colaborador.
- Trilha de capacitação obrigatória antes de liberar acesso, não depois de um incidente.
- Classificação de risco de cada projeto, para saber o que pode ficar com o colaborador e o que precisa de revisão técnica.
- Processo de aprovação proporcional a esse risco — leve para o de baixo impacto, rigoroso para o que toca dado sensível ou sistema em produção.
Sem esses quatro elementos, o que a empresa tem não é um programa — é exatamente o problema que shadow AI descreve: uso real acontecendo fora do radar.
Por que colaboradores recorrem a ferramentas de IA por conta própria
A motivação, na esmagadora maioria dos casos, não é contornar a regra — é entregar mais rápido diante de uma fila de TI que não acompanha a demanda. O Brasil forma cerca de 53 mil profissionais de tecnologia por ano contra uma demanda estimada em 159 mil, segundo dados citados no guia sobre déficit de talentos em IA no Brasil — a lacuna entre o que a área de negócio precisa e o que a TI central consegue entregar é estrutural, não um problema de prioridade mal definida.
Quando a alternativa aprovada não existe ou demora semanas, o colaborador de vendas, RH ou operações resolve sozinho: assina uma ferramenta com o próprio cartão, cola dado da empresa num chatbot público ou monta um fluxo de automação numa plataforma que ninguém revisou. A pesquisa mais recente da Gartner com 302 líderes de cibersegurança (coletada entre março e maio de 2025) confirma a escala do problema: 69% das organizações suspeitam ou já têm evidência de colaboradores usando ferramentas de IA generativa pública proibidas pela empresa, e a Gartner projeta que mais de 40% das empresas vão sofrer um incidente de segurança ou conformidade ligado a esse uso não sancionado até 2030 — segundo o analista Arun Chandrasekaran, em release da própria Gartner citado pelo iMasters e pela Infosecurity Magazine.
Tratar isso como falha de caráter individual ignora a causa. Tratar como sinal de demanda represada é o que abre espaço para a alternativa deste artigo.
Citizen development sancionado vs. shadow AI: mesma energia, dois caminhos
| Shadow AI (uso informal) | Citizen development com governança | |
|---|---|---|
| Ferramenta | Conta pessoal, sem contrato de dados | Ferramenta corporativa aprovada, com DPA |
| Visibilidade da empresa | Nenhuma — descoberta só após incidente | Registro central do que existe e quem é dono |
| Capacitação prévia | Nenhuma | Trilha obrigatória antes do acesso |
| Classificação de risco | Inexistente | Todo projeto é classificado antes de escalar |
| Caminho para produção | Vira dependência operacional sem revisão | Gate formal de aprovação por nível de risco |
| Postura da empresa | Reativa (detectar e bloquear) | Proativa (canalizar e capacitar) |
A Gartner já projetava, em 2021 — antes da onda de IA generativa —, que 80% dos produtos e serviços de tecnologia seriam construídos por profissionais fora da TI até 2024, segundo o analista Rajesh Kandaswamy, em cobertura da VentureBeat. A tendência já vinha antes da IA generativa acelerar tudo; a pergunta que resta para a empresa não é se isso vai acontecer, é se vai acontecer visível ou escondido.
Os quatro pilares de um programa de citizen development em IA
Pilar 1 — Ferramentas aprovadas e ambiente sandbox
O ponto de partida é dar ao colaborador uma ferramenta tão rápida quanto a pessoal, mas com contrato de tratamento de dados, log de uso e configuração de retenção sob controle da empresa. O conceito central aqui é o sandbox: um ambiente isolado, sem acesso a dado de produção ou sistema crítico, onde o citizen developer pode experimentar e construir sem risco de causar dano real. A TechTarget resume o princípio como "autonomia com limites definidos" — o colaborador não precisa de carta branca, precisa de um espaço seguro para experimentar antes de qualquer coisa tocar produção. Para o catálogo do que costuma sair desse tipo de experimentação — formulários, painéis, trackers internos —, veja criar aplicativos sem saber programar.
Pilar 2 — Trilha de capacitação obrigatória antes do acesso
Acesso à ferramenta sem capacitação prévia é o erro mais comum de programas malfeitos. A trilha mínima precisa cobrir três coisas, na ordem: o que nunca entra num prompt (dado de cliente, segredo comercial, informação sob NDA), como reconhecer quando um projeto passou do nível "experimentação pessoal" para "precisa de revisão", e o canal formal para pedir essa revisão. É o mesmo raciocínio por trás do estágio Booster do método Flight Plan da Jetpacks — a capacitação vem antes do acesso liberado, não depois de um incidente, com a certificação Jetpack Certified marcando quem concluiu a trilha.
Pilar 3 — Classificação de risco do projeto
Nem todo projeto de citizen development carrega o mesmo risco, e tratar todos com o mesmo rigor mata a velocidade que motivou o programa. Um critério objetivo, aplicado a cada novo projeto, evita tanto o excesso de burocracia quanto a leniência perigosa:
| Nível | Critério | Onde fica |
|---|---|---|
| Baixo | Só dado próprio do colaborador, sem integração com sistema oficial, uso individual | Fica no sandbox, sem gate formal |
| Médio | Toca dado de outras pessoas ou processo compartilhado, ainda sem produção | Exige registro e revisão leve antes de expandir o uso |
| Crítico | Acessa dado sensível, decide algo com impacto em cliente ou substitui sistema oficial | Precisa de aprovação formal e, geralmente, de assumir propriedade de TI |
A TechTarget lista cinco sinais de que um projeto criado por um citizen developer precisa escalar para TI: passou a acessar dado sensível, passa a alterar registro operacional oficial, passa a enviar dado para um modelo externo, passa a afetar pessoas fora do time que o criou, ou ganhou popularidade a ponto de virar dependência de várias áreas.
Pilar 4 — Processo de aprovação e revisão por nível de risco
O gate de aprovação precisa ser proporcional ao risco classificado no pilar anterior — um processo único e pesado para tudo recria o mesmo problema que gerou o shadow AI: fila lenta demais, então o colaborador contorna. Projeto de baixo risco segue sem gate formal; de risco médio, passa por revisão leve de um responsável de área; de risco crítico, entra no fluxo formal de aprovação de TI e segurança, com prazo definido — não indefinido.
Papéis: quem é o citizen developer, quem revisa, quem patrocina
Programas maduros de citizen development, dentro ou fora de IA, adotam o modelo de fusion team da Gartner: squads mistos com representante de negócio (o citizen developer), de tecnologia (revisão técnica) e, quando o caso pede, de segurança da informação e jurídico. Organizações com esse modelo de entrega chegam a 2,5 vezes mais rápido em iniciativas de transformação digital do que estruturas puramente centralizadas em TI, segundo dados consolidados pela WeWeb. Na prática, cada projeto tem três papéis claros:
- O citizen developer — dono do problema de negócio, responsável por manter o projeto dentro do escopo aprovado e por sinalizar quando ele muda de risco.
- O revisor técnico — normalmente alguém do centro de enablement ou de TI, responsável por avaliar o projeto no momento em que ele muda de nível de risco.
- O patrocinador — a liderança da área que assume a responsabilidade formal pelo projeto quando ele sai do sandbox.
A estrutura organizacional completa que sustenta esses papéis — se a empresa já tem escala para um centro dedicado — está detalhada em centro de enablement em IA. Fornecedores como Microsoft formalizam esse mesmo desenho em seus próprios frameworks — o CoE Starter Kit do Power Platform, por exemplo, é o modelo de referência do mercado para "proteger, medir e capacitar" citizen developers em escala, com case documentado da Deutsche Bahn aplicando o modelo em produção (via Microsoft Learn).
Como o programa se conecta à governança maior da empresa
Um programa de citizen development não substitui a governança de IA já existente — ele precisa se encaixar nela. Três conexões são obrigatórias:
- Inventário centralizado. Todo projeto que sai do nível "experimentação individual" entra no inventário de sistemas de IA da empresa, para que ninguém precise descobrir sua existência por acidente. O formato recomendado está em inventário de sistemas de IA (AI-BOM).
- Classificação de dado. A trilha de capacitação do Pilar 2 precisa se apoiar na mesma lógica de classificação — o que pode ou não entrar em cada tipo de ferramenta — detalhada em governança de dados para IA.
- Política de uso formal. O programa de citizen development é, na prática, a implementação operacional da política de uso de IA da empresa para quem constrói, não só para quem usa. O modelo completo está em política de uso de IA na empresa.
Métricas de sucesso de um programa de citizen development
Um programa que não é medido não sobrevive ao primeiro corte de orçamento. Quatro métricas concentram o essencial:
- Número de projetos registrados no sandbox — o indicador de adoção real do programa.
- Percentual de projetos com dono e patrocinador claros — mede se o processo está sendo seguido, não só tolerado.
- Tempo médio de aprovação por nível de risco — se o fluxo de risco crítico leva semanas, o programa vai perder para o shadow AI de novo.
- Redução de uso não sancionado detectado em auditoria — a métrica que fecha o ciclo: o programa está de fato substituindo o comportamento informal, não só coexistindo com ele.
Erros comuns ao lançar um programa de citizen development
- Liberar o sandbox sem trilha de capacitação obrigatória — vira exatamente o shadow AI que o programa deveria substituir, só que com aprovação formal no papel.
- Um único processo de aprovação para todo nível de risco — mata a velocidade que motivou o programa; quem precisa de aprovação rápida volta para a ferramenta pessoal.
- Nenhum dono nomeado por projeto — sem patrocinador, ninguém assume responsabilidade quando o projeto cresce além do escopo original.
- Tratar o programa como projeto único, não função permanente — citizen development exige revisão contínua de ferramentas aprovadas e da própria trilha de capacitação, à medida que o mercado de IA muda.
Como a Jetpacks estrutura citizen development dentro do Flight Plan
Na Jetpacks, o programa de citizen development não é um módulo avulso — é onde o método Flight Plan (quatro estágios, cerca de duas semanas cada, por área) se conecta diretamente à realidade de cada time. No Launchpad, mapeamos o que cada área já constrói por conta própria — o inventário de partida. O Flight Plan desenha, a partir desse mapa, quais ferramentas sancionadas e qual sandbox cada área precisa. O Booster capacita o time antes de liberar o acesso, com certificação Jetpack Certified por nível de competência. O Mission Control acompanha adoção real ao longo do tempo — não só a semana do lançamento. Como parceira oficial da Replit no Brasil, a Jetpacks aplica esse mesmo desenho ao vibe coding, o tipo de citizen development mais técnico dentro da própria área de tecnologia — veja o catálogo do que dá para construir sem saber programar e como estruturar agentes de IA para não-desenvolvedores dentro desse mesmo framework. A abordagem já foi aplicada em empresas como Hypera Pharma, Volvo, BMR Medical e C12 Brasil.
FAQ
O que é citizen development?
É a prática de colaboradores sem formação técnica construírem suas próprias ferramentas digitais — formulários, painéis, automações e, mais recentemente, agentes de IA — usando plataformas low-code/no-code ou linguagem natural, em vez de depender inteiramente da equipe de TI para cada demanda.
Qual a diferença entre shadow AI e citizen development?
Shadow AI é o uso não sancionado, sem visibilidade da empresa, sem contrato de dados e sem capacitação prévia. Citizen development com governança é a mesma energia — colaborador resolvendo seu próprio problema com IA — canalizada para ferramenta aprovada, com trilha de capacitação obrigatória, classificação de risco e processo de aprovação. A atividade é parecida; a estrutura ao redor é o que muda tudo.
Como estruturar um programa de citizen development em IA na empresa?
Quatro pilares, nesta ordem: ferramentas aprovadas com sandbox isolado de produção; trilha de capacitação obrigatória antes de liberar acesso; critério objetivo de classificação de risco por projeto; e processo de aprovação proporcional a esse risco — leve para baixo impacto, rigoroso para o que toca dado sensível ou sistema em produção.
Quem pode ser um citizen developer dentro da empresa?
Em princípio, qualquer colaborador que conclua a trilha de capacitação obrigatória do programa — não é um perfil técnico específico. Na prática, tende a concentrar em quem sente mais de perto a lacuna entre demanda e capacidade da TI: comercial, RH, operações, marketing e atendimento.
Quem aprova um aplicativo ou agente criado por um citizen developer?
Depende do nível de risco classificado. Projeto de baixo risco não precisa de aprovação formal; de risco médio, passa por revisão leve de um responsável de área; de risco crítico — que toca dado sensível, decide algo com impacto em cliente ou se conecta a sistema em produção — precisa de aprovação formal de TI e segurança da informação antes de sair do sandbox.
Um programa de citizen development elimina o shadow AI por completo?
Reduz, mas não elimina sozinho — é preciso que a alternativa aprovada seja de fato tão rápida quanto a informal, senão o colaborador volta a contornar o processo. Combinar o programa com visibilidade contínua (auditoria de uso, inventário atualizado) é o que sustenta a redução no longo prazo, como detalhado em shadow AI: por que proibir não funciona.
Conclusão: canalizar em vez de proibir
A energia que hoje vira shadow AI — colaborador resolvendo seu próprio problema com a ferramenta mais acessível — não desaparece com proibição. Um programa de citizen development com governança canaliza essa mesma energia para um caminho visível: ferramenta aprovada, capacitação antes do acesso, risco classificado e aprovação proporcional a esse risco. É o caminho que transforma o que hoje é ponto cego de governança em capacidade instalada e mensurável.
Se sua empresa já vê áreas de negócio construindo suas próprias soluções com IA — sancionadas ou não — o diagnóstico gratuito da Jetpacks mapeia, em uma conversa de 30 a 45 minutos, onde essa energia já está e desenha, com o método Flight Plan, o programa de citizen development que a transforma em capacidade real, sem travar a velocidade que os colaboradores já foram buscar sozinhos.
Descubra onde a IA gera mais resultado na sua empresa.
Comece com um diagnóstico gratuito: mapa de impacto por área e o desenho de um primeiro piloto medível, sem compromisso.