Sobre o Framework SinergIA (S)
Versão: 0.90b (beta) · Data: 2026-04-11 · Autor/Responsável: Elias Cotrim
O que é o Framework SinergIA
Seção intitulada “O que é o Framework SinergIA”SinergIA é um framework de processo e governança para desenvolvimento de sistemas com uso intensivo de inteligência artificial. Ele define como trabalhar com IA — papéis, artefatos, validações, evidências e controles — não qual IA usar.
Como qualquer framework estruturado, o SinergIA não é homogêneo: diferentes partes dele exercem funções distintas. Algumas recomendam, outras exigem. Algumas descrevem o funcionamento, outras detalham a execução. Compreender essa distinção é essencial para aplicar o framework com proporcionalidade e clareza institucional.
Esta página mapeia cada componente do SinergIA segundo seis naturezas documentais, permitindo que equipes, gestores e auditores identifiquem imediatamente o grau de obrigatoriedade e a margem de adaptação de cada elemento.
Naturezas documentais
Seção intitulada “Naturezas documentais”Orientativo
Seção intitulada “Orientativo”Documento de caráter recomendatório. Apresenta boas práticas, direções, sugestões e referências que podem ser adotadas integralmente, parcialmente ou adaptadas conforme o contexto. Não impõe conformidade estrita, mas serve para apoiar decisões e melhorar a qualidade das ações.
Características: alta flexibilidade, foco em apoio e aprendizado, admite customização ampla.
Normativo
Seção intitulada “Normativo”Documento que estabelece requisitos obrigatórios, critérios mínimos ou regras que devem ser observados. Seu objetivo é padronizar comportamentos, garantir conformidade e permitir verificação objetiva de atendimento.
Características: força obrigatória, foco em conformidade, usa linguagem de dever e exigência.
Operacional
Seção intitulada “Operacional”Documento que define como a organização ou iniciativa deve funcionar na prática. Estrutura papéis, fluxos, responsabilidades, artefatos, pontos de controle e formas de interação entre áreas ou agentes. Não necessariamente descreve cada passo minucioso, mas organiza o funcionamento do modelo.
Características: foco no funcionamento cotidiano, define estrutura de execução, pode admitir ajustes locais.
Procedimental
Seção intitulada “Procedimental”Documento voltado à execução detalhada de uma atividade específica. Descreve a sequência de passos, entradas, responsáveis, validações, exceções e saídas esperadas, permitindo que a rotina seja repetida com consistência.
Características: detalhamento prático, passo a passo claro, foco em repetibilidade e padronização da execução.
Prescritivo
Seção intitulada “Prescritivo”Documento que estabelece um método definido, com baixa margem de adaptação. Determina não apenas o que deve ser alcançado, mas também como isso deve ser feito, preservando uma lógica específica de execução. Desvios podem comprometer a aderência ao método.
Características: baixa flexibilidade, método estruturado, forte direcionamento de execução.
Mandatório Fechado
Seção intitulada “Mandatório Fechado”Documento de observância integral, no qual a aderência completa ao método ou rito é condição obrigatória. Não admite flexibilização relevante, salvo exceções formalmente autorizadas. Seu uso normalmente está associado a controle rigoroso, auditoria, certificação, segurança ou integração crítica.
Características: rigidez máxima, cumprimento integral, desvio descaracteriza a conformidade.
Mapeamento do SinergIA por natureza documental
Seção intitulada “Mapeamento do SinergIA por natureza documental”🟢 Orientativo
Seção intitulada “🟢 Orientativo”Componentes que oferecem direção e sugestões, sem impor conformidade estrita:
| Componente | Localização no framework |
|---|---|
| Apêndice A — Stack de referência | O próprio framework declara: “Este apêndice é não prescritivo.” Ferramentas como GitHub Actions, LangChain e Figma são referências de mercado — a GTI decide o que adotar. |
| Documentos estruturantes opcionais | Artefatos como VIS, BRD, PRD, RFC, SDD, TDD, DOM, ERD, API, TPL, DOD, CHG, REL — cada ponto de vista “poderá utilizar” conforme necessidade. |
| Princípio da proporcionalidade (2.9) | Orienta aplicação proporcional à criticidade do projeto; não impõe o conjunto completo a todos os casos. |
| Modo Ágil — Baixa Criticidade (17.3) | Configuração mínima do framework para protótipos, MVPs e ferramentas internas de baixo impacto. Alta flexibilidade dentro dos limites estabelecidos. |
| Indicadores de desempenho (15.1) | KPIs com metas orientativas (“a definir por projeto”) — referência, não exigência fechada. |
| Compatibilidade com metodologias ágeis (seção 13) | Recomendação de cadência por sprint — orientação de integração, não obrigação. |
🔵 Normativo
Seção intitulada “🔵 Normativo”Componentes que estabelecem requisitos obrigatórios a serem observados em todos os projetos que adotam o framework:
| Componente | Localização no framework |
|---|---|
| Princípios gerais do modelo (seção 2) | Os 9 princípios — rastreabilidade integral, validação em múltiplas camadas, supervisão humana obrigatória, segregação por ponto de vista, conformidade desde a origem, evidência mínima obrigatória, documentação contínua, documentação curta, proporcionalidade — são normativos para toda aplicação. |
| Convenção de nomenclatura de arquivos (seção 11) | Padrão <PV>-<TIPO>-<NUM>--<descricao-curta>.md é obrigatório. Nomenclatura incorreta quebra rastreabilidade e auditabilidade. |
| Regras obrigatórias de cada ponto de vista | Seções 4.2 (ESP), 5.4 (INF), 7.3 (IMP), 8.2 (GTI), 9.2 (GDA), 10.2 (PDP) — todas usam linguagem de dever e exigência explícita. |
| Evidências mínimas obrigatórias por ponto de vista | Seções 4.3, 5.5, 6.3, 7.4, 8.4, 9.3, 10.3 — definem o conjunto mínimo que não pode ser suprimido. |
| Cláusula de transparência operacional (seção 14) | Informações obrigatórias ao usuário final sobre IA, autenticação, uso de dados e disclaimers. |
| Regras obrigatórias de prototipação (seção 6.2) | Registro de reunião, versionamento e vinculação às histórias são normativos. |
🟡 Operacional
Seção intitulada “🟡 Operacional”Componentes que descrevem como o framework funciona no dia a dia — papéis, fluxos, estrutura de execução:
| Componente | Localização no framework |
|---|---|
| Ciclo operacional do framework (seção 13) | Descreve o fluxo entre pontos de vista, responsáveis por etapa e como as validações se encadeiam no processo de desenvolvimento. |
| Papéis de supervisão humana (seção 8.5) | Define Validador Técnico, Validador de Negócio e Encarregado de Dados/Privacidade — seus focos e como a IA os apoia com briefings estruturados. |
| Artefato Orquestrador (seção 18) | Componente central de automação: monitora repositórios, aciona validações, executa o Linter de Governança, gera dossiês e controla consumo de tokens. |
| Linter de Governança (seção 8.7) | Mecanismo automatizado que verifica conformidade documental antes de cada gate de promoção. Parte integrante do Artefato Orquestrador. |
| Modos de aplicação (seção 17) | Estrutura o funcionamento proporcional: Completo (alta criticidade), Essencial (média) e Ágil (baixa). Define quais pontos de vista, histórias e validações se aplicam em cada modo. |
| Estrutura de repositórios e documentação (seção 12) | Organização por pastas, regras de documentação curta, versionamento e documentação automatizada como pré-requisito operacional. |
| Governança de uso de IA na GTI (seção 8.2) | Engines permitidas, agentes autorizados, contextos e pontos de intervenção humana — funcionamento institucional do uso de IA. |
| Gestão de custo e capacidade de IA (seção 8.8) | Políticas de controle de consumo de tokens, retenção de histórico e avaliação periódica de engines. |
🟠 Procedimental
Seção intitulada “🟠 Procedimental”Componentes que descrevem sequências de execução, passos, responsáveis, validações e saídas esperadas:
| Componente | Localização no framework |
|---|---|
| CI/CD — operacionalização na IMP (seção 7.2) | Descreve como a implantação operacionaliza as pipelines: integração contínua, testes, build, promoção entre ambientes, aprovação manual em gates, rollback e geração de evidências. |
| CI/CD — definição de requisitos na INF (seção 5.2) | Define o que cada pipeline deve contemplar, com sequência e responsabilidades entre INF e IMP. |
| Condições de exceção e retorno (seção 13.1) | Tabela de situações operacionais (divergência entre engines, rejeição humana, rollback, ausência de registro) com ação obrigatória correspondente a cada caso. |
| RUN — Runbook / Playbook | Artefato documental do framework para execução de rotinas operacionais e resposta a incidentes — especialmente em INF e PDP. |
| PMT — Postmortem | Artefato obrigatório após rollback com impacto em produção ou incidentes com dados pessoais. Registra causas, ações e lições aprendidas. |
| Regras de monitoração (seção 5.3) | Descreve cadeia completa: classificação de eventos, severidade, responsáveis, canais, escalonamento, temporalidade, prazos de resposta e evidência de acionamento. |
| Registro obrigatório de reunião (seção 6.2) | Procedimento com entradas e saídas definidas: transcrição ou gravação, capturas do protótipo e log estruturado de decisões. |
🔴 Prescritivo
Seção intitulada “🔴 Prescritivo”Componentes que estabelecem métodos com baixa margem de adaptação — definem não só o que alcançar, mas como fazê-lo:
| Componente | Localização no framework |
|---|---|
| Estrutura de histórias da especificação (seção 4.1) | Define exatamente os 11 tipos de histórias (HNI, HNE, HNU, HS, HI, HRD, HUX, HC, HAI, HAC, HIVC) e o que cada uma deve conter. O método de estruturação é prescrito. |
| Critério de divergência obrigatória — ESP (seção 4.2) | Especifica precisamente o que configura divergência relevante (segurança, dado pessoal, lógica crítica, conformidade) versus o que não configura (estilo, formatação). |
| Critério de divergência obrigatória — IMP (seção 7.1) | Idem para a implementação: comportamento de segurança, dado pessoal, lógica crítica, teste de segurança ou Nível 3 no modelo de autonomia. |
| Validação cruzada obrigatória (Princípio 2.2) | Prescreve o método: modelo diferente, provedor diferente, sessão sem memória compartilhada e perspectiva de análise diferente. Não há liberdade de reinterpretar o que configura “contexto distinto”. |
| Modo Completo — Alta Criticidade (seção 17.1) | Para projetos de alta criticidade, todas as dimensões são prescritas: 7 pontos de vista, 11 tipos de histórias, 7 repositórios segregados, validação tripla, cobertura ≥ 80%. |
| Organização de repositórios (seção 12.1) | Prescreve a estrutura de pastas (/00-indice, /01-visao-geral, etc.) e as autoridades documentais (ESP sobre requisitos, INF sobre infraestrutura, GTI sobre decisões). |
| Estrutura de histórias de infraestrutura (seção 5.1) | Prescreve HII e HIS com subtipos obrigatórios — 6 tipos institucionais e 9 tipos da solução. |
🔴⛔ Mandatório Fechado
Seção intitulada “🔴⛔ Mandatório Fechado”Componentes de observância integral — desvio descaracteriza a conformidade, normalmente associados a segurança, dados pessoais, auditoria e operação crítica:
| Componente | Localização no framework |
|---|---|
| PDP — Proteção de Dados Pessoais (seção 10) | Privacidade desde a concepção não é opcional. Toda história que envolva dados pessoais ou sensíveis deve ser identificada, avaliada e controlada. Vinculado à LGPD — sem flexibilização. |
| Artefato Orquestrador como pré-requisito (seção 18.1) | “O Artefato Orquestrador não é opcional. Sem ele, a execução do framework depende inteiramente de intervenção humana manual.” Ausência invalida o modelo. |
| Gate de promoção de ambiente (seções 7.3 e 13) | Nenhuma promoção entre ambientes ocorre sem evidências mínimas de conformidade, segurança, qualidade, rastreabilidade e aderência às histórias aprovadas. Bloqueio absoluto. |
| Linter de Governança como bloqueador (seção 8.7) | O Linter bloqueia o avanço de fase quando artefatos obrigatórios estiverem ausentes ou incompletos. Não há avanço sem resolução das não-conformidades. |
| Nível 3 — Crítico no modelo de autonomia (seção 8.6) | Para tarefas de alto impacto (segurança, dados pessoais, autenticação, PDP): IA propõe, humano revisa linha a linha, IA valida implementação. Sem autonomia plena da IA nesses contextos. |
| Trilha de auditoria obrigatória (seções 5.4 e 7.3) | Toda infraestrutura e toda implantação devem prever trilha de auditoria suficiente para registrar autenticações, acessos, alterações, falhas e eventos críticos. Sem exceção. |
| Evidência de reunião como condição de validade (seção 6.2) | “A ausência de registro invalida as decisões para fins de rastreabilidade.” Não há reconhecimento de decisão sem transcrição/gravação, captura do protótipo e log estruturado. |
| Dados pessoais e uso por IA (seção 10.2) | Dados pessoais não podem ser utilizados em contextos de IA sem avaliação prévia de necessidade, adequação, retenção e limitação de exposição. Mandatório para qualquer modo de aplicação. |
Síntese
Seção intitulada “Síntese”| Natureza | Componentes-chave do SinergIA |
|---|---|
| 🟢 Orientativo | Stack de referência (Apêndice A), documentos opcionais, KPIs orientativos, Modo Ágil, compatibilidade ágil |
| 🔵 Normativo | 9 princípios gerais, convenção de nomenclatura, regras obrigatórias por PV, evidências mínimas |
| 🟡 Operacional | Ciclo operacional, papéis GTI, Artefato Orquestrador, Linter, Modos de Aplicação, estrutura de repositórios |
| 🟠 Procedimental | CI/CD (INF e IMP), condições de exceção, RUN/Runbook, PMT/Postmortem, monitoração, registro de reunião |
| 🔴 Prescritivo | Estrutura das 11 histórias ESP, critérios de divergência, validação cruzada, Modo Completo, estrutura de pastas |
| 🔴⛔ Mandatório Fechado | PDP/LGPD, gates de promoção, Linter como bloqueador, Nível 3 Crítico, trilha de auditoria, evidência de reunião |
Próximo: Introdução →