Manifesto

1. A odisseia que ninguém escolheu

Todo servidor público conhece essa história, ainda que com outros nomes.

Um projeto de tecnologia nasce com apoio da alta administração. Ganha comitê, cronograma, orçamento. Atravessa a primeira troca de gestão ferido, mas vivo — a nova direção "reavalia prioridades". Na segunda troca, o patrocinador original já não está mais lá, e o projeto vira linha de planilha que ninguém defende em reunião. Na terceira, sobra o esqueleto: uma licitação executada pela metade, um sistema que atende a um processo que já mudou, uma equipe que aprendeu a não se apegar.

Inovar no setor público é uma verdadeira odisseia — uma travessia longa, cheia de naufrágios, em que quase nada do que embarcou chega ao destino. A diferença é que ninguém escolheu embarcar nela. Ela é consequência de um desenho institucional, e desenhos institucionais podem ser mudados.

Este manifesto é sobre esse desenho: por que ele falha, o que já está acontecendo à sua revelia dentro de todo órgão público, e qual é a alternativa.

2. O diagnóstico em três camadas

2.1 A descontinuidade política mata primeiro os maiores

Órgãos públicos — especialmente no Poder Executivo, onde a alta administração tem forte determinação política — trocam de direção em ciclos curtos. Cada troca reordena prioridades. Isso não é patologia: é característica do regime democrático e não vai desaparecer.

O problema é que o modelo dominante de inovação pública aposta tudo contra essa característica. Megaprojetos centralizados, de ciclo longo, dependentes de patrocínio contínuo da cúpula, são exatamente o tipo de iniciativa que uma troca de gestão interrompe. Quanto maior o projeto, maior a superfície de exposição à descontinuidade — e maior o desperdício quando ele cai.

2.2 O silo sobrecarregado: uma falha de matemática, não de competência

Some-se a isso um segundo elemento: na maioria dos órgãos, um único departamento de tecnologia é, ao mesmo tempo, o operador de toda a infraestrutura, o sustentador de todos os sistemas legados, o executor de todas as demandas de manutenção — e, ainda, o único canal legítimo de inovação.

É preciso dizer com clareza o que este diagnóstico não afirma: não se trata de incompetência, desinteresse ou má vontade dos departamentos de tecnologia. Trata-se de aritmética institucional. Um departamento com equipe finita e fila infinita precisa priorizar; ao priorizar, tudo o que não é urgente e sistêmico espera; e a inovação da ponta — pequena, local, específica demais para competir com o sistema crítico que caiu ontem — espera para sempre. O silo não é hermético por escolha de quem está dentro dele. É hermético porque o desenho o obriga a se defender da própria fila.

2.3 O talento não está onde o desenho supõe

A terceira camada é a que o desenho tradicional mais ignora: conhecimento técnico não é monopólio do departamento de tecnologia. Existem servidores com formação e capacidade técnica reais espalhados por toda a organização — nas unidades finalísticas, nas áreas-meio, na ponta. E esses servidores têm algo que nenhuma equipe central terá: eles vivem o processo. Conhecem a dor no detalhe, testam a solução no dia seguinte, corrigem no outro.

O desenho atual desperdiça esse ativo duas vezes: primeiro ao não dar a esses servidores canal legítimo de construção; depois ao entregar-lhes, anos mais tarde, soluções desenhadas longe do processo real — que eles serão os primeiros a contornar.

3. O sintoma que já existe: desobediência criativa

Aqui está o fato que qualquer diagnóstico honesto precisa encarar: a inovação descentralizada já acontece no seu órgão. Hoje.

Bons servidores, com excelentes intenções, diante de dores concretas e de um canal oficial que não responde, criam suas próprias soluções: planilhas com macros que viram sistemas críticos de fato, ferramentas pagas do próprio bolso, automações montadas em contas pessoais, dados institucionais processados em serviços que a organização desconhece. O mercado chama esse fenômeno de Shadow IT — e, na sua versão mais recente e mais arriscada, Shadow AI.

Este manifesto propõe outro nome, que descreve melhor a natureza do fenômeno: desobediência criativa. Desobediência, porque contorna o canal formal. Criativa, porque não nasce de má-fé — nasce da combinação entre compromisso com o serviço público e desespero com o gargalo. O servidor que monta a automação por fora não está sabotando a instituição; está tentando entregá-la melhor, pelo único caminho que encontrou aberto.

Chamar isso de crime é errar o alvo. Mas romantizar também seria um erro — e este projeto não o comete. A desobediência criativa nas sombras é um problema real e grave: opera sem controle de risco, sem segurança da informação, sem base legal para tratamento de dados pessoais, sem continuidade quando o servidor-autor se remove, sem que a organização sequer saiba que depende dela. O risco existe, é institucional, e alguém responderá por ele — provavelmente sem jamais ter tido a chance de governá-lo.

A conclusão do diagnóstico é esta: a escolha institucional nunca foi entre ter ou não ter desobediência criativa. É entre deixá-la nas sombras ou dar a ela um canal.

4. Por que a proibição falha

Diante do fenômeno, a resposta institucional intuitiva é apertar o controle: bloquear ferramentas, proibir por circular, ameaçar por corregedoria. É a resposta errada, e falha por um mecanismo simples:

A proibição não elimina o comportamento — elimina a visibilidade sobre ele.

A dor da ponta continua existindo. O talento da ponta continua existindo. O canal oficial continua sem vazão. Proibida, a solução informal não desaparece: fica mais escondida, mais pessoal, mais improvisada — e o risco migra exatamente para onde ninguém pode governá-lo. A organização troca um risco visível e endereçável por um risco invisível e sem dono.

Há ainda um efeito secundário: a proibição pune seletivamente os servidores mais comprometidos — os que se importavam o bastante para tentar resolver — e ensina a todos os demais que a iniciativa é um passivo. Nenhuma organização inova depois de institucionalizar essa lição.

Mais controle central sobre um gargalo não desfaz o gargalo. Apenas o torna oficial.

5. A tese: inovar pelas bordas

A alternativa deste projeto inverte o desenho, sem abrir mão da governança:

As unidades da organização — as bordas — ganham autonomia para identificar dores, modelar seus processos e desenvolver MVPs locais. O departamento central de tecnologia muda de papel: deixa de ser o executor único da inovação e passa a ser o guardião de padrões, segurança e governança — e o operador de um rito de admissibilidade que decide, com critérios públicos, prazo de resposta e revisão humana obrigatória, o destino de cada projeto.

Um MVP aprovado tem três destinos possíveis: acoplamento ao ecossistema integral do órgão, autorização local para operar apenas na unidade que o criou, ou compartilhamento federado com outras unidades, via catálogo homologado.

E aqui entra a ponte que fecha o diagnóstico: o modelo federado não responde apenas ao gargalo — responde também à descontinuidade política da seção 2.1. Projetos pequenos, locais, de custo próximo de zero e com dono na ponta têm uma propriedade que nenhum megaprojeto centralizado tem: sobrevivem à troca de gestão. Não dependem de patrocínio da cúpula para existir; dependem de continuar resolvendo a dor de quem os usa todo dia. A direção muda, a prioridade muda — e a solução da ponta continua rodando, porque quem a mantém é quem precisa dela. A resiliência não vem de blindagem política; vem de arquitetura.

A inovação deixa de ser um transatlântico que precisa atravessar três gestões inteiro — e passa a ser uma frota de embarcações pequenas, das quais nenhuma, sozinha, é grande o bastante para naufragar o conjunto.

5.5 Liberdade com trilhos

Autonomia nas bordas não é anarquia institucionalizada. O modelo só funciona — e só é defensável perante controle interno, tribunais de contas e autoridade de proteção de dados — porque a liberdade das bordas corre sobre quatro trilhos, definidos antes do primeiro piloto:

1. Governança definida. Papéis, responsabilidades e alçadas de decisão são explícitos em cada fase — quem assina o quê está documentado antes de alguém precisar assinar. A arquitetura do modelo e a matriz de responsabilidade vivem em 02-modelo/.
2. Stack elegível justificada. As bordas não usam qualquer ferramenta: usam componentes de uma stack previamente qualificada quanto a segurança, licenciamento e risco regulatório — com critérios públicos que cada órgão pode adaptar. Os critérios de elegibilidade e a stack de referência vivem em 04-tecnico/.
3. Padrões de integração. Projetos cujo destino seja o acoplamento ao ecossistema integral do órgão atendem a padrões de interoperabilidade definidos pelo departamento central — condição para que a frota de soluções locais não vire arquipélago. Os padrões integram os critérios de admissibilidade.
4. Segurança como critério de admissão, não como auditoria póstuma. Segurança da informação e proteção de dados pessoais não são verificadas depois que o projeto cresceu: são requisitos do portão de entrada, verificáveis por checklist. O rito, o checklist mínimo e a camada LGPD vivem em 03-admissibilidade/.

O manifesto promete os trilhos; os documentos referenciados os constroem. Quem quiser adaptar o modelo ao seu órgão adapta os trilhos — não os remove.

6. O que o departamento central ganha

Se você chefia um departamento de tecnologia e leu até aqui com desconfiança, esta seção é sua — e o argumento é pragmático, não idealista.

Você ganha vazão. Toda demanda que uma borda resolve localmente, dentro dos trilhos, é uma demanda que sai da sua fila sem passar pela sua equipe. O modelo não distribui o seu trabalho: distribui o trabalho que hoje se acumula na sua porta sem que você tenha como atendê-lo.

Você ganha visibilidade sobre um risco que hoje já é seu. A desobediência criativa da seção 3 já existe no seu órgão — e, quando algo quebrar, a pergunta "onde estava a TI?" chegará à sua mesa de qualquer forma. O rito de admissibilidade transforma um passivo invisível em portfólio governado: você passa a saber o que roda, onde roda, com quais dados e sob responsabilidade de quem.

Você ganha proteção, não exposição. A matriz de responsabilidade existe precisamente para que o risco seja de quem o assume em cada fase — a unidade responde pelo que pilota, o central responde pelos padrões e pelo portão. Aderir ao modelo não significa assinar pelo que a ponta fizer; significa deixar de responder informalmente por tudo o que a ponta já faz sem você saber.

Você ganha um papel melhor. Executor único de fila infinita é o pior cargo da administração pública: cobrado por tudo, capaz de entregar uma fração. Guardião de padrões, operador do portão e exportador de metodologia é um papel com autoridade real — o departamento deixa de competir com as bordas em execução e passa a ser a instância que define como se executa.

O modelo não pede que o departamento central abra mão de controle. Pede que troque um controle nominal — que a realidade já contorna todos os dias — por um controle efetivo sobre o que importa: padrões, segurança e o portão de entrada.

7. Convite

Este manifesto fixa o vocabulário e a tese. O restante do repositório constrói o modelo:

• 02-modelo/ — a arquitetura federada, as fases de maturidade e a matriz de responsabilidade;
• 03-admissibilidade/ — o coração operacional: o rito, o checklist mínimo e a camada LGPD;
• 04-tecnico/ — a camada habilitadora, incluindo os critérios de elegibilidade da stack e a stack de referência;
• 05-templates/ — os artefatos prontos para preencher;
• 06-casos/ — os casos reais, que crescem com a comunidade.

Este modelo nasce aberto porque a dor que enfrenta não é de um órgão — é um padrão do setor público brasileiro. Ele está em construção e quer ser criticado: se você é servidor, gestor, pesquisador ou alguém que vive esse problema, forke, adapte, discorde por escrito. A desobediência criativa que este projeto defende começa, coerentemente, por ele mesmo — este texto não pede permissão para existir; pede colaboração para melhorar.