Plano de 
Incorporação e 
Optimização do 
Módulo 
Balcão Virtual — 
Portal do Investidor
Esta int
egração não precisa externa os documentos oficias são o bastante para a sua validação e aceitação. 
Objectivo: incorporar e optimizar o módulo Balcão Virtual no Portal do Investidor, disponível em https://teste-investidor.tempo.co.mz/, mantendo Laravel como núcleo transaccional e reutilizando, sempre que adequado, a identidade visual, autenticação, perfis, navegação, infraestrutura e padrões técnicos existentes no portal. Nesta fase, o módulo funcionará sem interoperabilidade: todas as acções de preenchimento, submissão, validação, análise, tramitação, acompanhamento e gestão serão realizadas internamente no Portal do Investidor. As ligações institucionais oficiais já disponibilizadas serão apresentadas apenas para encaminhar o utente aos sectores que integram a cadeia do serviço ou para consulta de informação complementar, sem troca automática de dados entre sistemas.
1. Referências comparáveis
e-BAU — Moçambique
:
 integração de serviços públicos, agendamento, pagamentos, consultas, denúncias, licenciamento e registos.
Balcão Virtual do INCM
:
 catálogo de serviços regulatórios, tramitação de processos e comunicação entre instituição e utentes.
Balcão Virtual do MTC
:
 fluxo explícito de cadastro, validação documental, pedido, pagamento e emissão de licenças.
Secretaria Virtual Municipal
:
 agendamento, submissão, acompanhamento, notificações e apoio multicanal.
IremboGov
 — Ruanda
:
 portal único, acesso 24/7, processamento institucional e serviços orientados ao cidadão.
gov.pt — Portugal
:
 pesquisa central, organização por temas e situações de vida, identidade digital e assistência ao utilizador.
GOV.BR — Brasil
:
 conta única, assinatura electrónica, integração de dados, acessibilidade, automação e monitorização.
Eesti.ee — Estónia
:
 serviços públicos integrados, identidade digital e reutilização segura de dados.
1.1. 
Quadro executivo de benchmarking
Orientação executiva:
 
implementar 
o
 Balcão Virtual 
como módulo nativo do Portal do Investidor, integrado na sua navegação e experiência de utilização
, com operação integralmente interna, catálogo unificado, formulários APIEX, validações determinísticas e assistidas por IA, 
workflow
, notificações, acompanhamento e gestão operacional. As ligações oficiais dos sectores participantes na cadeia serão disponibilizadas como pontos de encaminhamento ou consulta complementar. A interoperabilidade fica expressamente fora do âmbito desta fase e deverá ser objecto de iniciativa, acordo e plano próprios no futuro.
2. Melhorias prioritárias
Catálogo orientado a necessidades:
 organizar serviços por perfil, tema e situação de vida, com pesquisa, filtros, requisitos, custos, prazo, entidade responsável e resultado esperado.
Jornada integral no Balcão Virtual:
 permitir que o utente descubra o serviço, preencha ou retome o formulário, anexe documentos, submeta, receba validações, acompanhe o estado, responda a pedidos de esclarecimento e consulte o resultado dentro do portal. As ligações institucionais oficiais serão apresentadas apenas quando for necessário consultar ou contactar um sector da cadeia.
Área do utente:
 painel com pedidos, estados, pagamentos, documentos, notificações, histórico e próximos passos.
Formulários APIEX inteligentes:
 inventariar e incorporar os formulários da APIEX onde forem necessários, com campos condicionais, listas controladas, validações determinísticas, carregamento seguro de documentos e validação assistida por IA para completude, consistência e qualidade documental. A IA deverá apresentar alertas e recomendações explicáveis, mantendo confirmação do utente e decisão final humana.
Ligações institucionais 
de apoio
:
 disponibilizar, no catálogo e nas páginas dos serviços, os links oficiais 
fornecidos 
pelos sectores que integram a cadeia
, identificando 
entidade
, finalidade, 
última verificação
 e contacto. Os links não substituem a tramitação interna nem implicam interoperabilidade ou transferência automática
 de 
dados
.
Transparência processual:
 número de protocolo, linha temporal, 
SLA
, motivo de devolução e identificação da unidade responsável.
Pagamentos:
 referência única, múltiplos canais, confirmação automática, recibo e reconciliação financeira.
Acessibilidade e inclusão:
 desenho mobile-
first
, linguagem simples, baixo consumo de dados, contraste, navegação por teclado e conformidade 
WCAG
 2.2 AA.
Apoio 
omnicanal
:
 FAQ contextual, pedidos de suporte, WhatsApp/SMS/e-mail e atendimento assistido.
3. Arquitectura Laravel recomendada
Princípio de incorporação:
 o Balcão Virtual não será uma aplicação isolada. Será incluído no mesmo domínio funcional do Portal do Investidor, partilhando cabeçalho, menus, sessão, perfis, design 
system
, gestão de utilizadores, observabilidade e processos de publicação. A implementação deverá evitar autenticação duplicada, cadastros paralelos e componentes que já existam no portal.
URL e navegação recomendadas:
 disponibilizar o módulo através de uma rota própria no Portal do Investidor, por exemplo “/
balcao
-virtual”, acessível pelo menu principal e pela área autenticada. As rotas internas dos formulários, pedidos e painéis devem permanecer sob o mesmo domínio e respeitar os mecanismos de autorização já existentes.
Laravel modular por domínios: Identidade, Catálogo, Pedidos, 
Workflow
, Documentos, Pagamentos, Notificações, Atendimento e Auditoria.
API interna 
versionada
 e documentada em 
OpenAPI
 para os módulos do 
Portal do Investidor e do
 Balcão Virtual
, respeitando os padrões já adoptados em teste-investidor.tempo.co.mz.
 Integrações com sistemas externos e contratos de interoperabilidade não fazem parte do âmbito desta fase.
Filas para notificações, geração documental
 e tarefas demoradas; cache para catálogos e consultas frequentes.
Motor de 
workflow
 configurável, evitando estados codificados directamente nas interfaces.
PostgreSQL como fonte transaccional, identificadores únicos, integridade referencial, histórico de estados e trilho de auditoria imutável.
Armazenamento de ficheiros com antivírus, validação de tipo/tamanho, encriptação, controlo de acesso e política de retenção.
Camada de ligações institucionais com catálogo, verificação de disponibilidade, registo de encaminhamentos e métricas, sem sincronização, consumo de APIs externas ou transferência automática de dados.
Módulo de formulários APIEX com versionamento, regras configuráveis, validação no cliente e servidor, gestão de anexos, rascunhos, consentimento e serviços de IA isolados para análise de completude, coerência e documentação, com 
logs
, limiares de confiança e revisão humana.
Observabilidade com 
logs
 estruturados, métricas, rastreamento, alertas e painéis de 
SLA
.
3.1. Validação preliminar da arquitectura e dos componentes reutilizáveis
A validação pública do portal confirma uma plataforma activa com navegação, conteúdos, área de entrada, dados de mercado, notícias, explorador de activos, carteira, perfil do investidor e simuladores. A reutilização técnica definitiva depende de acesso ao repositório, configuração, base de dados e ambientes; por isso, os itens abaixo distinguem o que pode ser assumido como disponível do que deve ser comprovado na Fase 0.
Componente
Estado preliminar
Decisão de incorporação
Evidência exigida no G0
Navegação e identidade visual
Observável no portal público.
Reutilizar cabeçalho, menus, grelha, tipografia, cores, componentes e padrões responsivos.
Inventário de componentes, design 
tokens
 e regras de navegação.
Área de entrada e sessão
Existe ponto de entrada público; implementação interna não verificada.
Reutilizar autenticação e sessão existentes, sem criar credenciais paralelas.
Fluxo de login/
logout
, recuperação, MFA, duração de sessão e mecanismo de autorização.
Perfis e gestão de utilizadores
Há funcionalidades personalizadas, mas o modelo de permissões não é publicamente verificável.
Estender os perfis existentes com utente, representante, analista, supervisor e administrador do Balcão.
Modelo de utilizadores, organizações, roles, policies e segregação de dados.
Frontend e design 
system
Interface funcional confirmada; 
stack
 e biblioteca não verificados.
Reutilizar componentes existentes; criar apenas componentes específicos de formulários, 
timeline
, filas e validação.
Stack
 frontend, biblioteca, convenções, acessibilidade e cobertura de testes.
Backend Laravel e modularidade
Laravel é premissa do projecto; versão e organização não verificadas.
Incorporar o Balcão como domínio/módulo do backend existente, evitando uma aplicação paralela.
Versão Laravel/
PHP
, estrutura de módulos, rotas, serviços, jobs, eventos e dependências 
Composer
.
Base de dados
Não verificável externamente.
Reutilizar a instância e padrões existentes, criando 
schema
/tabelas próprias e relações controladas com utilizadores e organizações.
SGBD
, migrations, convenções, volumes, backups, índices, auditoria e política de dados.
Ficheiros e documentos
Não verificável externamente.
Reutilizar o armazenamento se cumprir antivírus, cifragem, controlo de acesso, versionamento e retenção.
Driver, localização, 
URLs
 assinadas, limites, antivírus, backup e eliminação.
Notificações e filas
Não verificável externamente.
Reutilizar mail, SMS, notificações internas, 
scheduler
 e 
queue
 
workers
 existentes.
Provedores, 
templates
, filas, 
retries
, 
dead-letter
, métricas e custos.
Pesquisa e catálogo
O portal apresenta múltiplas áreas e conteúdos pesquisáveis.
Estender a pesquisa e taxonomias para serviços e formulários, sem duplicar motor ou índice.
Motor de pesquisa, indexação, filtros, idiomas e desempenho.
Observabilidade e auditoria
Não verificável externamente.
Reutilizar 
logs
, métricas e alertas; acrescentar trilho imutável para pedidos, decisões e IA.
Ferramentas, retenção, correlação, dashboards, alertas e acessos.
CI/CD e ambientes
Portal de teste acessível; processo de entrega não verificável.
Integrar no pipeline existente com 
feature
 
flags
, migrations seguras e 
rollback
.
Repositórios, 
branches
, pipeline, segredos, ambientes, aprovações e plano de reversão.
Segurança e privacidade
Não 
auditável
 por observação pública.
Aplicar controlos existentes e executar análise de lacunas específica para formulários, documentos e IA.
SAST
/DAST, dependências, 
WAF
, gestão de segredos, testes de intrusão e políticas de privacidade.
Conclusão da validação preliminar:
 a incorporação é arquitecturalmente plausível e há componentes de experiência e navegação claramente reutilizáveis. A autenticação, permissões, backend, base de dados, armazenamento, filas, observabilidade, CI/CD e segurança ficam classificados como “reutilizáveis sob confirmação”. Nenhum destes componentes deve ser reconstruído antes da avaliação técnica do G0.
3.2. Jornada de criação da empresa e realização do investimento
Validação do processo 
actual do portal:
 a área
 pública do Portal do Investidor 
apresenta
 conteúdos 
de 
mercado, exploração de activos, carteira, Perfil do Investidor e simuladores. Não foi possível confirmar publicamente
 um 
workflow
 autenticado de 
criação
 de empresa
 ou de submissão de projecto de investimento. O alinhamento recomendado é preservar essa jornada existente — entrada, perfil, exploração e simuladores — e acrescentar, na área autenticada, o ponto de entrada “Criar empresa / Realizar investimento”, que cria um dossier único e abre a linha do tempo do Balcão Virtual. Na Fase 0, esta sequência deve ser confirmada no código, nas rotas e na base de dados antes de qualquer alteração.
Modelo alinhado de navegação:
 (1) visitante consulta informação e ferramentas já existentes; (2) utilizador entra ou cria conta; (3) completa o Perfil do Investidor; (4) usa simuladores e selecciona “Criar empresa / Realizar investimento”; (5) o portal cria o dossier da empresa e do projecto; (6) a linha do tempo apresenta etapas obrigatórias, 
condicionais e paralelas; (7) cada acto externo abre apenas a ligação oficial validada e o utilizador regressa para anexar a evidência e actualizar o estado. Não há interoperabilidade nem transmissão automática de dados.
ID / etapa
Documentos e requisitos essenciais
Responsável pela execução / validação
Dependência e resultado de saída
Ligação oficial / procedimento
E0 — Perfil e preparação do investimento
Conta autenticada; identificação e contactos do promotor; NUIT individual quando aplicável; sector; localização; forma jurídica; sócios; capital; descrição, valor, financiamento, emprego e cronograma do projecto.
Execução: 
Investidor
/Representante Legal. Validação:
 
Product
 
Owner
 APIEX.
Etapa inicial. Cria o dossier único, a checklist dinâmica e abre em paralelo E1 e a preparação de E10.
Ferramentas internas do Portal do Investidor; 
workflow
 a confirmar no G0.
E1 — Reserva do nome
Até três denominações; forma jurídica; objecto social; identificação e contacto do requerente; procuração quando aplicável; comprovativo de pagamento quando exigido.
Execução: Investidor/Representante Legal. Validação: 
SARN
.
Depende de E0. Saída: nome aprovado, ID do pedido, comprovativo e validade registados.
Reserva do nome — 
SARN
E2 — Constituição e registo definitivo
Reserva válida; acto constitutivo ou estatutos; identificação dos sócios; sede; objecto; capital e participações; órgãos sociais; forma de obrigar; procurações e declarações aplicáveis.
Execução: Investidor/Representante Legal. Validação: 
SARN
/Conservatória.
Depende de E1. Saída: certidão, 
NUEL
 ou comprovativo de registo anexado.
Entidades legais — 
SARN
E3 — Beneficiários efectivos
Identificação, nacionalidade, residência, NUIT quando aplicável, natureza e extensão do controlo, percentagem e documentos de suporte.
Execução: 
Representante 
Legal. Validação: 
SARN
/Conservatória
.
Depende de E2 e da aplicabilidade ao tipo de entidade. Saída: declaração ou recibo arquivado.
Beneficiários efectivos — 
SARN
E4 — NUIT colectivo
Modelo M01C; certidão/registo; estatutos quando solicitados; identificação e NUIT do representante; procuração; endereço fiscal; contactos e actividade.
Execução: 
Representante 
Legal. Validação:
 Autoridade Tributária.
Depende de E2. Saída: NUIT colectivo e carta registados, sem duplicação.
Formulários — AT
; 
Carta de NUIT
E5 — Dossier societário e certidões
Certidão; estatutos; reserva; declaração de beneficiários efectivos quando aplicável; órgãos sociais; procurações; comprovativos de publicação ou autenticação.
Execução: Gestor Documental. Validação: Representante Legal.
Consolida E2, E3 e E4. Saída: dossier societário completo, 
versionado
 e validado.
Registos e Notariado — 
SARN
E6 — Licenciamento ou registo da actividade
Certidão e estatutos; NUIT; representante; título de uso ou contrato do espaço; planta ou memória descritiva; actividade/CAE; documentos técnicos, ambientais, sanitários ou sectoriais; taxa.
Execução: Investidor/Representante Legal. Validação: BAU/Entidade Sectorial Competente.
Depende de 
E5
 e dos requisitos sectoriais. Saída: licença, alvará, registo ou justificação de não aplicabilidade.
Licenciamento — BAU
E7 — Início de actividade fiscal
Modelo M02; NUIT; certidão; actividade e endereço; licença/alvará ou prova do regime; enquadramento fiscal; data de início; identificação ou procuração.
Execução: 
Representante 
Legal/Contabilista. Validação:
 Autoridade Tributária.
Depende de E4 e, quando aplicável, E6. Saída: data efectiva e comprovativo de início de actividade.
M02 — Autoridade Tributária
E8 — Inscrição da empresa no INSS
Alvará ou licença simplificada; Modelo 2; NUIT; documento do proprietário ou representante; Boletim da República quando sociedade; boletim de identificação quando aplicável.
Execução: 
Empregador
/Representante Legal. Validação:
 INSS.
Depende de E7. Saída: número de contribuinte e comprovativo, com controlo do prazo de 15 dias.
Inscrição do contribuinte — INSS
E9 — Trabalhadores e gestão contributiva
Número de contribuinte; credenciais; identificação e dados laborais dos trabalhadores; remunerações; períodos declarativos e formulários aplicáveis.
Execução: 
Empregador
/
RH
/Contabilista. Validação:
 INSS.
Depende de E8. Saída: tarefas de inscrição, calendário contributivo, guias e comprovativos associados ao dossier.
SISSMO
; 
Documentos modelo
E10 — Projecto de investimento APIEX
Formulário APIEX homologado; investidor e entidade; NUIT quando disponível; descrição, localização, valor, financiamento, plano, emprego, equipamentos, cronograma, viabilidade, licenças e anexos sectoriais.
Execução: 
Investidor
/Representante Legal. Validação: Analista APIEX; aprovação funcional:
 
Product
 
Owner
 
APIEX
.
A preparação inicia
 em E0 e decorre em paralelo; 
a submissão depende do formulário homologado e das evidências societárias e 
fiscais exigidas para o regime aplicável.
 Saída: protocolo, análise, decisão e histórico interno.
Formulários APIEX incorporados no Portal do Investidor.
E11 — Pós-estabelecimento
Licenças e validades; calendário fiscal e contributivo; declarações; marcos do projecto; evidências de capital, investimento e emprego; alterações societárias; autorizações e relatórios.
Execução: Gestor de Conformidade da Empresa. Validação: 
Product
 
Owner
 APIEX ou entidade competente, conforme obrigação.
Depende de E7; 
incorpora 
E8
, E9 e 
E10
 conforme aplicabilidade e decisão do projecto.
 Saída contínua: conformidade, renovações, alertas e evidências actualizadas.
BAU
; 
Formulários fiscais
; 
INSS
3.2.1. Matriz de rastreabilidade da jornada empresarial
Nomenclatura normalizada:
 Responsável pela Execução = Investidor/Representante Legal ou equipa interna que realiza a actividade; Responsável pela Validação = entidade ou função que confirma a evidência; 
CA-E
## = critério de aceitação da etapa; 
CT-E
##-## = caso de teste da etapa; EV-E## = evidência mínima de saída.
Etapa
Dependência crítica validada
Responsável pela execução / validação
Critério de aceitação
Casos de teste
Evidência mínima
Parâmetro operacional e fonte
E0 — Perfil e preparação
Etapa inicial; conta autenticada e dados mínimos do promotor e do projecto.
Execução: Investidor/Representante Legal. Validação: 
Product
 
Owner
 APIEX.
CA-E00: dossier criado; reutilização consentida; checklist adaptada ao sector, forma jurídica, origem e valor do investimento.
CT-E00-01 dossier completo; CT-E00-02 campo obrigatório omisso; CT-E00-03 consentimento recusado; CT-E00-04 sector/localização alterado; CT-E00-05 regime de investimento recalculado.
EV-E00: dossier único, consentimento, classificação preliminar e checklist no histórico.
Prazo interno: imediato após dados mínimos. Custo: sem custo interno. Fonte: regras homologadas pelo 
Product
 
Owner
 APIEX.
E1 — Reserva do nome
E0 concluída.
Execução: Investidor/Representante Legal. Validação: 
SARN
.
CA-E01: pedido, nome aprovado, comprovativo e validade registados; alerta antes da expiração.
CT-E01-01 percurso normal; CT-E01-02 sem denominação; CT-E01-03 ligação indisponível; CT-E01-04 reserva expirada.
EV-E01: ID do pedido, nome aprovado, comprovativo, validade e encaminhamento.
Prazo, validade e emolumento: capturados do acto publicado pelo 
SARN
 no momento do pedido; não são fixados no portal. Dono do parâmetro: Gestor Institucional 
SARN
.
E2 — Constituição e registo definitivo
E1 válida.
Execução: Investidor/Representante Legal. Validação: 
SARN
/Conservatória.
CA-E02: checklist ajustada ao tipo de entidade; conclusão apenas com certidão, 
NUEL
 ou comprovativo.
CT-E02-01 documentos completos; CT-E02-02 reserva expirada; CT-E02-03 estatutos incompletos; CT-E02-04 conclusão sem certidão.
EV-E02: certidão, 
NUEL
 ou comprovativo do registo.
Regime: Decreto-Lei n.º 1/2024. Prazo e emolumento: catálogo oficial do 
SARN
/Conservatória vigente. Excepções por forma jurídica são regras versionadas.
E3 — Beneficiários efectivos
E2 concluída. Obrigatória para sociedades comerciais, associações, fundações, consórcios, cooperativas, confissões 
religiosas, representações de entidades estrangeiras, fundos fiduciários e outras entidades legalmente sujeitas.
Execução: Representante Legal. Validação: 
SARN
/Conservatória.
CA-E03: pessoa singular com participação ou controlo directo/indirecto igual ou superior a 10%, ou outro controlo efectivo, identificada; declaração feita no acto constitutivo, anualmente no mês da 
constituição e até 30 dias após alteração; não aplicabilidade fundamentada.
CT-E03-01 entidade abrangida; CT-E03-02 excepção fundamentada; CT-E03-03 percentagens incoerentes; CT-E03-04 identificação ausente; CT-E03-05 alteração não 
declarada em 30 dias.
EV-E03: declaração/recibo, estrutura de propriedade, documentos de identificação ou parecer de não aplicabilidade.
Fonte 
primária
 confirmada
: 
Decreto-Lei n.º 1/2024
, de 8 de Março
. 
Parâmetros aplicáveis na matriz
: limiar de 
participação ou controlo de 
10
%;
 declaração no acto 
constitutivo
;
 actualização anual no mês da constituição
; actualização
 até 30 dias após alteração. Verificação: 7 de Outubro de 2026. Confiança: alta.
E4 — NUIT colectivo
E2 concluída.
Execução: Representante Legal. Validação: Autoridade Tributária.
CA-E04: M01C e documentos completos; denominação, sede e representante coerentes; NUIT único.
CT-E04-01 pedido válido; CT-E04-02 denominação divergente; CT-E04-03 NUIT duplicado; CT-E04-04 carta ilegível.
EV-E04: NUIT colectivo e carta de NUIT válidos.
Prazo e taxa: obtidos da Autoridade Tributária no acto; catálogo interno guarda data, fonte e comprovativo. Dono do parâmetro: Gestor Institucional AT.
E5 — Dossier societário e certidões
E2 e E4 concluídas; E3 concluída quando aplicável.
Execução: Gestor Documental. Validação: Representante Legal.
CA-E05: documentos completos, versionados, válidos, autênticos e com acesso controlado.
CT-E05-01 consolidar dossier; CT-E05-02 substituir certidão; CT-E05-03 documento expirado; CT-E05-04 acesso indevido.
EV-E05: índice documental validado, versões, validade e permissões.
SLA
 interno: um dia útil após recepção da última evidência. Custo interno: nenhum. Excepção: pendência externa mantém estado “A aguardar resposta”.
E6 — Licenciamento ou 
registo da actividade
E5 concluída; actividade classificad
a por CAE, localização, risco e legislação sectorial.
Execução: Investidor/Representante Legal. Validação: BAU ou 
Entidade Sectorial Competente.
CA-E06: decisão documentada entre Mera 
Comunicação Prévia, Licenciamento Simplificado, Licenciamento Comercial/Industrial ou autorização sectorial; documento final ou não aplicabilidade comprovada.
CT-E06-01 mera comunicação; CT-E06-02 
licenciamento simplificado; CT-E06-03 autorização sectorial; CT-E06-04 requisito técnico ausente; CT-E06-05 regime alterado por data de vigência.
EV-E06: certidão, licença, alvará, 
autorização sectorial ou parecer de não aplicabilidade.
Fonte institucional 
confirmada
: 
BAU — licenciamento e registo
 de actividades económicas
. Parâmetros aplicáveis na matriz: Licenciamento Simplificado, Licenciamento Comercial, Licenciamento Industrial e Licenciamento de Representação Comercial. Prazos, custos, diplomas futuros e datas de vigência não confirmados não são usados como regras automáticas. Verificação: 7 de Outubro de 
2026. Confiança: alta para os tipos de serviço.
E7 — Início de actividade fiscal
E4 concluída e E6 concluída quando aplicável.
Execução: Representante Legal/Contabilista. Validação: Autoridade Tributária.
CA-E07: M02, actividade, endereço e data consistentes; comprovativo obrigatório e imutável.
CT-E07-01 declaração válida; CT-E07-02 data anterior ao licenciamento; CT-E07-03 actividade divergente; CT-E07-04 conclusão sem comprovativo.
EV-E07: data efectiva e comprovativo de início.
Prazo e custo: conforme acto e orientação vigente da Autoridade Tributária. Dono do parâmetro: Gestor Institucional AT. Divergência bloqueia E8.
E8 — Inscrição da empresa no INSS
E7 concluída.
Execução: Empregador/Representante Legal. Validação: INSS.
CA-E08: inscrição até 15 dias após o início de actividade; documentos completos; número de contribuinte único; atraso sinalizado.
CT-E08-01 dentro do prazo; CT-E08-02 prazo ultrapassado; CT-E08-03 documento ausente; CT-E08-04 número duplicado.
EV-E08: número de contribuinte, comprovativo, prazo e alertas.
Fonte institucional
 confirmada
: 
INSS — Direitos e Obrigações do Contribuinte
. Parâmetro aplicável na matriz
: inscrição da empresa até 15 dias após o início da actividade. Verificação: 7 de Outubro de 2026. Confiança: alta.
E9 — Trabalhado
res e gestão contributiva
E8 concluída 
e existência de trabalhadores ou obrigação contributiva.
Execução: Empregador/RH/Co
ntabilista. Validação: INSS.
CA-E09: trabalhadores 
inscritos; declarações e pagamentos controlados entre dia 20 do mês corrente e dia 10 do mês seguinte; calendário e comprovativos no dossier.
CT-E09-01 inscrever 
trabalhador; CT-E09-02 empresa sem número INSS; CT-E09-03 declaração após dia 10; CT-E09-04 remuneração divergente; CT-E09-05 ligação 
SISSMO
 alterada.
EV-E09: inscrições, 
declaração de remunerações, guias, pagamentos e alertas.
Fonte institucional
 
confirmada
: 
INSS — Direitos e Obrigações do Contribuinte
. Parâmetros aplicáveis na matriz: taxa contributiva
 global de 7%, repartida em 4% para o empregador e 3% para o trabalhador; declaração e pagamento entre o dia 20 do mês corrente e o dia 10 do mês seguinte
; transferência do
 termo para o primeiro dia útil quando coincidir com sábado, domingo ou feriado. Verificação: 7 de Outubro de 2026. Confiança: alta.
E10 — Projecto de investimento APIEX
Preparação inicia em E0. Submissão depende do 
formulário oficial homologado e das evidências societárias, fiscais, financeiras e sectoriais exigidas pelo regime.
Execução: Investidor/Representante Legal. Validação: Analista APIEX. Aprovação funcional: 
Product
 
Owner
 APIEX. Decisão: autoridade competente definida pelo valor/regime.
CA-E10: regime de mero registo ou autorização identificado; 
formulário assinado; identificação do investidor; documentos da entidade; plano, valor, fontes de financiamento, emprego, cronograma, localização, viabilidade e anexos sectoriais completos; decisão fundamentada e auditada.
CT-E10-01 mero registo; CT-E10-02 autorização; CT-E10-03 
financiamento inconsistente; CT-E10-04 anexo ilegível; CT-E10-05 falso positivo de IA; CT-E10-06 autoridade decisória incorrecta.
EV-E10: formulário, protocolo, comprovativos financeiros, 
pareceres, alertas/revisão humana, decisão e versão imutável.
Fontes normativas confirmadas
: Lei n.º 8/2023, de 9 
de Junho, e 
Decreto n.º 8/2024, de 7 de Março
, publicado na I Série do Boletim da República n.º 48. 
Parâmetros aplicáveis na matriz
: análise 
do mero registo 
até 
dois
 dias
;
 valor
 mínimo de investimento directo estrangeiro de 6,5 milhões 
MZN
; competência do
 Governador 
até
 3,5 mil milhões 
MZN
;
 Director-Geral 
da 
APIEX 
até
 6,5 mil milhões 
MZN
;
 Ministro das Finanças 
até
 32 mil milhões 
MZN
;
 Conselho de Ministros
 acima desse valor.
 Regimes especiais
, 
ZEE
, 
ZFI 
e 
ZETI
 
seguem legislação própria.
 Verificação: 7 de Outubro de 2026. 
Confiança: alta
. Os
 formulários operacionais permanecem dependentes de homologação pela APIEX.
E11 — Pós-estabelecimento
E7 concluída; incorpora E8, E9 e E10 conforme aplicabilidade e decisão do projecto.
Execução: Gestor de Conformidade da Empresa. Validação: 
Product
 
Owner
 APIEX ou autoridade sectorial/fiscal/contributiva competente.
CA-E11: obrigações geradas por licença, regime fiscal, INSS, decisão APIEX e compromissos do projecto; renovações e alterações monitorizadas; encerramento fundamentado.
CT-E11-01 licença a expirar; CT-E11-02 obrigação concluída; CT-E11-03 marco de investimento atrasado; CT-E11-04 alteração societária; CT-E11-05 mudança do beneficiário efectivo; CT-E11-06 cessação de actividade.
EV-E11: calendário de conformidade, alertas, comprovativos, relatórios, histórico e escalonamento.
SLA
 interno: alertas 30/15/5 dias antes do vencimento, salvo prazo legal diferente. Custos e prazos externos são versionados por entidade. Regra de excepção: alteração legal suspende a regra afectada até validação do Dono do Serviço.
3.2.2. Validação da sequência, caminho crítico e lacunas
Sequência principal validada:
 E0 → E1 → E2 → E4 → E5 → E6, quando aplicável → E7 → E8 → E9 → E11. E3 é um ramo obrigatório quando a entidade estiver sujeita à declaração de beneficiários efectivos e converge em E5. E10 inicia a preparação em paralelo a partir de E0; a sua submissão depende das evidências societárias e fiscais exigidas pelo regime aplicável e a respectiva decisão converge em E11.
Caminho crítico da constituição e entrada em actividade:
 E0 → E1 → E2 → E4 → E5 → E6 → E7. Para uma actividade dispensada de licenciamento, E6 é marcada “Não aplicável” mediante evidência e o caminho segue E5 → E7. Quando a empresa emprega trabalhadores, E8 e E9 prolongam o caminho até à prontidão laboral e contributiva. Para projectos sujeitos a decisão da APIEX antes da implementação ou do acesso a 
benefícios, E10 torna-se também crítico e deve estar concluído antes dos marcos correspondentes de E11.
Lacunas colmatadas e controlo residual:
 a aplicabilidade de E3 passa a seguir as entidades e o limiar de controlo definidos no Decreto-Lei n.º 1/2024; E6 utiliza uma árvore de decisão por CAE, risco, localização, data de vigência e legislação sectorial; E10 adopta o pacote documental mínimo, os regimes de mero registo/autorização, os limites de competência e o prazo de análise previstos na Lei n.º 8/2023 e no Decreto n.º 8/2024. Os responsáveis externos são definidos por função institucional — 
SARN
/Conservatória, Autoridade Tributária, BAU/Entidade Sectorial, INSS e autoridade decisória do investimento — e devem ser associados nominalmente no catálogo de serviços antes da publicação. Prazos e custos externos não confirmados não serão estimados: serão campos versionados com fonte, data de vigência e responsável pela validação. Regimes especiais, ZEE, ZFI, actividades reguladas e alterações legais activam uma checklist específica e exigem parecer do Dono do Serviço e Jurídico antes da progressão.
3.2.3. Catálogo de parâmetros externos e regra de actualização
Parâmetro
Regra de preenchimento
Responsável pela validação
Frequência / gatilho
Responsável nominal e contacto
Associar a unidade e o ponto focal oficialmente indicados pela entidade; na ausência de nome, usar o canal institucional publicado.
Gestor Institucional do Serviço.
Antes da publicação e trimestralmente.
Prazo legal ou institucional
Registar valor, unidade, evento de início, suspensão, fonte e data de vigência; nunca inferir prazo ausente.
Dono do Serviço e Jurídico.
A cada alteração normativa ou comunicação oficial.
Custo ou emolumento
Registar montante, moeda, base de cálculo, isenção, canal de pagamento, fonte e vigência; apresentar “A confirmar na entidade” quando não publicado.
Gestor Institucional e Finanças.
Antes de cada 
release
 e mensalmente.
Regra de aplicabilidade
Versionar
 condições por forma jurídica, CAE, sector, localização, risco, valor, origem do capital e data.
Product
 
Owner
 APIEX, Dono do Serviço e Jurídico.
A cada nova actividade, formulário ou alteração legal.
Excepção e regime especial
Exigir fundamento, parecer, aprovador, validade e evidência; bloquear progressão enquanto pendente.
Jurídico e autoridade competente.
Por processo.
3.2.4. Registo de validação das fontes externas
Parâmetro
Fonte validada
Data de verificação
Estado
Beneficiário efectivo: entidades, limiar e prazos
Decreto-Lei n.º 1/2024, de 8 de Março, cópia disponibilizada pelo Tribunal Supremo.
7 de Outubro de 2026
Confirmado — confiança alta.
Tipos de licenciamento e registo
Portal institucional do BAU.
7 de Outubro de 2026
Confirmado — confiança alta.
Decretos n.º 40/2026 e 41/2026; vigência em 25 de Outubro de 2026; prazos de duas horas/um dia
Referências secundárias coerentes; não localizados na página oficial de legislação do BAU nem em cópia primária acessível nesta validação.
7 de Outubro de 2026
Pendente de confirmação no Boletim da República; não activar como regra automática.
Inscrição da empresa no INSS em 15 dias
Portal institucional do INSS — Direitos e Obrigações do Contribuinte.
7 de Outubro de 2026
Confirmado — confiança alta.
Contribuição INSS de 7%, distribuição 4%/3% e janela mensal 20–10
Portal institucional do INSS — Direitos e Obrigações e Taxa Contributiva.
7 de Outubro de 2026
Confirmado — confiança alta.
Regulamento do investimento: mero registo, dois dias, IDE mínimo e competências
Decreto n.º 8/2024, de 7 de Março, I Série do Boletim da República n.º 48.
7 de Outubro de 2026
Confirmado — confiança alta.
Formulários e checklist operacional APIEX
O regulamento atribui ao Ministro das Finanças a aprovação dos formulários; não foi localizado um formulário oficial público específico.
7 de Outubro de 2026
Pendente de homologação formal pela APIEX.
Regra de publicação:
 parâmetros com estado “Pendente” não podem ser usados como prazo bloqueante, custo, data de vigência ou decisão automática. Devem aparecer como informação provisória, acompanhada da fonte e da data, até validação pelo Jurídico e pelo Dono do Serviço.
Condições de aprovação da jornada:
 
todas as etapas aplicáveis devem 
cumprir os critérios e evidências definidos na matriz de rastreabilidade;
 dependências
 não podem ser ultrapassadas sem excepção formal e auditada; ligações
 institucionais devem estar 
activas
; testes críticos, segurança, acessibilidade e UAT devem estar aprovados.
Estados 
e controlo
 da linha do tempo:
 
Não iniciado; Em preparação; Pronto para encaminhamento; Encaminhado ao sector; A aguardar resposta; Com pendência; Concluído; Não aplicável; Expirado. Cada fase deve exibir entidade
, requisitos
, documentos
, dependências
, prazo
, custo 
apenas 
quando 
oficialmente 
confirmado, ligação 
validada
, data da última verificação e próxima acção.
 Os links devem ser 
testados antes de cada 
release
 e mensalmente; redireccionamentos, indisponibilidade ou mudança de domínio geram alerta e bloqueiam a publicação até validação pelo gestor institucional.
Resultado da validação dos links:
 foram confirmados como institucionais os destinos do 
SARN
 para reserva, registo e beneficiários efectivos; da Autoridade Tributária para M01C, M02 e carta de NUIT; do BAU para licenciamento; e do INSS para inscrição, documentos modelo e 
SISSMO
. O endereço de teste do e-BAU foi retirado da jornada e substituído pela página oficial de licenciamento do BAU. Para a submissão de projectos de investimento, não foi encontrado um destino público específico da APIEX; por isso, o documento mantém os formulários incorporados no portal e exige homologação formal da APIEX antes do G0.
4. Segurança, privacidade e governação
MFA para perfis críticos, sessões seguras, protecção 
CSRF
/
XSS
/SQL 
injection
 e gestão centralizada de segredos.
Princípio do menor privilégio, segregação de funções e revisões periódicas de acessos.
Consentimento, minimização de dados, finalidade explícita, retenção definida e rastreabilidade de consultas e alterações.
Plano de cópias de segurança, recuperação de desastre, testes de restauro e continuidade do serviço.
Governação dos dados: manter fonte, proprietário, versão, finalidade e retenção de cada formulário e evidência; impedir duplicações internas; não sincronizar nem transferir automaticamente dados para sistemas institucionais externos nesta fase.
Governação da IA:
 validar os modelos e regras usados nos formulários APIEX quanto a precisão, explicabilidade, privacidade, enviesamento, segurança e rastreabilidade; proibir aprovação ou rejeição exclusivamente automatizada e assegurar canal de revisão humana.
4.1. Estratégia 
operacional sem
 interoperabilidade
Componente
Operação nesta fase
Controlo obrigatório
Resultado esperado
Catálogo e ligações
Publicar todos os serviços no Balcão Virtual e disponibilizar ligações oficiais apenas para encaminhamento ou consulta junto dos sectores da cadeia.
Responsável institucional, URL oficial, finalidade, estado, data de verificação, contacto e aviso de saída do portal.
Ponto único de acesso, sem dependência de integrações externas.
Formulários APIEX
Executar internamente preenchimento, rascunho, anexos, submissão, validação, análise, 
correcção, decisão e histórico.
Versão aprovada, regras de negócio, proprietário, perfis, consentimento, 
auditoria, retenção e suporte.
Tramitação digital completa dentro do Balcão Virtual.
Validação por IA
Detectar omissões, inconsistências, baixa qualidade de anexos e divergências prováveis, apoiando o utente e os analistas internos.
Regras determinísticas prevalecem; explicação, confiança, 
logs
, revisão humana e proibição de decisão exclusivamente automatizada.
Redução de erros e devoluções, com rastreabilidade.
Workflow
 interno
Distribuir processos às unidades ou perfis internos responsáveis pelas etapas da cadeia, com filas, prazos, pareceres e decisões.
Matriz de perfis, estados, transições, 
SLA
, segregação de funções e motivos obrigatórios.
Coordenação interna de toda a cadeia sem troca automática com sistemas externos.
Comunicação com sectores
Usar ligações oficiais, contactos e procedimentos definidos para consulta ou encaminhamento quando a participação externa for necessária.
Registo do encaminhamento, responsável, prazo de resposta e evidência documental anexada ao processo quando aplicável.
Continuidade da cadeia por canais oficiais, mantendo o processo principal no portal.
Princípio operacional:
 nesta fase, nenhum serviço depende de interoperabilidade. O Balcão Virtual concentra internamente todas as acções e mantém ligações oficiais apenas para acesso aos sectores da cadeia, consulta complementar ou contactos institucionais. Qualquer futura interoperabilidade será tratada num projecto separado, mediante acordo formal.
4.2. Validação de coerência e dependências
Relação
Validação
Regra de dependência
Responsável pela evidência
Catálogo → publicação
Todos os serviços são classificados e descritos antes da disponibilização.
Nenhum serviço é publicado sem formulário ou ligação válida, proprietário, requisitos, suporte e data de revisão.
Product
 
Owner
 e gestores institucionais dos links.
Formulário → validação por IA
A IA complementa, mas não substitui, regras determinísticas e decisão humana.
A versão funcional homologada e as regras de negócio precedem a configuração ou activação da IA.
Product
 
Owner
 APIEX, donos dos formulários e Equipa de IA.
Formulário → piloto
O piloto depende de formulários e fluxos internos testados.
G2 é pré-requisito para incluir um formulário no G3; formulários não homologados permanecem fora do lançamento.
QA
 e APIEX.
Links → operação
Os links apoiam o contacto com os sectores da cadeia sem retirar a tramitação do portal.
A publicação depende de validação da URL, finalidade, aviso de saída e contacto institucional.
DevOps
/
SRE
 e gestor institucional do link.
Workflow
 → operação
Todas as etapas do processo são executadas por perfis e unidades internas do Balcão Virtual.
Estados, permissões, filas, 
SLA
, notificações e escalonamento devem estar configurados antes do piloto.
Product
 
Owner
, Líder técnico e Operações.
Piloto → lançamento
Nenhum formulário entra em produção antes da estabilização.
G2, preparação operacional, UAT, segurança, acessibilidade, suporte e 
rollback
 precedem G3.
Comité Técnico, Operações e Patrocinador Executivo.
Resultado da validação:
 a sequência é coerente desde que G2 preceda a 
inclusão
 de formulários no 
piloto e 
G3 autorize o
 lançamento transitório
. A execução desta fase não possui dependências de interoperabilidade; depende apenas da prontidão interna do catálogo, formulários, 
workflow
, IA, segurança, operação e ligações institucionais de apoio.
Condições de arranque:
 
devem estar disponíveis o código-fonte
 e a documentação técnica de teste-investidor.tempo.co.mz
, os ambientes, o esquema da base de dados, 
a arquitectura de autenticação e perfis, o inventário de componentes reutilizáveis, as regras de navegação e publicação, 
o inventário inicial de ligações, as versões oficiais dos formulários e o acesso às equipas de segurança, jurídico, dados, 
QA
 e operações. Se uma destas condições não estiver satisfeita, o cronograma deve ser replaneado antes da aprovação de G0.
4.3. Requisitos funcionais dos formulários APIEX
ID
Requisito funcional
Critério de aceitação
Dependência / responsável
RF-01
Catálogo de formulários com título, finalidade, público-alvo, requisitos, prazo, custo, proprietário e versão.
O utente localiza o formulário por pesquisa, tema, perfil e serviço e consulta instruções antes de iniciar.
Inventário aprovado / 
Product
 
Owner
 APIEX.
RF-02
Controlo de acesso por perfil individual, empresa, representante, analista, supervisor e administrador.
Cada perfil visualiza e executa apenas as operações autorizadas; representação fica registada.
Identidade, procurações e matriz de permissões / Segurança.
RF-03
Criação, gravação automática, rascunho, retoma, duplicação autorizada e cancelamento.
O rascunho mantém versão e data, pode ser retomado noutro dispositivo e não é submetido sem acção expressa.
Sessão e armazenamento / Líder técnico.
RF-04
Campos configuráveis: texto, número, moeda, data, selecção, localização, contactos, identificadores e grupos repetíveis.
Tipos, máscaras, limites e formatos são aplicados no cliente e servidor.
Dicionário de campos / Donos dos formulários.
RF-05
Lógica condicional e regras de obrigatoriedade conforme perfil, respostas, serviço e fase.
Campos e secções aparecem, desaparecem ou tornam-se obrigatórios conforme regras versionadas e testadas.
Regras de negócio / 
Product
 
Owner
 APIEX.
RF-06
Carregamento e gestão de documentos, incluindo tipo, tamanho, validade, versão e categoria.
Ficheiros inválidos são bloqueados; documentos passam por antivírus, encriptação e controlo de acesso.
Política documental / Segurança e Operações.
RF-07
Validação determinística de completude, formato, consistência entre campos, duplicações e requisitos.
Erros bloqueantes indicam campo, causa e correcção; avisos não bloqueantes são diferenciados.
Catálogo de regras / 
QA
 e donos dos formulários.
RF-08
Validação assistida por IA para qualidade de anexos, omissões, incoerências e divergências prováveis.
Cada alerta apresenta fundamento compreensível, confiança, acção recomendada e opção de revisão humana.
Modelo autorizado e métricas aprovadas / Equipa de IA.
RF-09
Pré-visualização e confirmação antes da submissão.
O utente revê respostas, anexos, declarações e consentimentos e confirma explicitamente a submissão.
Conteúdo legal aprovado / Jurídico e APIEX.
RF-10
Submissão com identificador único, carimbo temporal, recibo e cópia imutável da versão submetida.
Uma submissão repetida não cria duplicação; o recibo fica disponível para descarga.
Idempotência
 e auditoria / Líder técnico.
RF-11
Workflow
 de análise, distribuição, pedido de esclarecimento, correcção, parecer, aprovação, rejeição e encerramento.
Transições obedecem a permissões, prazos e motivos obrigatórios e ficam integralmente auditadas.
Workflow
 aprovado / Donos dos serviços.
RF-12
Notificações configuráveis por e-mail, SMS e área do utente.
Eventos, modelos, destinatários, idioma, tentativas e comprovativo de entrega são registados.
Canais contratados / Operações.
RF-13
Correcção controlada após devolução, preservando versões e comparação.
O utente altera apenas campos autorizados; versão anterior e justificação permanecem consultáveis.
Regras do serviço / APIEX.
RF-14
Painel operacional com filas, prioridades, 
SLAs
, estados, alertas e atribuição de analistas.
Supervisores filtram, reatribuem e acompanham atrasos sem alterar o conteúdo original.
Modelo operacional / APIEX e Operações.
RF-15
Pesquisa, consulta, exportação e relatórios conforme permissões e finalidade.
Exportações são autorizadas, minimizadas, registadas e identificam origem, período e responsável.
Governação de dados / Equipa de Dados.
RF-16
Administração sem código de versões, campos, regras, 
textos, anexos, prazos e modelos de notificação.
Alterações passam por rascunho, aprovação, publicação agendada e 
rollback
, 
sem afectar submissões anteriores.
Workflow
 de publicação / 
Product
 
Owner
 e 
QA
.
RF-17
Acessibilidade, responsividade, linguagem simples e baixo consumo de dados.
Fluxos essenciais cumprem 
WCAG
 2.2 AA e funcionam em dispositivos móveis e ligações limitadas.
Design 
system
 / UX e 
QA
.
RF-18
Consentimento, retenção, eliminação, anonimização e trilho de auditoria.
Cada tratamento possui finalidade, base, prazo e evidência; acessos e alterações são rastreáveis.
Políticas aprovadas / Jurídico, Segurança e Dados.
ID
Requisito funcional complementar
Critério de aceitação
Dependência / responsável
RF-19
Linha do tempo da constituição da empresa e do investimento, com fases configuráveis, dependências, estados, prazos, entidade, requisitos, custos, evidências, ligação oficial e próxima acção.
O utente visualiza a posição actual, fases concluídas, pendências e próxima etapa; fases não aplicáveis são justificadas; nenhuma fase dependente é concluída sem evidência ou excepção autorizada.
Processo validado / 
Product
 
Owner
, APIEX e donos dos serviços.
RF-20
Gestão de ligações institucionais por fase, com URL oficial, entidade, finalidade, contacto, data da última verificação, disponibilidade e aviso de saída do portal.
Somente links aprovados e activos são publicados; falhas geram alerta; alterações mantêm histórico; o clique e o retorno ao processo são registados sem transmitir dados pessoais.
Catálogo de links / Gestores institucionais, 
DevOps
/
SRE
 e 
QA
.
RF-21
Dossier único da empresa e do investimento, reutilizando internamente dados e documentos entre fases autorizadas.
Dados comuns não são solicitados novamente; o utente confirma a reutilização; alterações propagam-se apenas a rascunhos e nunca modificam evidências já submetidas.
Modelo de dados e consentimento / Líder técnico, Segurança e Equipa de Dados.
Regra de priorização:
 cada formulário deve ter uma ficha de implementação com proprietário, volume, impacto, complexidade, dados tratados, anexos, regras, risco, dependências, esforço e critérios de aceitação. A entrada no 
piloto e lançamento
 exige homologação funcional, teste de segurança, acessibilidade, UAT e operação de suporte definida.
4.3.1. Matriz 
RACI
 dos requisitos APIEX
Legenda:
 R = executa; A = aprova e responde pelo resultado; C = consultado; I = informado. PO = 
Product
 
Owner
 APIEX; DF = Donos dos Formulários; LT = Líder Técnico; UX = UX/Acessibilidade; IA = Equipa de IA; 
SJD
 = Segurança/Jurídico/Dados; 
QA
 = Qualidade; OPS = Operações/
DevOps
.
Requisitos
PO
DF
LT
UX
IA
SJD
QA
OPS
RF-01 Catálogo
A
R
R
C
I
C
R
I
RF-02 Acessos e representação
A
C
R
C
I
R
R
C
RF-03 Rascunho e retoma
A
C
R
C
I
C
R
C
RF-04 Campos configuráveis
A
R
R
C
I
C
R
I
RF-05 Lógica condicional
A
R
R
C
I
C
R
I
RF-06 Documentos
A
C
R
C
I
R
R
R
RF-07 Validação determinística
A
R
R
C
C
C
R
I
RF-08 Validação por IA
A
C
R
C
R
C
R
C
RF-09 Pré-visualização e confirmação
A
R
R
R
I
C
R
I
RF-10 Submissão e recibo
A
C
R
C
I
C
R
R
RF-11 
Workflow
A
R
R
C
I
C
R
R
RF-12 Notificações
A
C
R
C
I
C
R
R
RF-13 Correcção e versões
A
R
R
C
I
C
R
I
RF-14 Painel operacional
A
C
R
C
C
C
R
R
RF-15 Pesquisa, exportação e relatórios
A
C
R
C
C
R
R
C
RF-16 Administração sem código
A
R
R
C
I
C
R
C
RF-17 Acessibilidade e responsividade
A
C
R
R
I
C
R
C
RF-18 Privacidade, retenção e auditoria
C
C
R
I
C
A/R
R
R
Regra de governação:
 cada requisito possui um único A, excepto RF-18, em que a função integrada 
SJD
 mantém a autoridade normativa. O 
QA
 produz evidência independente; a aprovação do PO não substitui pareceres obrigatórios de segurança, jurídico, dados ou acessibilidade.
4.3.2. Critérios de aceitação e casos de teste APIEX
ID
Critério de aceitação verificável
Casos de teste essenciais
Resultado / evidência
RF-01
Pesquisa e filtros devolvem apenas formulários publicados e compatíveis com o perfil; metadados obrigatórios estão completos.
CT-01A pesquisar por título/tema/perfil; CT-01B tentar aceder a versão retirada.
Resultados correctos; versão retirada indisponível; captura e log.
RF-02
Permissões aplicam menor privilégio e toda representação é autorizada e auditada.
CT-02A operações válidas por perfil; CT-02B acesso 
indevido; CT-02C representação expirada.
Acesso válido permitido; indevido/expirado 
bloqueado; evento auditado.
RF-03
Rascunho é gravado, retomado e cancelado sem submissão implícita ou perda de versão.
CT-03A interromper e retomar noutro dispositivo; CT-03B conflito de gravação; CT-03C cancelar.
Última versão reconciliada; aviso de conflito; estado correcto no histórico.
RF-04
Tipos, máscaras, limites e grupos repetíveis funcionam igualmente no cliente e servidor.
CT-04A valores-limite válidos; CT-04B formato inválido; CT-04C manipular pedido ignorando o cliente.
Válidos aceites; inválidos rejeitados pelo servidor com mensagem.
RF-05
Regras condicionais exibem e exigem exactamente os campos aplicáveis à combinação de respostas.
CT-05A percorrer cada ramo; CT-05B alterar 
resposta-mãe
; CT-05C submeter campo oculto malicioso.
Ramos e obrigatoriedade correctos; dado oculto ignorado/rejeitado.
RF-06
Somente ficheiros permitidos, íntegros e livres de 
malware
 são armazenados com acesso autorizado.
CT-06A ficheiro válido; CT-06B tipo/tamanho inválido; CT-06C 
malware
; CT-06D acesso não autorizado.
Válido armazenado e cifrado; restantes bloqueados e registados.
RF-07
Erros bloqueantes impedem submissão; avisos são diferenciados e apontam causa e correcção.
CT-07A obrigatório omisso; CT-07B incoerência entre campos; CT-07C possível duplicado.
Mensagens específicas; submissão bloqueada quando aplicável; log da regra.
RF-08
Alerta de IA mostra fundamento, confiança e recomendação; revisão humana prevalece.
CT-08A anexo ilegível; CT-08B inconsistência conhecida; CT-08C falso positivo; CT-08D indisponibilidade da IA.
Alertas explicáveis; decisão humana registada; 
fallback
 sem bloquear regras determinísticas.
RF-09
Pré-visualização reproduz respostas/anexos e exige confirmação e consentimentos vigentes.
CT-09A comparar formulário/pré-visualização; CT-09B consentimento ausente; CT-09C alteração antes de confirmar.
Conteúdo idêntico; bloqueio sem consentimento; nova pré-visualização após alteração.
RF-10
Submissão gera identificador único, carimbo, cópia imutável e recibo; repetição é 
idempotente
.
CT-10A submissão normal; CT-10B duplo clique/
retry
; CT-10C tentar alterar cópia submetida.
Um único pedido e recibo; alteração bloqueada; 
hash
/versão 
auditável
.
RF-11
Apenas transições autorizadas ocorrem, com responsável, prazo e motivo obrigatório.
CT-11A fluxo feliz; CT-11B transição inválida; CT-11C rejeição sem motivo; CT-11D 
SLA
 expirado.
Fluxo autorizado; inválidos bloqueados; alerta de 
SLA
; histórico completo.
RF-12
Cada evento gera mensagem correcta, no canal e idioma configurados, com tentativas e entrega rastreadas.
CT-12A e-mail/SMS/portal; CT-12B canal indisponível; CT-12C destinatário inválido.
Entrega ou 
retry
/falha registada; nenhum dado excessivo na mensagem.
RF-13
Devolução abre apenas campos autorizados e preserva versões, diferenças e justificação.
CT-13A corrigir campo permitido; CT-13B editar campo bloqueado; CT-13C comparar versões.
Permissões respeitadas; versões e diferenças consultáveis.
RF-14
Painel reflecte filas, prioridades, 
SLA
 e atribuições sem alterar o pedido original.
CT-14A filtrar/ordenar; CT-14B reatribuir; CT-14C concorrência; CT-14D alerta de atraso.
Dados correctos; conflito controlado; auditoria e alertas gerados.
RF-15
Consulta e exportação obedecem a filtros, finalidade, minimização e autorização.
CT-15A relatório autorizado; CT-15B exportar campo restrito; CT-15C grande volume.
Dados exactos e minimizados; restrição aplicada; exportação registada e 
performante
.
RF-16
Alterações configuráveis passam por rascunho, aprovação, publicação e 
rollback
 sem afectar versões antigas.
CT-16A publicar nova versão; CT-16B alteração não aprovada; CT-16C 
rollback
; CT-16D pedido antigo.
Só versão aprovada activa; 
rollback
 efectivo; submissões antigas preservadas.
RF-17
Fluxos essenciais cumprem 
WCAG
 2.2 AA, funcionam por teclado, leitor de ecrã, móvel e ligação limitada.
CT-17A teclado/foco; CT-17B leitor de ecrã; CT-17C contraste/zoom; CT-17D rede lenta e ecrã móvel.
Sem falhas críticas; relatório de acessibilidade e evidência 
multidispositivo
.
RF-18
Consentimento, finalidade, retenção, eliminação/anonimização e acessos são aplicados e auditáveis.
CT-18A recolher/retirar consentimento; CT-18B atingir retenção; CT-18C pedido de eliminação; CT-18D acesso à auditoria.
Tratamento interrompido quando aplicável; retenção executada; evidência íntegra e acesso restrito.
ID
Critério de aceitação verificável
Casos de teste essenciais
Resultado / evidência
RF-19
A linha do tempo respeita a ordem, dependências, estados, prazos e evidências configuradas para o perfil e actividade.
CT-19A concluir percurso padrão; CT-19B tentar concluir fase dependente sem evidência; CT-19C marcar fase não aplicável; CT-19D expirar reserva/licença.
Progressão correcta; bloqueio ou excepção auditada; alertas e próxima acção actualizados.
RF-20
Links publicados são oficiais, activos e associados à fase correcta, sem transmissão automática de dados pessoais.
CT-20A abrir cada link; CT-20B URL indisponível; CT-20C substituir URL; CT-20D verificar parâmetros e dados enviados.
Destino correcto; alerta para falha; histórico preservado; ausência de dados pessoais no URL.
RF-21
O dossier reutiliza dados autorizados e preserva versões e evidências submetidas.
CT-21A preencher dado comum uma vez; CT-21B recusar consentimento; CT-21C alterar dado após submissão; CT-21D tentar acesso de outra organização.
Reutilização controlada; pedido adicional quando necessário; versão submetida imutável; isolamento garantido.
Condições gerais de aprovação:
 todos os testes críticos aprovados; zero defeitos críticos ou altos sem excepção formal; evidência anexada ao requisito; regressão automatizada para fluxos repetíveis; pareceres de segurança, privacidade e acessibilidade concluídos. Casos de IA devem usar conjuntos representativos, medir falsos positivos e falsos negativos e confirmar que a indisponibilidade do modelo não impede a validação determinística.
Testes específicos de incorporação no Portal do Investidor:
 validar acesso pela navegação principal e área autenticada; sessão única e encerramento de sessão; herança correcta dos perfis e permissões; isolamento de dados por utente e organização; compatibilidade das rotas; preservação das funcionalidades existentes; responsividade e estilos; desempenho da página; auditoria; notificações; 
deployment
 e 
rollback
 sem indisponibilidade indevida do portal.
4.4. Cronograma executivo da 
operação interna
ID / actividade
Predecessora
Dependência crítica
Marco / saída
C1 — Mobilização e inventário
—
Nomeação do Gestor do Projecto, 
Product
 
Owner
 APIEX, donos dos formulários e gestores dos links.
M0:
 governação activa; inventário e prioridades aprovados.
C2 — Desenho 
da operação interna
C1
Jornadas, ficha de serviço, modelo de formulário, regras de publicação, suporte e critérios de aceitação validados.
M1:
 desenho funcional e técnico aprovado.
C3 — Catálogo e ligações institucionais
C2
URLs
 oficiais, responsáveis, avisos de saída, monitorização e contactos confirmados.
G1:
 catálogo 
e ligações de apoio prontos
 para piloto.
C4 — Configuração dos formulários prioritários
C2
Versões oficiais, campos, regras, anexos, retenção, 
workflow
 e ambientes disponíveis.
M2:
 dois a três formulários homologados funcionalmente.
C5 — IA, segurança, acessibilidade e qualidade
C3 e primeira versão de C4
Regras determinísticas estabilizadas, dados de teste, limiares de IA, revisão humana e correcção de vulnerabilidades.
G2:
 formulários e IA autorizados para piloto.
C6 — Preparação operacional
C3 e C4
Runbooks
, formação, suporte, monitorização, comunicação, backup e plano de 
rollback
.
M3:
 operação e suporte prontos.
C7 — Piloto controlado
G2 e M3
Utilizadores-piloto, dados de teste/produção controlados, suporte activo e métricas disponíveis.
M4:
 relatório do piloto; decisão 
Go
/
No-Go
.
C8 — Correcções e prontidão de lançamento
C7
Defeitos críticos resolvidos; evidências de UAT, segurança, acessibilidade e desempenho aprovadas.
M5:
 autorização de lançamento.
C9 — Lançamento 
da operação interna
M5
Catálogo, formulários, notificações, apoio, observabilidade e comunicação activos.
G3:
 entrada em operação; revisão após 30 dias.
C10 — Estabilização e expansão
G3
Capacidade operacional, análise de KPIs, priorização e disponibilidade dos próximos formulários e links.
M6:
 metas operacionais sustentadas e nova onda aprovada.
Caminho crítico
:
 
C1 → C2 → C4 → C5/G2 → C7 → C8/M5 → C9/G3
, com
 C3 e C6 
como ramos paralelos obrigatórios que 
convergem antes 
de C7. 
C3 conclui
 a prontidão 
do catálogo e das ligações institucionais
 de apoio;
 C6 
conclui
 a preparação 
operacional
.
 
Atrasos
 na homologação dos formulários, 
workflow
 interno,
 regras, 
IA, 
segurança
, preparação operacional
 ou UAT 
deslocam 
directamente o lançamento. A duração-base até G3 é de 16 semanas
 e não depende de interoperabilidade
.
Correspondência entre cronograma e plano de execução:
 C1 e parte de C2 suportam a Fase 0; C2, C3 e a preparação técnica transversal suportam a Fase 1; C4 e C5 correspondem à Fase 2; C6, C7, C8 e C9 correspondem à Fase 3. 
G1 ocorre quando o catálogo 
e as ligações de apoio estão prontos
 para piloto, ainda que o endurecimento técnico da fundação continue até à semana 8. G2 encerra a preparação dos formulários e da IA na semana 9, e G3 confirma a entrada em operação 
interna
 até à semana 16.
5. Plano faseado de incorporação do módulo
Fase / duração
Objectivo e actividades
Entregáveis
Responsável
Dependência / gate
Fase 0 — Descoberta e validação técnica
Aceder ao código, ambientes e documentação; 
inventariar as rotas e dados actualmente usados por entrada, Perfil do Investidor, simuladores, carteira e demais funcionalidades públicas/autenticadas; 
validar 
stack
, autenticação, perfis, design 
system
, 
módulos, base de dados, armazenamento, filas, pesquisa, CI/CD, 
observabilidade e segurança; 
confirmar onde inserir “Criar empresa / Realizar investimento”; 
decidir o que reutilizar, estender ou substituir.
Inventário técnico; mapa de componentes; análise de lacunas; arquitectura alvo; decisão de rota; 
backlog
; riscos; estimativa inicial.
Arquitecto/Líder Técnico e Gestor do Projecto
G0:
 arquitectura de incorporação, componentes reutilizáveis, acessos, equipa e orçamento-base aprovados.
Fase 1 — Encaixe no portal
Criar a rota do Balcão, menu, permissões, 
feature
 
flag
, layout e estrutura modular; preparar migrations, auditoria, configuração, ambientes e pipeline; garantir que funcionalidades existentes permanecem intactas.
Esqueleto do módulo acessível no portal; sessão única; perfis-base; layout integrado; pipeline e 
rollback
 testados.
Líder Técnico e 
DevOps
/
SRE
Depende de G0. 
G1:
 módulo vazio incorporado sem regressões.
Fase 2 — Catálogo e operação interna
Preservar a navegação existente e acrescentar, após entrada, Perfil do Investidor e simuladores, o acesso “Criar empresa / Realizar investimento”; implementar
 catálogo
, pesquisa, filtros, ligações oficiais
 validadas
, área do utente, protocolos, estados, 
linha do tempo
, dependências, checklist dinâmica, dossier único
, filas internas e painéis operacionais.
Catálogo navegável; área autenticada; linha do tempo configurada com reserva de nome, registo, beneficiários efectivos, NUIT, licenciamento, início de actividade, INSS, investimento e pós-estabelecimento; dossier único; 
workflow
-base; painel interno; monitorização de links e auditoria.
Product
 
Owner
 e Líder Técnico
Depende de G1 e taxonomia aprovada. 
G2A:
 jornada-base homologada.
Fase 3 — Formulários APIEX prioritários
Configurar dois a três formulários; implementar campos, regras condicionais, rascunho, anexos, pré-visualização, submissão, recibo, correcções, versões e notificações.
Formulários versionados; regras; cofre documental; recibos; notificações; casos de teste e UAT.
Product
 
Owner
 APIEX e Donos dos Formulários
Executa em paralelo parcial com Fase 2. 
G2B:
 formulários homologados.
Fase 4 — IA, segurança e qualidade
Activar validações assistidas por IA, confiança, explicações e revisão humana; executar acessibilidade, desempenho, 
SAST
/DAST, antivírus, privacidade, testes de 
integração interna e regressão do portal.
Relatório de IA; métricas de erro; parecer de segurança e privacidade; relatório 
WCAG
; testes automatizados e 
plano de correcção.
Equipa de IA, Segurança e 
QA
Depende da primeira versão dos formulários. 
G2:
 autorização conjunta para piloto.
Fase 5 — Preparação operacional
Preparar suporte, formação, 
runbooks
, monitorização, backup, capacidade, comunicação, dados-piloto, 
feature
 
flags
 e reversão.
Equipa treinada; suporte activo; dashboards; 
runbooks
; plano de lançamento e 
rollback
.
Operações e Gestor do Projecto
Converge com G2. 
M3:
 prontidão operacional.
Fase 6 — Piloto incorporado
Disponibilizar o módulo a grupo controlado dentro do portal; medir navegação, sessão, permissões, formulários, IA, 
workflow
, desempenho e suporte; recolher feedback e defeitos.
Relatório de piloto; KPIs; lista de correcções; evidência UAT; recomendação 
Go
/
No-Go
.
Gestor do Projecto e 
Product
 
Owner
Depende de G2 e M3. 
M4:
 piloto concluído.
Fase 7 — Correcções e lançamento
Corrigir defeitos, repetir regressão, validar capacidade, activar menu para todos os perfis autorizados e comunicar o lançamento.
Release
 de produção; acta 
Go
/
No-Go
; monitorização reforçada; suporte de estabilização.
Líder Técnico, Operações e 
Product
 
Owner
Depende de M4. 
G3:
 lançamento aprovado.
Fase 8 — Estabilização e expansão
Após G3
Rever resultados aos 30 dias; optimizar jornadas; adicionar formulários e sectores; ajustar regras, IA, capacidade e suporte.
Relatório de estabilização; 
backlog
 priorizado; nova onda e orçamento actualizados.
Comité de Governação
Metas mínimas sustentadas. 
Gate contínuo:
 expansão trimestral.
5.1. Frentes transversais de execução
Equipa mínima recomendada para a 
operação interna
:
 um Gestor do Projecto, um 
Product
 
Owner
 APIEX, um Líder Técnico Laravel, dois desenvolvedores 
full-stack
, um profissional de UX e acessibilidade, um profissional de 
QA
, um profissional de 
DevOps
/
SRE
 e disponibilidade parcial das funções de segurança, jurídico, dados e IA. A capacidade deve ser revista após o inventário dos formulários, considerando complexidade, volume de regras, anexos, 
fluxos internos
 e esforço de homologação.
Qualidade:
 cobertura de testes definida por criticidade, revisão de código, análise estática, testes de regressão e critérios 
Definition
 
of
 
Done
.
Segurança:
 modelação de ameaças, 
SAST
/DAST, análise de dependências, testes de intrusão antes da produção e correcção por severidade.
Dados:
 proprietário por domínio, dicionário de dados, regras de qualidade, 
deduplicação
, retenção, migração reconciliada e auditoria.
DevSecOps
:
 
branches
 protegidas, aprovação de pull requests, artefactos imutáveis, segredos fora do código e promoção controlada entre ambientes.
Operação:
 
SLOs
, alertas accionáveis, 
runbooks
, escalonamento, gestão de incidentes, capacidade, backups e testes periódicos de recuperação.
Adopção:
 formação por perfil, manuais contextuais, comunicação, atendimento de primeiro e segundo níveis e recolha contínua de feedback.
5
.2. 
Papéis de execução e autoridade
Papel
Responsabilidade e autoridade
Patrocinador Executivo
Assegurar mandato e orçamento; aprovar 
o âmbito sem interoperabilidade
, os gates e 
o lançamento da operação interna
.
Comité de Governação
Rever progresso, riscos, formulários APIEX, disponibilidade de links, indicadores e mudanças de âmbito.
Gestor do Projecto
Controlar plano, responsáveis, calendário, dependências, consulta às partes interessadas e evidências dos gates.
Product
 
Owner
 APIEX
Priorizar formulários e serviços; aprovar jornadas, regras, critérios de aceitação, mensagens de IA e homologação funcional.
Donos dos formulários APIEX
Fornecer versões oficiais, campos, regras, anexos, orientações, responsáveis, retenção e aprovação do conteúdo.
Gestores institucionais dos links
Confirmar 
URLs
 oficiais, validade, contactos, alterações, indisponibilidades e requisitos do serviço externo.
Arquitecto / Líder técnico
Responder pela arquitectura Laravel, formulários, 
workflow
 interno, camada de ligações institucionais, desempenho e qualidade, sem implementar integrações externas nesta fase.
Equipa de IA / Analítica
Configurar e avaliar validações assistidas por IA, limiares, explicações, métricas, monitorização e controlo de enviesamento.
UX e acessibilidade
Garantir jornadas claras entre portal e sites externos, formulários acessíveis, mensagens de validação compreensíveis e conformidade 
WCAG
.
Segurança, Jurídico e protecção de dados
Aprovar controlos, consentimento, finalidade, 
retenção, auditoria, uso de IA e 
procedimentos
 de 
encaminhamento institucional aplicáveis à operação interna
.
DevOps
 / 
SRE
Operar ambientes, monitorização de links, CI/CD, observabilidade, disponibilidade, backups e recuperação.
QA
Testar 
ligações oficiais
, formulários, regras, IA, 
workflow
, 
acessibilidade
 e 
operação interna, recomendando
 aprovação ou bloqueio de 
releases
.
Equipa de Dados
Gerir dicionário, qualidade, minimização, reconciliação, proveniência e prevenção de duplicações.
Donos dos serviços institucionais
Aprovar requisitos, 
ligações oficiais
, processos, 
SLAs
 internos
 e UAT de cada serviço.
5.3. Critérios 
Go
/
No-Go
 para produção
Ligações
 institucionais 
de apoio verificadas
, com responsáveis, 
finalidade, 
monitorização, avisos de encaminhamento e canais de suporte definidos.
Formulários APIEX versionados, homologados e associados a proprietários, regras, anexos, retenção e critérios de aceitação.
Validações determinísticas e assistidas por IA testadas, explicáveis, auditáveis e sujeitas a revisão humana; taxas de erro dentro dos limiares aprovados.
Zero vulnerabilidades críticas abertas e plano aprovado para as restantes.
Testes funcionais, regressão, carga, acessibilidade, segurança e UAT aprovados.
Monitorização, alertas, suporte, 
runbooks
, backups e responsáveis operacionais activos.
Todos os serviços desta fase funcionam internamente no Balcão Virtual; as ligações oficiais são usadas apenas para encaminhamento ou consulta junto dos sectores da cadeia e não realizam transferência automática de dados.
Aprovação formal da APIEX, 
dos 
donos dos serviços, 
de 
Segurança, Operações e 
do 
Patrocinador Executivo
 para o lançamento 
da operação interna sem interoperabilidade
.
6. Indicadores de sucesso
Percentagem de serviços activos no Balcão Virtual e percentagem com formulários internos completos.
Disponibilidade e taxa de ligações institucionais válidas; tempo médio de correcção de links quebrados.
Número de formulários APIEX incorporados, homologados e activos.
Taxa de conclusão e abandono por formulário e por etapa.
Percentagem de submissões com alertas de IA, alertas confirmados, falsos positivos, falsos negativos e revisão humana.
Redução de devoluções por campos incompletos, inconsistências ou baixa qualidade documental.
Tempo médio de preenchimento, validação, processamento e cumprimento do 
SLA
.
Percentagem de etapas da cadeia executadas e acompanhadas internamente no Balcão Virtual.
Taxa de encaminhamentos por ligações institucionais, disponibilidade dos links e tempo de resposta dos sectores quando aplicável.
Satisfação do utente, resolução no primeiro contacto e adopção por dispositivo, localidade, serviço e perfil.
6.1. Riscos prioritários de implementação
Devem ser mantidos num registo controlado: atraso na entrega ou homologação dos formulários; indisponibilidade dos donos dos serviços; regras de negócio incompletas; baixa qualidade dos dados de teste; desempenho insuficiente da IA; vulnerabilidades críticas; atraso na contratação de SMS ou infra-estrutura; indisponibilidade de ligações institucionais; e expansão não controlada do âmbito. Cada risco deve ter probabilidade, impacto, proprietário, resposta, data de revisão, indicador de accionamento e plano de contingência. Os riscos que afectem o caminho crítico devem ser revistos semanalmente até G3.
7. Próxima acção recomendada
Executar imediatamente 
uma avaliação técnica de teste-investidor.tempo.co.mz e 
um levantamento conjunto com a APIEX e 
os sectores que integram a cadeia
 para: (1) 
mapear a arquitectura, autenticação, perfis, navegação, base de dados, componentes reutilizáveis, ambientes e pipeline do Portal do Investidor; (2) definir a rota, o menu e os pontos de entrada do Balcão Virtual; (3) 
consolidar as ligações institucionais oficiais e nomear 
responsáveis; (
4
) inventariar
 e priorizar os formulários APIEX
; (
5
) documentar campos, regras, anexos, 
perfis, 
fluxos
 internos
, retenção e validações por IA; 
e (6
) preparar 
um piloto 
incorporado
 no 
Portal do Investidor
,
 com métricas
,
 suporte
, testes de regressão
 e 
procedimentos de encaminhamento por links oficiais quando necessário
.
C
onclusão de viabilidade:
 
a proposta é implementável como 
módulo incorporado no Portal do Investidor em teste-investidor.tempo.co.mz, com operação autónoma
 e sem interoperabilidade nesta fase
, desde que 
a avaliação inicial confirme a reutilização segura da autenticação, perfis, navegação, componentes, base técnica e pipeline existentes. O
 primeiro lançamento 
deve limitar-se
 ao
 catálogo 
institucional, às 
ligações 
oficiais de apoio
 e a dois ou três formulários APIEX prioritários
 com tramitação integralmente interna.
 