Trust Score v4 — Template de Relatório
Documento canônico:
04-operations/trust-score-v4-report-template.md
Status: template operacional aprovado para uso Produto: Trust Score by Tech Human Issue: #24
Regras obrigatorias de nomenclatura
Seção intitulada “Regras obrigatorias de nomenclatura”Todo relatorio deve usar:
- Trust Score by Tech Human na capa, header e rodape;
- Trust Score como referencia curta;
- Trust Score Laudo, Trust Score Completo ou Governanca Continua como tier;
- score 0-100, nunca escala 1-5 como resultado final.
Nunca usar como titulo ou assinatura:
- TH Vetting;
- Due Diligence;
- Tech Due Diligence;
- Auditoria Tecnica.
Esses termos podem aparecer apenas em contexto historico interno, nunca no relatorio final do cliente.
Campos obrigatorios da capa
Seção intitulada “Campos obrigatorios da capa”| Campo | Exemplo | Regra |
|---|---|---|
| Produto | Trust Score by Tech Human | Fixo |
| Cliente | Cliente Exemplo | Nome legal ou nome aprovado |
| Sistema auditado | Portal interno de IA | Nome do sistema |
| Tier | Trust Score Laudo | Laudo, Completo ou Governanca |
| Data | 04 Maio 2026 | Data de emissao |
| Metodo | Metodologia v4 | Versao visivel |
| Score geral | 0-100 | Calculado, nunca digitado manualmente |
| Classificacao | Risco critico | Derivada da faixa |
| Alerta imediato | Requer Assessment de Viabilidade | Obrigatorio se score < 35 |
Estrutura de 12 secoes
Seção intitulada “Estrutura de 12 secoes”1. Resumo executivo
Seção intitulada “1. Resumo executivo”Objetivo: CEO entende a decisao em menos de 3 minutos.
Campos:
- o que foi auditado;
- por que importa agora;
- score geral e classificacao;
- decisao recomendada;
- principal risco de negocio;
- proximo passo.
Modelo:
O sistema [nome] foi avaliado pelo Trust Score by Tech Human para responder se esta pronto parausuarios reais, escala, dados sensiveis e evolucao sustentavel. O resultado foi [score]/100,classificado como [classificacao]. A recomendacao e [decisao], porque [motivo principal].2. Trust Score por dimensao
Seção intitulada “2. Trust Score por dimensao”Objetivo: mostrar o score 0-100 nas quatro perguntas executivas.
Campos:
| Dimensao | Pilares | Score | Leitura executiva |
|---|---|---|---|
| D1 Funciona de verdade? | Arquitetura, Qualidade, Backend, Frontend, Testes | D1_score | Prontidao real |
| D2 Aguenta crescer? | Escalabilidade, DevOps | D2_score | Escala e operacao |
| D3 Protege a empresa? | Seguranca, Dados | D3_score | Risco legal/reputacional |
| D4 Gera ou destroi valor? | Governanca, Produto | D4_score | TCO e valor |
Regra: cada score deve ter evidencias associadas nos pilares que o compoem.
3. Framework metodologico dos 5 niveis
Seção intitulada “3. Framework metodologico dos 5 niveis”Objetivo: quebrar a objecao de que “funcionou na demo, entao esta pronto”.
Campos:
- nivel de uso de IA detectado;
- nivel de risco do sistema;
- diferenca entre uso atual e maturidade exigida;
- implicacao para negocio.
Modelo:
O sistema apresenta sinais de uso de IA em nivel [N], mas opera como [tipo de sistema]. Isso criauma diferenca entre velocidade de prototipo e maturidade de producao.4. As 6 perguntas estrategicas
Seção intitulada “4. As 6 perguntas estrategicas”Objetivo: responder perguntas de CEO com evidencias de codigo.
Perguntas obrigatorias:
- Quem governa esse sistema dentro da empresa?
- Se a pessoa que criou sair, qual o impacto?
- Isso pode virar produto SaaS/B2B?
- O sistema aguenta escala?
- O sistema protege a empresa?
- Isso gera valor real ou divida futura?
Formato por pergunta:
| Campo | Regra |
|---|---|
| Resposta curta | 1 frase |
| Classificacao | OK, Atencao, Risco Alto ou Risco Critico |
| Evidencia | Arquivo, comportamento, arquitetura, dado ou observacao |
| Impacto de negocio | Linguagem executiva |
5. Analise de valor
Seção intitulada “5. Analise de valor”Objetivo: separar valor real de divida futura.
Campos:
- valor que o sistema ja gera;
- valor que pode gerar se corrigido;
- risco de continuar sem remediacao;
- custo de oportunidade;
- decisao recomendada: manter, corrigir, reconstruir, escalar, governar ou desligar.
6. Achados criticos de seguranca
Seção intitulada “6. Achados criticos de seguranca”Objetivo: isolar temas que podem gerar dano imediato.
Obrigatorio quando D3 < 40 ou quando houver achado critico.
Campos por achado:
- titulo;
- severidade;
- evidencia;
- impacto;
- recomendacao;
- prazo sugerido.
Se nao houver achado critico:
Nao foram identificados achados criticos de seguranca no escopo avaliado. Ainda assim, asrecomendacoes de D3 devem ser acompanhadas no roadmap.7. Scorecard tecnico dos 10 pilares + lente Produto / Negocio
Seção intitulada “7. Scorecard tecnico dos 10 pilares + lente Produto / Negocio”Objetivo: CTO entende como o score foi formado.
Pilares e lente obrigatorios:
| Pilar | Escala | Dimensao |
|---|---|---|
| Arquitetura | 0-5 | D1 |
| Qualidade de Codigo | 0-5 | D1 |
| Backend | 0-5 | D1 |
| Frontend | 0-5 | D1 |
| Testes | 0-5 | D1 |
| Escalabilidade | 0-5 | D2 |
| DevOps / CI-CD | 0-5 | D2 |
| Seguranca | 0-5 | D3 |
| Dados / Banco | 0-5 | D3 |
| Governanca | 0-5 | D4 |
| Produto / Negocio | 0-5 | D4 — lente de valor |
Regra: score abaixo de 3 ou acima de 4 exige justificativa explicita.
8. Diagnostico de origem
Seção intitulada “8. Diagnostico de origem”Objetivo: explicar como o sistema foi construido sem culpar o criador.
Campos:
- origem provavel: humano, AI-augmented, vibe coding, no-code, legado ou mistura;
- nivel de confianca;
- evidencias;
- o que a IA entregou bem;
- o que exige intervencao humana;
- implicacao para manutencao.
Tom obrigatorio: editorial, tecnico e respeitoso.
9. Inventario tecnico
Seção intitulada “9. Inventario tecnico”Objetivo: registrar a fotografia tecnica do sistema.
Campos:
- frontend;
- backend;
- banco de dados;
- autenticacao;
- integracoes;
- infraestrutura;
- deploy;
- observabilidade;
- testes;
- documentacao.
10. Mapa de riscos
Seção intitulada “10. Mapa de riscos”Objetivo: priorizar riscos por impacto e urgencia.
Campos por risco:
- titulo;
- dimensao;
- severidade;
- probabilidade;
- impacto de negocio;
- evidencia;
- owner sugerido;
- prazo recomendado.
11. Caminho de solucao / roadmap
Seção intitulada “11. Caminho de solucao / roadmap”Objetivo: transformar diagnostico em execucao.
Formato recomendado:
| Fase | Janela | Objetivo | Entrega |
|---|---|---|---|
| 0 | 0-7 dias | Contencao | Seguranca, segredos, rollback, backups |
| 1 | 7-21 dias | Estabilizacao | testes, observabilidade, arquitetura minima |
| 2 | 21-45 dias | Remediacao | refatoracao, dados, CI/CD |
| 3 | 45-90 dias | Escala | multi-tenancy, governanca, custos, produto |
12. Proximo passo na jornada Tech Human
Seção intitulada “12. Proximo passo na jornada Tech Human”Objetivo: conectar o relatorio ao caminho comercial correto.
Regras:
- score 0-35: Assessment de Viabilidade antes de execucao;
- score 36-60: Trust Score Completo ou TH Build + JARVIS para remediacao;
- score 61-80: plano pontual + Governanca Continua;
- score 81-100: Governanca Continua para manter maturidade;
- padrao repetivel: avaliar conversa Trustyu Forge;
- falta de pessoa: avaliar THunting;
- perda de contexto: avaliar NeedyU.ai embedded.
Checklist final antes de entregar
Seção intitulada “Checklist final antes de entregar”- Capa usa Trust Score by Tech Human.
- Tier visivel.
- Score geral calculado automaticamente ou revisado contra a formula.
- Quatro dimensoes presentes.
- 10 pilares tecnicos e lente Produto / Negocio preenchidos.
- 6 perguntas estrategicas respondidas.
- 12 secoes na ordem aprovada.
- Nomes antigos removidos.
- Proximo passo comercial claro.
- CEO consegue entender a decisao.
- CTO consegue entender a evidencia.