Pular para o conteúdo
AtalaIA

Manual

5. Cada módulo: para que serve, como usar, exemplos, limites

Cada módulo tem um selo de estado, para não gerar expectativa errada:

M1 — Gabinete no Telegram — PREVISTO

Para que serve: dar ao prefeito e a cada secretaria um bot próprio no Telegram, com resumo diário, perguntas em linguagem natural e botões de aprovação (itens 3 e 4). Como vai funcionar: um bot por gabinete, cadastro de quem pode falar com cada bot, respostas restritas aos dados daquela pasta. Limites: nunca vai misturar dados de pastas diferentes; nunca vai enviar nada para fora sem aprovação. Quem aprova a saída: a pessoa com cargo no gabinete correspondente, pelos botões do item 4.

M2 — Assessor jurídico (Themis) — PREVISTO

Para que serve: revisar decretos, portarias, minutas de edital, contratos, aditivos e respostas a órgãos de controle, apontando riscos por gravidade (alta, média, regular) com a lei e o artigo citados. Como vai funcionar: a base de leis (item M15) vai alimentar as citações; a saída é sempre chamada de "subsídio à procuradoria", nunca de "parecer". Exemplo do tipo de achado que vai gerar: algo como "prazo de publicação do edital abaixo do mínimo legal" — sempre com a lei e o artigo exatos conferidos na base no momento do achado, nunca um número de artigo genérico. Limites: nunca vai se chamar de parecer jurídico; nunca vai citar artigo sem conferir o texto vigente na base (norma revogada é sinalizada). Quem aprova a saída: a procuradoria. É ela quem decide o que vira parecer oficial; a Themis só prepara o material de apoio.

M3 — Sala de ensaio / oposição simulada (Tribuna) — PREVISTO

Para que serve: simular, antes de publicar um ato, as perguntas que um vereador, a imprensa, o Ministério Público ou o Tribunal de Contas fariam — para achar a falha antes que ela apareça de fora. Como vai funcionar: no mínimo três rodadas, com perspectivas diferentes (política, controle externo, imprensa), organizadas em três colunas: o que a oposição diria, o que já está documentado, o que corrigir antes. Limites: o conteúdo é sempre interno do gabinete — nunca é publicado, nem mostrado a quem não é do gabinete. Quem aprova a saída: não há saída externa neste módulo (é uso interno). A decisão de corrigir ou não o ato continua sendo do secretário ou do prefeito.

M4 — Radar de recursos — PREVISTO

Para que serve: encontrar programas federais e estaduais com edital aberto, emendas parlamentares disponíveis, e valores que o município pagou a mais e pode recuperar (por exemplo, faturas de energia). Como vai funcionar: cada oportunidade vai aparecer com prazo, exigência, documento necessário e o próximo passo, sempre com fonte. Limites: o desenho, previsto e nada construído, separaria economia de despesa (que poderia ser remunerada por percentual, via contrato de eficiência, previsto) de captação de recurso novo (que não seria remunerada por percentual do valor captado, previsto) — e, também previsto, verbas vinculadas como educação e saúde nunca pagariam esse tipo de honorário. Quem aprova a saída: a decisão de usar ou não uma oportunidade encontrada é sempre do gestor responsável pela pasta; o Radar só vai apontar e organizar a informação, não agir por conta própria.

M5 — Secretária de e-mail (Escriba) — PREVISTO

Para que serve: organizar a caixa de e-mail de cada gabinete: ler, classificar por prioridade e prazo, agrupar assuntos repetidos e preparar uma resposta com base nos próprios documentos da prefeitura. Como vai funcionar: todo e-mail vai passar pelos estados recebido → classificado → rascunho → aguardando aprovação → aprovado → enviado (ou rejeitado); nunca existe um salto direto para "enviado". Limites: nunca vai enviar nada sem aprovação; e-mails sensíveis (ameaça, imprensa, órgão de controle) serão sempre marcados como tal antes de qualquer rascunho. Quem aprova a saída: quem responde pela caixa daquele gabinete, pelos botões do item 4.

M6 — Projetos de lei (Relator) — PREVISTO

Para que serve: ajudar a transformar um tema em minuta de lei — ementa, artigos, justificativa — já conferindo se o município pode legislar sobre aquilo, se a iniciativa é do prefeito ou de vereador, e o impacto no orçamento. Limites: também vai apontar quando o tema cabe melhor num decreto do que numa lei; nunca vai declarar uma minuta "pronta para votação" sem essa conferência. Quem aprova a saída: o prefeito ou o secretário responsável, antes de a minuta seguir para a Câmara ou para publicação como decreto.

M7 — Prazos e limites / vigia fiscal (Sentinela) — PREVISTO

Para que serve: o desenho, previsto e nada construído hoje, acompanharia limites como o teto de gasto com pessoal, o mínimo de investimento em educação e saúde, prazos de envio ao Tribunal de Contas, vencimento de contratos e de certidões, e avisaria com antecedência (30, 15, 7 e 3 dias antes). Limites: nunca vai decidir o que fazer com o alerta — vai criar uma tarefa e avisar o gabinete responsável; a ação é sempre humana. Quem aprova a saída: não há saída externa; os alertas vão só para dentro do gabinete responsável.

M8 — Escudo do gestor (integra o DETEPOL) — PREVISTO

Para que serve: olhar os contratos vigentes como um auditor olharia — fornecedor com sanção, contrato sem publicação encontrada, aditivo perto do limite, preço fora da curva — sempre com a fonte do sinal e uma ação recomendada. Limites: nunca vai acusar; o máximo que vai dizer é "padrão compatível com X, a verificar". Quem aprova a saída: não há saída externa; os alertas vão para a controladoria e para o gestor do contrato decidirem o que fazer.

M9 — Referência de preços (Balança, integra o RefFrota) — PREVISTO

Para que serve: o desenho, previsto e nada construído hoje, diria quanto uma peça ou serviço deveria custar, comparando o preço que o setor público paga com o preço do mercado privado, para apoiar um processo de compra. Como vai funcionar: consulta por veículo/serviço, com uma referência, uma faixa de confiança e um número de protocolo para juntar ao processo. Quem aprova a saída: o setor de compras decide se usa a referência; a Balança só vai emitir o número, com fonte.

M10 — Mapa do município (Cartógrafo, integra o pacote de obras do DETEPOL) — DISPONÍVEL (dados e API; tela sem estilo final)

Para que serve: mostrar cada obra da cidade — categoria, situação, empresa, valor, prazo, aditivos e andamento. O que já existe hoje: os dados de obras de Cascavel já foram trazidos para dentro do sistema (mais de cem obras reais, vindas do pacote de obras do DETEPOL) e podem ser consultados pela API do sistema (GET /mapa/obras), com filtro por situação e categoria. Uma primeira versão de tela já lista essas obras, sem acabamento visual, sem mapa geográfico e sem página do cidadão (o mapa geográfico com pontos no mapa segue previsto — ver item 10). Sobre o percentual de andamento: hoje nenhuma fonte pública consultada traz uma medição física real de andamento de obra — o campo que traria esse número (percentual_fisico) vem sempre vazio na fonte usada hoje, e por isso nenhuma tela mostra um percentual de fato. O sistema já marca esse campo com o rótulo estimativa por padrão, para o dia em que uma fonte trouxer um número (real ou calculado): calcular esse percentual pelo prazo do contrato, quando não houver medição real, ainda é previsto, não construído — hoje o campo simplesmente fica vazio, nunca com um número inventado. Limites: obra sem localização exata mostra a precisão que a fonte realmente permite (cidade, bairro ou trecho de rua) — nunca inventa um ponto exato no mapa que a fonte não confirma. Se o pacote de obras do DETEPOL ficar indisponível, a ingestão para de atualizar e o sistema continua servindo os últimos dados confirmados, em vez de travar ou mostrar dado inventado. Quem aprova a saída: este módulo só publica dado já público (contratos e obras já divulgados); não há uma pessoa aprovando cada obra individualmente. A regra de fonte e rótulo (item 6) é a política do produto, mas ainda não existe uma verificação automática que confira, campo a campo, se toda fonte tem link testado antes de aparecer — isso é regra de desenho, ainda não um mecanismo automático (ver item 6).

M11 — Organograma vivo — DISPONÍVEL (dados e API; tela sem estilo final)

Para que serve: mostrar a prefeitura inteira como uma rede — prefeito, secretarias, procuradoria, controladoria, autarquias — com o responsável humano de cada unidade e, quando existirem, os assistentes de IA que vão atendê-la. O que já existe hoje: a estrutura de Cascavel (26 órgãos, nesta versão) já está dentro do sistema, com cada responsável rotulado como fato confirmado ou ainda a conferir (item 6 explica com exemplo real). Isso pode ser consultado pela API (GET /organograma) e por uma primeira versão de tela, sem estilo final; ainda não existe o "modo caminho do ato" (acompanhar um ato tramitando pelas unidades) nem o modo apresentação — ambos previstos. O que a versão pública mostra hoje: a API pública tem um filtro (allowlist) que só deixa passar os campos liberados de cada órgão — nome, sigla, tipo, unidade superior e agentes de IA. O nome do responsável só aparece quando aquele órgão específico for marcado, um por um, como liberado para publicação — e, nesta versão, nenhum órgão foi liberado ainda (essa liberação depende de validação do dono). Por isso, hoje, a API pública do organograma não mostra nenhum nome de responsável, mesmo para os que já são FATO. Limites: nenhum nome é tratado como confirmado sem uma fonte oficial por trás. Enquanto essa fonte não existir, o nome fica marcado como "a conferir", mesmo que seja o nome mais provável. Hoje, 4 órgãos estão FATO — e em todos os 4, sem exceção, o tipo de prova é diferente do que o produto pede originalmente: não é o decreto de nomeação, é um ato assinado pela própria pessoa no exercício do cargo. Essa mudança de critério está registrada e ainda depende de validação do dono antes de aparecer sem esse aviso numa tela pública (ver item 6). Quem aprova a saída: a promoção de um nome de "a conferir" para "confirmado" segue uma checagem própria (item 6); a liberação de um responsável para a tela pública é sempre um ato explícito, órgão por órgão, e depende da validação do dono.

M12 — Portal do cidadão — PREVISTO

Para que serve: mostrar ao cidadão, em linguagem simples, obras, preços de referência e atos da prefeitura, com busca e com a fonte de cada informação. Também vai permitir consulta pelo WhatsApp. O que já existe hoje: só um aviso de "previsto, ainda não implementado" numa página reservada para isso na primeira versão do site (ver item 10). Limites: o assistente do cidadão só vai responder com dado já publicado; o que ele não souber, vai encaminhar para a ouvidoria humana — nunca vai prometer prazo ou serviço em nome da prefeitura. Quem aprova a saída: os dados mostrados serão sempre os mesmos já publicados oficialmente; não há aprovação individual por resposta, mas a checagem de dado sensível (item 7) precisa existir antes de qualquer informação sensível poder aparecer numa tela pública.

M13 — Atas e reuniões (Cronista) — PREVISTO

Para que serve: transcrever uma reunião de gabinete (a partir de um áudio enviado ao bot), gerar a ata no formato da prefeitura, e criar as tarefas com os responsáveis identificados. Limites: a ata será sempre um rascunho até alguém do gabinete confirmar que as decisões e responsáveis anotados estão certos. Quem aprova a saída: quem participou da reunião (tipicamente quem convocou), antes de a ata ser considerada definitiva.

M14 — Escuta (ouvidoria e consultas públicas) — PREVISTO

Para que serve: ler em volume as manifestações da ouvidoria e das consultas públicas, agrupar por tema e por bairro, e mostrar o que a cidade está pedindo. Limites: nunca vai expor dado pessoal de quem fez a manifestação fora da própria ouvidoria. Quem aprova a saída: não há saída externa; os temas detectados serão encaminhados para o gabinete responsável decidir o que fazer.

M15 — Memória da prefeitura (Arquivo) — EM CONSTRUÇÃO

Para que serve: ser a base de conhecimento pesquisável da prefeitura — leis municipais, decretos, portarias, pareceres, atas, contratos — para que qualquer assistente cite o documento certo antes de responder. O que já existe hoje: a Lei Orgânica do Município de Cascavel já foi carregada nessa base (150 artigos) e já é possível buscar nela por dentro do sistema, com o texto encontrado sempre citando o artigo de origem. A busca usa um modelo de linguagem que roda no próprio servidor (sem mandar o texto da lei para nenhum serviço externo — ver item 7). Isso ainda não está acessível por nenhuma tela, bot ou pergunta direta de um usuário — é um alicerce testado, não um recurso disponível ainda. Limites: quando a mesma lei tem mais de uma redação para o mesmo artigo (por causa de emendas), o sistema tenta identificar qual é a redação vigente; onde isso ainda não está totalmente resolvido para um artigo específico, essa dúvida fica registrada para conferência da procuradoria antes de qualquer uso jurídico real desse trecho. Quem aprova a saída: não há saída externa neste módulo; ele só alimenta os outros módulos e, mais adiante, deve ser conferido pela procuradoria antes de qualquer citação jurídica sair para fora da prefeitura.

M16 — Guardião de custo — CÓDIGO APROVADO, AINDA NÃO EM USO

Situação hoje: o código deste mecanismo foi escrito e aprovado pelas duas revisões do projeto (a adversarial e a de segurança e privacidade). Nenhuma parte do produto o usa, porque nenhum assistente do produto está em produção. Os tetos diários estão vazios, porque o valor deles é uma decisão do dono ainda não tomada; com os tetos vazios, nenhum teto é conferido.

Para que serve, quando entrar em uso: anotar cada chamada a um modelo de inteligência artificial (qual modelo, quantos tokens, o valor que o provedor informa, quanto demorou, para qual caso e qual assistente) e avisar quando o valor somado no dia passar de um teto, por município, por assistente dentro de cada município, ou no total.

Como funciona o código aprovado: o valor anotado é sempre o que o próprio provedor de IA informa, junto com a natureza desse valor. No único modo ligado hoje, o plano por assinatura, esse número é um equivalente calculado pelo provedor, e não uma cobrança. No modo de API paga por uso, hoje desligado, ele seria cobrança de verdade. Ao passar de um teto, o código cria um alerta interno, uma única vez por dia para cada teto. Um teste automático impede que outro código do produto chame o provedor de IA sem passar por ele.

Limites: o código nunca inventa um valor. Se o provedor não informa o valor de uma chamada, o campo fica vazio e essa chamada não entra na soma do teto.

Quem aprova a saída: não há saída externa. O alerta fica só dentro do sistema. Levar esse aviso automaticamente até o Telegram do dono é previsto, ainda não construído.