Briefing para Diretoria — Adoção do TTP¶
Tipo de documento: template para deliberação executiva. Audiência: diretoria, conselho ou comitê de tecnologia de empresas que avaliam contratar o TELECOM TOWER POWER (TTP) como ferramenta de apoio ao planejamento de rádio-enlaces. Status: referência. Cada organização deve adaptar números, datas e nomes ao seu próprio contexto e fazer aprovar formalmente.
1. Resumo executivo¶
O TTP é uma plataforma SaaS brasileira (hospedada em AWS sa-east-1, com contingência on-prem) que automatiza a etapa de triagem e dimensionamento preliminar de candidatos a rádio-enlace, combinando:
- Modelos de propagação consagrados (ITU-R P.1812 (Py1812), Longley-Rice/ITM, Sionna RT).
- Modelo ML estatístico (regressão ridge sobre 17 features topográficas e geométricas) com bandas de confiança publicadas.
- Base ANATEL pré-importada de torres e ERBs no território brasileiro.
- API REST + frontend para times de RF.
Recomendação: adoção como ferramenta complementar ao fluxo atual de engenharia, não como substituto de medição de campo, drive test ou emissão de ART. O ganho de produtividade é real (triagem de candidatos de horas → minutos) mas exige governança interna formal — ver Política Interna de Uso do TTP.
2. Envelope de uso recomendado¶
| Atividade | Adotar TTP? | Observação |
|---|---|---|
| Triagem de candidatos em massa | Sim | Caso de uso primário, ROI mais claro |
| Priorização e ranking comparativo | Sim | Onde o modelo tem maior valor relativo |
| Apoio a propostas comerciais preliminares | Sim | Com margem extra explícita de +5 dB |
| Pré-cálculo de cobertura para due diligence M&A | Sim | Com ressalva de bandas de confiança |
| Link budget contratual final | Não | Requer engenheiro habilitado + medição |
| Documento entregue à ANATEL/concessionária | Não | TTP não substitui ART nem ICP-Brasil |
| Cobertura comercial declarada ao consumidor final | Não | Requer drive test e validação de campo |
RMSE do modelo atual: aproximadamente 12–15 dB (cross-validated). Significa que qualquer estimativa pontual deve assumir incerteza de ±15 dB em casos piores. Para decisões com margem apertada, essa incerteza é proibitiva sem medição complementar.
3. Principais riscos e mitigações¶
3.1 Risco técnico — precisão do modelo¶
| Item | Status atual | Mitigação |
|---|---|---|
| RMSE em produção | ~12–15 dB cross-validated | Margem operacional de +5 dB + drive test |
| Cobertura urbana 3D (prédios individuais) | Não modelada | Drive test obrigatório em ambiente denso |
| Clutter (MapBiomas) | Opt-in, não ativo por padrão | Habilitar quando aplicável a estudos rurais |
Modelo lgbm-v1 em pipeline |
Em desenvolvimento | Aguardar promoção formal com gates publicados |
3.2 Risco regulatório¶
| Item | Análise |
|---|---|
| Aceitação pela ANATEL como fonte de link budget | Não há homologação formal da ferramenta pela ANATEL. |
| Necessidade de ART | Sempre obrigatória — TTP não dispensa. |
| Conformidade LGPD (dados pessoais) | DPA padrão disponível; dados de torres são públicos. |
| Logs de auditoria com SIEM | Disponíveis no plano enterprise (AWS CloudTrail + custom). |
3.3 Risco de fornecedor¶
| Item | Status |
|---|---|
| Bus factor | 1 (declarado pelo fornecedor em POSITIONING.md §8.4) |
| Cláusula de escrow de código | Disponível com gatilho de 60 dias de inatividade |
| Conversão de licença para Apache 2.0 | Automática em 2028-05-01 (cláusula BSL em LICENSE.md) |
| SOC 2 Type I / II | Framework publicado, sem atestação ainda (janela 2026-Q4) |
| Deploy on-prem isolado | Suportado (docker-compose.onprem.yml) — opção de hedge |
3.4 Risco financeiro¶
| Item | Recomendação |
|---|---|
| Modelo de cobrança SaaS | Validar projeção de uso vs. tier antes de assinar anual |
| Lock-in | Médio — dados/torres são padrão ANATEL, modelos exportáveis |
| Custo de saída | Baixo — exportação de relatórios em PDF/CSV padrão |
4. Critérios para piloto (PoC) de 30 dias¶
Antes de contratação anual, recomenda-se:
- Selecionar 20–50 candidatos reais dos quais a empresa já tem medição de campo válida.
- Submeter ao TTP os mesmos candidatos via API ou frontend.
- Comparar estimativas TTP × medição em três dimensões:
- Erro absoluto médio em dB (esperado: dentro de banda de confiança publicada).
- Ranking relativo (Spearman correlation candidatos TTP × candidatos campo).
- Detecção correta de candidatos inviáveis (precision / recall em SINR borderline).
- Avaliar workflow com 2–3 engenheiros internos por 2 semanas.
- Mensurar tempo de triagem antes/depois.
Gates de aprovação sugeridos para passar de piloto a contrato anual:
- Spearman > 0.7 entre ranking TTP e ranking campo.
- Falsos positivos críticos (candidato declarado bom pelo TTP e ruim em campo) < 10% no conjunto piloto.
- Pelo menos um engenheiro sênior interno valida que a ferramenta acelera triagem sem aumentar carga de revisão posterior.
5. Recomendações contratuais¶
| Cláusula | Recomendação |
|---|---|
| SLA | Mínimo 99,5% disponibilidade mensal (verificar default) |
| Janela de saída | 30 dias para downgrade, 90 dias para encerramento total |
| Acesso a logs próprios | Exportação contínua para SIEM próprio (S3 / Splunk / etc.) |
| Direito a exportação completa de dados | Garantido em formato aberto (PDF/CSV/GeoJSON) |
| Escrow de código | Acionável após 60 dias de inatividade do fornecedor |
| Conversão BSL → Apache 2.0 em 2028 | Confirmar cláusula em LICENSE.md anexo ao contrato |
| Direito a auditoria de segurança | Pelo menos 1× ao ano, sob NDA |
| Aviso de mudança de modelo ML | Notificação ≥ 30 dias antes de promoção de versão |
6. Impacto financeiro e operacional estimado¶
Preencher com números reais da empresa adotante. Os valores abaixo são ilustrativos.
| Métrica | Antes do TTP | Com TTP | Variação |
|---|---|---|---|
| Tempo médio de triagem por candidato | X horas | Y minutos | Z% redução |
| Custo por candidato pré-validado | R$ X | R$ Y | Z% |
| Drive tests necessários por mês | N | M | redução de K |
| Engenheiros dedicados à triagem inicial | A | B | realocação |
| Custo total anual do TTP | — | R$ X | |
| Payback estimado | — | X meses |
7. Posicionamento final¶
O TTP é uma ferramenta honesta sobre suas limitações (publica RMSE, bandas de confiança, status SOC 2, bus factor, dependências externas) e localizada para o mercado brasileiro (ANATEL pré-importada, sa-east-1, DPA-LGPD, EULA em português). Esses são diferenciais reais frente a alternativas internacionais (Atoll, iBwave, Planet) cujo custo de licença e curva de adaptação ao contexto brasileiro são significativamente maiores.
Por outro lado, o produto está em fase de maturidade inicial:
- Modelo ML é estatístico simples (ridge), não rede neural profunda.
- SOC 2 ainda sem atestação independente.
- Equipe é pequena (mitigada por escrow + BSL/Apache flip em 2028).
- Cobertura urbana 3D não está modelada.
A recomendação é adotar com governança formal (política interna obrigatória, margens operacionais explícitas, ART sempre acima de qualquer saída do TTP) e negociar contrato com cláusulas de saída e escrow ativas.
8. Decisão solicitada à diretoria¶
A diretoria delibera sobre:
- [ ] Aprovar piloto de 30 dias nos termos descritos na seção 4.
- [ ] Designar responsável técnico (CREA + ART) para validação dos resultados.
- [ ] Autorizar adoção da Política Interna de Uso do TTP como anexo obrigatório ao contrato.
- [ ] Autorizar contratação anual após gates de piloto cumpridos (seção 4).
- [ ] Negociar cláusulas contratuais conforme seção 5.
- [ ] Não adotar nesta janela — re-avaliar em N meses.
Assinaturas¶
| Função | Nome | Data | Assinatura |
|---|---|---|---|
| Diretor de Engenharia / CTO | |||
| Responsável Técnico (CREA + ART) | |||
| Diretor Financeiro / CFO | |||
| Diretor Jurídico / Compliance | |||
| CEO |
Documentos relacionados:
- Política Interna de Uso do TTP
- FAQ de due diligence
- Validação técnica e limitações
- Modelos de propagação
- Deploy isolado on-prem
- EULA, Termos de Serviço, Política de Privacidade, DPA-LGPD do contrato vigente