Pontos de Vista

4. Ponto de vista da Especificação (ESP (Especificação))

4.1. Estrutura de histórias da especificação

4.1.1. Histórias de Negócio Institucionais (HNI)

Contêm as definições de negócio de alto nível derivadas de normas, leis, políticas, regras internas, instruções normativas, diretrizes estratégicas e demais orientações da alta gestão.

4.1.2. Histórias de Negócio Especializadas (HNE)

Contêm as definições especializadas da área gestora da solução, condicionadas negocialmente às HNI e tecnicamente às histórias de sistemas.

4.1.3. Histórias de Negócio de Usuário (HNU)

Contêm as definições técnicas e operacionais das equipes usuárias e executoras do negócio, condicionadas às HNI, HNE e às histórias de sistemas.

4.1.4. Histórias de Sistema (HS)

Contêm a tradução técnica estruturada das necessidades de negócio para construção da solução.

4.1.5. Histórias de Integração (HI)

Contêm requisitos de interoperabilidade, troca de dados, APIs, barramentos, integrações internas, externas e com terceiros.

4.1.6. Histórias de Regra de Decisão (HRD)

Contêm regras explícitas de decisão, critérios, exceções, condicionantes, parâmetros e lógicas automatizáveis.

4.1.7. Histórias de Experiência do Usuário (HUX)

Contêm requisitos de jornada, interface, usabilidade, acessibilidade, comunicação e uso prático da solução.

4.1.8. Histórias de Conformidade (HC)

Contêm requisitos legais, regulatórios, normativos, auditoriais e de controle aplicáveis à solução.

4.1.9. Histórias de Autenticação e Identidade (HAI)

Contêm requisitos de autenticação centralizada, federação de identidade, integração institucional e integração com o gov.br.

4.1.10. Histórias de Acessibilidade (HAC)

Contêm requisitos de acessibilidade digital aplicáveis às interfaces, jornadas, componentes, fluxos e conteúdos.

4.1.11. Histórias de Identidade Visual e Comunicação (HIVC)

Contêm padrões de identidade visual de governo, padrões institucionais de interface, textos obrigatórios, disclaimers e componentes de comunicação com o usuário.

4.2. Regras obrigatórias da especificação

Toda história da especificação deverá possuir identificador único, versão, origem, data de geração, data de revisão, autor ou responsável, dependências, criticidade e vínculo com os demais artefatos afetados.

Toda história deverá possuir rastreabilidade bidirecional entre documentos de origem, protótipos, infraestrutura, código, testes, implantação, operação, documentação e evidências.

Toda história deverá ser submetida a validação de alucinação em dois níveis:

por outra engine de IA em contexto distinto;
por validação humana, quando aplicável, exercida pelo papel de supervisão correspondente.

Critério de divergência obrigatória: configura divergência relevante que obriga escalada ao Validador humano toda divergência entre engines que envolva requisito de segurança, dado pessoal ou sensível, lógica de negócio crítica, regra de conformidade ou impacto em autenticação. Divergências de estilo, formatação ou nomenclatura não configuram divergência relevante.

Toda história que envolva usuário externo deverá indicar o mecanismo de autenticação e o nível de autenticação gov.br compatível com a natureza do requisito de negócio.

Toda história que envolva interface, navegação ou interação humana deverá conter requisitos mínimos de acessibilidade.

Toda história que envolva comunicação com o usuário deverá indicar mensagens obrigatórias, disclaimers, avisos institucionais e elementos mínimos de transparência.

4.3. Evidências da especificação

A especificação deverá gerar e manter, no mínimo, as seguintes evidências documentadas:

evidência de origem documental;
evidência de validação por IA secundária;
evidência de validação humana;
evidência de aprovação da história;
evidência de rastreabilidade com protótipo, código, teste ou infraestrutura.

As evidências de validação e aprovação humana deverão ser preferencialmente capturadas via metadados de ferramentas: aprovação de Pull Request, commit assinado com identidade rastreável ou registro em sistema de gestão.

4.4. Documentos estruturantes da especificação

A ESP (Especificação) poderá utilizar, além das histórias, os seguintes documentos:

Vision Document (VIS);
Business Requirements Document (BRD);
Product Requirements Document (PRD);
Domain Model (DOM);
Style Guide (STY).

O STY deverá ser gerado em formato estruturado (JSON ou YAML) para consumo direto pelos agentes de IA da PRO (Prototipação) e da IMP (Implementação).

5. Ponto de vista da Infraestrutura (INF (Infraestrutura))

5.1. Estrutura das histórias de infraestrutura

5.1.1. Histórias de Infraestrutura Institucional (HII)

Definem os padrões corporativos obrigatórios da organização. Devem contemplar, no mínimo: HSI, HATI, HCTI, HCI, HSII, HAII.

5.1.2. Histórias de Infraestrutura da Solução (HIS)

Definem os requisitos especializados da solução. Devem contemplar, no mínimo: HSE, HDISP, HAUT, HMON, HSIS, HDEP, HAMB, HIOP, HAIS.

5.2. CI/CD no modelo — definição e requisitos

As Histórias de Automação (HAUT) deverão especificar os requisitos das pipelines, incluindo, quando aplicável: build automatizado, testes automatizados, análise de qualidade, análise de segurança, empacotamento, publicação de artefatos, promoção controlada entre ambientes, rollback, aprovação manual quando exigida, geração de evidências da pipeline e trilha de auditoria.

5.3. Regra específica de monitoração

As HMON deverão incluir, obrigatoriamente, os critérios de observabilidade da solução, métricas, logs, traces, dashboards, alertas e correlação de eventos. Deverão incluir também: classificação dos eventos, níveis de severidade, responsáveis, canais de comunicação, escalonamento automático, temporalidade da notificação, prazos de resposta, evidência de acionamento e tratamento.

5.4. Regras obrigatórias da infraestrutura

Toda história de infraestrutura deverá ser validada por outra engine de IA em contexto distinto e por instância humana. Toda infraestrutura deverá prever autenticação centralizada institucional e, quando aplicável, integração com gov.br por meio de camada de abstração que minimize vendor lock-in. Deverá prever trilha de auditoria obrigatória suficiente para registrar autenticações, acessos, alterações, falhas e eventos críticos.

5.5. Evidências da infraestrutura

evidência de aderência ao padrão institucional;
evidência de validação técnica;
evidência de validação por IA secundária;
evidência de validação humana;
evidência de configuração de monitoração;
evidência de cadeia de notificação;
evidência de auditoria e logs esperados;
evidência de execução e resultado de pipeline CI/CD.

5.6. Documentos estruturantes da infraestrutura

RFC, ADR, SDD, Runbook/Playbook (RUN), Postmortem (PMT).

6. Ponto de vista da Prototipação (PRO (Prototipação))

6.1. Finalidade da prototipação

A prototipação deverá antecipar a materialização da solução antes da reunião inicial com o demandante, utilizando como base as histórias gerais já disponíveis. Seu objetivo é permitir melhor compreensão do problema, redução de ambiguidades, aceleração do refinamento e registro mais rico das decisões.

6.2. Regras da prototipação

Antes da reunião inicial com o demandante deverá existir uma base preliminar de prototipação construída com apoio de IA.

Durante a reunião, a prototipação deverá admitir aprimoramentos “a quente”, com registro estruturado das alterações, justificativas, decisões, novas evidências e validações realizadas no próprio contexto da interação.

Registro obrigatório de reunião: toda reunião de refinamento “a quente” deverá gerar, obrigatoriamente, ao menos: transcrição ou gravação da sessão, captura das alterações aplicadas ao protótipo e log estruturado das decisões tomadas. A ausência de registro invalida as decisões para fins de rastreabilidade.

Mesmo em caráter preliminar, os protótipos deverão observar regras mínimas de acessibilidade, identidade visual de governo, comunicação institucional e disclaimers.

6.3. Evidências da prototipação

evidência da versão apresentada antes da reunião;
evidência das alterações feitas durante a reunião;
evidência das decisões tomadas “a quente”;
evidência de vinculação com histórias impactadas;
evidência de aprovação ou pendência do demandante.

7. Ponto de vista da Implantação e Construção (IMP (Implementação))

7.1. Modelo de construção

A codificação deverá ser realizada por IA agêntica especializada, com papeis definidos, segregação de responsabilidades e contexto controlado. Os testes deverão ser produzidos e executados por IA agêntica, abrangendo testes unitários, integrados, funcionais, estruturais, de regressão, carga, segurança e operação.

Critério de divergência obrigatória na implementação: configura divergência relevante que obriga escalada ao Validador Técnico toda divergência que envolva comportamento de segurança, tratamento de dado pessoal, lógica de negócio crítica, resultado de teste de segurança ou qualquer implementação classificada como Nível 3 no modelo de autonomia.

7.2. CI/CD na implantação — operacionalização

A IMP (Implementação) deverá implementar e executar as pipelines contemplando: integração contínua de código, execução automatizada de testes, geração de build, validações de qualidade e segurança, publicação de artefatos, promoção entre ambientes, aprovação manual em gates definidos, rollback e documentação de evidências da entrega.

7.3. Regras obrigatórias da implantação

Toda implantação deverá ocorrer com supervisão humana assistida por IA.
Nenhuma promoção entre ambientes deverá ocorrer sem evidências mínimas de conformidade, segurança, qualidade, rastreabilidade e aderência às histórias aprovadas.
Toda entrega deverá gerar dossiê automatizado.
Toda implementação deverá conter trilha de auditoria obrigatória.

7.4. Evidências da implantação

evidência de geração de código;
evidência de revisão automatizada;
evidência de testes executados;
evidência de testes de alucinação;
evidência de validação humana;
evidência de trilha de auditoria implementada;
evidência de autenticação integrada;
evidência de acessibilidade mínima implementada;
evidência de aprovação para promoção de ambiente;
evidência de execução de pipeline CI/CD;
evidência de publicação ou rollback, quando aplicável.

7.5. Documentos estruturantes da implantação

TDD, API Contract (API), Test Plan (TPL), Definition of Done (DOD), Changelog (CHG), Release Notes (REL).

8. Ponto de vista da Governança de TI (GTI (Governança de TI))

8.1. Finalidade

A GTI (Governança de TI) deverá assegurar controle institucional sobre papeis, decisões, mudanças, riscos, conformidade, versionamento, auditoria, documentação, evidências e uso de inteligência artificial no ciclo de vida da solução.

8.2. Regras obrigatórias da GTI (Governança de TI)

Papeis formalmente definidos: alta gestão, gestão de negócio, gestão técnica, arquitetura, segurança, dados, privacidade, operação, validação humana e supervisão de IA.
Toda decisão relevante formalizada, versionada e com evidência mínima correspondente.
Governança específica para uso de IA: engines permitidas, agentes autorizados, contextos, níveis de autonomia, critérios de validação cruzada e pontos de intervenção humana obrigatória.

8.3. Documentos estruturantes da GTI (Governança de TI)

ADR, RFC, Roadmap (RDM).

8.4. Evidências da GTI (Governança de TI)

evidência de papeis formalmente definidos e atribuídos;
evidência de decisões relevantes formalizadas;
evidência de análise de impacto em mudanças;
evidência de governança de uso de IA;
evidência de execução de revisão periódica do framework.

8.5. Papeis de supervisão humana

Papel	Foco de atuação	Como a IA auxilia
Validador Técnico	Segurança, arquitetura, aderência à INF (Infraestrutura)	Relatório de impacto técnico e análise de risco gerados por IA
Validador de Negócio (Demandante)	Usabilidade, regras de negócio, PRO (Prototipação)	Simulação de cenários e demonstração de jornadas via protótipo
Encarregado de Dados / Privacidade	PDP (Proteção de Dados Pessoais), linhagem de dados, minimização	Mapa de linhagem e verificação de minimização gerados por IA

8.6. Níveis de autonomia escalonada

Nível	Impacto	Execução	Validação	Aprovação humana
1 — Rotineiro	Baixo	IA executa	IA valida	Humano por amostragem
2 — Relevante	Médio	IA executa	IA valida	Humano antes do deploy
3 — Crítico	Alto — segurança, dados pessoais, PDP (Proteção de Dados Pessoais)	IA propõe	Humano revisa linha a linha	IA valida implementação

8.7. Linter de Governança

Mecanismo automatizado que verifica, antes de qualquer revisão humana, se um artefato possui todos os vínculos obrigatórios, metadados e evidências mínimas. Bloqueia o avanço de fase quando artefatos obrigatórios estiverem ausentes ou incompletos. Parte integrante do Artefato Orquestrador.

8.8. Gestão de custo e capacidade de IA

A GTI (Governança de TI) deverá manter políticas de: critérios para acionar a segunda engine de validação cruzada (apenas nos casos com divergência obrigatória definida), controle e monitoramento de consumo de tokens por projeto e engine, retenção de histórico de inferências para auditoria, e avaliação periódica da relação custo-benefício das engines.

8.9. Evolução e obsolescência do framework

O framework deverá possuir política explícita de evolução: revisão obrigatória a cada 12 meses, responsável designado pela GTI (Governança de TI), critérios de atualização definidos e versionamento do próprio framework.

9. Ponto de vista da Governança de Dados (GDA (Governança de Dados))

9.1. Finalidade

A GDA (Governança de Dados) deverá disciplinar a classificação, a qualidade, a origem, a linhagem, o acesso, o compartilhamento, o versionamento, as evidências e o ciclo de vida dos dados utilizados ou produzidos pela solução.

9.2. Regras obrigatórias da GDA (Governança de Dados)

Todos os dados classificados conforme natureza, sensibilidade, criticidade e restrição de uso.
Regras para coleta, uso, armazenamento, compartilhamento, retenção, anonimização, arquivamento e descarte.
Rastreabilidade de origem, transformações e usos dos dados ao longo do ciclo.
Avaliação de qualidade nas quatro dimensões obrigatórias:
- Completude: ausência de valores nulos em campos obrigatórios;
- Consistência: ausência de contradições entre registros e sistemas;
- Acurácia: correspondência dos dados com a realidade ou fonte autoritativa;
- Tempestividade: dados disponíveis dentro dos prazos exigidos.
Dados utilizados por IA com controle específico de origem, permissão de uso, sensibilidade e retenção.

9.3. Evidências da GDA (Governança de Dados)

evidência de classificação dos dados;
evidência de versionamento do modelo de dados;
evidência de aprovação de alterações estruturais;
evidência de coerência entre modelo conceitual e lógico;
evidência de avaliação de qualidade nas quatro dimensões;
evidência de impacto em integrações e dados pessoais.

9.4. Documentos estruturantes da GDA (Governança de Dados)

Domain Model (DOM), Data Model / ERD (ERD).

10. Ponto de vista da Proteção de Dados Pessoais (PDP (Proteção de Dados Pessoais))

10.1. Finalidade

A PDP (Proteção de Dados Pessoais) deverá ser tratada como requisito estrutural do framework, e não como etapa posterior.

10.2. Regras obrigatórias da PDP (Proteção de Dados Pessoais)

Toda solução deverá incorporar privacidade desde a concepção.
Cada história deverá indicar se envolve dados pessoais, dados pessoais sensíveis ou outras categorias protegidas.
Avaliação de impacto sobre proteção de dados quando necessário.
A solução deverá tratar apenas os dados estritamente necessários à finalidade declarada.
Uso de mecanismos de anonimização, pseudonimização ou mascaramento quando aplicável.
Rastreabilidade dos tratamentos de dados pessoais, seus responsáveis, finalidade, ambiente de execução e base autorizativa.
Dados pessoais não poderão ser utilizados em contextos de IA sem avaliação prévia de necessidade, adequação, retenção e limitação de exposição.
Integrações com plataformas externas, incluindo gov.br, deverão ser avaliadas quanto ao risco de vendor lock-in, com preferência por soluções com camada de abstração que permitam portabilidade.

10.3. Evidências da PDP (Proteção de Dados Pessoais)

evidência de classificação de dados pessoais;
evidência de avaliação de impacto, quando cabível;
evidência de minimização aplicada;
evidência de controle de uso por IA;
evidência de mecanismos de transparência e disclaimer;
evidência de validação humana nos pontos críticos.

10.4. Documentos estruturantes da PDP (Proteção de Dados Pessoais)

BRD (restrições legais de privacidade), ADR (decisões sobre minimização e retenção), Runbook/Playbook (resposta a incidentes de privacidade), Postmortem (após incidentes com dados pessoais).

Próximo: Convenções, Ciclo e Governança →