# Workshop Dataprev — consolidação dos dias 7 e 8 de outubro de 2026

Datas do workshop: **7 e 8 de outubro de 2026**. Atualização integrada em **9 de outubro de 2026**. Os horários M/T referem-se ao primeiro dia; D2 refere-se ao segundo dia.

**Status: três registros do primeiro dia cruzados e transcript do segundo dia incorporado.** A síntese integrada abaixo registra a posição no encerramento de 08/10; as seções 1 a 9 preservam o detalhamento e o comparativo de 07/10. Para o primeiro dia deste workshop, recomendo o **transcript bruto do Meet como registro principal**, com Granola como fonte complementar. A recomendação se baseia na consistência dos trechos comparados e na rastreabilidade das falas; sem áudio, não é uma medição de fidelidade palavra por palavra. As divergências relevantes estão preservadas nas seções 8 e 9.

## Fontes e método de leitura

- **M — manhã**, início às 09h44, encerramento da transcrição em 02:53:20: [documento do Meet](https://docs.google.com/document/d/1sfXIrh3xK6spGUvBO8tG76vi7I5CHeRUd92vOSJgLak/edit?tab=t.tx489n4bsnu6).
- **T — tarde**, início às 14h37, encerramento da transcrição em 03:52:17: [documento do Meet](https://docs.google.com/document/d/1XQdgq-8Qp98lMoVzD3rFr50JaoIREO61hSRfUW4coGY/edit?tab=t.m57jk2dbbw3d).
- **G — Granola**, transcript recebido no [arquivo fornecido](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4), associado ao [registro original](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4). Título: “[MARKETPLACE PAT] 20 dias em 2 - Dia 2/2”. Data indicada: Oct 7. Apesar do título, o conteúdo acompanha tanto a manhã quanto a tarde. O arquivo tem 1.110 linhas e não apresenta horários por fala. As referências G abaixo são números de linha do arquivo.

- **D2 — 08/10**, início às 09h33 GMT-03, encerramento da transcrição em 07:24:58: [documento do segundo dia](https://docs.google.com/document/d/13dyJo37nYN_6qF73Hvgq0yHkZdXJeAOEXJuuF0Fx0Yk/edit?tab=t.vp71i7f3e9al). Inclui observações Gemini e transcrição, com intervalo longo entre sessões. Não foi fornecido Granola deste dia.

Os documentos do Meet contêm **observações do Gemini e transcrição de falas**. As observações foram usadas como índice e confrontadas com as falas nos trechos de decisões, prioridades, escopo, preços e prazos. Os horários abaixo são relativos a cada sessão, não horários do relógio. O Granola fornecido contém **transcrição**, sem um resumo estruturado produzido pela ferramenta. A avaliação de resumo, portanto, é apenas do Gemini; não há base para comparar os resumidores das duas ferramentas.

O cruzamento localizou passagens equivalentes entre os textos e conferiu conteúdo, condições e correções, com atenção especial a decisões e compromissos. Não se presume que dois textos coincidentes sejam duas confirmações independentes do fato: ambos registram a mesma conversa. O início do arquivo G se aproxima de M 00:06:16; a retomada da tarde aparece por volta de G 439–445. Os minutos iniciais dos arquivos do Meet não têm correspondência clara no Granola; não atribuo essa diferença à ferramenta, pois o início efetivo da captura não foi fornecido.

Este é um inventário dos pontos substantivos de trabalho encontrados nos registros disponíveis. Repetições foram agrupadas. Conversas sociais, brincadeiras e detalhes pessoais foram representados apenas como contexto, sem reproduzir informações pessoais sem relação com o workshop. Não é uma transcrição literal de cada frase nem uma ata aprovada pelos participantes.

**Classificação:** 
- decisão/alinhamento = orientação explícita na conversa;
- declaração = relato de situação, número, experiência ou intenção;
- proposta = alternativa discutida;
- pendência = falta de definição ou validação.
- Decisão verbal não comprova aprovação contratual ou implantação.
- Afirmações sobre funcionalidades, regras jurídicas, preços e números são registradas como declarações do workshop, sem validação externa.

**Autoria:** o rótulo “Sao Paulo (14, C01)” agrupa diferentes pessoas na sala. No Granola aparecem “Me”, “Them” e o mesmo rótulo da sala. Muitos trechos “Me” repetem ou deformam conteúdo de “Them”; não é seguro interpretar “Me” como Juliane nem cada troca de rótulo como uma nova pessoa falando. Não atribuo automaticamente essas falas a Saulo, Chico, Fernanda ou Juliane. Nomes são mantidos quando citados explicitamente na atribuição de trabalho; onde houver ambiguidade, ela aparece no registro.

## Síntese integrada dos dias 7 e 8 de outubro

O workshop terminou com **quatro frentes para trabalhar primeiro: a jornada de APIs com Rafael Portinho/API DAS e três propostas de ofertas**. As três ofertas são atendimento cidadão para prefeituras, workspace com assistência a minutas e despachos no SEI, e autorregularização/cobrança. Workspace e minuta, apresentados separadamente, devem ser combinados para o Executivo. Foram selecionadas para detalhamento e validação, não declaradas plataformas já aprovadas ou implantadas. D2 03:09:32–03:13:43; 07:20:16–07:22:29.

**Dados e analítica permanecem como prioridade em paralelo.** A proposta integrada ainda precisa ser composta e apresentada. A fala que sugere deixar dados municipais para 2027 recebe uma ressalva: parte dessa capacidade pode estar nas iniciativas escolhidas. Não há fundamento para adiar toda a frente de dados para 2027. O Serviço na Ponta foi escolhido como primeiro contexto para desenhar a jornada de governança; a analítica também recebeu pedido de PoC, com alvo transcrito como UNA. Confirmar esse alvo antes de mobilizar o teste. D2 05:57:46–06:03:30; 06:33:11–06:37:11; 07:21:01–07:21:44.

**A UNA exige resolução operacional antes de sustentar o reuso com tranquilidade.** A nova org foi declarada criada e aprovada, mas a transferência dos produtos ainda depende de documentos, aprovações e assinaturas. Permanecem bugs, integrações e retestes. A contestação sobre o que está entregue versus acessível em teste deve ser resolvida por verificação conjunta. D2 06:46:13–06:49:05; 06:57:00–07:03:15; 07:09:03.

**O modelo com integradores ganhou três caminhos possíveis, escolhidos por projeto:** Professional Services executando; execução compartilhada; ou arquitetura/premissas e implantação pelo integrador. A sugestão inicial de PS sempre configurar a base foi corrigida. Tecnologias novas, risco e conhecimento do parceiro orientam a decisão, com justificativa técnica e econômica. D2 07:13:45–07:17:49; 07:22:29–07:23:17.

### Prioridades na saída do workshop

| Frente | Situação em 07/10 | O que 08/10 acrescenta | Próximo resultado esperado |
|---|---|---|---|
| APIs / Rafael Portinho / API DAS | Primeiro recorte operacional; loja em frente separada | Prioridade reiterada na abertura e no fechamento; agenda para a semana seguinte declarada já marcada | Jornada, requisitos, escopo e esforço revisáveis; não há nova comprovação do piloto pronto |
| Atendimento cidadão | Escolher poucas dores estaduais/municipais | Selecionado como uma das três propostas, com foco em demandas cotidianas de prefeituras | Conceito, fluxo, viabilidade, custo e dois slides para diretoria |
| Workspace + minutas/despachos no SEI | Automação de áreas meio como direção | Combinar duas ideias; adaptar do Judiciário para o Executivo e clientes com entrada comercial existente | Proposta integrada com base normativa, padronização e fluxo de revisão |
| Autorregularização/cobrança | Casos a selecionar | Selecionada; separar recuperação federal e ofertas para estados/municípios, incluindo formatos completo ou complementar | Requisitos reais, sistemas de débito/pagamento, regras e engajamento |
| Dados / governança / analítica | Marco estratégico; composição de ferramentas | Serviço na Ponta como primeiro desenho; PoC analítica solicitada; proposta maior ainda aberta | Jornada com Saulo, arquitetura e demonstração de um problema real |
| UNA / TJDFT | Entregas e licenciamento pendentes | Org de destino existente; transferência formal em aberto; demonstração contextualizada em 13/10 às 15h citada no contexto UNA/TJDFT | Transferência, bugs, APIs, retestes, acesso ao portal e de/para de capacidades |
| PAT / operação Mule | Entrega/adopção e arquitetura a preparar | 12/11 citado para entrega de integrações; produção 15–17/11 citada; operação, acesso e treinamento on-premise precisam ser tratados | Mobilizar responsáveis de infraestrutura, operação e mudança antes da produção |
| Marketplace | Frente própria com integração futura | Separação das APIs reiterada; marketplace de dados é outro recorte de uso, não mera loja de contratação | Desenhar integração futura e distinguir contratação de serviço de acesso ao produto de dados |
| Marketing / Field / novas capacidades | Expansão e automação discutidas | Demonstrações de campanhas, campo, reputação e conteúdo; agenda de inovação proposta | Avaliar aderência, licenciamento e maturidade; não converter demonstração em entrega adquirida |

A lista do board na abertura de 08/10 separa gateway/model proxy/wallet de bilhetagem de APIs, chega a citar a bilhetagem como quarto item e descreve a lista como orgânica. O fechamento é mais claro para o trabalho imediato: **Portinho + três propostas**, com dados em paralelo. Não reconstruo uma ordem numérica estável de todo o portfólio a partir da abertura. D2 00:01:33–00:07:03; 07:20:16–07:21:44.

### Decisões e alinhamentos atuais

1. **Manter a frente de Portinho/APIs e a loja em paralelo.** A separação do primeiro dia é reiterada no encerramento. D2 07:20:16.
2. **Detalhar três propostas de ofertas**, com atendimento cidadão, SEI/workspace com minutas/despachos e autorregularização. Essa seleção reduz a lista inicialmente mais ampla; não extingue as outras oportunidades. D2 03:09:32–03:13:43; 07:21:01.
3. **Adaptar workspace/minutas ao Executivo**, combinando as ideias e priorizando mercados nos quais já há acesso e contratos. A base do assistente deve ser normativa e padronizada; a reprodução do estilo de votos de um magistrado não se transfere automaticamente ao servidor. D2 03:03:22–03:04:17; 07:21:01.
4. **Submeter cada proposta à diretoria em até dois slides por assunto**, cobrindo problema/finalidade, forma de resolver e resultado esperado. A validação precede abertura dos consumos e execução. Interesse verbal não é aprovação da diretoria. D2 03:11:10; 07:21:44–07:22:29.
5. **Desenhar primeiro a jornada do Serviço na Ponta para governança**, validar com Saulo e depois expandir as outras possibilidades. D2 06:03:30.
6. **Construir uma proposta conjunta de dados e analítica**, incluindo carga, tratamento, acesso, painéis e consulta em linguagem natural, com uso simples e possibilidade de compor Oracle e Salesforce. D2 06:06:17–06:10:52; 06:28:22–06:35:28; 07:21:44.
7. **Explorar PoC/demo real antes da discussão executiva de dados.** O pedido analítico aparece em 06:33:11; governança e Serviço na Ponta são o outro recorte de demonstração. Não tratar como a mesma PoC já com escopo fechado. D2 05:57:46–05:59:30; 06:33:11.
8. **Tratar diretamente com os três superintendentes as dependências de Mule on-premise.** Saulo declara que conversará na semana seguinte; ele ressalva disponibilidade dos times. Não há confirmação de acesso, treinamento ou suporte já providenciados. D2 07:04:10–07:08:06.
9. **Resolver transferência e pendências da UNA**, reunir as partes e retestar na org separada. Foi declarada a existência de investimento aprovado para mais duas APIs sem custo adicional; execução e aceite ainda precisam ser demonstrados. D2 06:46:13–06:47:59; 06:58:39; 07:09:03.
10. **Revisar a estimativa e a comunicação de entrega das APIs.** Desenvolvimento, teste e passagem precisam aparecer no racional, sem usar o número genérico de 80h por API como orçamento fechado. D2 06:59:35–07:03:15.
11. **Separar interlocução técnica de preço/contrato.** Chico/Francisco, Giovani e Cláudio devem ter suporte técnico; questões comerciais são direcionadas a Meira/Letícia e à interlocução que fala com ela. Não é vedação a técnicos pedirem cotação quando necessário. D2 07:10:44–07:11:33; 07:18:46.
12. **Escolher o modelo PS/integrador caso a caso**, com três alternativas e possibilidade de acompanhamento técnico. A recomendação de PS para tecnologia nova e parceiros para nuvens maduras é critério de avaliação, não contratação obrigatória. D2 07:13:45–07:17:02.
13. **Testar os formatos de execução em três casos**, um com execução PS, outro compartilhado e outro com integrador, ainda sem associação nominal de cada oferta a cada formato. D2 07:22:29.
14. **Criar cadência de inovação com Chico/Giovani.** Foram mencionados mês, 45 dias e trimestre; a recorrência foi acolhida, mas o intervalo exato não foi fechado. D2 02:01:12.
15. **Mostrar a UNA/portal integrado e o builder no contexto da oferta**, em vez de demonstrar a ferramenta isolada. A reunião de 13/10 às 15h foi declarada marcada no contexto de UNA/TJDFT; é distinta da agenda de Portinho. D2 00:14:17–00:20:48.

### Plano integrado de ação: situação registrada em 08/10

Nenhuma ação abaixo é apresentada como realizada após a reunião. Datas como “amanhã” são convertidas tomando **08/10/2026** como referência, e não a data desta atualização. As ações de 07/10 sem retorno explícito continuam registradas na seção 4.

| ID | Ação / entrega verificável | Interlocução citada ou equipe | Prazo / condição | Situação e evidência |
|---|---|---|---|---|
| A01 | Desenhar jornada Portinho/API DAS; fechar requisitos, escopo, aceite e esforço | Rafael Portinho e equipes técnicas | Semana de 12/10; dia/hora da agenda não recuperados | Agenda declarada marcada; desenho ainda por fazer. D2 07:20:16; T 02:17:24–02:24:39 |
| A02 | Detalhar atendimento cidadão para prefeituras | Chico, Giovani, Saulo e equipe proponente | Antes de validação da diretoria | Selecionado, sem aprovação formal. D2 03:09:32–03:13:43 |
| A03 | Combinar workspace e minuta/despacho no SEI para o Executivo | Equipe de Rogério/Meira e Dataprev | Antes da proposta executiva | Conceito a adaptar. D2 03:03:22–03:04:17; 07:21:01 |
| A04 | Estruturar autorregularização: recuperação federal e oferta estadual/municipal, com opções completa/complementar | Equipe proponente + Dataprev | Antes de viabilizar oferta | Protótipo com sistemas simulados; requisitos reais abertos. D2 02:26:51–02:27:44; 02:59:07–03:01:36 |
| A05 | Preparar até dois slides por assunto: finalidade, solução e resultado esperado | Chico com apoio das equipes proponentes | Antes de apresentar ao diretor | Material solicitado. D2 03:11:10; 07:21:44–07:22:29 |
| A06 | Colher feedback de vendas e avaliar demanda/mercado | Dataprev/vendas; Felipe citado para levantamento; Rogério/Meira na oferta | Antes de investimento amplo | Sugestão de validação comercial, sem estudo concluído. D2 02:53:04–02:56:33 |
| A07 | Validar com diretoria e, após aceite, abrir consumo/modelagem, suporte e gestão de produto | Saulo/Dataprev, processo com Letícia | Após detalhamento das propostas | Dependência explícita, não aprovação obtida. D2 03:11:10; 07:22:29 |
| A08 | Desenhar jornada de governança do Serviço na Ponta e validar com Saulo | Ju/Juliane citada no encerramento da frente, com equipe de dados | Primeiro recorte da governança; sem data firme | Compromisso de desenho. D2 06:03:30 |
| A09 | Compor proposta de dados/analítica: carga, ETL, data prep, consulta e painéis | Times de dados, Informatica/Tableau, Rogério e Dataprev | Em paralelo às quatro frentes | Proposta expressamente não fechada. D2 06:29:19–06:35:28; 07:21:44 |
| A10 | Definir escopo de PoC analítica e da demo real de governança | Times de dados/analítica e Saulo | Antes de demonstração executiva | Pedidos registrados; confirmar alvo transcrito UNA e separar os dois recortes. D2 05:57:46; 06:33:11 |
| A11 | Agendar demonstração à diretoria com problema real | Saulo/Dataprev + equipes da solução | Após desenho/demo funcional | Reunião proposta, sem agenda comprovada. D2 05:59:30 |
| A12 | Conversar com Carita e apresentar governança/marketplace aplicado ao CAR | Carita + dados/negócio; articulador não individualizado | Sem prazo firme | Avaliar aderência e retorno; não contratação aprovada. D2 05:28:04–05:32:10 |
| A13 | Verificar plataforma existente com Vinicius e matriz de acesso com Guilherme/Bernardo | Saulo/interlocução Dataprev e times de dados | Antes de duplicar capacidades ou fechar arquitetura | Coexistência, acesso e complementação a confirmar. D2 05:29:04–05:32:10; 05:54:12–05:57:46 |
| A14 | Escolher instalação de governança: infraestrutura Dataprev ou pod dedicado | Arquitetura e Dataprev | Após definição conjunta | Brasil/controle governamental como requisitos declarados; topologia não escolhida. D2 05:19:26–05:21:20 |
| A15 | Disponibilizar portal UNA e demonstrar builder, template GOV e integração | Equipes UNA/Experience; apoio de acesso a identificar | **13/10/2026 às 15h**, declarada marcada no contexto UNA/TJDFT | Não confundir com agenda Portinho. D2 00:14:17–00:20:48 |
| A16 | Fazer de/para de capacidades e licenças, incluindo itens opcionais de analítica | Comercial/arquitetura Salesforce e Dataprev | Antes da oferta/instalação | Carta de correção e catálogo discutidos; não declaração de equivalência universal entre produtos. D2 00:19:51; 06:45:14–06:49:05 |
| A17 | Formalizar transferência de produtos UNA à org de destino, colher assinaturas e tratar itens gratuitos | Comercial Salesforce; Hamilton citado; Chico/Giovani para assinatura | Tentativa de resolver com Hamilton em **09/10**, não conclusão comprovada | Org declarada existente; quote/OF de transferência de valor zero pendentes. D2 06:46:13–06:47:59 |
| A18 | Validar conjuntamente APIs entregues/em teste; resolver bugs, duas integrações restantes e retestar na nova org | Delivery Salesforce + time UNA/Dataprev; Juliane na articulação | Antes de encerrar pendências | Divergência de aceite e acesso; investimento para duas APIs declarado aprovado. D2 06:46:13; 06:57:00–07:03:15; 07:09:03 |
| A19 | Revisar estimativas das APIs e regras de passagem, teste e retorno | Times de integração/PS + Dataprev | Antes das propostas de Portinho e próximas integrações | Ponto de melhoria acolhido; 80h não é orçamento acordado. D2 06:59:35–07:02:10 |
| A20 | Reunir superintendentes para acesso, treinamento e operação Mule on-premise | Saulo + três superintendentes e equipes de infraestrutura/operação/mudança | Semana seguinte, conforme disponibilidade | Conversa assumida; disponibilidade de execução não garantida. D2 07:04:10–07:08:06 |
| A21 | Preparar entrega de integrações PAT e registrar risco de sustentação | Time PAT/integração + Dataprev/operação | **12/11** citado para entrega; **15–17/11** para produção, a confirmar | Datas declaradas, sem plano validado; exemplo de incidente “dia 20” é risco operacional. D2 06:51:16; 07:04:10–07:06:24 |
| A22 | Agendar alinhamento consolidado da UNA | Partes de operação, produto, arquitetura e delivery | Após consolidar pendências; sem data firme | Reunião posterior proposta. D2 07:09:03 |
| A23 | Criar três desenhos de atuação PS/integrador e critérios de escolha | Professional Services + Dataprev | Por projeto, antes do consumo | Modelos alinhados; implementação da base não é obrigatoriamente PS. D2 07:13:45–07:17:49 |
| A24 | Selecionar três casos para testar execução PS, compartilhada e por integrador | Dataprev + PS + parceiros | Após validação das ofertas | Associação entre casos e modelos ainda aberta. D2 07:22:29 |
| A25 | Compartilhar governança Salesforce e articular responsáveis Dataprev | Equipe PS; Francisco/Chico, Giovani e Cláudio | Sem prazo fechado | Estruturas em formação; não atribuir time pronto. D2 07:17:49–07:19:30 |
| A26 | Preparar sessão remota de Agentforce com Thiago | Organização da agenda + Thiago | Após workshop, sem data | Demo retirada da agenda presencial; não cancelar toda a frente IA. D2 00:11:08–00:12:11 |
| A27 | Definir cadência de inovação e apresentação das novidades ao MGI | Chico/Giovani, time Salesforce; Milton/Everton citados | Mensal/45 dias/trimestre discutidos; intervalo a escolher | Recorrência proposta; pesquisa de licenciamento do produto transcrito “Palmata”. D2 02:00:19–02:02:36 |
| A28 | Formatar solução Field e validar com transporte, inclusive marca/app e infraestrutura | Cláudio citado na frente; times de Field/transportes | Sem prazo fechado | Formato de produto a validar; não prometer geolocalização sem conectividade. D2 00:55:07–01:00:46; 01:13:47–01:17:16 |
| A29 | Formalizar solicitação e proposta MEC respeitando capacidade de plataforma | Ricardo, Alexandre/custos, Hermes/proposta; Letícia/processo | Preço em **08/10** e proposta até **09/10** citados | Pedido e proposta em discussão; não prova de envio/aceite. D2 02:30:14–02:36:51; 02:42:42–02:45:47 |
| A30 | Confirmar referência do PL e reavaliar projeto de carteira/monetização de dados | Saulo/interlocução do projeto | Avaliação no fim do ano; número do PL a confirmar | Ideia debatida, sem solução ou base legal validada. D2 05:40:31–05:43:29; 05:52:57 |

### O que mudou nas ações do primeiro dia

- **Seleção de ofertas:** a tarefa de escolher poucas dores ganhou três propostas concretas; detalhamento, mercado, preço e validação continuam abertos.
- **Agenda UNA/TJDFT:** passou de de/para genérico a uma demonstração declarada marcada em 13/10 às 15h. O transcript não confirma sua realização, nem permite usar essa data como agenda exata de Portinho.
- **UNA:** a migração para org separada e o procedimento de transferência ficaram mais claros. A conclusão não está comprovada; APIs, bugs e retestes continuam em aberto.
- **PAT:** expectativa genérica de novembro ganhou referência à entrega em 12/11 e janela de produção em 15–17/11, além do risco operacional do on-premise. Manter confirmação de plano e dependências.
- **Dados:** a visão ampla ganhou primeiro desenho do Serviço na Ponta e pedido de PoC analítica. A proposta integrada de governança/analítica continua por compor; marketplace de dados é um terceiro recorte.
- **Integradores:** a intenção de escala passou a três alternativas de execução e um teste proposto. Não há associação definitiva de oferta a parceiro nem regra de que PS sempre implementa a base.
- **Piloto APIs em outubro, 80/180h, cortesia, preços e arquitetura do primeiro dia:** sem fechamento novo suficiente. Não marcar como concluídos por silêncio no segundo dia.

## Registro substantivo do segundo dia (08/10)

### Ofertas e maturidade

- A apresentação de Service tratou produtização de soluções, reutilização da UNA e casos de Metrô/DER. Implementação “em dias” foi argumento do apresentador para determinadas soluções, não prazo contratual para qualquer implantação. D2 00:21:33–00:22:36.
- Para o Metrô, foram apresentados atendimento B2B, qualificação de leads comerciais por CNPJ/CNAE, campanhas em estações e pós-venda; “Lina” foi o nome transcrito do agente. Regras de compliance eram parte do exemplo. D2 00:33:21–00:35:36.
- Achados e perdidos: relato pelo cidadão, cruzamento com inventário e revisão humana; 24h foi um SLA do caso demonstrado, não compromisso com a Dataprev. Emergências: transbordo imediato para operador humano foi requisito do exemplo. D2 00:39:51–00:44:36.
- Field Service: despacho, aceite, conclusão, localização e atualização de status. A apresentação de Iran citou 14 regionais, quase 300 viaturas e mais de mil operadores. São dimensões do caso apresentado, não contratação Dataprev. D2 01:11:35–01:12:41.
- A aplicação em outras regiões exige validar infraestrutura e conectividade. O diálogo questiona como compartilhar localização sem dados e admite não conhecer protocolo e viabilidade exatos. Starlink nas viaturas foi relato sobre o caso paulista, não garantia nacional. Marca própria/embutir Field no app continua em dúvida. D2 00:52:48–01:00:46.
- Telefonia/console: fevereiro de 2027 foi previsão declarada do apresentador para disponibilização de uma capacidade no Brasil. Conexão com operadoras nativas permanece necessária. Não há aprovação de projeto Dataprev nessa data; o contrato operacional próprio novembro/dezembro e sua renovação são outra conversa. D2 01:01:42–01:08:12.
- Pequenos negócios, MEI, Starter e parceria com Sebrae foram ideias exploratórias. Volumes, custos e contratos citados não são orçamento ou parceria aprovada. D2 00:27:21–00:33:21.
- Autorregularização: o protótipo permite escolher tipo de órgão e simula cadastro de débitos, negociação, parcelas e pagamento. O próprio apresentador responde que não está pronto para produção; depende de requisitos e integração real. D2 02:25:47–02:27:44.
- Cobrança federal deve considerar comunicação formal do débito, regras e cálculo no sistema de origem, e engajamento multicanal. Foram discutidas ofertas completa, de cobrança e de recuperação, considerando que vários órgãos já possuem o sistema financeiro. D2 02:55:47–03:01:36.
- Tribunais de Contas e geração de minutas judiciais foram exemplos, ainda com maturidade e mercado a avaliar. A seleção final preferiu adaptar a lógica de minuta ao Executivo, combinando-a ao workspace/SEI. D2 02:24:00–02:24:58; 03:02:34–03:13:43.
- Para multicliente, produto pronto é o ideal; uma solução minimamente construída com viabilidade de entrega em três meses foi considerada razoável na pré-venda, seis meses preocupante. São critérios verbais de seleção, não SLA universal nem prazo de projeto exclusivo. D2 03:05:21–03:08:50.
- O investimento Dataprev inclui modelagem do produto, esteira, suporte e treinamento; não se limita a configurar licença. Foi apontado risco de abrir muitas frentes e terminar com produtos incompletos. D2 02:24:58; 03:08:50–03:11:10.

### Campanhas, Slack e inovação

- Fábio apresentou criação de campanha a partir de áudio no Slack, geração de conteúdo, template enviado à Meta e criação de segmento/campanha. A aprovação da Meta permanece no fluxo. O ganho de horas/dias para minutos foi demonstração/alegação do apresentador. D2 01:23:01–01:31:31.
- Foi declarado que Slack já foi adquirido para gestão de campanhas do Serviço na Ponta e PAT. Para o Serviço na Ponta, a formalização da cadeia de aprovações e rastreabilidade foram o uso relatado; automações com os agentes apresentados são a fase seguinte. Não concluir que tudo demonstrado já roda em produção. D2 01:28:32–01:31:31.
- Audências adaptativas, campanhas por objetivos, testes de criativos e otimização de canais foram novas capacidades apresentadas. Disponibilidade, licenciamento e aderência devem ser checados antes de compor proposta. D2 01:41:49–01:51:55.
- A adoção do PAT envolve decisão institucional e áreas de comunicação. Houve divergência sobre pressão e momento de engajamento; preparar capacidade técnica não comprova plano final de adoção aprovado. D2 01:42:43–01:49:25.
- A solução transcrita como “Palmata” monitora menções/percepção em LLMs e recomenda otimização de conteúdo. Contentful foi apresentado como repositório/CMS para canais e agentes. Grafia do produto, licenciamento, preço e condições comerciais precisam ser confirmados. D2 01:54:37–02:02:36.
- Agenda de inovação com Chico/Giovani e conversa com Milton/Everton/MGI foram propostas para tornar novidades conhecidas. Não foi fechado um intervalo de 30–45 dias; o diálogo também cita três meses. D2 02:00:19–02:02:36.

### Governança, produtos de dados e analítica

- O problema central relatado é localizar, contextualizar, qualificar e disponibilizar dados com controle de uso. Metadados técnicos automatizados precisam ser combinados a conhecimento de negócio, termos, processos, políticas e papéis, que não são automaticamente conhecidos pela ferramenta. D2 05:00:05–05:18:33.
- Foram apresentados cinco grupos de capacidades: definição de negócio; catalogação e linhagem; certificação/qualidade; exposição e consumo; observabilidade. Os exemplos de Catar e Prodesp são casos relatados pelo apresentador. D2 05:06:38–05:15:36.
- Infraestrutura: Dataprev colocou controle governamental e permanência no Brasil como requisitos. Instalação local e pod dedicado foram alternativas discutidas. A escolha final depende da arquitetura; não há instalação on-premise definitivamente decidida para toda a suite. D2 05:19:26–05:21:20.
- O mercado de dados demonstrado permite descobrir produtos, ver origem/qualidade/sensibilidade, pedir acesso com propósito e tramitar aprovação. O score de 94% é dado demonstrativo, não indicador da base Dataprev. D2 05:23:25–05:27:07; 05:52:57–05:56:44.
- A solução interna existente, transcrita “Talent” (nome a confirmar), e a atuação de Vinicius precisam ser consideradas. Foi declarada possibilidade de extrair metadados, mas não consumir diretamente o catálogo existente dentro da plataforma apresentada. Coexistência não deve ser presumida sem validação. D2 05:29:04–05:32:10.
- CAR: mapas, geodados, validações e certificado de financiamento rural foram oportunidade de produto de dados. Carita deve avaliar aderência; regras com Banco Central e instituições financeiras e a operação proposta são dependências, não serviço novo formalmente aprovado. D2 05:28:04–05:32:58.
- Foram apresentados linhagem Tableau/Snowflake/Azure/AWS e scanner MuleSoft para correlacionar APIs/agentes. São capacidades declaradas/demonstradas; compatibilidade no ambiente Dataprev deve ser testada. D2 05:32:58–05:35:55.
- Dados recebidos em planilhas/arquivos e enviados por canais informais foram criticados pela qualidade, segurança e falhas em campanhas. O desenho do Serviço na Ponta pretende tratar entradas, autorizações, uso e indicadores. D2 05:37:08–05:39:40; 05:58:39–06:03:30.
- Controle de acesso externo: a intenção é que órgãos consumam dados dentro do ambiente governado, com propósito, vigência, trilha e autorização, em vez de dispersar arquivos. Push-down de políticas na camada semântica foi uma capacidade apresentada, não configuração já executada. D2 05:54:12–05:59:30.
- Carteira de dados, consentimento, eventual remuneração do titular e benefícios fiscais foram debate exploratório. “PL 234/2023” não é identificação confiável no trecho; não usar como referência jurídica confirmada. A revisão de continuidade no fim do ano diz respeito a essa iniciativa, não a toda a frente de dados. D2 05:40:31–05:52:57.
- Analítica: clientes precisam de carga, tratamento, consulta, painéis e linguagem natural, atendendo desde Excel municipal até pesquisa e bases históricas extensas. A ferramenta deve ser fácil e a composição pode incluir fornecedores distintos. Percentuais de perfis e volumes citados foram exemplos/estimativas verbais. D2 06:04:18–06:10:52; 06:30:03–06:36:17.
- Tableau Next foi demonstrado na plataforma Salesforce, com perguntas em linguagem natural e Slack/Canvas. Tableau Server e Next foram diferenciados; consulta ao vivo e extração devem considerar custo e desempenho. O Canvas gerado era uma foto do dado naquele momento; métricas e rotinas de atualização são outra capacidade. D2 06:12:38–06:24:55; 06:37:11–06:40:07.
- Data prep para transformação analítica simples é distinto de ETL em massa. A Dataprev explicitou necessidade dos dois. Nem todo dado precisa ser tempo real; atendimento/acesso merecem avaliar menor latência, enquanto dados mensais não exigem atualização contínua. D2 06:28:22–06:29:19; 06:35:28–06:36:17.
- Licenças e cortesia Tableau/Next, transparência pública, instalação base e inclusão opcional nas ofertas UNA continuam por dimensionar. O diálogo corrige a ideia de analítica já estar na base contratada: ela foi lembrada como opcional na oferta externa. Não afirmar Tableau incluído em toda licença ou já instalado na UNA. D2 06:37:11–06:50:10.

### Contratação, entrega e organização

- MEC/livros: a expansão deve preservar capacidades e lógica do serviço originalmente contratado; quantidade/valor de livros e direitos autorais não eram linha prevista. Foi alertado que ampliar para itens avulsos muda o enquadramento. Trata-se de interpretação relatada na reunião, não parecer jurídico desta análise. D2 02:30:14–02:36:51.
- Processo de proposta: Ricardo formaliza demanda, Alexandre calcula custo, Hermes prepara proposta e Letícia conduz a análise interna. Aceite do cliente/demanda devem estar vinculados ao consumo; fornecedor e validação foram tratados em paralelo excepcionalmente. D2 02:39:52–02:45:47; 02:50:03–02:51:10.
- Serviço na Ponta recebeu avaliação positiva sobre execução PS e resposta dos times. Isso não elimina problemas anteriores de relação com cliente e atraso na adoção interna. D2 06:55:14–06:56:12; 07:06:24–07:07:16; 07:12:14.
- UNA: divergência sobre acesso/entrega das APIs, estimativa de horas, entrada tardia de equipe, mudanças e desalocação foram expostas. As partes reconheceram melhorias necessárias; teste conjunto e responsabilidade de correção continuam relevantes. Não arbitrar culpa a partir de uma captura de sala. D2 06:57:00–07:03:15.
- A migração UNA exige OF/quote de transferência de valor zero e assinaturas; itens adicionais gratuitos agora poderão aparecer na renovação. Não equivale a gratuidade permanente nem conclusão da migração. D2 06:46:13–06:49:05.
- PAT e Mule on-premise: a entrega técnica funcional e a sustentação da infraestrutura são responsabilidades a coordenar. Houve discordância sobre chamar de problema atual versus risco futuro, mas concordância em conversar com responsáveis de operação/infraestrutura. Datas não provam prontidão. D2 06:51:16; 07:04:10–07:08:06.
- Relação com cliente final: a Dataprev reafirmou sua interlocução; temas devem ser tratados com ela e articulados conforme a governança. Não interpretar como autorização a contatos externos nesta tarefa. D2 07:06:24–07:07:16.
- Escala por integradores: arquitetura, setup, implementação, acompanhamento técnico e sustentação podem ser distribuídos de modos distintos. Justificar PS pela novidade da nuvem, risco, volume ou domínio; “800 versus 300 por hora” é exemplo de justificativa executiva, não tarifa proposta. D2 07:13:45–07:23:17.
- Organização Dataprev: área nova, pessoas chegando, estrutura por produto e infraestrutura compartilhada; criação de squad dedicado ainda é discussão. A governança Salesforce também foi descrita em construção e deve ser compartilhada. D2 07:17:49–07:19:30.

## Correções necessárias no resumo automático de 08/10

| Formulação do resumo | Leitura sustentada pelas falas |
|---|---|
| Quatro soluções comerciais independentes: atendimento, workspace, autorregularização e despacho | A discussão combina workspace e minuta/despacho para formar **três propostas**, além da frente Portinho: quatro frentes de trabalho no fechamento. D2 03:09:32–03:13:43; 07:20:16–07:21:01. |
| Cadência acordada a cada 30–45 dias | Mês, 45 dias e trimestre aparecem como alternativas; a periodicidade exata não foi fixada. D2 02:01:12. |
| Analítica com previsão para 2027 | O fechamento diz que a proposta ainda não está fechada e que dados seguem em paralelo; a sugestão de adiar dados municipais recebe ressalva. Não postergar toda a frente. D2 07:21:01–07:21:44. |
| Plataforma de governança obrigatoriamente on-premise | Duas alternativas: infraestrutura Dataprev ou pod dedicado; decisão em conjunto. Brasil e controle são requisitos declarados. D2 05:19:26–05:21:20. |
| Todo o fluxo de campanhas autônomas já implementado | Gestão/rastreabilidade Slack foi relatada em uso; as automações demonstradas com agentes são próxima fase. D2 01:28:32–01:31:31. |
| Field white label ou geolocalização sem internet já viáveis | O diálogo admite desconhecimento e pede aprofundamento do protocolo e da arquitetura. D2 00:52:48–01:00:46. |
| Fevereiro/2027 como entrega Dataprev | É previsão declarada de capacidade de produto no Brasil pelo apresentador. Não projeto comprado nem data validada da Dataprev. D2 01:01:42–01:08:12. |
| Governança e analítica constituem uma única PoC fechada | Há contexto do Serviço na Ponta para governança e pedido analítico com alvo transcrito UNA; precisam ser articulados e ter escopos confirmados. D2 05:57:46–06:03:30; 06:33:11. |
| Instância aprovada significa transferência executada | Org de destino foi declarada existente, mas OF, quote e assinaturas ainda são passos pendentes. D2 06:46:13–06:47:59. |
| PS sempre faz arquitetura e base antes do integrador | Essa premissa foi corrigida; três caminhos, decididos por projeto, com justificativa. D2 07:13:45–07:17:02. |
| “Modelo de interrupção” | O contexto é **modelo de execução com integradores**, testando três formatos; não interrupção operacional. D2 07:22:29. |
| PL 234/2023 identificado e regra de monetização definida | Número/ano são fragmentados e contestados; discussão exploratória sem validação jurídica. D2 05:52:57. |
| Nome “Eric” identifica sempre o mesmo profissional | Há apresentador de analítica e referências ao arquiteto do PAT. Não unir papéis de pessoas com o mesmo nome sem identificação adicional. D2 06:04:18; 06:50:10–06:51:16. |

O comparativo Meet × Granola nas seções 8 e 9 refere-se **somente a 07/10**. Para 08/10 foi fornecido apenas o documento do Meet. Não há avaliação comparativa de ferramentas para o segundo dia.


## Detalhamento histórico do primeiro dia (07/10)

As seções numeradas a seguir preservam o registro de 07/10. Para a situação no encerramento do workshop, consultar a síntese integrada e o plano de ação acima.

## Leitura executiva registrada em 07/10

A direção estratégica foi ampliar a atuação para estados, municípios e mercado privado usando capacidades já contratadas, produtos replicáveis e pouca customização. Para isso, arquitetura, preço, operação e governança precisam ser desenhados juntos, antes de chegar uma nova demanda.

A escolha operacional mais explícita ocorreu na tarde: **começar pelo ciclo de vida, acesso e bilhetagem de APIs com Rafael, usando API DAS como primeiro recorte**. A justificativa foi a relação entre tempo de implementação, custo e retorno, além da receita declarada como não recebida por dificuldades de gestão e apuração. LLMs e MCPs entram como evolução. Marketplace e APIs avançam em frentes separadas, com integração futura prevista.

O segundo grande eixo foi **previsibilidade comercial**: transformar SKUs e créditos complexos em unidades, licenças ou capacidades compreensíveis, com limites objetivos e valores claros. A conversa reconheceu que a forma de compra da Dataprev, o controle interno de consumo e a forma de venda ao órgão são camadas distintas.

A UNA foi simultaneamente apresentada como base de reaproveitamento e cobrada por entregas pendentes. O workshop não permite concluir que ela esteja integralmente pronta ou que todas as arquiteturas apresentadas tenham sido aprovadas como definitivas.

## 1. Prioridades e sua força de definição

| Frente | O que ficou expresso | Situação | Evidência |
|---|---|---|---|
| Gestão e bilhetagem de APIs | Resolver cadastro, usuário, autorização, contrato, consumo e relatório; começar com Rafael/API DAS | **Primeira prioridade operacional explícita** | T 01:45:31–01:51:38; 02:17:24–02:21:23 |
| Dados / Data Foundation / analítica | Construir visão de capacidades e arquitetura para dados, soberania, analítica e geolocalização | Prioridade estratégica; chamada de “marco zero” na manhã | M 00:58:54–01:08:41; 01:36:17–01:37:20 |
| Estados e municípios | Escolher duas ou três necessidades comuns e ofertar soluções de prateleira viáveis | Direção estratégica; lista de casos ainda por fechar | M 00:46:36–00:54:09 |
| Comunicação multimercado | Escalar o aprendizado do Serviço na Ponta com preço acessível; incluir comunicação e prestação de serviço | Prioridade de expansão; requisitos e desenho pendentes | M 00:55:51–00:56:43; 02:09:44–02:21:19 |
| PAT e mercado privado | Terminar a entrega e preparar adesão, marketing, vendas e autoatendimento com pouca fricção | Prioridade explícita para o mercado privado | M 00:57:24–00:58:54 |
| Processos de áreas meio | Automatizar produção, revisão e tramitação de documentos; compras e solicitações como candidatos | Prioridade temática; casos iniciais a selecionar | M 00:49:39–00:54:09; T 03:39:52–03:48:49 |
| UNA / TJDFT | Resolver pendências, forma de trabalho e licenciamento; aproveitar UNA para o judiciário | Continuidade necessária; não há ranking fechado | M 01:23:19–01:25:12; 02:35:31; 02:44:49–02:47:13 |
| Marketplace | Focar multicliente, contratação e acesso; prever propostas exclusivas e integração futura | Frente paralela às APIs | T 01:13:49–01:25:43; 01:33:14–01:36:05; 01:49:56–01:51:38 |
| Modelo comercial e catálogo | Simplificar unidades e capacidade; antecipar atualização e dimensionamento | Habilitador transversal | M 00:17:12; T 03:03:08–03:31:48 |

**Não houve evidência de um ranking final de todo o portfólio.** A prioridade das APIs ficou mais explícita que a ordenação das demais frentes. Dados como marco estratégico e APIs como primeira entrega operacional podem coexistir.

## 2. Decisões e alinhamentos identificados nas falas

1. **Tratar MuleSoft e a integração como capacidade da Dataprev**, reaproveitável entre projetos, não como componente exclusivo da UNA. M 00:29:10–00:30:55.
2. **Organizar a interlocução técnica em arquitetura empresarial e inovação:** Rogério e Eric para arquitetura empresarial, Rogério como primeira camada de contato; Juliane como arquiteta de inovação alinhada aos dois. M 00:32:50–00:33:53.
3. **Buscar soluções modulares e replicáveis, com investimento mínimo viável e proporcional ao risco**, evitando desenvolver tudo do zero ou montar um monólito. M 00:26:42–00:29:10; T 01:35:03.
4. **Avaliar o enquadramento de clientes e demandas pela arquitetura e pelo modelo de oferta:** acesso administrativo, customização, segurança, volume e custo importam; ofertas multicliente devem ter premissas previamente definidas. M 01:55:38–01:57:31; 02:12:30–02:17:34; 02:27:50–02:30:45.
5. **Otimizar recursos como premissa**, avaliando vantagens, perdas e impedimentos técnicos antes de abrir uma instância nova. Não equivale a aprovar especificamente a loja dentro da org da UNA. M 02:37:32–02:42:59.
6. **Usar Slack como complemento à esteira de automação.** A necessidade de um motor de fluxo agnóstico permanece distinta da interface de produtividade. T 00:48:23–01:00:58.
7. **Qualificar a entrada de propostas e pedidos pelo marketplace**, incluindo uma rota de solução exclusiva com desenho, precificação e cronograma; a operação requer alinhamento com SUNI. T 01:13:49–01:24:47.
8. **Reduzir o escopo imediato ao que pode avançar:** loja, acesso, validade, autorização e proposta; cálculo central de preço, emissão de fatura e rotinas internas dependentes de outras decisões ficam fora do avanço imediato. T 01:32:12–01:36:05.
9. **Resolver prioritariamente a jornada de Rafael**, com cadastro de APIs, usuários, autorizações, vínculo contratual e bilhetagem; um relatório de consumo apto a apoiar cobrança já entrega valor. T 01:45:31–01:50:51.
10. **Executar marketplace e gestão/bilhetagem de APIs separadamente**, mantendo visão de conjunto e integração futura. T 01:49:56–01:51:38.
11. **Começar com API DAS e ampliar depois para LLM/MCP**, com levantamento de requisitos, verificação das licenças existentes e atualização do catálogo. T 02:18:13–02:21:23.
12. **Preparar piloto com processo contratual em paralelo e possibilidade de cortesia temporária.** Funcionamento até o fim do mês foi pedido; escopo, esforço e entrega ainda precisam ser confirmados. T 02:19:03–02:24:39.
13. **Manter bolsões de serviços profissionais**, declarados como previamente aprovados por linha de serviço e contrato, inclusive para o próximo ano. Isso não demonstra aprovação automática de todo licenciamento novo. T 03:08:58–03:09:47.
14. **Simplificar a apresentação comercial:** mensageria por unidade; software por licença/capacidade previsível; infraestrutura por vCPU, memória e armazenamento quando aplicável. T 03:14:17–03:18:23; 03:28:15–03:31:48.
15. **Preferir entrega/marco/capacidade para desenvolvimento e sustentação**, mantendo racional de esforço e perfis quando solicitado. A conversa também admite horas para consultoria; não é proibição indistinta de cobrança por hora. T 03:23:47–03:27:29.

## 3. Inventário dos conceitos, declarações, problemas e propostas

### A. Organização, parceria e capacidade de execução

- **Mudança de uma operação reativa para pré-venda e inovação.** Foi relatada reorganização da área de negócios desde 2020/2021, com movimentação de aproximadamente 60–70 pessoas ao longo de cinco anos. É relato histórico, não decisão tomada no workshop. M 00:08:11–00:09:25.
- **Divisão atual de responsabilidades.** Chico ficou com pré-venda e plataforma; a outra frente reúne mercado privado, parcerias, contratos e consumos. Foram citados sete profissionais na pré-venda. M 00:10:33–00:11:33.
- **Conhecer os catálogos e propor antes da demanda.** Foram mencionados sete catálogos comprados e uso estimado de apenas 3–4% de suas capacidades. O percentual é uma estimativa verbal. M 00:12:31.
- **Plataforma e times compartilhados.** Foi defendido evitar duplicação de equipes de produto para capacidades semelhantes. Resistência cultural e disputas de atribuição foram relatadas como entraves. M 00:13:26–00:15:02.
- **Pedido até implantação integrados.** Foi declarado um fluxo integrado no sistema transcrito como IGSM, envolvendo arquitetura, infraestrutura, aprovação e mudança. A ideia é rodar consumos em uma semana; casos anteriores levaram meses. M 00:15:42–00:16:28.
- **Atualização periódica do catálogo.** Foi solicitada comunicação recorrente, com preferência por ciclos de três meses, para não atualizar catálogo apenas quando chega um consumo. M 00:17:12.
- **Apoio à gestão contratual.** Juliana, sobrenome transcrito como “Petrinha”, foi citada como nova pessoa na Salesforce para apoiar gestão técnica e administrativa dos contratos. Nome e abrangência devem ser confirmados. M 00:17:12–00:17:59.
- **Contrato estratégico versus consumo.** Foi explicado que a formalização cria condições de disponibilidade e o consumo ativa uma demanda concreta, com requisitos, proposta e valor. A justificativa jurídica apresentada é uma declaração, não parecer legal. M 00:18:48–00:23:21.
- **Agilidade de contratação.** Foi relatado que ritos tradicionais levam aproximadamente 1,5–2 anos e dificultam atender no tempo da necessidade. M 00:19:42–00:22:30.
- **Inovação proativa.** Entregar um pedido da Casa Civil foi contrastado com criar uma solução antecipadamente, como a UNA. O objetivo declarado é atuação consultiva e provocativa no mercado. M 00:24:13–00:26:03.
- **Parceria duradoura e expansão latino-americana.** Foi expressa ambição de parceria de longo prazo, cocriar capacidades e eventualmente usar a Dataprev como via de escala na América Latina. É visão futura, sem cronograma de expansão aprovado. M 00:31:49–00:35:39.
- **Patrocínio executivo e produtos.** Houve declaração de apoio de lideranças para discutir roadmap e adaptar capacidades ao governo, sem garantia de que toda adaptação seja simples ou imediata. M 01:12:53–01:16:00.
- **Governança compatível com equipe pública.** A Dataprev não aumenta pessoal no ritmo de crescimento tecnológico. Foi criticada expectativa de dezenas de profissionais por produto; organização de backlog e ferramentas foram apresentadas como caminho. M 01:26:52–01:29:51.
- **Integradores regionais.** Foi descrito programa com parceiros nacionais/regionais, suporte local e possibilidade de agrupar demandas por região. Mais de 20 empresas teriam participado da consulta. Dataprev e Salesforce definiriam arquitetura base e limites de intervenção do parceiro. M 01:33:41–01:35:18.
- **Especialistas para desenho e governança.** A intenção é escalar dezenas de projetos com especialistas concentrados em arquitetura/consultoria e integradores na implementação conforme o processo, evitando concentrar trabalho especializado em código trivial. T 03:34:48–03:35:47.

### B. Estados, municípios, UNA, atendimento e processos públicos

- **Selecionar poucas dores comuns primeiro.** A lista detalhada ainda não estava pronta. Foram citados atendimento, serviços digitais e processos administrativos; a orientação foi escolher duas ou três necessidades com pesquisa junto à prospecção. M 00:46:36–00:48:48.
- **Reaproveitar padrões sem apagar regras do órgão.** Fazendas e Detrans foram citados como famílias de problemas semelhantes entre estados. M 00:48:48.
- **Automatizar a burocracia de áreas meio.** Compras, jurídico, pessoal e logística têm estruturas repetitivas, ainda produzidas manualmente. ETP/TR, validações e conhecimento de orientações de controle foram exemplos. M 00:49:39–00:52:32.
- **Assistir a elaboração e revisão, além de abrir formulários.** O valor esperado está em apoiar a resposta e a produção documental, executar etapas e levar a revisão/validação humana. M 00:50:53–00:53:24.
- **Dataprev como cliente zero.** Foi proposto implementar internamente para provar funcionamento e demonstrar ao mercado. M 00:53:24–00:54:09.
- **Entrada modular.** A solução deve permitir começar por uma parte, integrada a sistemas existentes, sem exigir substituição imediata de processos críticos. M 00:53:24.
- **UMA experiência de governo para o cidadão.** Login, canal e acompanhamento podem ser comuns; os processos específicos ficam nos sistemas dos órgãos, integrados quando necessário. Licença ambiental, boletos e negociação de débitos foram exemplos. M 01:30:55–01:32:44.
- **A UNA tem escopo próprio.** Não foi defendido colocar todos os processos específicos dentro dela. Ela pode ser uma peça da composição. M 00:28:21; 01:31:49–01:32:44.
- **UNA com entregas pendentes.** Houve cobrança explícita de que capacidades contratadas deveriam estar prontas sem depender do primeiro cliente; a explicação de MVP não encerrou a divergência. Foi pedido mudar a forma de trabalho. M 01:23:19–01:25:12.
- **TJDFT como reaproveitamento dedicado.** O desenho apresentado prevê redeploy da UNA em org própria, com potencial de replicar para outros órgãos do judiciário. M 02:35:31; 02:43:41.
- **Licenciamento TJDFT em aberto.** Experience Cloud, WhatsApp e demais capacidades precisam ser confrontados com proposta e escopo contratado; catálogo, créditos ou aditivo dependem do caso. Foi solicitado um de/para. M 02:44:49–02:47:13.
- **Comunicação multimercado.** O Serviço na Ponta federal foi apontado como base para estados/municípios, mas o preço atual foi considerado inadequado para municípios. Foram sugeridos pacotes claros de mensageria, chat e atendimento. M 00:55:51–00:56:43.
- **Comunicar e prestar serviço.** A proposta multimercado vai além de campanhas: consulta e consumo de serviços públicos também entram na visão. Nome do produto ainda poderia mudar. M 02:09:44–02:11:41.
- **Separação do contexto MGI.** A conversa indica que a nova oferta multimercado precisa sair da estrutura dedicada ao MGI; requisitos, administração, volume e números de WhatsApp precisam orientar o desenho. M 02:10:46–02:14:35.
- **Viabilidade técnica e econômica juntas.** Não adianta uma arquitetura sofisticada cujo custo inviabilize adoção municipal. Foram aventadas trocas de SLA por custo como hipóteses, sem aprovar um SLA específico. M 02:17:34–02:22:24.
- **Pesquisa e análise de mercado.** Antes de colocar algo na prateleira, verificar demanda, preço e condições de escala; houve menção a parecer de análise de mercado e a um parceiro cujo nome saiu como “Wiild”. M 02:21:19–02:22:24.
- **Field Service como oferta replicável.** Foram apresentados casos de atendimento de campo/rodovias ligados a Prodesp/DER, com chamado, WhatsApp/central, despacho, viaturas e roteirização. Saúde, vacinação e Farmácia Popular foram possibilidades citadas, não implantações comprovadas. M 01:17:55–01:21:38.
- **Produto pronto versus criação de produto.** Foi declarado que algumas ofertas entregam cerca de 80% padrão e primeiras ondas em dias; a criação da UNA foi descrita como situação de maior aprendizado/customização. Prazos citados são experiências/exemplos, não SLA de todas as ofertas. M 01:18:50–01:24:22.
- **Compras, pedido, estoque, patrimônio e logística são processos diferentes.** A conversa final trouxe notebooks, uniformes, manutenção, entrega e baixa de bens; o caso desejado ainda precisa ser detalhado. T 03:38:02–03:47:48.
- **Onboarding é um recorte menor do ciclo.** No exemplo público, a compra pode ser prévia à solicitação; ingresso previsível, reposição e operação cotidiana exigem tratamento distinto. T 03:46:51–03:48:49.
- **Compras e solicitações como foco de exploração.** Foi manifestada preferência por priorizar esses dois temas e explorar exemplos para o dia seguinte. Central de Compras do MGI e exemplo da Polícia Federal foram mencionados. T 03:42:00–03:49:44.

### C. PAT, dados, soberania e arquitetura empresarial

- **PAT: entrega e adoção.** Entrada em novembro de 2026 e escala no ano seguinte foram expectativas declaradas. A preocupação destacou fricção do cliente e adesão, além de prontidão técnica. M 00:57:24.
- **Vendas/marketing e autoatendimento do PAT.** Foram cobradas definições e materiais do órgão transcrito como MDS, mecânica de adesão de empresas e formas de comunicação/cadastro/tira-dúvidas. A associação institucional precisa ser confirmada, pois em outros trechos aparece PAT MTE. M 00:58:12–00:58:54; 02:43:41.
- **Alinhar negócio antes da implantação.** A experiência do PAT expôs perguntas tardias sobre cada produto, dimensionamento, reutilização e cobrança; o novo arranjo deve levar insumos mais completos à modelagem. T 02:54:33–03:01:35.
- **Plataforma de dados e analítica com composição de fornecedores.** O objetivo é conhecer capacidades necessárias e combinar o melhor de cada solução, inclusive Oracle e Informatica, sem pressupor que toda a plataforma será de um fornecedor. M 00:59:58–01:08:41.
- **Fragmentação e cópias desatualizadas.** A crítica ao Conecta GOV e a data lakes isolados foi o risco de copiar dados sem acompanhar alterações na origem. M 01:01:37–01:03:16.
- **Data Foundation como ponto de partida.** Foi citado desenho já elaborado com especialistas de dados e soberania, a compartilhar e revisitar com a arquitetura Dataprev. É provocação inicial, não arquitetura final aprovada. M 01:07:00–01:08:41.
- **FinOps e capacidade.** Foram discutidas visibilidade de consumo e opções por transação/capacidade; capacidade é preferida para escala, sem excluir todo uso de transação. Letícia foi citada em grupo/comissão de FinOps. M 01:04:07–01:06:13.
- **Barreiras institucionais.** Acesso a GOV.BR e dados pode depender de decisões fora da técnica; prontidão técnica foi defendida como meio de avançar os acordos, sem comprovar que as autorizações estejam concedidas. M 01:09:38–01:11:17.
- **Integração gradual de agentes e sistemas.** Evitar substituir abruptamente trabalhos existentes de MGI/INSS; integrar primeiro e migrar depois foi a orientação defendida. M 00:42:17–00:43:55.
- **Tecnologias e visão futura.** Tableau/analítica geoespacial, Informatica, Agentforce e novidades de produtos foram pautas previstas. Termos transcritos como “homework”, “AI Force” e “cloud force” não permitem identificar precisamente todos os produtos. M 00:41:23–00:44:36.
- **Portfólio discutido.** Foram citados estados/municípios, APIs B2B, mercado privado, loja, cidadão transacional/MDS, servidor/SIAP, produtividade/operação, identidade/documentos/validação, IA, processos, analítica de prateleira, orquestração híbrida e risco. A fala menciona “dez pilares”, mas a enumeração mistura frentes e capacidades; não reconstruo uma lista numerada de dez sem o slide. M 01:36:17.
- **Single org não é sinônimo de cliente único.** Uma org pode atender um cliente ou vários; múltiplas orgs independentes foram diferenciadas de uma topologia em que orgs interagem para um mesmo contexto. M 01:50:17–02:02:36.
- **Limites físicos e de licenciamento.** Foram diferenciados governor limits, capacidade e licenças; ampliar licença nem sempre elimina limite físico. M 01:56:33–01:59:25.
- **Topologias de dados.** Hub-and-spoke, federação, Data Cloud central, Data Clouds independentes, zero-copy e home/companion foram discutidos. Houve correções e ambiguidades; não são equivalentes nem configuram aprovação universal de um modelo. M 02:02:36–02:07:58.
- **Rota preferida apresentada.** O apresentador favoreceu orgs com bases/Data Clouds próprios e compartilhamento quando necessário; UNA teria seu próprio Data Cloud separado do Serviço na Ponta. M 02:04:46–02:05:51.
- **WhatsApp como restrição de topologia.** Foram declaradas limitações para número único, companion org e uso em múltiplas orgs; devem ser validadas tecnicamente antes de desenho/compra. M 01:59:25; 02:06:48–02:09:44.
- **Framework proposto.** Público interno/externo, ocupação dedicada/compartilhada e natureza replicável/sob medida foram os três eixos apresentados. O material foi chamado de draft e proposição inicial. M 01:48:33–01:49:33; 02:22:24–02:34:29.
- **Público não determina segurança.** Saulo contestou interno/externo como critério decisório autônomo: conteúdo, restrição de acesso, carga e requisitos definem segregação. A informação ainda pode servir à governança e ao inventário de aplicações. M 02:23:21–02:30:45.
- **Mapa inicial de projetos.** MGI/Serviço na Ponta dedicado e candidato à replicação; UNA compartilhada por padrão; TJDFT dedicado com reuso; PAT e Anatel dedicados; loja como demanda interna com possibilidade de compartilhar infraestrutura. Classificação inicial, não decisão final de todas as orgs. M 02:35:31–02:43:41.
- **Sob medida pode virar produto.** Recorrência de demandas federais pode originar prateleira para estados/municípios, preservando o padrão e tratando exceções em ofertas próprias. M 02:31:34–02:33:40.
- **Reaproveitar código, conhecimento e integração.** PAT já teria usado aprendizado da UNA; replicar pode exigir resetup, sem redesenvolver a mesma capacidade. M 02:15:32–02:16:27.
- **Qualidade de dados existente.** Foi declarado uso de MDM desde 2016, qualificação de bases internas e integração em tempo real; as maiores lacunas relatadas incluem dados externos e documentação. T 01:58:26–02:00:19.
- **Exemplos de legado.** CTPS digital foi apresentada como processo automatizado; CAR como caso de anos de código e múltiplas fábricas sem documentação suficiente. Tempos e histórico são relatos dos participantes. T 01:59:32–02:00:19.
- **Evitar duplicação de contratação de governança de dados.** Verificar com Vini contratação em andamento antes de abrir disputa ampla; uma aplicação menor em APIs pode testar valor. T 01:53:58–02:03:45.
- **Data Foundation reaproveitável entre frentes.** Serviço na Ponta foi citado como necessidade concreta de evolução de dados, que poderia também atender um recorte menor das APIs. T 02:01:59–02:03:45.

### D. Slack, integração e automação

- **Slack como camada de produtividade.** Foi apresentado como interface entre pessoas, eventos e sistemas para consultas, ações, aprovações e acompanhamento. Banco Inter e uso interno da Salesforce foram exemplos de maturidade. T 00:03:24–00:05:52; 00:14:20; 00:45:51–00:47:41.
- **Casos concretos antes de discurso de produto.** Chico pediu jornada demonstrável que permita entender ganho frente ao uso atual de Teams/e-mail. M 00:55:51; T 00:07:08–00:08:05.
- **Operação multinuvem e swarming.** Conectores, webhooks, monitoramento e canais com responsáveis foram apresentados como forma de organizar incidentes. T 00:08:57–00:11:04.
- **Hub para sistemas internos Dataprev.** Demanda de Pedro por camada única para Clarity, Proteus e outros sistemas, com consultas, distribuição e acompanhamento; os nomes dos cinco sistemas não ficaram integralmente identificados. T 00:12:06–00:13:10.
- **Busca e linguagem natural com permissões.** Pesquisa cruzada nos aplicativos conectados foi apresentada como limitada à matriz de acesso do usuário. T 00:15:21; 00:18:26–00:20:29.
- **Proad demonstrado com APIs simuladas.** Consulta de processos, prioridade/vencimento, despachos, anexos, assinatura e canal do processo foram mostrados. Não houve comprovação de integração produtiva com o Proad real. T 00:22:18–00:26:54.
- **DevOps demonstrado com ferramentas reais em ambiente de demo.** Jira, Sonar, Jenkins, Bitbucket e Salesforce integrados; alteração, build/testes, quality gate, PR, aprovação, change e deploy acompanhados no Slack. T 00:30:48–00:36:31.
- **SEI como protótipo.** Foram mostradas/citadas telas para prioridades e assinaturas; sem acesso ao ambiente ao vivo. SEI continuaria guardando dados e governando o processo; Slack melhoraria a jornada. T 00:43:11–00:45:51.
- **Materiais de pré-venda, sem prontidão garantida.** Foi dito explicitamente que Proad, SEI e DevOps pertencem ao conjunto de protótipos pré-construídos e não são produtos para entrar em produção no dia seguinte. T 00:37:50.
- **Proxy e token.** MuleSoft foi usado no exemplo como proxy que enriquece chamadas com token e controla acesso. T 00:40:35.
- **WSO2 e adoção incremental.** Foram discutidos padrão existente, resistência e coexistência; retirar WSO2/SAP BODS apareceu como desejo, não decisão de migração imediata. T 00:41:29–00:42:26; 02:15:38–02:16:37.
- **BPM é uma necessidade própria.** O pedido é um configurador de fluxo com etapas, regras, responsabilidades, travas, dados e integrações para aplicações heterogêneas. Não se resolveu apenas mostrando a interface Slack ou fluxos nativos Salesforce. T 00:48:23–01:00:58.
- **Limitações de legado.** SIAP/mainframe e ausência de APIs foram obstáculos citados; peças devem ser encaixadas conforme a jornada e os limites de cada ferramenta. T 00:55:54–00:59:16.
- **Retomar caso de orquestração.** Houve compromisso de investigar quem construiu o caso demonstrado para TRF e como a orquestração funcionava. T 00:50:23.
- **Segurança e residência do processamento.** Foi exigido detalhamento de onde Agentforce processa dados, data center, anonimização e processamento externo, para avaliação de segurança e autorizações do cliente. Não houve confirmação de que tudo rode dentro da Dataprev. T 00:15:21–00:17:26.

### E. APIs, marketplace, governança de consumo e IA

- **Hub de dados com contratos e rastreabilidade.** Escala exige identidade, autorização, segurança, privacidade, consumo, custo/receita e vínculo contratual por órgão/agente. T 01:04:07–01:06:08; 01:52:23–01:53:05.
- **Wallet, cota e proxy.** Carteira pode limitar chamadas, tokens ou valor; foi apresentada como mecanismo de controle, sem definir um único modelo para todas as ofertas. T 01:06:08; 02:04:28–02:08:06.
- **Esteira comercial ponta a ponta como visão.** Proposta, contratação, liberação de acesso, consumo, extrato e faturamento foram conectados conceitualmente; escopo imediato foi depois reduzido. T 01:07:12–01:09:16; 01:31:11–01:35:03.
- **Contratos pequenos precisam de automação.** Foram citados contratos de R$ 200/R$ 300 cujo custo administrativo pode exceder a receita. Alertas de saldo, expiração e aditivo foram sugestões. T 01:07:12–01:09:16.
- **Autorizações são distintas.** Autorização da controladora do dado e credenciamento do usuário são etapas diferentes. O fluxo com INSS poderia automatizar ofício, espera e resposta, sem dispensar a autorização. T 01:09:16–01:11:27; 01:36:57–01:38:42.
- **Solução exclusiva versus prateleira.** Exclusiva exige desenho/modelagem, proposta e cronograma; multicliente tem modelo e preço preestabelecidos, mas também pode precisar de proposta comercial automática. T 01:12:43–01:24:47.
- **Entrada qualificada e roteamento.** Formulário poderia encaminhar arquitetura, produto, SUNI ou consumo conforme demanda; recorrência pode revelar candidato a produto multimercado. T 01:15:41–01:25:43.
- **CRM existente e Proteus.** A visão inclui integração com CRM da Dataprev e refletir contratos no Proteus. Sua customização exige confirmar API/processo com Franco; não basta pressupor integração padrão. T 01:25:43; 01:33:14–01:34:12.
- **Volume multicliente.** Foram declarados cerca de 2.250 contratos, menos de 50 específicos e aproximadamente 2.200 multicliente; esse universo justificou o foco. T 01:36:05.
- **Um painel não resolve cadastro transacional.** Contar chamadas por domínio/e-mail não basta para associar AGU/CNJ ao contrato INSS, vigência, autorização e cotas. T 00:42:26–00:43:11; 01:36:57–01:38:42.
- **Contrato único de serviço com cotas compartilhadas.** O modelo pretendido permite consumir diferentes APIs autorizadas no mesmo pacote; a loja atual forçaria produtos/contratos separados. O transacional deve sustentar o modelo e depois ser consumido pela loja. T 01:39:28–01:45:31.
- **Cadastramento necessário.** O requisito inclui API, conteúdo/capacidade, usuário, órgão, autorizador, documento/meio de autorização, vigência, motivação, contrato e consumo. Critérios de cobrança e tratamento de erro também foram citados. T 01:36:05–01:37:50; 01:48:58–01:50:51.
- **Relatório como primeira saída útil.** PDF/relatório com contrato, cliente, usuários e consumo foi considerado suficiente para apoiar a cobrança antes da automação total do faturamento. T 01:49:56–01:51:38.
- **Documentação de APIs irregular.** Foram mencionadas 23 APIs e diferenças de completude; padronização, códigos de erro, semântica e enriquecimento por IA foram propostas. Catálogo de APIs e catálogo de dados são camadas distintas. T 01:54:56–01:57:34.
- **Informatica e linhagem.** Qualidade, registro mestre/MDM, origem e dado prevalente foram apresentados como complementos à exposição por API/MCP; integrar não garante, por si, qualidade dos dados. T 01:26:44–01:30:21; 01:53:05–01:53:58.
- **Model Proxy e controle de LLM.** Foi apresentado controle por tokens ou valor, vínculo a usuário/contrato e roteamento ao modelo mais eficiente, não necessariamente ao mais barato. Inclusão no catálogo e no licenciamento precisava ser validada. T 02:04:28–02:09:05.
- **Mensuração antes de venda.** A dificuldade de medir tokens foi apontada como impedimento para cobrar serviços existentes/futuros. GPU, agentes e MCP foram exemplos. T 02:05:21–02:11:53.
- **Simulador de integração.** Foi citado simulador já existente, desconhecido pela equipe, como exemplo de falha de comunicação de capacidades. T 02:09:57.
- **Bridge API→MCP.** Foi demonstrada/apresentada federação para expor APIs como ferramentas MCP sem desenvolvimento adicional naquele exemplo, mantendo gateway existente; não ficou decidida migração geral. T 02:14:37–02:15:38.
- **Reestruturação multimercado.** Dia 20 foi citado para reorganização da conta; é expectativa verbal a confirmar. T 02:17:24.
- **Delivery precisa ser organizado.** Foi reconhecida dificuldade de alocar execução, especialmente em MuleSoft, e necessidade de coordenação interna; demonstração não elimina esforço de implementação. T 02:23:38–02:24:39.

### F. Modelo comercial, preços, escala e investimento

- **Compra, venda e aferição não são a mesma pergunta.** A conversa reformulou a discussão para como Dataprev prefere comprar e quais informações precisa para formular venda; aferição de fatura é pós-venda. T 03:02:22–03:03:08.
- **Previsibilidade e unidade compreensível.** Crédito abstrato foi criticado quando não permite traduzir preço e quantidade ao governo. WhatsApp por mensagem foi exemplo de unidade clara. T 03:03:08–03:05:36.
- **Capacidade tem teto.** “Ilimitado” foi considerado nome enganoso; explicitar volume mensal, simultaneidade e regras de expansão/preço foi solicitado. T 03:06:30–03:08:07.
- **Créditos não foram abolidos universalmente.** O participante também admitiu preferência por créditos em mensageria para usar diferentes canais/categorias. O requisito é tradução clara em serviço/unidade/valor. T 03:09:47–03:10:29.
- **Revisões comerciais dependem de aprovação interna.** Data Cloud/MuleSoft e modalidades chamadas de ilimitadas foram descritos como assuntos submetidos ou a submeter à aprovação, sem concluir contratação de tudo. T 03:05:36; 03:10:29; 03:21:47–03:22:55.
- **Volume real superou hipóteses iniciais.** Foi declarado que Serviço na Ponta excedeu previsão de 120 milhões de conversas/ano e exigiu investimentos de GPU; os números posteriores são falas que precisam confirmação. T 03:11:22–03:12:18.
- **Formato final de proposta.** Linha de serviço, descrição, quantidade, valor unitário, mensal e anual; a unidade muda conforme licença, usuário, mensagem ou capacidade. T 03:14:17–03:16:03.
- **Janela de conversa como exemplo.** Contrato de outro fornecedor com janela de 24h e separação de infraestrutura/conversa foi citado para ilustrar preço objetivo; não é tabela Salesforce aprovada. T 03:16:46–03:17:35.
- **Aferição e órgãos de controle.** Foi discutida dificuldade de justificar uma caixa preta de consumo, mesmo quando mais barata; preferir unidade clara facilita apuração, segundo os participantes. T 03:19:13–03:22:55.
- **CPF na base versus usuário/licença.** Oracle foi exemplo de preço por CPF; Data Cloud teve propostas de 10 milhões e 160 milhões de registros discutidas. Distinguir registro de pessoa, usuário do sistema e licença evita dimensionar incorretamente. T 03:23:47; 03:28:15–03:30:06.
- **Escala nacional precisa caber no preço.** 220 milhões de pessoas foi usado como cenário de dimensionamento; valores ilustrativos da conversa não são orçamento aprovado. T 03:29:11–03:30:06.
- **Prontidão antes da demanda.** Foi proposto colocar capacidades selecionadas em cortesia por dois ou três meses, com Dataprev pagando setup, e negociar transição ao consumo. Duração e itens permanecem por fechar. T 03:32:30–03:34:48.
- **Sala de guerra comercial.** Consolidar preços, capacidade e itens de cortesia foi encaminhado como ação, incluindo Márcia e time interno. T 03:16:03; 03:23:47; 03:33:54–03:34:48.
- **Racional de serviços profissionais.** Perfil, esforço e proporcionalidade devem sustentar o preço; foi criticado excesso de horas de arquitetura frente à execução. Horas podem compor o racional sem serem a unidade final de desenvolvimento/sustentação. T 03:24:39–03:27:29.

## 4. Encaminhamentos, responsáveis e prazos

“Não identificado” significa que a transcrição não permite fixar o dono; não representa ação atribuída genericamente a todos. As datas derivadas abaixo partem de 07/10/2026 e precisam confirmação de agenda.

| Ação / entrega | Responsável identificável ou envolvido | Prazo / condição | Evidência |
|---|---|---|---|
| Levantar jornada completa de cadastro, usuário, órgão, autorização, contrato, cota e consumo das APIs; enviar requisitos e prints | **Rafael**, com alinhamento Chico/Giovani e equipe Salesforce | Imediato; insumo para desenho e piloto | T 01:46:25–01:48:58; 02:12:38; 02:18:13 |
| Enviar disponibilidade para reunião de detalhamento | Rafael; interlocutor Salesforce não individualizado | Sem data fechada | T 01:48:11 |
| Desenhar solução API DAS e evolução para modelos/proxy, com orçamento, escopo e cronograma | Equipe Salesforce com Rafael/Chico; donos internos a definir | Documento na terça e apresentação na quarta da semana seguinte foram citados: **13 e 14/10**, a confirmar | T 02:19:03–02:23:38 |
| Ter ao menos parte do piloto funcionando | Equipe de execução a organizar | **Fim de outubro de 2026 como alvo**, condicionado a escopo/esforço/licença | T 02:19:03–02:24:39 |
| Conferir licenças já disponíveis e incorporar produtos faltantes ao catálogo | Equipe comercial/contratual Salesforce, Dataprev e Chico; “Viviani” citada | Em paralelo ao piloto; atualização na semana seguinte citada | T 02:09:05–02:12:38; 02:18:13–02:22:32 |
| Aprovar/formalizar cortesia e contratação para o piloto | Instâncias comercial/contratual citadas, identificação parcial | Em paralelo à implantação; não comprova aprovação final | T 02:19:03–02:22:32 |
| Organizar recursos internos de delivery | Liderança/equipe Salesforce não individualizadas | Antes do compromisso final de execução | T 02:24:39 |
| Desenvolver marketplace multicliente em frente própria, prevendo integração futura | Chico e equipe da loja, com arquitetura empresarial | Sem prazo firme | T 01:36:05; 01:49:56–01:51:38 |
| Alinhar rota de solução exclusiva/proposta com SUNI | Equipes de marketplace, negócio, arquitetura e SUNI | Sem prazo firme | T 01:18:20–01:24:47 |
| Confirmar API/processo de criação/reflexo de contratos no Proteus | Consultar **Franco**; solicitante não individualizado | Dependência técnica | T 01:33:14–01:34:12 |
| Consultar contratação de governança/catálogo de dados em curso | Consultar **Vini**; solicitante não individualizado | Antes de abrir frente ampla equivalente | T 01:53:58–02:01:08 |
| Padronizar e testar documentação de APIs no recorte de DAS | Rafael e equipe técnica a definir | Proposta de teste, sem prazo firme | T 01:54:56–01:57:34 |
| Compartilhar arquitetura inicial de Data Foundation/soberania | Apresentador/equipe do desenho; autoria individual incerta | Sem prazo firme | M 01:07:00–01:08:41 |
| Revisitar arquitetura e contratos para dados/analítica | Rogério, Eric e especialista de dados, junto à Dataprev | Sem prazo firme | M 01:00:45–01:08:41 |
| Identificar duas ou três principais dores de estados/municípios com prospecção | Dataprev/prospecção; Rogério contribui com experiências | Antes de definir primeiras ofertas | M 00:46:36–00:48:48 |
| Levantar requisitos da plataforma de comunicação multimercado | Dataprev e arquitetos, incluindo Rogério | Antes de fechar arquitetura/preço | M 00:55:51–00:56:43; 02:14:35 |
| Compartilhar jornadas, mapa de frentes e blueprint; evoluir classificação de orgs | Autores do material/arquitetura; Rogério associado à apresentação | Sem prazo firme | M 01:25:58; 01:32:44; 01:48:33–01:49:33; 02:48:01–02:50:17 |
| Fazer reunião para mudar a forma operacional de trabalho da UNA | Interlocutores de operação/produto e Salesforce não individualizados | Proposta para durante a visita/até o dia seguinte; duração diverge: 30 minutos no Meet e uma hora no Granola. Não comprova reunião realizada | M 01:25:12; G 235 |
| Fazer de/para de licenciamento e escopo do TJDFT; esclarecer Experience Cloud e WhatsApp | Dataprev/Salesforce, com **Dário/TJDFT** | Sem prazo firme | M 02:44:49–02:47:13 |
| Validar ferramentas no catálogo e solicitar preços a provedores | **Letícia**, com arquitetura e provedores | Conforme desenho de solução | M 01:41:22–01:46:24 |
| Produzir desenho conceitual de uma página, com fluxo, componentes e problema resolvido | Equipe proponente, dono não individualizado | Antes da validação executiva; propostas podem acompanhar | M 01:43:17–01:47:29 |
| Enviar atualizações periódicas do catálogo | Fornecedores/equipe responsável pelo catálogo | Preferência por **três em três meses** | M 00:17:12 |
| Registrar mercado privado e evolução do PAT, incluindo vendas/marketing/adoção | Editor do mapa, identidade não segura | Encaminhamento da manhã | M 00:58:54 |
| Preparar prontidão e adoção do PAT; cobrar definições e material institucional | Equipes PAT/negócio/comunicação e órgão envolvido | Novembro de 2026 como expectativa de entrada; escala em 2027 | M 00:57:24–00:58:54 |
| Fornecer documentação de processamento do Agentforce | Equipe técnica Salesforce; destinatário Dataprev/segurança | Sem prazo firme; informar data center, processamento e anonimização | T 00:16:24–00:17:26 |
| Investigar implementação da orquestração do caso TRF | Apresentador Slack, não identificado individualmente | Retorno sem data fechada | T 00:50:23 |
| Compartilhar apresentação Slack e estimativas de infraestrutura | Respectivos apresentadores, nomes não seguros | Sem prazo firme | T 00:00:01–00:01:15; 00:10:02 |
| Apresentar plataforma de batimento de dados | Interlocutor Dataprev, não individualizado | Sem prazo firme | T 01:10:26–01:11:27 |
| Consolidar modelo por capacidade/unidades e preços de Data Cloud | Time comercial/técnico, com **Márcia** citada | Sala de guerra a marcar; sem data firme | T 03:16:03; 03:23:47; 03:33:54 |
| Levantar setup mínimo e itens selecionados para cortesia | Pessoa chamada de **“Juliana”** na fala; provável associação com Juliane deve ser confirmada | Antes da aprovação; prazo sem fechamento | T 03:33:05–03:34:48 |
| Reunir exemplos de compras e discutir oferta de serviços/ativos | **Eduardo** citado; Iran e demais especialistas envolvidos | “Amanhã” = **08/10/2026**, agenda prevista | T 03:37:09–03:49:44 |
| Prosseguir apresentações de Service Cloud, dados/Informatica, Tableau, Marketing Cloud e temas de IA | Especialistas das frentes | Agenda de 08/10; início em torno de 9h30/10h citado | T 03:49:44 |
| Publicar/avançar processo de integradores | Dataprev, responsável individual não determinado | “Sexta-feira que vem”; **16/10 é leitura provável**, a confirmar | M 01:33:41; T 03:34:48 |
| Abrir canal com executivos de serviços/suporte | Liderança Salesforce; Chico, Saulo e Giovani convidados | Convite/almoço e compartilhamento de contatos; realização não confirmada | M 00:08:11; 02:51:07 |

### Atenção especial aos prazos do piloto

- **Terça/quarta da semana seguinte** têm referência relativamente clara, mas precisam ser confirmadas com os donos.
- **15/10** aparece em trecho com falas sobrepostas e várias referências a cronograma; não fixo essa data como entrega formal aprovada.
- **80 e 180 horas** aparecem na negociação de esforço. O resumo automático escolhe 180h, mas as falas não sustentam uma estimativa final inequívoca.
- **Fim do mês** é uma solicitação de funcionamento parcial/piloto, seguida de pedido para conhecer o escopo antes de estimar duração. Não é compromisso comprovado de entregar toda a solução nesse prazo.
- A reorganização no **dia 20** e a duração de **dois ou três meses de cortesia** são expectativas/propostas, não eventos realizados ou condições fechadas.

## 5. Números e declarações que merecem confirmação

| Dado citado | Como usar na consolidação |
|---|---|
| 60–70 pessoas movimentadas; sete pessoas em pré-venda; uso de 3–4% de catálogos | Contexto e estimativas verbais da reorganização, não indicadores auditados. M 00:09:25–00:12:31. |
| Tramitação em uma semana versus casos de seis meses | Uma semana é objetivo declarado; não tratar como resultado universal já alcançado. M 00:15:42. |
| Cerca de R$ 100 milhões/ano associados a APIs sem apuração adequada | Impacto declarado pelos participantes; não é perda auditada nem necessariamente problema causado pelo MuleSoft. M 00:30:55; T 01:49:56. |
| Margem de 2,5% no Serviço na Ponta | Declaração referente àquele contexto; PAT foi explicitamente diferenciado. M 00:21:37. |
| INSS: R$ 450 milhões e custo transcrito de forma ambígua na manhã; contrato de R$ 2 bilhões à tarde | Contextos potencialmente distintos; não fechar comparação financeira sem fonte original/validação. M 00:21:37; T 01:38:42–01:39:28. |
| 2.250 contratos, aproximadamente 2.200 multicliente | Dimensão declarada para justificar prioridade; não inventário verificado. T 01:36:05. |
| 23 APIs | Recorte mencionado para teste de documentação; confirmar quais APIs estão incluídas. T 01:54:56. |
| 80% padrão e primeiras ondas em 7–12 dias | Experiências e alegações de replicabilidade; não garantia para cada caso. M 01:18:50–01:22:29. |
| 120 milhões/ano e mais de quatro vezes o previsto | Volumes declarados do Serviço na Ponta; confirmar período e unidade, pois conversa mistura referências mensais/anuais. T 03:08:07; 03:11:22. |
| 10 milhões → 160 milhões de CPFs; cenário de 220 milhões | Dimensionamento de propostas e cenário ilustrativo; CPF na base não é usuário licenciado. T 03:28:15–03:30:06. |
| 80/180 horas e cifras de exemplos de preço/SLA | Negociação e ilustrações, sem estimativa ou tabela final. M 02:18:31–02:21:19; T 02:22:32–02:23:38; 03:16:46–03:30:06. |

## 6. Avaliação de qualidade do Meet e erros do resumo automático

**A transcrição do Meet é útil para recuperar a evolução da conversa e localizar evidência, mas exige revisão de termos, autores e números. O resumo do Gemini não deve virar ata automaticamente.**

| Aspecto | Evidência nos registros | Efeito na análise |
|---|---|---|
| Cobertura e navegação | Duas sessões extensas com horários relativos e falas | Permite rastrear escopo e mudanças de prioridade; sem áudio, não mede omissões reais |
| Autoria | Pessoas da sala compartilham “Sao Paulo (14, C01)” | Atribuição individual de decisões e tarefas é fraca |
| Termos técnicos | “Milly/Mil/Mild/Missoft”, “Slag/Slab”, “data prév”, entre outros | Exige normalização contextual; termos ambíguos precisam do slide/áudio |
| Falas sobrepostas | Trechos de topologias, estimativas e prazos interrompidos | Não converter negociação fragmentada em compromisso exato |
| Resumo versus fala | Objetivos, propostas e relatos são promovidos a resultados/decisões | Rever status antes de usar como ata |
| Números | Há correções e valores aproximados durante a conversa | Preservar contexto e marcar confirmação necessária |

### Divergências concretas encontradas

1. **PAT com nome errado nos próximos passos.** O resumo da manhã usa “Programa de Apoio Técnico”, enquanto a seção de detalhes identifica Programa de Alimentação do Trabalhador. Manter PAT e confirmar órgão/escopo; não usar a expansão errada.
2. **Uma semana apresentada como melhora já obtida.** Os detalhes do Gemini dizem que o tempo foi reduzido de seis meses para uma semana. A fala começa com “a ideia é que a gente rode os consumos em uma semana”. M 00:15:42.
3. **MuleSoft tratado como gerador da perda de receita.** O resumo diz que consumo via MuleSoft gerava perda. A fala relata ausência de ferramenta estruturada de cadastro/apuração e apresenta a camada de integração como parte da solução. M 00:30:55; T 00:42:26–00:43:11.
4. **Framework classificado como aprovado.** A apresentação é chamada de draft, primeira sugestão e proposta inicial; o eixo interno/externo é contestado. Houve receptividade e discussão, mas não aprovação irrestrita de todos os critérios. M 01:48:33–01:49:33; 02:22:24–02:30:45.
5. **Single/multi-org confundidos em parte das observações.** O próprio diálogo corrige multicliente dentro de single org versus orgs que interagem. Não classificar automaticamente ambiente compartilhado como multi-org. M 01:52:19–02:02:36.
6. **Home/companion e Data Clouds independentes fundidos.** As falas distinguem e corrigem modelos, inclusive um caso compartilhando Data Cloud e outro de bases independentes. O resumo elimina parte da ambiguidade indevidamente. M 02:05:51–02:07:58.
7. **Créditos descritos como decisão única da tarde.** Em 02:19:03 discutem-se créditos para itens comprados/proxy; em 03:04:04–03:16:03 exige-se unidade e preço claros na venda ao governo. Há ainda aceitação de créditos para mensageria. São contextos distintos, não autorização genérica nem abolição universal.
8. **180 horas tratadas como cronograma definido.** As falas mencionam 80 e 180 horas, pedem escopo e mostram interrupções. Não sustenta orçamento/esforço final fechado. T 02:22:32–02:24:39.
9. **Bolsões confundidos com aprovação geral.** Foi declarada pré-aprovação de bolsões por linha/contrato; não de todos os produtos/licenças apresentados. T 03:08:58–03:09:47.
10. **Cobrança por entrega generalizada a todos os serviços.** O debate distingue consultoria por horas de desenvolvimento/sustentação por entrega/capacidade, com racional de perfis. T 03:23:47–03:27:29.
11. **Proad/SEI podem parecer soluções produtivas no resumo.** A fala deixa claro protótipo, APIs simuladas e telas sem acesso ao ambiente SEI. T 00:22:18; 00:37:50; 00:44:03.
12. **Cargos executivos não consistentes.** O mesmo executivo aparece descrito com títulos diferentes durante a manhã. Registrar apoio/visão declarados sem certificar cargo vigente. M 00:35:39; 01:16:00.

## 7. O que permanece aberto

1. Resumo produzido pelo Granola, caso exista: o arquivo recebido só permite comparar transcrições.
2. Áudio/vídeo e início efetivo das capturas, se for necessário resolver divergências literais. A cobertura temática de manhã e tarde está identificada; a fidelidade absoluta não foi medida.
3. Identificação dos falantes da sala para confirmar responsáveis e autores.
4. Slides/blueprint para confirmar os dez pilares, topologias e nomes técnicos mal transcritos.
5. Escopo mínimo do piloto, lista de APIs e critério de aceite.
6. Responsável de execução, estimativa final de esforço e cronograma aprovado.
7. Produtos já licenciados, itens que exigem atualização, cortesia e aprovações.
8. Destino final do marketplace e integração com cálculo de preço/faturamento central.
9. Arquitetura efetiva de UNA, Data Cloud e comunicação multimercado, com limites e dimensionamento.
10. De/para TJDFT e situação de cada entrega pendente da UNA.
11. Duas ou três primeiras ofertas estaduais/municipais, preço e adequação ao mercado.
12. Detalhes de residência/processamento de IA e autorizações necessárias.

## 8. Comparação concluída: qual registro está melhor neste workshop?

**O Meet bruto é a melhor base documental neste caso.** Ele preserva melhor as passagens examinadas de implementação, negociação comercial e cronograma, além de oferecer horários que permitem recuperar o contexto. O Granola é complementar: registra as duas sessões e às vezes escreve melhor nomes de produtos, mas tem duplicações, frases desconexas e divergências que tornam arriscado usá-lo sozinho para gerar a ata.

Essa conclusão vale para os arquivos recebidos e para esta reunião. Não demonstra que uma ferramenta seja sempre superior nem identifica a causa dos problemas de captura. Sem a gravação, não se calcula taxa de erro nem se comprova qual palavra foi efetivamente pronunciada.

| Critério | Meet bruto | Granola recebido | Avaliação |
|---|---|---|---|
| Cobertura temática | Manhã e tarde em arquivos separados | Manhã e tarde no mesmo arquivo | Ambos cobrem os grandes temas; título do Granola não delimita seu conteúdo |
| Localização de evidências | Horários por trecho e separação das sessões | Sem horários; localização por linha | Meet favorece auditoria e retorno ao contexto |
| Autoria individual na sala | Rótulo coletivo; alguns participantes identificados fora dele | “Me”/“Them”/sala, com repetições entre rótulos | Ambos insuficientes para fechar todos os responsáveis |
| Nomes de produtos | Várias grafias fonéticas de Salesforce/MuleSoft/Slack | Melhor grafia em alguns trechos, mas API DAS vira também PayDAS/Petrobras | Granola ajuda pontualmente; não resolve nomes por completo |
| Coerência e duplicação | Também contém interrupções e falas mal reconhecidas | Várias versões repetidas e trechos sem conexão com o assunto | Meet mais aproveitável nos trechos examinados |
| Decisões e condições | Mantém separação de frentes, escopo e condicionantes com mais clareza | Os grandes encaminhamentos reaparecem, mas alguns termos mudam o sentido | Usar Meet como base e conferir G como apoio |
| Números e prazos | Tem ambiguidades próprias, como 80/180h | Diverge em valores, duração, nomes e agenda; não resolve 80/180h | Nenhum autoriza fechar números ambíguos |
| Resumo automático | Gemini disponível, com erros descritos na seção 6 | Resumo do Granola não fornecido | Comparação entre resumidores não realizada |

### Exemplos concretos que sustentam a avaliação

1. **Separação das frentes: mudança de sentido.** M/T preserva “estratégia de implementação é segregado nesse momento” em T 01:51:38. O Granola registra “estratégia de implementação é ser agregado nesse momento” em [G 825](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4). O próprio G 823 diz que não será implementado casado/acoplado. A leitura consistente do conjunto é **duas frentes separadas, integração futura**, não implementação conjunta obrigatória.
2. **API DAS vira Petrobras no trecho repetido.** [G 795–796](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) alterna API DAS/PayDAS em “Them” e Petrobras em “Me”. A jornada é de contratação e autorização de APIs, como em T 01:38:42–01:41:22. Não há base nesse trecho para incluir Petrobras como novo cliente ou projeto.
3. **Repetição altera a impressão de autoria técnica.** [G 162](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) repete várias vezes a frase que apresenta Eric como arquiteto especializado em dados. O parágrafo anterior distingue Rogério, Eric e um especialista de dados a envolver. Não trato a repetição como quatro declarações nem como prova de especialidade/cargo de Eric.
4. **Uma semana: Granola confirma a correção do resumo do Gemini.** [G 30](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) mantém que uma semana é objetivo, enquanto existem consumos que levam seis meses. Está alinhado com M 00:15:42. Aqui os dois transcripts sustentam a mesma leitura e o resumo do Meet é que transforma intenção em resultado.
5. **MuleSoft: grafia e sentido recuperados pelo Granola.** [G 82](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) escreve MuleSoft e preserva a distinção entre capacidade Dataprev e UNA, além da falta de cadastro/apuração para faturar. É um bom apoio para normalizar a grafia fonética em M 00:29:10–00:30:55.
6. **Reunião da UNA: duração divergente.** M 01:25:12 registra meia hora; [G 235](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) registra uma hora. O pedido de reunião está preservado; sua duração precisa de confirmação.
7. **Contrato INSS: o Granola não estabiliza a quantidade.** [G 795](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) contém 220 e logo depois “desses duzentos”; T 01:38:42–01:39:28 menciona 200. O ponto de negócio é que um contrato pode agrupar vários consumos. A contagem não deve ser fechada pela transcrição.
8. **Receita INSS: valores diferentes.** [G 52](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) traz R$ 453 milhões e aproximadamente R$ 1,5 bilhão/ano; M 00:21:37 traz R$ 450 milhões e uma formulação ambígua para o outro valor. Sem fonte financeira original, ambos permanecem declarações com divergência.
9. **Mensageria: Granola torna específico um preço genérico.** T 03:04:04 fala em “tanto centavo a mensagem”. [G 988](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) traz “5 centavos”. O princípio de preço unitário está claro; **R$ 0,05 não é preço acordado nem validado**.
10. **Piloto: concordância no alvo, sem fechar esforço.** G 945–948 preserva terça/quarta da semana seguinte e o pedido de conhecer escopo para determinar duração. Não oferece confirmação legível das 80/180 horas ou de 15/10 em T 02:22:32–02:24:39. O cruzamento reforça a condição, não fecha a estimativa.
11. **Responsável do piloto continua incerto.** [G 945](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) cita Fernanda; a passagem correspondente do Meet contém referência a Viviani. Não escolho um nome apenas porque está mais legível. Rafael é o interlocutor da jornada prioritária; isso não o torna automaticamente responsável pelo delivery completo.
12. **Consultoria versus desenvolvimento: Meet é mais claro.** T 03:23:47–03:27:29 permite distinguir horas de consultoria e pacotes/entregas de desenvolvimento e sustentação. [G 1058](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) usa “Disney Movement” onde o contexto trata desenvolvimento. A orientação comercial se recupera melhor no Meet.
13. **Cortesia: os dois preservam negociação aberta.** [G 1080](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) menciona dois/três meses, depois seis e três, terminando em negociação. Isso reforça T 03:33:05–03:34:48: há proposta de divisão do custo e levantamento do setup, sem duração contratual fechada. “Juliana” não vira atribuição segura a Juliane.
14. **Agenda de encerramento: data incoerente no Granola.** [G 1108](https://notes.granola.ai/t/ff05f8ac-b549-4ea0-a6bc-cd301ad91e6d-008umkv4) associa a apresentação de amanhã a “1º de julho”, incompatível com a data Oct 7 e com a própria referência a amanhã. T 03:49:44 cita início por volta de 9h30/10h. Uso 08/10 como data derivada da reunião e mantenho o horário como previsão a confirmar.

## 9. Matriz de cruzamento dos principais pontos substantivos

Esta matriz complementa o inventário da seção 3 e a lista de ações da seção 4. “Confirmado nos textos” significa que o mesmo sentido aparece em ambas as capturas; não certifica implantação, aprovação formal, valor financeiro ou exatidão da fala.

| Ponto | Meet | Granola | Resultado do cruzamento |
|---|---|---|---|
| Automatizar burocracia e reduzir tempo do consumo | M 00:15:42–00:17:12 | G 30–32 | Objetivo de uma semana, catálogo periódico; não resultado universal já obtido |
| Significado de consumo/contrato | M 00:18:48–00:23:21 | G 39 e discussão adjacente | G torna explícita a pergunta sobre “consumo”; manter explicação de ativação de uma demanda sob contrato |
| Reuso de integração e receita de APIs não apurada | M 00:29:10–00:30:55 | G 82–84 | Corrobora problema e distinção MuleSoft/UNA; valor permanece relato |
| Arquitetura empresarial e inovação | M 00:32:50–00:33:53 | G 86–88 | Rogério/Eric e Juliane aparecem no alinhamento; especialidades e cargos não são certificados |
| Visão de parceria e LATAM | M 00:34:46–00:35:39 | G 92–94 | Ambição de longo prazo; não expansão contratada |
| PAT, marketing, adoção e visão de dados | M 00:57:24–01:08:41 | G 161–165 e contexto anterior | Preserva frentes; nomes do programa/órgão e calendário requerem confirmação |
| Entregas pendentes da UNA | M 01:23:19–01:25:12 | G 231–235 | Cobrança e mudança de forma de trabalho confirmadas; duração da reunião diverge |
| Blueprint em elaboração | M 01:48:33–01:49:33 | G 307 | Draft, primeira sugestão; não aprovação final irrestrita |
| Single org/multicliente e multi-org | M 01:52:19–02:02:36 | G 309–331 | Distinção e debate preservados; Granola ajuda na grafia de alguns termos |
| Data Cloud, zero-copy, home/companion | M 02:03:25–02:07:58 | G 333–337 | Correções aparecem nas duas fontes; validar diagrama antes de fechar topologia |
| WhatsApp e restrições de arquitetura/licença | M 02:08:51–02:21:19 | G 343–345 e discussão seguinte | Não reduz tudo a público/interno/externo; requisitos e limites precisam do desenho |
| Framework de classificação | M 02:22:24–02:30:45 | G 367–391 | Há discussão/contestação; frase G sobre “seis eixos” não cria um novo framework aprovado |
| TJDFT e licenciamento | M 02:35:31–02:47:13 | G 393–411 | Reuso dedicado e de/para continuam necessários |
| Slack e automação | T 00:03:24–01:00:58 | G 445–639 | Demonstração e complementaridade; não decisão de substituir todos os motores de workflow |
| Proad e SEI | T 00:22:18; 00:37:50; 00:44:03 | G 521; 569 | APIs simuladas/protótipo, não produção aprovada |
| WSO2 e MuleSoft | T 00:42:26–00:43:11 | G 581 | Integração/coexistência; não há decisão genérica de desativar WSO2 |
| Marketplace multicliente e escopo imediato | T 01:13:49–01:36:05 | G 751–775 | Qualificar contratação/acesso; definição central de preço/fatura está fora do avanço imediato |
| Proteus e contratos | T 01:33:14–01:34:12 | G 765–769 | Consultar Franco sobre integração; não assumir API pronta |
| Jornada Rafael/API DAS | T 01:38:42–01:50:51 | G 795–821 | Primeiro recorte operacional confirmado; cadastro/autorização/contrato/consumo/relatório |
| Loja e bilhetagem em frentes separadas | T 01:49:56–01:51:38 | G 823–825 | Confirmado pelo contexto; “agregado” em G é divergência literal, não nova decisão |
| Documentação de APIs | T 01:54:56–01:57:34 | G 839 e discussão adjacente | Recorte de 23 APIs citado; lista e aceite não fechados |
| Proxy para LLMs e capacidade on-premise | T 02:01:59–02:09:05 | G 877–879 | G explicita possibilidade de execução on-premise na solução Mule apresentada; não estender a todos os componentes Salesforce/Agentforce |
| API para MCP | T 02:12:38–02:16:33 | G 915 e contexto | Evolução demonstrada/proposta; não transformar em promessa universal de zero desenvolvimento |
| Prioridade API antes de LLM/MCP | T 02:17:24–02:21:23 | G 933–939 | Primeira prioridade preservada; requisitos/licenças em paralelo |
| Cronograma do piloto | T 02:21:23–02:24:39 | G 941–952 | Semana seguinte/fim do mês como alvos condicionais; nomes, horas e 15/10 não fechados |
| “Ilimitado” com capacidade e regras | T 02:28:30–03:08:07 | G 962–992 | Limites mensais/simultaneidade e previsibilidade; não capacidade infinita |
| Compra, medição e venda em camadas distintas | T 03:03:08–03:16:03 | G 982–1000 | Modelo interno de crédito não obriga o órgão a comprar créditos; preço unitário de mensageria aceito |
| Bolsões previamente aprovados | T 03:08:58–03:09:47 | G 996–1000 | Pré-aprovação por linha/contrato aparece em ambas; referência ao próximo ano é mais explícita no Meet |
| Modelo por unidades/capacidade e preços de dados | T 03:16:03–03:31:48 | G 1014–1074 | Direção preservada; exemplos não são tabela comercial aprovada |
| Consultoria, desenvolvimento e sustentação | T 03:23:47–03:27:29 | G 1052–1066 | Separar horas consultivas de entrega/capacidade; Meet recupera melhor o racional |
| Setup mínimo e cortesia | T 03:33:05–03:34:48 | G 1078–1080 | Levantamento antes de aprovação; duração e responsável a confirmar |
| Integradores e escala de implementação | M 01:33:41; T 03:34:48–03:35:47 | G 1082–1088 | Arquitetura/governança com especialistas; implantação por parceiros conforme processo |
| Serviços a empregados e áreas meio | T 03:39:52–03:48:49 | G 1098–1104 | Granola explicita “AI Employee” e onboarding/manutenção; é discussão de oferta, sem contratação aprovada |
| Agenda seguinte | T 03:49:44 | G 1108–1109 | Service Cloud e outras frentes confirmadas como agenda prevista; horário exato não fechado |

### Como usar os registros daqui em diante

Guardar as três fontes. Usar o Meet bruto com horários para sustentar a ata, o Granola para complementar termos e contexto, e o resumo do Gemini apenas como índice revisado. Antes de transformar a lista de ações em plano de execução, confirmar com os participantes os responsáveis, escopo e aceite do piloto; os números de esforço; os itens de licença; os valores divergentes; a duração da cortesia; e as entregas da UNA/TJDFT. Essa confirmação é uma pendência do trabalho descrito na reunião, não uma condição para concluir esta análise.